# ISPConfig Multiserver-Installation sauber upgraden



## nicbec (25. Nov. 2013)

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


----------



## Till (25. Nov. 2013)

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


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.


----------



## Till (25. Nov. 2013)

Und natürlich vorher immer Backups machen, falls doch was schief geht.


----------



## nicbec (25. Nov. 2013)

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


----------



## Till (25. Nov. 2013)

Zitat von nicbec:


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


Deshalb musst Du ja ein ISPConfig Update machen.


----------



## nicbec (28. Nov. 2013)

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.


----------



## nicbec (1. Dez. 2013)

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:


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


----------



## Till (2. Dez. 2013)

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


----------



## nicbec (7. Dez. 2013)

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?


----------



## Till (9. Dez. 2013)

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


Ja, denn symlinks akzeptiert ispconfig in web Pfaden nicht mehr da sie von Kunden verwendet werden könnten umd das System anzugreifen und sich mehr Rechte zu verschaffen.


----------



## nicbec (14. Dez. 2013)

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.


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


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?


----------



## Till (16. Dez. 2013)

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?


----------

