Nouveaux paquets [OBM]: Réflexion sur la Gestion des composants partagées
Bonjour,
Effectivement, vous exposez une problématique interessante:
- Comment peut-on configurer un ensemble de briques logicielles dans le cadre d'un macro fonctionnement autre que leur utilisation/configuration par
défaut ?
- Comment peut-on configurer un ensemble de briques logicielles sans altérer le fonctionnement des autres applicatifs qui l'utilise ?
- Lors de l'upgrade de mes composants logiciels, comment éviter de devoir tout reconfigurer pour mon application cible ?
Bien entendu, on peut réaliser en upgrade et répondre à dpkg qu'on veut Installer la nouvelle version, diagnostiquer ou conserver. Mais ceci demande
une analyse utilisateur. Suivant le niveau de la mise à jour, les anciens fichiers de conf nécessiteront peut-être tout de même une réécriture pour
respecter de nouvelle spécification ... etc. Bref ce n'est pas automatisable tel quel, la réponse n'est pas systématiquement évidente et ce n'ai pas
ce que nous souhaitons de le cadre que j'expose ici.
Autre point, celà dépend énormément du potentiel de configuration du composant. Si celui-ci peut gérer plusieurs configurations d'applicatifs et la
manière dont il architecture concraitement ses fichiers de configuration. Cette notion doit rentrer dans les critères à prendre en compte lors du
choix stratégique des composants au moment de l'élaboration de l'applicatif.
==============
Donc on aborde ici la question des "Configurations partagées":
- J'ai un composant (comme apache)
- J'ai mon appli (Comme OBM)
- Un fichier de configuration qui me permet d'adapter mon composant à mon appli (comme httpd.conf)
- Et là j'ai un soucis de gestions des paquets car:
- httpd.conf appartient à Apache: donc lors des upgrades d'Apache, ce fichier sera concerné et risque de rentrer dans le méchanisme du dpkg qui nous
intérroge sur l'avenir de la conf actuelle.
- httpd.conf n'appartient pas à OBM: mais lors d'un upgrade je peux avoir besoin d'y accéder or si tu le gère au niveau paquet t'aura un conflit
d'appartenance. Tu risque de vouloir passer par un processus externe perso pour aller modifier le fichier et donc outre passer ce contrôle du
gestionnaire de paquet.
==> A mon avis, Cette configuration ne doit pas être gérée par le gestionnaire de paquet, mais par ton applicatif.
Les Axes de réfléxion:
- Si le composant le permet. (apache en fait le permet), externaliser la conf spécifique. Dans l'exemple d'Apache, on peut faire des includes pour le
httpd.conf (Samba le permet aussi ... et plein d'autres). Dans le cas de la possibilité d'externaliser la configuration, celà te permet d'être peu
impacté par l'upgradee du composant. Et peu impacté par les autres applicatifs utilisant aussi ce composant.
Tu n'as plus que ton lien à injecter dans la conf. Dans ce mode de fonctionnement, je te recommande de gérer un traitement de contrôle d'intégrité de
la configuration des composants. Un traitement que tu pourrais lancer lors de la séquence de démarrage de ton applicatif et qui consisterait à:
- Vérifier les versions des composants:
Si tu détectes qu'il y eu des chagements de version, il faudra mettre à jour tes confs pour ce composant.
- Vérification des injections de configuration:
Tu controles que les includes et autres fichiers de conf modulaire (comme les sites-avaible) soient bien présent:
- Mise à jour éventuellement de ses configurations personnalisées en fonction d'une mise à jour réalisée sur les composants:
Par exemple, rétablisement du lien, mise à jour de certains attributs ... etc. met à jour ces configurations, ou indique à l'utilisateur que ton
application ne sait pas se configurer automatiquement pour "telle version" du composant et qu'il va devoir éventuellement corriger le
fichier "blabla" à la mano.
- Si le composant ne permet d'inclure des configurations partagées ... c'est plus génant car il te faut gérer tout le fichier de configuration. Et là
tu augmentes un risque important de conflit avec d'autres applicatifs qui utilise aussi ce composant ! Il peut même être préférable de s'orienter
vers un autre composant équivalent, mais qui gère cette modularité...
On pourrait dire que si le composant est "instanciable" pour différents applicatifs c'est plus facile sinon, c'est grosse galère car il faut faire du
chirurgical dans la conf tout en prenant le risque de planter un autre applicatif.
Autre idée pouvant peut-être vous aider:
- Dans le cadre d'un macro applicatif comme OBM, Peut-être que la gestion d'une tâche (au sens tasksel) pourrait être aussi une piste interressante ?
Je ne connais pas précisément l'ensemble des briques logicielles que vous utilisez, mais intègrez dans vos critères de choix de ces composants cette
notions de flexibilité de configuration. Celà permettra plus facilement son intégration dans une distribution.
Voilà, j'ai pas apporté réellement de solution, mais simplement détaillé quelques reflexions qui pourront peut-être vous aider.
Bon courage, et vivement qu'on ait OBM sur Debian !
Bon week-end.
Salokine.
Le Thursday 13 November 2008 23:44:32 Sylvain GARCIA, vous avez écrit :
> Mon but est d'intégrer au fur et a mesure dans les distribs (Debian ET
> Ubuntu) tous les composants d'OBM. Cela est difficile a gérer car OBM a
> besoin d'une configuration spécifique pour chaque services, et je n'ai pas
> trouver d'exemple d'autres logiciels (dans Debian) qui utilise par exemple
> cyrus avec une conf spécifique, et c'est un peu la même chose pour tous les
> services qu'obm a besoin.
Le Friday 14 November 2008 01:42:39 Christian Bayle, vous avez écrit :
> Salut,
> Sinon, sur les problèmes de conf avec ldap/exim/.. on a exactement les
> mêmes problèmatiques dans gforge.
> Avec le temps les choses s'améliorent et les paquets fournissent de plus
> en plus les moyens, de modifier proprement leur conf.
>
>
> Bon courage
>
>
> Christian
Reply to: