ISPConfig Cluster über Public IP

Dieses Thema im Forum "Allgemein" wurde erstellt von Brainfood, 22. Apr. 2013.

  1. Brainfood

    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 ?
     
  2. Till

    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.
     
  3. Brainfood

    Brainfood Member

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

    oder erst:

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

    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 ?
     
  5. florian030

    florian030 Member

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

    Till Administrator

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

    florian030 Member

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

    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

    [​IMG]

    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?

    [​IMG]

    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: 23. Apr. 2013
  9. florian030

    florian030 Member

    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.
     
  10. Brainfood

    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: 23. Apr. 2013
  11. Brainfood

    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
     
  12. Brainfood

    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?
     
  13. Brainfood

    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: 23. Apr. 2013
  14. Brainfood

    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 ...
     
  15. Till

    Till Administrator

    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 :)
     
  16. Brainfood

    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?
     
  17. Till

    Till Administrator

    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.

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

    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: 23. Apr. 2013
  19. Brainfood

    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?
     
  20. florian030

    florian030 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.
     

Diese Seite empfehlen