# O Manual do &lisa;

Alexander
Neundorf

    neundorf@kde.org

Marcus
Gama

    marcus_gama@uol.com.br

Tradução
2001
Alexander Neundorf
2001-07-07
0.01.00

O &lisa; pretende oferecer uma espécie de vizinhança na rede, mas baseando-se apenas na pilha de protocolos do TCP/IP, sem precisar do SMB ou algo do gênero.

Este é o manual para o Servidor de Informações da LAN (LAN Information Server - &lisa;) e também para o Servidor Restrito de Informações da LAN (Restricted LAN Information Server - &reslisa;)

KDE
kdenetwork
LAN
rede
vizinhança de rede

## Introdução

O &lisa; pretende fornecer uma espécie de vizinhança da rede, mas confiando apenas na pilha de protocolos do TCP/IP, sem usar SMB ou algo do gênero.

É completamente independente do &kde;/&Qt;.

A lista das máquinas em funcionamento é fornecida através da porta 7741 do TCP.

O &lisa; suporta duas formas de procurar máquinas:

1. Você indica ao &lisa; um intervalo de endereços IP, e o &lisa; irá então enviar pedidos de eco de ICMP para todos os endereços IP fornecidos, ficando à espera das respostas.

2. Você pode indicar ao &lisa; para executar o `nmblookup` `"*`. A ferramenta da linha de comando `nmblookup` precisa estar instalada do pacote do Samba. O `nmblookup` `"*"` envia um pedido por difusão para as redes associadas e todas as máquinas que estejam executando serviços de SMB irão atender a essa difusão.

## Como funciona

No arquivo de configuração você indica um intervalo de endereços IP que o &lisa; irá verificar para ver se eles estão funcionando.

No caso mais simples, isto poderá ser o seu endereço da rede/máscara da sub-rede, onde então o &lisa; irá verificar todas as máquinas possíveis da sua rede para ver se estão funcionando.

As máquinas são verificadas usando os pedidos de eco do ICMP. Para ser capaz de enviar e receber pedidos e respostas de ecos do ICMP, o programa tem que criar um dispositivo denominado de raw socket (canal bruto). Por essa razão, ele necessita de privilégios do root. Este soquete é criado logo após o início do programa, e depois de ter conseguido criar esse canal, os privilégios do root são logo abandonados (veja o `main.cpp` e o `strictmain.cpp`).

Se você configurar o &lisa; de modo a que ele use também o `nmblookup`, ele irá fazer `popen("nmblookup \"*\"")` e depois irá então processar o resultado.

Uma vez que os pedidos de ICMP e as difusões poderão causar algum tráfego de rede, se existir mais de um servidor funcionando, os servidores cooperam entre si. Antes deles começarem a enviar os pedidos, eles enviam uma difusão para a porta 7741.

Se alguém responder a esse pedido, as máquinas irão obter a lista completa de máquinas em funcionamento, através da porta 7741 de TCP, dessa máquina e não irão enviar os pedidos de ICMP (ou do `nmblookup`).

Se ninguém responder, a máquina que enviou a difusão irá começar a enviar pedidos às máquinas e irá então abrir um soquete que atende as referidas difusões. Se a máquina recebeu uma resposta à sua difusão, ela não terá o soquete aberto para atender as difusões. Por isso, normalmente só um dos servidores terá o seu canal aberto e só esse é que irá efetuar os pedidos às máquinas.

Em outras palavras, os servidores são preguiçosos, ou seja, funcionam do tipo Só farei algo se não existir ninguém que o faça por mim.

Existe também outra funcionalidade que reduz a carga da rede.

Digamos que você configurou o &lisa; para se atualizar a cada 10 minutos. Imagine que você não acessar ao seu servidor muitas vezes. Se ninguém acessar o servidor durante o último período de atualização, o servidor irá atualizar-se (por iniciativa própria ou de alguém que faça essa tarefa) e irá duplicar o seu período de atualização, &ie; a próxima atualização só irá ocorrer ao fim de 20 minutos.

Isto irá acontecer 4 vezes, assim se ninguém acessar o servidor com um intervalo de atualização de 10 minutos durante bastante tempo, o seu intervalo de atualização irá aumentar até 160 minutos, o que corresponde a quase 3 horas. Se alguém acessar então aos dados do servidor, ele irá obter uma lista antiga (com até 160 minutos de idade). Ao acessar o servidor, ele irá restaurar o seu intervalo de atualização no seu valor inicial, &ie; 10 minutos e irá iniciar automaticamente a atualizar se a última atualização ocorreu há mais do que esses 10 minutos. Isto significa que, se obtiver uma lista muito antiga, você poderá tentar alguns segundos depois de novo e já deverá obter uma versão atualizada.

