[AlternC-dev] Le package debian d'alternc

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

Benjamin Sonntag benjamin at globenet.org
Sam 8 Mai 19:12:52 CEST 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The Anarcat a écrit :

|>Oui, belle idée, mais la lecture de /usr/sbin/alternc.install peut
|>donner de serieux renseignements sur la complexité du machin ...
|
|
|Oui, certes, je l'ai lu. Je vais évidemment avoir à le relire et le
|relire assez souvent, j'imagine. :)
|
|N'empêche: tant qu'à avoir un package debian, aussi bien le faire
|proprement sinon, il ne sert à rien de conserver l'idée de faire AlternC
|debian-only. On aurait moins de problèmes de maintenance en *débarquant*
|des .debs et en s'orientant vers un tarball source simple (parce qu'il y
|a pratiquement aucune compilation à faire pour alternc) avec des
|instructions et un script d'install robuste.

On peut donc partir de 2 manières différentes :

- - se dire que l'on restera strictement debian-centric, (un peu 
embêtant, vu que beaucoup d'internautes on demandé si des portages *bsd 
ou redhat/fedora etaient prévus, et prêts à aider) dans ce cas, on met 
tout les scripts dans postint, prerm etc. on gère des dépendances sur 
les paquets debian stricts etc.
- - se dire que l'on veut faire un machin installable facilement sur une 
autre distribution, dans ce cas :
~    * on crée des script comme alternc.install, alternc.update etc.
~    * on signale les dépendances "simple" genre "ca a besoin d'apache 
;) " dans un fichier texte, dans lequel on spécifie les dépendances 
correspondantes dans les distributions visées (debian pour commencer) du 
genre "ca a besoin d'apache 1.3 = "apache>=1.3<2.0"
~    * on crée de PETITS scripts pour les distributions correspondantes 
(postinst/prerm dans le cas debian) qui se chargent de la partie 
spécifique à la distribution : dans le cas debian = interrogation via 
debconf, enregistrement des réponses dans /etc/alternc/alternc.conf et 
lancement de alternc.install tout simplement.

Personnellement, et je rejoins Jonathan là-dessus, vu le contenu et le 
boulot qu'il y a déjà sur alternc.install, je préfère la deuxième 
solution (le but est quand même de reconfigurer proprement tous les 
services utilisés par AlternC, justement pour qu'un non initié n'ai pas 
à aller trifouiller par défaut dans ses conf. Cette configuration 
automatique est quand même aussi un gros boulot en soi. )

- ------------------------------

