ISPConfig Cluster über Public IP

Brainfood · 22. Apr. 2013

Heho,

spricht irgendetwas dagegen ein ISPConfig3 - 2 Server Cluster (Master/Master MySQL Rep.) über public IP zu betreiben?

MySQL könnte man mit SSL absichern ?

Till · 22. Apr. 2013

Das sollte kein Problem sein. ISPConfig kommuniziert nur über mysql, wenn Du da eine verschlüsselte Verbindung nutzt dann ist es genauso sicher wie ein Einzelserver.

Brainfood · 23. Apr. 2013

System (Debian) -> MySQL SSL Rep. dann -> Dienste + ISPConfig3 installieren?

oder erst:

System (Debian) -> MySQL Rep. -> Dienste -> ISPConfig3 -> MySQL Rep. SSL?

Brainfood · 23. Apr. 2013

MySQL Master/Master Rep. SSL?

MySQL synct sich dann per slave_account, der ganze ISPConfig3 Kram geht aber weiterhin unverschlüsselt über root@ip ?

florian030 · 23. Apr. 2013

Du musst die Replikation doch nicht über die gleiche IP laufen lassen. Oder Du nimmst stunnel. Schau mal hier.

Till · 23. Apr. 2013

MySQL synct sich dann per slave_account, der ganze ISPConfig3 Kram geht aber weiterhin unverschlüsselt über root@ip ?

Nein. Du kannst auch für ISPConfig mysql ssl verschlüsselte Verbindeungen nutzen.

florian030 · 23. Apr. 2013

Das ist bei einer Master-Master-Replikation nicht erforderlich. Die SQL-Connects können dann immer über localhost erfolgen.

Brainfood · 23. Apr. 2013

moment mal ...

