La configuration est l’ensemble des informations sur la façon précise d’installer un ordinateur. L'espace de configuration central pour tous les clients est placé sur le serveur d'installation dans /usr/local/share/fai et ses sous-répertoires. Ce répertoire sera monté par les clients sur /fai. Il est aussi possible de recevoir toutes les données de configuration à partir d'un dépôt cvs[ (1)]. Les sous-répertoires suivants sont créés et incluent plusieurs fichiers :
Scripts et fichiers pour définir les classes et variables et pour charger des modules du noyau.
Fichiers de configuration pour le partitionnement des disques et la création des systèmes de fichiers.
Ce répertoire rassemble toutes les données pour debconf[ (8)]. Non encore utilisé !
Contient le fichier avec les listes de logiciels à installer ou supprimer.
Scripts pour la personnalisation locale (propre à chaque site).
Les fichiers utilisés par les scripts de personnalisation, par exemple les paquets de noyau (kernel packages) créés par l’utilisateur. La plupart des fichiers sont placés dans une arborescence de sous-répertoires qui reflète l'arborescence de répertoires standard. Par exemple, les modèles pour nsswitch.conf sont placés dans /fai/files/etc/nsswich.conf . Le répertoire files/packages/ peut contenir vos paquets Debian locaux, qui peuvent être installés en les ajoutant aux variables addpackages . Voir Définition de Variables pour plus d'information.
Ce sont des programmes ou des scripts définis par l'utilisateur, qui sont lancés pendant le processus d'installation. (NdT : nommés « crochets » dans le texte.)
Le script d'installation principal rcS_fai utilise tous ces sous-répertoires dans l'ordre listé, à part pour hooks/ . Le paquet FAI contient des exemples pour tous ces scripts et fichiers de configuration dans /usr/share/doc/fai/examples. Copiez les exemples dans l'espace de configuration et commencez une installation. Ces fichiers n'ont pas besoin d'appartenir au compte root. Vous pouvez changer leur appartenance et éditer ensuite la configuration avec un compte utilisateur normal.
# cp -a /usr/share/doc/fai/examples/simple/* /usr/local/share/fai
# chown -R fai /usr/local/share/faiLes fichiers suivants contiennent une configuration simple pour quelques exemples d’hôtes. Les exemples sont : un hôte de démonstration (appelé demohost ) avec le bureau GNOME, et un cluster Beowulf avec un noeud maître appelé nucleus et des noeuds de calcul appelés atom01 , atom02 ....
Une machine avec un petit disque dur IDE installée avec GNOME et utilisant DHCP pour obtenir sa configuration réseau. C'est l'exemple le plus facile. Vous devez juste ajouter un fichier XF86Config.
Ce noeud maître Beowulf est un serveur avec beaucoup de logiciels. Il fournit les répertoires /home et /usr/local pour ses noeuds de calcul. Quelques démons sont installés et activés par défaut.
Ces clients Beowulf montent /usr/local et /home sur nucleus . La majorité de l'espace disque est utilisé pour une partition vide, qui est exportée à un netgroup d'hôtes. Toutes les partitions vides sont montées sur tous les clients Beowulf via l'automonteur.
Commencez par regarder ces exemples et les étudier. Ensuite modifiez ou ajoutez des choses à ces exemples. Mais n'oubliez pas de préparer votre propre installation !
Après le démarrage du noyau, celui-ci monte le système de fichiers racine par NFS depuis le serveur d'installation et le processus init[ (1)] démarre le script /sbin/rcS_fai . Ce script contrôle la séquence d'installation. Aucun autre script de /etc/init.d/ n'est utilisé.
Le script d'installation utilise beaucoup de sous-programmes, qui sont définis dans /usr/share/fai/subroutines et un fichier spécifique au système d'exploitation[13]. Toutes les tâches importantes de l'installation sont appelées via le sous-programme task avec le nom de la tâche accolé comme une option (par exemple task_instsoft ). Le sous-programme task appelle d'abord les crochets avec ce préfixe si il en existe et appelle ensuite la tâche par défaut (définie comme task_name dans les sous-programmes). La tâche par défaut et ses crochets peuvent être sautés sur demande en utilisant le sous-programme skiptask().[13]
Ci-dessous la description de toutes les tâches par défaut.
le noyau a ajouté des variables définies par paramètres, le syslog et le démon de log du noyau sont démarrés. La liste des équipements réseau est stockée dans $netdevices . Des paramètres complémentaires sont alors récupérés d'un serveur DHCP ou BOOTP et des variables supplémentaires sont définies. Le fichier de configuration DNS est créé. L'espace de configuration est monté via NFS depuis le serveur d'installation sur /fai ou il est récupéré sur le dépôt CVS[ (1)] correspondant. Pour utiliser un dépôt CVS, vous devez positionner les variables $FAI_CVSROOT , $FAI_CVSTAG , $FAI_CVSMODULE . Pour les détails, regardez le sous-programme get_fai_cvs() . Après cela, le fichier /fai/hooks/subroutines est sourcé si il existe. En utilisant ce fichier, vous pouvez définir vos propres sous-programmes ou ignorer la définition des sous-programmes de FAI.
Cette tâche positionne l’horloge système, tous les FAI_FLAGS sont définis et deux terminaux virtuels complémentaires sont disponibles. Un démon ssh est disponible pour les connexions à distance.
Appelle fai-class[ (1)] pour définir les classes en utilisant les scripts et les fichiers dans /fai/class et des classes de /tmp/fai/additional-classes .
Source tous les fichiers /fai/class/*.var pour chaque classe définie. Si un crochet a écrit quelques définitions de variables dans le fichier /tmp/fai/additional.var , ce fichier est aussi sourcé.
Selon la valeur de $FAI_ACTION , ce sous-programme décide quelle action FAI doit exécuter. Les actions par défaut disponibles sont : sysinfo et install. Si $FAI_ACTION a une autre valeur, une action définie par l'utilisateur est appelée si un fichier /fai/hooks/$FAI_ACTION existe. Donc vous pouvez facilement définir vos propres actions.
Appelé quand aucune installation n'est exécutée, mais que l'action est sysinfo . Cela récupère les informations sur le matériel détecté et monte les disques durs locaux en lecture seule sur /tmp/target/partitionname ou en suivant le contenu d’un fichier fstab trouvé sur l'une des partitions. Les fichiers de log sont stockés sur le serveur de logs.
Cette tâche contrôle la séquence d'installation. Vous entendrez trois bips sonores avant que l’installation ne démarre. Le travail principal est d’appeler les autres tâches et de sauvegarder la sortie dans /tmp/fai/rcS.log. Si vous avez des problèmes pendant l'installation, regardez tous les fichiers contenus dans /tmp/fai/. Vous trouverez des exemples de fichiers de log pour quelques hôtes dans le répertoire de téléchargement de la page d'accueil FAI.
Appelle setup_harddisk pour partitionner les disques durs. La tâche écrit les définitions de variables pour les partitions et device root et boot ( $ROOT_PARTITION , $BOOT_PARTITION , $BOOT_DEVICE ) dans /tmp/fai/disk_var.sh et crée un fichier fstab.
Monte les partitions, selon le fichier /tmp/fai/fstab créé, relativement à $FAI_ROOT.
Extrait le fichier compressé base.tgz , qui contient tous les logiciels demandés. C'est une image d'un système Debian de base créé par debootstrap[ (8)]
Si un miroir Debian local est accessible par NFS (quand $FAI_DEBMIRROR est définie), ce répertoire sera monté à $MNTPOINT .
Prépare le système de base Debian précédemment extrait pour l’installation et met à jour la liste de paquets disponibles. Met à jour la version des paquets. Elle modifie aussi quelques commandes (appelées diversions ) à l'intérieur du nouveau système en utilisant dpkg-divert[ (8)].
Installe les paquets souhaités en utilisant les fichiers de classes dans /fai/package_config.
Appelle les scripts de /fai/scripts/ et ses sous-répertoires pour chaque classe définie.
Démonte tous les systèmes de fichiers dans le nouveau système et supprime les diversions de fichiers en utilisant la commande fai-divert .
Attend que les taches de fond se terminent (par exemple la compilation des fichiers Lisp d'Emacs) et redémarre automatiquement le client ou attend une entrée manuelle avant de rebouter.
Change le lien symbolique sur le serveur d'installation qui indique quelle image de noyau doit être chargée au prochain démarrage sur la carte réseau via TFTP.
Sauvegarde les fichiers de log sur le disque local et sur les comptes $LOGUSER sur $LOGSERVER (par défaut sur le serveur d'installation). Actuellement le fichier error.log n'est pas copié sur le serveur de logs.
Après l’initialisation de base, réalisée par le sous-programme fai_init (création du disque virtuel, lecture de fai.conf et définitions de tous les sous-programmes, mise en place du « path », impression du copyright), l'installation continue en appelant la tâche confdir et la tâche setup . La commande get-boot-info est appelée pour obtenir toutes les informations du serveur BOOTP ou DHCP. Cette commande écrit le fichier /tmp/fai/boot.log , qui est alors sourcé pour définir les variables globales correspondantes. Voici un exemple de fichier de log avec utilisation d’un serveur DHCP.
# cat /tmp/fai/boot.log
netdevices_all="eth0
eth0 eth0"
netdevices_up="eth0"
netdevices="eth0"
BROADCAST='192.168.1.255'
DOMAIN='localdomain'
DNSSRVS='192.168.1.1'
DNSSRVS_1='192.168.1.1'
HOSTNAME='demohost'
IPADDR='192.168.1.12'
NETWORK='192.168.1.0'
GATEWAYS='192.168.1.250'
GATEWAYS_1='192.168.1.250'
SERVER='faiserver'
NETMASK='255.255.255.0'On passe des informations complémentaires par la ligne de commande du noyau ou depuis le fichier /etc/fai/fai.conf . En démarrant avec PXE, les paramètres de ligne de commande sont créés en utilisant fai-chboot[ (8)]. La variable $FAI_FLAGS contient une liste d’options séparées par un espace. On connaît les options suivantes :
Fournit plus d’informations pendant le déroulement de l'installation. Cela devrait toujours être la première option, car ainsi les définitions des options suivantes sont affichées verbeusement.
Fournit des informations de mise au point. Aucune installation sans surveillance n'est exécutée. Pendant l'installation des logiciels, vous devez répondre à toutes les questions des scripts de post-installation sur la console du client. De nombreuses informations de debogage seropnt affichées. Cette option n'est utile que pour les développeurs FAI.
Démarre le démon ssh pour permettre les connexions à distance.
Démarre les démons de logs système et noyau, ce qui permet aux processus de l'utiliser pour distribuer l'information. Cette option ne devrait être utilisée que si le syslogd n’est pas déjà actif sur le système, donc il ne peut être utilisé que sur l’installation initiale, pas sur un update !
Créé deux terminaux virtuels et exécute un shell bash si ctrl-c est tapé sur la console. Les terminaux complémentaires peuvent être accédés en tapant Alt-F2 ou Alt-F3. Sinon, aucun terminal n'est disponible et taper ctrl-c redémarrera le client. Mettre cette option est utile pour le débogage. Si vous voulez une installation qui ne soit pas interruptible, ne mettez pas ce drapeau.
Redémarre le client lorsque l'installation est finie sans taper Entrée sur la console. Ce n'est utile que si vous pouvez changer d'image de boot ou d'unité de boot automatiquement ou si votre robot peut retirer la disquette de boot par contrôle à distance :-) Pour le moment, cela ne devrait être utilisé qu'avec le boot sur la carte réseau.
Les classes déterminent quel(s) fichier(s) de configuration choisir dans une liste de modèles disponibles. Les classes sont utilisées dans toutes les tâches de l'installation. Pour déterminer quelle configuration utiliser, un client recherche la liste des classes définies pour lui et utilise tous les fichiers de configuration qui correspondent à un nom de classe. Il est aussi possible de n'utiliser que le fichier de configuration avec la priorité la plus haute, puisque l'ordre de classes définit la priorité de la plus basse à la plus haute. Il y a quelques classes prédéterminées (DEFAULT, LAST et « hostname » ), mais les classes peuvent aussi être inscrites dans un fichier ou définies dynamiquement par des scripts. Il est alors facile de définir une classe en fonction du sous-réseau ou d'un certain matériel présent sur la machine cliente.
L'idée d'utiliser les classes en général et d'utiliser certains fichiers correspondant à un nom de classe pour une configuration vient des scripts d'installation de Casper Dik pour Solaris. Cette technique s'est avérée très utile pour les postes de travail SUN, donc je l'utilise aussi pour l'installation entièrement automatique (FAI) de Linux. Une fonction simple et très efficace des scripts de Casper est d'appeler une commande avec tous les fichiers (ou seulement le premier) dont le nom soit aussi une classe.
La boucle suivante met en oeuvre cette fonction dans du code en pseudo-shell :
for class in $all_classes; do
if [ -r $config_dir/$class ]; then
your_command $config_dir/$class
# exit if only the first matching file is needed
fi
doneDe cette façon, il est possible d'ajouter un nouveau fichier à la configuration sans changer le script. C'est parce que la boucle détecte automatiquement les nouveaux fichiers de configurations qui doivent être utilisés. Malheureusement cfengine ne supporte pas cette fonction agréable, alors toutes les classes utilisées dans cfengine doivent aussi être spécifiées à l'intérieur des scripts cfengine.
Les classes sont primordiales pour l'installation entièrement automatique.
Si un client appartient à la classe A, nous disons que la classe A est définie. Une classe n'a aucune valeur, elle est juste définie ou non définie. Dans des scripts, la variable $classes contient la liste des noms de toutes les classes définies, séparés par un espace.
Les classes déterminent comment l'installation est exécutée. Par exemple, un client peut être configuré pour devenir un serveur FTP en y ajoutant juste la classe FTP . Et surtout une configuration peut être créée en modifiant ou en ajoutant des classes auxquelles un client appartient, l'installation d'un nouveau client est alors très facile. Ainsi aucune information supplémentaire ne doit être ajoutée aux fichiers de configuration si les classes existantes suffisent pour vos besoins.
Il y a plusieurs possibilités différentes de définir des classes :
Quelques classes par défaut sont définies pour chaque hôte : DEFAULT, LAST et son « hostname ».
Les classes peuvent être inscrites dans un fichier.
Les classes peuvent être définies par des scripts.
La dernière option est un dispositif très agréable, puisque ces scripts définiront des classes automatiquement. Par exemple, plusieurs classes sont définies seulement si un certain matériel est identifié. Nous utilisons Perl et des scripts shell pour définir des classes.
Tous les noms de classes, sauf pour « hostname » , sont écrits en majuscule. Ils ne doivent pas contenir de trait d'union, de dièse ou de point, mais peuvent contenir un souligné. Une description de toutes les classes peut être trouvée dans /usr/share/doc/fai/classes_description.txt. Le « hostname » devrait être rarement utilisé pour les fichiers de configuration dans l'espace de configuration. Il vaut mieux définir une classe et l'ajouter ensuite pour un hôte donné. En effet la plupart du temps les données de configuration ne sont pas spécifiques à un hôte, mais peuvent être partagées par plusieurs clients.
La tâche par défaut defclass appelle le script faiclass[ (1)] pour définir les classes. Les scripts correspondants à [0-9][0-9]* dans /fai/class sont exécutés. De plus, les fichiers dans ce répertoire peuvent contenir une liste de classes. Nous utilisons par exemple un fichier KOELN pour tous nos clients qui appartiennent à un certain sous-réseau. Si nous voulons ajouter une classe à toutes ces machines, nous ajoutons juste la classe à ce fichier. Pour plus d'information sur la définition de classes, lisez les pages de manuel pour faiclass[ (1)]. La liste de toutes les classes définies est stockée dans la variable $classes et sauvegardée dans /tmp/fai/FAI_CLASSES . La liste de toutes les classes est transférée à cfengine , donc il peut aussi les utiliser.
Le script 01alias (ci-dessous en version dépouillée) est utilisé pour définir des classes pour plusieurs groupes de machines. D'abord ce script définit la classe avec le nom de l'architecture matérielle en lettres majuscules. Les hôtes qui ont une adresse IP dans le sous-réseau 134.95.9.0 appartiennent aussi à la classe NET_9 , les hôtes dans le sous-réseau de classe B 134.95 utilisent toutes les classes du fichier KOELN . Tous les noeuds Beowulf avec le préfixe atom sauf atom00 (le serveur maître) appartiendront aux classes inscrites dans le fichier atoms .
Voici un exemple de la simplicité avec laquelle vous pouvez grouper les machines qui doivent appartenir au même groupe de classes.
# cat 01alias
uname -s | tr /a-z/ /A-Z/
[ -x "`which dpkg`" ] && dpkg --print-installation-architecture | tr /a-z/ /A-Z/
# the Beowulf cluster; all nodes except the master node
# use classes from file class/atoms
case $HOSTNAME in
atom00) echo BEOWULF_MASTER ;;
atom??) cat atoms ;;
esac
# if host belongs to class C subnet 134.95.9.0 use class NET_9
# exclude all hosts with an IP address above 200
case $IPADDR in
134.95.9.2??) ;;
134.95.*.*) cat koeln ; echo "CS_KOELN NET_9" ;;
134.95.9.*) echo "CS_KOELN NET_9" ;;
esacLe script 24nis définit automatiquement des classes correspondant au NIS. Le nom du domaine NIS (défini via BOOTP ou DHCP) devient aussi une classe (en lettres majuscules uniquement, et les tirets sont remplacés par un souligné). Si aucun domaine NIS n'est défini, seule la classe NONIS est définie.
En fonction des noms de partitions définis dans la première correspondance disk_config trouvée, 70partitions définit des classes supplémentaires. Par exemple, si une partition /files/scratch existe, la classe FILES_SCRATCH est définie. Elle force le client à exporter ce répertoire par NFS et à installer les paquets du serveur NFS.
Le script 06hwdetect.source utilise les commandes par défaut de Debian pour détecter le matériel SCSI et charger les drivers nécessaires au noyau. Si un matériel spécifique est trouvé, il peut aussi définir une nouvelle classe pour celui-ci.
Vous pouvez trouver les messages de modprobe dans /tmp/fai/kernel.log et sur le terminal de la quatrième console en appuyant Alt-F4.
La tâche defvar définit les variables pour le client. Les variables sont définies par des scripts dans class/*.var. Toutes les variables globales peuvent être déclarées dans DEFAULT.var . Pour certains groupes de machines, il faut utiliser un fichier de classe, mais pour un hôte isolé, on utilise le fichier hostname.var . Là encore, il est utile d'étudier tous les exemples. Les variables suivantes sont utilisées dans les exemples et peuvent être très utiles pour personnaliser votre installation :
indique l'action que FAI doit exécuter. Normalement cela est fait par fai-chboot[ (8)]. Si vous ne pouvez pas utiliser cette commande et que vous n'utilisez pas de serveur BOOTP, définissez cette variable dans le script LAST.var.
désigne la police qui est chargée pendant l'installation par consolechars[ (8)].
définit les fichiers de map du clavier dans /usr/share/keymaps et $FAI/files . Vous n'avez pas besoin de spécifier le chemin complet, ce fichier sera placé automatiquement.
Le mot de passe de « root » pour le nouveau système. De plus, FAI crée un compte « root » avec le même mot de passe appelé « roott » , qui utilise tcsh[ (1)].
règle l'horloge matérielle sur UTC si $UTC=yes . Sinon, l'horloge est réglée sur l'heure locale. Voir clock[ (8)] pour plus d'information.
est le fichier relatif à /usr/share/zoneinfo/ qui indique votre fuseau horaire.
ajoute des paramètres pour le noyau du nouveau système (écrit dans /etc/lilo.conf).
peut être une définition multi-lignes. C'est la liste des modules (en incluant les paramètres de noyau) qui sont chargés pendant le boot du nouveau système (écrit dans /etc/modules ).
assure la liaison vers l'image de noyau TFTP au démarrage en utilisant le système de fichiers racine du disque local. C'est utilisé uniquement avec un serveur BOOTP pour le démarrage.
les noms des serveurs NFS pour /home et /usr ou /usr/local.
la liste des imprimantes pour lesquelles un répertoire de spool est créé. Les scripts de configuration n'initialisent pas /etc/printcap.
contient la liste des paquets complémentaires qui sont installés sur le nouveau système, s'ils sont disponibles dans /fai/files/packages. Elle doit aussi contenir le nom du paquet du noyau qui doit être installé. Vous pouvez créer un dépôt simple en utilisant les commandes suivantes sur le serveur d'installation :
# cd /usr/local/share/fai/files
# dpkg-scanpackages packages /dev/null | \
gzip -9 > packages/Packages.gzSi vous ne voulez pas utiliser cette fonction (pour quelle raison ?), créez un fichier vide Packages pour supprimer les messages d'erreurs. En complément, vous pouvez aussi créer un fichier de version (Release) dans ce répertoire. Alors addpackages peut être la liste des paquets sans numéro de version. Pour plus d'information, référez-vous au « repository-howto »[14]. Ceci peut être utilisé pour installer des paquets spécifiques au site.[14]
Le format des fichiers de configuration de disque dur est décrit dans /usr/share/doc/fai/README.disk_config.gz.
Le fichier de configuration /fai/disk_config/CS_KOELN est une description générique pour un disque dur IDE, qui devrait convenir pour la plupart des installations. Si vous ne pouvez pas partitionner votre disque dur en utilisant ce script[15], utilisez un « crochet » à la place. Le « crochet » doit écrire la nouvelle table de partition, créer les systèmes de fichiers et écrire les fichiers /tmp/fai/fstab et /tmp/fai/disk_var.sh , qui contiennent les définitions des partitions racine et de boot.[15]
Le script install_packages installe les logiciels sélectionnés. Il utilise tous les fichiers de configuration présents dans /fai/package_config dont le nom correspond à une classe définie. La syntaxe est très simple.
# an example package class
PACKAGES taskinst
german science
PACKAGES install
adduser netstd ae
less passwd
PACKAGES remove
gpm xdm
PACKAGES dselect-upgrade
ddd install
a2ps installLes commentaires commencent par un dièse (#) et se terminent à la fin de la ligne. Chaque commande commence par le mot PACKAGES suivi par un nom de commande. Le nom de commande est similaire à ceux d'apt-get . Voici la liste de noms de commande acceptés :
Fige l'état d'un paquet. Ce paquet ne sera pas traité par dpkg, par exemple ne sera pas upgradé.
Installe tous les paquets qui sont spécifiés dans les lignes suivantes. Si un trait d'union (-) est ajouté devant le nom du paquet (sans espace intercalaire), le paquet sera retiré, et non pas installé. L'orthographe de tous les noms de paquet est vérifiée. Tous les paquets qui n'existent pas, seront enlevés de la liste de paquets à installer. Alors faites attention pour ne pas faire d'erreur sur le nom d'un paquet.
Enlève tous les paquets qui sont spécifiés dans les lignes suivantes. Ajoutez un (+) au nom du paquet si le paquet doit être installé.
Installe tous les paquets appartenant aux tâches qui sont spécifiées dans les lignes suivantes, en utilisant tasksel[ (1)].
positionne les sélections de paquets en fonction des lignes suivantes et installe ou retire les paquets indiqués. Ces lignes sont produites par la commande dpkg –get-selections .
De nombreuses lignes avec les listes de noms de paquets séparés par des espaces s'inscrivent à la suite des commandes install et remove . Toutes les dépendances sont résolues et apt-get est utilisé pour exécuter l'installation ou la suppression des paquets. L'ordre des paquets importe peu.
Une ligne qui contient la commande PRELOADRM télécharge un fichier en utilisant wget[ (1)] dans un répertoire avant d'installer les paquets. En utilisant l'URL file: , ce fichier est copié depuis $FAI_ROOT vers le répertoire de téléchargement. Par exemple le paquet realplayer a besoin d'une archive pour installer le logiciel, alors cette archive est téléchargée dans le répertoire /root . Après l'installation des paquets ce fichier sera supprimé. Si le fichier ne doit pas être enlevé, il faut utiliser la commande PRELOAD à la place .
Maintenant il est possible d'ajouter une liste de noms de classes après la commande pour apt-get . Alors la commande PACKAGE ne sera exécutée que si la classe correspondante est définie. Ainsi vous pouvez combiner beaucoup de petits fichiers dans le fichier DEFAULT. ATTENTION ! N'utilisez cette fonction que dans le fichier DEFAULT pour conserver les choses simples. Reportez-vous à ce fichier pour quelques exemples.
Si vous indiquez un paquet qui n'existe pas, ce paquet sera enlevé de la liste d'installation. Vous pouvez aussi tester tous les fichiers de configuration de logiciels avec l'utilitaire chkdebnames , qui est disponible dans /usr/share/doc/fai/examples/utils/.
> chkdebnames stable /usr/local/share/fai/package_config/*L'ensemble de scripts par défaut dans /fai/scripts est fournit uniquement à titre d'exemple. Mais ils devraient raisonnablement convenir pour votre installation. Vous pouvez les éditer ou ajouter de nouveaux scripts pour correspondre à vos besoins.
La commande fai-do-scripts[ (1)] est appelée pour exécuter tous les scripts dans ce répertoire. Si un répertoire portant un nom de classe existe, tous les scripts du type S[0-9]* sont exécutés par ordre alphabétique. Il est ainsi possible d'utiliser des scripts de langages différents (shell, cfengine, perl...) pour chaque classe.
La plupart des scripts sont des scripts BASH . Les script Shell sont très utiles si la tâche de configuration doit seulement appeler quelques commandes de shell ou créer un fichier à partir de zéro. De façon à ne pas écrire plein de petits scripts, il est possible de distinguer les classes à l'intérieur d'un script en utilisant la commande ifclass . Pour copier des fichiers en rapport avec des classes, utilisez la commande fcopy[ (8)]. Si vous voulez extraire des archives en utilisant des classes, utilisez ftar[ (8)]. Mais maintenant regardez les script pour voir ce qu'ils font.
Actuellement aucun script Perl n'est utilisé pour modifier la configuration de système.
Actuellement aucun script « Expect » n'est utilisé pour modifier la configuration de système.
Cfengine possède un jeu de fonctions assez riche pour éditer des fichiers de configuration existants, par exemple LocateLineMatching , ReplaceAll , InsertLine , AppendIfNoSuchLine , HashCommentLinesContaining . Mais il ne peut pas manipuler de variables qui ne sont pas définies. Si une seule variable n'est pas définie, la totalité du script cfengine échouera. Étudiez les exemples fournis dans le paquet fai . Vous trouverez plus d'information dans la page de manuel cfengine[ (8)] ou sur la page d'accueil cfengine http://www.cfengine.org.
Le changement de l'ordre de boot est normalement réalisé dans le setup du BIOS. Mais on ne peut pas changer le BIOS depuis une session Linux active (pour autant que je le sache !) Si vous savez le faire, envoyez-moi s'il vous plaît un e-mail. Mais il y a une autre façon d'échanger le dispositif de boot d'un système Linux en fonctionnement.
Normalement, l'ordre de boot du BIOS reste inchangé et votre ordinateur doit toujours démarrer en premier sur sa carte réseau et en second sur le disque dur local. On peut alors obtenir une image de noyau d'installation à partir du serveur d'installation, si on exécute une installation, ou on peut dire à pxelinux de démarrer sur le disque local. C'est ce qu'on fait en utilisant fai-chboot[ (8)].
Voici comment configurer une carte réseau 3Com™ comme premier dispositif de boot. Validez le réseau local comme premier dispositif de boot dans le BIOS.
Boot From LAN First: Enabled Boot Sequence : C only
Entrez alors dans le setup MBA de la carte réseau 3COM™ et changez-le comme suit :
Default Boot Local Local Boot Enabled Message Timeout 3 Seconds Boot Failure Prompt Wait for timeout Boot Failure Next boot device
Cela validera le premier disque dur IDE comme second dispositif de boot. En boutant sur une disquette FAI, vous avez une autre solution pour éviter une réinstallation si le BIOS est configuré pour démarrer sur la disquette en premier et que vous n'êtes pas là pour enlever la disquette :
# lilo -R ...indiquera à la disquette FAI de démarrer du disque dur une seule fois (voir lilo [(8)]). Ainsi après ce premier reboot, la disquette FAI peut être utilisée pour une autre installation FAI.
Les « crochets » vous permettent de spécifier des fonctions ou les programmes qui sont exécutés à certaines phases du processus d'installation. Avant d'appeler une tâche par défaut, FAI recherche l'existence de « crochets » pour cette tâche et les exécute. Comme vous vous en doutez, les classes sont aussi utilisées pour appeler les « crochets ». Les « crochets » sont exécutés pour chaque classe définie. Vous devez seulement créer le « crochet » avec le nom de la classe désirée et il sera utilisé. Si l'option debug est incluse dans $FAI_FLAG, on passe l'option -d à tous les crochets, vous pouvez donc mettre au point vos propres « crochets ». Si vous devez sauter certaines tâches par défaut, utilisez le sous-programme skiptask avec la liste de ces tâches par défaut comme paramètres. L'exemple partition.DISKLESS saute certaines tâches par défaut.
Le répertoire /fai/hooks/ contient tous les « crochets ». Le nom de fichier d'un « crochet » consiste en un nom de « crochet » comme préfixe et un nom de classe, séparés par un point. Le préfixe décrit le moment où le « crochet » est appelé, si la classe est définie pour le client. Par exemple, le « crochet » partition.DISKLESS est appelé pour chaque client appartenant à la classe DISKLESS avant le partitionnement des disques locaux. Si cela doit devenir un client sans disque, ce « crochet » peut monter les systèmes de fichiers distants via NFS et créer /tmp/fai/fstab . Ensuite, le processus d'installation n'essayera pas de partitionner et formater un disque dur local, parce qu'un fichier /tmp/fai/fstab existe déjà.
Un « crochet » de la forme hookprefix.classname ne peut pas définir de variables pour le script d'installation, parce que c'est un sous-programme. Mais vous pouvez utiliser n'importe quel fichier binaire exécutable ou n'importe quel script que vous avez écrit. Les « crochets » qui ont le suffixe .source (par exemple partition.DEFAULT.source ) doivent être des script BASH et sont sourcés. De cette façon, il est possible de redéfinir des variables pour les script d'installation.
Dans la première partie de fai, tous les « crochets » avec le préfixe confdir sont appelés. Comme le répertoire de configuration /fai est monté dans la tâche par défaut confdir , les « crochets » pour cette tâche sont les seuls « crochets » placés dans $nfsroot/fai/hooks sur le serveur d'installation. Tous les autres « crochets » se trouvent dans /usr/local/share/fai/hooks sur le serveur d'installation. Tous les « crochets » qui sont appelés avant que les classes ne soient définies ne peuvent utiliser que les classes suivantes : DEFAULT ; $HOSTNAME ; LAST . Si un crochet pour la classe DEFAULT ne doit être appelé que si aucun crochet pour la classe $HOSTNAME n'est disponible, insérez ces lignes dans le crochet par défaut :
hookexample.DEFAULT:
#! /bin/sh
# skip DEFAULT hook if a hook for $HOSTNAME exists
scriptname=$(basename $0 .DEFAULT)
[-f /fai/hooks/$scriptname.$HOSTNAME ] && exit
# here follows the actions for class DEFAULT
.
.Quelques exemples d'utilisations possibles des crochets :
Utiliser ssh au tout début pour vérifier que vous avez monté la configuration sur le bon serveur et pas sur un possible hôte de spoofing.
Ne pas monter le répertoire de configuration, mais au lieu de cela récupérer des archives compressées via HTTP ou sur une disquette et l'extraire dans un nouveau ram-disque, puis redéfinir $FAI_LOCATION.
Charger des modules de noyau avant que les classes ne soient définies dans /fai/class.
Envoyer un e-mail à l'administrateur lorsque l'installation est terminée.
Installer un client sans disque et éviter le partitionnement de disque local. Voir hooks/partition.DISKLESS.
Partitionner le disque dur sur un système IA64, qui a besoin d'un type spécial de table de partition qui doit être créé avec parted[ (8)]. Voir hooks/partition.IA64.
Si le client ne peut pas bouter sur la carte réseau, utilisez tcpdump pour regarder les paquets Ethernet entre le serveur d'installation et le client. Recherchez aussi les entrées dans plusieurs fichiers de log créées par in.tftpd[ (8)], dhcpd3[ (8)]ou bootpd[ (8)]:
egrep "tftpd|bootpd|dhcpd" /var/log/*Si le processus d'installation se termine, le « crochet » faiend.LAST recherche les erreurs communes dans tous les fichiers de log et les écrit dans le fichier error.log. Vous devrez donc d'abord examiner ce fichier pour voir les erreurs. Le fichier status.log vous donne le code de sortie de la dernière commande exécutée dans un script. Pour être sur, vous devriez chercher les erreurs dans tous les fichiers de log.
Parfois l'installation semble s'arrêter, mais c'est seulement un script de postinstall d'un logiciel qui demande une entrée manuelle sur la console. Passez sur un autre terminal virtuel et regardez quel processus est actif avec des outils comme top[ (1) ]et pstree[ (1)] . Vous pouvez ajouter debug à FAI_FLAGS pour que le processus d'installation montre toute les sorties des scripts de postinstall sur la console et établir aussi son entrée sur la console. N'hésitez pas à envoyer un e-mail à la liste de diffusion ou à <fai@informatik.uni-koeln.de> si vous avez des questions. Des fichiers de log exemples d'ordinateurs installés avec succès sont disponibles sur la page d'accueil FAI.