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 SMB ou algo do género sendo necessários.
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 do porto 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 indicados, ficando à espera das respostas.
Você pode indicar ao LISa para executar o nmblookup "*. A ferramenta da linha de comandos 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 a correr serviços de SMB irão atender a essa difusão.
No ficheiro de configuração você indica um intervalo de endereços IP que o LISa irá verificar para ver se eles estão a funcionar.
No caso mais simples, este 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 a funcionar.
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 de criar um dispositivo denominado de “raw socket” (canal em bruto). Por essa razão, ele necessita de privilégios do root. Este 'socket' é criado logo a seguir ao início do programa, depois de ter conseguido criar esse canl, 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.
Dado que os pedidos de ICMP e as difusões poderão causar algum tráfego de rede se existir mais do que um servidor a funcionar numa rede, os servidores cooperam entre si. Antes de eles começarem a emitir os pedidos, eles enviam uma difusão para o porto 7741.
Se alguém responder a esse pedido, as máquinas irão obter a lista completa de máquinas em funcionamento, através do porto 7741 de TCP, dessa máquina e não irão começar a emitir os pedidos de ICMP (ou do nmblookup).
Se ninguém responder, a máquina que enviou a difusão irá começar a mandar pedidos às máquinas e irá então abrir um 'socket' que atende as tais difusões. Se a máquina recebeu uma resposta à sua difusão, ela não terá o 'socket' aberto para atender as difusões. Por isso, normalmente só um dos servidores é que terá o seu canal aberto e só esse é que irá efectuar os pedidos às máquinas.
Por 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 actualizar a cada 10 minutos. Agora, o caso em que você não aceder ao seu servidor muitas vezes. Se ninguém aceder ao servidor durante o último período de actualização, o servidor irá actualizar-se (a partir de si próprio ou de alguém que faça essa tarefa) e irá duplicar o seu período de actualização, isto é a próxima actualização só irá ocorrer ao fim de 20 minutos.
Isto irá acontecer 4 vezes por isso, se ninguém aceder ao servidor com um intervalo de actualização de 10 minutos durante bastante tempo, o seu intervalo de actualização irá aumentar até 160 minutos, o que corresponde a quase 3 horas. Se alguém aceder então aos dados do servidor, ele irá obter uma lista antiga (com até 160 minutos de idade). Ao aceder ao servidor, irá repor o seu intervalo de actualização no seu valor inicial, isto é 10 minutos e irá iniciar automaticamente a actualizar se a última actualizaçã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 actualizada.
Isto terá um efeito rápido para os servidores, os quais não enviam pedidos a si próprios, dado que só um utilizador é que acede normalmente a eles, e terá menos efeito para o servidor que efectua os pedidos, dado que esse servidor é acedido a partir de todos os outros servidores da rede.
Desta forma é possível que várias máquinas de uma rede corram este servidor, mas a carga da rede irá permanecer baixa. Para o utilizador, não é necessário saber se existe um servidor (isto é um servidor de nomes, de ficheiros ou do que for) na rede que esteja a correr também o LISa. Ele poderá sempre correr o LISa localmente e o LISa irá detectar se existe algum, de forma transparente para o utilizador.
O primeiro cliente para o LISa é um 'IO slave' para o KDE 2, de modo a que o utilizador possa indicar aqui lan://localhost/ ou lan:/, em que ambas as formas irão contactar o LISa para o próprio sistema.
Se existir uma máquina que corra o tempo inteiro e o utilizador saiba que esta máquina também corre o LISa, ele poderá usar o seu cliente do LISa directamente com este servidor (o qual será referenciado no 'IO slave' indicado como lan://nome_do_servidor/).
Se você não quiser que o seu LISa faça parte da difusão, mas que efectue sempre a emissão de pedidos, faça-o usar outro porto com a opção da linha de comandos --port ou -p. Isto não é recomendado!
Se você enviar um SIGHUP ao LISa, ele irá reler o seu ficheiro de configuração. Se você enviar um SIGUSR1 para o LISa, ele irá imprimir algumas informações de estado para o 'stdout'.
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 outro porto aberto 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 ao resLISa até 64 máquinas de momento com os seus nomes no seu ficheiro de configuração. Só estas é que receberão pedidos. Você poderá à mesma usar o nmblookup.
O resLISa também só irá fornecer as informações das máquinas através de um 'socket' do domínio do UNIX, isto é não o fará na rede. O nome do 'socket' é /tmp/resLisa-OSeuUtilizador, de modo a que o resLISa possa ser executado em segurança por vários utilizadores na mesma máquina.
Dado que não irá produzir nenhum risco de segurança de qualquer espécie, é seguro instalar o resLISa '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 em 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, ver-se-á um exemplo de ficheiro 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 à segunda esperar 0,6 segundos UpdatePeriod = 300 #actualizar 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 de 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 de 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.
Este provavelmente só será útil em muito poucos casos. Aqui você terá de 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 exactamente 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 a correr (máquinas de Windows® ou que corram o Samba).
Se você activar esta opção e também indicar os endereços IP a contactar, então o nmblookup será executado em primeiro lugar e depois é que o envio de pedidos será iniciado. Aí, só os endereços que não foram já referenciados pelo nmblookup é que 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 de o LISa ter enviado os pedidos de eco da primeira vez, é à mesma 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. Nesta altura, só irá comunicar com as máquinas das quais não tenha recebido respostas. Se tiver bons resultados ao efectuar os pedidos uma única vez, você poderá desactivar o segundo tempo, configurando para tal o SecondWait igual a -1.
Caso contrário, poderá ser uma boa ideia tornar este valor um pouco mais elevado que o valor do FirstWait, dado 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 a responder. Normalmente, os valores de 5 a 50 serão os adequados e o -1 poderá ser usado para desactivar 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á efectuar a actualização. Ao fim desse período o LISa irá enviar pedidos de novo ou executar o nmblookup para obter uma lista das máquinas do servidor do LISa que efectua de facto 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 actualização é duplicado se ninguém aceder ao servidor, até 4 tentativas, por isso o intervalo ficará 16 vezes maior do que o valor indicado aqui e será reposto no valor aqui especificado se alguém aceder 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 será 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 de ser publicados. Ponha este valor igual a 0 se os quiser manter secretos ;-). Se não tiver a certeza, indique 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 omissão, são contactados 256 endereços de uma vez, e normalmente não terá de alterar este valor. Se o tornar muito mais elevado, as filas de recepção das respostas aos pedidos de eco poder-se-ão tornar demasiado pequenas, e se o configurar demasiado baixo, a actualizaçã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 #actualizar ao fim de 300 s DeliverUnnamedHosts = 0 #não publicar as máquinas sem nome
Exemplo 4.2. O ficheiro de configuração só para as máquinas que corram o SMB
Você só está interessado nas máquinas que estão a correr serviços de SMB e não tem 'routers' (encaminhadores) 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 #actualizar ao fim de 300 segundos DeliverUnnamedHosts = 0 #não publicar as máquinas sem nome
Exemplo 4.3. O ficheiro 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 à 2a esperar 0,6 segundos UpdatePeriod = 300 #actualizar 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 ficheiro de configuração do resLISa
E agora um ficheiro 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 à 2a esperar 0,6 segundos UpdatePeriod = 300 #actualizar 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 comandos:
-v, --versionImprime uma breve informação da versão.
-h, --helpDá uma ideia geral das opções da linha de comandos
-u, --unixProcura primeiro pelo $, e depois pelo HOME/.lisarc/etc/lisarc. Este é o comportamento por omissão.
-k, --kde1Procura primeiro pelo $, e depois pelo HOME/.kde/share/config/lisarc$.KDEDIR/share/config/lisarc
-K, --kde2Procura pelo ficheiro lisarc em todas as pastas, executando para tal o kde-config --path config
-c, --config=FICHEIROLê o FICHEIRO e não lê mais nenhum ficheiro de configuração.
-p, --port PORTNRInicia o servidor neste número de porto. 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 ficheiro 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 o ecrã (ou o 'standard output') (killall ). Você não verá nada se a consola a partir da 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 copyright 2000, 2001, Alexander Neundorf
Tradução de José Nuno Pires (jncp AT netcabo.pt)
Divirta-se, Alexander Neundorf (neundorf AT kde.org)
A documentação está licenciada ao abrigo da GNU Free Documentation License.
Este programa está licenciado ao abrigo da GNU General Public License.
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 poder compilar e instalar o LISa no seu sistema escreva o seguinte na pasta de base da distribuição do LISa:
%./configure%make%make install
Dado que o LISa usa o autoconf e o automake não deve ter quaisquer problemas a compilá-lo. Se tiver, comunique-os para as listas do KDE.
Tanto o resLISa como o LISa acedem a um “canal em bruto” para enviar e receber os pedidos de eco do ICMP. Para o fazer eles precisam de privilégios do root.
O LISa oferece um serviço no porto de TCP 7741, e deverá ser instalado pelo root, sendo iniciado quando o sistema arranca. Ele depende em grande medida do seu sistema operativo para conseguir isto.
O resLISa pretende-se que seja iniciado por utilizador 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 ficheiro lisarc, enquanto que o resLISa lê o ficheiro reslisarc. Se você quiser ser capaz de configurar ambos a partir do KControl, terá de os iniciar com a opção da linha de comandos -K.
Para mais informações sobre onde as aplicações procuram os seus ficheiros de configuração leia o capítulo sobre Capítulo 5, Opções da Linha de Comandos e Outras Utilizações.
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