Les supplements de Linuxconf Introduction La maniere courante d'ajouter des procedures de demarrage person­ nalisees sur un systeme est generalement d'editer un fichier script ou batch. Sous Unix, il faut ajouter des commandes dans le script rc.local. Malheureusement, ceci a quelques limitations. Les supple­ ments de Linuxconf ainsi que les scripts d'initialisation Sysv etendus fournissent une meilleure alternative. Les supplements sont parfois appeles _d_r_o_p_i_n_s. 11.. SSccrriipptt dd''iinniittiiaalliissaattiioonn SSyyssvv oouu SSuupppplleemmeennttss LLiinnuuxxccoonnff Les deux offrent les memes fonctionnalites, mais il est plus facile de mettre en place un supplement (une interface utilisateur est disponible). Notez qu'a cette heure, les scripts d'initialisation Sysv (Unix de style System V) trouvees sur toutes les distributions ont des fonctionnalites tres limitees. Le document suivant indique comment etendre votre script : http://www.solucorp.qc.ca/linuxconf/tech/enhsysv 11..11.. UUnn ssuupppplleemmeenntt ppoorrttaanntt llee mmeemmee nnoomm qquu''uunn ssccrriipptt SSyyssvv Si vous donnez a un supplement le meme nom qu'a un script Sysv, le supplement aura la priorite. Le script ne sera donc jamais appele. Il est assez frequent que l'on cree un supplement pour lequel on definit simplement les commandes _s_t_a_r_t, _s_t_o_p et _r_e_l_o_a_d qui appellent le script Sysv. C'est une maniere d'etendre un script Sysv sans autant le modifier, gardant ainsi la compatibilite en cas de mise a jour. 22.. TTaacchheess Un _d_r_o_p_i_n enumere simplement comment demarrer, arreter et redemarrer un paquetage. Il fournit aussi des informations pour que _L_i_n_u_x_c_o_n_f puisse effectivement decider l'action a executer (demarrage, arret, redemarrage). 33.. CChhaammppss dduu ddiiaalloogguuee Beaucoup de champs du dialogue sont optionnels. Voici une explication pour chacun d'eux. Nous presenterons aussi le tag correspondant necessaire a etendre un script Sysv donne. Les dropins et les scripts Sysv sont tous deux supportes par le meme moteur dans Linuxconf. 33..11.. NNoomm dduu mmoodduullee Fournissez simplement un nom. Chaque dropin a un nom unique. Tous les dropins sont stockes sous forme de fichiers ASCII dans >/etc/linuxconf/control. Le nom est utilise comme clef par divers autres services, comme : · la gestion des versions du profil systeme, · la gestion de machines multiples, · le controle de l'activite des services. 33..22.. RReevviissiioonn dduu ddrrooppiinn Non utilise, entrez 1 ici. 33..33.. DDeessccrriippttiioonn dduu mmoodduullee Entrez une description du module. Soyez bref, car elle sera utilisee dans des menus et des dialogues. 33..44.. CCoommmmaannddee ddee ddeemmaarrrraaggee Fournissez la commande complete (avec les arguments) necessaire a demarrer ou a initialiser le module. 33..55.. CCoommmmaannddee dd''aarrrreett Ce champ est optionnel. Fournissez la commande complete et les arguments necessaires a arreter le module. Si ce champ est vide, Linuxconf va utiliser le nom du processus et tuer (_k_i_l_l) ce processus (Voir plus bas). 33..66.. CCoommmmaannddee ddee rreeddeemmaarrrraaggee Ce champ est optionnel. Fournissez la commande complete et les arguments necessaires a redemarrer ou a reinitialiser le module. Si ce champ est vide, Linuxconf va generer une commande d'arret puis une commande de demarrage. 33..77.. CCoommmmaannddee ddee tteesstt Ce champ est optionnel et seulement utile pour les modules complexes. Linuxconf fait des tests divers, comparant l'anciennete des processus associes a un module a la date de revision des fichiers de configuration. Si ces fichiers sont plus recents, Linuxconf declenche une commande de redemarrage (ou une sequence arret/demarrage) sur le module. Certains modules ont des fichiers de configuration complexes qui ne peuvent etre enumeres dans le dropin. Ou bien leur etat est influence par d'autres facteurs. La commande de test laisse un module decider s'il doit etre redemarre, arrete ou demarre. La commande de test ne doit pas contenir d'argument. Linuxconf appellera cette commande avec comme seul argument probe. La commande reagit a cet argument en imprimant des lignes, ou rien si rien ne doit etre fait. Chacune de ces lignes correspond a une action specifique. Les actions standard start, stop et restart seront interpretees par Linuxconf qui utilisera la commande fournie pour lancer l'action. La commande de test peut aussi retourner l'action unknown (a Linuxconf). Dans ce cas, la commande de test elle-meme sera appelee pour executer ces actions. 33..77..11.. FFoonnccttiioonnnnaalliittee ddee tteesstt ppoouurr lleess ssccrriippttss SSyyssvv Ajoutez la ligne suivante a un script Sysv pour que Linuxconf execute le script avec l'argument probe. Les lignes retournees par le script sont utilisees comme pour les dropins. # probe: true 33..88.. NNeettttooyyaaggee aauu ddeemmaarrrraaggee Ce champ est optionnel. Entrez ici une commande complete avec ses arguments. Cette commande sera executee par Linuxconf au demarrage, juste avant qu'apparaisse le menu de selection de niveau de demarrage (runlevel). La sortie de cette commande sera redirigee dans la section _t_a_c_h_e_s _a_v_a_n_t _d_e_m_a_r_r_a_g_e des journaux de Linuxconf. 33..99.. NNoommss ddeess pprroocceessssuuss Cette section est optionnelle. Vous devez entrer les noms des divers processus demarres par la commande de demarrage (demons persistents). Si vous laissez cette section vide, Linuxconf deduira le nom du processus de la commande start elle-meme. Par exemple, si la commande start est : /usr/sbin/toto -a -b le nom du processus sera toto. Lorsque plusieurs noms de processus sont fournis, Linuxconf regarde tous ces noms de processus pour determiner si le module est a jour, en comparaison a ses fichiers de configuration. 33..99..11.. NNoommss ddeess pprroocceessssuuss aavveecc lleess ssccrriippttss SSyyssvv Le tag suivant vous permet de specifier les noms des processus demarres par le script Sysv. Vous pouvez specifier ce tag plusieurs fois. # processname: toto 33..1100.. FFiicchhiieerrss PPIIDD Cette section est optionnelle. Certains modules demarrent plusieurs instances d'un demon. Linuxconf doit savoir lequel est le maitre, qui doit etre controle. La plupart des modules produisent un fichier de texte court contenant l'ID du processus principal du module. Ce fichier est generalement range dans /vezr/run, avec l'extension .pid. Un module demarrant plusieurs processus peut avoir plusieurs fichiers PID. 33..1100..11.. LLeess ffiicchhiieerrss PPIIDD aavveecc lleess ssccrriippttss SSyyssvv Le tag suivant vous permet de specifier les fichiers PID associes au script Sysv. Vous pouvez specifier ce tag plusieurs fois. # pidfile: /var/run/toto.pid 33..1111.. CCoonnttrroollee dd''aaccttiivvaattiioonn Cette section dit a Linuxconf a quel moment les modules doivent etre demarres. 33..1111..11.. DDeemmaarrrreerr aapprreess llee mmoodduullee Ce champ est optionnel. Vous pouvez specifier un nom de module. Une liste d'appoint donne tous les modules disponibles. Linuxconf demarrera ou testera le module courant apres le module specifie ici. 33..1111..22.. DDeemmaarrrreerr aauu nniivveeaauu ddee ddeemmaarrrraaggee Linuxconf definit 3 niveaux d'activite reseau : · Pas de reseau · Partie reseau cliente · Partie reseau serveur Vous definissez ici a quel niveau de demarrage le module doit etre demarre. Un module demarre a un certain niveau sera disponible aux niveaux superieurs. Par exemple, si vous decidez de demarrer votre module au niveau _P_a_r_t_i_e _r_e_s_e_a_u _c_l_i_e_n_t_e, il sera aussi disponible au niveau _P_a_r_t_i_e _r_e_s_e_a_u _s_e_r_v_e_u_r. Vous pouvez controler le niveau de demarrage reseau au demarrage et depuis le menu du panneau de controle. 33..1111..33.. AArrrreetteerr aauu nniivveeaauu ddee ddeemmaarrrraaggee Le champ precedent definissait le niveau auquel le module etait demarre. Celui-ci determine a quel niveau de demarrage il doit etre arrete. Vous pouvez aussi choisir qu'un module ne sera jamais arrete. 33..1122.. FFiicchhiieerrss ddee ccoonnffiigguurraattiioonn Dans cette section, vous devez enumerer toute configuration (si possible) affectant l'etat d'un module. Pour chaque fichier de configuration, vous pouvez specifier si le module a les moyens de s'auto-recharger lui-meme. Les fichiers de configuration a relecture automatique ne participeront pas au test avec lequel Linuxconf decide si un module doit etre redemarre. Ainsi, de tels fichiers peuvent etre omis. C'est neanmoins une bonne idee que de les enumerer car ils participent automatiquement dans la _g_e_s_t_i_o_n _d_e_s _v_e_r_s_i_o_n_s _d_u _p_r_o_f_i_l _s_y_s_t_e_m_e et dans la _g_e_s_t_i_o_n _d_e _m_a_c_h_i_n_e_s _m_u_l_t_i_p_l_e_s. 33..1122..11.. LLeess ffiicchhiieerrss ddee ccoonnffiigguurraattiioonn aavveecc lleess ssccrriipptt SSyyssvv Le tag suivant vous permet de specifier les fichiers de configuration affectant l'etat d'un module. Vous pouvez specifier ce tag plusieurs fois. Ce tag peut etre optionnellement suivi du mot-cle autoreload (auto-recheargeable). # config: /etc/toto.conf [ autoreload ] 33..1133.. CCoommmmeennttaaiirreess Vous pouvez entrer quelques commentaires sur ce module. Ils sont Seulement utilises comme reference. Linuxconf ne les utilise pas, et ne les affiche nulle part non plus. 44.. PPoouurrqquuooii ddeeuuxx eennttrreeeess ppoouurr eeddiitteerr lleess ssuupppplleemmeennttss ?? Un menu est _E_d_i_t_e_r _l_e_s _s_u_p_p_l_e_m_e_n_t_s _d_e _L_i_n_u_x_c_o_n_f, alors que l'autre est _C_r_e_e_r _l_e_s _s_u_p_p_l_e_m_e_n_t_s _d_e _L_i_n_u_x_c_o_n_f. Les deux semblent pointer vers le meme menu. Il y a une tres petite mais neanmoins importante difference : Le menu _C_r_e_e_r est utilise pour editer le fichier de supplement dans /etc/linuxconf/control/. Le menu _E_d_i_t_e_r est utilise pour editer le meme fichier, mais les changements ne sont pas stockes dans ce meme fichier, mais dans le fichier /etc/conf.linuxconf. Ainsi, le menu _E_d_i_t_e_r est utilise pour faire des changements locaux, alors que le menu _C_r_e_e_r est utilise pour manipuler le supplement directement. Si vous n'avez pas l'intention de distribuer de supplements, utilisez toujours le menu _C_r_e_e_r.