LISa"> resLISa"> ]> Alexander Neundorf

neundorf@kde.org

&traducteurJeanJacquesFreulon; 2001 Alexander Neundorf 2001-07-07 0.01.00 &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;). KDE kdenetwork LAN réseau voisinage réseau &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 succeeded Cela 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;. 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). 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 : adresse réseau/masque réseau 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. Un intervalle d'adresses IP 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, représentée par des intervalles de chacune 4 chiffres décimaux. 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 -. Simples adresses IP ou noms de poste. 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. Ici 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. C'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. Cette 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 Vous 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. Si &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. Aprè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). C'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. Si 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. 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. Vous êtes membre d'un petit réseau avec 24 bits en masque réseau, &cad; 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 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 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 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 Les options suivantes sur la commande en ligne sont supportées : -v,--version Affiche quelques informations sur la version. -h, --help Donne un aperçu des options sur la commande en ligne -u, --unix Recherche d'abord le fichier $HOME/.lisarc, puis le fichier /etc/lisarc. C'est la valeur par défaut. -k, --kde1 Recherche d'abord le fichier $HOME/.kde/share/config/lisarc, puis le fichier $KDEDIR/share/config/lisarc . -K, --kde2 Recherche le fichier lisarc dans tous les dossiers retournés en exécutant kde-config --path config -c, --config=FICHIER Lit le fichier FICHIER et aucun autre fichier de configuration. -p, --port PORTNR Dé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 -USR1 lisa). Vous ne verrez rien si la console à partir de laquelle &lisa;/&reslisa; a été lancé est fermée. &lisa; and &reslisa; copyright 2000, 2001, Alexander Neundorf Traduction française par &JeanJacquesFreulon;. Prenez du plaisir, Alexander Neundorf neundorf@kde.org &underFDL; &underGPL; &lisa; et &reslisa; ont besoins de libstdc++ ( ils utilisent uniquement la classe string ), ils n'ont pas besoin ni de &Qt; ni de &kde;. &install.compile.documentation; &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 &SE; 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 ¢reConfiguration;, 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 .