IspCP - Debianisation

[Nuxwin]

Bonjour à tous ;

Dans le cadre de l'empaquetage du logiciel ispCP (debianisation), je vous demande un petit coup de main ne serait-ce que pour le respect du FHS. En effet, la structure t-elle actuellement définie ne respecte pas le FHS et donc, la charte debian.

Je vous demande donc de m'aider en validant ceci :

Code:

- le daemon ---> /usr/sbin ;
- les script perl (backend) --> /usr/lib/ispcp-omega ( ou /usr/share/ispcp-omega ? ) ;
- les fichiers de configuration --> /etc/ispcp-omega ;
- les fichiers du GUI ---> /var/www/ispcp-omega (normalement /usr/share/ispcp-omega mais on ne peut pas à cause du suexec)

Bien entendu, certaines fichiers seront patchés en conséquence pour tenir compte de la nouvelle structure.

Par ailleurs, afin de respecter la charte debian, je vais devoir créer des sous paquet pour ce qui concerne la modification de fichiers de configuration fournis par les paquets debian, je pense notamment aux fichiers fournis par les paquet Postfix, bind9 .... En effet, la charte debian ne permet pas de modifier un fichier appartenant à un autre paquet en procédant par écrasement. Bref, vous l'aurez compris, cela ne va pas être facile. Je pense me baser sur le paquet source gforge pour cela. Autre point :

Via une installation standard, les deux modules libapache2-mod-fcgid et libapache2-mod-fastcgi sont installés. Ensuite, le module utilisé est selectionné pendant le setup selon le choix de l'administrateur (par défaut, il s'agit de fcgid). En ce qui concerne le paquet Debian, je voudrais permettre l'un ou l'autre mais pas les deux en même temps, soit :

Code:

Package: ispcp-omega-apache
Architecture: all
Depends: ispcp-omega-common, apache2 (>= 2.0.52), libapache2-mod-fcgid | libapache2-mod-fastcgi, php5-cgi, php5-gd, php5-idn, php5-imap, php5-mcrypt, php5-mhash, php5-mysql, debconf (>= 1.0.32) | debconf-2.0
Provides: ispcp-omega-gui
Description: virtual hosting control panel - web part (using Apache)
ispCP Omega is a virtual hosting control panel system for administrators.
.
It provides a ready to use system for web servers with:
* Domains, subdomains and aliases support
* HTTP, FTP, smtp, pop, imap and SQL services
* Domain and SQL data backup-restore support
* Bandwidth and disk quota limits
* Admin, Reseller and Users administration levels
* Hosting packages
* Bandwidth and web traffic statistics
.
This package contains the files needed to run the web part of ispCP on an Apache webserver.

Ce faisant, je me pose la question de savoir lequel des deux modules doit être installé si l'utilisateur ne le précise pas explicitement ? Pour ma part, je pense que le fcgid est le mieux. Qu'en pensez-vous ?

[itanium]

Je ferais si possible:

Quote:- le daemon ---> /usr/sbin
- les script perl (backend) --> /usr/share/ispcp
- les fichiers de configuration --> /etc/ispcp
- les fichiers du GUI ---> /var/www/ispcp

Concernant libapache2-mod, fcgid est un bon choix.

Pour ce qui est des fichiers de configuration, pourquoi ne pas lancer une commande à la fin de l'installation des debs?

du type:

Quote:/usr/share/ispcp/install/setup

Cela mettrait les fichiers à jours avec la bonne config (serveur dns, ip etc...)

[Nuxwin]

Bonjour ;

Pour ce qui est de la configuration des paquets, Debian propose une interface spécifique nommée debconf. C'est par l'intermédiaire de cette interface que les questions du setup sont posées. Cela implique de ré-écrire la partie setup. Debconf ne fait que poser les questions. Il n'effectue pas la configuration.

Le problème ici, c'est que plusieurs fichiers de configuration fournis par ispCP écrasent ceux qui sont déjà fournis par les paquets des services respectifs ( postfix, bind ... ) et pour faire ce genre de chose, la charte Debian est assez stricte. Notamment, il faut faire la distinction entre les fichiers de configuration qui sont gérés comme des conffiles ( fichiers traités spécifiquement par dpkg ) et les autres.

