[AlternC-dev] debianisation, suite

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Benjamin Sonntag benjamin at globenet.org
Sam 8 Mai 19:53:24 CEST 2004


Je viens de re-réfléchir à ce problème de gestion de la configuration 
des services AlternC.

Je vous propose le fonctionnement suivant :

Lexique :
* un module AlternC <=> Un paquet Debian avec ses dépendances. Un module 
assure un service (genre mailman, webinstaller ...) il existe aussi un 
module "core" nommé AlternC tout court qui contient le gros des services 
mail/web
* fichier de conf AlternC <=> liste de variables la plupart du temps 
sous la forme key=value\n ou key="complex value"\n et # est pour les 
commentaires. On peut imaginer de nouvelles syntaxes __si besoin__ (pour 
des blocs par exemple, on pourrait utiliser <> </> comme dans httpd.conf.)

Fonctionnement :

- on met dans /etc/alternc un fichier de conf AlternC par module : par 
exemple alternc.conf (pour le core), alternc-mailman.conf 
alternc-webinstaller.conf etc.

- on met dans /etc/ac/ (ou un autre nom, si possible court et facile à 
retenir/comprendre) la copie de l'ensemble de l'arborescence de /etc 
concernée par les fichiers de configuration. par exemple, 
/etc/ac/apache/httpd.conf /etc/ac/postfix/main.cf  /etc/ac/proftpd.conf

- on a dans /usr/lib/alternc/install/ un script shell par module 
d'AlternC. Chaque script shell peut prendre le paramètre --first-install 
pour signaler qu'il s'agit d'une première installation du module sur 
cette machine (ou d'alternc lui-même pour le core). Sinon, il est chargé 
de mettre juste à jour la conf correspondante au module concerné.
Ces scripts shells utilisent la conf dans 
/etc/alternc/alternc-"module".conf pour substituer les variables qui 
vont bien dans les fichiers de /etc/ac/* qui les concernent et les 
recopier dans /etc/, et redémarrer les services dans le bon ordre.

- on a 2 scripts shells dans /usr/sbin : alternc.install et alternc.update.
    * alternc.install lance les scripts de /usr/lib/alternc/install/ 
avec --first-install (après avoir confirmé que le type savait bien ce 
qu'il fait ;) )
    * alternc.update lance les scripts sans --first-install (pour mise à 
jour seule de la conf).

- (sous réserve que cela soit vraiment utile : ) les fichier de 
/etc/alternc/*.conf sont copiés dans /var/cache/alternc/conf/*.conf pour 
pouvoir trouver les variables qui ont été modifiées lors d'un update, si 
besoin. Cela permettrait par exemple à bind de ne pas avoir à modifier 
tous les fichiers de zones lors d'un update si l'ip n'a pas changée ...

- on maintient sur le dev d'AlternC la liste des variables des fichiers 
de conf pour qu'il n'y ait pas conflit entre modules, ainsi, chaque 
script shell peut inclure toutes les données de tous les fichiers de 
conf avant de travailler ... (je pense à mailman par exemple, qui a 
besoin de l'ip, stockée dans la conf du core)

- on ajoute à chaque fichier de configuration, lors de sa recopie de 
/etc/ac/* vers /etc/* des lignes de commentaire indiquant que ces 
fichiers ne DOIVENT PAS etre modifiés, mais qu'il faut modifier le 
fichier original dans /etc/ac/* ;)

- on déplace les cas bizarre comme /etc/webalizer/* dans 
/var/cache/alternc/webalizer/ : en effet, ces fichiers sont une sorte de 
"cache" de configuration vu que la vraie autorité en matière de 
statistiques est la table system.stat. et avant le process quotidien de 
webalizer, on régénère le cache [si besoin].


Questions / Réponses :

- pourquoi mettre un __script shell__ de config "par module" plutot 
qu'un gros script qui substitue toutes les variables dans tous les 
fichiers de conf ? (comme la fin du alternc.install actuel) ?
* parce que le jour où il y aura un cas auquel on n'aura pas pensé, (par 
exemple bind doit reecrire TOUTES les zones dns en cas de changement 
d'ip...) et bien on est mort avec ce fonctionnement là. avec un script 
shell par module, on peut imaginer d'autres mises à jour plus complexes...
Exemple :  imaginons (parce qu'en fait c'est du core, quoique...) 
alternc-bind.sh dans /usr/lib/alternc/install, il
    - substitue les variables dans /etc/ac/bind/named.conf pour recopier 
le /etc/bind/named.conf
    - vérifie si l'ip de la machine a changée grace a 
/var/cache/alternc/alternc.conf et si oui, réécrit toutes les zones de 
/etc/bind/master/* pour la nouvelle ip.
    - relance bind.

- pourquoi mettre les "vraies" conf dans /etc/ac (ou mieux à trouver...) 
et plus dans /usr/share/alternc/1.0/install/etc
* parce que c'est BEAUCOUP plus court, donc plus facile à retenir et à 
accéder, et aussi pour mieux respecter la FHS : on met les fic de conf 
dans /etc ;)

J'ai mis cela dans le wiki, ici :

http://www.alternc.org/wiki/ConfigurationDalternc

accessible depuis le lien "FuturdAlternc"

Ajoutez vos questions si besoin, et amendez le machin si vous avez de 
meilleures idées.

@+

Benjamin




Plus d'informations sur la liste de diffusion Dev