Le choix entre NIS et NIS+ est assez facile : utilisez NIS si vous n'avez pas à utiliser NIS+ ou si vous avez besoin d'un bon niveau de sécurité. NIS+ est beaucoup plus problématique à administrer (c'est assez simple à gérer du coté client, mais le coté serveur est absolument horrible). Un autre problème vient du fait que le support NIS+ sous Linux est toujours en développement : vous devrez récupérer la dernière version de la glibc ou attendre que la glibc 2.1 soit diffusée. Il existe un portage du NIS+ glibc pour libc5, qui consiste à installer une libc de remplacement.
Le choix entre la version tradionnelle de NIS ou le code NIS dans la bibliothèque NYS est un choix entre paresse et maturité contre flexibilité et amour de l'aventure.
Le code du "NIS traditionnel" se trouve dans la bibliothèque standard C et souffre quelquefois de son âge et de son peu de souplesse.
Le code NIS situé dans la bibliothèque NYS, vous oblige soit à recompiler et refaire une édition de liens sur tous vos programmes avec la bibliothèque libnsl, soit de recompiler la bibliothèque libc pour y inclure le code libnsl (ou peut-être pouvez-vous récupérer une version précompilée de la libc chez quelqu'un qui l'a déjà fait.).
Une autre différence est que le code traditionnel NIS gère quelques fonctionnalités pour les groupes de réseaux NIS (Netgroups), ce que le code NYS n'implémente pas (encore !). Par contre, le code NYS vous permet d'utiliser les mots de passe Shadow d'une manière transparente. Le code "NIS traditionnel" ne gère pas les Shadow avec NIS.
Toutefois, oubliez tout cela si vous utilisez la nouvelle bibliothèque GNU C 2.x (c.a.d. libc6). Elle utilise NSS (name switch service), ce qui la rend beaucoup plus souple et est capable de gérer les "maps" NIS/NIS+ suivantes : aliases, ethers, group, hosts, netgroups, networks, protocols, publickey, passwd, rpc, services et shadow.
Chapitre suivant, Chapitre Précédent
Table des matières de ce chapitre, Table des matières générale
Début du document, Début de ce chapitre