O Manual do LISa
Copyright © 2001 Alexander Neundorf
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)
Índice
Lista de Exemplos
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:
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.
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.
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, isto é 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, isto é 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 (isto é 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 succeededIsto 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.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
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, isto é 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).
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
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
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:
192.168.100.0/255.255.255.0, isto é 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, isto é o 10.12.34.67/255.0.0.0 é o mesmo que 10.0.0.0/255.0.0.0 .
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 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 “-”.
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.
PingNamesAqui 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.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
AllowedAddressesIsto 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.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
BroadcastNetworkEste 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
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
SearchUsingNmblookupAqui 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.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
FirstWaitSe 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.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
SecondWaitDepois 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).
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
UpdatePeriodEste é 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.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
DeliverUnnamedHostsSe 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.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
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.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Exemplo 4.1. CORRIGIR
Você é um membro de uma pequena rede com uma máscara de rede de 24 bits, isto é 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
Exemplo 4.2. 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
Exemplo 4.3. 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
Exemplo 4.4. 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
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
São suportadas as seguintes opções da linha de comando:
-v, --versionImprime uma breve informação da versão.
-h, --helpDá uma ideia geral das opções da linha de comando
-u, --unixProcura primeiro pelo $, e depois pelo HOME/.lisarc/etc/lisarc. Este é o comportamento padrão.
-k, --kde1Procura primeiro pelo $, e depois pelo HOME/.kde/share/config/lisarc$.KDEDIR/share/config/lisarc
-K, --kde2Procura pelo arquivo lisarc em todas as pastas, executando para tal o kde-config --path config
-c, --config=ARQUIVOLê o ARQUIVO e não lê mais nenhum arquivo de configuração.
-p, --port PORTNRInicia 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 ). Você não verá nada se o console a partir do qual o LISa/resLISa foi iniciado tiver terminado.-USR1 lisa
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
LISa e resLISa direitos autorais 2000, 2001, Alexander Neundorf
Tradução de Marcus Gama(marcus_gama AT uol.com.br)
Divirta-se, Alexander Neundorf (neundorf AT kde.org)
Esta documentação é licenciada sob os termos da Licença de Documentação Livre GNU.
Este programa é licenciado sob os termos da Licença Pública Geral GNU.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Índice
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.
Para compilar e instalar o LISa sem seu sistema, digite o sequinte no diretório base da distribuição de LISa:
%./configure%make%make install
Uma vez que o LISa usa o autoconf e o automake você não deve ter problemas em compilá-lo. Se você tiver problemas por favor reporte-os às lista de correio do KDE.
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 Sistema Operacional 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 Capítulo 5, Opções da Linha de Comando e Outros Usos.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team