4.9.2023 - Die Chronik der Wiederbelebung der Museen-Seiten

.

Der (Trans-) Port des rudimentär laufenden Apache Webservers (bei mir auf dem lokalen Test-Server im EDV-Labor) ist nur "die halbe Miete". Es sind nämlich mehr als 5 Domains, die der Webserver bedienen und ausliefern muß.

Dazu ist umfangreiches Wissen über die DNS Technik (Namensauflösung in IP-Nummern) und die sogenannte vhost-Konfiguration eines Web-Servers erforderlich. Also einfach mal einschalten geht so nicht.
.

Wird ein Apache2 Webserver mit mehr als einer Domain (einem Host) betrieben - das sind dann die sogenannten virtuellen Hosts - und konfiguriert, sind für jede einzelne Domain gespeicherte vhost Konfigurations-Dateien (.conf) erforderlich.

Dort steht (unter anderem) drinnen, wie die Domain heißt und in welchem Arbeitsverzeichnis die domainspezifschen Daten (die Konfiguration und die Bilder) dieser Domain auf dem Server zu finden sind. Es spielt dabei keine Rolle, daß die Daten-Inhalte der Text-Seiten am Ende aus einer einzigen gemeinsamen mysql Datenbank kommen. Die vielen Bilder "eines Museums" sind in den jeeiligen vhost Verzeichnissen abgelegt

Beim Start des Apache Webservers prüft die Apache Start-Routine, ob die DNS- Namens- Referenzen auf diesen in den vhost.conf Dateien kofigurierten Domains auch alle online abrufbar sind (und funktionieren). Findet die Prüfung eine von diesen DNS-Refrenzen nicht, startet der Apache-Server ganz einfach nicht (und meldet diese(n) speziellen Fehler).

Bild ....

Bei der bislang laufenden online Version unseres Apache Servers in Düsseldorf fragt die Startroutine unsere im Internet online laufenden DNS- Name-Server ab, in denen diese Domains eingetragen und refrenziert sind und für Jedermann nach draußen publiziert werden. Dort in den DNS- Einträgen hinterlegt steht die richtige IP-Nummer unseres Servers mit dem Apache-Server in Düsseldorf und somit klappt das.

Weiterhin gehört zum Grundwissen der verknüpften Museen-Seiten, daß in den Seiten (etwa 45.000) und den Artikeln (etwas über 70.000) - den sogenannten Content-Elementen - die Verlinkungen der Informationen der einzelnen Museen (und damit der Domains) untereinander (es sind weit über 20.000 Links) im Klartext auf die entsprecheden Domain-Namen verweisen, die somit erreichbar sein müssen !!. Und all das geht auf dem lokalen Testserver natürlich nicht.
.

(auf meinem Test-Server) hier in Wiesbaden muß daher an eine lokale IP-Nummer (anstelle des Domain-Namens) angepaßt werden, sonst geht gar nichts - und damit ist der lokale Test nur bedingt praxis-tauglich.

Hier bei mir wird also nur eine einzige Domain - eine "namenslose" Domain - über die IP-Nummer des Servers eingerichtet. Und nur damit kann ich die grundlegende Funktion des benötigten opensuse Betriebssystems Version 12.3 und die des Apache Webservers und der Verbindung zur mysql Datenbank zum Laufen bringen und überhaupt erstmal prüfen, ob das alles harmoniert.

Das habe ich stellvertretend nur mit den IPW- Software- Seiten gemacht. Ich kann also auf diesem lokalen Server die gesamten IPW-Seiten samt der Unterseiten aufrufen und anschaun und alles sieht gut aus. Leider nur Radio Eriwan - es funktioniert - so scheint es.

Es gibt 2 verbreitete Varianten der Virtualisierung von Servern, die eine auf Software basierende Technik mit "Xen" und die andere auf der Prozessor-Hardware basierende Technik unter der Bezeichnung "KVM". Und dort gibt es auch wiederum 2 Varianten, die "voll virtualisierte" Lösung und die "paravirtualisierte" Lösung.

Bei der voll virtualisierten Variante (bei uns) soll man angeblich ein auf einem ganz normalen PC gestartetes Betriebssystem unverändert laufen lassen können. Der Virt-Manager gaukelt jeder dieser "virtuellen maschinen" die gleiche Hardware des PCs vor. - So die hehre Theorie.

