ISPConfig Multiserver-Installation sauber upgraden

N

nicbec

New Member
Hallo zusammen,
aktuell arbeite ich an folgendem Problem:

Es gibt eine bestehende ISPConfig Multiserver Installation. Diese ist zu upgraden (OS und services).

Bestehend aus einem Master (server-a), einem Webserver (server-b), MySQL-Server (server-db), nameserver usw.

Diese laufen mit einem veraltetem Debian5.

Was ist der gängigste Weg die ganze Kiste auf moderne Beine zu stellen? Am besten ohne Downtime.

Debian eiskalt Upgraden? Gibt es bei einem Upgrade in Kombination mit ISPCOnfig irgendwelche bekannten Probleme die beachtet werden müssen?

Bei einer Testinstallation hatte ich Probleme mit MySQL und phpmyadmin.

Server einzeln austauschen gegen aktuellere vorinstallierte?

Vielen Dank
 
T

Till

Administrator
Debian eiskalt Upgraden? Gibt es bei einem Upgrade in Kombination mit ISPCOnfig irgendwelche bekannten Probleme die beachtet werden müssen?
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

an sich ja, von 5 auf 6 und dann von 6 auf 7. Außer Du nutzt mysql von dotdeb, da gibt es von 6 auf 7 Probleme mit Namenskollisionen bei Paketen. Dann ein ispconfig update mit reconfigure services machen, damit die Konfiguration auf den aktuellen Stand gebracht wird.
 
N

nicbec

New Member
Sicherungen werden gemacht.
Merkt das ISPConfig selbstständig die neue OS-Version oder muss man da noch was manuell konfigurieren?
 
N

nicbec

New Member
Ich habe jetzt das Upgrade auf einer Kopie der VM vom master-Server durchgeführt.

Zur Erklärung: Auf diesem läuft die ISPconfig-GUI (eigene subdomain:8080) und phpmyadmin unter einer subdomain phpmyadmin.domain.tld.
ISPCOnfigGUI läuft sauber.

phpmyadmin.domain.tld greift scheinbar nicht. Wenn ich dies über einen lokalen /etc/hosts eintrag aufrufe, dann wird mir die Debian Standard-Apache-html-seite "It Works" angezeigt.

Kennt jemand dieses Problem?
Im Logfile des "phpmyadmin"-vhosts stehen auch keine Einträge.

UPDATE:
Ich konnte das Problem tmeporär lösen indem ich den vhost nochmals von Hand angelegt habe. (Ohne eingreifen von ISPConfig)
Das ist sicher nicht sauber, aber es funktioniert erstmal.

Weitere Frage:
Wie sieht ein Update von ISPConfig aus.
update_ispconfig.sh sagt, ich habe bereits die aktuelle Version.
 
Zuletzt bearbeitet:
N

nicbec

New Member
So jetzt muss ich nach dem eigentlich recht erfolgreichen Upgrade nochmal nachfragen.

Nach dem Upgrade hat eigentlich alles auf Anhieb funktioniert.

Problem ist jetzt nur, dass das ISPConfig Konfigurationsanpassungen am Webserver nicht mehr sauber durchführt. Im Log vom ispconfig-cron steht seit dem soetwas:

Code: 
Sa 30. Nov 14:53:02 CET 2013 ln: Symbolische Verknüpfung »/var/www/clients/client18/domainname.tld« konnte nicht angelegt werden: Datei oder Verzeichnis nicht gefunden
Sa 30. Nov 14:53:02 CET 2013 setquota: Kann Quotadatei nicht öffnen //aquota.user: Datei oder Verzeichnis nicht gefunden
Sa 30. Nov 14:53:02 CET 2013 setquota: Kann Quotadatei nicht öffnen //aquota.user: Datei oder Verzeichnis nicht gefunden

Problem ist jetzt, dass das Verzeichnis "/var/www/clients/client18/" komplett falsch ist, denn wir haben damals den Documentroot komplett verlegt. ("/wwwroot/...")

Diesen nutzt er scheinbar aber nicht mehr.

Kennt jemand diesen Fehler?
 
T

Till

Administrator
Stell sicher dass /var/www ein bind mount in /etc/fstab ist welcher auf das Verzeichnis verweist in dem die Seiten liegen.
 
