Requêtes POST non interprétées par PHP

Il faut que je me note ça quelque part, ce sera donc ici. Ce billet fait écho à ce topic sur le forum OVH : http://forum.ovh.net/showthread.php?t=72560.

En bref, il semble que PHP cesse d’interpréter correctement la valeur de la variable post_max_size si celle-ci est de 2G. Le résultat est que plus aucun formulaire web ne fonctionne sur aucun des sites concernés par le php.ini dans lequel se trouve cette valeur. Lorsque le formulaire est validé, la page est simplement rafraichie sans que rien d’autre ne se passe.

J’ignore quelles sont les versions de PHP qui sont affectées (pas eu le temps de creuser, désolé) mais j’ai remarqué que la personne qui a rapporté ce bug sur le forum OVH a un serveur dont la configuration est assez semblable à celle de nombreux serveurs dont je m’occupe : Debian (Lenny) + Virtualmin. Une raison de plus pour que je me note ça en vitesse … et à plus forte raison si la solution est toute simple : il suffit de remplacer la valeur 2G par 2000M 🙂

Virtualmin + Debian : Usermin pas démarré au boot

A tous les coups c’est pareil : il suffit que je prenne quelques jours de congé pour qu’il se passe un truc bizarre qui m’oblige à bosser. Ca doit être la loi de Murphy…

Enfin bref, voici donc le truc bizarre du jour (sur un serveur installé en Debian Lenny + Virtualmin) : un client me dit que Usermin (le webmail qui vient avec Virtualmin et qui se trouve sur le port 20000 – au contraire de Webmin qui se trouve sur le port 10000) n’est plus accessible suite à un reboot de son serveur. Vérification faite, Usermin n’était tout simplement pas lancé. Il a suffit donc de :

/etc/init.d/usermin start

Et tout est rentré dans l’ordre. Seulement voilà, c’est bien … mais pas suffisant : au prochain reboot, Usermin risque fort de ne plus être lancé. On a beau ne pas rebooter tous les jours, il faut tout de même que cela tienne le reboot ! Je m’empresse donc de vérifier sur un serveur de test et j’arrive à reproduire le problème : Usermin ne se lance effectivement plus au démarrage. Cela doit probablement dater d’une des dernières mises à jour de Usermin (peut-être la version 1.480 datant du 5 aout dernier mais j’ignore précisément laquelle car je reboote fort heureusement assez rarement).

Après une petite recherche Google, il semble que la solution n’est pas bien compliquée (mais pas forcément facile à trouver, d’où ce billet). Elle se trouve ici : http://readlist.com/lists/lists.sourceforge.net/webadmin-list/2/13638.html. Il suffit donc de :

insserv usermin

Et le script d’init est à nouveau correctement activé (au besoin, installer le paquet insserv par apt-get install). Testé et approuvé : ça tient à présent le reboot.

Voilou, ce n’est pas très fouillé et je n’ai pas testé à fond … mais bon, n’oublions pas que je suis en vacances 😉

Debian – Installation Virtualmin – Le bug Postfix

Tiens, depuis la récente mise à jour de Postfix dans les dépots Debian Lenny, il me semble qu’il y a comme un souci avec l’installateur automatique de Virtualmin.

Les utilisateurs assidus de Virtualmin savent que l’installation de la bête est d’une simplicité à faire ricaner un enfant de 3 ans. Pour installer Virtualmin sur une Debian, il suffit de :

wget http://software.virtualmin.com/gpl/scripts/install.sh
chmod +x install.sh
./install.sh

Et il ne reste plus qu’à laisser tourner le bouzin. Glop glop glop 🙂

Sauf que voilà, depuis quelques jours … pas glop.

En lançant l’installateur “comme d’habitude”, on se retrouve avec une belle erreur :
E: Package postfix-tls has no installation candidate
Et, quelques lignes plus loin :
FATAL – Cannot continue installation.

En version longue, ça donne ça :

/E: Package postfix-tls has no installation candidate                                                                                                                                 /usr/bin/apt-get --config-file apt.conf.noninteractive -y --force-yes install postfix postfix-pcre webmin usermin ruby libapache2-mod-ruby libxml-simple-perl libcrypt-ssleay-perl unzip zip libfcgi-dev bind9 spamassassin spamc procmail libnet-ssleay-perl libpg-perl libdbd-pg-perl libdbd-mysql-perl quota iptables openssl python mailman subversion ruby irb rdoc ri mysql-server mysql-client mysql-common postgresql postgresql-client awstats webalizer dovecot-common dovecot-imapd dovecot-pop3d proftpd libcrypt-ssleay-perl awstats clamav-base clamav-daemon clamav clamav-freshclam clamav-docs clamav-testfiles libapache2-mod-fcgid apache2-suexec-custom scponly apache2 apache2-doc libapache2-svn libsasl2-2 libsasl2-modules sasl2-bin php-pear php5 php5-cgi libgd2-xpm libapache2-mod-php5 php5-mysql postfix-tls failed.  Error (if any): 0

