Sept. 2023 - Die Chronik der Wiederbelebung der Museen-Seiten

Ausgangspunkt für weitere Probleme auf diesem Server war die Reparatur einer der "virtuellen maschinen" (VMs) - noch unter opensuse 12.3 mit unserem Museen-Webserver drauf und der angeschlossenen mysql Datenbank.

Das Passwort des root Benutzers klappte nicht mehr. Auch das Überkopieren der "/etc/shadow" Datei vom Host aus - mit allen root-Rechten des Hosts - direkt in das Verzeichnis der abgeschalteten VM - brachte keinen Erfolg. Übrig blieb die Installation eines 12.3 rescue Systems "über" diese Partition der "virtuellen maschine" (bei uns die Partition md8), um dort dann als root-user (des Hosts) mit "chroot" die Kontrolle über die abgeschaltete VM zu übernehmen. In dieser Konstellation funktioniert der System-Befehl "passwd" wie in der echten laufenden VM, um ein neues korrektes Passwort in die Datei "shadow" (auf der Platte) einzutragen,
.

Nachdem die 4 (bzw. 5) vorher gemounteten Verzeichnisse wieder gelöst waren (umount), hatte ich aber den Ausstieg aus dem "chroot"-Zustand versäumt- das wäre der "exit" Befehl gewesen und ctrl +d wa falsch und das war ein dicker Fehler.

Mit "reboot" startete die VM wie gewöhnlich und ich konnte über alle beide "Türen" wieder als root-user in diese VM rein und sie administrieren.

Am Sonntag Nacht um 3.oo hatte ich den Museen-Webserver so weit, daß alle Museenseiten wieder online waren.
.

Das Host-System hat offensichtlich eine Macke abbekommen : ich hatte nicht mitbekommen, daß inzwischen der Host (opensuse 42.3) erheblich beschädigt war. Und so lange wie der Host einfach nur läuft, läuft er eben. Das merkt man nicht so schnell.

Nachts um 3.00 !!!! - Die Museen-Seiten liefen wieder - das war schon ein Erfolg. Aber als typo3-Admin und Chefedakteur war mir dort der Zugang verwehrt, schon wieder Mist.
.

Am nächsten Morgen wollte ich über den Virt-Manager des Hosts den vordergründig wieder intakten Museen-Webserver nocheinmal runter fahren und unter der gleichen IP-Nummer diesen Reserve-Server hier starten, um den Rest an dem Web-Server zu reparieren.

Beim Einloggen auf dem Hostbereich, der DOM-0, als Hilfs-Benutzer traten schon die ersten komischen Fehler auf. Der "dir" Befehl wurde nicht mehr ausgeführt. Der "midnight commander" hingegen lief zum Glück. "YAST" startete auch nicht mehr. Da war also in der Nacht vorher unbekannter Weise etwas Schlimmns passiert. Was tun war die Frage ........
.

[Intel-i7-DOM0-root] $ dir
.

• ls: /lib64/libselinux.so.1: no version information available (required by ls)
• ls: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by ls)

.
[Intel-i7-DOM0-root] $

Doch auch das dürfte ja kein Problem sein, dann eben die "Library" "lib64/libc.so.6" mit "zypper" nachinstallieren. Doch das geht so nicht - unbekannt.

Also dann die "GLIBC_2.28" nachinstallieren, das geht aber auch nicht, ebenfalls "nicht gefunden".

Aha, dann eben im Internet suchen. Diese "lib" ist sehr selten, jedoch es gibt die 2.22 und die 2.31, aber keine 2.28. Dann eben die etwas höhrere "GLIBC" installieren, geht aber auch nicht, es ergibt tausende von Fehlern.

[Intel-i7-DOM0-root] /opt $ rpm -i --force -v -U -F ./glibc-2.31-150300.20.7.x86_64.rpm
warning: ./glibc-2.31-150300.20.7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 39db7c82: NOKEY
error: Failed dependencies:
glibc = 2.22 is needed by (installed) glibc-extra-2.22-25.1.x86_64
glibc = 2.22 is needed by (installed) glibc-locale-2.22-25.1.x86_64

.........hier kommen massenweise Fehler ......................

es sind fast 100 Zeilen, was alles verlangt wird und was nicht geht.

Die etwas niedrigere 2.22 geht aber auch nicht, die sei nämlich schon da. Nach mehreren Stunden kommen Sie sich wirklich verar.... vor. Das "dir" Programm und auch "YAST" wollen eine Library haben, die es gar nicht gibt, die man aber auch nicht installieren kann.

Ganz schnell sind 4 Stunden rum.
.

