Re: Nouveaux paquets [OBM]: Réflexion sur la Gestion des composants partagées
Salokine Terata <salokine.terata@free.fr> writes:
> [ une bonne analyse ]
>
> 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.
Oui, ou par un applicatif intermédiaire...
> Les Axes de réfléxion:
> - Si le composant le permet. (apache en fait le permet), externaliser
> la conf spécifique.
Il y a 2 aspects là-dedans:
- externaliser la conf dans un fichier séparé. Ceci est nécessaire
pour commencer à gérer ces conf modulaire avec les paquets
- isoler "logiquement" la conf de façon à ce qu'une conf évite de
casser une application voisine. Eh oui, même avec un fichier séparé,
une application peut casser la conf d'une application gérée par le
même serveur apache. On peut dite que ça relève du bug, mais c'est
un risque supplémentaire lors des upgrades.
> 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.
Oui.
> 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.
En te basant sur quelle info ? Ton applicatif a été prévu pour le
composant version a et tu ne pouvais connaître à ce moment comment
gérer un upgrade vers le même composant en version b
Le seul élément qui puisse apporter des informations (notez que je
n'ai pas écrit "scripts") sur la façon de gérer l'upgrade du composant
version a vers composant version b est le composant version b. Pas
l'applicatif qui utilise 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:
Est-ce que tu penses aussi en vérifier le contenu ?
> - 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.
Là, je suis perdu. Tu as des exemples ??
> - 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 peut aussi gérer une version découpée du fichier et le racoller
dans support du serveur. C'est fait pour exim.
Avec ça, on retombe dans le cas précédent.
> 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.
C'est à éviter.
> 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 ?
Ca ne règle pas le problème des la gestion de la conf.
> 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.
Pas de problème. C'est toujours bon de discuter :-)
A+
--
Dominique Dumont
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner
Reply to: