Manuale di LISa
Copyright © 2001 Alexander Neundorf
LISa è un programma progettato per fornire una specie di “vicinato di rete” usando solo la pila di protocolli TCP/IP, non è necessario SMB o altro.
Questo manuale copre sia il LAN Information Server (LISa) che il Restricted LAN Information Server (resLISa)
Sommario
Lista degli Esempi
LISa è un programma progettato per fornire una specie di “vicinato di rete” usando solo la pila di protocolli TCP/IP, non SMB o altro.
È completamente indipendente da KDE/Qt™
L'elenco degli host attivi è fornito attraverso la porta TCP 7741.
LISa è dotata di due metodi di ricerca degli host:
Si può fornire a LISa una sequenza di indirizzi IP, in questo caso LISa invierà richieste di eco ICMP a tutti gli indirizzi IP, ed aspetterà le risposte.
Si può dire a LISa di eseguire nmblookup "*". Lo strumento da linea di comando nmblookup del pacchetto Samba deve essere installato. nmblookup "*" invia una richiesta broadcast alle reti a cui siamo collegati, e tutti gli host dotati di servizi SMB risponderanno a questa trasmissione.
Nel file di configurazione si fornisce un elenco di indirizzi IP che LISa deve controllare per vedere se sono attivi.
Nel caso più semplice questo potrebbe essere l'indirizzo di rete/maschera di sottorete della stazione di lavoro. In questo caso, LISa verificherebbe tutti gli host della rete per vedere se è in esecuzione.
La verifica degli host è fatta usando richieste di eco ICMP. Per poter inviare e ricevere le richieste di eco ICMP e le risposte, il programma deve aprire un cosiddetto “socket raw”. Quindi ha bisogno dei privilegi di root. Questo socket è aperto all'inizio dell'esecuzione del programma, e subito dopo l'apertura del socket i privilegi di root sono immediatamente lasciati cadere. (vedi main.cpp e strictmain.cpp).
Se LISa è configurato per usare nmblookup, eseguirà popen("nmblookup \"*\"") e ne valuterà il risultato.
Dal momento che le richieste ICMP e le trasmissioni broadcast possono congestionare la rete se c'è più di un server di questo tipo su una rete, i server cooperano tra di loro. Prima di iniziare i ping (o nmblookup), inviano una richiesta broadcast sulla porta 7741.
Se qualcuno risponde alla richiesta broadcast, ottengono la lista completa degli host attivi attraverso la porta TCP 7741 di chi ha risposto, e non eseguono alcun ping (o onym > 7741 di chi ha risposto, e non eseguono alcun ping (o nmblookup).
Se nessuno risponde, l'host che ha inviato la richiesta broadcast inizerà a fare ping (o nmblookup) sugli host e poi apre un socket in ascolto per la richiesta broadcast menzionata. Se l'host aveva ricevuto risposta alla richiesta, non apre alcun socket per l'ascolto di richieste broadcast. In questo modo, tipicamente, esattamente uno dei server avrà il socket aperto, e solo questo host eseguirà i ping (o nmblookup) per gli altri host.
In altre parole, i server sono pigri, lavorano pensando “Farò qualcosa solo se nessun altro lo può fare al mio posto”.
C'è un'altra funzione che riduce il carico di rete.
Diciamo che hai configurato LISa per un aggiornamento ogni dieci minuti. Ora non accedi molto spesso al server. Se nessuno accede al server per l'intero periodo fra un aggiornamento e l'altro, il server eseguirà un aggiornamento (o direttamente o attraverso quello che fa effettivamente il lavoro) e poi raddoppia il proprio periodo di aggiornamento, cioè il successivo aggiornamento avverrà dopo venti minuti.
Questo avverrà quattro volte, per cui se nessuno accede al server con un periodo di aggiornamento di dieci minuti per molto tempo, l'intervallo di aggiornamento crescerà fino a centosessanta minuti, quasi tre ore. Se a questo punto qualcuno accede ai dati dal server, otterrà una lista vecchia (anche di centosessanta minuti). Accedendo al server si reimposta l'intervallo di aggiornamento al valore iniziale, cioè dieci minuti, e se l'ultimo aggiornamento è più vecchio di dieci minuti, eseguirà un aggiornamento immediatamente. Quindi, se si ottiene una lista molto vecchia, si può riprovare dopo pochi secondi per avere una lista corrente.
Questo avrà un effetto evidente sui server che non fanno ping (o nmblookup) per proprio conto, dal momento che tipicamente un solo utente vi accederà, ed un effetto minore sul server che fa il ping (o nmblookup), visto che questo è interrogato dagli altri server della rete.
In questo modo è possibile che molti host di una rete abbiano questo server attivo, ma che il carico di rete rimanga basso. Per l'utente non è necessario sapere se c'è un server (cioè un nameserver o un server di file o altro) sulla rete che contiene anche LISa, Può sempre attivare LISa in locale e LISa farà il necessario in modo trasparente per l'utente.
Il primo client di LISa è un ioslave di KDE 2, quindi si può accedere alla rete con l'URL lan:://localhost/ o lan:/, che contattano entrambi LISa sulla macchina locale.
Se c'è una macchina sempre accesa e questa ha LISa abilitato, si può usare direttamente il client LISa con il server attivo su questa (cioè con l'ioslave menzionato lan://nome_del_server/).
Volendo evitare che LISa prenda parte alla rete di broadcast, ma faccia la scansione in modo autonomo, si può forzare l'uso di una porta differente con l'opzione da linea di comando --port o -p. L'uso di questa opzione nel caso generale è vivamente sconsigliato!
LISa rilegge il file di configurazione ogni volta che riceve un SIGHUP. Inoltre, stampa su stdout alcune informazioni sul proprio stato.
I dati forniti sul socket hanno un formato molto semplice: <indirizzo ip decimale in network byte order><uno spazio 0x20><nome completo dell'host><uno '\0' di terminazione><a-capo '\n'< e l'ultima linea 0 succeeded<'\n'>
Per esempio,
17302538 un_host.qualcosa.it
18285834 linux.qualcosa.it
17827082 nameserver.qualcosa.it
0 succeededQuesto dovrebbe renderne facile l'elaborazione con strumenti informatici.
Su una rete con politica di sicurezza molto stretta, i ping potrebbero essere considerati un potenziale attacco. Se questo è un problema, prova ad usare resLISa.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Se la rete ha regole di sicurezza molto strette, e non vuoi avere un'ulteriore porta aperta, puoi usare resLISa.
Con resLISa non si possono eseguire ping a reti o sequenze di indirizzi, si può solo passare a resLISa fino a sessantaquattro host per nome nel file di configurazione. Questi riceveranno il ping. Si può ancora usare nmblookup.
resLISa fornisce l'informazione solo su un socket di dominio unix, cioè non sulla rete. Il nome del socket è /tmp/resLisa-TuoLoginName, in modo che resLISa possa essere lanciato da più utenti della macchina contemporaneamente.
resLISa può essere installato setuid root, visto che non dovrebbe porre rischi di alcun tipo per la sicurezza. I privilegi diroot vengono lasciati cadere subito dopo la partenza (vedi strictmain.cpp), e sono usati solo per creare il socket raw usato per inviare le richieste ICMP.
Inoltre, non invia o riceve richieste broadcast. Il suo primo client è anche un ioslave di KDE 2 (rlan:/ in Konqueror per esempio.)
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Ecco un esempio di file di configurazione:
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 #also try nmblookup FirstWait = 30 #30 hundredth seconds SecondWait = -1 #only one try #SecondWait = 60 #try twice, and the second time wait 0.6 seconds UpdatePeriod = 300 #update after 300 secs DeliverUnnamedHosts = 0 #don't publish hosts without name MaxPingsAtOnce = 256 #send up to 256 ICMP echo requests at once
Questa è probabilmente la voce più importante.
Qui vanno inseriti gli indirizzi a cui fare ping. Si possono specificare più sequenze di indirizzi, separati da punto e virgola.
Ci sono quattro modi per definire gli indirizzi:
192.168.100.0/255.255.255.0, cioè un indirizzo IP con la maschera di rete assegnata.
Questo non deve essere necessariamente l'indirizzo e la maschera di rete della tua macchina. Per esempio, se la tua rete è 10.0.0.0/255.0.0.0, puoi specificare 10.1.2.0/255.255.255.0 se ti interessano solo questi indirizzi. La combinazione indirizzo IP-maschera di rete deve essere separata da una barra “/” e l'indirizzo non deve essere un vero indirizzo di rete, può anche essere l'indirizzo di un host della rete desiderata, cioè 10.12.34.67/255.0.0.0 equivale a 10.0.0.0/255.0.0.0 .
Per esempio: 192.168.100.10-192.168.199.19
Un indirizzo IP da cui cominciare il ping ed un indirizzo IP dove terminare il ping.
Entrambi gli indirizzi devono essere separati da “-”
In questo esempio questo produrrebbe 199-100+1=100, 100*256=25.600, 25.600+(19-10+1)=25.590 indirizzi
un indirizzo IP può essere rappresentato con quattro numeri decimali, e si possono specificare sequenze per ciascuno dei quattro numeri: 192-192.169-171.100-199.0-9
In questo esempio tutti gli indirizzi IP il cui primo ottetto è 192, il secondo 168, il terzo da 100 a 199 e l'ultimo da 0 a 9 riceveranno un ping, per un totale di 1*1*100*10=1000 indirizzi.
Questo è probabilmente utile molto raramente. Si possono fornire sequenze per ciascuno dei quatto numeri, sempre divise da “-”.
L'indirizzo IP o l'hostname di una macchina specifica.
Si può anche lasciare il campo vuoto.
PingNamesQui si possono specificare gli host a cui fare ping usando il loro nome. I nomi devono essere divisi da punti e virgola.
Si può anche lasciare il campo vuoto.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
AllowedAddressesAnche questo è molto importante. LISa eseguirà ping agli indirizzi, accetterà client e risponderà a messaggi broadcast solo dagli indirizzi coperti dalla serie di indirizzi inserita in questa linea. Si possono inserire fino a 32 indirizzi di rete/maschere di rete od indirizzi singoli. Questi vanno separati con ';' e non vanno lasciati spazi tra uno e l'altro.
Per esempio, 192.168.0.0/255.255.0.0;192.169.0.0
Una rete intera ed un singolo indirizzo sono validi. Cerca sempre di essere il più preciso possibile. Solitamente, l'uso del tuo indirizzo di rete/maschera di sottorete è una buona scelta.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
BroadcastNetworkQuesta voce contiene esattamente una coppia indirizzo di rete/maschera di sottorete. Di solito va bene quella della rete locale, per esempio: 192.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
SearchUsingNmblookupQui si può inserire 0 o 1. 1 indica che LISa eseguirà nmblookup "*" ed analizzerà l'outout del comando. Questo produce meno traffico di rete rispetto all'uso di ping, ma verranno riconosciute solo le macchine con il servizio SMB attivo (cioè macchine Windows® o macchine con samba attivo).
Abilitando questa opzione e fornendo anche un indirizzo IP a cui fare ping, verrà prima eseguito nmblookup ed in seguito il ping. In questo modo verranno scanditi con ping solo gli indirizzi che non hanno reagito alla richiesta nmblookup. Questo dovrebbe alleggerire un poco il carico di rete.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
FirstWaitSe LISa esegue un ping, cioè invia richieste di eco ICMP, ne manda un gruppo di seguito, e poi aspetta per il numero di centesimi di secondo specificato qui. Di solito valori compresi tra 5 e 50 vanno bene, il massimo è 99 (0.99 secondi, un tempo molto lungo). Prova a rendere questo valore il più piccolo che permetta di trovare ancora tutti gli host attivi.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
SecondWaitDopo che LISa ha inviato le richieste di eco la prima volta, può darsi che alcuni host non vengano trovati. Per migliorare i risultati, LISa può eseguire un ping per un'altra volta. Questa volta verranno scanditi solo gli host da cui non si è ricevuta risposta. Se ottieni buoni risultati con un solo ping, puoi disabilitare la seconda scansione impostando SecondWait a -1
Altrimenti può essere una buona idea aumentare questo valore rispetto a quello di FirstWait, visto che gli host che non sono stati trovati al primo tentativo sono probabilmente più lenti o più lontani, e quindi possono aver bisogno di qualche millisecondo in più per rispondere. Valori fra 5 e 50 sono adeguati; il massimo è 99, e -1 disabilita la seconda scansione.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
UpdatePeriodQuesto è l'intervallo di tempo dopo il quale LISa si aggiornerà. Trascorso questo lasso di tempo, LISa farà di nuovo ping o nmblookup, o richiederà nuovamente la lista di host dal server LISa.
I valori validi vanno da 30 a 1800 secondi (cioè mezz'ora). Su una rete molto grande, l'intervallo non deve essere troppo basso (per tenere basso il carico di rete). Valori compresi tra 300 e 900 secondi (da 5 a 15 minuti) vanno bene.
Ricorda che il periodo di aggiornamento è raddoppiato se nessuno accede al sever fino a quattro volte, quindi l'intervallo diventerà sedici volte più lungo di quello qui specificato se nessuno accede al server.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
DeliverUnnamedHostsSe viene ricevuta la risposta ad una richiesta di eco da un indirizzo IP di cui LISa non riesce a determinare il nome, questa verrà pubblicata sulla porta solo se questa opzione è impostata ad 1.
Non so se questa è una caratteristica utile, ma forse ci sono dei dispositivi di infrastruttura nella rete senza nomi assegnati, in modo che non debbano essere pubblicati. Se vuoi tenerli segreti :-), imposta questo valore a zero. In caso di dubbio, inserisci 0
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Quando fa una scansione, LISa invia un gruppo di richieste di eco ed aspetta una risposta. Normalmente sono eseguiti 256 ping di seguito, e di solito non è necessario cambiare questo valore. Aumentandolo troppo, i buffer di ricezione delle richieste di eco diventano troppo piccoli, e quindi l'aggiornamento rallenta.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Esempio 4.1. FIXME
Fai parte di una piccola rete con una maschera di rete di ventiquattro bit, cioè fino a duecentocinquantasei host:
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 #don't use nmblookup FirstWait = 20 #20 hundredth seconds SecondWait = 30 #30 hundredth seconds on the seconds try UpdatePeriod = 300 #update after 300 secs DeliverUnnamedHosts = 0 #don't publish hosts without name
Esempio 4.2. File di configurazione per i soli host con SMB
Sei interessato solo agli host con i servizi SMB attivi, e non ci sono router sul network:
AllowedAddresses = 192.168.100.0/255.255.255.0 BroadcastNetwork = 192.168.100.0/255.255.255.0 SearchUsingNmblookup = 1 #use nmblookup UpdatePeriod = 300 #update after 300 secs DeliverUnnamedHosts = 0 #don't publish hosts without name
Esempio 4.3. File di configurazione che usa sia nmblookup che il ping
La stessa rete, ma qui è usato sia nbmlookup che ping.
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 #also try nmblookup FirstWait = 30 #30 hundredth seconds SecondWait = -1 #only one try #SecondWait = 60 #try twice, and the second time wait 0.6 seconds UpdatePeriod = 300 #update after 300 secs DeliverUnnamedHosts = 0 #don't publish hosts without name MaxPingsAtOnce = 256 #send up to 256 ICMP echo requests at once
Esempio 4.4. File di configurazione di resLISa
Ecco un file di configurazione per resLISa. PingAddress non è usato da resLISa, e nemmeno BroadcastNetwork.
PingNames = bb_mail;some_host;some_other_host AllowedAddresses = 192.168.0.0/255.255.0.0 SearchUsingNmblookup = 1 # use nmblookup FirstWait = 30 #30 hundredth seconds SecondWait = -1 #only one try #SecondWait = 60 #try twice, and the second time wait 0.6 seconds UpdatePeriod = 300 #update after 300 secs DeliverUnnamedHosts = 1 #also publish hosts without name MaxPingsAtOnce = 256 #send up to 256 ICMP echo requests at once
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
Sono disponibili le seguenti opzioni:
-v, --versionStampa sintetiche informazioni sulla versione del programma.
-h, --helpOffre una panoramica delle opzioni disponibili
-u, --unixCerca prima in $, poi in HOME/.lisarc/etc/lisarc. Questo è il comportamento predefinito.
-k, --kde1Cerca prima nel file $ e poi in HOME/.kde/share/config/lisarc$.KDEDIR/share/config/lisarc
-K, --kde2Cerca il file lisarc in tutte le cartelle restituite dall'esecuzione di kde-config --path config
-c, --config=FILELegge FILE e nessun altro file di configurazione.
-p, --port PORTNRAvvia il server su questo numero di porta. Usando questa opzione, LISa non potrà cooperare con altre sue istanze sulla rete. L'opzione non è disponibile per resLISa
Inviando un segnale Hangup a LISa o resLISa questi rileggeranno i file di configurazione (killall ).-HUP lisa
Inviando un segnale User1 a LISa o resLISa questi stamperanno sul canale di output standard alcune informazioni sul loro stato (killall ). Se la console da cui LISa o resLISa sono stati lanciati è stata chiusa, non si otterrà alcun messaggio.-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
Traduzione di Luciano Montanaro (mikelima AT kde.org).
Have fun, Alexander Neundorf (neundorf AT kde.org)
Questa documentazione è concessa in licenza sotto i termini della GNU Free Documentation License.
Questo programma è concesso in licenza sotto i termini della 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
Sommario
LISa e resLISa richiedono la presenza della libreria libstdc++ (ne usano la classe string), non hanno bisogno né di Qt™ né di KDE.
Per compilare e installare LISa sul tuo sistema, immetti i seguenti comandi nella directory di base della distribuzione di LISa:
%./configure%make%make install
Dato che LISa usa autoconf e automake, non dovresti incontrare dei problemi per compilarlo. Se si verificasse qualche problema, per piacere segnalalo alle mailing list di KDE.
Sia resLISa che LISa aprono un cosiddetto “socket raw” per inviare e ricevere richieste di eco ICMP (ping). Per fare ciò, richiedono privilegi di root.
LISa offre un servizio sulla porta TCP 7741, e dovrebbe essere installato da root ed avviato alla partenza del sistema. Come fare ciò è un fattore pesantemente dipendente dal sistema operativo in uso.
resLISa è progettato per essere avviato dall'utente, e non offre niente alla rete. Deve essere installato setuid root.
Usando il kioslave rlan da KDE 2, resLISa può essere avviato in modo automatico.
LISa legge il file lisarc, resLISa legge reslisarc. volendo configurare i due programmi da KControl, questi vanno avviati con l'opzione -K.
Per maggiori informazioni su dove trovino i file di configurazione, vedi il capitolo su Capitolo 5, Opzioni da linea di comando ed altri utilizzi.
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