Jetzt zur Vorbereitung des Transfers:
Theoretisch verpacke ich das Root-File-System meiner lokalen Test-Installation offline in einen speziellen ZIP-File, lade den auf den Host nach Düsseldorf und packe den in solch einer bereits vorbereiteten virtuellen Maschine wieder aus.

Die 2,8 GB (das root-Filesystem) hier bei mir lokal sind gezippt nur 1,2 GB groß und die sind in Düsseldorf gut angekommen. Die dortige vorbereitete VM hatte bereits vorher ein geprüftes boot-fähiges Betriebssystem und das wurde nur einfach überschrieben. Bis auf den Daten-Transfer mit allen Protokollen und Rechten, die nicht gestimmt hatten, war das bislang einfach.
.

Ein beliebiger Server im öffentlichen Bereich muß unbedingt "dicht" sein. Die Chinesen und die Russen und andere Gauner und Ganoven aus Fernost oder sonstwo "baggern" ununterbrochen auf allen IP Nummern weltweit herum, um Einfallstore bzw. Lücken zu finden. Damit ich verschont bleibe, ist schon mal der wichtige sogenannte "root"-Zugang (der alles könnende Administrator) abgeschaltet. Der ist einfach nicht da.

Ein Dienst eines Server kann über die IP Nummer und zusätzlich ganz spezielle Portnummern gezielt angesprochen werden, und derer gibt es bis zu 64.000.

Die diversen Dienste und Zugänge eines Servers bedingen spezielle weltweit vereinbarte Standard-Ports. Aber auch die sind bei mir alle auf völlig andere (noch) unbekannte Port-Nummern verlegt. Damit ist das "Baggern" erheblich erschwert und zeitlich unattraktiv. Alleine die beiden (unveränderbar festgelegten) Web-Server Ports - also Port 80 (http) und 443 (https) sind nach draußen offen. Damit erschwert sich natürlich auch für mich als Admin ein Datentransfer erheblich.

Weiterhin kann ich nur von hier (lokal) aus irgendwelche Files auf die Server dort draußen laden, umgekehrt ist mein Netzwerk gesperrt. Alle Versuche mit dem "Midnight-Commander", dem "Filezilla" und dem "ftp-Client" und dessen Ersatz scheiterten an der Auswahl des Protokolls (SCP bzw. ssh2) und auch anderer Macken.

Alleine das uralte "gftp" Programm (aus 1998), ein ganz einfacher simpler grafischer FTP-Client aus dem Jahr 1998 löste das Problen souverän. Nachtrag : Das aktuelle WINSCP-Programm ab version 6.1 kann es "endlich" und sogar sehr komfortabel (und sogar ab WIN XP/32). Hat das lange gedauert .......
.

Jeder Gast bzw. jede "VM" bekommt bei uns immer ihre ganz eigene Raw-Partition (z.B. 100 GB) nur für sich alleine. Innerhalb dieser RAW-Partition werden bei der Installation von opensuse drei neue und jetzt formatierte Sub-Partitionen angelegt - als Beispiel etwa so : swap (2GB), root (30GB) und data (70GB).

In der root-Subpartition sollte es keine weiteren Daten geben, alleine die Server- Konfiguration und die Passwörter sind dort (in /etc/) dabei. Alle unsere typo3- CMS-Daten wohnen in der "data"-Partition. Das hat sich unglaublich gut bewährt, denn alle unsere Museen-Daten bis zur letzten Sekunde sind unangetastet vorhanden (und jetzt mehrfach gesichert).
.

Doch alle Theorie in Ehren, diese vom lokalen Test-Server transferierte (auf opensuse 12.3 basierende) VM startet gleich am Anfang mit einem "grub2" Boot-Error. Was nun ? Das dürfte doch gar nicht vorkommen.

Die Crux beginnt mit den sogenannten UUIDs (das sind ganz spezielle absolut einmalige 32-stellige Ziffern und Zahlen-Ketten) und das macht das ganze richtig komplex. In den Start-Konfigurationen - den Dateien "/etc/fstab" und "/boot/grub2.conf" - stehen diese UUIDs für die (einzelnen) Platten- Partitonen eines Servers, für die Gesamt-Patition und für den Server selbst und vieles andere mehr.

Und diese neuen Düsseldorfer UUIDs stimmen natürlich mit denen meines lokalen Wiesbadener Test-Servers überhaupt nicht mehr überein. (Diese UUIDs kann man natürlich mit dem herauzufindenen Device-Namen - z.B. "/dev/sda3" ersetzen und dann ist zumindest diese Hürde vom Tisch. Aber es ist mühsam.)

Zum Glück hatte ich diese Original-Dateien fast alle aus der damals noch laufenden VM gesichert (an den Partitionen auf der "data-" Platte und damit an den UUIDs hatte sich ja nichts geändert), denoch wollte die VM nicht starten.

Ein Tip aus dem Internet : Wenn also der Linux grub2-loader nicht startet, sollte man den Loader vom grub2-Installer reparieren lassen. Das ist "klug geschwätzt", wenn der Server gar nicht mehr startet.

Und jetzt ist bei den VMs auf den dedicatetd root-servern sowieso alles ganz anders. Erstens steht der Server in Düsseldorf und zweitens ist der Netzwerkschrank dort nicht zugänglich. Also der 100fache Tip, starten Sie den Server mit einer Rescue-DVD oder von einem Rescue-Stick ist bei den Profis im Datacenter "daneben". - Es geht bei uns zwar auch - aber eben ganz anders, und ist aber auch wieder deutlich komplexer :
.

Eine virtuelle Maschine (VM) im rescue Modus bearbeiten / reparieren

Auch hier gibt es bezüglich des rescue-Modus ganz viele Tips und Anleitungen aus den letzten 20 Jahren, die aber meist nicht zutreffen oder veraltet sind oder sonst wie NICHT funktionieren.

Erstmal muß der rescue-Modus überhaupt mal gestartet werden können. Weiterhin soll oder muß das die gleiche Betriebssystem-Revision sein - wie auf dem defekten Server vormals installiert. Und dann ist volle Aufmerksamkeit angebracht, denn jetzt wird es ernst. Obwohl diese VM runtergefahren ist (abgeschaltet ist), wird am lebenden Patienten operiert. Die anderen VMs können und müssten weiter laufen können.

Ich hatte mir die opensuse "12.3 X86/64 ISO DVD" auf den Host geholt und dann über den Virtualisierungmanager das Programm zur Neu-Anlage / Neu-Installation einer neuen VM gestartet. Bevor dieser Manager die 4,7GB ISO Datei entpackt und ausführt, muß man das Installations-Ziel - die RAW-Partition - auf dem Server suchen und festlegen und dort ist ja das defekte aber kostbare transferierte boot-System schon drinnen.

Hochkonzentriert muß man jetzt bei erstem Erscheinen des opensuse Initial-screens die Sprache und die screen-Resolution bestimmen und dann aber sofort den rescue Modus auswählen, sonst gibts Bruch.

In diesem rescue-Modus loggt man sich als root-user ohne Passwort ein. Wer (pseudo-) physikalischen Zugriff auf die Hardware hat, ist auch der legitime "Superadministrator", der "root-user" - sagt man.

Doch jetzt ist nur erstmal eine externe opensuse 12.3 in dieser VM gestart, die komplett im RAM (32 Giga) wohnt und die die Platten und Partitionen der VM zwar sieht, aber (noch) nicht bearbeiten kann.
.

Die allgemein bekannte Linux-Verzeichnisstruktur dieser rescue Installation sieht (fast) genauso aus wie auf einer von der Platte gestarteten opensuse Version, ist also täuschend ähnlich. Aber diese opensuse ist überhaupt erstmal in dieser VM gestartet und betriebsbereit.

Um die boot-Konfiguration auf der Festplatte reprieren zu können, muß ich dem rescue- System ganz bestimmte Verzeichnisse auf der Fetsplatte "unterjubeln", quasi überlagern.

Daran bin ich fast gescheitert. Die vielen Vorschläge und zum Teil auch Protokolle hatten alle nicht funktioniert. Erst eine mühsam aus mehreren Texten zusammengesetzte Kombination aus mehreren Foren brachte das typische AHA-Erlebnis. Am Ende war es wieder mal "so" simpel und einfach, daß ........... na ja.

Und darum beschreibe ich das hier etwas ausführlicher - es sowieso nur etwas für XEN-Profis : Der rote Promt in der rescue-Kommandzeile erwartet typische Linux Befehle.

