Mysql m’a “tuer” ! Maia aussi !

Tout part d’une notification du monitoring xymon à propos de portaudit concernant une vulnérabilité sur mysql56-server.

Capture d’écran 2015-07-21 à 16.30.02

 

S’en suit la procédure standard de mise à jour:

root@distran:~ # portmaster mysql56-server

Tout se déroule correctement jusqu’au moment ou je décide de vérifier l’accès á la base de données.
Et la c’est le FAIL. Il me dit qu’il trouve pas la socket.

Le premier réflèxe est d’aller jeter un oeil au log de mysql:

20:06:09 UTC – mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Et mysql crash en boucle avec ce message sans plus de détail.
Mes mails reposant sur postfixadmin et donc la base de données, je décide de ne pas perdre de temps et de reínstaller les bases avec les dumps nocturnes.
La perte de données est faible voir nulle car ce sont des bases de données pour les mails et je n’ajoute pas de nouveaux utilisateurs chaque jour.
Néanmoins, dans le cas d’une base critique fréquemment mise á jour, j’aurais utilisé les bin-log.
Techniquement, je conserve un backup de la base broken et je recommence from scratch:
# mv /var/db/mysql /var/db/mysql.old
# mkdir /var/db/mysql ; chown mysql: /var/db/mysql
# /usr/local/etc/rc.d/mysql start

Puis utilisation des dump noctures:
# echo « create database mysql » | mysql
Je relance mysql et la rebelle tout crash en continue avec le même message que plus haut.. Youpi ! vive les backup qui marchent pas ! 🙂
Je décide de rebuild tout sauf la db mysql et de recréer les utilisateurs via les grant d’origine á la main en récupérant les l/p dans les fichiers de conf postfixadmin et maia.
# echo « create database postfix » | mysql
# echo « create database maia » | mysql
# zcat postfix_xxxxx.sql.gz | mysql  postfix;
# cat maia_xxxxx.sql.gz | mysql maia
# mysql
mysql> grant all privileges to postfix.* blabla
mysql> grant all privileges to maia.* blabla
A ce point, on se dit “ouf” c’est fini.
Et même pas, dans les logs maillog apparait ce joli message:
Jul 19 22:31:35 distran maiad[15376]: (15376-03) TROUBLE in check_mail: Take Action! FAILED: DBD::mysql::st execute failed: Column ‘autolearn_status’ cannot be null at /usr/local/sbin/maiad line 4410, <GEN18> line 159.
Jul 19 22:31:35 distran maiad[15376]: (15376-03) PRESERVING EVIDENCE in /var/maiad/tmp/maia-20150719T223135-15376
Jul 19 22:31:35 distran postfix/smtp[16349]: C2D1E895191: to=<nicolas@lienard.name>, orig_to=<root@distran.org>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.9, delays=0.27/0.01/0/0.62, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=15376-03, Take Action! FAILED: DBD::mysql::st execute failed: Column ‘autolearn_status’ cannot be null at /usr/local/sbin/maiad line 4410, <GEN18> line 159. (in reply to end of DATA command))
 Humm, je me fais tué une 2eme fois par maia.
il est tard, et je veux en finir. je google rapidement mais ne trouve rien sur ce bug.
Je jete un oeil sur
 /usr/local/sbin/maiad a la ligne 4410
UPDATE maia_mail SET score = ?, autolearn_status = ? WHERE id = ?
Ok donc il y a un souci lors des updates sql de maia avec le champs autolearn_status qui ne peut plus être “null”.
Je regarde la description de la table en question:
mysql> desc maia_mail;

+------------------+------------------+------+-----+-------------+----------------+
| Field            | Type             | Null | Key | Default     | Extra          |
+------------------+------------------+------+-----+-------------+----------------+
| id               | int(10) unsigned | NO   | PRI | NULL        | auto_increment |
| received_date    | datetime         | NO   | MUL | NULL        |                |
| size             | int(10) unsigned | NO   |     | NULL        |                |
| sender_email     | varbinary(255)   | NO   | MUL | NULL        |                |
| envelope_to      | blob             | NO   |     | NULL        |                |
| subject          | varchar(255)     | NO   | MUL | NULL        |                |
| contents         | longblob         | NO   |     | NULL        |                |
| score            | float            | YES  | MUL | NULL        |                |
| autolearn_status | varchar(15)      | NO   |     | unavailable |                |
+------------------+------------------+------+-----+-------------+————————+
Le paramètre NULL est effectivement à “No”. Comment cela pouvait-il fonctionner auparavant ??
Je regarde á l’intérieur et il y a bien des rows á null donc ca marchait comment avant ? 🙂
Pour en finir. j’altère la table:
mysql> alter table   maia_mail MODIFY autolearn_status varchar(15)
Le résultat:
mysql> desc maia_mail;

+------------------+------------------+------+-----+-------------+----------------+
| Field            | Type             | Null | Key | Default     | Extra          |
+------------------+------------------+------+-----+-------------+----------------+
| id               | int(10) unsigned | NO   | PRI | NULL        | auto_increment |
| received_date    | datetime         | NO   | MUL | NULL        |                |
| size             | int(10) unsigned | NO   |     | NULL        |                |
| sender_email     | varbinary(255)   | NO   | MUL | NULL        |                |
| envelope_to      | blob             | NO   |     | NULL        |                |
| subject          | varchar(255)     | NO   | MUL | NULL        |                |
| contents         | longblob         | NO   |     | NULL        |                |
| score            | float            | YES  | MUL | NULL        |                |
| autolearn_status | varchar(15)      | YES  |     | unavailable |                |
+------------------+------------------+------+-----+-------------+————————+
Et tout refonctionne ! OUF !

Leave a Reply

Your email address will not be published. Required fields are marked *


nine + = 14