# 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


```
SHOW SLAVE STATUS\G
```
zeigt einen sauberen:


```
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:


```
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)

```
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:


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


```
$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)

```
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


```
$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:

```
[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.


----------



## Brainfood (23. Apr. 2013)

Server1

```
; ### ### ### PLITC ### ### ###
; #
chroot = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
pid = /stunnel4.pid

; #
sslVersion = SSLv3
; foreground = yes
; debug = 7

[repliserver]
; accept = XXX.XXX.XXX.XXX:3307
accept = 2a01:XXXX:XXXX:XXXX::XXXX:3307
connect = 127.0.0.1:3306
cert = /etc/stunnel/mysql.pem

[repliclient]
accept = 127.0.0.1:3307
; connect = XXX.XXX.XXX.XXX:3307
failover = rr
connect = 2a01:XXXX:XXXX:XXXX::XXXX:3307
connect = 2a01:XXXX:XXXX:XXXX::XXXX:3307
connect = 2a01:XXXX:XXXX:XXXX::XXXX:3307
connect = 2a01:XXXX:XXXX:XXXX::XXXX:3307
cert = /etc/stunnel/mysql.pem
client = yes

; #
; ### ### ### PLITC ### ### ###
; # EOF
```
bei Server2 umgekehrt


----------



## Brainfood (23. Apr. 2013)

Wenn ich mich ins ISPConfig3 auf den Server 2 (Slave) einlogge steht in der Überwachung:



> Daten vom: ????-??-?? ??:??
> Derzeit stehen keine Protokolldaten zur Verfügung. Bitte später erneut überprüfen.


das ist normal im Cluster (Master/Slave Modus)?

Nein, das bedeutet dass sich der slave nicht mit dem Master verbinden kann um seine Status und Logdaten in die master DB zu schreiben.


----------



## Brainfood (23. Apr. 2013)

so schauts in der syslog aus:


```
Apr 23 23:07:11 server2 stunnel: LOG5[2699:140386453493504]: repliserver accepted connection from 2a01:XXXX:XXXX:XXXX::XXXX:36524
Apr 23 23:07:11 server2 stunnel: LOG5[2699:140386453493504]: connect_blocking: connected 127.0.0.1:3306
Apr 23 23:07:11 server2 stunnel: LOG5[2699:140386453493504]: repliserver connected remote server from 127.0.0.1:50640
Apr 23 23:07:11 server2 stunnel: LOG5[2699:140386453423872]: repliclient accepted connection from 127.0.0.1:56533
Apr 23 23:07:11 server2 stunnel: LOG5[2699:140386453423872]: connect_blocking: connected 2a01:XXXX:XXXX:XXXX::XXXX:3307
Apr 23 23:07:11 server2 stunnel: LOG5[2699:140386453423872]: repliclient connected remote server from 2a01:XXXX:XXXX:XXXX::XXXX:55982
Apr 23 23:07:11 server2 mysqld: 130423 23:07:11 [Note] Slave I/O thread: connected to master 'slaveuser@127.0.0.1:3307',replication started in log 'mysql-bin.000012' at position 106
```


----------



## Brainfood (25. Apr. 2013)

da der stunnel sync über ipv6 läuft kommt ab und an im syslog:


```
IPv6: sending pkt_too_big to self
```
ich teste mal:


```
ifconfig eth0 mtu 1496
```


----------



## Till (25. Apr. 2013)

Zitat von Brainfood:


> Wenn ich mich ins ISPConfig3 auf den Server 2 (Slave) einlogge steht in der Überwachung:
> 
> 
> 
> das ist normal im Cluster (Master/Slave Modus)?


Sorry, ich hatte meine Antwort aus Versehen in Deinen Post geschrieben. Hier nochmal richtig:

Nein, das bedeutet an sich dass sich der slave nicht mit dem Master verbinden kann um seine Status und Logdaten in die master DB zu schreiben. Die Verbindung slave zu master hat recht komplexe Rechte in der master db, vielleicht sthet dort irgendwo bei den table oder column Rechten noch der falsche hostname drin.


----------



## Brainfood (25. Apr. 2013)

verstehe,

ISPConfig3-Master = ispconfig(1)@localhost + root@localhost -> dbispconfig(1)
ISPConfig3-Slave = ispconfig(2)@localhost + root@localhost -> dbispconfig(2)
ISPConfig3-Slave = ispcsrv3@remote_host -> dbispconfig(1)

und wenn ich auf dem Server2 statt dem ispcsrv3 User den ispconfig1@localhost nehme (Statt jetzt nach den Werten in der Datenbank zu suchen und dort herum zu wuseln?)?


----------



## Brainfood (25. Apr. 2013)

moment habe ich gerade einen denkfehler?

ispcsrv3 "poll"t doch nur die Daten zum Server1 um sie per (Master) ISPConfig3 -> "Überwachung" darstellen zu können?

Nur wenn: /usr/local/ispconfig/server/lib/config.inc.php


```
//** Database settings for the master DB. This setting is only used in multiserver setups
$conf['dbmaster_type']            = 'mysql';
$conf['dbmaster_host']            = '';
$conf['dbmaster_database']        = 'dbispconfig';
$conf['dbmaster_user']            = '';
$conf['dbmaster_password']        = 'XXX';
$conf['dbmaster_new_link']         = false;
$conf['dbmaster_client_flags']     = 0;
```
garnicht erst auf dem Master-Server eingestellt ist, pollt dann auch der Server nicht die Logdaten zum Slave um sie dort anzeigen zu können ...

In einem ISPConfig3 Cluster möchte man natürlich auch vom Server2 (Slave) unteranderem die Überwachung vom Server1 (Master) sauber sehen können


----------



## Till (25. Apr. 2013)

> ispcsrv3 "poll"t doch nur die Daten zum Server1 um sie per (Master) ISPConfig3 -> "Überwachung" darstellen zu können?


Nein, nicht nur.

1) Er pollt die Daten um Konfigurationsänderungen durchzuführen.
2) er schreibt aber auch Daten in die master DB, dabei hat er aber sehr eingeschränkte Rechte so dass er nur auf wenige Tabellen schrebzugriff hat, so wenige wie unbedingt notwendig damit kein node Konfigurationsänderungen für einen anderen node ausführen könnte wenn mal einer gehackt würde.


----------



## Brainfood (25. Apr. 2013)

Ich habe ja andere ISPConfig3 Multiserver-Installationen laufen, da ist die "Einschränkung" auf den Slaves genauso

Master -> ISPConfig Überwachung und Einstellungsübernahme an die Slaves geht
Slave1 (mit ISPConfig) -> keine Loganzeige
Slave2 (mit ISPConfig) -> keine Loganzeige
Slave3 (mit ISPConfig) -> keine Loganzeige
Slave4 (mit ISPConfig) -> keine Loganzeige

Ok Till, du sagtest es mir schon einmal an einer anderen Stelle: "Es mache kein Sinn ISPConfig Interface ebenfalls auf den Slaves zu installieren"

In einem Cluster sollte aber der Node A gleichberechtigt mit Node B sein.

Die ISPConfig3 Master & Slave (Cluster) Installation ist schon klar, macht es da Sinn den ispcsrv3 User ebenso mit in die Master config.inc.phps einzubinden?


----------



## Till (25. Apr. 2013)

> Master -> ISPConfig Überwachung und Einstellungsübernahme an die Slaves geht
> Slave1 (mit ISPConfig) -> keine Loganzeige
> Slave2 (mit ISPConfig) -> keine Loganzeige
> Slave3 (mit ISPConfig) -> keine Loganzeige
> Slave4 (mit ISPConfig) -> keine Loganzeige


Ich habe hier auch einen Cluster und der zeigt die Logs der slaves auf dem Master an. Vielleicht hast Du bei den Updates kein "reconfigure permissions in master database" gemacht?



> Die ISPConfig3 Master & Slave (Cluster) Installation ist schon klar, macht es da Sinn den ispcsrv3 User ebenso mit in den Master config.inc.phps einzubinden?


Meines Erachtens nicht. Der Cluster mit Mirroring und 2 ispconfig Interfaces functioniert ja so:

Es gibt 2 unabhängige ispconfig datenbanken, dbispconfig1 und dbispconfig2 und zwar gibt es sie auf beiden servern da mysql master/master Replication. ISPConfig kümmert sich um das verschieben der daten von db1 zu db2, mysql kümmert sich darum dass db1 und auch db2 auf beiden servern zur verfügung stehen. Die Interfaces beider server verbinden sich mit db1. der server teil von server1 verbindet sich mit db1, der serverteil von server2 verbindet sich mit db2. das ist notwendig damit beide server ihr eigenes datalog haben.


----------



## Brainfood (25. Apr. 2013)

"reconfigure permissions in master database" wurde gemacht, die Loganzeige auf dem Master ISPConfig3 funktioniert ja, nur eben auf dem Slave nicht (Überwachung von Server1) ... es geht mir nur um den Slave

Prinzip ist klar, deswegen speichern root@ und ispconfig(1/2)@ jeweils in die lokale ispconfig1 und ispconfig2 DB, User ispcsrv3 verteilt dann ja nur vom Slave zum Master ...

unabhängig von der MySQL Master/Master Replication, die sowieso eigentlich nur für den Sync von "Kunden"-Datenbanken gedacht ist, warum findet der "poll" nicht auch auf dem Master statt?

anders formuliert: warum kein ISPConfig3 Master/Master Cluster?


----------



## Till (26. Apr. 2013)

> "reconfigure permissions in master database" wurde gemacht, die Loganzeige auf dem Master ISPConfig3 funktioniert ja, nur eben auf dem Slave nicht (Überwachung von Server1) ... es geht mir nur um den Slave


Hast Du denn wie im mirror Tutorial beschrieben die interface config.inc.php Datei des slaves geändert? Das slave interface connected auf die master DB auf localhost, er muss also definitiv das gleiche anzeigen wie der master. Falls nicht dann geht die mysql master/master Replikation nicht.



> anders formuliert: warum kein ISPConfig3 Master/Master Cluster?


Mögliche Datenkonflike und es ist in dieser Konfigurazion auch nicht notwendig da der Teil durch die mysql master/master Replikation angedeckt wird.


----------



## Brainfood (26. Apr. 2013)

Ach Fuck, du meinst wohl:



> On server 1:
> 
> ... and execute this command:
> 
> ...


hab ich wohl vergessen, die /server/lib/config.inc.php bleibt aber mit den lokalen (server2) daten?


----------



## Till (26. Apr. 2013)

> die /server/lib/config.inc.php bleibt aber mit den lokalen (server2) daten?


Ja, die server Datei bleibt so.


----------



## Brainfood (26. Apr. 2013)

OK, funktioniert jetzt ... Asche auf mein Haupt.


----------



## Brainfood (26. Apr. 2013)

Ach eine Sache noch, wie ist das mit der "billing" app, einfach auf server 1 und 2 installieren oder kreuzen sich die db Einträge dann?


----------



## Till (26. Apr. 2013)

Die billing app einfach auf beiden Servern installieren. Da die interfaces ja die gleiche gespiegelte master DB nutzen, gibt es da keine Probleme.


----------



## Brainfood (26. Apr. 2013)

ok nächste Sache, Datenverteilung:

- ich halte bis jetzt die Multiserverkisten mit rsync/ssh aller 10 min gleich
- unison?
- glusterfs?

Wie gut läuft GlusterFS über ein OpenVPN/IPSec?

Skalierung? Trafficverzehr? etc.


----------



## Brainfood (26. Apr. 2013)

Zum Thema MySQL noch einmal:


```
mysqld: 130426 23:15:14 [Warning] Statement may not be safe to log in statement format. Statement: DELETE FROM invoice_message_template WHERE invoice_message_template_id = 1 LIMIT 1
```


----------



## Till (27. Apr. 2013)

Zitat von Brainfood:


> ok nächste Sache, Datenverteilung:
> 
> - ich halte bis jetzt die Multiserverkisten mit rsync/ssh aller 10 min gleich
> - unison?
> ...


Ich würde unison nehmen. Wir haben anfangs auf glusterfs gesetzt, wie es noch im lenny tutorial steht, aber glusterfs kommt nicht mit vielen kleinen dateien klar wie sie für webserver typisch sind und bricht dann komplett in der performance ein auf dateraten im kilobit bereich trotz 1gbit verbindung zwischen den servern.


----------



## Brainfood (27. Apr. 2013)

Habe heute Nacht mal Unison eingerichtet, cron lief aller 5 min.

Habe von einem RZ ins andere ein 1.6 GB File verschoben, nebenbei habe ich etwas per "iftop" den Traffic beobachtet und die Verzeichnisse vergleichen

Irgendwann fing er mit, .unison_xyz_temp_verzeichnis an ... der Traffic stieg vom erwarteten 1.6 GB Transfer auf 2, 3, dann 5 ... dann 6 ... an, in der /root/unison.log stand folgendes:


```
Failed: The file .unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar was incorrectly transferred  (fingerprint mismatch in file contents) -- temp file saved as.unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar-bad