Der Aufruf von "lsblk" zeigt mir Informationen an, die einen nur verwirren. Erst der Aufruf von "fdisk -l" zeigt die aktuellen Sub-Partitionen dieser VM an. Bilder kommen noch.

Nur mal ein Beispiel eines Servers - das ist nur ein kleiner Teil der Host-Abfrage :

Device         Boot                Start            End Sectors                     Size                   Id Type
/dev/sda1 * 2048               16787455        16785408                          8G fd Linux raid autodetect
/dev/sda2   16787456     18892799        2105344                             1G fd Linux raid autodetect
/dev/sda3   18892800      80332799        61440000                         29.3G fd Linux raid autodetect
/dev/sda4    80332800    1953523711   1873190912                    893.2G f W95 Ext'd (LBA)
/dev/sda5    80334848     122269695     41934848                         20G fd Linux raid autodetect
/dev/sda6    122271744   290037759    167766016                       80G fd Linux raid autodetect
/dev/sda7    290039808   457803775    167763968                       80G fd Linux raid autodetect
/dev/sda8    457805824   541695999      83890176                        40G fd Linux raid autodetect
/dev/sda9    541698048   625586175      83888128                       40G fd Linux raid autodetect
/dev/sda10  625588224   793354239    167766016                     80G fd Linux raid autodetect
/dev/sda11  793356288   1003081727  209725440                  100G fd Linux raid autodetect
/dev/sda12  1003083776 1254739967  251656192                  120G fd Linux raid autodetect
/dev/sda13  1254742016 1487521791  232779776                  111G fd Linux raid autodetect
/dev/sda14  1487523840 1953523711  465999872                  222.2G fd Linux raid autodetect
.

Unsere jetzt über 6 Jahre (sei 2016) gelaufene VM mit der Museen-Datenbank "wohnt" zum Beispiel in der RAID-1 Partition "md8". - Diese RAID-1 Partiton "ist die aufgesetzte verbindende Brücke" auf den beiden symmetrisch gespiegelten Platten "/dev/sda10" und "/dev/sdb10".

Von Außen (vom Host aus gesehen) sieht diese RAW-Partition so aus :
Disk /dev/md8: 80 GiB, 85896069120 bytes, 167765760 sectors

Innen drinnen hat sie die 3 für das Betriebssystem wichtigen Unterpartitionen
Device              Boot            Start              End Sectors      Size      Id Type
/dev/md8p1    2048           8386559 8       384512            4G 82   Linux swap / Solaris
/dev/md8p2 *  8386560    39841791       31455232      15G 83 Linux / ext4
/dev/md8p3    39841792  167763967    127922176     61G 83 Linux / ext4

Ist das Betriebssystem der VM erst einmal gestartet, sehe ich innerhalb der VM nur noch diese 3 Partitions-Bezeichnungen: vda1, vda2 und vda3.

Von außen sind es ja /dev/md8p1, /dev/md8p2 und /dev/md8p3.

.

Die wichtige "root"-Partition unserer VM (/dev/md8p2) müssen wir uns in unser rescue-System "mappen" bzw. "mounten".

Zuerst mounten wir die ganze "root"-Sub-Partition "vda2" auf ein immer vorhandenes Verzeichnis /mnt/, dann mounten wir dort hinein die einzelnen Verzeichnisse, die wir brauchen.

mount /dev/vda2 /mnt  - und das nimmt das System ohne Fehler an

Wir sind noch im Verzeichnis /root im RAM und mit "cd .." kommen wir eine Ebene tiefer nach /. Dort mit "cd /mnt" kommen wir in das gemountete root-Verzeichnis auf der Platte - und jetzt tippen wir :

mount -o bind /dev /mnt/dev
mount -o bind /run /mnt/run
mount -o bind /sys /mnt/sys
mount -o bind /proc /mnt/proc  -  alle 4 sind ohne Fehler ok

chroot /mnt ---- auch das funktioniert

Nach diesem Befehl "chroot" arbeite ich "quasi" mit dem neuen rescue-Betriebssystem auf der lokalen abgeschotteten Festplatte dieser VM, die ja nicht booten wollte - aber jetzt doch gestartet wurde. Das war also der Trick.
.

Und jetzt starte ich zwei "Reparatur"- Programme für den üblichen Startvorgang :

mkinitrd  ---- nimmt er und führt es (mit viel Text) ohne Fehler aus

