NIS avec le sourire

Chaput Emmanuel

11 octobre 2000

ResumeCe document presente l’utilisation et l’administration du systeme NIS (Net-

work Information Service) qui permet une gestion centralisee de fichiers telsque ceux impliques dans la configuration des machines UNIX.

”NIS avec le sourire” se veut simple, comme son nom l’indique, et essentiel-lement pratique ; je n’y developpe aucune theorie, il reste donc a la portee detoute personne ayant des connaissances minimales d’utilisation et d’adminis-tration d’un systeme de type UNIX.

Table des matieres1 Introduction 3

1.1 Buts de NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Contexte des exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Principes 52.1 Modele client-serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Les fichiers geres par NIS . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Ouverture du systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Modification des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Installation du serveur maıtre 73.1 Affectation du nom de domaine . . . . . . . . . . . . . . . . . . . . . . 73.2 Initialisation du serveur maıtre . . . . . . . . . . . . . . . . . . . . . . 83.3 Lancement du serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Installation d’un serveur esclave 94.1 Affectation du nom de domaine . . . . . . . . . . . . . . . . . . . . . . 94.2 Initialisation d’un serveur esclave . . . . . . . . . . . . . . . . . . . . . 9

5 Installation d’un client 95.1 Affectation du nom de domaine . . . . . . . . . . . . . . . . . . . . . . 95.2 Liaison avec un serveur . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6 Prise en compte des services NIS 106.1 La table netgroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6.1.1 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106.1.2 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106.1.3 Utilisation de la table . . . . . . . . . . . . . . . . . . . . . . . . 11

6.2 Les tables des mots de passe . . . . . . . . . . . . . . . . . . . . . . . . 126.2.1 Mise en œuvre de NIS . . . . . . . . . . . . . . . . . . . . . . . 126.2.2 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.3 Les tables hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1

6.3.1 Lien avec le DNS . . . . . . . . . . . . . . . . . . . . . . . . . . 156.3.2 Generation des tables . . . . . . . . . . . . . . . . . . . . . . . 16

7 Format des tables NIS 16

8 Maintenance des tables 178.1 Mise a jour des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178.2 Transfert de tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188.3 Changement de serveur maıtre . . . . . . . . . . . . . . . . . . . . . . 18

9 Choix des domaines et des serveurs 19

10 Specificites de certains systemes 1910.1 Le fichier nsswitch.conf . . . . . . . . . . . . . . . . . . . . . . . . 1910.2 Le systeme Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2110.3 Linux avec NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

10.3.1 Le client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2110.3.2 Le serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

10.4 Linux avec NYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2210.4.1 Le client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2210.4.2 Le serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

A Resume des principales commandes 23

2

1 IntroductionSi la gestion des fichiers de configuration tels que /etc/passwd ou /etc/-

hosts est simple sur une machine isolee, elle peut se reveler beaucoup plus pro-blematique sur un reseau comportant un nombre consequent de stations. Il est eneffet difficile, mais important, de garder une coherence entre les fichiers de confi-guration des differentes machines.

La tache de l’administrateur du systeme s’avere alors penible, puisqu’il lui fautmettre a jour autant de fichiers qu’il a de machines sous sa responsabilite, et ce cha-que fois qu’une ressource (machine, imprimante ou meme utilisateur) est ajoutee,supprimee ou modifiee. Dans de telles conditions, l’administration d’un reseaudevient vite penible, voir impraticable. C’est la qu’intervient NIS.

Le but de ce document est de decrire le fonctionnement et l’administration dusysteme NIS de facon simple mais detaillee. Je vais donc essayer d’une part d’etreasses precis et d’autre part de ne pas sombrer dans une exhausivite rebarbative.Ce document en etant a ses toutes premieres versions, je vous demanderai d’etreindulgent vis a vis des eventuelles erreurs et de m’envoyer tous vos commentairesa l’adresse chaput@ensica.fr, merci d’avance !

Je tiens a remercier Thierry Parisot et Vincent Nicomette pour leurs precieusesremarques et leurs nombreuses corrections.

1.1 Buts de NIS

Le Network Information Service (ou NIS anciennement connu sous le nom depages jaunes, ou yellow pages) propose une solution a la situation problematiquedecrite precedemment. Pour cela, NIS fournit un mecanisme de gestion centraliseedes principaux fichiers de configuration d’une machine UNIX. Ce mecanisme fonc-tionne selon un modele client-serveur.

Un tel service est particulierement adapte aux fichiers de configuration com-muns a toutes les machines d’un meme domaine NIS, tels que :

– la liste des comptes utilisateurs et leurs caracteristiques,– la liste des machines du reseau et leur(s) adresse(s),– la liste des protocoles de communication.Il n’est cependant pas utilisable tel quel pour les fichiers comportant une com-

posante fortement specifique a chaque machine tels que la liste des systemes defichiers a monter (fichier /etc/fstab) ou la liste des imprimantes connectees ausysteme (fichier /etc/printcap). Notons cependant que l’automonteur permetd’etendre les possibilitees du fichier fstab en profitant notemment de NIS. Au-cune solution similaire n’existe pour le moment pour le fichier printcap.

Notons enfin qu’il est possible de construire ses propres outils et de modifierNIS, pour permettre une gestion centralisee de donnees telles qu’un annuaire ouun ensemble de licenses.

Remarque : Sauf indication contraire, la syntaxe des fichiers de configu-ration du systeme ainsi que leur localisation, sont valables pour l’im-plementation de NIS disponible sur les systemes SunOS 4.11. Elles res-tent cependant valables sur nombre d’autres systemes, tels que Linux.Chaque fois que possible, les specificites de chaque systeme ou famillede systeme seront donnees.

1SunOS est une marque deposee par Sun Microsystem.

3

1.2 Contexte des exemplesAfin d’etre aussi illustratif que possible, je vais essayer de ponctuer ce docu-

ment par quelques petits exemples tout a fait concrets.Nous allons donc imaginer une petite communautee composee de deux famil-

les, les Dupond et les Durant. Ces deux familles sont composees de Monsieur,Madame et leurs enfants. Comme ils habitent tous dans deux maisons jumelles, ilsont un resau commun sur lequel sont connectees leurs machines.

crepe tiramisu tarte glace

coulomiersroquefort gruyereemental

bzzbzz

dessert

fromage

crrcrrgloubiboulga-f

gloubiboulga-d

FIG. 1 – Le reseau de notre communautee.

machine adresse internetroquefort 192.70.110.2emental 192.70.110.3

coulomiers 192.70.110.4gruyere 192.70.110.5

gloubiboulga-f 192.70.110.6gloubiboulga-d 192.70.110.66

crepe 192.70.110.67tiramisu 192.70.110.68

tarte 192.70.110.69glace 192.70.110.70

TAB. 1 – Les adresses internet de notre exemple.

La figure 1 montre le reseau de cette petite communautee. Les machines dureseau fromage appartiennent a la famille Durant, alors que le reseau dessertet les machines qui en font partie appartiennent a la famille Dupond. La machinegloubiboulga est un achat commun et permet aux deux reseaux (et donc auxdeux familles) de communiquer.

Les adresses internet des differentes machines sont donnees par la table 1. Biensur, ces adresses sont completement farfelues, aussi n’essayez pas de les utiliser,ou vous risqueriez d’avoir des surprises, ainsi que leur actuel proprietaire.

Les tables 2 (a) et (b) donnent respectivement les numeros des differents utili-sateurs et des differents groupes.

4

login UIDraymond 101gisele 102

emmanuel 103valerie 104marcel 201

therese 202carine 203