Pour revenir au choix de mettre les ips d'apache en dur dans la conf 
(avec "Bind %%IP%%" et <VirtualHost %%IP%%:80> c'est un choix simple 
mais habituel en info de ma part : je ne fais pas faire à la machine ce 
pour quoi elle n'est pas faite. Un serveur peu (souvent) avoir plusieurs 
ip publiques, dans ce cas, il est généralement bien vu que seuls les 
services devant tourner sur une ip soient visibles sur cette ip .

Ainsi, si ma machine a 2 ip : l'une pour apache/postfix etc. et l'autre 
pour faire par exemple le dns secondaire d'un collègue, je ne voudrais 
pas qu'apache réponde AUSSI sur la seconde ip, c'est un peu un 
raisonnement proche de celui du firewalling : on interdit TOUT et on 
autorise ensuite point par point le plus précisément possible. Proftpd a 
d'ailleurs beaucoup de mal à créer un socket qui écoute sur $IP et non 
pas 0.0.0.0.


|Ça, ça serait plus facile à porter. Présentement, on est dans une
|situation que je sens ambigüe où AlternC a été partiellement engagé dans
|la voie de la Debianisation, sans opérer complètement la solution
|proprement.
|
|Ça, c'est grave. Peu importe alternc.install, tant qu'alternc.upgrade
|est vide, on est mal foutus, package debian ou pas.

exact, de l'importance donc de trouver une solution PROPRE au problème 
suivant :

A- on souhaite qu'AlternC configure complètement et proprement les 
services qu'il fournit (dns, web, mail, ml ...)
B- on souhaite que cela soit modulaire (alternc-mailman s'occupe de 
mailman ...)
C- on souhaite pouvoir REconfigurer un système après avoir modifié 
alternc.conf (genre migration => changement d'ip)
D- on souhaite pouvoir personnaliser ses fichiers de conf avec des 
entrées personnelles (cgi spéciaux, dns exotiques etc.) sans que ces 
spécificités ne soient perdues lors d'un alternc.update.
( toute précision ou nouveau point bienvenu ...)

On peut imaginer utiliser les scripts du genre apacheconf, mais qui ne 
marchent qu'avec apache, ou encore utiliser ucf pour configurer tous les 
services, mais je n'ai pas compris grand chose à ce machin 'ucf' ...

La solution qui avait donc été envisagée à l'époque était ce fameux mais 
inutilisé /usr/share/alternc/1.0/install/etc (je crois) qui reprennait 
les fic de conf écrasé par AlternC, permettant
A- ok.
B- non prévu, quoique le système de template / remplacement de variables 
pourrait bien marché en mode modulaire...
C- ok (au moins en partie le problème de bind par exemple, si on change 
d'ip, il faut réécrire TOUTES les zones ...)
D- ok (même si cela est inutilisable car alternc.install et aussi très 
destructif... un alternc.update ne recréant que la conf et n'écrasant 
pas les comptes mysql ou root/alternc est donc nécessaire ...)

Je ne vois donc pas de meilleure solution actuellement.

On pourrait imaginer, tout à fait autrement :
- - création d'un /etc/alternc/ avec les fic de conf spécifiques à 
AlternC de tous les services utilisés
(donc existance de /etc/alternc/apache /etc/alternc/bind etc.)
- - lancement de ces services dans un gros script de démarrage dans 
/etc/init.d/alternc (qui lancerait, dans le bon ordre et proprement : 
apache, mysql, postfix ...)
problème de ce système => très dépendant des distributions, risque 
d'entrer en conflit avec des conf existantes (genre port 80 occupé paske 
apache lancé avant alternc ;( ), et difficulté supplémentaire de 
maintenir des script d'init propre spécifiques aux différents services.

D'autres idées ? ??? ??

|Je vois la debianisation complète et la debconfisation (!) de
|alternc.install comme un pré-requis pour une procédure d'upgrade
|efficace.

Oui. mais debianisation complète ne signifie pas FORCEMENT suppression 
de alternc.install.

| Je vois pas. Il y a des milliers de serveurs roulant postfix/woody
|
|parfaitement, et mes serveurs ne font pas exception.

Il voulait parler des problèmes sur le postfix SARGE.
Pour ma part, j'utilise postfix sarge pour pleins de machines (dont 
Globenet et un projet de mail perso) sans aucun souci ...

|>Mais dans le genre moins pessimiste, l'installation d'un alternc actuel
|>sur une sarge est complètement possible avec un peu de persévérance et
|>les modifs pour une installation aussi automatisée que pour la woody
|>sont vraiment peu importantes (j'ai jamais pris de notes, donc vous dire
|>lesquelles ... :-D).
|
|
|Peu importe que le package soit fait pour woody ou sarge. Les jours de
|woody sont (je l'espère) comptés, et les différences de porting
|devraient être mineures.
|
|Il faut juste le faire, et là, je vois plein de monde (moi y compris)
|qui parlent mais qui n'avancent pas. :)

Oui, et je suis prêt à avancer dès que l'on aura trouvé une solution 
satisfaisante pour résoudre les 4 points abordés précédemment...

Pas simple en soi ...

@+

Benjamin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAnRUSd5FD2Z8azpwRAkWFAJ4lFFc+lJYD3L97GBWi8A6iFmvWYQCgko/8
FsCJLDySxDf9bVldJaY7x6Q=
=qhw4
-----END PGP SIGNATURE-----




Plus d'informations sur la liste de diffusion Dev