Das Install-Programm zum Konfigurieren des Boot-Loaders muß auf die gesamte Partition verweisen, also nicht mehr nur auf eine Sub-Partition .

grub2-install /dev/vda    ------------  und nicht etwa "/vda2" oder so - das gibt Fehler aus

Einen Teil der obigen Befehle könnte man in einen Shell-Script eintragen, damit sie nicht zu oft eintippen muß.
.

Ist grub2-install durchgelaufen, muß ich diesen gemappten Bereich mit "exit" verlassen und bin wieder auf meinem originalen rescue Betriebssystem gelandet. Und dort funktioniert der "reboot" Befehl.

Das wars also und die VM startet wieder - im VNC Fenster des Hosts als virtuelle Maschine - aber leider diesmal mit wieder anderen Macken.
.

Diese opensuse Version 12.3 hatte ich auf dem lokalen Test-Server bereits so vor-konfiguriert, daß der "quiet"- und der "silent"-boot-Mode abgeschaltet waren.

So kann ich in dem VNC-Fenster des Hosts genau Start-Zeile für Start-Zeile mitverfolgen, wie das System runter fährt und wie es wieder startet, fast wie wenn ich vor dem realen Bildschirm in Düsseldorf sitzen würde (oder könnte).
.

Der im Fenster der VM mitverfolgte anlaufende opensuse 12.3 Starvorgang hört plötzlich auf, es wird nichts mehr angezeigt. Was ist das ?

Zur Kontrolle lasse ich auf einem meiner Bildschirme in einem DOS-Fenster immer ein "ping" auf die IP-Nummer der überwachten VM mitlaufen. (zum Beispiel ping 213.202.xxx.yyy -n 20000) - Dann weiß ich, ob und wann der Server wieder reagiert.

Also das VNC-Fenster war dunkel und die Server-IP erschien dennoch ??? Der für mich als Admin wichtige boot-Vorgang war damit (unsichtbar und vermutlich doch) bis zum Ende durchgelaufen. Das ist alles sehr merkwürdig und vor allem nicht kontrollierbar.

Im jeweiligen VM-Fenster des Virtual-Managers im Host kann ich mit einem Klick für jede VM ein "reboot" oder ein "shutdown" erzwingen. Beim "reboot" sehe ich plötzlich, wie auf der VM die einzelnen Dienste gestoppt werden und der Bootvorgang ist auch wieder bis zum schwarzen Fenster mitzuverfolgen. Der Boot-Vorgang der VM war demnach eigentlich erfolgreich, nur eben nicht mehr sichtbar.

Also da ist der Wurm, die Grafik-Auflösung der grafischen Oberfläche dieser VM ist vermutlich zu hoch und überfordert die "virtuelle maschine", der Server bootet damit ganz normal - aber im Hintergrund.

Der SSH-Server in der VM ist auch hochgefahren und ich kann über mein Windows- Konsolen- Programm "putty" auf die jetzt neue IP-Nummer (des ehemaligen Test-Servers) zugreifen und mich mit meinem Hilfs-User anmelden. Der direkte root- Zugang ist sowieso immer abgeschaltet.

Doch die Umschaltung auf den "su" (den Superuser) geht nicht, mein Kennwort "sei" falsch. Das war jetzt ganz neu, das hatte ich noch nicht. Alle user und die Passwörter stehen bei opensuse ziemlich sicher in der /etc/shadow Datei, aber als kryptische Schlüssel. Also das muß nachgebessert werden.
.

Der Apache Webserver war auf dem Test-Server (mit a2nmode) als autostart eingetragen und die mysql Engine auch - und beide waren jetzt bereits aktiv. Leider stimmt aber irgendetwas mit der Apache Rechte-Konfiguration nicht, auch beim Hifimuseum.de kommen die IPW.de - Seiten, beim Fernsehmuseum.de kommen die auch. Es sind also noch ein paar (vermeintlich kleine) Fehler zu beseitigen, ehe der Apache Server auf dem alten Stand wieder online geht.

... denn als Admin komme ich in den Web-Server nicht mehr rein. Soetwas hatte ich in den letzten 30 Jahren nicht.