Isto terá um efeito rápido para os servidores, que não enviam pedidos a si próprios, uma vez que só um usuário é que os acessa normalmente, e terá menos efeito para o servidor que efetua os pedidos, uma vez que esse servidor é acessado a partir de todos os outros servidores da rede.

Desta forma é possível que várias máquinas de uma rede rodem este servidor, mas a carga da rede irá permanecer baixa. Para o usuário, não é necessário saber se existe um servidor (&ie; um servidor de nomes, de arquivos ou do que for) na rede que esteja rodando também o &lisa;. Ele poderá sempre rodar o &lisa; localmente e o &lisa; irá detectar se existe algum, de forma transparente para o usuário.

O primeiro cliente para o &lisa; é um 'IO slave' para o &kde; 2, de modo que o usuário possa inserir aqui `lan://localhost/` ou `lan:/`, sendo que ambas as formas irão contactar o &lisa; para o próprio sistema.

Se existir uma máquina que esteja ligada o tempo inteiro e o usuário saiba que esta máquina também roda o &lisa;, ele poderá usar o seu cliente do &lisa; diretamente com este servidor (que será referenciado no 'IO slave' mencionado como `lan://nome_do_servidor/`).

Se você não quiser que o seu &lisa; faça parte da difusão, mas que efetue sempre a emissão de pedidos, faça-o usar outra porta com a opção da linha de comando `--port` ou `-p`. Isto não é recomendado!

Se você enviar um `SIGHUP` ao &lisa;, ele irá reler o seu arquivo de configuração. Se você enviar um `SIGUSR1` para o &lisa;, ele irá imprimir algumas informações de estado para a saída padrão.

Os dados fornecidos no canal têm um formato simples: `<endereço IP em decimal com ordem de bytes da rede><um espaço 0x20><nome completo da máquina><um '\0' de finalização><mudança de linha '\n'<` e a última linha irá indicar `0 succeeded<'\n'>`

Por exemplo,

    17302538 uma_maquina.aqui.pt
    18285834 linux.aqui.pt
    17827082 servidor_nomes.aqui.pt
    0 succeeded

Isto deverá tornar o processamento simples.

Se existirem regras de segurança muito restritas na sua rede, poderão existir algumas pessoas que achem a emissão dos pedidos um ataque potencial. Se você tiver problemas com isto, tente a versão restrita, o &reslisa;.

## &reslisa;

Se você tiver regras de segurança muito restritas na sua rede ou se não quiser ter outra porta aberta ou mesmo por outra razão qualquer, você poderá usar o &reslisa;.

Com o &reslisa; você não poderá enviar pedidos para redes inteiras ou para intervalos de endereços; só poderá indicar atualmente ao &reslisa; até 64 máquinas com os seus nomes no seu arquivo de configuração. Só estas receberão pedidos. Você poderá ainda usar o `nmblookup`.

O &reslisa; também só irá fornecer as informações das máquinas através de um soquete do domínio do UNIX, &ie; não o fará na rede. O nome do soquete é `/tmp/resLisa-OSeuUsuario`, de modo que o &reslisa; possa ser executado em segurança por vários usuários na mesma máquina.

Uma vez que não irá produzir nenhum risco de segurança de qualquer espécie, é seguro instalar o &reslisa; com 'setuid' para root. Os privilégios do root serão descartados logo após o início (veja em `strictmain.cpp`), e só serão necessários para criar um canal bruto para enviar os pedidos de eco do ICMP.

Também não irá enviar ou receber difusões. O primeiro cliente para isto é também um 'IO slave' para o &kde; 2 (`rlan:/` no &konqueror;, por exemplo).

## O Arquivo de Configuração

Agora, veremos um exemplo de arquivo de configuração:

    PingAddresses = 192.168.100.0/255.255.255.0;192.168.100.10-192.168.199.19;192.168.200.1;192-192.168-168.100-199.0-9;
    PingNames = bb_mail;
    AllowedAddresses = 192.168.0.0/255.255.0.0
    BroadcastNetwork = 192.168.100.0/255.255.255.0
    SearchUsingNmblookup = 1                #tentar também o 'nmblookup'
    FirstWait = 30                          #30 centésimos de segundo
    SecondWait = -1                         #só uma tentativa
    #SecondWait = 60                         #tentar duas vezes, e na segunda esperar 0,6 segundos
    UpdatePeriod = 300                      #atualizar ao fim de 300 segundos
    DeliverUnnamedHosts = 0                 #não publicar as máquinas sem nome
    MaxPingsAtOnce = 256                    #enviar até 256 pedidos de eco de ICMP de cada vez

