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.

Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:34