2. Principes de base

Dans cette configuration les clients utilisent le système de fichiers racine du serveur. Ils y accèdent bien sûr en lecture seule.

2.1 Les choses ne peuvent pas être aussi simples...

Quelques problèmes apparaissent rapidement.

Chaque station a besoin de sa propre copie d'un certain nombre de répertoires

Une configuration linux doit avoir les accès en écriture sur les répertoires suivants :

1. /dev
2. /var
3. /tmp

Il y a trois solutions, l'une d'elles ne fonctionnant que pour /dev :

1. utiliser (monter) un ramdisk et remplir celui-ci par extraction d'une archive ou copie depuis un répertoire modèle.
   • avantages :
     1. nettoyé à chaque reboot (suppression des fichiers tmp et log). Pas de maintenance.
     2. ne prend pas de place sur le serveur et ne génère pas de trafic réseau. Il est donc plus rapide et utilise moins de ressources côté serveur.
   • inconvénients :
     1. occupe de la mémoire
     2. les fichiers de log ne sont pas conservés. Il faut configurer syslog pour rediriger les logs sur le serveur si on tient vraiment à récupérer les messages des clients.
2. créer un répertoire pour chaque station sur le serveur et le monter par NFS en lecture-écriture.
   • avantages & inconvénients :
     1. les arguments ci-dessus sont à prendre à l'envers dans le cas des répertoires situés sur le serveur.
3. à partir du noyau 2.2, on peut utiliser le type devfs pour /dev (un système de fichiers virtuel à la manière de /proc).
   • avantages:
     1. devfs prend très peu de mémoire comparé à un ramdisk, et pas du tout d'espace disque sur le serveur. En plus il est très rapide. Un /dev normal occupe au moins 1,5 Mo dans la mesure où un fichier (un device) fait au minimum 1 ko, et il y a environ 1200 fichiers. On peut bien entendu utiliser un modèle de /dev avec simplement les entrées nécessaires pour économiser un peu de place : 1,5 Mo, ça fait beaucoup pour un ramdisk et ça ne fait pas très propre sur un serveur.
     2. devfs crée automatiquement des entrées pour les devices détectés et ajoutés, donc pas besoin de maintenance.
   • inconvénients :
     1. tout changement sur /dev tel que création d'un lien pour la souris ou le lecteur de cdrom est perdu. Devfs fournit cependant un script nommé rc.devfs pour sauvegarder ces changements. Le script présent dans ce HowTo va alors automatiquement restaurer les liens symboliques nouvellement positionnés en appelant rc.devfs. Si on fait des changements sur /dev, il faut donc appeler rc.devfs soi-même de cette façon :

     /etc/rc.d/rc.devfs save /etc/sysconfig

Comme on peut le voir, il y a plusieurs moyens de résoudre ce problème d'accès en lecture-écriture. Voici les options choisies pour le reste de ce Howto :

• pour /dev nous utiliserons devfs
• pour /var et /tmp, nous utiliserons un ramdisk de 1 Mo. Celui-ci sera partagé pour utiliser la mémoire de manière efficace. Pour réaliser ce partage, /tmp sera en fait un lien symbolique sur /var/tmp.
• pour remplir ce ramdisk, une archive conviendra tout aussi bien qu'un répertoire modèle. Mais comme les modifications sont plus aisées avec le répertoire modèle, c'est cette dernière solution qui sera retenue.

Un accès en écriture sur /home semble nécessaire...

Mais ce n'est pas vraiment un problème puisque dans toute configuration unix de type client/serveur, /home est monté en lecture-écriture depuis le serveur, donc ça nous conviendra ;)

Comment une station récupère son adresse IP de manière à pouvoir communiquer avec le serveur ?

Heureusement pour nous ce probleme a déjà été résolu et le noyau a deux possibilités pour la configuration automatique de l'adresse IP :

1. RARP
2. Bootp

RARP est le plus facile à configurer, bootp est le plus flexible. Mais la plupart des bootroms supportent uniquement bootp, donc nous utiliserons bootp.

Et la configuration spécifique à chaque station ?

Sur RedHat, la plupart des fichiers de configuration système sont déjà situés sous /etc/sysconfig. Nous déplacerons donc simplement ceux qui ne le sont pas encore et ajouterons des liens symboliques. Ensuite nous monterons un répertoire /etc/sysconfig par station. C'est la seule partie qui est propre à la distribution utilisée ici. Avec une autre distribution, il suffira de créer un répertoire sysconfig, déplacer tous les fichiers de configuration qui ne peuvent être partagés, et ajouter les liens nécessaires. De même, /etc/rc.d/rc3.d (ou l'équivalent dans les autres distribs) peut présenter des différences entre le serveur et les stations. Si on considère que toutes les stations lancent les mêmes services, on créera simplement un rc3.d pour les stations et un pour le serveur :

1. créer un /etc/rc.d/rc3.ws et un /etc/rc.d/rc3.server
2. faire un lien de /etc/rc.d/rc3.d vers /etc/sysconfig/rc3.d
3. faire un lien de /etc/sysconfig/rc3.d vers /etc/rc.d/rc3.xxx
4. remplacer S99local dans rc3.ws par un lien vers /etc/sysconfig/rc.local pour que chaque station ait son propre rc.local

Divers problèmes

1. /etc/rc.d/rc.sysinit a besoin de /var, donc /var doit être monté ou créé avant que rc.sysinit ne soit exécuté. Il serait également intéressant que /etc/sysconfig (propre à chaque station) soit monté avant le lancement des scripts d'initialisation.
   • pour cela nous appellerons un script dès le début de /etc/rc.d/rc.sysinit, aussi bien sur le serveur que sur les stations ; ce script devra donc détecter sur quelle machine il tourne pour ne rien faire dans le cas du serveur.
2. /etc/mtab doit être accessible en écriture :
   • il suffit de créer un lien vers /proc/mounts et un fichier vide mounts dans /proc pour que fsck et mount ne se plaignent pas pendant l'initialisation (alors que /proc n'est pas encore monté). Il est à noter que smb(u)mount ne respecte pas le lien mtab et va l'écraser. Donc si on utilise smb(u)mount, il faut écrire un wrapper qui va restorer le lien.