Chapitre 1 : Serveurs UNIX/Linux

1.1 Introduction.

1.1.1 UNIX/Linux : historique

UNIX est un système d'exploitation fonctionnant sur divers processeurs : Sun Sparc, DEC Alpha,
PowerPC IBM …et aussi sur PC et compatibles Intel (Linux et FreeBSD)
Il est entièrement multitâche préemptif et multi-utilisateurs.

Partant d'un base de développement commune dans les année 1970, il est apparu deux familles
initiales d'UNIX :
une libre d'origine universitaire BSD (Berkeley Software Distribution) avec diffusion des sources
une dépendant d'ATT : System V

Quoi qu'il en soit au fur et à mesure des versions des parties de code ont été échangées, conduisant
à des systèmes proches mais pas tout à fait compatibles.

Dans les années 1990, en parallèle avec des versions propriétaires (AIX d'IBM, HPUX de HP,
Solaris de SUN), des versions libres ont été développées : GNULinux, repartant d'une base de
codes différente, et des versions basées sur BSD : NetBSD, OpenBSD et FreeBSD pour une
architecture PC.

1.1.2 GNU/Linux

Les distributions Linux sont exemptes de droits d'utilisation. Le code source est livré et
« recompilable ». Il est donc complètement indépendant des éditeurs de logiciel.

Différentes distributions sont proposées : Red Hat, Caldera, Debian, Suse, Ubuntu... avec plus ou
moins de variantes. Elles se distinguent par la méthode de distribution (les paquets), par les
utilitaires d'installation et par la configuration initiale.
Les distributions sont toutes basées sur un noyau Linux commun dont la version est repérée par une
suite de 3 nombres : X.YY.ZZ (actuellement 4,4 pour la dernière version)
Exemple : 2.0.34

1
Elles proposent un certain nombre d'applications, en particulier plusieurs environnements
graphiques (gnome et kde) permettant un usage identique à Windows.

Le type de distribution libre conduit à un inconvénient pour l'utilisateur : aucun service après vente
n'est disponible, quoi qu'il en soit la communauté Linux sur Internet est très active et il est des fois
plus rapide d'obtenir une solution à son problème qu'avec un vrai SAV. Dans les versions plus
anciennes, la prise en charge de certains périphériques récents n'était pas possible, cette partie étant
souvent laissée au bon soin du fabricant de périphériques (qui ne voulait pas distribuer son code),
ceci est beaucoup moins sensible actuellement.

Des entreprises proposent des versions payantes car elles y ont inclus des services supplémentaires
dont l'aide à l'installation ou des fonctionnalités propres dans la gestion. C'était le cas de Novell qui
est passé d'un système d'exploitation serveur propriétaire à une implémentation de Linux Suse. De
même dans le domaine des stations de travail,

1.1.3 BSD
Dans le même ordre d'idée, la branche universitaire d'UNIX a continué d'exister via des projets de
même type que Linux. Si Linux est plutôt sur le segment (mais pas exclusivement) des postes de
travail, les dérivés de BSD se positionnent plutôt dans le domaine des serveurs avec une fiabilité
importante. FreeBSD, OpenBSD, NetBSD sont les 3 distributions qui tiennent la plus grande part
de marché. Des versions commerciales dérivées existent aussi : Apple propose sur ses ordinateurs
un système commercial dérivé de UNIX BSD : Mac OS X.

1.1.4 Caractéristiques

Contrairement à Windows, UNIX/Linux est naturellement un SE serveur dès ses versions initiales.
Il possède depuis de nombreuses années un accès réseau natif basé sur TCP/IP, une gestion des
utilisateurs cohérente, des mécanismes de partage de ressources fiables.

Il a servi de base sous une version propriétaire à des serveurs de type MainFrame constructeur
(exemples : AIX d’IBM, HPUX, Solaris). Il reste une référence dans ce domaine.
Il est très répandu sous une version libre pour de plus petits serveurs et même sur de plus grosses
machines depuis quelques années. Linux représente plus de 25% de part de marché (part évaluée
avec, bien entendu, les versions payantes). Pour mémoire Windows Server est autour de 50%, mais
tout cela en valeur. Il est plus difficile d'avoir une estimation en nombre sur des distributions
libres !

1.2 Structure du système d'exploitation UNIX

1.2.1 Structure du système de fichiers UNIX

Sa structure logique est basée sur plusieurs partitions d'un disque. Il comprend au minimum 2
partitions :
une partition principale montée sur le répertoire racine (/) contenant tout le système de fichiers.
Une partition de swap (mémoire virtuelle) : non directement accessible par l’utilisateur

2
La taille de la partition de mémoire virtuelle doit être au minimum supérieure à la taille de la
mémoire physique (deux fois est plus confortable).
Couramment il y a plusieurs partitions supplémentaires, ce qui permet d'isoler les données
utilisateurs du système, ce qui est souhaitable lors d'une ré-installation du système. Ces partitions
apparaissent toutes dans l'arborescence complète. Elles sont montées sur le système de fichiers / à
des points de montage définis, par exemple :
– Les répertoires utilisateurs sont montés sous /home
– les fichiers du SE et des applications sous /usr
– Les fichiers variables du système d'exploitation sous /var …

Le choix de ce découpage se fait au moment de l'installation, il peut être modifié à la demande en

faisant des montages différents mais au prix d'un gaspillage de ressources (partitions rendues
inaccessibles), ce qui n'est pas souhaitable.

L'arborescence complète comprend à partir de / : répertoire racine

/home : répertoires utilisateurs
/usr : fichiers permettant l’exécution du SE et de certaines applications
/var : fichiers de tailles variables
/tmp : fichiers temporaires
/etc : fichiers de configuration
/export : fichiers exportés pour les serveurs
/dev : fichiers de périphériques, utilitaires
/bin : lien sur /usr/bin
/sbin : utilitaires de supervision

Il y a ensuite des découpages de 2ème niveau. Pour le répertoire /usr on trouve :

/usr/bin : commandes basiques
/usr/etc : commandes de maintenances
/usr/lib : librairies et diverses fonctions
/usr/local : logiciels installés en local
/usr/share : logiciels indépendants de la machine cible
/usr/kvm : logiciels dépendants de la machine cible
et bien d’autres suivant les SE

Concernant le répertoire utilisateur /home, on retrouve tous les répertoires utilisateur en 2ème
niveau :
Exemples : /home/jacquet ; /home/aubert... quoi qu'il en soit ce choix n'est qu'une convention la
position des répertoires utilisateur est totalement configurable.

Il faut bien prévoir une place suffisante pour chaque partition, car la modification de taille d'une
partition n'est pas disponible sur toutes les implémentations et n'est pas compatible d'un système à
un autre. Pour ne pas dégrader les performances, un taux de remplissage maximum de 80% est à
prévoir.

1.2.2 Contrôle du fonctionnement du SE et des applications.

Sous UNIX, beaucoup de commandes de configuration sont en fait des scripts. Ces commande sont
donc modifiables et peuvent différer suivant les distributions, c'est même une des principales
différences apparentes au moment du fonctionnement entre les distributions.

3
Les fichiers de configuration sous UNIX sont donc des fichiers texte éditables associés aux
applications. Leur syntaxe est précise et des fois complexe, voire pointilleuse. Il y a de nombreux
fichiers de configuration, souvent plusieurs par application. Des projets d'évolution vers une
configuration centralisée (type Windows) existent au grand désarroi des amateurs d'UNIX.
Hormis le chargement initial du noyau, tout le démarrage du système est aussi basé sur des fichiers
script de démarrage, de fait toutes les procédures de démarrage sont paramétrables.
Du fait de la modification de fichiers de script pour la configuration, il est souhaitable pour bien
maîtriser les changements de ne les effectuer que d'une seule manière et manuellement. La mise en
œuvre de modification via l'interface graphique, si elle peut se comprendre pour un système de type
poste de travail n'est pas à envisager pour un serveur, car les modifications par des menus ne
peuvent être maîtrisées par l'administrateur. C'est l'une des différences principales entre la gestion
d'un système Windows Server et celui d'UNIX. Pour l'un la facilité, pour l'autre la maîtrise...à
chacun de choisir.

1.3 Compte d'utilisateurs.

1.3.1 Utilisateurs et groupes

Principe
Il y a 2 catégories d’utilisateurs :
– des utilisateurs locaux de la machine
– des utilisateurs « réseaux » (par un service spécifique : NIS ou autre)

En local, il y a de nombreux utilisateurs et groupes prédéfinis :

– root (c’est l’administrateur)
– guest (invité) : souvent sans droit et mot de passe
– groupe et utilisateurs nobody (créé pour des raisons de sécurité)
– A cela s'ajoute des utilisateurs et des groupes spécifiques pour les applications, qui ont le même
usage que nobody, ils permettent au système, de faire fonctionner certaines applications sans avoir
les droits de root (ftp, gdm, bind …). Ce sont en général des comptes non accessibles via un
login.

Fichier de gestion des comptes utilisateurs

Les utilisateurs locaux sont stockés dans /etc/passwd.
C'est un fichier texte avec les droits d'écriture pour root, et de lecture tout le monde.
Une entrée du fichier se présente sous la forme :
Username:Password:ID_User:ID_Group:Information:User_Directory:Shell

Chaque utilisateur est repéré par un ID unique

Chaque utilisateur appartient à un groupe au minimum
Un répertoire est associé à l’utilisateur (on y va par la commande cd ~)
On peut choisir l’interpréteur de commande utilisé par défaut (Shell), car UNIX propose plusieurs
interpréteurs de commande (csh, Borne shell, ksh...).

Le mot de passe est crypté dans le fichier /etc/passwd. Mais le problème est que /etc/passwd est
accessible en lecture, ce qui est nécessaire pour connaître les utilisateurs. La découverte du mot de

4
passe est ainsi possible par cryptage et comparaison (force brute mais hors ligne donc indétectable).
Cela est d'autant facilité que la fonction de cryptage est fournie par le Système d ’Exploitation.

Les implémentations plus récentes utilisent un fichier /etc/shadow qui ne contient que les mots de
passe et qui donne une correspondance ligne à ligne avec le fichier /etc/passwd.
Chaque utilisateur a une entrée dans chaque fichier, mais le fichier /etc/shadow n'est lisible que par
root.

Fichier de gestion des groupes d'utilisateurs

Chaque utilisateur est membre d'un groupe au moins. L'intérêt étant de définir des droits d'accès
commun pour un ensemble d'utilisateurs. Les informations sur les groupes sont stockées dans
/etc/group sous le format suivant :

GroupName:Special_Field:ID_Group : Usernames of possible members

Exemple d'entrée du fichier /etc/group
Etud : :21:betty,baba,noel,quentin,sandra

Chaque groupe a un ID unique. Un utilisateur peut être présent dans plusieurs groupes. Son groupe
initial est celui défini dans /etc/passwd, mais il peut en changer et prendre un de ceux auxquels il
est associé dans le fichier /etc/group par la commande newgrp.

Méthodes de gestion des utilisateurs et des groupes.

Même si le résultat final se trouve dans les 3 fichiers précédents, il existe différentes méthodes pour
la gestion des utilisateurs et des groupes :
– Edition des fichiers,
– utilisation de commandes,
– utilisation de scripts,
– des applications avec l'interface graphique

L'édition manuelle des fichiers concernés, même si elle a été la méthode habituelle dans les
premières versions est à proscrire car trop risquée et surtout difficilement compatible avec le fichier
/etc/shadow.

En mode graphique le gestionnaire des utilisateurs permet cette gestion mais attention aux
modifications automatiques des fichiers, il y a risque de perte des modifications antérieures, et
souvent incompatibilité avec une autre méthode de modification.

La méthode conseillée est l'utilisation des différentes commandes :

useradd : commande création d’utilisateurs
userdel : commande suppression d'utilisateurs
groupadd : commande création de groupes
groupdel : commande suppression de groupes

Il existe de nombreuses options permettant de configurer tous les paramètres. Lors de la création de
plusieurs utilisateurs, il y a la possibilité de scripts spécifiques fait par l’administrateur à partir des
commandes précédentes.
Les scripts adduser, deluser, addgroup, delgroup sont aussi une autre possibilité, mais ils sont
spécifiques à Linux Debian et donc moins portables. Ils permettent d'écrire des scripts plus
complets.

5
1.3.2 Profils

Fidèle à la philosophie UNIX, les profils utilisateurs sont des fichiers script au format texte. Ces
fichiers sont stockés dans le répertoire utilisateur, il débute par un point (visible si seulement on
utilise l'option « a » dans ls -la). Des fichiers de configuration sont nécessaires pour chaque shell et
pour certaines applications.
Exemple de fichiers définissant le profil :
.Xdefaults, .bashrc, .kde, .kderc, .screenrc, .cshrc et une liste de fichiers dépendant des applications
utilisées (gestionnaire de fenêtres utilisé...).

A la création on peut recopier un profil par défaut stocké dans /etc/skel (Linux debian). Ce qui
permet d'avoir un profil utilisable dès la création.

Remarques : Fichiers script

Les scripts doivent avoir les droits d’exécution x, sinon il faut le lancer avec le shell. Par exemple
un script cshell se lance par « csh cmd » si cmd est le nom du fichier script.

La variable d'environnement PATH contient le chemin de recherche des exécutables. Si le chemin

« . » n’est pas présent, l’exécution dans le répertoire local ne se fait pas, il faut alors taper ./cmd.

Pour modifier la variable d'environnement PATH on utilise la commande set : set path= ....
La modification des variables d'environnement est locale au processus (celui qui gère la console).
Pour la rendre disponible depuis n'importe quelle fenêtre de commande, il faut l'exporter avec la
commande : export path

1.3.3 NIS (gestion centralisé des utilisateurs)

a) Introduction

NIS (Network Information System) est un annuaire répliqué. NIS a été introduit par SUN en 1985
(Yellow Pages (yp) à l'origine). Ce n'est pas un standard de l'Internet mais il a été largement utilisé
et le reste encore en environnement 100% UNIX.

L'objectif est de réduire le temps d'administration d'un parc de machines. NIS fournit des
informations à l'ensemble des machines connectées, il est à comparer à un domaine Windows basé
aussi sur un annuaire.
L'usage minimum est de simplifier la gestion des comptes, des mots de passe. Il suffit de créer un
nouvel utilisateur sur le serveur NIS pour que chaque machine client NIS ait accès aux informations
de login de cet utilisateur et puisse se connecter sur les machines raccordées au domaine. Le
fonctionnement est basé sur un échange physique via le réseau du contenu des tables. Par exemple,
les informations des utilisateurs définis sur le serveur (dans le fichier /etc/passwd) vont être
automatiquement recopiées sur chaque machine client NIS et venir compléter le fichier /etc/passwd
local lors de l'exécution.

Les informations susceptibles d'être distribuées via NIS sont entre autre :
– les noms de logins, mots de passe et répertoire d'ouverture de session (/etc/passwd)
– les renseignements de groupes d'utilisateurs (/etc/groups)

6
– les alias réseaux (/etc/hosts)
– et en fait toutes informations contenus dans les fichiers de configuration d'UNIX ayant un intérêt
en réseau

NIS est une base de données distribuée qui permet le partage d'informations système. Son
architecture est basée sur un découpage en domaines. Les clients sont rattachés à un domaine NIS
via un ou plusieurs serveurs NIS.

Domaine NIS
Un domaine NIS est constitué :
– d'un serveur NIS maître qui maintient les tables NIS (maps NIS : informations contenues dans la
base). NIS gère une base de données (format DBM) contenant les informations nécessaires (login,
password…).
– En option : un ou plusieurs serveurs NIS esclaves qui permettent de décharger le serveur principal
et procurent une meilleure résistance aux pannes et permet la maintenance en ligne. Le maître
réplique ses informations vers les serveurs esclaves.
– Des clients NIS qui peuvent interroger les serveurs maîtres ou esclaves. Les clients NIS se
connectent à la base de données pour récupérer les informations nécessaires (ypbind). Il y a
échange des données en clair.

Protocole NIS :
NIS est basé sur des protocoles de couche haute : protocole de couches « session », et
« présentation ». La couche session est réalisée avec les RPC (SUN-RPC) : Remote Procedure Call

Un démon est nécessaire au fonctionnement des RPC : rpc.portmap Le rôle de ce démon (daemon)
est de scruter les ports logiques de la machine et rediriger les paquets TCP/IP vers les bons services
c'est à dire des démons utilisés par les services de couche supérieure (NIS, NFS…).

Remarque : les serveurs standard basés sur les RPC sont lancés par inetd (démon généralement
lancé via un script au démarrage), il faut veiller à ce que portmap soit lancé avant inetd.

Mise en œuvre :
Il a 2 aspects à considérer :
– Coté serveur : il faut définir un domaine NIS, construire les bases de données dbm (makedbm ou
make), puis lancer le démon ypserv (serveur NIS).
– Coté client : au démarrage (avant authentification), il faut lancer la connexion sur le serveur NIS
(ypbind) du domaine. Dès que ypbind fonctionne, la machine devient un client NIS. Il y a
récupération des bases de données et authentification.

7
 /var/yp/makefile
domainname+ bases NIS
Base locale /var/yp/domain
/etc/passwd
/etc/group make
...
ypserv

NIS Serveur
ypbind
Client

Préalablement, il faut que les machines soient dans le même domaine (commande domainname ou
nisdomainname). Ensuite, Il faut alors que le serveur réponde, sinon la machine cliente est en
attente jusqu'à un timeout relativement long, puis login sur des utilisateurs locaux.

b) Configuration détaillée du serveur

1ère étape : Attribution d’un nom de domaine

L'attribution d’un nom de domaine se fait par commande « nisdomainname » ou ypdomainname
Cette étape doit se faire en premier car les tables seront stockées dans le répertoire :
/var/yp/« nom de domaine »
La liaison d'un client et d'un serveur se fait à l'intérieur d'un domaine, le choix du nom doit donc
être partagé entre les clients et le serveur.

2ème étape : Construction des bases de données NIS locales

La création des bases de données NIS (ou maps NIS) revient à faire une traduction de fichiers
locaux ayant vocation à être exportés vers des fichiers au format base de données de type dbm,
fichier à fichier.
Le choix des fichiers que l'on souhaite "publier" via NIS, se fait par modification d'un fichier de
type Makefile. Il faut ajouter les entrées appropriées dans /var/yp/Makefile.
La construction des tables NIS se fait par lancement de la commande make (ou makedbm) dans le
répertoir /var/yp (il utilise alors le fichier Makefile précédent qui est dans le répertoire courant).
Les bases sont construites sous /var/yp/nom_de_domain, on y retrouve chaque fichier traduit dans
un format différent. Il est utile de bien vérifier que cette traduction a eu lieu en listant ce répertoire
et en regardant les dates.

Concernant certains fichiers dont /etc/passwd et /etc/group, des contraintes sont définies dans le
Makefile et qui vont permettre de n'exporter que certains utilisateurs. On définit un UID et un GID
minimum pour que les entrées puissent être publiés (ce qui évite que les comptes systèmes dont
root soient exportés).

3ème étape : Configuration du serveur NIS

2 fichiers sont nécessaires à sa configuration :
– /var/yp/securenets (adresse des domaines vers lesquels NIS est autorisé)
– /etc/ypserv.conf (configuration de base du démon ypserv, liaison à un DNS)

8
4ème étape : Lancement du serveur NIS
En premier lieu, assurez-vous que le portmapper tourne (rpcinfo -p), puis lancez le serveur par la
commande : ypserv.
On peut lancer le serveur nis pour un domaine différent de celui du serveur par la commande :
ypserv -d

La commande rpcinfo - u localhost ypserv devrait alors répondre :

program 100004 version 2 ready and waiting

Vous pouvez aussi vérifier les potentiels messages d’erreur dans les fichiers log
(/var/log/daemon.log ou /var/log/syslog).

c) Lancement de NIS au démarrage du serveur

Les bases étant construites, si l'on veut lancer le serveur NIS au démarrage, il est nécessaire de
modifier les fichiers de démarrage pour cela. Sur un serveur Linux de type Debian, il faut créer ou
modifier un lien dans le répertoire de démarrage du niveau concerné (par exemple : /etc/rc2.d pour
un niveau 2), les liens commençant par Sxx (où xx est un nombre) font démarrer des services dans
l'ordre des xx. Les liens débutant par Kxx arrêtent des services dans l'ordre inverse. Ces liens
(symboliques) doivent pointer vers des fichiers script qui sont habituellement dans le répertoire
« /etc/init.d ». Cette méthode a été remplacée dans la dernière version par l'utilitaire « systemctl ».
On peut paramétrer le fichier concernant nis (/etc/init.d/nis) pour contrôler le démarrage du serveur.

d) Script d'initialisation lors d’un premier usage

Un utilitaire (script) nommé « ypinit » permet de s'affranchir des premières étapes. Et de simplifier
la gestion des serveurs esclaves.
Sur le serveur maître, lancer : /usr/lib/yp/ypinit -m
Le script va demander des informations pour la configuration (serveur esclave…) puis construire
les bases de données.
Sur un serveur esclave, lancer /usr/lib/yp/ypinit -s masterhost, il y a alors recopie automatique des
bases exportées par le serveur maître sur le serveur esclave par ypxfr.

e) Configuration et lancement du client

Le lancement du client se fait par la commande /usr/sbin/ypbind qui va lancer le démon de même
nom.
Le fichier de configuration de ypbind se nomme yp.conf
Dans ce fichier, on trouve le nom du serveur NIS :
ypserver monServeurNis ou ypserver 161.3.51.86

Il est impératif de tester manuellement le bon fonctionnement de ypbind avant de raccorder la

machine au domaine au démarrage.
On peut faire une vérification a posteriori du lancement via la commande ps -aux (liste des
processus). On peut aussi vérifier que tout s'est bien passé, en scrutant les ports rpc mappés (via
rpcinfo -p localhost), on trouve au minimum deux ports mappés pour ypbind :
100007 2 tcp 705 ypbind
100007 2 udp 708 ypbind
Signification : numéro du programme, version, protocole, port

9
Des utilitaires, se trouvant dans /usr/bin, vont permettre de tester le fonctionnement :
– ypwhich : donne l’identification du serveur NIS
– ypcat : affiche une table publiée du serveur
– ypmatch : vérifie manuellement qu’une clef est conforme
– yppasswd : modification d’une clef mot de passe sur le serveur à partir du client

Remarque : pour que ypbind fonctionne il faut que le répertoire /var/yp existe sur le client.

f) Configuration de l’authentification via NIS

Pour que l'authentification se fasse via les tables NIS il faut ajouter la ligne :
+: : : : : : : au fichier /etc/passwd des machines clientes

Cela revient à ajouter temporairement le fichier exporté /etc/passwd à celui existant en local (doù le
+, le nombre de « : » correspond à la syntaxe du fichier passwd.

Cela peut se faire de manière plus précise, par exemple, utilisation des logins NIS pour jack, le
groupe etud, pas de login autorisé pour l'utilisateur guest via NIS :
+jack:::::::
+@etud:::::::
-guest

On peut vérifier le bon fonctionnement de l'authentification, en effet, dès que ybbind fonctionne, la
machine est client NIS du domaine. Comme l'utilisateur est déjà logué, il faut utiliser un nouveau
login par la commande « su » qui va mettre en place une vérification sur /etc/passwd local puis une
vérification sur les tables (maps) publiées par le serveur NIS du domaine.

g) Exécution du client au démarrage de la machine

De la même manière que le serveur, il faut lancer le programme ypbind (daemon) au démarrage de
Linux. La méthode habituelle est la même que pour le serveur, il faut modifier le fichier de
démarrage dans le répertoire adapté : /etc/init.d/nis et le positionner en client. Il faut faire attention
à ce que tout fonctionne bien car lorsque NIS est démarré, le timeout à la connexion est très long si
le serveur ne répond pas, d'où la quasi obligation d'avoir un serveur esclave.

h) Configuration de la résolution de nom via NIS

On peut utiliser les fichiers /etc/hosts du serveur pour la résolution de nom du client. Il faut ajouter
nis dans la ligne host du fichier /etc/host.conf
Exemple hosts : files nis dns

i) Défauts des NIS

Il n'y a pas d'authentification des clients NIS : il suffit de connaître le nom de domaine pour
interroger le serveur et connaître le contenu de ses maps. On peut toutefois contrôler un peu la
sécurité par les fichiers de configuration du serveur. La sécurité minimum implique de ne pas
publier /etc/shadow car il y a transmission du fichier. Il ne faut mettre dans /etc/shadow que les
utilisateurs locaux.

10
Les maps sont transmises en totalité même en cas de faible modification de leurs contenus, ce
fonctionnement n'est pas adapté aux WAN car le trafic pourrait être important.
NIS est petit à petit remplacé par LDAP, cependant, les NIS sont encore largement utilisés dans les
domaines anciennement installés.

1.4 Ressources.
1.4.1 . Principes généraux.

a) Système de fichiers
Sous UNIX, la description des ressources se fait suivant une approche unifiée : toutes les ressources
sont vues extérieurement comme des fichiers.

Elles sont rassemblées dans un système de fichiers global de type arborescent. Il existe 4 types
d’objets dans l’arborescence du système de fichiers UNIX :
Les fichiers ordinaires
Les répertoires
Les liens
Les fichiers spéciaux ou fichiers de périphériques

Du fait de cette approche unifiée, un certain nombre de commandes permettent de gérer ces objets
de manière unique : ls (« listage »), rm (destruction), cp (copie), … Mais il faut faire attention à
l’usage de ces commandes et à leur résultat (effacer un périphérique de type disque peut avoir
certaines conséquences...).

Les 2 premiers types sont courants, il est toutefois nécessaire de rentrer un peu plus dans le détail
des 2 derniers.

b) Les liens
Ce sont des pointeurs vers d'autres fichiers (un peu comme les raccourcis Windows).
Toutefois il existe, sous UNIX, 2 types de liens :
Lien physique : fichier est effectivement effacé lorsque tous ses liens sont effacés. Tous les liens ont
mêmes propriétés que le fichier initial
Lien symbolique (c'est plutôt ceux-ci qui sont équivalents à un raccourci Windows). Dans ce cas, le
lien peut subsister même si le fichier est effacé. Ils sont très utilisés pour les scripts de démarrage et
pour les bibliothèques, car ils permettent de gérer des versions différentes sans changement des
scripts (par exemple gcc -compilateur C/C++- est un lien vers gcc-4.23 une version de ce
compilateur)

Création d'un lien

Lien physique : ln mainfile.txt tempfile.txt

Lien symbolique : ln -s monfichier monlien

11
c) Les fichiers de périphériques
Ce sont des fichiers spéciaux de 2 types :
type b : pour périphériques en mode « bloc » Exemples : disques, cdrom...
Type c : pour périphérique en mode « character » clavier, liaisons série...

En général ils sont contenus dans le répertoire /dev (devices). Ces fichiers permettent d'accéder
directement aux périphériques, dans ce cas l'usage en est délicat. En fait, ils sont plutôt destinés à
être montés sur un point du système de fichier, ce qui en est l'usage normal.

La commande mount permet de réaliser ce montage.

mount -t ext2 /dev/hda3 /mnt

Répertoire /dev
/dev/console : écran
/dev/fd : lecteurs de disquettes (/dev/fd0 pour a:)?
/dev/hd : disques dur IDE
/dev/hda1 : 1ère partition sur le premier disque maître
/dev/sd : disque dur SCSI
/dev/cdrom : cdrom !
/dev/tty : terminaux
/dev/ttyS : ports série (/dev/ttyS0 : COM1)?

Ils peuvent correspondre à des périphériques physiques ou logiques

Par exemple les partitions logiques du disque physique sd0 vont être : sd0a ; sd0b ; sd0c ;

On peut utiliser directement (mais avec beaucoup de précaution) ces périphériques. L'usage
habituel est de les monter à un nœud du système de fichiers.

d) Commande ls
La visualisation du contenu du système de fichiers se fait avec la commande ls :
en général avec des options : ls -la
Chaque entrée est affichée avec une présentation uniforme que ce soit un fichier, un répertoire ou
un lien :
-rw-r--r-- 1 jacquet prof 1283 feb 31 25:63 chap6.txt