vincent 204ernest 301bart 302

groupe GIDdupond 101durant 102enfants 103adultes 104

amis 105

(a) (b)

TAB. 2 – Les numeros des utilisateurs et groupes.

2 PrincipesRegardons brievement les grands principes mis en œuvre ou exploites par NIS.

2.1 Modele client-serveurLe service NIS fonctionne selon un modele client-serveur. Plusieurs serveurs

peuvent etre actifs simultanement, mais un seul d’entre eux, appele serveur maıtre,possede la source des informations. Les autres serveurs (appele serveurs esclaves),obtiennent une copie des informations en provenance du serveur maıtre. Un telmecanisme permet de meilleurs temps de reponse. La figure 2 montre un exemplede configuration d’un ensemble de machines utilisant NIS.

De plus, les clients NIS ¡¡choisissant¿¿ leur serveur dynamiquement, un serveurhors service ne bloque que temporairement ses clients si un autre serveur est lapour traiter leurs requetes. Ainsi la structure de la figure 2 peut evoluer au coursdu temps, en fonction de la disponibilite des differents serveurs.

Données

maitreServeur

esclave

Serveur

esclave

Serveur

Client Client Client Client Client

FIG. 2 – Architecture client-serveur de NIS.

Un serveur (qu’il soit maıtre ou esclave) peut etre egalement client du serviceNIS, et c’est generalement le cas. Ce n’est cependant pas une obligation. Certains

5

Nom du fichier Augmente Type d’informationRemplace

/etc/aliases A Les aliases utilises pour le mail/etc/bootparams A Informations pour le boot des

stations sans disque/etc/ethers R Correspondance

adresses MAC - adresses Internet/etc/group A Liste des groupes d’utilisateurs/etc/hosts R Correspondance

adresses Internet - noms/etc/netgroup N Groupes reseau (introduit par NIS)/etc/netmasks R Masques reseau/etc/networks R Adresses reseau/etc/passwd A Definition des utilisateurs/etc/protocols R Noms des protocoles reseau/etc/rpc R Definition des RPC/etc/services R Noms et ports des services reseau

TAB. 3 – Les fichiers geres par NIS.

serveurs particulierement ¡¡critiques¿¿ peuvent ne pas utiliser les services NIS, no-temment pour la gestion des utilisateurs.

2.2 TerminologieNous appellerons table NIS toute base de donnees traduite dans le format DBM

manipule par NIS. Une base sera designee par un nom, generalement celui de labase de donnees qu’elle centralise.

Un domaine NIS est un ensemble de tables NIS, mais l’on designe souvent, parextension, sous le terme de domaine NIS l’ensemble des machines qui utilisent lesmemes tables.

2.3 Les fichiers geres par NIS

Toute information susceptible d’etre geree de facon centralisee au niveau d’unreseau peut etre geree par NIS ; par defaut, ce dernier ne permet cependant de gererqu’un certain nombre de fichiers.

Le service NIS est ainsi particulierement bien adapte aux fichiers censes etrecommuns a un reseau de machines, tel que le fichier des mots de passe (/etc/passwd),celui definissant les noms symboliques des machines (/etc/hosts) ou encore ce-lui des aliases mail (/etc/aliases).

La table 3 donne la liste des fichiers traditionnellement geres par NIS. Ces fi-chiers peuvent etre augmentes, auquel cas le fichier local correspondant reste va-lable, NIS ne faisant qu’ajouter de nouvelles informations, c’est le cas par exempledu fichier des mots de passe, qui permet de definir des utilisateurs locaux a unemachine2. Mais ces fichiers peuvent egalement etre completement remplaces par latable leur correspondant, c’est le cas du fichiers des noms de machines, /etc/hos-ts qui n’est pas consulte si le service NIS est actif.

2Le super utilisateur, particulierement, ne doit pas etre definit dans la table NIS, pour des raisonsevidentes de securite.

6

2.4 Ouverture du systemeNotons egalament que le service NIS est parfaitement ouvert a la gestion de

nouvelles informations. Toute base d’informations pouvant etre geree de faconcentralisee peut etre traitee simplement par NIS. La seule veritable contrainte surl’information est qu’elle puisse etre stockee sous forme d’enregistrements (clef, va-leur), chaque valeur pouvant alors etre retrouvee en fonction de la clef. Ainsi unannuaire peut etre aisement mis en place avec NIS, la clef etant le nom des per-sonnes et la valeur contenant les informations interessantes (numero de telephone,bureau, adresse e-mail, ...).

La mise en place d’un tel systeme necessite bien entendu le developpementdes applications utilisant les services de NIS, ce dernier n’assurant que la gestioncentralisee des informations et leur propagation. Ainsi pour mettre en place unegestion centralisee des imprimantes, il serait necessaire de modifier les commandesde gestion de l’impression afin qu’elles prennent en compte le systeme NIS.

Si l’information doit pouvoir etre accedee par une autre clef (on veut par exemplepouvoir demander a notre annuaire des choses comme ”Qui travaille dans le bureauxxx ?”), il faut alors igenerer plusieurs tables NIS, chacune contenant la meme in-formation indexee par une clef differente. Il faut alors bien entendu se preocupperde conserver la coherence des differentes tables entre elles. Ceci n’est cependantpas un probleme puisque les tables NIS sont construites automatiquement d’apresune base de donnees decrite dans un autre format (generalement du texte simple) ;il est alors simple de s’assurer de la coherence des differentes tables lors de leurconstruction.

2.5 Modification des tablesUn inconvenient quant a la gestion de bases d’information grace a NIS est la dif-

ficulte de modifier les donnees. A priori, seul l’administrateur de NIS peut modifierla base de donnees, et ce uniquement sur la machine qui est le serveur maıtre. Deplus, une telle modification n’est pas ”elementaire” dans son principe, puisqu’elleimplique une recompilation de la base de donnees, puis une propagation, via lereseau, de la nouvelle base. On evitera donc de gerer par NIS des bases d’informa-tion qui sont, par nature, changeantes, telles qu’un agenda. Si il semble utile delaisser la possibilite aux utilisateurs de modifier une table NIS, on prendra soint deconstruire les commandes necessaires (voir par exemple la commande yppasswdpour la table des mots de passe).

3 Installation du serveur maıtreApres avoir choisi un nom de domaine, l’administrateur doit determiner la ma-

chine qui servira de serveur maıtre. Une telle machine doit etre stable et disponible.Son installation se deroule en plusieurs etapes.

3.1 Affectation du nom de domaineCette affectation se fait par la commande suivante, qui doit etre executee par le

super-utilisateur :

maitre# domainname � nom-du-domaine �en general, cette commande sera executee automatiquement lors du boot de

la machine par un des scripts d’initialisation, que ce soit /etc/rc.local pourun systeme de type BSD ou un des scripts definis dans /etc/inittab pour unemachine System V. Ces scripts comportent le plus souvent des lignes telles que :

7

if [ -f /etc/defaultdomain ] then/usr/etc/yp/domainname ’cat defaultdomain’

endif

de telle sorte qu’il suffit de mettre le nom du domaine dans le fichier /etc/-defaultdomain pour qu’il soit correctement positionne lors du boot suivant.

3.2 Initialisation du serveur maıtreElle se fait par la commande suivante :

maitre# ypinit -m

le repertoire /var/yp/nom-du-domaine (ou /etc/yp/nom-du-domaine)est alors cree. Puis les tables NIS sont mises en place, en commencant par la tableypservers qui contient la liste des serveurs esclaves du domaine. Cette table estconstruite de facon interactive. Les serveurs esclaves n’ont pas besoin d’etre dejaoperationnels. Ils devront l’etre lors du premier transfert des tables.

