MySQL lauscht nur auf 127.0.0.1

Apps & App Center
#1

Moin,
wir haben folgendes auf einem UCS 4.2.3-310 beobachtet:

Installieren wir SuiteCRM aus dem Appcenter, funktioniert das nicht. Ein Blick ins Logfile im Docker-Container offenbart, dass es keine Verbindung zum MySQL bekommt.

Die Ursache war, das SuiteCRM vom Docker aus, sich zu 172.17.42.1 (Docker0 Interface) verbinden möchte, der mysql dort aber nicht lauscht:

Nach einem Restart des MySQL lauschte er entsprechend:

root@vm-ucsfresh42:~# netstat -tnlp |grep mysql
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1646/mysqld
root@vm-ucsfresh42:~# /etc/init.d/mysql restart
[ ok ] Restarting mysql (via systemctl): mysql.service.
root@vm-ucsfresh42:~# netstat -tnlp |grep mysql
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      31913/mysqld

Nachdem wir auf den vSphre Snapshot von vor der Installation zurückgegangen sind, verhält sich das System korrekt:

Vor der Installation von SuiteCRM:

root@vm-ucsfresh42:~# netstat -tnlp |grep mysql
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1760/mysqld
root@vm-ucsfresh42:~# ls /etc/mysql/conf.d/
mysqld_safe_syslog.cnf
root@vm-ucsfresh42:~# ucr search mysql
mysql/autostart: <empty>
 This variable configures the start mode of the MySQL daemon. If set to 'no' or 'disabled', the service cannot be started. If the variable is set to 'manually', the service isn't started during system boot, but can be enabled manually at a later point.

Nach der Installation:

root@vm-ucsfresh42:~# ucr search mysql
mysql/autostart: <empty>
 This variable configures the start mode of the MySQL daemon. If set to 'no' or 'disabled', the service cannot be started. If the to 'manually', the service isn't started during system boot, but can be enabled manually at a later point.

mysql/config/.*/.*: <empty>
 These variables in the format 'mysql/config/$group/$option=$value' configure arbitrary MySQL settings in the format for '/etc/mythe option name ends on a '/', the value is ignored and not printed.

mysql/config/mysqld/bind_address: 0.0.0.0
 These variables in the format 'mysql/config/$group/$option=$value' configure arbitrary MySQL settings in the format for '/etc/mythe option name ends on a '/', the value is ignored and not printed.

.....


root@vm-ucsfresh42:~# netstat -tnlp |grep mysql
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      4446/mysqld

Das Problem ist also für uns nicht nachstellbar und nicht erklärbar.

#2

Aber ist ist doch oben nachgestellt und erklärt?

Von den Effekten her würde ich sagen vorher läuft zwar mysql-server, aber das univention-mysql Paket ist noch nicht installiert. Dieses macht u.a. das MySQL global lauscht.

Idealerweise sollte die App bereits im preinst Skript testen, ob ein Zugriff auf die Datenbank funktioniert. Dann könnte die Installation abgebrochen bevor es zu dem eigentlichen Fehler kommt.

#3

Moin,
Deinen Post verstehe ich nicht.

  1. Wir setzen ja das MySQL nicht selber auf, sondern beschreiben in der App-Center-Config des Pakets SuiteCRM nur, dass wir einen Docker-Container mit MySQL brauchen. Prozessse des Basis-Systems sorgen dann dafür, dass der MySQL Server läuft und uns Umgebungsvariablen mit den Verbindungsadaten zur Verfügung gestellt werden (ein Teil diese Prozesses ist es wohl, das Paket univention-mysql)

  2. Ist das univention-mysql Paket ja in beiden Fällen installiert worden, nur der mysql wurden in ersten Fall nicht automatisch restartet

  3. Das komische ist, dass ich von einen und dem selben Software-Stand mit VM-Ware Snapshot zwei verschieden Ergebnisse hatte, einmal war der mysql restartet und einmal nicht. Deshalb habe ich geschrieben, das das Problem für uns nicht erklärbar ist.