1ère lettre : d (directory), l (link), - fichier, b/c (fichier spéciaux)

9 lettres suivantes : permissions rwx (lecture, écriture, exécution) pour user,group,all others
le nombre de liens physiques existants
le nom du propriétaire ; le groupe ; la taille ; la date ; le nom de l'élément

D'autres attributs peuvent se rajouter : bits SetGID/SetUID, sticky bit (dont nous verrons le sens
plus tard) ils sont visualisés à la place du bit d'exécution (s = s+x ; S = s mais pas x).

1.4.2 Autorisations.

a) Les autorisations de base

Les droits ou autorisations sur un objet Linux sont assez simples. Il y a 3 niveaux d'autorisations
avec 3 possibilités.

12
Les trois niveaux d'autorisation sont :
– propriétaire (o) pour owner
– groupe (g)
– tous les autres (a) all others (attention c'est bien tous les autres, ces permissions ne s'appliquent
donc pas aux deux précédents.

Pour chaque niveau, il y a trois spécifications :

r (read), w (write), x(execute)

Ces spécifications ont un sens seulement pour les fichiers. Pour les répertoires, les permissions
deviennent :
– r : autorisation de listing du répertoire (commande ls)
– w : autorisation de créer un fichier dans le répertoire, de l'effacer ou d'en modifier son nom : en
fait tous ce qui modifie l'aspect du répertoire lors d'un ls.
– x : autorisation d'ouvrir ce répertoire (commande cd).

Si l'utilisateur a un droit w sur un fichier, il peut le modifier mais pour l'effacer il faut qu'il ait les
droits w sur le répertoire.

Exemple : (obtenu par la commande ls)

drwx rwx rwx name1
-rwx --- --- name2
name1 : répertoire accessible en listing/modification/ouverture à tout le monde (owner+group+all
others)
name2 : fichier accessible en lecture/écriture/exécution à son seul propriétaire

b) Les attributs supplémentaires

Des attributs supplémentaires existent :

Les bits SetGID/SetUID : (lettre s ou S)

Ces attributs s'appliquent aux programmes exécutables (binaires, a priori pas aux scripts). Quand il
est positionné, il permet l'exécution du programme avec un niveau de droit de l'ID user (SetUID)
ou group (SetGID). En effet, il est parfois nécessaire de donner des droits temporaires plus élevés à
un utilisateur pour réaliser une opération particulière (un exemple courant est le programme de
montage /bin/mount : chaque utilisateur peut monter ses propres systèmes de fichiers mais
l'opération de montage intervient directement au niveau du système d'exploitation).
Ces bits sont positionnés en interne dans le champ des permissions d'un élément (9 bits sont utilisés
pour les autorisations), 3 autres vont être utilisés par ces nouveaux attributs.

Sur un répertoire le bit SetGID indique que les fichiers (ou répertoires) créés auront une
appartenance au groupe du répertoire et non au créateur.

Enfin un dernier attribut existe : le sticky bit ou bit collant (lettre T ou t) qui vient remplacer les
droits d'exécution des autres utilisateurs avec la même règle. Il va servir à contrôler l'effacement
des fichiers dans un répertoire. Si le répertoire possède cet attribut, les fichiers contenus à l'intérieur
ne peuvent être effacés (sauf par le propriétaire), mais ils peuvent être modifiés suivant les droits
donnés par les spécifications w. Il permet de gérer l'effacement ou la modification d'un fichier de
manière différente.
Lorsque ce bit s'applique à un fichier, il permet dans les anciennes versions de laisser ce programme
résidant en mémoire (les méthodes de gestion de la mémoire actuelles ne le nécessitent plus).

13
c) La modification des droits d’accès
Elle est réalisable par le propriétaire (ou par root) via la commande chmod :
Exemple :
chmod a+x fichier (exécution pour tout le monde)
syntaxe : chmod ([a] [g] [u] ) ([+] [-]) ([r][w][x]) filename

Usuellement, on utilise aussi une notation octale (pour faire plus pro !)

On traduit les droits d'accès en octal en considérant :

r=4, w=2, x=1
Exemples : -rwxrwxrw- : 0776 ; -rwx --- --- : 0700

Utilisation : chmod 777 fichier (changement des droits d'accès pour tous)

d) La modification du propriétaire ou du groupe

Elle s'exécute par la commande chown et seulement pour root (a priori l'utilisateur n'a plus le droit
de le faire pour ses fichiers (ce qui lui permettait de s'affranchir des quotas!) :
Exemple :
chown nouveau_propriétaire fichier : chown jacquet file.txt

De même pour la modification du groupe et la commande chgrp, celle-ci pouvant se faire aussi par
le propriétaire (s’il appartient au nouveau groupe) ou root.
chgrp new_group fichier : chgrp group1 file.txt

Le propriétaire n’est pas forcément membre initial du groupe du fichier.

1.4.3 Construction du système de fichiers.

Le système de fichiers d'un serveur sous UNIX est en général constitué de plusieurs partitions, ou
de plusieurs disques, voire réparti sur plusieurs machines. Afin de constituer l'entité unique qui est
le système de fichiers on va réalise une opération commune sous UNIX : le montage des ressources.

En fait, pour pouvoir être utilisée sous UNIX, une ressource, telle que une partition de disque, un
CDRom, une disquette, doit être raccordée sur la structure unique du système de fichiers. Cette
opération s'appelle un montage. C'est une de différence avec le fonctionnement de Windows où
toute nouvelle ressource sera associée à un nouveau lecteur (lettre avec:).

Une fois montée, la ressource ne se distingue pas du reste du système de fichiers, ce qui permet
d'avoir une gestion plus uniforme des ressources.

La commande pour réaliser ce montage est :

mount options périphérique « point de montage »

Options :
-t : type de montage (ext2, msdos, vfat, iso9660…)?

14
-w : monte la ressource avec autorisation rw
-r : monte la ressource avec autorisation lecture seule

Les fichiers déjà existants sous le point de montage seront masqués.

Exemple :
mount -t ext3 /dev/sd0b /mnt/test

Montage d'une partition /dev/sd0b au format ext3 au point de montage /mnt/test.

De nombreuses options existent, il faut regarder l'aide (commande man mount) pour connaître
celles utilisées sur le système concerné.

De la même manière que le montage, il faut libérer les ressources (les démonter) lorsque l'on ne les
utilise plus. Cela permet entre autre de fermer correctement tous les fichiers ouverts et de terminer
les transactions si il y en a en cours. Par exemple, on ne peut extraire (proprement) un CDROM ou
une disquette que si elle est démontée (cela est équivalent à retirer le périphérique de Windows
pour une clef USB). Il arrive même que des fois sur certaines stations de travail, il n’y ait pas de
boutons mécaniques d’extraction, seul le démontage éjecte le périphérique.

Usage :
umount unité | pointMontage

umount -a : démonte tous les systèmes de fichiers

umount -f fstype : démonte tous les systèmes du type spécifié (msdos, ntfs,hpfs, nfs, ....)

umount /dev/sd0b ou umount /mnt/test a le même effet pour l'exemple précédent.

Pour faciliter les montages courants, on les regroupe dans un fichier : le fichier fstab.
fstab contient les montages prédéfinis avant le démarrage, il peut être utilisé directement au
démarrage avec un mount -a qui exécute tous les montages spécifiés dans /etc/fstab. Cela est fait en
général au démarrage via un script.

Ce fichier peut être aussi utilisé pour ne pas avoir à taper toutes les options : si l'entrée sd0b reliée à
/mnt/test est dans ce fichier avec les bonnes options, il suffit de taper mount /mnt/test pour que le
reste soit fait automatiquement.

Le fichier mtab contient les montages actuellement réalisés. A chaque opération manuelle
mount/umount modifie le fichier mtab. Ceci permet d'avoir une vue instantanée des ressources
associées. Entre autre, avant l’arrêt d'une machine un script démonte tous les montages présents
dans mtab, d'où l'obligation d'arrêter une machine sous UNIX de manière correcte (commande
shutdown -h now par exemple).