Exemple. Imaginons que notre petite communaute ai decide d’utiliser la ma-chine gruyere comme serveur maıtre et la machine crepe comme serveuresclave. Les lignes suivantes montrent alors l’initialisation du serveur maıtresur la machine gruyere qui fonctionne avec le systeme d’exploitation Li-nux :gruyere# /usr/lib/yp/ypinit -mAt this point, we have to construct a list of the hosts which will run NIS

servers. gruyere is in the list of NIS server hosts. Please continue to add

the names for the other hosts, one per line. When you are done with the

list, type a <control D>.

next host to add : crepenext host to add :

The current list of NIS servers looks like this :

gruyere

crepe

Is this correct? [y/n : y] yWe need some minutes to build the databases...

Building /var/yp/familles/ypservers...

Running /var/yp/Makefile...

make[1] : Entering directory ‘/var/yp/famille’

Updating hosts.byname...

Updating hosts.byaddr...

Updating networks.byaddr...

Updating networks.byname...

Updating protocols.bynumber...

Updating protocols.byname...

Updating rpc.byname...

Updating rpc.bynumber...

Updating services.byname...

Updating passwd.byname...

Updating passwd.byuid...

Updating group.byname...

Updating group.bygid...

Updating netid.byname...

make[1] : Leaving directory ‘/var/yp/famille’

gruyere#

8

3.3 Lancement du serveurIl est lance par :

maitre# ypserv

cette commande etant generalement lancee par un des scripts d’initialisationde la machine.

4 Installation d’un serveur esclaveElle est tres similaire a celle du serveur maıtre.

4.1 Affectation du nom de domaineLe nom du domaine doit d’abord etre positionne par la commande domain-

name (en general lors du boot), exactement comme sur le serveur maıtre :

maitre# domainname � nom-du-domaine �Ici aussi cette operation est generalement realisee lors du boot.

4.2 Initialisation d’un serveur esclaveL’initialisation se fait en specifiant le nom du serveur maıtre (qui doit etre

operationnel), par la commande :

esclave# ypinit -s � maitre �cette commande entraine une recuperation d’une version compilee des tables

depuis le serveur maıtre. Le serveur est ensuite lance de la meme facon que sur leserveur maıtre.

Avant d’etre initialise, un serveur esclave doit etre defini dans la table ypser-vers. Si ce n’est pas le cas, cette derniere doit donc etre mise a jour sur l’esclaveavant de lancer la commande ypinit sur le serveur esclave.

5 Installation d’un clientL’installation d’un client se reduit a sa plus simple expression, comme nous

allons le voir.

5.1 Affectation du nom de domaineLe nom de domaine d’un client doit avant toute chose etre positionne, et ce de

la meme facon que sur un serveur (maıtre ou esclave) :

client# domainname � nom-du-domaine �comme sur les serveurs, cette manipulation sera generalement effectuee au

boot par les scripts d’initialisation.

5.2 Liaison avec un serveurEnsuite le demon de liaison avec un serveur NIS doit etre lance :

esclave# ypbind

comme toutes les commandes NIS importantes, ypbind est generalement lanceau demarrage de la machine par un script d’initialisation.

9

�Cette configuration est valable pour des systemes tels que SunOS 4.1.x ; sur

des systemes plus recents (Solaris, Linux, . . .), la configuration du client estbasee sur le fichier nsswitch.conf (voir 10.1).

Le demon ypbind cherche un serveur grace a une requete envoyee sur lereseau local, et ce via le mecanisme de broadcast fournit par le reseau physiquesous-jacent. Il utilisera alors les services du premier serveur (maıtre ou esclave)qui lui reponde.

Cette solution peut ne pas etre satisfaisante, soit pour des raisons de securite,soit parce qu’elle necessite un serveur par reseau local. Il est alors possible despecifier explicitement a un client le serveur qu’il doit utiliser.

Exemple. Imaginons que nous voulions que la machine glace utilise commeserveur la machine roquefort, il faut alors taper la commande suivante :

glace# ypset roquefortglace#

La relation client-serveur peut ainsi traverser les routeurs.

6 Prise en compte des services NIS

Les services NIS ne sont pas pris en compte automatiquement, l’administrateurdoit le specifier explicitement. La syntaxe varie selon le service utilise.

Nous allons decrire ici la mise en œuvre de NIS pour les base de donnees lesplus critiques.

6.1 La table netgroupCette table ne remplace ni n’enrichit aucun fichier de configuration, elle n’a

aucune fin en soi. Elle permet simplement de gerer des groupes de machines et/oud’utilisateurs pour une utilisation dans les autres tables.

6.1.1 Syntaxe

La syntaxe d’une entree dans cette table est la suivante :

nom-du-groupe (triplet | nom-de-groupe)*

ou un triplet est de la forme :

(machine, utilisateur, domaine)

Il faut noter que le nom de domaine stipule dans le triplet n’est pas reellementun troisieme discriminant, mais le nom du domaine dans lequel cette entree estdefinie.

Chacune des trois valeurs peut etre omise, ce qui signifie que toute valeur pource champs est conforme au triplet. Elle peut egalement etre remplacee par un tiret(-), pour signifier que ce champs n’est pas defini pour ce triplet.

6.1.2 Exemples

Voyons sur quelques exemples l’utilisation de cette table. D’abord la definitionde groupes d’utilisateurs :

10

Exemple. Definition de groupes d’utilisateurs.Nos utilisateurs se divisent dans un premier temps en deux grands groupesprincipaux, les familles Durant et Dupond, nous allons donc creer deuxgoupes pour les reunir :

durant (-, raymond, -) (-, gisele, -) \(-, emmanuel, -) (-, valerie, -)

dupond (-, marcel, -) (-, therese, -) \(-, carine, -) (-, vincent, -)

Mais notre petite communaute peut egalement etre decomposee logiquementsuivant d’autres criteres, nous pouvons ainsi creer les groupes suivants :

enfants-dupond (-, carine, -) (-, vincent, -)adultes-dupond (-, marcel, -) (-, therese, -)enfants-durant (-, emmanuel, -) (-, valerie, -)adultes-durant (-, raymond, -) (-, gisele, -)adultes adultes-dupond adultes-durantenfants enfants-dupond enfants-durantamis (-, ernest, -) (-, bart, -)

ainsi certaines autorisations pourront etre offertes aux enfants seuls ou auxadultes seuls, et ce independament de la famille (et donc de leur groupe d’ap-partenance defini dans le fichier /etc/passwd ).Attention, les autorisations qui peuvent etre accordees ou refusees via ce mecanismen’ont aucun rapport direct avec les droits regissant les systemes de fichiers.

Ensuite, la definition de groupe de machines, de facon independante des utili-sateurs :

Exemple. Definition de groupes de machines.Les deux familles ont chacune leur reseau, nous pouvons definir des netgroupspermettant de gerer chaque reseau comme un groupe de machines :

dessert (crepe, -, -) (tiramisu, -, -) \(tarte, -, -) (glace, -, -) (gloubiboulga-d)

fromage (roquefort, -, -) (emental, -, -)\(coulomiers, -, -) (gruyere, -, -)\(gloubiboulga-f, -, -)

6.1.3 Utilisation de la table

Comme nous l’avons deja dit, le seul but de cette table est d’etre utilisee dansles autres tables. Nous verrons donc des exemples d’utilisation des groupes quenous venons de creer lors de la description de chacune des autres tables.

Nous pouvons tout de meme consulter une table netgroup precedemmentcreee grace a la commande ypcat.

