Manuel de LISa
Copyright © 2001 Alexander Neundorf
LISa est destiné è fournir un genre de « voisinage réseau », mais uniquement en utilisant le protocole TCP/IP, sans besoin de SMB ou quoi que se soit d'autre.
C'est le manuel pour le serveur d'Information LAN (LISa) et le serveur restreint d'information LAN (resLISa).
Table des matières
Balayer ces adressesNoms de posteAdresses sûresAdresse de diffusion du réseauEnvoyer des diffusions NETBIOS en utilisant nmblookup pour la rechercheAttendre les réponses après le premier balayageAttendre les réponses après le second balayageIntervalle de rafraîchissementSignaler les hôtes sans nomListe des exemples
LISa est destiné à fournir un genre de « voisinage réseau », mais seulement en utilisant le protocole TCP/IP, aucun samba ou quoi que ce soit d'autre.
Il est complètement indépendant de KDE/Qt™.
La liste des hôtes courants est fournie par l'intermédiaire du port 7741 via TCP.
LISa supporte deux façons de trouver les hôtes :
Vous donnez à LISa un intervalle d'adresses IP, puis LISa enverra des requêtes ICMP à toutes les adresses IP données, et attendra les réponses.
Vous pouvez dire à LISa d'exécuter nmblookup "*. La ligne de commande nmblookup doit être installée à partir de Samba. nmblookup "*" envoie une requête générale à tous les postes du réseau, et tous les hôtes du réseau exécutant les services SMB répondront à ces requêtes.
Dans le fichier de configuration, vous fournissez un intervalle d'adresses IP que LISa contrôlera pour voir si elles sont actives.
Dans le cas le plus simple cela peut être votre adresse réseau/masque réseau, puis LISa contrôlera chaque poste possible de votre réseau pour voir s'il est actif.
Les hôtes sont contrôlés en utilisant des requêtes ICMP. Pour pouvoir envoyer et recevoir des requêtes ICMP le programme doit ouvrir un « raw socket ». Par conséquent il a besoin des privilèges root. Cette socket est ouverte après le début du programme, après avoir ouvert avec succès les sockets ayant les droits root, elles sont relâchées immédiatement (voir main.cpp et strictmain.cpp).
Si vous configurez LISa de sorte qu'il utilise également nmblookup, il ouvrira popen("nmblookup \"*\"") et analysera alors les résultats.
Puisque les requêtes ICMP et les requêtes générales peuvent causer du trafic réseau s'il y a plus d'un poste fonctionnant dans un réseau, les serveurs coopèrent l'un avec l'autre. Avant qu'ils n'envoient des ping (ou nmblookup), ils envoient une requête générale sur le port 7741.
Si quelqu'un répond aux requêtes générales, ils rechercheront la liste complète des postes via TCP sur le port 7741 à partir de cet hôte et ne commenceront pas à envoyer de ping (ou nmblookup).
Si personne ne répond, le poste qui a envoyé des requêtes générales commencera à envoyer des ping (ou nmblookup) et puis ouvrira une socket qui écoutera le retour des requêtes générales mentionnées. Si le poste recevait une réponse à son émission, il n'aura pas la socket pour écouter les requêtes générales. Dans la réalité un des serveurs aura cette socket ouverte et seulement lui pourra envoyer des requêtes ping (ou nmblookup) vers les postes.
En d'autres termes, les serveurs sont paresseux, ils travaillent comme « je ne ferais quelque chose seulement si personne d'autre ne peut le faire pour moi ».
Il y a un autre dispositif qui réduit la charge réseau.
Disons que vous avez configuré LISa pour faire une mise à jour toutes les 10 minutes. Maintenant vous n'accédez pas à votre serveur très souvent. Si personne n'accède au serveur sur la dernière période de mise à jour, le serveur mettra à jour (ou lui-même ou de celui qui effectue réellement le travail) et puis doublera sa période de mise à jour, c'est-à-dire que la prochaine mise à jour se produira après 20 minutes.
Ceci se produira 4 fois, ainsi si personne n'accède au serveur avec la période de mise à jour de 10 minutes, son intervalle de mise à jour augmentera jusqu'à 160 minutes, presque trois heures. Si alors quelqu'un accède aux données du serveur, il obtiendra une vieille liste (jusqu'à 160 minutes d'ancienneté). Avec l'accès le serveur remettra à l'état initial son intervalle de mise à jour à sa valeur initiale, c'est-à-dire 10 minutes et se remettra à jour immédiatement si la dernière mise à jour est terminée depuis plus de 10 minutes. C'est un moyen, si vous obtenez une liste très vieille, d'essayer quelques secondes plus tard et vous devriez obtenir une version en cours.
Ceci aura un effet rapide pour les serveurs, qui n'envoient pas de requêtes ping (ou nmblookup) eux-mêmes, mais seulement depuis un utilisateur qui les accède habituellement, et il aura moins d'effet pour le serveur qui fait les requêtes ping (ou nmblookup), puisque ce serveur est consulté depuis tous les autres serveurs du réseau.
De cette façon il est possible que beaucoup de postes dans un réseau emploient ce serveur, mais la charge réseau demeurera basse. Pour l'utilisateur il n'est pas nécessaire de savoir quel est le serveur (c'est-à-dire un serveur nommé ou un serveur d'archivage ou quoi que ce soit d'autre) dans le réseau qui exécute également le LISa. Il peut toujours exécuter le LISa localement et LISa détectera s'il y en a un, d'une manière transparente pour l'utilisateur.
Le premier client pour le LISa est un module d'entrée-sortie pour KDE 2. ainsi l'utilisateur peut écrire lan://localhost/ ou lan:/, qui tous les deux entreront en contact avec LISa sur son propre système.
S'il y a une machine qui fonctionne en permanence et que l'utilisateur sait que cette machine exécute également LISa, il peut utiliser son client LISa directement avec ce serveur (avec le module d'entrée-sortie mentionné lan://le_nom_du_serveur/).
Si vous ne voulez pas que votre LISa participe aux requêtes générales, mais toujours faire les requêtes de ping elle-même, utiliser un autre port avec l'option sur la ligne de commande --port ou -p. Ceci n'est pas recommandé !
Si vous envoyez SIGHUP à LISa, il relira son fichier de configuration. Si vous envoyez SIGUSR1 à LISa, il affichera certaines informations sur le périphérique stdout.
Les données fournies à travers la socket ont un format simple : <adresse ip décimal dans l'ordre des octets du réseau> <un espace 0x20><nom complet du poste>< un caractère de fin '\0'><nouvelle ligne '\n'< et la dernière ligne 0 succeeded<'\n'>
Par exemple,
17302538 some_host.whatever.de
18285834 linux.whatever.de
17827082 nameserver.whatever.de
0 succeededCela devrait être facilement transformable.
S'il y a une sécurité très stricte dans votre réseau, certains pourrait considérer l'envoi de requête ping comme une attaque potentielle. Si vous avez des problèmes avec ceci, essayez la version restreinte, resLISa.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Si vous des règles très strictes de sécurité dans votre réseau ou que vous ne vouliez pas avoir un autre port ouvert, vous peut utiliser resLISa.
Avec resLISa vous ne pouvez pas envoyer des requêtes de ping sur le réseau entier, vous pouvez donner à resLISa jusqu'à 64 postes par leurs noms dans son fichier de configuration. Ceux-ci seront soumis aux requêtes ping. Vous pouvez encore utiliser nmblookup.
resLISa fournis seulement les informations sur un domaine de socket Unix, c'est-à-dire pas en dehors du réseau. Le nom de socket est /tmp/resLisa-VotreNomLogin donc resLISa, peut être exécuté de manière saine par plus d'utilisateurs sur une même machine.
Puisqu'il ne devrait pas se produire de risque de sécurité d'aucune sorte il est sûr d'installer resLISa setuid root. Les privilèges root seront relâchés après la mise en route (voir strictmain.cpp), ils sont seulement nécessaires pour créer une raw socket pour envoyer les requêtes ICMP.
Il n'enverra pas ou ne recevra pas de requêtes générales. Le premier client pour ceci est un module d'entrée-sortie pour le KDE 2 (rlan:/ dans Konqueror par exemple).
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Maintenant un exemple de fichier de configuration :
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 #essaye nmblookup FirstWait = 30 #30 secondes SecondWait = -1 #seulement un essais #SecondWait = 60 #essaye de nouveau et le nouvel essais dans 0,6s UpdatePeriod = 300 #mise à jour après 300 secs DeliverUnnamedHosts = 0 #Ne pas afficher les postes sans nom MaxPingsAtOnce = 256 #Envoie d'abord 256 requêtes ICMP
C'est probablement la saisie la plus importante.
Ici vous dites quelles adresses seront testées. Vous pouvez indiquer des intervalles multiples, elles sont divisées par des points-virgules.
Il y a quatre possibilités pour définir des adresses :
192.168.100.0/255.255.255.0, c'est-à-dire une adresse IP et son masque réseau.
Ceci ne doit pas être l'adresse réseau et le masque réseau de votre machine. Par exemple, si vous avez 10.0.0.0/255.0.0.0 pour votre propre adresse, vous pouvez indiquer 10.1.2.0/255.255.255.0 si vous êtes seulement intéressé par ces adresses. Le masque d'adresse réseau IP doit être divisé par une barre de fraction « / » et l'adresse ne doit pas être une vraie adresse de réseau, elle peut également être une adresse de poste du réseau désiré, c'est-à-dire 10.12.34.67/255.0.0.0 est identiques à 10.0.0.0/255.0.0.0.
Par exemple : 192.168.100.10-192.168.199.19
Une adresse IP qui est testée démarre et une adresse IP qui est testées s'arrête.
Les adresses doivent être séparées par un « - ».
Dans cet exemple, cela génère 199-100+1=100, 100*256=25.600, 25.600+(19-10+1)=25.590 adresses
Une adresse IP peut être représentée par ses 4 chiffres décimaux, et vous pouvez spécifier un interval pour chacun d'eux : 192-192.169-171.100-199.0-9
Dans cet exemple toutes les adresses IP avec comme premier chiffre 192, comme second chiffre de 168 à 168, troisième chiffre de 100 à 199 et le dernier de 0 à 9 sont testées. Cela donne 1*1*100*10=1000 adresses.
C'est probablement utile seulement dans des cas très rares. Vous devez fournir des intervalles pour chacun des quatre nombres, toujours séparés par « - ».
Les adresses IP ou les noms de poste de toutes les machines qui vous intéresse particulièrement.
Il est également possible de laisser cette entrée vide.
Noms de posteIci vous pouvez ajouter des postes spécifiques pour les pinger en utilisant leurs noms. Les noms sont séparés par des points-virgules.
Il est également possible de laisser cette entrée vide.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Adresses sûresC'est également très important. LISa envoie seulement des ping, accepte les clients et répond aux requêtes générales à partir des adresses qui sont couvertes par les adresses données dans cette ligne. Vous pouvez ajouter jusqu'à 32 adresse réseau/masque réseau ou choisir des adresses simples. Séparez-les par ; et ne mettez pas d'espace vide entre les adresses !
Par exemple, 192.168.0.0/255.255.0.0;192.169.0.0
Un réseau complet et une adresse unique sont valables. Essayer toujours d'être aussi strict que possible, habituellement votre adresse réseau/masque réseau est un bon choix.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Adresse de diffusion du réseauCette entrée contient exactement une adresse réseau/masque réseau. Les requêtes générales sont envoyés sur ce réseau. Habituellement, il faut mettre votre adresse réseau/masque réseau, par exemple : 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
Envoyer des diffusions NETBIOS en utilisant nmblookup pour la rechercheVous pouvez donner 0 ou 1. 1 signifie que LISa exécutera nmblookup "*" et analysera la sortie de cette commande. Ceci produit moins de trafic de réseau que le ping, mais vous obtiendrez seulement les postes qui fonctionnent avec le service SMB (machines Windows® ou machines exécutant Samba).
Si vous permettez cette option et donnez également des adresses IP aux requêtes ping, alors nmblookup sera d'abord exécuté puis les requêtes ping commenceront. Alors seulement les adresses seront soumises aux requêtes ping, qui n'ont pas été déjà faits par nmblookup. Ceci devrait légèrement diminuer la charge réseau.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Attendre les réponses après le premier balayageSi LISa envoie des requêtes ping, c'est-à-dire s'il envoie les requêtes ICMP , il envoie un groupe de requêtes immédiatement, et il attendra le nombre de centièmes de secondes que vous indiquez ici. Habituellement les valeurs de 5 à 50 devraient être bonnes, le maximum est 99 (donne 0.99 seconde, un temps très long). Essayez de rendre cette valeur aussi petite que possible tout en trouvant toujours tous les postes en fonctionnement.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Attendre les réponses après le second balayageAprès que LISa est envoyé les demandes d'écho la première fois, il peut être possible que quelques postes n'aient pas été trouvés. Pour améliorer les résultats, LISa peut envoyer des requêtes ping une deuxième fois. Cette fois elle enverra des requêtes ping uniquement aux postes dont elle n'a pas reçu de réponse. Si vous avez de bons résultats avec les requêtes ping en seulement une fois, vous pouvez invalider la deuxième fois avec Attendre les réponses après le second balayage à -1.
Autrement ce pourrait être une bonne idée de rendre cette valeur un peu plus grande que la valeur pour Première attente, puisque les postes qui n'ont pas été trouvés sur le premier essai sont probablement plus lents ou autre ainsi ils pourraient prendre quelques millisecondes de plus pour la réponse. Habituellement les valeurs de 5 à 50 devraient être bonnes ou -1 pour invalider le deuxième balayage. Le maximum est 99 (donne 0.99 seconde, un temps très long).
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Intervalle de rafraîchissementC'est un interval après lequel LISa se mettra à jour. Après ce temps LISa enverra de nouveau des requêtes ping ou nmblookup ou récupérera la liste des postes depuis le serveur LISa qui fait actuellement les pings.
Les valeurs valables se situent entre 30 secondes et 1800 secondes (une demi-heure). Si vous avez un grand réseau, ne rendez pas l'intervalle trop petit (pour maintenir la charge du réseau faible). Les valeurs de 300 à 900 secondes (5 à 15 minutes) pourraient être une bonne idée.
Maintenez à l'esprit que la période de mise à jour est doublée si personne n'accède au serveur, ceci jusqu'à 4 fois, ainsi l'intervalle deviendra 16 fois la valeur indiquée ici et sera remise à la valeur indiquée ici si quelqu'un accède au serveur.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Signaler les hôtes sans nomSi une réponse à une demande d'écho d'une adresse IP est reçue, où LISa ne pourrait pas déterminer un nom, elle sera seulement transmis au port si vous placez ceci à 1.
Je ne suis pas vraiment sûr si c'est un dispositif utile, mais peut-être y a t-il quelques dispositifs d'infrastructure dans votre réseau sans noms assignés, ainsi ils ne doivent pas être édités. Placez ceci à 0 si vous voulez les maintenir secrets ! Si vous ne savez pas, placer la valeur 0.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Lors de l'envoi des pings (requête d'écho), LISa envois un paquet de ces requêtes et attend les réponses. Par défaut, il y a 256 pings envoyés en même temps, normalement vous n'avez pas à modifier cette valeur. Si vous mettez une valeur plus grande, le tampon de réception pour les réponses des requêtes deviendra plus petit, s'il devient plus petit, la mise à jour sera moins rapide.
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
Exemple 4.1. FIXE
Vous êtes membre d'un petit réseau avec 24 bits en masque réseau, c'est-à-dire jusqu'à 256 postes :
Balayer ces adresses = 192.168.100.0/255.255.255.0 Adresses sûres = 192.168.100.0/255.255.255.0 Adresse de diffusion du réseau = 192.168.100.0/255.255.255.0 Envoyer des diffusions NETBIOS en utilisant nmblookup pour la recherche = 0 #n'utilise pas nmblookup Attendre les réponses après le premier balayage = 20 #20 centième de seconde Attendre les réponse après le second balayage = 30 #30 centième de seconde sur le second essais Intervalle de rafraîchissement = 300 #mise à jour après 300 secs Signaler les hôtes sans nom = 0 #ne pas afficher les hôtes sans nom
Exemple 4.2. Fichier de configuration pour les hôtes n'utilisant que SMB.
Vous n'êtes intéressé que par les hôtes fonctionnant avec le service SMB et vous n'avez pas de routeur dans votre réseau :
Adresses sûres = 192.168.100.0/255.255.255.0 Adresse de diffusion du réseau = 192.168.100.0/255.255.255.0 Envoyer des diffusions NETBIOS en utilisant nmblookup pour la recherche = 1 #utilise nmblookup Intervalle de rafraîchissement = 300 #mise à jour après 300 secs Signaler les hôtes sans nom = 0 #ne pas afficher les hôtes sans nom
Exemple 4.3. Fichier de configuration utilisant à la fois nmblookup et le ping.
Le même réseau, mais nmblookup et le ping sont utilisés en même temps.
Balayer ces adresses = 192.168.100.0/255.255.255.0 Vérifier en plus les hôtes suivant = bb_mail Adresses sûres = 192.168.100.0/255.255.255.0 Adresse de diffusion du réseau = 192.168.100.0/255.255.255.0 Envoyer des diffusions NETBIOS en utilisant nmblookup pour la recherche = 1 #utilise nmblookup Attendre les réponses après le premier balayage = 20 #20 centième de seconde Attendre les réponse après le second balayage = -1 #ne fait qu'un essais Intervalle de rafraîchissement = 300 #mise à jour après 300 secs Signaler les hôtes sans nom = 0 #ne pas afficher les hôtes sans nom Envoyer des pings maintenant = 256 # envois 256 écho ICMP à la fois
Exemple 4.4. Fichier de configuration pour resLISa
Et maintenant un fichier de configuration pour resLISa, les adresses de diffusion ne sont pas utilisées par resLISa.
Balayer ces adresses = bb_mail;un_hote;un_autre_hote Adresses sûres = 192.168.100.0/255.255.0.0 Envoyer des diffusions NETBIOS en utilisant nmblookup pour la recherche = 1 #utilise nmblookup Attendre les réponses après le premier balayage = 20 #20 centième de seconde Attendre les réponse après le second balayage = -1 #ne fait qu'un essais Intervalle de rafraîchissement = 300 #mise à jour après 300 secs Signaler les hôtes sans nom = 1 # afficher les hôtes sans nom Envoyer des pings maintenant = 256 # envois 256 écho ICMP à la fois
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
Les options suivantes sur la commande en ligne sont supportées :
-v,--versionAffiche quelques informations sur la version.
-h, --helpDonne un aperçu des options sur la commande en ligne
-u, --unixRecherche d'abord le fichier $, puis le fichier HOME/.lisarc/etc/lisarc. C'est la valeur par défaut.
-k, --kde1Recherche d'abord le fichier $, puis le fichier HOME/.kde/share/config/lisarc$.KDEDIR/share/config/lisarc
-K, --kde2Recherche le fichier lisarc dans tous les dossiers retournés en exécutant kde-config --path config
-c, --config=FICHIERLit le fichier FICHIER et aucun autre fichier de configuration.
-p, --port PORTNRDémarre le serveur sur ce numéro de port. Si vous utilisez cela, LISa ne pourra pas coopérer avec d'autres LISa sur le réseau. Cette option n'est pas valable pour resLISa.
Si vous envoyer un signal Hangup à LISa ou à resLISa, ils relieront leur fichier de configuration (killall ).-HUP lisa
Si vous envoyez un signal User1 à LISa ou à resLISa, ils afficheront quelques informations sur la sortie standart ( killall ). Vous ne verrez rien si la console à partir de laquelle LISa/resLISa a été lancé est fermée.-USR1 lisa
Would you like to make a comment or contribute an update to this page?
Send feedback to the KDE Docs Team
LISa and resLISa copyright 2000, 2001, Alexander Neundorf
Traduction française par Jean-Jacques Freulon (jeanjacques.freulon AT free.fr).
Prenez du plaisir, Alexander Neundorf (neundorf AT kde.org)
Cette documentation est soumise aux termes de la Licence de Documentation Libre GNU (GNU Free Documentation License).
Ce programme est soumis aux termes de la Licence Générale Publique GNU (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
Table des matières
LISa et resLISa ont besoins de libstdc++ ( ils utilisent uniquement la classe string ), ils n'ont pas besoin ni de Qt™ ni de KDE.
Pour compiler et installer LISa sur votre système, saisissez les lignes suivantes dans le dossier de base de la distribution de LISa :
%./configure%make%make install
Étant donné que LISa utilise autoconf et automake, vous ne devriez pas rencontrer de problèmes pour le compiler. Si c'est le cas, veuillez les signaler aux listes de discussions de KDE.
resLISa et LISa sont amenés à ouvrir une « raw socket » pour envoyer et recevoir les requêtes ICMP (pings). Pour cela, ils doivent avoir les privilèges root.
LISa offre un service sur le port TCP 7741, et doit être installé par root et démarré lorsque le système démarre. Cela dépend trop de votre système d'exploitation pour vous expliquez comment faire cela.
resLISa est démarré quant à lui par l'utilisateur, il n'offre aucun service réseau. Il doit être installé avec un setuid root.
Si vous utilisez le module d'entrée-sortie rlan depuis KDE 2, resLISa démarrera automatiquement.
LISa lit le fichier lisarc, resLISa lit le fichier reslisarc. Si vous souhaitez pouvoir effectuer la configuration depuis Centre de configuration de KDE, vous devez les démarrer en utilisant l'option -K sur la commande en ligne.
Pour plus d'information sur le fait de savoir à quel endroit sont lus les fichiers de configuration, reportez vous au chapitre Chapitre 5, Options de la Commande en Ligne et Autre Usage.
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