1.4.4 NFS

a) Principe
Si l'on veut utiliser des ressources reliées par réseau, il faut utiliser un service spécifique : NFS
(Network File System).

15
Son objectif est de monter un système de fichiers à distance sur un réseau TCP/IP. L'intérêt étant de
bénéficier de disques durs d'autres machines comme si ils étaient locaux. D'un point de vue de
l'utilisateur, l'accès à une ressource distante est transparent. Le mécanisme de montage se fait de la
même manière que pour une ressource locale. Quoi qu'il en soit il faut qu'un service soit présent sur
le serveur pour mettre en place cette relation clients/serveur.

L'usage de NFS va nécessiter d'intervenir au niveau du serveur et du client. Sur le serveur, il faut
que le serveur possédant la ressource l'autorise à être monté par un système distant (cela s'appelle
exportation). Il faut aussi que le service NFS server soit activé. Au niveau du client, il faut que le
service NFS client soit activé et que celui-ci monte la ressource.

b) Opérations sur le serveur NFS

Etape 1 : autorisations d'exportation

Les autorisations d'exportation se font sur le serveur via le fichier /etc/exports. Il contient des lignes
qui vont définir les portions de son système de fichiers qui peuvent être exportées. Par exemple la
ligne :
/home istapc85.univ-st-etienne.fr (rw)
va permettre l'exportation en lecture écriture de /home au bénéfice de la machine istapc85

D'autres options sont possibles : ro (read only), de la même manière que pour la commande mount,
il faut taper l'aide (man exports) pour connaître toutes ces options.

Etape 2 : lancement du service

Il faut que plusieurs démons soient lancés (portmap et en général nfsd)

Pour être sur du bon lancement, on utilise un fichier script (exemple /etc/init.d/nfs-kernel-server
sous Linux) en fait un certain nombre de services sont lancés et on peut retrouver sur certains
systèmes tout un ensemble de démons :
rpc.statd : surveillance du trafic et gestion des erreurs NFS
rquotad : gestion des quotas utilisateurs
mountd : gestion du montage
nfs : interface utilisateur
nlockmgr : gestion des verrous NFS (lockd) qui empêche l’ouverture simultanée en écriture

Ces démons sont visibles par la commande ps aux.

Le démon NFS est contrôlé par plusieurs fichiers de configuration dont :

/etc/hosts.allow : machines autorisées à se connecter via nfs
/etc/hosts.deny : machines interdites de connexion
Le défaut est l'autorisation, c'est pour cela qu'une sécurité minimum consiste à remplir ces fichiers.

c) Opération sur le client

Etape 1 : lancement du service
Certains démons doivent aussi fonctionner sur le client (le portmapper et nfsd aussi). Le lancement
se fait aussi par un script (/etc/init.d/nfs-common). On peut visualiser les démons lancés avec la
commande ps aux.

16
Etape 2 : montage de la ressource

On peut utiliser un montage manuel avec l'option -t :

mount -t nfs istapc86:/home /mnt

Ou aussi mettre une entrée dans le fichier /etc/fstab pour un montage automatique :
istapc86:/home /home nfs timeo=20
syntaxe : nomHote:/fichier/système/chemin
La valeur timeo=n spécifie un timeout (ms) pour l'accès aux fichiers distants, elle est fondamentale
pour ne pas bloquer trop longtemps le client si le serveur ne répond pas.

d) Gestion des droits d’accès aux ressources partagées (exportées) :

La gestion des droits d'accès aux éléments contenus dans la ressource peut être assez complexe,
c'est pour cela qu'il est bon de préciser ce point là. Il y a trois niveaux de contrôle : au niveau de
NFS, au niveau du partage et au niveau des droits individuels sur l'élément. La complexité vient de
l'interaction entre ces 3 aspects lorsqu'ils sont tous utilisés.

1er niveau : les fichiers /etc/hosts.allow et hosts.deny vont permettre un contrôle global sur les
postes ayant droit.

2ème niveau : comme nous l'avons vu précédemment le contrôle de l'exportation se fait via le
fichier /etc/exports. Beaucoup d'éléments peuvent être contrôlés. En particulier, les machines ayant
une autorisation pour un partage donné, mais aussi les utilisateurs. Par exemple :
Pour les sous-réseaux (n° IP ou nom DNS)
/var/mail 192.168.3.0/24(ro)
Pour les groupes de postes
@group1 : défini dans /etc/netgroup
Pour les postes :
/tmp istapc32(rw)
Il existe des options permettant de limiter à certains utilisateurs pour un poste (avec le UID et le
GID)

3ème niveau : il concerne la gestion des droits d’accès aux éléments dans la ressources partagées :
En particulier chaque fichier ou répertoire a des autorisations. Elles sont données principalement
pour le propriétaire et le groupe. Il faut donc déterminer un UID et un GID lors d'un échange NFS.
Cela ne pose pas de problème de réalisation car NFS transmet l'UID et le GID du demandeur, mais
ceux-ci sont comparés avec l'UID et le GID de l'élément qui ne proviennent pas de la même
machine. Pour une gestion stricte, il faudrait qu’il y ait correspondance des UID et des GID entre
les machines (ce qui est le cas en fonctionnement NIS), quoi qu'il en soit la sécurité est limité à la
connaissance de ces 2 identifiants. En lecture, le problème n'est pas crucial, mais lors d'une écriture,
le fichier va appartenir à un utilisateur local du serveur qui lui doit correspondre à celui distant.
Quelquefois l'UID nobody est utilisé si il n'y a pas correspondance. De même, il y a un problème si
l'utilisateur distant est root, car il est forcément différent de celui du serveur pour des raisons de
sécurité. Un paramètre (root-squash) permet de contrôler les accès par un utilisateur root distant.

17
e) Cohabitation avec le DNS
Dans la version 4 de NFS, si le client DNS est activé, il y a une requête PTR pour trouver le
domaine du client. S'il n'existe pas de serveur DNS, NFS bloque pendant un temps supérieur au
timeout, un message d'erreur est alors généré (la demande ne peut être acceptée).