Jetzt weiß ich von unseren anderen Servern, daß bei einem Upgrade auf die nächst höhere opensuse Version (hier also von der 42.3 auf 15.0) fast immer auch solche sonderbaren Fehler repariert werden, dafür aber meist wieder andere Fehler auftauchen.

Und beim Upgrade einer Hostversion ist das für den ganzen Server samt der noch laufenden drei Gäste ein "volles Risko". Auf einem anderen Host-Server hatte dieses Upgrade aber bereits funktioniert. Es könnte also klappen.
.

Die vorhanden 42.3 Repos zur Sicherheit abfragen
zypper lr -d
#dann "deactivate other repositories"
zypper mr -adR
#"add new repos for upgrade" - alle vier 15.0 Repos eintragen bzw. anlegen

zypper ar -n "openSUSE-15.0 OSS" download.opensuse.org/distribution/leap/15.0/repo/oss/ repo-15.0-oss
zypper ar -n "openSUSE-15.0 Non-OSS" download.opensuse.org/distribution/leap/15.0/repo/non-oss/ repo-15.0-non-oss
zypper ar -f -n "openSUSE-15.0 Updates OSS" download.opensuse.org/update/leap/15.0/oss/ repo-15.0-update-oss
zypper ar -f -n "openSUSE-15.0 Updates Non-OSS" download.opensuse.org/update/leap/15.0/non-oss/ repo-15.0-up-non-oss

refresh zypper repository cache

Und so geht es weiter :

[Intel-i7-DOM0-root] /etc/zypp/repos.d $ zypper ref
Retrieving repository 'openSUSE-15.0 Non-OSS' metadata .............................[done]
Building repository 'openSUSE-15.0 Non-OSS' cache ......................................[done]
Retrieving repository 'openSUSE-15.0 OSS' metadata ......................................[done]
Building repository 'openSUSE-15.0 OSS' cache ................................................[done]
Retrieving repository 'openSUSE-15.0 Updates Non-OSS' metadata ..............[done]
Building repository 'openSUSE-15.0 Updates Non-OSS' cache .......................[done]
Retrieving repository 'openSUSE-15.0 Updates OSS' metadata .......................[done]
Building repository 'openSUSE-15.0 Updates OSS' cache ................................[done]
All repositories have been refreshed.
[Intel-i7-DOM0-root] /etc/zypp/repos.d $

#und dann
zypper clean -a && zypper dup

und jetzt gehts los, oft nur 40 Minuten, manchmal aber 3 Stunden - die Sever in Düsseldorf sind mit Gigabit mir dem Internet verbunden

[Intel-i7-DOM0-root] /etc/zypp/repos.d $ zypper clean -a && zypper dup

All repositories have been cleaned up.
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.

Building repository 'openSUSE-15.0 Non-OSS' cache ..............................[done]
Building repository 'openSUSE-15.0 OSS' cache ......................................[done]
Retrieving repository 'openSUSE-15.0 Updates Non-OSS' metadata ......[done]
Building repository 'openSUSE-15.0 Updates Non-OSS' cache ................[done]
Retrieving repository 'openSUSE-15.0 Updates OSS' metadata ..............[done]
Building repository 'openSUSE-15.0 Updates OSS' cache ........................[done]

Loading repository data...
Warning: Repository 'openSUSE-15.0 Updates Non-OSS' appears to be outdated. Consider using a different mirror or server.
Warning: Repository 'openSUSE-15.0 Updates OSS' appears to be outdated. Consider using a different mirror or server.

Reading installed packages...

Computing distribution upgrade...
The following 543 NEW packages are going to be installed:
................................... > hier kommt ganz viel Text
The following 3 NEW patterns are going to be installed:
basesystem x11_enhanced yast2_basis
The following 3 applications are going to be REMOVED:
"Archive Manager" "Virtual Machine Manager" gFTP
The following 150 packages are going to be REMOVED:
....................................... > hier kommt ganz viel Text

The following pattern is going to be REMOVED:
generic_server

The following 892 packages are going to be upgraded:
....................... > hier kommt ganz viel Text

The following 12 patterns are going to be upgraded:
apparmor apparmor_opt base console enhanced_base enhanced_base_opt kvm_server minimal_base sw_management x11 x11_opt x11_yast
The following 436 packages are going to be downgraded:
........................................ > hier kommt ganz viel Text

The following 2 patterns are going to be downgraded:
fonts fonts_opt

The following 2 products are going to be downgraded:
"openSUSE Leap 42.3" "openSUSE NonOSS Addon"

The following 6 packages are going to change architecture:
file-magic x86_64 -> noarch
openssl x86_64 -> noarch
perl-Net-DNS x86_64 -> noarch
perl-XML-NamespaceSupport x86_64 -> noarch
perl-XML-XPath x86_64 -> noarch
sharutils-lang x86_64 -> noarch

