ISPConfig 3 - ERROR - Replication failed

[Samir]

Hallo zusammen,

ich habe ein Problem mit ISPConfig3 und hoffe, dass hier jemand eine Lösung kennt oder wenigstens ein paar Tipps geben kann, wie ich das Problem lösen könnte.

Folgende Konfiguration:
Ich hab Centos 5.3 nach der Perfect Server Anleitung in HowtoForge auf einer virtuellen Maschine (Hyper-V) installiert. Hat alles ganz gut geklappt. Danach habe ich noch einen zweiten Server mit der gleichen Konfiguration erstellt. Auf beiden läuft ISPConfig3 mit der neuesten Version aus dem SVN.

Das ganze soll nun in einem Multiserver-Verbund laufen. Der erste Server bildet den Master und der zweite ist der Slave.

Nach der Installation von ISPConfig3 auf dem Master-Server habe ich alle Funktionalitäten erfolgreich getestet und es gab keinerlei Probleme. Dann habe ich ISPConfig3 auf dem Slave installiert und ihn in dem Master-Server eingebunden, was zunächst auch geklappt hat.

Das Problem:
Sobald ich eine Webseite erstelle, kommt folgende Fehlermeldung:

.06.2009-16:19 - ERROR - Replication failed. Error: (sys_group) UPDATE command denied to user 'ispcsrv2'@'192.168.80.81' for table 'server' # SQL: REPLACE INTO sys_group (`groupid`,`name`,`description`,`client_id`) VALUES ('2','test','','1')

Ich habe den kompletten Vorgang (inkl. Installation auf beiden Servern) mehrmals wiederholt und jedes mal wurde eine andere Tabelle bzw. ein anderer Befehl in der Fehlermeldung angegeben.

Vermutung:
Anscheinend stimmt was mit den Rechten des MySQL-Benutzers ispcsrv2 nicht. Dieser wird ja von ISPConfig automatisch erstellt und erhält die Rechte USAGE. Wenn ich aber die Rechte dieses Nutzers auf ALL PRIVILEGES setze, bevor durch den cronjob die Webseite erstellt wird, funktioniert alles einwandfrei. Aber dies ist m.E. keine adequate Lösung, da sie erhebliche Sicherheitsrisiken mit sich bringt (z.B. könnte der Slave alle Tabellen des Masters löschen).

Hat jemand eine Idee, warum die Rechte USAGE nicht ausreichen? ich vermute ja einen Bug, aber ich kann mir nicht vorstellen, dass der noch nicht gepostet wurde. Ich vermute halt, dass ich irgendwo etwas falsch eingestellt hab, aber was?

Bin dankbar für jede Hilfe!

 

[Till]

Das ist kein Bug in ISPConfig. Der Fehler bedeutet dass Du ein Berechtigungsproblem in der mysql DB hast. Ich vermute mal Du hast bei der Installation des slave was falsches angegeben. Der Installer fragt erstmal nach dem lokalen mysql Server, Da musst Du auf jeden Fall "localhost" als hostname lassen wie der Installer es vorschlägt und keinen anderen Hostnamen angeben. Dann im 2. Schritt werden die Zugangsdaten des mysql master Servers abgefragt.

 

[Samir]

jo...

hab ich auch genauso gemacht:

man kann einen MySQL-Server angeben. Dort hab ich die IP des Master-Servers angegeben. Das funkioniert auch, vorausgesetzt ich erlaube in der MySQL-Datenbank des Master den Zugriff von root von jedem Host aus.

Danach gebe ich die Zugangsdaten des Master-Servers ein und es wird alles installiert...

Zunächst funktioniert dann auch alles...

ich hab jetzt auch mal dem Benutzer ispcsrv2 die benötigten Rechte für die Tabellen server und sys_group gegeben (siehe Fehlermeldung). Dann klappts auch besser, zumindest ist die Fehlermeldung weg, aber dann tritt das Problem auf, dass die Dateien unter /var/www/domain.de/web immer wieder neu geschrieben werden...

 

[Till]

Du musst bei der ersten Eingabe localhost angeben und nicht die IP des master Servers. Erst bei der 2. Anbfrage, wo nach dem Master Server gefragt wird, musst Du den Hostnamen des master servers angeben und nicht dessen IP.

Wie Deine Fehlermeldung besagt, versucht er sich zu der IP 192.168.80.81 zu verbinden. localhost ist aber die IP 127.0.0.1. Also ahst Du enteweder eine falsche Ip bzw. einen falschen Server bei der ersten Frage des lokalen mysql Servers angegeben oder aber Deine /etc/hosts Datei ist inkorrekt und enthält keinen Verweis dass die IP 127.0.0.1 localhost ist.

 

[Samir]

Du musst bei der ersten Eingabe localhost angeben und nicht die IP des master Servers. Erst bei der 2. Anbfrage, wo nach dem Master Server gefragt wird, musst Du den Hostnamen des master servers angeben und nicht dessen IP.

Wie Deine Fehlermeldung besagt, versucht er sich zu der IP 192.168.80.81 zu verbinden. localhost ist aber die IP 127.0.0.1. Also ahst Du enteweder eine falsche Ip bzw. einen falschen Server bei der ersten Frage des lokalen mysql Servers angegeben oder aber Deine /etc/hosts Datei ist inkorrekt und enthält keinen Verweis dass die IP 127.0.0.1 localhost ist.

ich bin mir ziemlich sicher, dass ich die installation richtig durchgeführt hab: als erstes den lokalen server mit localhost und dann wird gefragt, ob man ein multiserver setup einrichten will. Das hab ich bestätigt und daraufhin hab ich die zugangsdaten des master servers eingegeben.

die fehlermeldung besagt ja, dass der user 'ispcsrv2' vom Rechner '192.168.80.81' auf die tabelle sys_group kein update durchführen kann. komischerweise wird als nächstes die SQL-Fehlermeldung ausgegeben, bei der die Tabelle server erwähnt wird. (Fehlermeldung siehe oben)

Wenn ich nun auf dem Master-server (mit der IP 192.168.80.80) dem user 'ispcsrv2'@'192.168.80.81' alle Rechte für alle Tabellen gebe, wird diese Fehlermeldung nicht mehr erzeugt. Ich hab sogar das installationsskript so umgeschrieben, dass die benötigten Rechte für genau diese beiden tabellen (also UPDATE für sys_group und server) vergeben werden. Danach tritt der Fehler auch nicht mehr auf.

Im Bugtracker wurde mir das gleiche geantwortet, aber ich hab die installation genau so durchgeführt.

Genau das gleiche Problem tritt übrigens auch in diesem Thread auf, aber dort gibt es auch keine Lösung. Ich hab auch wiseguy angeschrieben, aber leider ist es zu lange her, als dass er sich an die lösung erinnert.
http://www.howtoforge.de/forum/showthread.php?t=1205

Naja, nach der Veränderung im Installationsskript funktioniert zwar alles, aber trotzdem hab ich noch das Problem, dass die der Status der Zeilen in der Tabelle sys_datalog, in der die Veränderungen für den Slave-Server gelistet werden (anscheinend für die Replikation), noch bei "pending" steht, während in der Job-Queue im Webinterface keine Jobs angezeigt werden.

Können dadurch Probleme entstehen?

Also für mich sieht das nach einem Bug aus!

Benutzt denn hier jemand ISPConfig in der aktuellsten SVN-Version im Multiserver-Setup?

Das Problem wurmt mich wirklich sehr...

 

[Till]

Naja, nach der Veränderung im Installationsskript funktioniert zwar alles, aber trotzdem hab ich noch das Problem, dass die der Status der Zeilen in der Tabelle sys_datalog, in der die Veränderungen für den Slave-Server gelistet werden (anscheinend für die Replikation), noch bei "pending" steht, während in der Job-Queue im Webinterface keine Jobs angezeigt werden.

Das ist ok, dieses Feld wird nicht mehr verwendet.

Also für mich sieht das nach einem Bug aus!

Es laufen einige multiserver Systeme auch bei Entwicklern ohne ein Problem bei der Replikation und ohne manuellen Einfriff. Da der Fehler auch nicht auf meinen Systemen reproduzierbar ist auf denen ich sicherstellen kann dass die Angaben korrekt sind, kann ich einen Bug ausschließen.

vermutlich hast Du IP Adressen statt hostnamen angegeben oder die verwendeten Hostnamen können nicht von allen beteiligten Servern korrekt per DNS aufgelöst werden.

 

[Samir]

vermutlich hast Du IP Adressen statt hostnamen angegeben oder die verwendeten Hostnamen können nicht von allen beteiligten Servern korrekt per DNS aufgelöst werden.

Das kann ich ja sicherstellen, indem ich in die Host datei zur jeweiligen IP-Adresse die FQDN und den Hostnamen eintrage und das jeweils bei beiden Rechnern. Also müssten die Rechner beide erreichbar sein. Bei der Installation habe ich die FQDN (so ähnlich wie rechner.netzwerk.local - da die beiden Rechner nur im internen Netzwerk agieren sollen) eingegeben.

Die Fehlermeldung befindet sich ja auf dem Slave, das bedeutet ja, dass dieser mit dem benutzernamen ispcsrv2 auf der Master-DB ein UPDATE durchführen will (Stimmt das?). Ich dachte aber eigentlich, dass der Slave wegen der Replikation die geänderten Daten aus sys_datalog ausliest und daraufhin bei sich selber ändert. Demnach müsste er gar kein update auf dem Master vornehmen müssen. Oder hab ich da was falsch verstanden?

 

[Till]

Die Fehlermeldung befindet sich ja auf dem Slave, das bedeutet ja, dass dieser mit dem benutzernamen ispcsrv2 auf der Master-DB ein UPDATE durchführen will (Stimmt das?).

Nein, das stimmt nicht. Was bei Dir fehlschlägt ist die Replikation vom master zum slave. Es gibt zwar auch status updates in der anderen Richtung, aber nicht für die Tabelle sys_group. Wenn dort also eine falsche Ip beim connect steht dann wurde wie von mir angemerkt im Installer eine falscher Hostname angegeben oder der Hostname löst zur falschen IP auf.