Par exemple ( a vérifier ) il me semble que les fichiers de configuration fournis par les modules libpache2-mod-fcgid et libpache2-mod-fastcgi sont des conffiles, tandis que le master.cf de postfix n'en est pas un. Ainsi, le remplacement de ces fichiers doit être géré différemment selon qu'il s'agisse de conffile ou non. Pour le cas des conffiles, je ne crois pas que je puisse opérer par écrasement pure est simple, de même que je ne suis pas certain que la charte autorise un remplacement directe via les scripts de maintenance ( postinst ). Pour ce qui est des autres, là, il faut au contraire les gérer via des script de maintenance en sachant que :

- Toutes modification locale opérées sur un fichier de configuration doit être préservée en cas de mise à jour d'un paquet ;
- Que les fichiers de configuration doivent être préservés en cas de dés-installation du paquet, et seulement supprimés si le paquet est purgé.

Ceci implique dont une logique métier assez rigoureuse en ce qui concerne la gestion de ces fichiers.

Admettons l'exemple suivant :

J'installe le serveur postfix qui fourni le fichier main.cf.

Ensuite, j'install le paquet ispcp-omega qui lui aussi, via ses script de maintenance génère une version spécifique du fichier main.cf.

Sur ce, que dois-je faire pour respecter la charte debian ?

- Remplacer sans autre mesure le fichier main.cf fourni par le paquet postfix ? Et alors quid du cas ou plus tard, je décide de purger le paquet ispcp... mais conserver mon serveur postfix ? dois-je faire en sorte qu'il soit possible de restituer le fichier de configuration par défaut fournit par le paquet postfix ?

Bref voilà en gros le problème auquel je suis confronté.

Pour résumer mon problème c'est de savoir comment bien gérer les fichiers de configuration qui sont partagés entre plusieurs paquets, paquets qui peuvent raisonnablement êtres installés de concert. Il s'agit ici d'un problème lié au respect de la charte Debian. Faire n'importe quoi, je sais faire

Merci pour le coup de main...

[itanium]

Je connais bien debconf et c'est pour cela que je pensais à une commande à faire manuellement à la fin du dpkg.

Malheureusement je ne vois pas, pour le moment, de solution qui permettrait de garder les fichiers de config d'origine des paquets (postfix etc..).

Le panel à besoin de ses propres fichiers et la gestion d'une version debian va être dur à maintenir si l'on doit patcher à chaque fois le panel. De plus, obtenir de l'aide sur une version patcher implique des changements de répertoire et gestions fichiers différentes de l'origine.

L'idée est pas mal de rendre le panel "apt-get installable" mais si on regarde la concurrence (cpanel, plesk & co), on passe forcement par des modifications de fichiers de conf.

Je continu de creuser...

[Nuxwin]

Salut ;

Ok, j'ai bien pris note de tes observations. Je vais donc suivre tes recommandation concernant les scripts de maintenance mais je vais faire en sorte que les fichiers puissent êtres restaurés. Le paquet source gforge contient de bon exemples pour cela.

Maintenant, tu l'as toi même soulevé sans le faire exprès, il y a un autre problème vis à vis de la charte debian qui doit absolument être réglé : C'est le respect du FHS.

Par exemple, tu imagine bien que les scripts du backend (les scripts perls) n'ont rien à faire sous /var/www... Et là effectivement, va falloir, outre déplacer ces fichiers, créer plusieurs patches pour modifier certains paths... Bref, c'est du boulot, j'en conviens volontiers mais bon, si on veux que le paquet puisse être soumis à debian pour intégration officiel, va bien falloir faire les choses correctement.

Si tu connais bien Debian, j'accepte volontiers ton aide.

[itanium]

Nous devrions peut être demander à la devteam de changer le répertoire des scripts perl dans l'installation d'origine.

Comme tu le dis si bien "les scripts du backend (les scripts perls) n'ont rien à faire sous /var/www" . De plus niveau sécurité je n'aime pas beaucoup /var/www