### `PingAddresses`

Este é provavelmente o item mais importante.

Aqui você indica quais os endereços que irão receber pedidos. Você poderá indicar vários intervalos, separados por ponto e vírgula (;).

Existem quatro formas possíveis de definir endereços:

endereço de rede/máscara da rede

  192.168.100.0/255.255.255.0, &ie; um endereço IP e a máscara de rede atribuída.

  Isto não tem que ser o endereço de rede nem a máscara da sua máquina. Por exemplo, se você tiver o 10.0.0.0/255.0.0.0 como o seu próprio endereço, você poderá indicar 10.1.2.0/255.255.255.0 se só estiver interessado nestes endereços. A combinação do endereço IP-máscara de rede terão de estar divididos por uma barra / e o endereço não tem que ser um endereço de rede real; poderá ser também o endereço de uma máquina da rede desejada, &ie; o 10.12.34.67/255.0.0.0 é o mesmo que 10.0.0.0/255.0.0.0 .

um intervalo de endereços IP

  Por exemplo: 192.168.100.10-192.168.199.19

  Um endereço IP onde o envio de pedidos irá começar e um endereço IP onde o mesmo envio irá terminar.

  Ambos os endereços deverão estar divididos por um -.

  Neste exemplo irá produzir 199-100+1=100, 100*256=25 600, 25 600+(19-10+1)=25 590 endereços

Um endereço IP, e que se encontra representado por intervalos dos quatro números decimais

  Um endereço IP que pode ser representado pelo seus quatro números em decimal e onde poderá indicar intervalos para cada um desses quatro números: 192-192.169-171.100-199.0-9

  Neste exemplo, todos os endereços IP com o primeiro número igual a 192, com o segundo de 169 a 171, com o terceiro de 100 até 199 e com o último de 0 até 9 irão receber pedidos. Isto irá dar um total de 1*1*100*10=1 000 endereços.

  Isto provavelmente só será útil em muito poucos casos. Aqui você terá que definir os intervalos para todos os quatro números, sempre divididos por -.

Endereços IP simples ou nomes de máquinas

  O endereço IP ou o nome de qualquer máquina em que esteja particularmente interessado.

Também é válido deixar este campo em branco.

### `PingNames`

Aqui você poderá indicar adicionalmente as máquinas a pesquisar, recorrendo aos seus nomes. Estes terão de ser divididos por ponto e vírgula (;).

Também é válido deixar este campo em branco.

### `AllowedAddresses`

Isto também é muito importante. O &lisa; só irá pesquisar os endereços, aceitar os clientes e responder aos endereços cobertos pelos valores desta opção. Você poderá adicionar até 32 endereços de rede/máscaras de rede ou endereços simples. Divida-os por ponto-e-vírgulas (;) e não coloque espaços em branco entre os endereços!

Por exemplo, 192.168.0.0/255.255.0.0;192.169.0.0

Uma rede completa e um endereço simples são igualmente válidos. Torne isto sempre tão restrito quanto possível; normalmente o seu endereço de rede/máscara de sub-rede são uma boa escolha.

### `BroadcastNetwork`

Este item contém exatamente um endereço de rede/máscara de sub-rede. Os pedidos de difusão serão enviados para esta rede. Normalmente, deverá ser o seu endereço de rede/máscara de sub-rede, como por exemplo: 192.168.0.0/255.255.0.0

### `SearchUsingNmblookup`

Aqui você poderá indicar `0` ou `1`. O `1` significa que o &lisa; irá executar o `nmblookup` `"*"` e processar o resultado deste comando. Isto irá produzir menos tráfego de rede que com os pedidos, mas você só irá obter as máquinas que tenham um serviço de SMB rodando (máquinas de &Windows; ou que rodem o Samba).

Se você ativar esta opção e também indicar os endereços IP a contactar, então o `nmblookup` será executado em primeiro lugar e depois o envio de pedidos será iniciado. Aí, só os endereços que não foram já referenciados pelo `nmblookup` serão contactados. Isto deverá reduzir ligeiramente a carga da rede.

### `FirstWait`

Se o &lisa; enviar os pedidos de eco do ICMP, ele envia um conjunto de pedidos de uma vez, e irá esperar durante o período em centésimos de segundo que indicar aqui. Normalmente, os valores de 5 a 50 deverão ser bons, e o máximo é 99 (o que dá 0,99 segundos, um tempo bastante longo). Tente tornar este valor tão baixo quanto possível, desde que consiga encontrar todas as máquinas em funcionamento.

### `SecondWait`

Depois que o &lisa; tiver enviado os pedidos de eco da primeira vez, é ainda possível que algumas das máquinas não tenham sido encontradas. Para melhorar os resultados, o &lisa; poderá enviar os pedidos uma segunda vez. Neste momento, só irá se comunicar com as máquinas das quais não tenha recebido respostas. Se tiver bons resultados ao efetuar os pedidos uma única vez, você poderá desativar o segundo tentativa, configurando para tal o SecondWait para `-1`.

Caso contrário, poderá ser uma boa ideia tornar este valor um pouco mais elevado que o valor do `FirstWait`, uma vez que as máquinas que não foram encontradas na primeira tentativa, poderão ser mais lentas ou estarem ausentes, por isso poderão levar mais uns milisegundos para responder. Normalmente, os valores de 5 a 50 serão os adequados e o -1 poderá ser usado para desativar a segunda pesquisa. O valor máximo é 99 (o que corresponde a 0,99 segundos, o que é bastante tempo).

### `UpdatePeriod`

Este é o intervalo ao fim do qual o &lisa; irá efetuar a atualização. Ao fim desse período o &lisa; irá enviar pedidos novamente ou executar o `nmblookup` para obter uma lista das máquinas do servidor do &lisa; que efetua de fato a emissão dos pedidos.

Os valores válidos situam-se entre 30 e 1800 segundos (meia-hora). Se tiver uma rede grande, não torne o intervalo demasiado pequeno (para manter a carga de rede baixa). Os valores de 300 a 900 segundos (5 a 15 minutos) serão uma boa escolha.

Tenha em mente que o intervalo de atualização é duplicado se ninguém acessar ao servidor, até 4 vezes, por isso o intervalo ficará 16 vezes maior do que o valor indicado aqui e será restaurado ao valor aqui especificado se alguém acessar ao servidor.

### `DeliverUnnamedHosts`

Se for recebida uma resposta a um pedido de eco de um determinado endereço IP, e se o &lisa; não conseguir determinar o nome, este só será apresentado se você configurar este parâmetro como sendo igual a 1.

Não é certo se isto será uma funcionalidade útil, mas poderão existir alguns dispositivos da infra-estrutura da sua rede que não tenham nomes atribuídos, e que por isso não tenham que ser publicados. Ponha este valor igual a 0 se quiser mantê-los secretos ;-). Se não tiver a certeza, insira 0.

### MaxPingsAtOnce

Ao enviar os pedidos de eco, o &lisa; envia-os em conjunto e fica então à espera das respostas. Por padrão, são contactados 256 endereços de uma vez, e você normalmente não terá que alterar este valor. Se torná-lo muito maior, as filas de recepção das respostas aos pedidos de eco poderão tornar-se demasiado pequenas, e se o configurar demasiado baixo, a atualização será mais lenta.

### Mais três arquivos de exemplo

#### CORRIGIR

Você é um membro de uma pequena rede com uma máscara de rede de 24 bits, &ie; até 256 máquinas:

    PingAddresses = 192.168.100.0/255.255.255.0
    AllowedAddresses = 192.168.100.0/255.255.255.0
    BroadcastNetwork = 192.168.100.0/255.255.255.0
    SearchUsingNmblookup = 0                         #não usar o 'nmblookup'
    FirstWait = 20                                   #20 centésimos de segundo
    SecondWait = 30                                  #30 centésimos à 2a tentativa
    UpdatePeriod = 300                               #atualizar ao fim de 300 s
    DeliverUnnamedHosts = 0                          #não publicar as máquinas sem nome

#### O arquivo de configuração só para as máquinas que rodem o SMB

Você só está interessado nas máquinas que estão rodando serviços de SMB e não possui roteadores na sua rede:

    AllowedAddresses = 192.168.100.0/255.255.255.0
    BroadcastNetwork = 192.168.100.0/255.255.255.0
    SearchUsingNmblookup = 1                #usar o nmblookup
    UpdatePeriod = 300                      #atualizar ao fim de 300 segundos
    DeliverUnnamedHosts = 0                 #não publicar as máquinas sem nome

#### Arquivo de configuração que use tanto o `nmblookup` como os pedidos de eco

