Upgrade LiveConfig Cluster (Reihenfolge & PHP-Versionen)

  • Hallo,


    da wir auf unsere Anfrage vom 15.12.2020 (Ticket LC#2020121534000027) leider noch immer keine Rückmeldung erhalten haben, versuche ich es diesmal direkt hier im Forum.


    Wir betreiben einen LiveConfig Cluster bestehend aus mehreren Debian-Systemen (Business-Lizenz in Kombination mit getrennten Webservern, Mailservern, Datenbankservern und ein gesondertes System für den LiveConfig-Zugang) und würden diesen gerne auf die jeweils nächste Debian-Version aktualisieren. Dazu zwei Fragen:


    1)
    Spielt die Reihenfolge der Upgrades eine Rolle, sollte beispielsweise der Server mit der Business-Lizenz zuerst an die Reihe kommen? Oder ist das nicht relevant und wir können das beliebig durchgehen? Gibt es sonst etwas in Bezug auf Liveconfig zu beachten?


    2)
    Zum Thema PHP gibt es hier im Forum z.B. diesen Topic:
    https://www.liveconfig.com/de/…%C3%A4nderung-PHP-Version
    Wir würden im Rahmen der Upgrades natürlich auch bei den PHP-Versionen ein wenig "aufräumen" wollen. Gehe ich richtig in der Annahme, das LiveConfig als Default-Version immer die installierte PHP-Basisversion von Debian nutzt? Wenn man ein älteres php-opt Paket entfernen möchte, müssen die jeweiligen Domains immer noch manuell in der MySQL-Datenbank von LiveConfig entsprechend abgeändert werden, oder gibt es hierzu bereits einen anderen Mechanismus?

  • Spielt die Reihenfolge der Upgrades eine Rolle, sollte beispielsweise der Server mit der Business-Lizenz zuerst an die Reihe kommen? Oder ist das nicht relevant und wir können das beliebig durchgehen? Gibt es sonst etwas in Bezug auf Liveconfig zu beachten?


    Was die LiveConfig-Versionen betrifft spielt das eigentlich nur dann eine Rolle, wenn es um sehr große Versionssprünge geht - das ist im Changelog jeweils vermerkt, und auch LiveConfig lehnt dann ggf Verbindungen zu "inkompatiblen" Systemen ab.


    Im Allgemeinen empfehlen wir immer erst die Clients zu aktualisieren, und ganz zum Schluß den LiveConfig-Master. Grund hierfür ist, dass bei manchen Updates Aktualisierungen der Konfigurationen angestoßen werden - somit werden die auf den Clients dann gleich in der aktuellsten Version ausgeführt.


    Zitat

    Wir würden im Rahmen der Upgrades natürlich auch bei den PHP-Versionen ein wenig "aufräumen" wollen. Gehe ich richtig in der Annahme, das LiveConfig als Default-Version immer die installierte PHP-Basisversion von Debian nutzt? Wenn man ein älteres php-opt Paket entfernen möchte, müssen die jeweiligen Domains immer noch manuell in der MySQL-Datenbank von LiveConfig entsprechend abgeändert werden, oder gibt es hierzu bereits einen anderen Mechanismus?


    Seit LiveConfig 2.10 haben Sie unter Serververwaltung -> Web eine Box "PHP-Version" - da sehen Sie welche PHP-Versionen noch mit wie vielen Subdomains genutzt werden. Demnächst wird da auch eine Anzeigemöglichkeit dieser Subdomains dazu kommen.
    Es gibt ab LiveConfig 2.11 (aktuelle Preview) zudem die Möglichkeit, alte PHP-Versionen nicht mehr für neue Subdomains zu Verfügung zu stellen. Somit können "alte" Konfigurationen weiter betrieben werden und die entsprechende PHP-Version so langsam aber sicher aussterben.


    Zur Standard-Version: siehe https://www.liveconfig.com/de/…d-php-version-%C3%A4ndern
    Infos zum Upgrade von Debian 8 auf 9: https://www.liveconfig.com/de/kb/debian-upgrade-8/ (den Abschnitt zu PHP 7 beachten)


    Viele Grüße


    -Klaus Keppler

  • Vielen Dank für die Rückmeldung! Wir haben die Upgrade-Vorgänge nun einmal an einem Einzelsystem getestet (Debian 8 -> 9 -> 10). Das Update auf Stretch verlief völlig problemlos. Nach dem Update auf Debian Buster und dem abschließenden "apt-get autoremove" möchte das System allerdings eine ganze Menge an Paketen deinstallieren, welche aber natürlich noch benötigt werden:


    Code
    The following packages will be REMOVED:
      apache2 apache2-bin apache2-data apache2-suexec-pristine apache2-utils clamav clamav-base clamav-daemon clamav-freshclam clamav-milter clamdscan default-mysql-server dh-python dns-root-data
      g++-6 galera-3 gnupg-agent imagemagick imagemagick-6-common imagemagick-6.q16 libaio1 libapache2-mod-fcgid libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libargon2-0 libbind9-140
    [...]
    linux-image-3.16.0-11-amd64 mariadb-client-10.3 mariadb-client-core-10.3 mariadb-common mariadb-server-10.3 mariadb-server-core-10.3 mysql-common netpbm opendkim php-common php-imagick php5-cgi
      php5-cli php5-gd php5-imap php5-json php5-mcrypt php5-mysql php5-readline php5-sqlite php7.0-cli php7.0-common php7.0-json php7.0-opcache php7.0-phpdbg php7.0-readline php7.3-cli php7.3-common
      php7.3-json php7.3-opcache php7.3-readline proftpd-basic proftpd-doc python-pyasn1 python3-distutils python3-lib2to3 python3.5 python3.5-minimal quota


    Ist dieses Verhalten normal bzw. warum landen die Pakete im Autoremove? Mittels "apt-get install [Paketnamen]" wechseln diese auf "manually installed" und verschwinden aus der Autoremove-Warteschlange, daher gehe ich davon aus das es sich hierbei um mitinstallierte Abhängigkeiten handeln muss (vom Liveconfig-Metapaket?). Im Prinzip sind wir so vorgegangen wie hier beschrieben:


    https://www.liveconfig.com/de/kb/debian-upgrade-9/


    Code
    apt-get upgrade && apt-get dist-upgrade
    /etc/apt/sources.list (stretch durch buster ersetzt)
    /etc/apt/sources.list.d/liveconfig.list (stretch durch buster ersetzt)
    apt update
    apt install apt dpkg
    apt upgrade
    apt full-upgrade
    apt-get autoremove (hier tritt das Problem dann auf)
  • Als Zusatzinfo:


    Das Problem mit dem Autoremove trat bisher immer bei den Systemen auf, welche seit Debian 8 mit dem "liveconfig-meta" Paket installiert wurden. Beim Upgrade von Debian 8 -> 9 läuft alles einwandfrei, von 9 -> 10 möchte das System die Einzelpakete deinstallieren. Wenn vor dem "apt-get autoremove" ein "apt install liveconfig-meta" nochmals ausgeführt wird, bleiben die Pakete erhalten und es wird wirklich nur nicht mehr benötigtes deinstalliert. Auf unserem Liveconfig-Cluster wurden die Pakete gezielt und ohne Meta-Paket installiert, daher gehe ich davon aus das es dort nicht zu diesem Problem kommen wird.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!