Exemple. Utilisons la commandeypcat sur la machine glace pour verifiernotre table definie dans les exemples precedents.glace$ ypcat -k netgroupdurant (-, raymond, -) (-, gisele, -) (-, emmanuel, -) (-, valerie, -)

dupond (-, marcel, -) (-, therese, -) (-, carine, -) (-, vincent, -)

enfants-dupond (-, carine, -) (-, vincent, -)

adultes-dupond (-, marcel, -) (-, therese, -)

enfants-durant (-, emmanuel, -) (-, valerie, -)

11

adultes adultes-dupond adultes-durant

enfants enfants-dupond enfants-durant

amis (-, ernest, -) (-, bart, -)

dessert (crepe, -, -) (tiramisu, -, -) (tarte, -, -) (glace, -, -)(gloubiboulga-d)

fromage (roquefort, -, -) (emental, -, -) (coulomiers, -, -) (gruyere, -, -)(gloubiboulga-f, -, -)

glace$

Notons que n’importe quel utilisateur peut consulter les tables NIS.

6.2 Les tables des mots de passeLe fichier des mots de passe est enrichi par les tables passwd.byname et pass-

wd.byuid qui ne representent que deux facons distinctes d’acceder aux memesinformations.

Ces deux tables montrent les limitations du service NIS evoquees en 2.4 et 2.5. Ilest en effet necessaire de pouvoir acceder aux informations du fichier (de la table)des mots de passe grace a deux clef, le login de l’utilisateur (pour les commandesde connection, de changement de proprietaire ou d’identite, ...) et son numerod’utilisateur (pour pouvoir donner le nom du proprietaire d’un fichier en fonc-tion de ce numero, ...)3. NIS ne permettant pas directement ce double acces, il a etenecessaire de construire deux tables contenant la meme information.

De plus, la table (ou les tables) des mots de passe doit (ou doivent) pouvoiretre mise(s) a jour par l’utilisateur, ce dernier ayant la possibilite de modifier sonpropre mot de passe, son champs ”commentaire” ou le shell qui lui est associe. Ila donc ete necessaire de creer une commande pour cela, la commande yppasswd,qui remplace la commande passwd. Un demon, yppasswdd(), a du etre ajouteafin de conserver a cette nouvelle commande la semantique de celle qu’elle doitremplacer. En effet, un changement de mot de passe doit etre effectif des la com-mande validee. Dans le cas de NIS, une modification d’une table n’est effectiveau niveau des machines clientes qu’apres une recompilation puis une propagationde la table depuis le serveur maıtre. Le demon est donc charge de declencher cesactions.

6.2.1 Mise en œuvre de NIS

La prise en compte de la table des mots de passes se fait par des lignes commencantpar un signe + (plus) ou - (moins) dans le fichier /etc/passwd. La syntaxe resteanalogue a celle du fichier des mots de passe :

{+|-}[nom|@netgroup]:passwd:uid:gid:comment:home:shell

– Le signe + permet de valider l’entre, alors que le signe - interdit la connection.– Le nom permet de designer un utilisateur particulier, et un netgroup un en-

semble d’utilisateurs definis dans la table netgroup ; si aucun nom ni aucunnetgroup n’est present, alors c’est la table des mots de passe complete qui estconcernee.

– Le mot de passe doit etre tel que si le service NIS est desactive, l’entree definiene permette pas de connection ; il s’agit generalement du caractere *.

– Les numeros d’utilisateur et de groupes importent peu, puisque NIS est prio-ritaire sur ces seuls champs (et sur le mot de passe lui-meme).

– Les trois derniers champs peuvent etre modifies a volonte afin de tenir comptedes specificites de la machine.

3Ces deux acces sont necessaires afin de generaliser a NIS les appels getpwnam() et getpwuid()utilises pour acceder au fichier local /etc/passwd.

12

�L’ordre des lignes du fichier passwd modifie devient particulierement im-

portant, toute recherche s’arretant des qu’une entree, positive ou negative,concernant l’utilisateur cherche est trouvee. Deux lignes ne peuvent alors etre per-muttees sans risque, sauf si elles sont de meme signe, ou si aucun utilisateur n’estconcerne par ces deux lignes a la fois. Voir les exemples pour plus plus de details.

6.2.2 Exemples

Voyons sur quelques exemples comment exploiter cela. Nous ne nous preoccuperonsici que de la table des mots de passe, meme si les exemples decrits ne fonctionnentpas tels quels. Le resultat dependra en effet des groupes definis dans la table net-group et de la configuration de l’automount sur les machines considerees.

Inclusion de toute la table Le cas le plus classique de l’utilisation de la table desmots de passe est son inclusion totale. Elle se fait grace a la ligne suivante a la findu fichier /etc/passwd :

+:*:0:0:::�

Tous les systemes ne necessitent pas cette ligne, notemment ceux utilisantle fichier nsswitch.conf (cf 10.1) . . .

Inclusion d’un groupe d’utilisateurs L’utilisation des tables NIS dans le fichierdes mots de passe peut cependant etre reglee de facon beaucoup plus fine qu’uneinclusion totale ou pas d’inclusion du tout. Il est ainsi possible de manipuler desgroupes d’utilisateurs, au sens de la table netgroup.

Exemple. Imaginons dans un premier temps que nos utilisateurs ne se con-nectent jamais sur une machine appartenant a l’autre famille. Tous nos uti-lisateurs etant definis dans la tables NIS des mots de passe, nous voulons unmoyen de n’autoriser qu’une partie d’entre eux a se connecter sur une ma-chine donnee. Pour cela, nous creons deux entres dans la table netgroup (cfsous-section 6.1), que nous appelons dupond et durant, puis, sur chaquemachine de la famille Durant, nous inserons a la fin du fichier des mots depasse la ligne suivante :

+@durant:*:0:0:::

Ainsi, seuls les utilisateurs definis dans le netgroup durant pourront seconnecter sur ces machines. Les machines de la famille Dupond sont evidemmentmodifiees de facon symetrique.Quant a la machine gloubiboulga, elle contient dans son fichier des motsde passe :

+:*:0:0:::

afin de permettre, comme nous l’avons deja vu, a tous les utilisateurs definisdans les pages jaunes de se connecter.

Exclusion d’un groupe d’utilisateurs De la meme facon qu’il est possible d’in-clure un groupe d’utilisateurs, il est egalement possible d’en exclure.

Exemple. Imaginons maintenant que nos familles veulent regler l’acces acertaines machines d’une facon un peu plus souple. Par exemple, supposonsqu’il soit decide, pour des raisons de securite, que la machine gloubiboulgane soit pas accessible aux amis des familles. Le fichier des mots de passe de cettemachine doit alors contenir par exemple les lignes suivantes :

13

-@amis:*:0:0:::+:*:0:0:::

Attention a l’ordre ! Comme je l’ai deja dit, l’algorithme de recherche dans lefichier des mots de passe (puis eventuellement dans la table NIS) s’arrete des qu’iltrouve un entre correspondant au nom d’utilisateur recherche. Voyons ca sur unexemple.

Exemple. Ainsi si le fichier /etc/passwd d’une machine contient, danscet ordre :

+@durant:*:0:0:::-@enfants:*:0:0:::

alors l’utilisateur manu pourra se connecter sur cette machine. En effet, il abeau appartenir au groupe enfant, a priori interdit sur cette machine, ilappartient egalement au groupe durant qui, lui, est autorise. Cette autori-sation figurant avant l’interdiction du groupe enfant, c’est elle qui fait loi. . .

