ISPConfig Multiserver-Installation sauber upgraden

Dieses Thema im Forum "Installation und Konfiguration" wurde erstellt von nicbec, 25. Nov. 2013.

  1. nicbec

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

    Till Administrator

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

    Till Administrator

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

    nicbec New Member

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

    Till Administrator

    Deshalb musst Du ja ein ISPConfig Update machen.
     
  6. nicbec

    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: 28. Nov. 2013
  7. nicbec

    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?
     
  8. Till

    Till Administrator

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

    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?
     
  10. Till

    Till Administrator

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

    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:
    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:
    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: 14. Dez. 2013
  12. Till

    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?
     

Diese Seite empfehlen