1.5 Administration
L'administration d'un système UNIX/Linux peut être assez complexe lorsqu'il est utilisé en tant que
serveur. Certaines distributions, orientées utilisateurs (Ubuntu…), masquent la complexité de cette
gestion, beaucoup de fonctions ont été automatisées et sont masquées à l'utilisateur, cette option
rend souvent plus complexe la gestion d'une machine UNIX/Linux en tant que serveur. De fait, un
minimum de choses doivent être connues par un administrateur de serveurs pour contrôler son
focntionnement.

1.5.1 Services
Dans les versions antérieures, les différents services étaient lancés par des scripts en langage shell
au démarrage de la machine (/etc/rc.local, scripts dans /etc/init.d par exemple) et permettaient un
contrôle fin et aisé par l'administrateur. Depuis les dernières versions de Linux, une gestion plus
automatisée est apparue (systemd). Elle rend plus complexe les modifications manuelles et oblige à
passer par des utilitaires pour configurer les services.
La commande systemctl rassemble la gestion des services au démarrage et en cours de
fonctionnement. Par exemple :
systemctl disable service désactive un service au démarrage
systemctl enable service active un service au démarrage
systemctl start/restart service active un service en cours de fonctionnement
systemctl stop service arrête un service en cours de fonctionnement

La configuration des services dépend de fichiers multiples dans le répertoire : /etc/systemd/system

Chaque service y est décrit entre autre par un fichier nom_du_service.service.

Ce nouveau mode de fonctionnement permet toutefois d'avoir des utilitaires d'analyse du

fonctionnement :
systemd-analyze blame ou systemd-analyze dump permet de visualiser la part de chaque process
dans le temps de démarrage.

1.5.2 Sauvegarde des données

Il existe un utilitaire (tar : tape archiver) simple, fiable, disponible sur tous les systèmes Unix. Il
permet de créer un fichier archive (équivalent d'un zip mais sans compression) contenant une partie
de l'arborescence. Il était adapté à la sauvegarde sur bandes, mais il est parfaitement utilisable
autrement.

tar option destination source

Options principales de tar :

18
c : crée une archive
x : extrait une archive
f fichier : crée ou lit une archive de nom fichier
Z : compacte ou décompacte l'archive
t : crée un index des fichiers de l'archive et l'affiche sur stdout

Exemple :
tar cvf /dev/fd0 /home : sauvegarde de home sur une disquette

1.5.3 Réseau.

La configuration réseau du réseau est un élément essentiel du bon fonctionnement d'un serveur sous
UNIX.
Le fonctionnement de TCP/IP est commandé par un ensemble de fichiers de configurations situé
dans /etc
/etc/hosts : associe nomMachines et adressesIP
/etc/networks : associe les noms de domaines à des classes d'adresse IP
/etc/network/interfaces : configure et active les interfaces Ethernet
Un daemon démarre ensuite les services réseaux bas niveau : /etc/inetd ou équivalent

a) Commande ifconfig
La commande ifconfig va permettre de configurer une interface individuelle. Le premier usage est
l'attribution d'une adresse IP à une interface.
ifconfig interface adresse_IP netmask masque

Exemple :
ifconfig eth0 161.3.51.81 netmask 255.255.255.0

On peut aussi afficher l'état de l'interface (Nb de packets émis, reçus, adresses...) en tapant :
ifcongih interface (ifconfig eth0 ou ifconfig -a pour toutes les interfaces)

En général, si il y a plusieurs cartes réseau sur un serveur, la 1ère carte réseau porte le nom eth0
(sous Debian), mais ce n'est pas toujours la même suivant la configuration (IRQ…) et les
caractéristiques. Le choix est fait à l'installation.

On peut activer ou désactiver une interface par la commande ifconfig interface up/down.

b) Fichier /etc/network/interfaces
Ce fichier contient les informations nécessaires pour la configuration du réseau lors du démarrage
du PC
Il contient pour chaque interface utilisée :
– Son adresse IP (ou la configuration auto en DHCP)
– Le masque
– L'adresse IP de la passerelle
– D'autres informations sur le fonctionnement du réseau

Des fichiers scripts sont aussi présents dans le même répertoire pour gérer les cartes réseaux

19
Attention, il y a risque d'interférence entre les configurations lorsque la configuration par menu
graphique du réseau est utilisée en alternance avec les commandes en ligne. Depuis les dernières
versions de Linux, un utilitaire "network-manager" permet de configurer le réseau de manière plus
obscure mais il présente l'avantage de pouvoir gérer des périphériques ajoutés en cours de
fonctionnement (clef USB Wifi...).

c) Fichier /etc/hosts
Il permet de définir une correspondance statique et locale entre nom de machines et adresses IP
Exemple
127.0.0.1 localhost
161.3.51.81 istapc81.univ-st-etienne.fr
En complément du DNS (ou NIS…) si le service est lancé

De même le fichier /etc/networks fournit une correspondance entre nom de domaines et adresses IP
Exemple :
localnet 127.0.0.0
univ-st-etienne.fr -c1 161.3.51 /*(-c1 : identifie le 1er sous réseau de classe C)*/

d) Programme route
Il permet de gérer les routes pour parvenir à certains réseaux.
– Suppression d'une route : route del
– Ajout d'une route : route add
– Affichage des routes : route

Pour une machine avec une carte réseau unique, il n'y a à définir qu'une passerelle par défaut :
route add default gw adresseIP_passerelle

Exemple : affichage de la table de routage IP

tpserver:/home/tpuser# route
Table de routage IP du noyau
Destination Passerelle GenMask Indic Metric Ref
Use Iface
10.2.0.0 * 255.255.255.0 U 0 0 0
eth0
default rout1.org 0.0.0.0 UG 0 0 0
eth0
tpserver:/home/tpuser#

e) Programme netstat
Sans argument : affichage des connexions réseau actives
-i : affiche les statistiques pour toutes les interfaces du réseau
-c : affiche l'état du réseau mis à jour toutes les secondes
Exemple de résultat de netstat -i :

20
tpserver:/home/tpuser# netstat -i
Table d'interfaces noyau
iface MTU Mst RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR
Flg
eth0 1500 0 128645 0 0 0 2508432 0 0 0
BMRJ
l0 16436 0 25689 0 0 0 123245 0 0 0 LRU
tpserver:/home/tpuser#

1.5.4 Surveillance

La surveillance du bon fonctionnement du serveur se fait via un ensemble de fichiers au format

texte qui sont situés dans le répertoire /var/log.
Les plus intéressants sont syslog, kern.log pour les processus généraux du système. Mais en fait se
rajoute à tous cela les fichiers spécifiques à chaque serveur d'application dans des fichiers à part ou
même des sous-répertoires supplémentaires style samba ou apache.

21
 TP N°4 : OptionRX1

1.6 TP4 : Configuration d'un Serveur UNIX

Objectifs du TP:
Installation et paramétrage d’un serveur de comptes et de fichiers sous Linux Debian.

Ressources nécessaires au TP
- Durant le TP, vous allez utiliser 3 PC sous Linux (un serveur et 2 clients) à configurer
avec l’adresse IP 10.20.N°poste.N°PC. Ils seront reliés par un switch.

Phase 1 : Configuration réseau des PC client et serveur sous UNIX

1. Configurer les adresses IP sur les 3 PC. Vérifier le bon fonctionnement par un ping.