892 packages to upgrade, 436 to downgrade, 543 new, 150 to remove, 6 to change arch. - Overall download size: 937.5 MiB. Already cached: 0 B. After the operation, additional 1.2 GiB will be used.
.

...................................................... 1800 Files werden geladen

Retrieving: tracker-lang-2.0.3-lp150.4.6.1.noarch.rpm ................................................................[done]
Checking for file conflicts: ....................................................................................................................[error]

Detected 4 file conflicts:
File /usr/lib/python2.7/site-packages/six-1.11.0-py2.7.egg-info
from install of python2-six-1.11.0-lp150.2.3.noarch (openSUSE-15.0 OSS)
conflicts with file from package python-six-1.11.0-9.4.1.noarch (@System)
File /usr/lib/python2.7/site-packages/six.py
from install of python2-six-1.11.0-lp150.2.3.noarch (openSUSE-15.0 OSS)
conflicts with file from package python-six-1.11.0-9.4.1.noarch (@System)
File /usr/lib/python2.7/site-packages/six.pyc
from install of python2-six-1.11.0-lp150.2.3.noarch (openSUSE-15.0 OSS)
conflicts with file from package  python-six-1.11.0-9.4.1.noarch (@System)
File /usr/lib/python2.7/site-packages/six.pyo
from install of python2-six-1.11.0-lp150.2.3.noarch (openSUSE-15.0 OSS)
conflicts with file from package python-six-1.11.0-9.4.1.noarch (@System)

File conflicts happen when two packages attempt to install files with the same name but different contents. If you continue, conflicting files will be replaced losing the previous content.
Continue? [yes/no] (no): YES

Die folgende Logdatei, die am Bildschirm ausgegeben wird, ist mehrere Meter lang

............................................................ > hier kommt ganz viel Text .......................

dracut: *** Store current command line parameters ***
dracut: Stored kernel commandline:
dracut: rd.md.uuid=a63bff35:fc188397:926be376:997f95b1 rd.md.uuid=cbf69f7f:437993ef:01077aca:b528cdfb rd.md.uuid=146ffbf7:caa77278:6d3cb955:93026c10

dracut: resume=UUID=bb4a14dc-3eb3-4d45-a89d-1a2290f56281
racut: root=UUID=9b13270f-c288-471b-8731-27011dd978d0 rootfstype=ext4 rootflags=rw,relatime,data=ordered
dracut: *** Creating image file '/boot/initrd-4.4.180-102-default' ***
dracut: *** Creating initramfs image file '/boot/initrd-4.4.180-102-default' done ***
Output of systemd-presets-common-SUSE-15-lp150.1.1.noarch.rpm %posttrans script:
Created symlink /etc/systemd/system/multi-user.target.wants/apparmor.service -> /usr/lib/systemd/system/apparmor.service.
Created symlink /etc/systemd/system/multi-user.target.wants/cups.path -> /usr/lib/systemd/system/cups.path.
Created symlink /etc/systemd/system/printer.target.wants/cups.service -> /usr/lib/systemd/system/cups.service.
Created symlink /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.service -> /usr/lib/systemd/system/btrfsmaintenance-refresh.service.
Created symlink /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.path -> /usr/lib/systemd/system/btrfsmaintenance-refresh.path.
Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-monitor.service -> /usr/lib/systemd/system/lvm2-monitor.service.
Output of rpm-4.14.1-lp150.9.13.1.x86_64.rpm %posttrans script:
migrating rpmdb from /var/lib/rpm to /usr/lib/sysimage/rpm...
Output of dmraid-1.0.0.rc16-lp150.3.4.x86_64.rpm %posttrans script:
Updating /etc/sysconfig/dmraid ...
Output of grub2-i386-pc-2.02-lp150.13.26.1.x86_64.rpm %posttrans script:
update-bootloader: 2023-09-04 20:02:47 <3> update-bootloader-3515 run_command.294: '/usr/lib/bootloader/grub2/install' failed with exit code 1, output:
<<<<<<<<<<<<<<<<
target = i386-pc
+ /usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe /dev/sdb
i386-pc wird für Ihre Plattform installiert.
/usr/sbin/grub2-install: Fehler: Das Laufwerk hd0 wurde in der Gerätetabelle mehrfach /boot/grub2/device.map definiert.
+ /usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe /dev/sda
i386-pc wird für Ihre Plattform installiert.
/usr/sbin/grub2-install: Fehler: Das Laufwerk hd0 wurde in der Gerätetabelle mehrfach /boot/grub2/device.map definiert. (Dieser Fehler wurde von mir von Hand repariert)
>>>>>>>>>>>>>>>>
There are some running programs that might use files deleted by recent upgrade. You may wish to check and restart some of them. Run 'zypper ps -s' to list these programs.

Alles in allem waren das auch wieder 3 Stunden.
.

.

Der virtuelle Museen-Webserver, er ist ja auch nur ein Gast auf dem Host, der am Sonntag Nacht ab 3.oo Uhr noch alle unsere Museen- Seiten in voller Schönheit auf allen Menü-Ebenen ausgeliefert hatte, hatte jedoch auch noch ein (kleines ?) Problem - außer daß ich noch nicht ins typo3- Redaktions- Backend rein kam.

Über den Host (die DOM-0) kann ich mir die Konsole dieses virtuellen Servers holen, als wenn ich vor einem ganz normalen PC mit Tastatur und Maus sitzen würde. Doch das ging nicht mehr, das "Warum" war nicht zu ergründen.

Der Starvorgang auf dem Consolen-Fenster dieses Gastes mit den ganzen Boot-Informationen verschwand irgendwann im schwarzen Nichts und der sogenannte Login-Promt war einfach (noch) nicht da.

Über die SSH-Textkonsole von putty funktionierte das aber ganz normal, auch als root-User. Das bedeutet, der Startvorgang ist irgendwo nicht in Ordnung und wenn dann der SSH Zugang "klemmt" (klemmen würde), käme ich gar nicht mehr rein. Das ist ja mit ein Sinn für diese ganze Virtualisierung, daß ich über den Virtmanager immer in jeden Gast rein komme.

Das kann so nicht beiben. Was tun ? Nach mehreren Stunden an Reparaturversuchen mit Abschalten aller Grafik-Module blieb auch hier nur eine (von zwei), aber riskante Alternative übrig, ein online Upgrade von opensuse 12.3 auf 13.1. Es bleibt ja immer noch als letzte Reserve die Rücksicherung meines lokalen 12.3 Test- Servers hier aus Wiesbaden und das Nachtragen aller Änderungen samt Reparatur des 12.3 Bootloaders.

Und das fange ich jetzt an. - Es klapt aber nicht. Eine neue "virtuelle machine" mit opensuse 12.3 oder 13.1 oder 13.2  bleibt beim Starten der Installation einfach im "Nichts" (da gabs mal im Kino die unendliche Geschichte) hängen. Also so geht es schon mal nicht.
.

.

Bleibt als letzte Rettung nur das Überkopieren fast des gesamten "root"- Bereiches (ausgehend von einer funktionierenden lokalen Root-Partition) von meinem lokalen opensuse 12.3 Test-Server auf den Düsseldorfer Gast (mit Hilfe des erstellten Zip-Files).

Also auf keinen Fall ein online Upgrade von 12.3 auf eine 13.1 oder 13.2 probieren, das klappt nämlich nicht mehr. (Nachtrag - da war mein damals aktueller Wissensstand - also daß es nicht funktioniert)

Und unerwartet war auf einmal "das Netzwerk" (besser die Netzwerk- Verbindung) des Host- Betriebssystems inaktiv.  Damit sind auch alle VMs weg - aus dem Internet verschwunden.

Jetzt muß ich nachdenken, was noch alles pasierte. Es war ein ganz merkwürdiger Lawinen-Effekt.
.

Zu den selten bemerkten Macken bei den verschiedenen Revisionen der Linux Systeme kommt natürlich auch meine angespannte eigene Verfassung hinzu, - es sind ja schon mehrere Wochen rum - sodaß sich auch kleine Flüchtigkeitsfehler sofort rächen. Vor allem müssen Sicherungsdateien doch ab und zu mal ausprobiert werden und das kostet mehr Zeit als geplant.

Beim Sichern und Rücksichern von virtualisierten Servern und deren Gästen ist es schon wichtig, ob diese Virtualisierung ehemals (1) auf der Hardware- Basis (KVM) oder (2) auf der Software-Basis (Xen) lief.

Eine Sicherung eines VM-Gastes - also der gesamten Gast-Partition von bis zu 40 gepackten GB bringt dann nichts, wenn die zugehörige XML-Start-Datei auf dem Host nicht mitgesichert wird (wurde).

In dieser auf dem Host wohnenden "(Name des virtuellen Gastes).xml"- Datei steht sehr genau, in welcher Umgebung dieser Gast vormals gelaufen war und nur in solch einer Umgebung bekommt man den auch wieder zum Laufen.

Es ist ein sehr komplexes verkettetes System, bei dem man immer wieder (unerwartet) auf die Nase fallen kann. Die Lernkurve ist enorm steil.
.

.

.