Après avoir utilisé pendant un temps LDAP, j'en arrive à la conclusion que ce type de serveur est parfait pour une grande structure mais totalement ridicule pour un réseau domestique. D'un autre côté, on a aussi autre à faire de son temps que de s'amuser à répliquer les comptes, les droits, les groupes sur 5 machines. La solution intermédiaire est un bon vieux retour au source avec NIS.

Principe

NIS est un protocole d'origine SUN dont le but est de publier sur un réseau UNIX à peu prés toutes les bases de données traditionnelles au format ndbm et ainsi les rendre disponibles pour des clients, UNIX eux aussi.

Ces bases de données sont tout simplement /etc/passwd, /etc/shadow, /etc/group, /etc/hosts, /etc/services, /etc/protocols, etc. En utilisant les 3 premières citées, de la même manière qu'avec un serveur LDAP, ce protocole permet de s'authentifier partout sur le réseau. Et en utilisant /etc/hosts il serait aussi possible de se passer, plus ou moins de Bind mais il est souvent délicat de se passer de DNS, même pour une petite infrastructure.

Techniquement NIS, aussi appelé Yellow Pages, utiliser le même canal RPC que les transactions NFS. NFS, pour ceux qui ne le savent pas, est aussi un système d'origine SUN, permettant le partage de dossier dans le monde UNIX à l'instar de SMB/CIFS dans le monde Windows.

Lorsque l'on ne compte QUE des machines UNIX dans son réseau, et que ce réseau n'est pas composé de what-milles bécanes, NIS est une très bonne alternative à LDAP/Bind. Non pas qu'il soit plus performant, loin de là, mais surtout parce qu'il est simple, stable, vieux, solide, il ne bouge plus ou presque. Et surtout il ne menace pas de vous planter à chaque mise à jour parce qu'un ingénieur de chez Mandriva (ou autre) a décidé qu'il était absolument intolérable que le serveur bidulo ne soit chrooté dans /var avec des ACLs sécurisés par des jetons Kerberos 5 et encapsulé dans des transactions chiffrées vous obligeant à passer la nuit à tenter de comprendre pourquoi vous êtes devenu un inconnu sur votre propre système...

NIS se contente très simplement d'utiliser ces bons vieux fichiers pour en faire des bases de données toute bêtes et de les publier à la demande aux clients qui en ont besoin.

Installation du serveur

