[LinuxFocus-icon]
Sommaire  |  Carte  |  Index  |  Recherche

Nouvelles | Archives | Liens | A propos  
Ce document est disponible en: English  Deutsch  Francais  Nederlands  Portugues  Russian  Turkce  

convert to palmConvert to GutenPalm
or to PalmDoc


par Frédéric Raynal

L´auteur:
Frédéric Raynal prépare une thèse en informatique à l'INRIA. Il aime lire (aussi bien Tolkien que Balzac) et écouter de la musique (de Mozart à Philip Glass et de Led Zeppelin à Massive Attack en passant par Björk et Boris Vian, mais en évitant soigneusement le rap, la techno et quelques autres bruits ;-)
Sommaire:

 

Yellow Pages 2 : Le côté client

Résumé:

L'article précédent était une introduction aux concepts gravitant autour des yellow pages (YPs). Dans celui-ci, nous verrons comment configurer son client, un exemple pratique du fonctionnement du client et une présentation des différents outils qui vont avec. Enfin, nous toucherons quelques mots de NIS+



Introduction

Le côté client des services liés aux yellow pages repose essentiellement sur le démon ypbind : il émet les requêtes vers le serveur des YPs. Nous détaillerons d'abord son fonctionnement et expliquerons comment le configurer. Ensuite, nous verrons également comment fonctionne le protocole NIS. Enfin, la dernière partie de cet article présentera les différents outils présents du côté client des YPs (les yp-tools).

Configurer son client NIS

La seule chose à faire pour faire tourner un client NIS sur une machine est de lancer le démon ypbind.  

ypbind

ypbind établit une liaison entre le client et le serveur NIS (to bind signifie, entre autre, lier ou attacher en Anglais). Ce lien est visible dans le répertoire /var/yp/binding1 au travers du fichier conventionnellement appelé domainname.version. La seule version actuellement supportée est la version 2. Donc, si mon nom de domaine NIS est "messie", le fichier sera messie.2

Le programme ypbind appartient au super-utilisateur (i.e. root), il doit donc se trouver soit dans /sbin, soit dans /usr/sbin.

Quand il est lancé, ypbind va chercher ses instructions dans le fichier /etc/yp.conf. Les entrées de ce fichier sont :

Si ce fichier de configuration est incorrect ou n'existe pas, ypbind broadcast2 sur tout le réseau local à la recherche d'un serveur NIS pour le domaine local.

Quelques opérations élémentaires permettent de vérifier que ypbind est correctement configuré.

  1. créer son fichier /etc/yp.conf ;
  2. vérifier que portmap fonctionne (ps aux | grep portmap). Si ce n'est pas le cas, le lancer. Ce programme associe les ports TCP/IP (ou UDP/IP) de l'ordinateur aux programmes. A l'initialisation d'un serveur RPC, celui-ci signale à portmap les ports qu'il écoute et les numéros de programmes qu'il est susceptible de lancer. Quand un client adresse une requête RPC vers un numéro de programme donné, il contacte d'abord portmap pour connaître le port vers lequel les paquets RPC doivent être expédiés. Comme l'illustre le fonctionnement décrit précédemment, il est donc bien nécessaire que portmap soit initialisé avant ypbind ;
  3. créer le répertoire /var/yp ;
  4. lancer ypbind ;
  5. utiliser la commande rpcinfo pour s'assurer que ypbind fonctionne correctement : soit en fonction de la version de ypbind. Le message important est celui portant sur la version 2.
Maintenant que ypbind fonctionne correctement, votre machine est devenue un client NIS. Vous pouvez donc vous en servir pour adresser des requêtes à votre serveur. Par exemple, "ypcat passwd.byname" renvoie tous les mots de passe, triés par nom d'utilisateur présent dans la map correspondante.  

Derniers détails

Quelques fichiers doivent encore subir de légères modifications pour que les YPs fonctionnent de manière efficace : En ce qui concerne les shadow passwords via NIS, leur support n'est possible qu'avec la glibc2.x. Il faut alors penser à le spécifier dans le fichier nsswitch.conf

Le protocole NIS

Maintenant que notre client NIS est complètement opérationnel, nous allons voir comment il se débrouille pour récupérer les informations dont il a besoin.

Quand un client à besoin d'une information contenue dans une map des YPs, il commence par chercher un serveur YP. Pour le trouver, il ouvre une connexion TCP vers le ypbind local. Le client l'informe du domaine (on parle ici du domaine NIS) auquel il appartient et ypbind broadcast via la fonction RPC YPPROC_DOMAIN_NOACK. Les serveurs NIS qui servent ce domaine répondent avec un ACK, les autres font la sourde oreille.

ypbind renvoie au client le résultat de la recherche (échec ou réussite) et, s'il l'a, l'adresse du premier serveur YP qui a répondu. Le client peut maintenant adresser à ce serveur sa requête, composée du domaine, de la map puis de la clé.

