| Version 2 (modified by anonyme, 6 years ago) (diff) |
|---|
Un meeting pour regler plusieurs questions et orientations
Date et heure
Nouvelle date: mardi 10 mai prochain, 20h heure de paris.
Presences
- TheAnarcat
- NitWoh?: dispo seulement le 7,9,10,11 Mai ou le soir des 5,6, 8 Mai. dispo completement a partir du 19 Mai
Medium
Sur quoi on fait ca? On se rencontre sur IRC pour en decider.
IRC
Plus de gens peuvent y participer, malgre tout probleme hardware/firewall.
~#alternc sur freenode - acces web garanti pour les enmures
De plus, TheAnarcat peut faire un bot pour faire le gateway IRC/Jabber.
SIP
Standard ouvert qui fonctionne ;)
Skype
Ca marche, mais c'est pas tout le monde qui l'a et je dois descendre au sous-sol.
Points a discuter
Prochain release: 0.9.4 ou 0.9.3.1
La question ici est de savoir si on continue avec le [plan elabore dans le bugtracker pour la version 0.9.4| http://mantis.alternc.org/view.php?id=373], ou si on force un release contenant les bugfixes que anarcat a entre lors de ses tests de mise a jour pre-1.0 -> 0.9.3.
Anarcat suggere de faire une nouvelle version. Elle pourrait s'appeler 0.9.3.1 pour clarifier qu'il n'y a pas de nouvelles fonctionalites... Il y a deja un bug pour ce release dans le bugtracker: http://mantis.alternc.org/view.php?id=436
Decision: on fait une 0.9.3.1 rapidement pour regler les bugs et donner un upgrade path de woody. On regle la date pour 20/05/2005.
Le cas woody
J'ai fait un backport de gettext pour woody, car notre repo officiel n'en n'avait plus. Le package woody est toujours inexistant, d'ailleurs. Anarcat a fait des packages woody issus du CVS, et on devrait donc faire un release pour woody.
Desicion: on fait un dernier release pour woody, qui sera l'upgrade path vers sarge. On force donc les hebergeurs a migrer vers sarge.
Les auto-builds debian3.alternc.org
Les autobuilds ne marchent plus. Ils devraient s'appeler "package-version-timestamp" et non "package-version.timestamp.nightly" (non?)
Ca devrait s'appeler nightly.alternc.org. :)
Le probleme est regle: c'etait le cron qui decronait.
Vinci: donc le principe du nightly build est le suivant : tous les jours sur cvs.alternc.org, les modules cvs ayant ete modifies dans la journee sont recompiles et envoyes sur debian3.alternc.org/sarge
<jerom> il faut que je mette en place la possibilite de supprimer des paquets dans le repository <jerom> todo donc
L'archive debian.alternc.org
Aussi, anarcat aimerait bien avoir acces a l'autobuilder, pour quand il le brise.
<vinci> bein cvs# cat /etc/cron.daily/nightlybuild <anarcat> merveilleux, j'ai acces alors <anarcat> ToDo: documenter tout ce bordel :) <vinci> TODO: remplir le module alternc-doc ToDo: <jerom> et si on faisait plutot un target cvs dans le repository officiel ?
Webalizer: pourquoi webalizer-i18n?
Est-ce que c'est seulement pour woody? La homepage de webalizer semble dire que webalizer est deja multi-lingue....
<vinci> oui, webalizer est multilingue avec choix de LA langue a la compilation <vinci> donc n'ayant pas mieux, j'avais cree webalizer-i18n qui compile webalizer en 4 langues <vinci> et cree 4 binaire : webalizer-FR webalizer-EN -ES -DE <vinci> sauf que depuis ... <vinci> ... le package sarge integre un patch gettext ... <vinci> on peut choisir la langue via $LOCALE <anarcat> alors il faudrait patcher alternc-webalizer pour utiliser ces nouveaux trucs sous sarge, right? <vinci> je crois que c'est deja fait <anarcat> verifier alors <anarcat> tester <anarcat> alors on laisse webalizer-i18n dans woody <vinci> oui <anarcat> ou un backport <anarcat> et pour sarge, on n'a qu'un dep vers webalizer <vinci> je dirais plutot un backport sauf que backport.org n'en propore pas ... donc TODO <vinci> enfin, alternc-webalizer est (a mon avis) a tester grave ..
resume: (webalizer-i18n ou backport) pour woody, pour sarge, on se fie sur le webalizer par defaut. Il faut tester que alternc-webalizer tient la route.
postfix, proxymaps et mount --bind
Mount --bind marche (bien!) sous woody pour permettre a postfix de sortir du chroot. Le postfix de sarge permet les proxymaps, alors l'install de sarge les utilise... Cependant, il y a des problemes avec les proxymaps, qui ne fonctionnent pas dans certaines circonstances. En particulier, en essayant de configurer des filtres de spam ici, j'ai obtenu des erreurs selon lesquelles smtpd ne pouvait pas parler a mysql. Normal, la config d'alternc ne met pas de proxymap devant les alias. Mais, en ajoutant le proxymap, oh surprise, postfix refuse de livrer les mails quand meme:
May 3 16:09:57 marvin postfix/local[25151]: fatal: mysql:/etc/postfix/myalias.cf: proxy map is not allowed for security sensitive data
Le probleme est regle sous 2.2, comme en temoigne [la doc| http://www.postfix.org/postconf.5.html#alias_maps]. Qu'est-ce qu'on fait?
Je suggere de virer tout en --bind, jusqu'a ce que postfix 2.2 arrive dans debian, ce qui devrait prendre encore quelques millions d'annees.
Deux options:
<anarcat> mysql stop <anarcat> mv /var/run/mysqld /var/spool/postfix/var/run <anarcat> ln -s /var/spool/postfix/var/run /var/run/mysqld <anarcat> mysql start
ou mount --bind. Decision: on va vers le symlink.
/etc/alternc/sendmail: pourquoi???
On a toujours des problemes avec ce script-la, qui n'est pas executable. Pourquoi utiliser ce tel script?
Nitwoh soutient que ce script devrait disparaitre : Son seul interet est d'apposer le GID du membre utilisant un mail() dans l'entete Message-ID.
<vinci> l'utilite originelle de ce truc est d'eviter le spam via mail() <vinci> ainsi le fournisseur de hosting peu savoir quel gid a poste le mail <anarcat> c'est facile a contourner <jerom> en quoi il gene ce srcipt ? <anarcat> 1- il est inutile <vinci> vrai <anarcat> 2- il est pas chmod +x <vinci> corrigeable, mais vrai pour l'instant <anarcat> 3- il est pas installe au bon endroit <vinci> vrai (corrigeable) <anarcat> 4- maintenance de plus... <anarcat> ie il demande une modif au php.ini <jerom> bof, pas lourd <anarcat> et on veut reduire de telles modifs
Vu que les problemes ci-haut peuvent etre tous regles, on s'entend pour garder le script, mais l'arranger:
<vinci> je vote comme jerome et je m'accole a cette TODO la <vinci> - chmod +x <vinci> - deplacement du script dans /usr/sbin/sendmail.alternc <vinci> - verif de son bon fonctionnement malgre le chdir par exemple
SuExecPhp? revival: 1.0?
arnaud_lb (?) a ameliore mon idee du SuExecPhp?, et je crois que ca commence a prendre serieusement forme, cette option. Avec les problemes de securite que nous avons connu, ca serait une bonne idee, selon moi, de prendre cette voie pour la 1.0. On pourrait cibler l'integration du suexecphp dans une 0.9.5 de test, pour s'assurer que tout est en ordre. On a deja un script de migration en place, qui semble fonctionner, quoiqu'il y a plein de petites modifs a faire a gauche et a droite:
Bon. Il semble que ceci cause probleme car suphp, comme suexec + php, demande un process CGI par page PHP, ce qui est hors de question. On remet ceci a plus tard.
pop-before-smtp
<anarcat> donc 1: on garde /var/lib/pop-before-smtp <anarcat> 2: il faut changer la conf dans sarge <anarcat> 3: jerom, tu parlais pas de simplement virer pop-b4-smtp? <vinci> - verifier le fic de conf de popb4 dans sarge <vinci> - modifier main.cf pour que cas marche <vinci> - tester <jerom> je veux bien prendre ca en charge
Pour 3: on decide de garder pop-before-smtp parce que plusieurs vieux clients risque de ne pas le supporter.