Inclusion et exclusion d’un utilisateur Il est possible d’autoriser ou d’interdirel’acces a une machine a un unique utilisateur. Le mecanisme est exactement lememe que pour un groupe d’utilisateur en remplacant le nom du groupe par celuide l’utilisateur.

Exemple. Ainsi, sur une machine ayant un fichier des mots de passe tel que :

root:JuhYOkIJreiqZU:0:0:root:/root:/bin/bashbin:*:1:1:bin:/bin:daemon:*:2:2:daemon:/sbin:+manu:*:0:0:::-@enfants:*:0:0:::-marcel:*:0:0:::+@dupond:*:0:0:::-gisele:*:0:0:::+::0:0:::

– l’utilisateur manu peut se connecter, meme si c’est un enfant,– les enfants ne peuvent pas se connecter (sauf manu),– marcel ne peut pas se connecter,– les Dupond peuvent se connecter, sauf les enfants et marcel.– gisele ne peut pas se connecter, (ce qui aurait ete different si elle avait ete

de la famille Dupond et pas un enfant).

Modification des champs Nous avons vu comment autoriser ou interdire l’accesa un utilisateur ou un groupe d’utilisateurs, voyons maintenant pourquoi et com-ment modifier certains champs. Cette possibilite n’est que tres rarement employeeet son utilisation ne se justifie que tres rarement.

Exemple. Imaginons que de nos deux familles aient envies de s’echanger desinformations. Ils peuvent utiliser ftp, le courrier electronique, le telephone,ou meme aller se voir. Mais si ils doivent partager des fichiers, il est plusconfortable de pouvoir aller ¡¡trainer¿¿ sur les comptes des autres grace a quel-quechose du genre :

14

carine@glace% cd valerie

Cependant, cela ne sera possible que si l’utilisateur valerie est defini dansle fichier des mots de passe. Pourtant nous ne voulons pas forcement autorisertout le monde dans le fichiers des mots de passe afin que chacun reste surses machines et n’aille pas sur celles des autres. Nous pouvons contourner leprobleme avec un fichier des mots de passe de la forme suivante (pour la familleDurant par exemple) :

+@durant:*:0:0:::+:*:0:0:Connection interdite sur cette machine::/bin/false

ainsi, les Durant peuvent toujours s’y connecter normalement, tous les utili-sateurs y sont definis (grace a la derniere ligne) mais personne d’autre que lesDurant ne peut s’y connecter.En fait la connection n’est pas reellement interdite, mais les utilisateurs ontun shell (/bin/false) qui ne permet de rien faire sur la machine. Quant auchamp commentaire, il est utilise pour expliquer pourquoi la connection n’estpas possible (il sera vu a l’aide de commandes telles que finger).

La modification d’un champ peut egalement etre employee pour des utilisa-teurs dont le repertoire de connection n’est pas le meme sur toutes les machines.

Exemple. Si, par exemple, l’utilisateur marcel qui est un Dupond a ha-bituellement ses fichiers sur le repertoire /home/marcel, mais qu’il ait unederogation pour se connecter sur une machine particuliere de la famille Du-rant ou ses fichiers se trouvent sur le repertoire /users/marcel, alors cettemachine aura dans son fichier des mots de passe :

+@durant:*:0:0:::+marcel:*:0:0::/users/marcel:

Ce genre de pratique reste cependant a eviter. On aura tendance a preferer desrepertoires de connection homogenes, autant pour le confort des utilisateurs quepour la simplicite de l’administration.

6.3 Les tables hostsDe la meme facon que la table des mots de passe se decompose en deux tables,

la tables de correspondance entre les noms des machines et leurs adresses IP sedecompose en deux tables qui sont

hosts.byaddr qui permet de retrouver le nom d’une machine en fonction deson adresse,

hosts.byname qui permet de retrouver l’adresse d’une machine en fonction deson nom.

Ces deux tables, hosts.byname et hosts.byaddr, permettent d’etablir lescorrespondances entre des noms de machines et leurs adresses internet. Elles peuventdonc etre utilisees conjointement avec un autre service equivalent, le DNS.

6.3.1 Lien avec le DNS

Le probleme de la resolution des noms (c’est a dire d’etablissement d’une cor-respondance bilaterale entre les noms symboliques des machines et leurs adressesinternet) est relativement complexe et peut mettre en oeuvre plusieurs mecanismesde resolution, parmis lesquels le fichiers /etc/hosts, les tables NIS qui lui cor-respondent, et le Domain Name Service ou DNS. Les tables NIS sont generalement

15

le mecanisme choisi pour un reseau local, alors que le DNS est mieux appoprie aun reseau a grande echelle et plus particulierement a un reseau de reseaux tel quel’Internet. Il peut cependant etre utilise sans probleme sur un petit reseau local siles autres fonctionnalites de NIS n’y sont pas utiles.

Sur un reseau local faisant partie d’un reseau a plus grande echelle, il est interessantde beneficier des avantages des deux techniques. C’est pour cela que les tablesNIS permettent l’integration du DNS. Dans ce cas, le mecanisme de recherche del’adresse d’une machine a partir de son nom est le suivant :

– le nom de la machine est cherche dans le fichier local de la machine surlaquelle s’execute le processus ayant effectue la requete, si il y est trouve,l’adresse est extraite de ce fichier,

– dans le cas contraire, et si la machine est un client NIS, la table hosts.bynameest consultee par une requete au serveur NIS,

– si cette deuxieme tentative echoue, et si le lien avec le DNS a ete etabli, le ser-veur NIS envoit une requete DNS au serveur stipule dans son fichier /etc/re-solv.conf . Puis il retourne la reponse (ou le constat d’echec) au clientayant effectue la demande.

La requete DNS est donc emise par le serveur NIS en cas d’echec, elle est parfai-tement transparente pour le client NIS.�

Sur les systemes bases sur le fichier nsswitch.conf, l’interaction avec leDNS est differente, voir 10.1.

Sur les serveurs NIS Sur les serveurs NIS, les interactions avec le service DNSsont parametres par le fichier /etc/resolv.conf qui doit contenir un pointeurvers un serveur de nom DNS, ce pointeur consiste en une ligne de la forme :

nameserver aaa.bbb.ccc.ddd

ou aaa.bbb.ccc.ddd represente l’adresse internet du serveur DNS.

Sur les clients NIS La cohabitation avec le service DNS est parfaitement trans-parente sur les clients NIS dans la mesure ou la resolution des noms passe alorsdirectement par le service NIS.

6.3.2 Generation des tables

Afin de valider le lien avec le DNS, les tables hosts doivent avoir ete genereesavec l’option -b de la commande makedbm. Ceci peut etre automatise en validantcette option dans le fichier /var/yp/Makefile du serveur maıtre.

7 Format des tables NIS

Comme je l’ai deja souligne, les tables NIS sont, en general, generees automa-tiquement a partir de fichiers ASCII classiques. Les tables gerees par defaut sontd’ailleurs eventuellement initialisees a partir des fichiers qu’elles doivent rempla-cer ou completer.

Ces fichiers ASCII sont donc convertis au format DBM, le format des bases dedonnees sous BSD, par la commande makedbm, qui cree un fichier de donnees(<table>.pag) et un fichier d’index (<table>.dir).

L’information est enregistree sous la forme clef - valeur, une seule clef etantdisponible pour chaque valeur. C’est pour cette raison qu’il est necessaire de creerplusieurs tables lorsque la meme base d’informations doit etre accedee par plu-sieurs clefs (voir par exemple les tables hosts.byname et hosts.byaddr).

16