Displaying the last 15 lines of /root/virtualmin-install.log to help troubleshoot this problem:
INFO - 2011-05-18 20:17:58 - OK
INFO - 2011-05-18 20:18:03 - Hit
INFO - 2011-05-18 20:18:03 - Removing Debian standard Webmin package, if they exist...
INFO - 2011-05-18 20:18:03 - Removing Debian apache packages...
DEBUG - 2011-05-18 20:18:04 - Reading
INFO - 2011-05-18 20:18:04 - Installing dependencies using command: /usr/bin/apt-get --config-file apt.conf.noninteractive -y --force-yes install postfix postfix-pcre webmin usermin ruby libapache2-mod-ruby libxml-simple-perl libcrypt-ssleay-perl unzip zip libfcgi-dev bind9 spamassassin spamc procmail libnet-ssleay-perl libpg-perl libdbd-pg-perl libdbd-mysql-perl quota iptables openssl python mailman subversion ruby irb rdoc ri mysql-server mysql-client mysql-common postgresql postgresql-client awstats webalizer dovecot-common dovecot-imapd dovecot-pop3d proftpd libcrypt-ssleay-perl awstats clamav-base clamav-daemon clamav clamav-freshclam clamav-docs clamav-testfiles libapache2-mod-fcgid apache2-suexec-custom scponly apache2 apache2-doc libapache2-svn libsasl2-2 libsasl2-modules sasl2-bin php-pear php5 php5-cgi libgd2-xpm libapache2-mod-php5 php5-mysql postfix-tls
Reading package lists...
Building dependency tree...
Reading state information...
bind9 is already the newest version.
iptables is already the newest version.
libsasl2-2 is already the newest version.
Package postfix-tls is a virtual package provided by:
postfix 2.5.5-1.1+lenny1
You should explicitly select one to install.

FATAL - Fatal Error Occurred: Something went wrong during installation: 0
FATAL - Cannot continue installation.
FATAL - Attempting to remove virtualmin repository configuration, so the installation can be
FATAL - re-attempted after any problems have been resolved.
FATAL - Removing temporary directory and files.
FATAL - If you are unsure of what went wrong, you may wish to review the log
FATAL - in /root/virtualmin-install.log

Pan dans les dents ! 🙁

On comprend bien que le paquet postfix-tls pose problème, mais que faire ? La solution existe, elle est un poil difficile à trouver (d’où ce billet) et elle se trouve sur le forum Virtualmin :  http://www.virtualmin.com/node/18213

En bref, il suffit d’éditer l’installateur (install.sh donc) et de commenter les lignes 97, 98 et 99 :

if [ "$?" != 0 ]; then
       debdeps="$debdeps postfix-tls"
fi

On relance le bouzin et (soulagement, volupté), ça remarche.

Release OVH : OVHm et les domaines avec accents

Tiens, un petit bug dans la release OVH … et du coup, hop, un petit billet 🙂

Comme le savent les utilisateurs de cette distribution, OVHm est le module Webmin qui permet de gérer les hébergements et les noms de domaines qui se trouvent sur le serveur. Ce module permet sans problème de créer un hébergement pour un nom de domaine contenant des caractères spéciaux, notamment des accents. Par exemple accentué.com <– ce nom de domaine est libre à l’heure où j’écris ces lignes, allez-y, foncez ! 😉 Il suffit simplement d’indiquer à OVHm le punycode de votre nom de domaine (dans notre exemple : xn--accentu-hya.com) et ça fonctionne très bien.

Là où ça se gâte un peu, c’est quand on souhaite créer un alias de nom de domaine : on a beau essayer accentué.com ou bien xn--accentu-hya.com, rien n’y fait, OVHm nous envoie sur les roses :

Moche hein ? Oui, mais rien de grave : OVHm refuse en fait qu’un nom de domaine contiennent deux tirets qui se suivent.

La solution est toute bête, il suffit simplement d’aller modifier le fichier /usr/libexec/webmin/ovhm/ajouter_alias.cgi

Repérez la ligne :

&error ($text{'domaine_ko'}) if ($alias !~ /^[0-9a-zA-Z]+(-[0-9a-zA-Z]+)*(\.[0-9a-zA-Z]+)+$/);

Et remplacez la par :

&error ($text{'domaine_ko'}) if ($alias !~ /^[0-9a-zA-Z]+(-+[0-9a-zA-Z\-]+)*(\.[0-9a-zA-Z]+)+$/);

Fastoche !

Release OVH : spamassassin et le bug de l’an 2010

Un bug connu depuis belle lurette déclenche encore pas mal de faux-positifs sur certains spamassassin. C’est dû au fait qu’une des règles utilisées fai(sai)t que tout mail qui a une date éloignée dans le futur voit sa probabilité d’être considéré comme spam augmenter fortement. Jusque là, rien que de très normal : il est louche de voir passer des mails dont la date est en avance de plusieurs années sur le date présente. Oui mais voilà, la règle en question (assez ancienne) stipulait que 2010 est une année éloignée dans le futur … suffisamment éloignée pour titiller spamassassin. Pas de bol, on y est finalement arrivés en 2010 !

Ce bug a été très vite mis à jour dès le début de cette année, à vrai dire dès qu’un grand nombre d’admin ont commencé a voir passer des cargaisons entières de faux-positifs (des mails classés abusivement comme spam par spamassassin). Le bug a été rapidement corrigé et la situation est revenue à la normale. Cela supposait cependant de faire la mise à jour qui va bien … ce qui n’a toujours pas été fait à l’heure actuelle sur la distribution phare d’OVH : la release 2.

Pour ceux qui utilisent cette distribution et qui se servent de spamassassin, il convient donc de faire le mini-patch suivant : dans le fichier /usr/share/spamassassin/72_active.cf (ligne 565), remplacer :

header   FH_DATE_PAST_20XX    Date =~ /20[1-9][0-9]/ [if-unset: 2006]

Par :

header   FH_DATE_PAST_20XX    Date =~ /20[2-9][0-9]/ [if-unset: 2006]

Votre spamassassin considérera alors comme “futur éloigné” les dates de 2020 à 2099 (et non plus 2010 à 2099).