Inzwischen hatte sich nämlich der virtuelle Web-Server strikt geweigert, mein Administrator- Passwort anzunehmen. Mit dem Hilfsuser konnte ich zwar auf den Server drauf bzw. rein - hatte aber keinerlei Rechte, irgend etwas zu administrieren. Ich habe ja zwei "Eingänge / Türen" zu einem solchen virtuellen Server, die virtuelle Tastatur (des Gerätes - die hole ich mir über den grafischen VNC-Sever des Hosts und dem dortigen VM-Fenster) und die Text-Konsole, die ich mir direkt aus Windows heraus über das SSH-Programm "putty" hole.

Als normaler (Hilfs-) User hat das Login auf beiden "Türen" funktioniert, aber als admin hatte es auf beiden "Türen" nicht funktioniert. Damit war also weder der VNC-Server (des Hosts) noch der SSH-Server an der Abweisung Schuld. Es muß an der Verschlüsselung der Passwort-Abfage liegen. Doch ohne Admin-Rechte kann ich logischer Weise das Admin Passwort nicht ändern - wie die Katze, die sich in den Schwanz beißt.
.

Für jedes Linux- und Server- Problem gibt es eine Lösung. Und google zeigt hunderte von Lösungen an. Deshalb ist die Lösung an sich trivial, wenn man sie aus den hunderten von Vorschlägen endlich extrahiert hat. Schmerzlich dabei war nur, daß ich zwei Nächte lang unbrauchbare Methoden und bei mir nicht funktionierende Lösungen ausprobiert hatte, bis man durch Zufall auf die einfache Variante stößt. Das steht weiter oben beschrieben.
.

Hier eigentlich nochmal von vorne .... Mit dem VM-Installer und dann dem opensuse 12.3 Rescue Modus kann ich mir für eine neue VM ein (externes) Betriebssystem im RAM starten, das ich mit den Platten- Partitionen meines Reparatur Delinquenten verknüpfe.

Ich kann also einem nicht mehr bootenden oder sonst defekten Betriebs-System eine fremde (ähnliche) Glocke überstülpen, mir ein paar wesenliche Verzeichnisse "krallen" und schon bin ich der Herr (der Admin) über diese virtuelle Maschine. (das htten wir aber schon weiter oben)

So habe ich also nochmal eine opensuse version 12.3 aus einer ISO Datei heraus als vorläufig neu anzulegende VM mit einem dummy-Namen gestartet und mir die root Platte meiner vorhandenen (streikenden) VM sowei 4 System-Verzeichnisse "gemounted". Danach habe ich mir mit "chroot" die Admin-Rechte auf dieser root-Platte geholt.

Jetzt kann ich als Admin eine System- Administration durchführen (es geht nicht alles) und zum Beispiel den Bootloader neu zusammenbauen lassen, weil dieser "grub-Installer" sich alle "Brocken" von der root Platte holt und den fertigen Loader auch wieder auf diese root-Platte (bei mir ist es auch die Boot-Platte) schreibt.

Auch der system-Befehl "passwd", der das neue root-Passwort (das war ja mein Problem) in die "shadow"- Datei einträgt, wird genauso ausgeführt, als wenn es im funktionierendem System geschähe. Doch die Sache hat einen bösartigen Hinkefuß, den man beachten muß, wenn man ihn denn kennt ud aufpaßt. Ich hatte da einen Fehler gemacht.
.

Mein Host-Betriebssystem opensuse XEN 42.3 fing auf einmal an zu spinnen (ich solle die chroot-Umgebung verlassen) und wollte mir auf einmal Module aus dem VM-Betriebssystem 12.3 unterjubeln. Dann gingen plötzlich mehrere Pflege- Programme nicht mehr und am Schluß ging nicht mal mehr der "dir"-Befehl.

Auch "YAST" lief nicht mehr und das Programm ist essentiell wichtig. Wie gesagt, stürzt der Host-Server ab, sind (später) auch alle Gast-Server tot.

Damit war der Montag - der 4.9.2023 - komplett im Eimer. Um die Host-Umgebung, die jetzt 3 Jahre problemlos gelaufen war, zu reparieren, war ein Neustart fällig. Das wars dann. Der Host-Server mit dem merkwürdigen Mix aus opensue 12.3 und 42.3 startete nicht mehr.

Es ist mir nach wie vor schleierhaft, wie soetwas in einer virtualisierten Umgebung passieren kann. - Als Ausweg kam dann nur noch ein Host- System- Upgrade auf opensuse 15.0 in Frage, das auf dem anderen Server bereits ausprobiert war und funktioniert hatte.
.

.