Des informations permettant de prendre en compte la chronologie des tablessont egalement ajoutees afin de pouvoir suivre sans probleme leurs differentesversions, de meme que des informations permettant d’identifier le serveur maıtrede ces tables, afin d’eviter qu’un serveur esclave ou qu’un client ne soit victimed’un serveur pirate.

Le format tres particulier des fichiers DBM qui ne se prete pas a la copie tradi-tionnelle d’une machine a une autre (avec rcp par exemple) est une des raisonspour lesquelles un transfert de table(s) NIS, et plus particulierement un change-ment de serveur maıtre, doit etre effectue selon une methode bien particuliere (voir8.2).

8 Maintenance des tablesCreer et utiliser des tables, c’est bien joli, me direz-vous, mais il faut egalement

les maintenir, c’est a dire les modifier sur le serveur maıtre, les transferer versles serveurs esclaves, et eventuellement les faire migrer vers un nouveau serveurmaıtre.

8.1 Mise a jour des tablesSur le serveur, les tables dependent par defaut des fichiers de configuration

qu’elles doivent remplacer ou completer, ce qui n’est pas forcement une bonnesolution. Leur mise a jour est assuree explicitement par l’administrateur NIS gracea la commande make. Des fichiers d’extensions .time servent a mettre en oeuvreles dependances temporelles.

Ainsi, la mise a jour puis la propagation des tables s’effectuent de facon ”ato-mique” de la maniere suivante :

maitre# cd /var/ypmaitre# make

les fichiers <table>.dir et <table>.pag sont alors generes, si necessaire, apartir des fichiers de configuration (/etc/passwd, par exemple) grace a la com-mande makedbm4 puis les tables ainsi construites sont transferees sur les serveursesclaves grace a la commande yppush.

L’administrateur NIS a la possibilite de faire que les tables dependent d’autresfichiers que ceux par defaut. Pour cela, il doit modifier le fichier /var/yp/Makefileafin d’y exprimer les dependances souhaitees.

Exemple. Imaginons que l’administrateur de notre communaute decide d’uti-liser comme fichier source de sa table netgroup le fichier /etc/famil-les.ng local a la machine gruyere. Il va alors definir les groupes dansce fichier, modifier la ligne definissant la variable NETGROUP dans le fichier/var/yp/Makefile de la facon suivante :

NETGROUP = $(YPSRCDIR)/familles.ng

(la variable YPSRCDIR vaut “/etc”), puis propager les tables :

gruyere# makeNIS Map update started on Thu May 8 15 :02 :55 MET DST1997

make[1] : Entering directory ‘/var/yp/familles’

4Eventuellement aidee de quelques scripts shell de mise en forme.

17

Updating netgroup...

Updating netgroup.byhost...

Updating netgroup.byuser...

make[1] : Leaving directory ‘/var/yp/familles’

NIS Map update completed.

gruyere#

Attention, ce scenario peut varier legerement, dans sa forme, d’un systeme al’autre.

8.2 Transfert de tablesLes tables NIS peuvent etre transferees explicitement depuis le serveur maıtre

vers les serveurs esclaves, un tel transfert peut avoir lieu a l’initiative :– du serveur maıtre, avec la commande yppush qui transfere une table a tous

les serveurs esclaves, en general pour la propagation d’une table recemmentmise a jour,

– du serveur esclave, grace a la commande ypxfr qui recupere une table de-puis le serveur maıtre, si elle y a ete modifiee depuis le dernier transfert. Cemecanisme est en general utilise pour les transferts periodiques de tables, parexemple pour pallier a une eventuelle panne d’un serveur esclave durant ledernier transfert effectue a l’initiative du serveur maıtre.

8.3 Changement de serveur maıtrePar mesure de securite, les tables NIS ne peuvent pas etre propagees par n’im-

porte quelle machine. Seul le serveur maıtre possede cette autorite. De ce fait, maisegalement du fait du format particulier des bases de donnees DBM, le changementde serveur maıtre est une operation delicate a realiser. La methode a adopter est lasuivante :

Initialisation du nouveau serveur maıtre. Le transfert des tables ne doit cepen-dant pas encore etre effectue. Une fois cette initialisation faite, on transfere sur cenouveau serveur maıtre les fichiers sources des tables, grace a une commande telleque ftp ou rcp. Il est bien important de ne pas transferer les fichiers DBM.

Construction des tables. Sur le nouveau serveur maıtre, les tables doivent etrecompilees, mais sans etre propagees, car le nouveau serveur n’a pas encore cetteautorite (pour les serveurs esclaves, ce n’est pas encore lui le maıtre) :

nouveau# cd /var/ypnouveau# make -DNOPUSH

Propagation des nouvelles tables. Les nouvelles tables ainsi construites doiventmaintenant etre transferees aux serveurs esclaves. Seul l’ancien maıtre a cette au-torite, aussi faut-il dans un premier temps transferer les tables depuis le nouveauserveur maıtre vers l’ancien, grace a la commande ypxfr, executer sur l’ancien ser-veur, puis transferer ces nouvelles tables aux serveurs esclaves par la commandeyppush. Le tout peut etre effectue sur l’ensemble des tables grace, par exemple,aux commandes suivantes5 :

5Nous supposons ici que le shell utilise par l’utilisateur est un C-shell.

18

ancien# foreach map (passwd.bynam passwd.byuid ... )foreach � ypxfr -h nouveau -f mapforeach � yppush mapforeach � endancien#

Autre methode La methode de changement de serveur maıtre que je viens dedecrire est la methode ”ideale”. Elle n’est malheureusement pas toujours appli-cable, par exemple si le serveur maıtre est hors service.

Une autre solution consiste alors a initialiser le nouveau serveur maıtre puisa faire le tour des serveurs esclaves en y relancant la commande ypinit avec lenom du nouveau serveur maıtre.

9 Choix des domaines et des serveursLe nombre de domaines NIS depend de nombreux parametres, parmis lesquels :– Le nombre de reseaux physiques et leur interconnection. Il peut en effet etre

interessant de minimiser les transfert d’un reseau a l’autre.– Le nombre d’administrateurs impliques dans la gestion du reseau. Si chacun

a un sous-reseau a administrer, les domaines NIS peuvent refleter ce partage.– Le nombre de departements ou de laboratoires concernes. Ils peuvent avoir

des besoins differents ainsi que de nombreuses ressources non communes.– Le nombre de reseaux locaux sur lesquels s’etend le domaine concerne. En

effet, lorsque l’on utilise NIS dans sa configuration originale (celle de SunOS,par exemple), le demon ypbind cherche un serveur grace au mecanisme debroadcast fournit par le reseau local sous-jacent. Il est alors necessaire d’avoirau moins un serveur (maıtre ou esclave) par reseau local. Il reste cependantpossible d’eviter le mecanisme de broadcast grace a la commande ypset ;cette contrainte est alors levee.

Differents domaines peuvent cependant partager certaines tables. Cela dit, lagestion d’une telle configuration peut relever de la haute voltige et n’est que rare-ment necessaire, on tachera donc de l’eviter . . .

10 Specificites de certains systemesL’ensemble de ce document est globalement vrai pour la majorite des systemes.

Certains systemes presentent cependant quelques caracteristiques propres et differentdonc sur certains points de ce que j’ai dit plus haut.

Ainsi, sur certains systemes, tels que Solaris, il est possible de gerer de faconbeaucoup plus fine les tables NIS.

D’autres systemes ne necessitent pas la modification des fichiers locaux deconfiguration des differents services (mots de passe, noms des machines, ...) pourvalider ou non l’utilisation de NIS.