UNISON 2.32.52 finished propagating changes at 05:02:26 on 27 Apr 2013

Synchronization incomplete at 05:02:26  (28 items transferred, 0 skipped, 1 failed)
  failed: www/clients/client1/web3/web/sun

UNISON 2.32.52 started propagating changes at 05:05:07 on 27 Apr 2013

[BGN] Copying www/clients/client1/web3/web/sun from /var to //XXX.XXX.XXX.XXX//var
/var/www/clients/client1/web3/web/.unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar.md5 has already been transferred
Failed: Failed to set modification time of file /var/www/clients/client1/web3/web/.unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar to 2013-04-27 at  4:53:57: the time was set to 2013-04-27 at  5:06:44 instead

UNISON 2.32.52 finished propagating changes at 05:06:44 on 27 Apr 2013

Synchronization incomplete at 05:06:44  (33 items transferred, 0 skipped, 1 failed)
  failed: www/clients/client1/web3/web/sun

UNISON 2.32.52 started propagating changes at 05:10:07 on 27 Apr 2013

[BGN] Copying www/clients/client1/web3/web/sun from /var to //XXX.XXX.XXX.XXX//var
/var/www/clients/client1/web3/web/.unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar.md5 has already been transferred
Failed: The file .unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar was incorrectly transferred  (fingerprint mismatch in file contents) -- temp file saved as.unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar-bad