A mesma rede, só que usando tanto o nmblookup como os pedidos de eco.

    PingAddresses = 192.168.100.0/255.255.255.0
    PingNames = bb_mail
    AllowedAddresses = 192.168.0.0/255.255.0.0
    BroadcastNetwork = 192.168.100.0/255.255.255.0
    SearchUsingNmblookup = 1                #usar também o nmblookup
    FirstWait = 30                          #30 centésimos de segundo
    SecondWait = -1                         #só uma tentativa
    #SecondWait = 60                         #tentar duas vezes e na 2a esperar 0,6 segundos
    UpdatePeriod = 300                      #atualizar ao fim de 300 segundos
    DeliverUnnamedHosts = 0                 #não publicar as máquinas sem nome
    MaxPingsAtOnce = 256                    #enviar até 256 pedidos de eco de ICMP de uma vez

#### O arquivo de configuração do &reslisa;

E agora um arquivo de configuração para o &reslisa;; os PingAddresses não são usados pelo &reslisa;, nem o BroadcastNetwork.

    PingNames = bb_mail;uma_maquina;outra_maquina
    AllowedAddresses = 192.168.0.0/255.255.0.0
    SearchUsingNmblookup = 1                # usar o nmblookup
    FirstWait = 30                          #30 centésimos de segundo
    SecondWait = -1                         #só uma tentativa
    #SecondWait = 60                         #tentar 2 vezes, e na 2a esperar 0,6 segundos
    UpdatePeriod = 300                      #atualizar ao fim de 300 segundos
    DeliverUnnamedHosts = 1                 #também publicar as máquinas sem nome
    MaxPingsAtOnce = 256                    #enviar até 256 pedidos de eco de ICMP de uma vez

## Opções da Linha de Comando e Outros Usos

São suportadas as seguintes opções da linha de comando:

`-v`, `--version`

  Imprime uma breve informação da versão.

`-h`, `--help`

  Dá uma ideia geral das opções da linha de comando

`-u`, `--unix`

  Procura primeiro pelo `$`HOME`/.lisarc`, e depois pelo `/etc/lisarc`. Este é o comportamento padrão.

`-k`, `--kde1`

  Procura primeiro pelo `$`HOME`/.kde/share/config/lisarc`, e depois pelo `$`KDEDIR`/share/config/lisarc`.

`-K`, `--kde2`

  Procura pelo arquivo `lisarc` em todas as pastas, executando para tal o ``kde-config` `--path` `config``

`-c`, `--config=``ARQUIVO`

  Lê o `ARQUIVO` e não lê mais nenhum arquivo de configuração.

`-p`, `--port` `PORTNR`

  Inicia o servidor neste número de porta. Se usar esta opção, o &lisa; não será capaz de cooperar com os outros &lisa;'s da rede. Esta opção não está disponível para o &reslisa;

Se você enviar o sinal de Hangup para o &lisa; ou para o &reslisa;, ele irá reler o seu arquivo de configuração (``killall` `-HUP lisa``).

Se você enviar o sinal User1 para o &lisa; ou para o &reslisa;, ele irá imprimir alguma informação do estado para a saída padrão (``killall` `-USR1 lisa``). Você não verá nada se o console a partir do qual o &lisa;/&reslisa; foi iniciado tiver terminado.

## Créditos e Licenças

&lisa; e &reslisa; direitos autorais 2000, 2001, Alexander Neundorf

Tradução de Marcus Gamamarcus_gama@uol.com.br

Divirta-se, Alexander Neundorf neundorf@kde.org

&underFDL; &underGPL;

## Instalação

O &lisa; e o &reslisa; necessitam da libstdc++ (ela só usa a classe string da mesma), mas não necessita nem do &Qt; nem do &kde;.

&install.compile.documentation;

### Outros Requisitos

Tanto o &reslisa; como o &lisa; acessam a um canal bruto para enviar e receber os pedidos de eco do ICMP. Para fazer isso eles precisam de privilégios do root.

O &lisa; oferece um serviço na porta de TCP 7741, e deverá ser instalado pelo root, sendo iniciado quando o sistema inicializa. Ele depende em grande medida do seu &OS; para conseguir isto.

O &reslisa; pretende-se que seja iniciado por usuário e não oferece nada para a rede. Ele necessita, contudo, de ser instalado setuid para root.

Se você usar o 'IO slave' `rlan` do &kde; 2, o &reslisa; poderá ser iniciado automaticamente.

O &lisa; lê o arquivo `lisarc`, enquanto que o &reslisa; lê o arquivo `reslisarc`. Se você quiser ser capaz de configurar ambos a partir do &kcontrol;, terá de iniciá-los com a opção da linha de comando `-K`.

Para mais informações sobre onde os aplicativos procuram os seus arquivos de configuração leia o capítulo sobre .