N

nicbec

New Member
Hallo Till,
vielen Dank für die Antwort.
Ich hatte das Problem temporär mit einem symlink von
/var/www/clients -> /wwwroot/www/clients
geholfen.
Die FInale Lösung ist dies aber nicht.

In der fstab ist seit dem Upgrade der entspreche Eintrag zu dem /wwwroot auskommentiert ist.

# /dev/sdb1 /wwwroot ext3 rw,suid,dev,exec,auto,nouser,sync 0 0

Außerdem merkwürdig, dass seitdem Upgrade neue Volumes auftauchen.
Auszug aus /etc/fstab:
/var/log/ispconfig/httpd/domain.tld /wwwroot/www/clients/client18/web156/log none bind,nobootwait 0 0
/var/log/ispconfig/httpd/domain.tld /wwwroot/www/clients/client6/web79/log none bind,nobootwait 0 0
/var/log/ispconfig/httpd/domain.tld /wwwroot/www/clients/client18/web59/log none bind,nobootwait 0 0
/var/log/ispconfig/httpd/domain.tld /wwwroot/www/clients/client53/web144/log none bind,nobootwait 0 0
/var/log/ispconfig/httpd/domain.tld /wwwroot/www/clients/client37/web101/log none bind,nobootwait 0 0


Um das erst genannte Problem zu lösen soll ich also ein bind-mount von /var/www auf /wwwroot/ setzen?
 
N

nicbec

New Member
So vielen Dank schonmal.

Der Mount hat grundsätzlich funktioniert denke ich.
Wenn ich /var/www/clients/ aufrufe, dann sehe ich alle Unterverzeichnisse von /wwwroot/www/clients.

Jetzt ist es nur so dass die Job-Queue dieses Servers in ISPConfig nicht mehr abgearbeitet wird.
Es erscheint kein Output, wenn ich das Skript manuell starte.

Im cron.log erscheint kein neuer Eintrag mehr. Hundert prozentig scheints also nicht zu funktionieren...

Muss ich noch irgendwas beachten?

PS: Wozu gebe ich eigentlich in den ISPConfig Einstellungen an, dass der DocumentRoot unter /wwwroot/www/ ist, wenn er pauschal von /var/www ausgeht?

EDIT:
Die Meldung "setquota: Kann Quotadatei nicht öffnen //aquota.user: Datei oder Verzeichnis nicht gefunden" kommt weiterhin im cron.log von ispconfig

EDIT2:
Alle geänderten Vhosts funktionieren nicht mehr. In der VHOST-Datei erscheint folgendes:
# Apache did not start after modifying this vhost file.
# Please check file /etc/apache2/sites-available/test.test.tld.vhost.err for syntax errors.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Ich bin aktuell ein wenig verzweifelt, denn seit dem Debian( und ISPCONFIG)-Upgrade scheint das System nicht mehr sauber zu laufen.

EDIT3:
Das in EDIT2 genannte Problem konnte ich lösen. Der Fehler war, dass ISPCONFIG die Vhosts plötzlich folgendermaßen anlegen wollte:
<Directory /wwwroot/www/test.test.tld>
AllowOverride None
Order Deny,Allow
Deny from all
</Directory>

<VirtualHost :80>
DocumentRoot /wwwroot/www/test.test.tld/web
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Siehe Fett-Rot-markierte Zeile. Bei allen Vhosts vorher hatte ISPCONFIG ein *:80 angelegt.
Als Workaround habe ich unter Server-IP-Adressen in ISPCONFIG die IP des Masters festgelegt. Anschließend habe ich das auf jeder Website von Hand in ISPCONFIG geändert. Danach klappt es. In meinen Augen ist das sehr unsauber.
Weiß hier jemand eine elegantere Lösung?
 
Zuletzt bearbeitet:
T

Till

Administrator
Die Frage ist eher wie es kommt dass Du da <VirtualHost :80> drin stehen hast, denn das gibt es an sich nicht. Hast Di vielleicht ein eigenes vhost template in conf-custom angelegt welches nicht an die aktuelle ispconfig version angepasst ist?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Werbung

Top