Pour commencer, une brassée de paquets à installer : portmap (si vous n'avez pas déjà un serveur NFS), ypserv, yp-tools et nscd. Ce dernier permet d'ajouter un cache configuré par défaut pour retenir les login/mot de passe un certain temps. Cela permet de limite les requêtes faites sur le serveur pour connaître le group ou l'uid de tel ou tel utilisateur.

Première étape, déclarer un nom de réseau NIS. Pour cela il faut modifier votre fichier /etc/sysconfig/netword :

Le serveur qui va distribuer les informations est ypserv. Son fichier de paramétrage est /etc/ypserv.conf et généralement il contient déjà tout ce qu'il faut, vérifiez seulement que vous avez au moins cela :

Faites un man ypserv.conf pour les deux dernières lignes si vous voulez blinder un peu la sécurité. Personnellement, dans un LAN domestique totalement étanche, je m'en moque un peu.

Maintenant il nous faut initialiser notre serveur principal

Là je n'ai donc que faire répondre oui à la question, rien de bien sorcier. Et... c'est tout... Le serveur est techniquement configuré Maintenant un bon ami administrateur m'a un jour expliqué que ce n'était pas parce que Linux n'avait à peu prés jamais besoin de redémarrer qu'il ne fallait pas le faire pour vérifier que tout se lançait correctement, surtout sur un serveur. Et il a grandement raison, donc maintenant, redémarrage. Tant pis pour le record d'uptime .

Une fois le serveur redémarré, vous pouvez regarder si tout semble en place

Tout semble bon, passons au paramétrage des clients. Si vous utilisez un serveur dhcpd, vous pouvez aussi ajouter la ligne option nis-domain "karma-lab.net"; dans votre subnet de sorte à réduire ne pas avoir à régler ce domaine sur les clients.

Paramétrage des clients UNIX

Cette fois nous devons installer ypbind, yp-tools et toujours portmap. Vous l'aurez compris, ypbind est le client de ypserv et son paramétrage se fait par le fichier /etc/yp.conf dans lequel nous allons indique notre domaine et l'adresse IP de notre serveur NIS.

NIS se contente de distribuer l'information. Le choix de la source d'authentification en elle-même passe par glibc et est paramétrée par le fichier /etc/nsswitch.conf. C'est dans ce fichier que nous allons indiquer les sources à utiliser par ordre de priorité et par type d'action voulue :

Ainsi configuré, pour chacune des 3 clefs de recherche nous cherchons en priorité dans le fichier local puis si rien n'y est trouvé, la source NIS.

Le paramétrage est terminé dans le cas où vous utilisez un serveur dhcp (voir plus haut) et presque terminé dans le cas contraire où il nous faut encore modifier /etc/sysconfig/network pour ajouter la même entrée NISDOMAIN=mon_domaine que pour le serveur.

Là il s'agit de la version longue. Dans la version courte, utilisez simplement l'outil mandriva drakauth, sélectionnez NIS, donnez le nom du domaine et l'adresse IP du serveur et validez. L'outil se charge de récupérer les paquets manquants et de tout configurer. Coût de l'opération, 5 secondes...

Ceci fait, il ne nous reste plus qu'à tester :

Après il faut bien sur tester une authentification mais tout devrait marcher sans problèmes.

Mise à jour des bases de données

Un point appréciable avec NIS est que c'est aussi simple à maintenir qu'à configurer. Voyons sur le serveur en combien de temps nous pouvons ajouter un utilisateur, son groupe, et sa machine (si vous utilisez la publication de /etc/hosts) :

En gros cela a du prendre 10 à 30 secondes selon votre rapidité à taper les commandes. Pour vérifier que ce n'est pas du bleuf, un petit tour sur une machine cliente s'impose :

Voilà, terminé. Maintenant il faut comparer cela au temps que cela aurait pris avec un serveur LDAP avec myLdapAdmin ou mieux... à la main en ligne de commande...

Pour les portables

Le soucis avec les authentification centralisée et les portables c'est que ce dernier ne sont pas toujours connecté au réseau. Du coup, impossible de contacter le serveur NIS et par voir de conséquence impossible de s'authentifier.

Pour régler ce problème de manière élégante nous allons utiliser nscd de manière plus avancée en modifiant un peu sa configuration. L'idée est d'obtenir quelque chose comme cela pour son fichier de configuration /etc/nscd.conf

Ainsi configuré, le cache va être persistant, maintenu autant que fois que nécessaire (reload-count), d'une durée de vie de 7 jours (604800 secondes) et ce pour les tables passwd et group. A noter que passwd indique ce que c'est la table /etc/passwd distante qui est mise en cache, celle qui ne contient pas les mots de passe.

L'effet de cette configuration est qu'une fois nscd relancé, un utilisateur connecté au réseau qui s'authentifie peut continue à travailler sur sa machine même s'il est déconnecté du réseau. En revanche, s'il met fin à sa session, comme shadow n'est pas en cache, il ne pourra plus s'authentifier.

Pour pouvoir ouvrir une session hors du réseau la seule solution est... de ne pas utiliser de mot de passe et préférer une authentification par empreinte digitale, par clef usb, etc.

Conclusion

J'étais passé de NIS à LDAP il y a un peu plus d'un an, pensant que ça allait me simplifier la vie. J'avoue que cela a été instructif car LDAP est un monde à part entière qu'il est pertinent d'au moins connaître un peu. Mais ce retour à NIS a été un vrai soulagement car même si c'est un petit réseau local, une partie de la complexité (le groupe d'accès à telle ou telle ressource via le net, le pote bidulo de passage sur le réseau, le bon ami à qui l'on crée un compte pour qu'il mate la machine pendant qu'on se dore la pilule, l'ajout de droits temporaire à la copine bidulette pour télécharger une vidéo, etc.) reste la même que pour un réseau plus grand à la différence que l'on a autre chose à faire de son temps que de jouer les administrateurs système...

Commentaires