Phase 2 : Configuration du PC serveur sous Linux Debian

1. Visualiser les fichiers /etc/group et /etc/passwd pour vérifier leur état initial (Aucun ID
supérieur ou égal à 2000).
2. Créer un groupe de nom tpgrp avec un GID = 2000 (commande groupadd). Vérifier la
bonne réalisation de cette commande.
3. Créer un répertoire utilisateur (tpuser1) sous le répertoire /home/tpreseau qui doit être
initialement vide (commande mkdir).
4. Créer un compte utilisateur (ID tpuser1 = 2001) : utiliser la commande useradd, positionner
cet utilisateur dans le groupe tpgrp. (Attention le script adduser fait le même genre
d’opérations mais n’est pas présent sur tous les UNIX). Visualiser le fichier /etc/passwd
pour en voir l’évolution. Le répertoire de démarrage doit correspondre à celui créé.
5. Copier les fichiers stockés (profils) dans /etc/skel dans le répertoire utilisateur.
6. Ajouter un mot de passe (tpuser1) au compte tpuser1 par la commande « passwd tpuser1 »
(attention ne pas changer le mot de passe de l’utilisateur root). Où ce mot de passe est-il
stocké ? Voir le fichier /etc/shadow.
7. Connecter-vous en tant qu’utilisateur tpuser1 (su tpuser1). Visualiser les fichiers présents
sur votre répertoire personnel (more …). Editer ces fichiers, que se passe-t-il ? Pourquoi ?
8. Essayer d’autoriser l’accès à l’un d’eux en changeant le propriétaire et le groupe
(commandes chown, chgrp). Que se passe-t-il ?
9. Reconnecter vous sur le terminal en root (su root), faire les modifications précédentes.
10. Modifier les droits d’écriture (en les donnant à tous le monde) sur un autre fichier
appartenant à root par la commande chmod. Vérifier en vous reconnectant en tpuser1.
11. Combien de shell avez-vous lancé, déconnectez-vous de ces scripts par la commande exit.
12. Réaliser un fichier script (fichier texte), reprenant toutes les commandes afin de faire les
mêmes opérations sur les deux autres utilisateurs (tpuser2, tpuser3). Vérifier le bon
fonctionnement du script en l’exécutant. Mettre le script sous /home/tpreseau.
13. Reconnecter vous en tpuser1 par l’interface graphique.

Phase 3 : Configuration du PC client sous Linux

1. Créer les mêmes répertoires et comptes que sur le serveur (utiliser un fichier script).

Phase 4 : Mettre en œuvre l’accès au fichier par partage

1. Vérifier par la commande rpcinfo – p, les services rpc disponibles sur la machine serveur et
client.

22
 2. Lancer les services nfs et portmap sur les machines s’ils ne le sont pas (/etc/init.d/nfs-
kernel-server). Avant cela créer un fichier /etc/exports contenant une ligne de commentaires
(début par #).
3. Refaire la commande rpcinfo. Visualiser aussi les ressources exportées par le serveur
showmount –e Ipserveur. Y en a-t-il ?
4. Autoriser l’exportation du système de fichier /home/tpuser1 (modification du fichier
/etc/exports). Redémarrer les services nfs pour prendre en compte la modification du fichier.
Vérifier la bonne exécution avec la commande showmount à partir du client.
5. Monter cette arborescence sur le client au point de montage /mnt/remote : commande
(mount –t nfs répertoire_distant répertoire_local) Pour le répertoire distant il faut préciser la
machine : 192.168.1.34:/home….
6. Essayer de modifier les fichiers du serveur à partir du client, vérifier les évolutions de part
et d’autre en créant de nouveaux sous-répertoires. Supprimer ce montage.
7. Pour mettre en place un vrai service de compte partagé pour un utilisateur, réaliser le
montage de /home/tpuser1 sur le même répertoire client. Comment cela est-il vu du côté
utilisateur. Faire la même chose pour les autres comptes. Quelle stratégie aurait été plus
simple à mettre en œuvre ?
8. Pour rendre permanent ce montage sur le client, modifier le fichier fstab en conséquence.
Démonter les montages actuels puis faire mount all (pour simuler un redémarrage de la
machine client).
9. En modifiant les paramètres de montage dans le fichier /etc/exports déterminer comment est
gérée l’authentification.
10. A l’aide de Wireshark, regarder les protocoles mis en oeuvre lors des échanges.

Phase 5 : Création de répertoires supplémentaires

1. Créer un répertoire accessible à tous les utilisateurs sous /home/tpreseau/partage
2. Créer un répertoire accessible au groupe tpuser uniquement sous /home/tpreseau/tpuser.

Phase 6 : Gestion centralisée des comptes

Afin de non seulement partager les ressources disques mais aussi de gérer de manière
centralisée les utilisateurs, nous allons utiliser un service rpc appelé NIS (ou yp yellow page)
1. Définir un nom de domaine pour le serveur (domainname istase.net) (fichier
/etc/defaultdomain).
2. Construire les tables nis via un make dans le répertoire /var/yp.
3. Visualiser le contenu du fichier Makefile, quelles tables ont été construites ?.
4. Paramétrer les différents fichiers pour le serveur (définir les caractéristiques du serveur via
les fichiers /etc/ypserv.conf et ypserv.securenets). Il y a peu de modifications (voire pas).
5. Lancer manuellement le démon nis par la commande ypserv.
6. Vérifier que le service nis est lancé par la présence des démons nécessaires.
7. Lancer le client après l'avoir configuré. Vérifier le lancement.
8. Tester le service nis, le serveur doit bien répondre et les tables peuvent être lues, en utilisant
les utilitaires ypwhich, ypcat, ypmatch.
9. Supprimer les utilisateurs sur la machine client. Editer les fichiers :
/etc/passwd : ajouter la ligne suivante à la fin : + : : : : : :
/etc/group : ajouter la ligne suivante à la fin + : : :
/etc/shadow (si utilisé) : ajouter la ligne + : : : : : : : :
(Attention ne jamais supprimer la ligne de l’utilisateur root ni les lignes des
utilisateurs prédéfinis)
10. Tester une connexion sur le client via un su user, user étant un utilisateur nis défini sur le
serveur.

23
 11. Comment faut-il faire pour que l'authentification nis se fasse au démarrage ? Connectez-
vous sur le PC client avec un compte défini sur le serveur.
12. Reconstruire les tables par la commande /usr/lib/yp/ypinit –m. Vérifier préalablement la
présence d’un fichier /etc/network.
13. Lancer le serveur par le script global (/etc/init.d/nis). Que se passe-t-il ?
14. Vérifier que le service nis répond bien et que les tables peuvent être lues.

Phase 7 : Désinstallation (Phase obligatoire)

1. Sauvegarder les configurations que vous avez modifiées. Vous devez être capable à la fin du
TP de reconstruire toutes les configurations très rapidement. Pour cela vous devez
sauvegarder les fichiers de configurations modifiés ainsi que créer les scripts nécessaires
pour reconstruire les modifications que vous avez effectuées.
2. ATTENTION : le service NIS ayant un timeout très long au démarrage, vous devez le
désactiver pour la suite des TP.

24