UNISON 2.32.52 finished propagating changes at 05:11:25 on 27 Apr 2013

Synchronization incomplete at 05:11:25  (0 items transferred, 0 skipped, 1 failed)
  failed: www/clients/client1/web3/web/sun

UNISON 2.32.52 started propagating changes at 05:15:07 on 27 Apr 2013

[BGN] Copying www/clients/client1/web3/web/sun from /var to //XXX.XXX.XXX.XXX//var
/var/www/clients/client1/web3/web/.unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar.md5 has already been transferred
Failed: The file .unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar was incorrectly transferred  (fingerprint mismatch in file contents) -- temp file saved as.unison.sun.b1ffbeb9967c7d50667263bef6eeb0b8.unison.tmp/sun_fire_v245carepaket.tar-bad

UNISON 2.32.52 finished propagating changes at 05:16:12 on 27 Apr 2013

Synchronization incomplete at 05:16:12  (0 items transferred, 0 skipped, 1 failed)
  failed: www/clients/client1/web3/web/sun
```
Unison-Prozess gekillt, und auf */15 Minuten im Crontab gesetzt ... dann wurde das File sauber übertragen, er scheint also irgendwie Probleme zu haben wenn Unison ausgeführt wird und erneut Unison (per crontab) gestartet wird ...

des is Mist.

PS: Im Installing A Web, Email & MySQL Database Cluster On Debian 6.0 With ISPConfig 3 sollten noch ergänzt werden, dass Unison ebenso auf Server2 installiert sein muss


----------



## Till (28. Apr. 2013)

> des is Mist.


Pack doch unison in ein wrapper script welches eine lock Datei erstellt und am ende wieder entfernt und nur dann unison ausführt wenn keine lockdatei da ist.



> PS: Im Installing A Web, Email & MySQL Database Cluster On Debian 6.0 With ISPConfig 3 sollten noch ergänzt werden, dass Unison ebenso auf Server2 installiert sein muss


Danke für den Hinweis!


----------



## Brainfood (1. Mai 2013)

Jop hab es mit .lock File gemacht und mir die ganze Schoße paar Stunden angeschaut.

Übermittelt werden sollte 75 GB, 5 Domain Postfächer mit ca. insgesamt 15 Konten + ca 30 GB Webcontent.

Unison hat erstmal 30 min nix gemacht, als nur CPU belastet (file scan?) dann 10 Sub_Prozesse gestartet. zig .unison.tmp Files auf dem Server2 erstellt und nix gebacken bekommen.

Unison taugt überhaupt nix ...

1. Ich hab Apache2/Postfix/Dovecot beendet
2. Alle files aufs aktuelle Datum (auf Server1) gesetzt:


```
find /var/vmail -exec touch -c {} \;

