CT zu VM Verbindung (MySQL-Datenbank und z.B. Nextcloud)

[Devy76]

Hallo!

Folgendes Problem treibt mich zum Wahnsinn:

Bestimmte Anwendungen, wie zum Beispiel Nextcloud, die in VM´s oder CT´s auf Proxmox laufen, sollen auf eine Datenbank zugreifen die wiederum auf einen anderen Proxmox Container läuft. Nämlich einen Datenbankserver mit phpMyAdmin, MySQL.

Anpingen lassen sich die VMs CTs gegenseitig. Aber ich bekomme einfach keine Verbindung hin.

Bitte dringend Hilfe.

 

[noPa$$word]

Was funktioniert denn nicht? Bei MariaDB sollte der Zugriff vom User root über das Netzwerk standardmäßig nicht erlaubt sein.

 

[shrdlicka]

Hast du schon probiert ob du die entsprechenden ports erreichst? Zum Beispiel mit telnet:

telnet <IP> <PORT>

 

[Devy76]

Hast du schon probiert ob du die entsprechenden ports erreichst? Zum Beispiel mit telnet:

telnet <IP> <PORT>

Ja hab ich getestet. Keine Kommunikation. Root login habe ich bei der Konfiguration zugelassen. Bzw. nicht deaktiviert.

Die Datenbank kann einfach nicht angesprochen und gefunden werden

 

[shrdlicka]

kannst du mal die /etc/network/interfaces sowie die container config (mysql, und von einem anderen vm/ct) posten?

 

[bluesite]

ich denke es liegt daran das deine db nur auf localhost lauscht und nicht auf der ext IP

wie sieht deine /etc/mysql/debian.cnf aus?

steht da sowas drin (meine Daten natürlich rausgenommen)

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host     = 192.168.x.x
user     = root
password = meinsicherespasswort
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = 192.168.x.x
user     = root
password = meinsicherespasswort
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

bei netstat -tulpean muss es so aussehen

tcp 0 0 192.168.x.x:3306 0.0.0.0:* LISTEN 107 95293838 276/mariadbd

 

[Devy76]

Super danke!

Ich checke das heute abend mal und poste auch die entsprechenden Dateien

 

[Devy76]

kannst du mal die /etc/network/interfaces sowie die container config (mysql, und von einem anderen vm/ct) posten?

INTERFACE und CONFIG des CT mit der DB auf die ich zugreifen will:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.178.33/24
gateway 192.168.178.1


arch: amd64
cores: 4
features: nesting=1
hostname: mariadb
memory: 2048
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.178.1,hwaddr=CEE0:3D:C0:BB,ip=192.168.>
ostype: debian
rootfs: Toshiba4TB:subvol-505-disk-0,size=100G
swap: 2048
unprivileged: 1


BEI DER VM finde ich kein "interface"

 

[Devy76]

ich denke es liegt daran das deine db nur auf localhost lauscht und nicht auf der ext IP

wie sieht deine /etc/mysql/debian.cnf aus?

steht da sowas drin (meine Daten natürlich rausgenommen)

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host     = 192.168.x.x
user     = root
password = meinsicherespasswort
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = 192.168.x.x
user     = root
password = meinsicherespasswort
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

bei netstat -tulpean muss es so aussehen

tcp 0 0 192.168.x.x:3306 0.0.0.0:* LISTEN 107 95293838 276/mariadbd

Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 107 1265223 195/mariadbd
tcp 0 0 0.0.0.0:5355 0.0.0.0:* LISTEN 104 1264327 117/systemd-resolve
tcp 0 0 10.0.3.1:53 0.0.0.0:* LISTEN 0 1265319 266/dnsmasq
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 104 1264333 117/systemd-resolve
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 0 1266971 418/master
tcp 0 0 192.168.178.33:37102 199.232.138.132:80 TIME_WAIT 0 0 -
tcp6 0 0 :::5355 :::* LISTEN 104 1264330 117/systemd-resolve
tcp6 0 0 :::80 :::* LISTEN 0 1265194 177/apache2
tcp6 0 0 :::22 :::* LISTEN 0 1263532 1/init
tcp6 0 0 ::1:25 :::* LISTEN 0 1266972 418/master
udp 0 0 10.0.3.1:53 0.0.0.0:* 0 1265318 266/dnsmasq
udp 0 0 127.0.0.53:53 0.0.0.0:* 104 1264332 117/systemd-resolve
udp 0 0 0.0.0.0:67 0.0.0.0:* 0 1265315 266/dnsmasq
udp 0 0 0.0.0.0:5355 0.0.0.0:* 104 1264326 117/systemd-resolve
udp6 0 0 :::5355 :::* 104 1264329 117/systemd-resolve

 

[Dunuin]

ich denke es liegt daran das deine db nur auf localhost lauscht und nicht auf der ext IP

Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 107 1265223 195/mariadbd

Sieht so aus als wenn @bluesite gut geraten hat. Deine MariaDB lässt nur lokale Verbindungen zu. Musst du gucken, dass du in den MariaDB Konfig-Dateien das localhost bzw 127.0.0.1 auf deine IP im LAN abänderst.

 

