ISPConfig Multiserver Setup: Problem DNS

#1
Hi,

Ich versuche seit Tagen vergeblich, ein Multiserver Setup mit einem Master auf dem alle Dienste laufen und einem Slave als Slave DNS aufzusetzen.

Den Master habe ich nach der Debian 8 Perfect-Server Anleitung installiert und habe vor der ISPConfig installation die nötigen Berechtigungen in der MySQL Datenbank gesetzt. (Wie in der Multiserver-Setup-Anleitung für Debian). Den Slave habe ich nach der Anleitung Own DNS Primary and Slave installiert.

Der Master zeigt den Slave nun an, aber es werden keinerlei Änderungen übernommen. Dann habe ich den entsprechenden Cron manuell ausgeführt und dabei stürzt jedes mal der Server ab. (Verbindung von außen nicht möglich) Ich habe die Installation mit zwei Servern versucht. Dedicated und Openvz Container. Beim VZ habe ich dann angezeigt bekommen das der Container noch läuft, aber mit einer extrem hohen last.

Debugging habe ich zwar auf beiden aktiviert. Der Slave gibt mir aber überhaupt keine Daten. Alle ISPConfig-Logs sind leer. Auf dem Master sind in der Jobwarteschlange folgende Jobs:

Datum Server Aktion Datenbanktabelle




05.01.2016 13:58 s1.beispiel.de Update server
05.01.2016 13:58 s1.beispiel.de Update server
05.01.2016 13:58 s1.beispiel.de Update server
05.01.2016 13:58 s1.beispiel.de Update server
05.01.2016 13:50 s1.beispiel.de Update server




Hat jemand ne Idee?
 
#4
Die Server können auf jeden Fall miteinander kommunizieren. Die auf dem Master angelegten DNS-Zonen lassen sich mittels des Resync-Tools auf den Slave übertragen.

Frage: Muss der Cronjob:
/usr/local/ispconfig/server/server.sh 2>&1 > /dev/null | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
auf dem Master UND auf dem Slave laufen oder nur auf dem Master?
 
#6
Okay. Weil auf dem Slave hat der ISPConfig installer den Cronjob gar nicht angelegt. Wenn ich das entsprechende Script über die Shell manuell aufrufe stürzt der Server ab.....
 
#8
Achso ja sorry. Von außen nicht erreichbar. Im Falle des OpenVZ Containers ist es so, dass der Container noch läuft, aber mit 100% Last. Der dedizierte Server stürzt aber genauso ab. Es ist also kein OpenVZ Problem.
 
#9
Von diesem Eintrag hab ich nach dem manuellen Cron Aufruf jede Menge im Log. Was bedeutet der?

05.01.2016-19:54 - DEBUG - There is already a lockfile set. Waiting another 10 seconds...
 
#11
Na steht doch da. Eine Lockdatei ist noch vorhanden.

Was heißt der dedizierte Server stürzt ab?
Ja aber was für ne Lockdatei ???? Wo find ich die???? Soll die noch vorhanden sein? Ist es normal , dass sich nach einem Cronaufruf geschätzte 15 Einträge davon im Log befinden. Scheinbar verhindert diese Lockdatei das synchronisieren.

Der dedizierte Server ist dann auch nicht mehr erreichbar. Lässt sich auch nicht mehr anpingen. Mit nem Hard-Reset bootet er dann wieder....
 
#12
Genau das ist die Aufgabe der Lockdatei. Sie soll verhindern, dass der Job mehrmals parallel läuft.

Such mal nach einer Datei .ispconfig_lock auf deiner Platte und lösche diese. So lange die Datei vorhanden ist, wird der Cronjob nicht ausgeführt. Denn der ist der Meinung, dass bereits ein Cronjob läuft.

Also wenn dein Server so abschmiert, dann hast Du ein ganz anderes Problem. Da ist ISPConfig dein kleinstes Problem.
 
#13
rm /usr/local/ispconfig/server/temp/.ispconfig_lock

Mir das noch nicht passiert, dass beim Install der cronjob fehlt. Bist Du Dir sicher, dass Du cron überhaupt installiert hast?
 
#15
Eine kleine Frage hätte ich noch: Im Tab Überwachung beschwert sich ISPConfig, dass auf dem Slave der FTP Offline ist. Da der Slave aber nur für DNS zuständig ist, soll ja auch kein FTP Online sein.

Im Tutorial ist die Box Datei-Server angehakt. Ist das richtig so? Soll ich die deaktivieren?
 

Werbung