Mein Kollege Christopher hatte sich in seinem Artikel über MySQL-Replikation ja bereits über die etwas gewöhnungsbedürfte Behandlung von localhost vs. 127.0.0.1 bei MySQL ausgelassen. Wir konfigurieren bei uns laufende MySQL-Server in der Regel mit skip-networking oder, wenn z.B. (lokale) Replikation benötigt wird, zumindest mit bind-address = 127.0.0.1.
Auf einem Server, den wir nur während einer Übergangsphase ausnahmsweise betreuen, musste ich nun dennoch erstmal Rätselraten: Die Verbindung über 127.0.0.1 klappte nämlich nicht, obwohl MySQL sich durchaus an das Loopback-Interface gebunden hatte und keinerlei iptables-Regeln vorlagen, die einen Connect auf dieser IP verhindert hätten. Die wenig aussagekräftige Fehlermeldung:
$ mysql --host=127.0.0.1 -p
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
Insbesondere ein system error: 0 erschien mir ziemlich verwirrend, ist die 0 doch typischerweise der Exitcode für „alles klar, kein Problem“.
Nach einem Suchen war die Lösung überraschend einfach: Auf dem fraglichen System existierte eine /etc/hosts.deny mit ALL : ALL darin, und es war explizites Whitelisting mittels mysqld : 127.0.0.1 in der /etc/hosts.allow vonnöten. Für jemanden wie mich, der eigentlich grundsätzlich IP-basierte Zugriffe per iptables regelt und nicht per /etc/hosts.{allow,deny} durchaus eine Stolperfalle … und MySQL-typisch verwirrend, denn mit localhost funktioniert’s ja. (Wer Christophers Artikel nicht gelesen hat: Es funktioniert deshalb, weil MySQL bei der Angabe von localhost grundsätzlich eine socketbasierte Verbindung benutzt, weshalb nebenbei dann auch sämtliche Portangaben ignoriert werden – und eben auch die /etc/hosts.{allow,deny}.)