Ubuntu 20.04 LTS Focal Fossa Upradeerfahrungen [Kommentar]
Neu = gut?
Am 23.04 ist offiziell die nächste LTS Version von Ubuntu erschienen.
Da ich Ubuntu für meinen VPS nutze und beim letzten Update auf 18.04 der Prozess sehr rund verlief war ich – wie sich anschließend gezeigt hat – etwas zu optimistisch / mutig.
Der normale Prozess beim Release Upgrade ist bei Ubuntu über “sudo do-release upgrade” den Prozess zu starten. Das funktioniert aktuell noch nicht, wenn man von Ubuntu 18.04 LTS Bionic kommt. Das hat seine Gründe, wie ich festgestellt habe. Über sudo do-release upgrade -d kann man etwas nachhelfen.
Ich hatte zwar ein vollständiges Backup von 18.04 LTS aber ich hatte nicht ernsthaft damit gerechnet, dass ich es brauche. Allerdings habe ich damals bis zum ersten Patch gewartet und hatte auch deutlich weniger auf dem Server installiert.
Upgrade mit Überraschungen
Wie waren die Erfahrungen bei der Installation? Sehr durchwachsen. Je nach Zugriff auf den Installer (z.B. VNC auf einem VPS) kann ich nur davon abraten Detail / Vergleichsdialoge oder ähnliches aufzurufen. Man sollte sich auf simples ja / nein beschränken.
Teilweise werden Konfigurationdialoge ohne Rückfrage erzwungen und wenn man dann versucht sie zu verlassen wird das als Versuch gewertet das komplette Upgrade abzubrechen (bei mir z.B. mehrere LDAP Dialoge). Generell sollte der ganze Upgradeprozess robuster sein. Das mag aber auch auf andere Linux Versionen zutreffen.
An einer Stelle ich bei mir die Installation einer Endlosschleife gelandet, die ich nur durch Abbruch der Installation beenden konnte.
man path config
updating database manual page
Das scheint aber nicht ungewöhnlich zu sein oder spezifisch für Ubuntu 20.04. Trotzdem hat mein definitiv kein gutes Gefühl, wenn man die Installation abbrechen muss. Der Beim Versuch mit sudo apt upgrade das Upgrade fort zu setzten war DPKG durch einen Prozess geblockt. Ich habe den Prozess über kill <id> beendet. Anschließend lies sich sudo apt upgrade wieder starten und das Upgrade fortsetzen.
Darf es etwas weniger sein?
Nach der Installation waren diverse Pakete deinstalliert. Das hängt damit zusammen, dass z.B. FirewallD diverse andere Pakete voraussetzt. Auch der X2GOCLIENT verwendet teilweise diese Pakete. Diese Pakete werden teilweise durch neue Versionen mit anderen Namen ersetzt. Um also FirewallD auf den aktuellen Stand zu bringen muss vorher X2GO und FirewallD deinstalliert werden, dann die diversen alten Pakete runter, die neuen Pakete drauf und danach wieder X2GO und FirewallD.
Während des Installationsprozesses werden diverse Pakete entfernt (z.B. auch Webmin, das ist ein Cockpit zur Steuerung des Webservers). Neu installiert werden sie aber nicht alle. Ohne Backups ist das Upgrade also eine ganz schlechte Idee, weil Webmin bei mir z.b. auch nach der Neuinstallation nicht wieder richtig lief. Erst das Rücksichern der alten Ordner (auch die diversen Ablageordner muss man erst mal kennen – im Falle von Webmin zum Beispiel /etc/webmin, /var/webmin, /usr/shares/webmin/.
Empfohlene Variante? – lieber nicht
Die zweite Installationsvariante (sources bionic gegen focal tauschen und anschließend dist-upgrade ausführen) hat sich bei mir wegen diverser nicht erfüllbarer Abhängigkeitsbeziehungen in Endlosschleifen geendet. Deinstallation nicht möglich weil, x gebraucht wird, x hängt von y ab aber y kann nicht installiert werden. Das heißt bei dieser Variante zerlegt sich Ubuntu selber.
Bei Apache wurde ein Mod deinstalliert und die Konfiguration wird nun schärfer geprüft. Im Meinem Fall wurde der SSL Port für SSL / GNUTLS belegt (also doppelt), früher wurde wohl einfach der zweite Eintrag genutzt und ein Mod von Apache wurde beim Upgrade deinstalliert (Reparatur über a2enmod socache_dbm).
Zur Sicherheit habe ich auch OpenOTP auf dem Server (Token zusätzlich zur Passworteingabe was verhindert, dass sich jemand auf dem Server anmelden kann, der das PW erlangt hat). Das Problem ist noch auf meiner To-Do Liste. Offenbar gibt es Probleme bei der Kommunikation von LDAP und der PAM Anmeldung. Warum ist mir aber noch nicht klar.
Und Ubuntu 20.04 verursacht Probleme im Kontext GUI. Ich habe es bisher auf zwei VPS Servern von Contabo installiert (VPS SSD und HDD) und in beiden Fällen ist der Start der grafischen Oberfläche Gnome nicht möglich. Auch das Problem ist noch ungelöst.
Bei X2GO verhält sich Ubuntu auch anders. Ohne Root Rechte lassen sich einige Programme nicht mehr starten. Bei vielen Programmen macht das wenig bis keinen Sinn. Beispielsweise lässt sich die Konsole nur mit root Rechten öffnen. Dort muss man aber eh ein Passwort eingeben, um irgendwelche Aktionen durchzuführen. Was soll also diese Zusatzprüfung? Somit meldet man sich gleich als Root an, das ist viel schlimmer.
Stand heute ist der Upgradeprozess also eher im Beta oder Alphastadium aber definitiv nicht für produktive Server geeignet, wenn man kein Snapshot hat. Ich habe das System zwar mit einem Backup auf den Stand vor dem Releaseupgrade zurückversetzen können aber dabei muss man höllisch aufpassen bei einem Laufenden Linux oder gleich ein Rescue System nutzen, was aber auch diverse Probleme mit sich bringt (Stichwort Rechte).
Fazit und Ausblick
Nicht ohne Grund wird das Upgrade erst zum ersten Patch auf 20.04.1 angeboten.
Aktuell bieten die meisten auch keine focal Version an. Somit ist es durchaus angeraten einige Wochen / Monate zu warten.
Erste Tests zeigen, dass 20.04 unter bestimmten Rahmenbedingungen im Schnitt 25% schneller als 18.04. Wenn der Upgradeprozess also irgendwann mal rund läuft und die o.g. Probleme (GUI, LDAP, X2GO, Webadm) irgendwann behoben sind, ist das ein gutes Upgrade.
Einige Versionen in Ubuntu 20.04 waren ziemlich vorsintflutlich. Der Versionssprung ist teilweise dementsprechend groß.
Aktuell kann ich von einem Upgrade auf einem produktiven Server aber nur abraten. Wenn man es versuchen will ist ein Snapshot sehr hilfreich. Wenn man die Option nicht hat, dann benötigt man wenigstens ein Backup und einen Zugriff auf ein Rescue System.
Das ist eine Voraussetzung, an der man bei vielen VPS Anbietern bereits scheitert. In dem Kontext muss ich den Support und die Möglichkeiten bei Contabo loben (nein, ich bekomme für die Aussage kein Geld und wurde auch nicht von Contabo darum gebeten das zu erwähnen).
Man sollte nach meinen Erfahrungen auf eine Downtime von mindestens einem Tag planen und ggf. auch damit rechnen, dass man ein Backup zurückspielen muss. Das hängt natürlich individuell davon ab was auf dem Server alles läuft. Bei mir ist das schon einiges.
Nachtrag 1 27.04.2020 – 16:55
Das Problem mit OpenOTP wurde mir vom Support bestätigt. Wenn man die Zertifikatsprüfung zwischen Webadm und OpenOTP deaktiviert, dann geht es wieder (einfach den Zertifikatseintrag bei OpenOTP auskommentieren). D.h. das LDAP Problem ist noch mal ein anderes. Wobei mir aktuell nicht so ganz klar ist, ob das wirklich ein Problem ist. Das sieht eher nach einer Zusatzfunktion aus, die nur halb konfiguriert ist. Scheinbar ist das eine zusätzlich genutzte Variante (Authentifizierung von LDAP statt mit PW File), die mit Ubuntu 20.04 scharf geschaltet wird, obwohl ich die Konfiguration abgebrochen habe, da ich mit SLAPD bereits einen funktionierenden LDAP Server habe.
Das Problem der nicht aufrufbaren Konsole konnte ich umgehen, in dem ich einfach einen anderen Terminalemulator installiert habe (Terminator).
Somit bleibt noch das Problem bei der GUI in VNC, das ich bisher noch nicht lösen konnte (aktuell weiß ich aber auch nicht, ob dafür evtl. Anpassungen vom VPS Anbieter nötig sind). Somit sieht es nun nicht mehr so schlecht aus. Trotzdem ist Ubuntu 20.04 als Gesamtpaket noch recht experimentell.
Wie ich gerade festgestellt habe geht auch RDP noch nicht. Aber das war schon immer nicht so ganz stabil und kommt eigentlich auch aus der Windows Welt. Das muss also nicht zwingend mit Ubuntu 20.04 zu tun haben aber das es auch GUI Probleme gibt, ist die Wahrscheinlichkeit durchaus vorhanden.
Ein RDP Zugang ist aber immer dann hilfreich, wenn man einen grafischen Zugang aus der Ferne benötigt (zum Beispiel auf dem Handy oder Pad und funktioniert auch mit iOS Devices). Das Thema werde ich aber erst angehen, wenn die GUI funktioniert. X2Go, RDP und Gui verwenden X11 / XORG. Somit beeinflussen die sich gegenseitig.
Nachtrag 2 03.05.2020 – 8:30
Ein paar Nachwehen gibt es noch aber teilweise auch Sachen, die durch das Update erst aufgefallen sind aber schon vorher da waren (vermutlich bereits durch das 18.04.4 Update).
Aktuell stürzt NGINX reproduzierbar zu einer bestimmten Uhrzeit mit einem Coredump ab. Das hatte ich vorher noch nie. Da ich die Ursache anfangs noch nicht ermitteln konnte habe ich mir nun mit restart always im Service Eintrag beholfen. D.h. mitten in der Nacht ist Nginx für zwei Sekunden weg. Das sollte verschmerzbar sein.
Das Problem hängt scheinbar damit zusammen, dass NGINX neuerdings empfindlich darauf reagiert, wenn ein Host nicht erreichbar ist. Da ich Nginx im Proxymodus auf einem Apache 2 Server nutze und den Nachts für Zertifikatsupdates durchstarte, killt das den NGINX gleich mit (die Fehlermeldung in den logs besagt, dass der Upstream nicht verfügbar ist). Die Lösung ist eine Variable statt einer direkten Adressierung.
Die o.g. Probleme (Stand 27.04) sind nach wie vor vorhanden. Auch jetzt sind diverse Repositories noch nicht für Focal verfügbar.
Ich habe einen neuen VPS bei Contabo augesetzt mit einem frischen Ubuntu 20.04 – die GUI Probleme in VNC sind auch dort vorhanden. Ich habe diverse Guides im Netz befolgt und Ubuntu Desktop, Gnome Desktop und StartX Pakete installiert. Weiterhin habe ich den Displaymanager testweise gewechselt (gdm3 / lightdm). Keine Variante hat reproduzierbar funktioniert.
Einmal habe ich den Desktop zu Gesicht bekommen aber reproduzieren konnte ich es später nicht (plötzlich war er im VNC sichtbar, währen ich gerade im Terminal gearbeitet habe).
Das heißt irgendwie geht es aber ich habe nach mehreren Stunden basteln aufgegeben. Das ist bestenfalls Alphazustand. Zum Glück kommt man mit X2Go und Webmin i.d.R. Auch ohne die Linux Standard Gui zurecht.
Bei Webmin ist noch ein Problem hinzugekommen. Die CPU und RAM Monitore im Dashboard sind verschwunden.
Die Webmin Probleme sind auf dem frischen VPS nicht vorhanden. Wie ich festgestellt habe liegt das an den Einstellungen für den Befehl PS im Prozess Manager von Webmin. Entweder funktionierende Gauges für CPU / Ram (Einstellung Linux) oder die Prozessliste (andere Einstellungen z.B. HPUX). Beides zusammen geht nicht. Ich habe einen Bugreport bei Webmin dazu eröffnet.
In Summe kann man Ubuntu 20.04 bei einfachen Setups nutzen oder eben wenn man experimentierfreudig ist. Ansonsten sollte man auf 20.04.1 warten.
Nachtrag 3 03.07.2020
Die meisten Probleme konnte ich unterdessen einkreisen. Das Nginx Problem hatte ich ja bereits im letzen Update bedchrieben. Nginx reagiert unterdessen offenbar äußerst empfindlich darauf, wenn das Weiterleitungsziele zum Zeitpunkt des Nginx starts nicht verfügbar sind. Das lässt sich über dynamische Aufrufe beheben.
set $platzhalter1 https://<URL>:8082;
proxy_pass $platzhalter1;
Früher hat man einfach bei proxy_pass die URL direkt eingetragen. Durch die Variable prüft Nginx nicht beim Start, sondern beim Aufruf.
Die externen Repositories sind jetzt weitgehend (noch immer nicht alle) für Focal verfügbar.
Die Probleme mit Webmin lagen an einem Bug in Webmin, der im aktuellsten Entwicklungsstand behoben ist. Das ist also ein Fehler in Kombination von Webmin / Ubuntu 20.04
Die Desktop Probleme auf dem VPS waren / sind ein ganzes Sammelsurium von Effekten. Es wurden automatisch nicht alle Treiber installiert, die für die virtuellen Devices benötigt wurden. Somit musste ich Maus / Tastatur Treiber manuell nachinstallieren. Weiterhin funktioniert der Login Screen von GDM nicht auf dm VPS (bei einem Wechsel auf lightdm funktioniert der Login Screen).
Zusätzlich sind zwingend root Rechte erforderlich, damit der Ubuntu Desktop auf dem VPS startet. Die Standardlösungen, die man beim googeln findet helfen alle nicht. Auch ein Kontakt zum Support hat nichts gebracht. Offenbar sind die Probleme aber VPS bezogen also nur für einen überschaubaren Teil der Anwender relevant.
Wenn ich also den GDM service stoppe und mit sudo startx aufrufe, gibt es auch einen Desktop zu bewundern. Der automatische Start in die GUI funktioniert nach wie vor nicht. Auf einem Server kann man damit leben, da man die GUI in der Regel nicht so oft verwendet.
Bei einem Aufruf des Dektop per RDP gilt das gleiche – aktuell geht es nur mit ROOT Rechten.
Das OpenOTP Problem in Kombination mit Ubuntu wurde von dem Entwicklern mit der aktuellen Version behoben.