Ce protocole est assez lent car il utilise des connexions TCP. De plus, il emploie également beaucoup de sockets. Pour éviter ceci, ypbind n'attend pas qu'un client le contacte pour trouver les serveurs. En fait, il conserve dans le fichier /var/yp/binding/. une liste de serveur pour chaque domaine et vérifie régulièrement qu'ils fonctionnent correctement.

Les yp-tools

Cette section présente très rapidement quelques outils contenus dans le package yp-tools. Pour en savoir plus, chacune de ces instructions dispose d'une page man très détaillée ;-P

Quelques mots de NIS+

Tout au long de cet article, nous n'avons à aucun moment abordé une variante de NIS, à savoir NIS+. Dans un réseau, NIS pose énormément de problème en terme de sécurité. Par exemple, si le serveur NIS est mal protégé et qu'une personne mal intentionnée découvre :

  1. le nom du domaine NIS
  2. l'adresse IP d'un client NIS
il ne lui reste alors qu'à se faire passer pour la machine avec l'IP du client et envoyer un ypcat passwd pour récupérer tranquillement le fichier des mots de passe :-(

NIS+ offre une couche de sécurité supplémentaire en intégrant un protocole d'authentification fondé sur un échange de clés et supporte le chiffrement des données.

Les données sont conservées dans des tables, elles-mêmes étant dans différents répertoires. Chaque colonne d'une table dispose de qualificatif précisant, par exemple, si les données sont "case sensitive", en format binaire, etc ...

La structure décrite précédemment permet simplement de gérer des droits d'accès sur les répertoires et les tables, mais également sur les colonnes des tables. Ceci implique qu'on peut interdire l'accès à la table des mots de passe à tout utilisateur qui ne s'est pas authentifié auprès du serveur NIS+, mais autoriser tous les utilisateurs certifiés à accéder à toute la table des mots de passes, sauf au champs "passwd". Seul le propriétaire du champs "passwd" pourra le voir.

Il existe 4 niveaux de droits :

  1. Nobody (personne) : l'utilisateur n'est pas authentifié ;
  2. Owner (propriétaire) : l'utilisateur est authentifié et il est le propriétaire ;
  3. Group (groupe ) : l'utilisateur est authentifié et il est dans le groupe pour cet objet ;
  4. World (monde) : l'utilisateur est authentifié mais il n'est ni propriétaire, ni dans le groupe pour cet objet.

Dans cette configuration, root n'est plus qu'un utilisateur comme les autres ... enfin, presque ;-) S'il n'a pas les permissions adéquates, il ne peut plus voir les mots de passe des autres utilisateurs. Il ne pourra donc plus s'authentifier comme un autre utilisateur ... mais, il pourra toujours faire tranquillement un su :)

Les données qui transiteront sur le réseau ne seront pas cryptées, à l'exception des mots de passe : aucun mot de passe ne transite en clair sur le réseau.

NIS+ est un outil puissant ... mais compliqué à mettre en oeuvre. Comme Thorsten Kuduk (il travaille sur NIS, NIS+, NIS-HOWTO ... bref, quelqu'un qui sait de quoi il est question ;-) écrit :
"Le choix entre NIS et NIS+ est facile à faire : utilisez NIS tant que vous n'avez pas des besoins de sécurité important. NIS+ est bien plus problématique à administrer (particulièrement du côté serveur)"

Conclusion

Nous savons maintenant comment insérer une nouvelle machine dans un réseau existant et disposant d'un serveur NIS. Nous verrons, au prochain épisode, comment configurer le serveur ainsi que son fonctionnement.


Footnotes

... var/yp/binding1
Les localisations des fichiers seront rarement précisées car elles varient d'une distribution à l'autre. Par exemple, pour avoir un démon ypbind lancé au démarrage : /etc/init.d/nis, /sbin/init.d/ypclient, /etc/rc.d/init.d/ypbind, /etc/rc.local
... broadcast2
ceci signifie que le message est émis sur tout le sous-réseau sans destinaire précis avec une adresse du type X.Y.0.0
... netgroup3
Le fichier /etc/netgroup défini des groupes composés de triplets (host, user, domain) servant pour vérifier des permissions quand on utilise des commandes "à distance" (remote logins, shells ou mount par exemple). Voir la page man pour plus de détails.

 

Discussion sur cet article

Chaque article possède sa page de discussion. Vous pouvez y soumettre un commentaire ou lire ceux d´autres lecteurs:
 page de discussion 

Site Web maintenu par l´équipe d´édition LinuxFocus
© Frédéric Raynal, FDL
LinuxFocus.org

Cliquez ici pour signaler une erreur ou envoyer un commentaire à Linuxfocus

2001-05-25, generated by lfparser version 2.12