find /var/www -exec touch -c {} \;
```
3. alles per rsync over ssh transferiert


```
# web sync
/usr/bin/rsync -avz --delete /var/www/domain.tld/cgi-bin/ root@server.domain.tld:/var/www/domain.tld/cgi-bin/
/usr/bin/rsync -avz --delete /var/www/domain.tld/ssl/ root@server.domain.tld:/var/www/domain.tld/ssl/
/usr/bin/rsync -avz --delete /var/www/domain.tld/web/ root@server.domain.tld:/var/www/domain.tld/web/
/usr/bin/rsync -avz --delete /var/www/domain.tld/webdav/ root@server.domain.tld:/var/www/domain.tld/webdav/

# mail sync
/usr/bin/rsync -avz --delete /var/vmail/domain.tld/ root@server.domain.tld:/var/vmail/domain.tld/
```
Ein Script läuft per Crontab aller 24 Stunden durch.

Um es salopp zu sagen: *rsync over ssh* ist schnell, zuverlässig = geil und ballert mir in wenigen Minuten die GBs über die Gigabit Leitung ins andere RZ weg.


----------



## Brainfood (1. Mai 2013)

Ok Cluster trifft derzeit wirklich nur für die MySQL Master/Master Replication zu.

Was die Konsistenz bei Web/Mail angeht, sind rsync/unison keine "gute" Lösung. GlusterFS sagtest du, skaliert schlecht ab einer großen Anzahl von kleinen Dateien ...

Was mich jetzt interessiert ist ein brauchbarer Sync für Web, um eben per DNS Roundrobin ein einfaches HA (High Availability) und simples Loadbalacing zu bekommen.

Ich schau mir jetzt mal die "Relay Empfänger/E-mail Routing" Funktionen von ISPConfig und eine direkte Dovecot Synchronisierung mit "dsync" für den Clusterbetrieb an.

Bis jetzt laufen meine anderen (ISPConfig Master+dedicated Slave Server) Mailserver mit mehreren MX Einträgen und Routing + maximal_queue_lifetime als Cache.

Definiert sind also per DNS:


```
domain.tld   TTL   MX 10   server1.domain.tld.
domain.tld   TTL   MX 20   server2.domain.tld.
domain.tld   TTL   MX 30   server3.domain.tld.
domain.tld   TTL   MX 40   server4.domain.tld.
domain.tld   TTL   MX 50   server5.domain.tld.
domain.tld   TTL   TXT   "v=spf1 mx -all"
```
Server2/3/4/5 sind nicht nicht für die Email-Domains zuständig:

ISPConfig -> E-Mail -> E-Mail Domain = keine domain.tld Einträge

jedoch für das Zwischenlagern:

ISPConfig -> E-Mail Routing -> domain.tld


```
fremddomain.tld   smtp   Ziel   server1.domain.tld
```
ISPConfig -> Relay Empfänger


```
@domain.tld
```
vi /etc/postfix/main.cf


```
### ### ### PLITC ### ### ###
delay_warning_time = 6h
bounce_queue_lifetime = 12h
maximal_queue_lifetime = 12h
### ### ### PLITC ### ### ###
```
Server3/4/5 haben höhere delay/bounce/queue_lifetime werte

*Ergebnis:*
- Wenn Server1 ausfällt, wird die Mail an Server2 geschickt, dort bis zu 12 Stunden zwischengelagert, in dieser Zeit versucht an Server1 zu schicken und  erst nach abgelaufener Zeit als unzustellbar abgelehnt.

Das ganze funktioniert tadellos

*Was jetzt jedoch das Cluster Setup angeht:*

- Die Mail würde auf MX2 zugestellt werden, da das Postfach auf Server2 vorhanden ist, und durch den primitiven file sync einfach plump überschrieben werden.

Punkt1: Wenn ich nun das Postfach mit domain Zugehörigkeit auf Server2 im Cluster erstellen lasse, greift vermutlich die Routing nicht mehr?

Punkt2: statt rsync muss ein direktes *mirroring* per dsync her, dass teste ich jetzt mal ...

Punkt3: Was den Websync angeht, fällt mir auf die schnelle nix brauchbares ein...



Das Cluster-Pärchen synct wie gesagt aller 24 Stunden von Server1 zu Server1, da einige Leute ihr Outlook auf "Lösche/Säubere den Papierkorb beim beenden von Outlook" aktiviert haben, ist im Roundcube der (Mail)Server2 als Server2 (Backup) definiert.

POP3 deaktiviere ich aus Prinzip beim erstellen der Postfächer und per autodiscover.xml ist nur IMAP definiert, ebenso werden standardmäßig die SRV Records negiert:


```
_autodiscover._tcp.domain.tld. 3600      SRV        5 0 443 domain.tld.
_imap._tcp.domain.tld. 3600      SRV        0 0 0 .
_imaps._tcp.domain.tld. 3600      SRV        5 0 993 server1.domain.tld.
_pop3._tcp.domain.tld. 3600      SRV        0 0 0 .
_pop3s._tcp.domain.tld. 3600      SRV        20 0 995 server1.domain.tld.
_submission._tcp.domain.tld. 3600      SRV        5 0 587 server1.domain.tld.
```
Gesagt wurde ihnen: "Jungs, wenn ihr mal eine Mail (trotz erzwungenem IMAP) versehentlich gänzlich gelöscht haben solltet, könnt ihr sie per Roundcube vom Backup-Server innerhalb von 24 Stunden wieder zurück schieben"

Im "professionellen" Umfeld muss aber sowieso ein vernünftiger Sync zwischen den Web/Mail Inhalten herrschen.


----------



## florian030 (1. Mai 2013)

Ich verwende statt GlusterFS DRBD als dual-primary und als FS OCFS2. Das funktioniert ganz gut.

Da die meisten Web-Domains aber eh CMS sind, würde dafür auch Unison o.ä. reichen.


----------



## Brainfood (5. Mai 2013)

ok ich bastel mir erstmal ein VPN, vermutlich cert.basiertes IPSec drumherum bevor ich dann mal ein DRBD/OCFS2 aufsetze ...

Zum Thema Mysql-Sync:


```
May  5 12:40:07 servername mysqld: 130505 12:40:07 [Warning] Statement may not be safe to log in statement format. Statement: UPDATE `session` 
May  5 12:40:07 servername mysqld:             SET `data` = 'last_login_date|s:19:\"2013-05-04 17:28:47\";new_member|b:0;sysmsg|a:0:{}return_url|s:0:\"\";sysmsg_info|a:0:{}', `expire` = '1367930407' 
May  5 12:40:07 servername mysqld:             WHERE `sid` = 'apl16uantloehe0g9001svlq34' LIMIT 1
```
irgendein Tipp dazu?


----------



## Brainfood (5. Mai 2013)

ich habe mal etwas per PHPMyAdmin geblättert:

dbispconfig1

der Einträgt lässt sich unter: dbispconfig1 -> monitor_data -> log_messages finden:


```
1	log_messages	1367783102	s:16810:"May  5 21:43:17 server mysqld:...	no_state
3	log_messages	1367783102	s:13917:"May  5 21:33:17 server mysqld...	no_state
```
Der Inhalt wird vermutlich aus dem "minütlichem" ISPConfig Crontab erzeugt.

Zwischen der MySQL Replication hängt aber immer noch der "ALTE" Eintrag in der Luft:


```
SET `data` = 'last_login_date|s:19:\"2013-05-04 17:28:47\";new_member|b:0;sysmsg|a:0:{}return_url|s:0:\"\";sysmsg_info|a:0:{}', `expire` = '1367962037'
```
Wenn ich jetzt per phpmyadmin die 2 Sachen heraus lösche, sodass der M+M Rep. die alten Daten sauber reinschreiben kann und diese automatisiert per Crontab ersetzt werden ... wäre das eine brauchbare Lösung?


----------



## florian030 (6. Mai 2013)

Nein, löschen ist keine brauchbare Lösung. Das dürfte Dir dann öfter passieren. Welches binlog_format verwendest Du denn? Das sollte mixed sein.


----------



## Brainfood (6. Mai 2013)

Jop genau,

ich war mir erst unsicher, da:


```
grep CONFIG $(which mysqlbug)
```
nix von irgendeiner "row" Unterstützung in dem vorkompilierten Debianbinary zeigte.

Zuerst versuchte ich einen Resync - mit STOP SLAVE; CHANGE MASTER TO MASTER ...; RESET SLAVE; START SLAVE; dass zerschoss mir aber nur den laufenden Sync, da er wieder die "Public IPs" aus der /etc/mysql/my.cnf nahm ... der sync wurde aber nachträglich übers stunnel gepackt.

ein erneuter CHANGE MASTER TO MASTER, zerschoss dann auf Filesystemebene den Sync, da die "alten" Bin-Logs vorhanden waren und er beim RESET SLAVE; auf 0 wieder springen sollte ...

Nach einem Backup-Recovery beider Master Server hab ich nun den "mixed mode" in der my.cnf ergänzt:


```
skip-external-locking
#
### ### ### PLITC ### ### ###
# MySQL Master / Master Replication - Server1
#
server-id = 1
replicate-same-server-id = 0
auto-increment-increment = 2
auto-increment-offset = 1

