Root Server Systemupdate - Ubuntu 14.04 auf 18.04 updaten

  • Hallo

    ist es eigentlich möglich, einen (virtuellen) Root Server über die normale Aktualisierung mit Ubuntu 14.04 LTS auf 18.04 LTS zu aktualisieren?


    Im Juli 2015 habe ich diesen Root-Server gebucht:


    Root-Server L SATA v6 für 18.99 / Monat (monatlich kündbar)

    Virtualisierungstechnik: KVM

    Prozessor: Intel®Xeon® E5-26xxV3 (min. 2,3 GHz je Kern)

    RAM: 12 GB DDR4

    HDD: 320GB SATA ( / 240GB SSD)

    RAID: RAID10

    CPU-Kerne: 4 dediziert

    Ich hab da das damals aktuelle Ubuntu 14.04 LTS drauf gespielt und seit dem lauft er auch so.

    Ich hatte vorher, bei einem anderen Provider (hosteurope) ein Ubuntu 12.04 laufen, da hieß es, dass ich wg. dem Kernel des Wirtssystems (also der Host, auf dem der virtuelle Server lauft) gar kein neueres Ubuntu aufspielen könnte.

    Ist das hier genauso?


    Ich hab das nie gefragt, ich ging davon aus, dass auf einem vServer so was halt nicht geht.
    Ansonsten würde ich natürlich updaten, da mittlerweile einiges veraltet ist.

    Auch der Preis zwar.

    Aber ein neues Paket buchen, das zwar für die selbe Leistung (oder mehr) viel billiger ist, geht wohl sicher nicht ohne kompletten Umzug (was sehr aufwendig, lästig und somit teuer wäre).

    Oder gibt es da auch Möglichkeiten, mit Erhalten der IP usw.?


    Danke für Hinweise die zu sachdienlichen Ergebnissen führen ;)


    Gruß franc

  • [I]st es eigentlich möglich, einen (virtuellen) Root Server über die normale Aktualisierung mit Ubuntu 14.04 LTS auf 18.04 LTS zu aktualisieren?

    […]

    Ich hatte vorher, bei einem anderen Provider […] ein Ubuntu 12.04 laufen, da hieß es, dass ich wg. dem Kernel des Wirtssystems (also der Host, auf dem der virtuelle Server lauft) gar kein neueres Ubuntu aufspielen könnte. Ist das hier genauso?

    […]

    Aber ein neues Paket buchen, das zwar für die selbe Leistung (oder mehr) viel billiger ist, geht wohl sicher nicht ohne kompletten Umzug (was sehr aufwendig, lästig und somit teuer wäre). Oder gibt es da auch Möglichkeiten, mit Erhalten der IP usw.?

    Wie von alhazred geschrieben, kann man mittels sudo do-release-upgrade von 14.04 auf 16.04, und danach von 16.04 auf 18.04 wechseln. Dank der KVM-Virtualisierungstechnik ist auch der Kernel Bestandteil Deiner isolierten Umgebung (VM), ein Wechsel ist also beliebig möglich. Es ist sogar ratsam, zu überlegen, ob man aktuelle Kernel regelmäßig manuell einspielt/einspielen läßt; unter Ubuntu gibt es zudem einen Livepatch Service, der unbedingt einen Blick wert ist (für bis zu drei Rechner kostenlos!)

    Bzgl. Paketwechsel: (1) Man kann den Server herunterfahren, um ein Abbild zu erstellen und dieses Abbild danach auf einen anderen Server aufzuspielen (IP-Adressen sind anzupassen). Das sollte relativ problemlos/zügig gehen.

    (2) Es ist möglich, gegen Gebühr zusätzliche IPv4/IPv6-Adressen zu buchen, welche man dynamisch oder via Auftrag "umziehen" kann – also an den neuen Server übertragen. Ein Umzug der "Standard-IP-Adressen" des Pakets ist wahrscheinlich in dieser Form nicht möglich, aber hier empfiehlt sich eine Nachfrage beim Support. Ob sich das rechnet ggü. einer Neuaufsetzung oder der Akzeptanz, dass der neue Server eben neue IP-Adressen hat, muss man individuell entscheiden.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Wie von alhazred geschrieben, kann man mittels sudo do-release-upgrade von 14.04 auf 16.04, und danach von 16.04 auf 18.04 wechseln. Dank der KVM-Virtualisierungstechnik ist auch der Kernel Bestandteil Deiner isolierten Umgebung (VM), ein Wechsel ist also beliebig möglich. Es ist sogar ratsam, zu überlegen, ob man aktuelle Kernel regelmäßig manuell einspielt/einspielen läßt; unter Ubuntu gibt es zudem einen Livepatch Service, der unbedingt einen Blick wert ist (für bis zu drei Rechner kostenlos!)

    Bzgl. Paketwechsel: (1) Man kann den Server herunterfahren, um ein Abbild zu erstellen und dieses Abbild danach auf einen anderen Server aufzuspielen (IP-Adressen sind anzupassen). Das sollte relativ problemlos/zügig gehen.

    (2) Es ist möglich, gegen Gebühr zusätzliche IPv4/IPv6-Adressen zu buchen, welche man dynamisch oder via Auftrag "umziehen" kann – also an den neuen Server übertragen. Ein Umzug der "Standard-IP-Adressen" des Pakets ist wahrscheinlich in dieser Form nicht möglich, aber hier empfiehlt sich eine Nachfrage beim Support. Ob sich das rechnet ggü. einer Neuaufsetzung oder der Akzeptanz, dass der neue Server eben neue IP-Adressen hat, muss man individuell entscheiden.

    Danke, das klingt ja vielversprechend :)

    Ich würde dann zunächst abends ein Image machen, falls was schief geht, dann den release upgrade.


    Laufen die unter 14.04 installierten Programme (namentlich postfix und dovecot) problemlos nach so einem Upgrade?

    Oder laufen die Programme dann erst wieder, wenn ich auch die dann aktualisiere?


    Es ist ein Produktivserver, ungern wäre ich damit einen halben Tag offline, wenn ich dann notfalls ein Image zurück spielen müsste.

    Ein Paketwechsel (das Paket: RS 1000 G8, Intel® Xeon® Gold 6140, 8 GB DDR4 RAM, 2 dedizierte Kerne, 40 GB SSD / 320 GB SAS) für 9.- im Monat (bei 1 Monat Vertragslaufzeit) würde eigentlich reichen, damit würde ich im Monat 10.- sparen.

    Allerdings hatte mich gerade der IP-Wechsel beim letzen Wechsel immens aufgehalten (namentlich DNS-Probleme), das hat mich Tage Arbeit und Ärger gekostet. Allerdings behalte ich es im Hinterkopf.





  • Laufen die unter 14.04 installierten Programme (namentlich postfix und dovecot) problemlos nach so einem Upgrade?

    Oder laufen die Programme dann erst wieder, wenn ich auch die dann aktualisiere?

    Die Programme aktualisieren sich normalerweise beim Upgrade. Ob die Konfiguration mit der neuen Version kompatibel ist weis ich leider nicht. Vermutlich schon.

    Am besten vorher ein Backup machen und probieren.

  • [Es ist ein Produktivserver, ungern wäre ich damit einen halben Tag offline, wenn ich dann notfalls ein Image zurück spielen müsste.

    In diesem Fall kann man natürlich beide Schritte kombinieren: Neuen Server anmieten (geht ja auch monatsweise), Snapshot-Abbild mit 14.04-Image transferieren, auf neuem Server alles unter 18.04 zum Laufen bringen (da die neue IP-Adresse nicht im DNS hinterlegt ist, stört das den laufenden Betrieb nicht), und danach DNS-Einträge anpassen. In der Zwischenzeit aufgelaufene Änderungen sind anwendungsspezifisch zu synchronisieren. Dieser Vorgang reduziert eine für Kunden sichtbare Ausfallzeit auf ein Minimum.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Gestern habe ich nun angefangen damit (hatte zuvor noch kein freies Wochenende) und erst mal eine "Serveroptimierung" durchgeführt. Wurde zuvor gesagt, dass es bis 1h47min dauern könne, dauerte aber nur eine 3/4 h.

    Zuvor war der Speicherplatz mit 312 von 312 GB angegeben, danach mit 68 von 312, scheint also funktioniert zu haben.

    Heute abend dann mache ich ein Image und versuche den Upgrade...

  • Uff. Hat geklappt. Das "No new release found" lag an meinem schon vor langem editiertem:

    Code
    /etc/update-manager/release-upgrades
    ...
    [DEFAULT]
    Prompt=never
    ...

    Das hab ich wieder auf lts gestellt und die Datei release-upgrade-available wieder erstellt (damals gelöscht):

    Code
    touch /var/lib/ubuntu-release-upgrader/release-upgrade-available

    Danach wurde das Update auf 16.04 LTS wieder gezeigt.


    Das Update hat eine gute Weile gebraucht und ich musste zig mal bestätigen, dass ich die bestehenden Konfigurationsdateien (für die ganzen aktualisierten Programme) beibehalten will.


    Zuvor hatte ich natürlich ein Image gezogen, das ging aber wiederum erst, nachdem ich mehrfach eine Speicherplatzoptimierung durchgeführt hatte (Defrag also, kenn ich ja von VMware usw.). Die Speichernutzung war am Schluss bei nur noch 60 von 312 GB (von vorher 312 von 312) ich hatte vorher aber auch einiges gelöscht (entschlackt).

    Jetzt werde ich beim Login (per SSH) mit:


    Zitat


    Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-150-generic x86_64)

    empfangen :)


    Ich muss "nur" noch mindestens Logwatch ( /etc/cron.daily/00logwatch: Wrong configuration entry for "Service", if "All" selected, only "-" items are allowed) und certbot (/bin/sh: 1: certbot: not found) reparieren. Aber ich vermute, da sind schon noch andere Programme nicht mehr so kompatibel.
    Das Wichtigste, Mail und Apache scheinen aber noch zu funktionieren :)

    Danke!

  • Übrigens ging das Erstellen des Image sehr schnell, sekundenschnell vielleicht sogar. Die Speicheroptimierung dauerte ca. 3/4 h, dann beim 2. Mal auch ganz schnell.

    Scheints ist ein Image "nur" ein Snapshot.

  • Ich habe noch ein Problem mit dem Storagespace, der wird nicht mehr eingehängt:

    Code
    #mount -t nfs 1.2.3.4:/voln12345a6 /mnt/storagespace
    mount.nfs: rpc.statd is not running but is required for remote locking.
    mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
    mount.nfs: an incorrect mount option was specified


    Was kann das sein?

    nfs-common ist (noch) installiert, Version 1.2.8-9ubuntu12.2

  • Was kann ich denn tun, um den storagespace dauerhaft eingebunden zu lassen?

    Wenn systemctl start rpc.statd jedes Mal erforderlich ist, um den Dienst manuell zu starten, bedeutet dies, dass er nicht automatisch nach einem Reboot gestartet wird; ein einmaliger zusätzlicher Aufruf von systemctl enable rpc.statd sorgt dafür.

    Der Rest ist in zahlreichen Howtos (beispielsweise hier ab Schritt 5) erläutert.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Code
    #systemctl enable rpc.statd
    Failed to execute operation: No such file or directory

    Hm. Ich glaube ich muss erst mal verstehen, was das ist, "rpc.statd".

    Ich habe in der Zwischenzeit in fstab den Parameter eingefügt:

    Code
    1.2.3.4:/voln12345a1      /mnt/storagespace       nfs     rw,suid,dev,exec,auto,nouser,async,nolock       0       0

    also indem ich defaults durch rw,suid,dev,exec,auto,nouser,async,nolock ersetzt habe, also das nolock angehängt habe.

    Vermutlich hätte ich das nolock auch ans defaults anhängen können, wollte aber nicht so viel experimentieren, immerhin ist es ein "Produktivserver"

    Scheint aber zu gehen - nach Neustart ist er noch da, der storagespace, bis jetzt.

  • In diesem Fall kann man natürlich beide Schritte kombinieren: Neuen Server anmieten (geht ja auch monatsweise), Snapshot-Abbild mit 14.04-Image transferieren, auf neuem Server alles unter 18.04 zum Laufen bringen (da die neue IP-Adresse nicht im DNS hinterlegt ist, stört das den laufenden Betrieb nicht), und danach DNS-Einträge anpassen. In der Zwischenzeit aufgelaufene Änderungen sind anwendungsspezifisch zu synchronisieren. Dieser Vorgang reduziert eine für Kunden sichtbare Ausfallzeit auf ein Minimum.

    So, heute abend gegen 20 Uhr ist es geplant, das do-release-upgrade auf 18.04 von 16.04 aus.

    Zuerst dann wieder Systemoptimierung durchführen, bin bei 159 von 312 GB belegt:

    Zitat


    Es ist eine intensive Speicher-Optimierung notwendig. Diese kann bis zu 54 Minuten andauern.

  • So, heute abend gegen 20 Uhr ist es geplant, das do-release-upgrade auf 18.04 von 16.04 aus.

    Zuerst dann wieder Systemoptimierung durchführen, bin bei 159 von 312 GB belegt:

    df zeigt allerdings nur belegte 54 G an:

  • fstrim -a sollte da die Lösung sein.

    Ich hatte im SCP die Speicheroptimierung durchgeführt, dauerte ca. 40 Minuten, danach war das System wieder "schlank" :)
    Danach das do-release-upgrade, das lief auch eine Weile, wobei man dabei sitzen muss und immer wieder die bestehenden Konfigurationsdateien erhalten (mit "N") und dann ging alles noch.

    Ubuntu 18.04 jetzt :)


    Im Moment bin ich an PHP dran, will die 7.4 haben, Ubuntu 18.04 kommt mit der 7.2. Ein Kunde hätte aber gerne die 7.4 (obwohl es eigentlich egal ist, weil die 7.2 ja auch noch eine Weile gepflegt wird, siehe LTS).