ISPConfig Cluster über Public IP

B

Brainfood

Member
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 ?
 
T

Till

Administrator
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.
 
B

Brainfood

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

oder erst:

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

Brainfood

Member
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

florian030

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

Brainfood

Member
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?
 
Zuletzt bearbeitet:
B

Brainfood

Member
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?
 
Zuletzt bearbeitet:
B

Brainfood

Member
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
 
B

Brainfood

Member
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?
 
B

Brainfood

Member
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
 
Zuletzt bearbeitet:
B

Brainfood

Member
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 ...
 
B

Brainfood

Member
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?
 
T

Till

Administrator
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.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
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?
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Root Verbindeungen gehen imemr nur über localhost und die Daten dazu stehen in der mysql_clientdb.conf
 
B

Brainfood

Member
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.
 
Zuletzt bearbeitet:
B

Brainfood

Member
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

florian030

Well-Known Member
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.
 
You must log in or register to reply here.

Werbung

Top