Um die MySQL Verbindung abzusichern kann ich entweder direkt SSL in MySQL benutzen (was recht viel Gefummel bei einem laufenden Master/Master Rep. System ist) oder ich Kapsel den Datenstrom in irgendein VPN Zeugs (openvpn/ipsec/stunnel) ein (hier seh ich nun wieder das Problem mit verschiedenen host_names/eth0:0 virtual dev gefrickel, anderen Subnetzen und unnötigen MySQL Usern@IP.

Was genau läuft eigentlich mit Master/Master Cluster Betrieb ab?

Box 1 hat ihre lokale ISPConfig-Datenbank
Box 2 hat ihre lokale ISPConfig-Datenbank

- Für einen funktionierenden Slave-Modus werden also "Remote" Connections aufgebaut (root@ip/root@hostname)
- zusätzlich tauschen sich die 2 MySQL Master Repl. die Inhalte über ihre eigene Verbindung aus

MySQL master-slave and master-master replication. Step by step configuration instructions. | ErlyCoder

Wenn ich also nun stunnel als alternative benutzen möchte, biege ich einmal komplett in den /etc/mysql/my.cnf die MASTER/MASTER Repl. um?

MySQL Master-Master Replication over a Secure Stunnel Connection (SSL) - Akom's Tech Ruminations

Was passiert dann mit diesen root@IP/root@hostname Usern, die nach dem Cluster HowTo eingerichtet worden?

florian030 · 23. Apr. 2013

Wenn ich also nun stunnel als alternative benutzen möchte, biege ich einmal komplett in den /etc/mysql/my.cnf die MASTER/MASTER Repl. um?

Ja. Dann reicht CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=3307 ...; ich würds nicht unbedingt über die my.cnf machen.

Brainfood · 23. Apr. 2013

MySQL Master/Master Repl. Sync über stunnel steht,

Nur was hat jetzt Gültigkeit?

1. die direkte Kommunikation zwischen MySQL Server1/Server2 (Mirror Mode) laut Cluster Howto?
root@IP/root@hostname?
2. die /etc/mysql/my.cnf Master Repl. master-host/master-user/master-password?
oder
3. die stunnel CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=3307, MASTER_LOG_FILE/MASTER_LOG_POS

Code:

SHOW SLAVE STATUS\G

zeigt einen sauberen:

Code:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Ändere ich nun z.B. die Firewallregeln übers ISPConfig3 am Server1, wird dies übernommen (iptables -S) und ich seh Protokolländerungen per (mysql SHOW SLAVE STATUS\G)
Haue ich jedoch den Port 3306 vom Server 2 übers ISPConfig3 raus, passiert garnix ...

per netstat sind noch immer (direkt) aktive MySQL-Verbindungen offen:

Code:

tcp        0      1 Server2:49916 Server1:mysql SYN_SENT   
tcp        0      0 localhost:55899         localhost:mysql         ESTABLISHED
tcp        1      0 localhost:54584         localhost:mysql         CLOSE_WAIT 
tcp        0      0 Server2:48387 Server1:3307 ESTABLISHED
tcp        0      1 Server2:49918 Server1:mysql SYN_SENT

Was muss noch angepasst werden?
Sind das Verbindungen vom MySQL M+M Rep. (ohne encryption) oder die aus den ISPConfig3 Cluster Installationseinstellungen?

Brainfood · 23. Apr. 2013

Code:

root@server2 # tcpdump port 3306

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:19:09.641872 IP Server2.50295 > Server1.mysql: Flags [S], seq 1796739189, win 5840, options [mss 1460,sackOK,TS val 5261010 ecr 0,nop,wscale 7], length 0
16:19:10.709832 IP Server2.50294 > Server1.mysql: Flags [S], seq 2196468443, win 5840, options [mss 1460,sackOK,TS val 5261277 ecr 0,nop,wscale 7], length 0
16:19:12.646582 IP Server2.50296 > Server1.mysql: Flags [S], seq 2825172855, win 5840, options [mss 1460,sackOK,TS val 5261761 ecr 0,nop,wscale 7], length 0
16:19:15.641879 IP Server2.50295 > Server1.mysql: Flags [S], seq 1796739189, win 5840, options [mss 1460,sackOK,TS val 5262510 ecr 0,nop,wscale 7], length 0
16:19:15.645789 IP Server2.50296 > Server1.mysql: Flags [S], seq 2825172855, win 5840, options [mss 1460,sackOK,TS val 5262511 ecr 0,nop,wscale 7], length 0

Brainfood · 23. Apr. 2013

ich seh gerade auf dem Server2 steht in der:

Code:

/usr/local/ispconfig/interface/lib/config.inc.php

Code:

$conf['dbmaster_host'] auf Server1.domain.tld

das funktioniert natürlich bei gesperrten 3306 Ports nicht.

Ist der User "ispcsrv3" auf eine bestimmte Schnittstelle gebunden?

z.B. ispcsrv3@server2.domain.tld?

Das Passwort kann ich schlecht durch salt crypt/md5 erraten, sonst hätte ich einfach einen User ispcsrv3@127.0.0.1:3307 erstellt.

Werden eigentlich bei der Master/Master Replikation auch die "dbispconfig1" und "dbispconfig2" synchronisiert?

Wenn ja könnte man ja einfach server2.domain.tld durch localhost ersetzen, der sync würde dann über M+M stunnel Repl. laufen?

Brainfood · 23. Apr. 2013

per phpmyadmin (als root)

Code:

Benutzer	Host	Passwort	Globale Rechte 1	GRANT	Aktion
debian-sys-maint localhost	Ja	 ALL PRIVILEGES	Ja	
ispconfig	localhost	Ja	 USAGE	Nein	
ispconfig2	localhost	Ja	 USAGE	Nein	
ispcsrv3	PUBLIC-IP	Ja	 USAGE	Nein	
ispcsrv3	srv2.domain.tld	Ja	 USAGE	Nein	
root		127.0.0.1	Ja	 ALL PRIVILEGES	Ja	
root		PUBLIC-IP	Ja	 ALL PRIVILEGES	Ja	
root		localhost	Ja	 ALL PRIVILEGES	Ja	
root		srv2.domain.tld	Ja	 ALL PRIVILEGES	Ja	
root		srv2.domain.tld	Ja	 ALL PRIVILEGES	Ja	
slaveuser	%	Ja	 REPLICATION SLAVE	Nein

Brainfood · 23. Apr. 2013

Quatsch, in der /usr/local/ispconfig/interface/lib/config.inc.php stehen die Passwörter doch als plaintext, der mysql login klappt ohne Probleme damit ...

Till · 23. Apr. 2013

Zitat von Brainfood:
Quatsch, in der /usr/local/ispconfig/interface/lib/config.inc.php stehen die Passwörter doch als plaintext, der mysql login klappt ohne Probleme damit ...

Natürlich ist das Plaintext. Wie in jeder Konfigurationsdatei eines Dienstes der sich mit mysql verbindet, denn wie sollte sich ispconfig bei mysql einloggen können wenn es selbst das Passwort nicht kennt

Brainfood · 23. Apr. 2013

ich Fummel nun 24 stunden an dem Ding herum, da lässt die Konzentration nach.

Also Till was muss genau an MySQL Benuterrechten angepasst werden?

ich würde jetzt auf dem Server2, in der /usr/local/ispconfig/interface/lib/config.inc.php, den server2.domain.tld durch localhost ersetzen und einen entsprechenden User (ispcsrv3) einrichten.

Muss irgendwo noch der root@server2.domain.tld angepasst werden?

Till · 23. Apr. 2013

ich würde jetzt auf dem Server2, in der /usr/local/ispconfig/interface/lib/config.inc.php, den server2.domain.tld durch localhost ersetzen und einen entsprechenden User (ispcsrv3) einrichten.

Kannst Du machen, Du hebelst damit aber die ispconfig DB Replikation aus welche Fehlertoleranter als die von mysql ist. ISPConfig kümmert sich ja selbst um die Replikation der Datenbanken dbispconfig zwischen master und slave.

Muss irgendwo noch der root@server2.domain.tld angepasst werden?

Root Verbindeungen gehen imemr nur über localhost und die Daten dazu stehen in der mysql_clientdb.conf

Brainfood · 23. Apr. 2013

Dann mach ein Vorschlag, was sinnvoll ist.

Die Kisten haben eine "closed" 3306 Port, die MySQL Master/Master Replication läuft über stunnel (3307).

Wie binde ich jetzt den ISPConfig3 Slave (Server2) brauchbar wieder an?

In der /usr/local/ispconfig/interface/lib/config.inc.php ist ja keine Portangabe möglich um per stunnel direkt auf den ISPConfig3 Master (Server1) zugreifen zu können.

Brainfood · 23. Apr. 2013

habe jetzt User "ispcsrv3" als @localhost kopiert und auf Server2 (Slave), in den:

/usr/local/ispconfig/server/libconfig.inc.php
/usr/local/ispconfig/interface/lib/config.inc.php

folgenden Eintrag gesetzt

Code:

$conf['dbmaster_host']			= 'localhost';

OK die ISPConfig3 Replikation geht jetzt erst einmal über M+M Repl, wie gesagt ... wenn dir etwas besseres einfällt?

@Florian, wie benutzt du das ganze?

florian030 · 23. Apr. 2013

Ich lasse die Replikation über stunnel laufen. (SET MASTER ... MASTER_PORT = 3307). Da muss nicht großartig etwas geändert werden. Die Client-Zugriffe (ISPConfig, Websites) laufe ganz normal über localhost:3306.

Und die stunnel.conf sieht dann so aus:

Code:

[repliserver]
accept = tiro.schaal-24.de:3307
connect = 3306
cert = /usr/local/etc/stunnel/mysql.pem

[repliclient]
accept=127.0.0.1:3307
connect= cicero.schaal-24.de:3307
client=yes
cert = /usr/local/etc/stunnel/mysql.pem

Das bedeutet:
repliserver reagiert auf connects von tiro.schaal-24.de:3307 und schickt die an port 3306.
repliclient reagiert auf connects von 127.0.0.1:3307 und schickt die an cicero.schaal-24.de:3307

Auf dem anderen Server ist die stunnel.conf entsprechend gedreht.

ISPConfig Cluster über Public IP

Member

Administrator

Member

Member

Active Member

Administrator

Active Member

Member

Active Member

Member

Member

Member

Member

Member

Administrator

Member

Administrator

Member

Member

Active Member

Werbung