10.1 Le fichier nsswitch.confSur certains systemes, la configuration de l’utilisation de NIS par les machines

clientes est parametree par le fichier /etc/nsswitch.conf.Citons parmis ces systemes Solaris et Linux, lorsqu’il est utilise avec l’environ-

nement NYS.

19

Le fichier nsswitch.conf permet de choisir, pour chaque base de donnees(fichier des mots de passe, des noms de machines, . . .) les services a mettre enœuvre et dans quel ordre.

Il s’agit d’un fichier texte oriente ligne ou chaque ligne definie la procedure amettre en œuvre pour satisfaire une requete visant une base de donnnee choisie.

Exemple. Voici un exemple d’une partie de fichier nsswitch.confpasswd: files nisplus nishosts: files nis [NOTFOUND=return] dns nisplusservices: nisplus [NOTFOUND=return] filesautomount: files nisplusaliases: files nisplus

Comme vous le voyez, la syntaxe est simple. Chaque ligne commence par lenom de la base de donnees concernee, suivi de ” :” puis de la liste des sources autiliser, dans l’ordre voulu.

Exemple. Ainsi, dans le cadre de l’exemple precedent, un mot de passe (basede donnees passwd) sera d’abord cherche dans le fichier /etc/passwd lo-cal, puis via une requete a un serveur NIS+ et enfin via une requete a unserveur NIS.

Notez cependant qu’apres une source peuvent figurer, entre crochets, une listede couples RESULTAT=action separes par des espaces. Ceci permet de parametrerplus finement encore le comportement du systeme.

Exemple. Ainsi, dans la cas de la recherche d’un nom de machine (base dedonnees hosts), si le serveur NIS ne trouve pas la reponse a la requete (NOTFOUND), cette requete est abandonnee a ce point (return), sans utiliser lesautres mecanismes (dns puis nisplus).En revanche, si aucun serveur NIS n’est trouve, ces autres mecanismes serontutilises.

Le tableau 4 donne la liste des resultats possibles pour une recherche.

Resultat SignificationNOTFOUND La source n’a pas pu satisfaire la requeteSUCCESS La requete a pu etre satisfaite

TRYAGAIN La source est occupee et n’a pu repondreUNAVAIL La source n’est pas disponible

TAB. 4 – Les differents resultats acceptables dans nsswitch.conf

Le tableau 5 donne quant a lui la liste des actions que l’on peut appliquer enfonction du resultat fournit par une source. Par defaut, le systeme applique l’actionreturn pour le resultat SUCCESS et l’action continue pour tous les autres.

Action Consequencecontinue Utiliser la prochaine source de la listereturn Retourner le resultat

TAB. 5 – Actions acceptables dans nsswitch.conf

Enfin, le tableau 6 donne la liste des bases de donnees que le fichier nsswit-ch.conf permet d’aiguiller entre les bases de donnees locales (fichier passwd etautres), les tables NIS et eventuellement d’autres services.

20

aliases automount bootparams ethers grouphosts netgroup netmasks networks passwd

protocols publickey rpc sendmailvars servicesshadows6

TAB. 6 – Les bases de sonnees aiguillables par nsswitch.conf

10.2 Le systeme LinuxLes utilisateurs du systeme Linux ont la joie et l’avantage d’avoir a leur dis-

position deux implementations de NIS differentes, il est alors important de savoirquelle est l’implementation utilisee afin de ne pas se melanger les pinceaux.

Nous appelerons NIS standard la “premiere” version, ou simplement NIS si celane prete pas a confusion. L’autre version, plus recente, s’appelle NYS.

Suivant la distribution choisie pour installer votre systeme, vous pouvez doncvous retrouver en presence de l’une ou de l’autre de ces versions. Vous pouvezalors eventuellement choisir de changer de version, si cela vous chante.

Les differences entre les deux versions sont essentiellement de l’ordre de lasouplesse de configuration et de la stabilite.

La version standard est plus vieille et plus stable, elle s’administre simplement,pour l’essentiel comme je l’ai decrit dans ce document, avec les avantages et lesinconvenients que cela implique.

Le systeme NYS est, a l’heure actuelle, un peu moins stable, mais l’auteur s’estdonne un but plus large, qui est d’integrer NIS et NIS+. Ce systeme est donc pluspuissant que la version standard, et plus souple a configurer. Il utilise le fichiernsswitch.conf.

Une autre difference, qui peut se reveler determinante, est que, pour le mo-ment, le code compile dans la librairie C standard est celui du NIS traditionnel.L’utilisation de NYS risque donc de necessiter de nombreuses recompilations.

10.3 Linux avec NIS

Le systeme NIS traditionnel sur Linux presente quelques originalites par rap-port a ce que j’ai dit dans ce document. Regardons-les brievement.

10.3.1 Le client

Sur le client, le fichier /etc/yp.conf permet de parametrer la recherche d’unserveur de facon a eviter le mecanisme de broadcast relativement dangereux si lereseau local n’est pas sur.

Le fichier yp.conf est un fichier texte oriente ligne relativement simple. Troistypes d’entrees sont possibles.

Exemple. Voici a quoi peut ressembler un fichier yp.conf :

domain yp-dupond server crepedomain yp-durant broadcastypserver gloubiboulga-f

Un tel fichier serit par exemple celui de la machine emental en supposantque nos deux familles aient, en plus du domaine NIS familles deja decrit,deux domaines yp-durant et yp-dupond.

Les trois types d’entrees sont les suivantes :

21

domain <nom-domaine> server <nom-serveur> pour preciser quel serveurcontacter pour les requetes concernant un domaine.

domain <nom-domaine> broadcast pour preciser a ypbindd’utiliser le mecanismede broadcast pour le domaine indique.

ypserver <nom-serveur> pour preciser le nom du serveur a contacter pour ledomaine par defaut.

Remarque : Notons de plus que les fichiers passwd et groups n’ontdesormais plus besoin de contenir une ligne commencant par un ”+”pour valider l’utilisation de NIS.

10.3.2 Le serveur

Il existe un serveur NIS disponible pour Linux, il s’appelle yps et est l’œuvrede Tobias Reber. C’est cependant generalement le serveur de NYS qui est utilisesur Linux lorsqu’un serveur est necessaire, et ce du fait de sa souplesse.

10.4 Linux avec NYS

NYS est la creation de Peter Eriksson ; il s’agit d’une librairie et d’un ensemblede programmes permettant d’integrer une machine Linux ou autre dans un do-maine NIS ou NIS+.

Ce systeme est tres souple et tres puissant mais encore en cours de developpement.On en utilise tres souvent le serveur, qui est certainement le meilleur actuellementdisponible sous Linux, plus rarement le client, qui necessite souvent des modifica-tions de librairies ou/et des recompilations de programmes.

10.4.1 Le client

La configuration des clients bases sur le systeme NYS utilise le fichier /etc/ns-switch.conf. Je vous invite donc a vous referer a cette section.�

Le code client de NYS ne prend pas encore en compte, a l’heure actuelle, latable netgroup, ceci ne sera cependant peut-etre plus vrai avec la version

que vous utiliserez, verifiez donc dans la documentation.

10.4.2 Le serveur

Sur un serveur, le fichier /etc/ypserv.conf permet de parametrer le com-portement du serveur et d’introduire dans ce dernier quelques mecanismes desecurite.

22

A Resume des principales commandesVoici un bref resume des differentes commandes directement liees a l’utilisation

ou a l’administration de NIS, avec leur localisation pour les systeme SunOS 4.1.3,Solaris, Linux, Irix et AIX :