Blöd ist, dass das für den Kunden der erste Kontakt zu SuiteCRM ist, und vielleicht der eine oder andere Kunde keinen Bugreport ausfüllt, sondern gleich weiter die nächste CRM Lösung evaluiert. Deshalb ist es für uns wichtig, auszuschließen, das der Kunde überhaupt auf so einen Fehler läuft.

Gruß
Sven

#4

ah, dieser Umstand war für mich nicht ganz klar. Mein Schluss war aufgrund des “Vor der Installation von SuiteCRM:” vs. “Nach der Installation:” dass vor der installation das univention-mysql Paket scheinbar nicht installiert war, da diese Variablen afaik eben von diesem Paket gesetzt werden.

Der Weg aus dem Dilemma den ich sehen würde wäre ein Check im preinst Skript der prüft ob MySQL global lauscht und eben abbricht wenn dies nicht der Fall ist. Abhängig was sonst noch auf dem System läuft könnte an dieser Stelle auch ein Restart der Datenbank durchgeführt werden.

#5

Das ändert aber nichts daran, dass ein unentschlossener Kunde unser Produkt nicht installieren kann und ggf. keinen Bugreport ausfüllt, sondern ein anders CRM evaluiert.

Laufen die perinst Befehle denn im Container oder auf dem Gastsystem? Ist der univention-mysql dann schon installiert?

Ich habe noch die Hoffnung, dass es sich irgendwie erklären lässt, warum es zwei verschiedene Ergebnisse gibt/gab und man das Problem an der Wurzel beheben kann (so es denn noch nötig ist).

#6

https://wiki.univention.de/index.php/Docker_Apps/Container_Scripts

preinst
An outer script called before the Docker Container is initialized, even before the image is downloaded. Its purpose is to check whether installation may be successful. For example, the preinst may fail if certain hardware requirements are not met. Any exit code other than 0 will result in cancellation of the installation process. If the installation of an App is the result of an image exchange (and thus more of an upgrade) the preinst is also called. This script may also be used to setup the Host environment for the App before container creation, e.g., creating an outer directory with proper permissions.

#7

Hallo,

wirklich erklärbar ist das für mich auch nicht. Ich habe es eben probiert, es funktioniert. Die Tests haben auch nie etwas derartiges ergeben.

Es stimmt schon: Nur MySQL alleine lauscht nur auf 127.0.0.1. Mit univention-mysql zusammen wird es für die Docker-Container freigegeben. So gesehen scheint im ersten Fall tatsächlich der Restart gefehlt zu haben.

Aber: Im postinst von univention-mysql steht explizit ein Restart des Dienstes. Also egal ob mysql vor 10 Tagen händisch installiert wurde oder als Abhängigkeit von univention-mysql mitgezogen wird: In beiden Fällen läuft der Dienst zunächst mit der “Vanilla”-Konfiguration, dann setzt univention-mysql neue Konfigurationen und startet den Dienst neu. Danach muss es eigentlich funktionieren (und wie gesagt: tut es in den Tests auch).

Was da schief gelaufen ist, kann ich leider nicht sagen. Bestenfalls hätte man was in den Logs von dpkg sehen können, möglicherweise sogar in der appcenter.log (insb. ein Fehler beim Restart des Dienstes während des postinst des Paketes).

Davon abgesehen kann man im preinst leider auch nicht wirklich etwas in der Richtung testen, weil zu dem Zeitpunkt univention-mysql möglicherweise noch nicht installiert ist.

Wenn das noch einmal auftritt, bräuchten wir die Logs des Systems, um das weiter zu untersuchen.

Viele Grüße
Dirk Wiesenthal

#8

Hallo,

ich habe es gerade erneut getestet und der Fehler ist wieder aufgetreten.
Ich sende unsere logs an die appcenter Email Adresse.

Viele Grüße
Heiko Ahrens

Mastodon