master-host = XXX.XXX.XXX.XXX
master-user = slaveuser
master-password = Geheim
master-connect-retry = 60

expire_logs_days        = 10
max_binlog_size         = 500M
log_bin                        = /var/log/mysql/mysql-bin.log
#
### avoid ISPConfig/MySQL Repl. create/delete DB sync_fail ###
slave_skip_errors=1007,1008
#
### more robustness ###
sync_binlog = 1
#
### avoid ISPConfig data value sync warnings ###
binlog-format = mixed
#
### ### ### PLITC ### ### ###
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
### ### ### PLITC ### ### ###
# bind-address          = 127.0.0.1
### ### ### PLITC ### ### ###
#
# * Fine Tuning
#
```

mmm repl. geht & syslog kann wieder durchatmen ...


----------



## florian030 (6. Mai 2013)

Das hängt mit der jeweiligen mysql-Version zusammen:


> In MySQL         5.1.12, MIXED become the default logging         mode; in 5.1.29, the default was changed back to         STATEMENT for compatibility with MySQL 5.0.


MySQL :: MySQL 5.1 Reference Manual :: 5.2.4.1 Binary Logging Formats


----------



## Brainfood (6. Mai 2013)

Jop,

die ganzen MySQL Guides zum Thema *Multi Master/Master Replication*, hatte ich in den letzten Tagen "durchgewälzt".

Debian 6

Paket mysql-server
squeeze (oldstable) (misc): MySQL-Datenbankserver (Metapaket, abhängig von der neuesten Version) 
5.1.66-0+squeeze1 [security]: all 
auch bereitgestellt durch: mysql-server-5.1

Hast du dir mal:

Multi-Master Replication Manager for MySQL [MMM for MySQL Wiki]

angeschaut?


----------