domainname permet de consulter ou de positionner le nom du domaine. Locali-sation :– SunOS 4.1.3 /bin/domainname– Solaris /bin/domainname– Linux /bin/domainname– AIX /usr/bin/domainname– Irix /usr/bin/domainname

makedbm Permet de construire les tables en fonction de leurs fichiers sources. Lo-calisation :– SunOS 4.1.3 /usr/etc/yp/makedbm– Solaris /usr/sbin/makedbm– Linux /usr/lib/yp/makedbm– AIX /usr/sbin/makedbm– Irix /usr/sbin/makedbm

ypbind permet aux clients de trouver un serveur NIS. Localisation :– SunOS 4.1.3 /usr/etc/ypbind– Solaris /usr/lib/netsvc/yp/ypbind– Linux /usr/sbin/ypbind– AIX /usr/etc/ypbind– Irix /usr/etc/ypbind

ypcat permet de consulter le contenu des tables. Localisation :– SunOS 4.1.3 /bin/ypcat– Solaris /usr/bin/ypcat– Linux /usr/bin/ypcat– AIX /usr/bin/ypcat– Irix /usr/bin/ypcat

ypinit permet l’initialisation des serveurs NIS, qu’ils soient maıtre ou esclaves.Localisation :– SunOS 4.1.3 /usr/etc/yp/ypinit– Solaris /usr/sbin/ypinit– Linux /usr/lib/yp/ypinit– AIX /usr/sbin/ypinit– Irix /var/yp/ypinit

ypmatch permet de chercher dans une table NIS des entrees en fonction d’une ouplusieurs clefs. Localisation :– SunOS 4.1.3 /bin/ypmatch– Solaris /usr/bin/ypmatch– Linux /usr/bin/ypmatch– AIX /usr/bin/ypmatch– Irix /usr/bin/ypmatch

yppasswd permet a un utilisateur de changer son mot de passe dans les tablesNIS. Cette commmande est en voie de disparition, du fait de l’integration decette fonctionalite directement dans la librairie C. La commande tradition-nelle passwd remplit donc desormais souvent ce role. Localisation :– SunOS 4.1.3 /bin/yppasswd– Solaris /usr/bin/yppasswd– Linux /usr/bin/yppasswd

23

– AIX /usr/bin/yppasswd– Irix /usr/bin/yppasswd

ypchfn permet de changer le champs commentaire d’une entree dans les tablesNIS des mots de passe, ici aussi, la commande chfn remplit generalement lerole. Localisation :– SunOS 4.1.3 /usr/bin/chfn– Solaris /usr/bin/yppasswd -r nis -g– Linux /usr/bin/ypchfn– AIX /usr/bin/chfn

ypchsh permet de changer le champs shell d’une entree dans les tables NIS desmots de passes. Encore une fois, la commande chsh est souvent utilisee pourca. Localisation :– SunOS 4.1.3 /usr/bin/chsh– Solaris /usr/bin/yppasswd -r nis -e– Linux /usr/bin/ypchsh– AIX /usr/bin/chsh

yppoll permet d’obtenir le numero d’ordre d’une table NIS ainsi que le nom duserveur maıtre de cette table. Localisation :– SunOS 4.1.3 /usr/etc/yp/yppoll– Solaris /usr/sbin/yppoll– Linux /usr/sbin/yppoll– AIX /usr/sbin/yppoll– Irix /usr/sbin/yppoll

yppush permet de forcer la propagation des tables NIS depuis le serveur maıtre,par exemple en cas de mise a jour d’une de ces tables. Cette commande estgeneralement invoquee automatiquement par la commande make lors de laregeneration des tables en fonction des fichiers sources. Localisation :– SunOS 4.1.3 /usr/etc/yp/yppush– Linux /usr/sbin/yppush– AIX /usr/sbin/yppush– Irix /usr/sbin/yppush

ypserv est le demon des serveurs NIS aussi bien pour les serveurs esclaves quepour le serveur maıtre. Localisation :– SunOS 4.1.3 /usr/etc/ypserv– Solaris– Linux /usr/sbin/ypserv– AIX /usr/etc/ypserv– Irix /usr/etc/ypserv

ypset permet, sur un client, de specifier le serveur a contacter pour les requetesNIS, afin d’eviter d’utiliser le mecanisme de broadcast utilise par ypbind. Lo-calisation :– SunOS 4.1.3 /usr/etc/yp/ypset– Solaris /usr/sbin/ypset– Linux /usr/sbin/ypset– AIX /usr/sbin/ypset– Irix /usr/sbin/ypset

ypwhich permet, sur un client, de connaitre le serveur NIS utilise par ce client, quece serveur ait ete decouvert par ypbind ou specifie par ypset. Localisation :– SunOS 4.1.3 /bin/ypwhich– Solaris /usr/bin/ypwhich– Linux /usr/bin/ypwhich– AIX /usr/bin/ypwhich

24

– Irix /usr/bin/ypwhichypxfr permet de recuperer une ou plusieurs tables depuis un serveur, pour mettre

a jour ces tables sur un serveur esclave par exemple. Localisation :– SunOS 4.1.3 /usr/etc/yp/ypxfr– Solaris– Linux /usr/lib/yp/ypxfr– AIX /usr/sbin/ypxfr– Irix /usr/sbin/ypxfr

ypchpass est une commande specifique au systeme Irix. Elle permet de modifiersur un client et de facon interactive (grace a un editeur) les champs d’uneentree dans les tables passwd. Le serveur maıtre doit pour cela etre une sta-tion sous IRIX. Localisation : /usr/bin/ypchpass

25

Index/etc/aliases, 6/etc/bootparams, 6/etc/ethers, 6/etc/group, 6/etc/hosts, 6/etc/netgroup, 6/etc/netmasks, 6/etc/networks, 6/etc/nsswitch.conf, 19–20/etc/passwd, 6/etc/protocols, 6/etc/resolv.conf, 16/etc/rpc, 6/etc/services, 6/etc/yp.conf, 21–22/etc/ypserv.conf, 22chfn, 24chsh, 24domainname, 7–9, 23makedbm, 23ypbind, 9–10, 19, 21–23ypcat, 11–12, 23ypchfn, 24ypchpass, 25ypchsh, 24ypinit, 8–9, 23ypmatch, 23yppasswdd, 12yppasswd, 12, 23yppoll, 24yppush, 24ypserv, 9, 22, 24ypset, 9–10, 24ypwhich, 24ypxfr, 25/etc/resolv.conf, 16/var/yp/Makefile, 16, 17

Broadcast, 10, 21Buts de NIS, 3

Client, 9–10Liaison avec un serveur, 9–10Nom de domaine, 9

Contexte des exemples, 4

Domaines, 19

Fichiers geres par NIS, 6

Introduction, 3–4

Lien avec le DNS, 15–16

Modele client-serveur, 5–6Modification des tables, 7

Ouverture du systeme, 7

Principe de NIS, 7Principes de NIS, 5Prise en compte de NIS, 10–16

Serveur esclave, 9Initialisation, 9Nom de domaine, 9

Serveur maıtre, 7–9Changement, 18–19Initialisation, 8Lancement, 9Nom de domaine, 7–8

Tables, 10–16hosts.byaddr, 15–16hosts.byname, 15–16netgroup, 22passwd.byname, 12–15passwd.byuid, 12–15Consultation, 11–12Format, 16–17Maintenance, 17–19Mise a jour, 17–18Mots de passe, 12–15

Exemples, 13–15Mise en œuvre, 12–13

Netgroup, 10–12Exemples, 10–11Syntaxe, 10

Noms de machines, 15–16Transfert, 18

Terminologie, 6

26