[bluesite]

in der Standard Konfig ist das ja immer so nach der Installation aus Sicherheitsgründen,
meine lauscht auch auf meiner Ext-IP da mehrere LXC meine DB nutzen und ich nicht für jeden LXC nen eigene maria Instanz laufen lassen muss so

 

[Dunuin]

Ich persönlich verpasse lieber jedem LXC eine eigene MariaDB Instanz. Macht es dann leichter wenn ich mal später einen LXC wegwerfen will, weil ich dann einfach nur den LXC löschen muss, ohne da irgendwelche DB-Leichen zurückzubehalten die ich sonst erst zusätzlich noch manuell aus der DB löschen müsste. Und macht es mit Backups auch leichter. Sagen wir ich hätte einen MariaDB LXC und zwei Webserver LXCs die beide den selben MariaDB LXC benutzen. Verbocke ich nun etwas und muss einen Webserver LXC aus einem Backup wiederherstellen oder zu einem früheren Snapshot zurückrollen, dann würde zwar der Webserver wieder wie z.B. vor einem Tag sein, die DB aber nicht. DB und Webserver passen also nicht mehr zusammen. Natürlich könnte ich dann auch den MariaDB LXC zurückrollen, damit das wieder zum ersten Webserver passt, aber dann passt es wieder nicht zum Webserver der nicht zurückgerollt/wiederhergestellt wurde. Und perfekt würden dann auch nie DB LXC und Webserver LXC nach einem Restore zusammenpassen, da die Backups ja nicht gleichzeitig sondern nacheinander durchgeführt werden.

 

[Devy76]

Ich persönlich verpasse lieber jedem LXC eine eigene MariaDB Instanz. Macht es dann leichter wenn ich mal später einen LXC wegwerfen will, weil ich dann einfach nur den LXC löschen muss, ohne da irgendwelche DB-Leichen zurückzubehalten die ich sonst erst zusätzlich noch manuell aus der DB löschen müsste. Und macht es mit Backups auch leichter. Sagen wir ich hätte einen MariaDB LXC und zwei Webserver LXCs die beide den selben MariaDB LXC benutzen. Verbocke ich nun etwas und muss einen Webserver LXC aus einem Backup wiederherstellen oder zu einem früheren Snapshot zurückrollen, dann würde zwar der Webserver wieder wie z.B. vor einem Tag sein, die DB aber nicht. DB und Webserver passen also nicht mehr zusammen. Natürlich könnte ich dann auch den MariaDB LXC zurückrollen, damit das wieder zum ersten Webserver passt, aber dann passt es wieder nicht zum Webserver der nicht zurückgerollt/wiederhergestellt wurde. Und perfekt würden dann auch nie DB LXC und Webserver LXC nach einem Restore zusammenpassen, da die Backups ja nicht gleichzeitig sondern nacheinander durchgeführt werden.

Das ist ein guter Gedankengang.
Meine Überlegungen waren aber dahingehend, dass alle Container und VMs einen Datenbankserver nutzen sollen, weil dieser dann auf einer großen extra Festplatte läuft und die dazugehörigen Systeme dann auf einer schnellen Nvme.

Die nvme wird dann auch weniger gestresst und hält hoffentlich länger.


Kann ich in die MariaDB Config einfach sowas wie 192.168.%.% reinschreiben, dass sie Listening im ganzen Proxmox Rechenzentrum macht??

 

[bluesite]

du trägst einfach in die Konfig deine IP ein vom Server auf dem Maria DB läuft %.%. geht nicht
die anderen greifen dann einfach auf die IP und den Port 3306 zu wenn sie eine Verbindung zur DB machen

 

[Dunuin]

Das ist ein guter Gedankengang.
Meine Überlegungen waren aber dahingehend, dass alle Container und VMs einen Datenbankserver nutzen sollen, weil dieser dann auf einer großen extra Festplatte läuft und die dazugehörigen Systeme dann auf einer schnellen Nvme.

Die nvme wird dann auch weniger gestresst und hält hoffentlich länger.


Kann ich in die MariaDB Config einfach sowas wie 192.168.%.% reinschreiben, dass sie Listening im ganzen Proxmox Rechenzentrum macht??

Sehe nicht warum das nicht auch mit einer DB je LXC gehen sollte. Gibst du halt jedem LXC zwei virtuelle Disks. Eine für das Root Dateisystem auf der schnellen SSD und eine zweite die auf die langsame HDD kommt und nach /var/lib/mysql gemountet wird. Dann hat der MySQL Ordner im LXC seine eigene virtuelle Disk auf der langsamen HDD.

Aber ob es überhaupt sinnvoll ist die DB gezielt auf eine langsamere HDD auszulagern ist noch einmal eine ganze andere Sache...eigentlich will man die ja gerade auf der schnellsten SSD haben, weil DBs vorallem IOPS-Performance brauchen was HDDs halt mal so garnicht leisten können.