[erledigt] Relution kann aus Docker-Container die mariadb auf Host nicht erreichen

Apps & App Center
, , ,
#1

Hallo,

Relution startet bei mir nicht mehr, da relution nicht mehr auf die Datenbank zugreifen kann (nicht nur 172.17.42.1, sodern auch alle anderen IP-Adressen des Hosts funktionieren nicht).

root@ucs1:~# docker exec -ti wonderful_curie mysql relution -h 172.17.42.1 -u relution -p
Enter password:
ERROR 2002 (HY000): Can't connect to server on '172.17.42.1' (115)

ohne Angabe des Hosts:

root@ucs1:~# docker exec -ti wonderful_curie mysql relution -u relution -p
Enter password:
ERROR 2002 (HY000): Can't connect to local server through socket '/var/lib/mysql/mysql.sock' (2)

aus welchen Gründen auch immer scheint der Port 3306 aus dem relution-docker-container heraus betrachtet geschlossen zu sein.

[root@relut-08246147 relution]# (echo >/dev/tcp/172.17.42.1/3306) &>/dev/null && echo "open" || echo "close"
close

Auf dem Host selber ist er offen und erreichbar und auch mariadb ist problemlos erreichbar.

root@ucs1:~# (echo >/dev/tcp/172.17.42.1/3306) &>/dev/null && echo "open" || echo "close"
open

auf dem Host liefert iptables -t nat -L -v zurück:

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
31179 2048K DOCKER     all  --  any    any     anywhere             anywhere             ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
1690  101K MASQUERADE  all  --  any    !docker0  172.17.0.0/16        anywhere
   0     0 MASQUERADE  all  --  any    !br-8d9804b1945d  172.16.2.0/24        anywhere
   0     0 MASQUERADE  tcp  --  any    any     172.16.2.2           172.16.2.2           tcp dpt:8000
   0     0 MASQUERADE  tcp  --  any    any     172.17.0.1           172.17.0.1           tcp dpt:9090
   0     0 MASQUERADE  tcp  --  any    any     172.17.0.2           172.17.0.2           tcp dpt:3000
   0     0 MASQUERADE  tcp  --  any    any     172.17.0.4           172.17.0.4           tcp dpt:8777
   0     0 MASQUERADE  tcp  --  any    any     172.17.0.5           172.17.0.5           tcp dpt:9001
   0     0 MASQUERADE  tcp  --  any    any     172.17.0.3           172.17.0.3           tcp dpt:http-alt

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
12739 1042K DOCKER     all  --  any    any     anywhere            !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain DOCKER (2 references)
pkts bytes target     prot opt in     out     source               destination
8204  559K RETURN     all  --  docker0 any     anywhere             anywhere
   0     0 RETURN     all  --  br-8d9804b1945d any     anywhere             anywhere
   0     0 DNAT       tcp  --  !br-8d9804b1945d any     anywhere             anywhere             tcp dpt:40003 to:172.16.2.2:8000
   0     0 DNAT       tcp  --  !docker0 any     anywhere             localhost            tcp dpt:9090 to:172.17.0.1:9090
   0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:3000 to:172.17.0.2:3000
   0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:8777 to:172.17.0.4:8777
   0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:9001 to:172.17.0.5:9001
   0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:40005 to:172.17.0.3:8080

Viele Grüße,
Christoph

#2

Hi Christoph.

Ich habe keine Erklärung und auch keine Lösung.

Aber den Hinweis, dass es da womöglich weitere Fälle gibt:

Wir (EGroupware) wissen aktuell leider nicht was da passiert. Auf unseren Kundensystemen ist das bislang nicht aufgetreten.

(Ab) wann ist das bei dir aufgetreten?
Update? Von was?

Stefan
EGroupware Community Manager

#3

Hallo Stefan,

es war auch bei mir ein Firewall-Problem, ich habe den Port 3306 pauschal über die Firewall geöffnet und jetzt funktioniert auch Relution wieder.

ucr set security/packetfilter/tcp/3306/all=ACCEPT
service univention-firewall restart

Vielleicht sollte Univention hier die passende Firewall-Regel automatisch ausspielen (Beschränkt auf die tatsächlich relevanten IP-Adressen bzw. Interfaces / docker0 ?)

Viele Grüße,
Christoph

1 Like
#4

Je nach dem was vor dem UCS sitzt kann das ziemlich unangenehm werden.

Was war denn bei dir der Auslöser?

Stefan

#5

Hallo Stefan,

daß die Firewall-Regel für den Port noch angepasst werden musste, ist klar. Aber es ging mir ja fürs Erste auch darum, die Ursache zu finden, warum die Datenbank nicht aus dem Container erreichbar war.

Auslöser war vermutlich auch hier das UCS-Update auf 5.0.8

Gruß,
Christoph

#6

Just wanted to let anyone else know. After the recent UCS updates my WordPress site no longer worked. Gave a database error. The solution above worked for me.

Mastodon