Die aktuellen Texte stehen immer unten am Ende .....

Hier fange ich nun doch an, alles mal aufzuschreiben, was da so im "Museum" - also in der Redaktion der virtuellen Museen - passiert ist. Nach 4 oder mehr Wochen geht sonst eine Menge verloren.

Inzwischen hat der neue der beiden root-Server von webtropia in Düsseldorf (ein Ryzen 5) den Geist vollends aufgegeben (zum 2. Mal) und die Neuinstallation stockt. Mal sehen, wie lange der dortige Support/Service benötigt, bis die "Kiste" wieder läuft. Vorgestern wurde eine der beiden 1 TB (RAID1) Platten getauscht, weil der Server nicht mehr startete. Warum der Server im "Nichts" verschwand und nicht mehr "hoch" kam, kann ich von hier aus ohne Hilfen - (z.B. eine KVM Tastatur) nicht erkennen. Jetzt ist die "Kiste" schon wieder hinüber und es geht von vorne los.

Inzwischen ist dieser neue leistungstärkere Ryzen Server gänzlich abgestürzt und der Support läßt mich über (zu viele) Stunden im Ungewissen, wann der wieder im Netz mit seiner IP-Nummer auftaucht. Also so richtig professionell ist das nicht.

Und auch unser Kabel-Provider Vodafone hat sich diese Nacht nicht mit Ruhm bekleckert und es waren mehrere Viertelstunden, da ging überhaupt nichts mehr. Und das geht schon seit Weihnachten 2022 so. Und sie bekommen es einfach nicht gebacken. (Nachtrag : Im August 2023 ging es dann wieder ohne Probleme. .... Das waren aber 6 lange Monate, in denen "sie" bei Vodafone an ihren Routern "gebastelt" hatten.)

Jetzt läuft er wieder, mit EFI und secure boot und sonstigen boot-Feinheiten, aber leider in einer 2 Terabyte RAID1 Plattenkonfiguration (es sind 2 neue 2TB Platten und auch die 32 GB RAM vom Webtropia Support in Düsseldorf ausgetauscht worden), also einer 1,8 TB root Partition, die einfach nicht brauchbar ist. Es hat sich über Jahre herausgestellt, daß jede virtuelle Maschine eine eigene RAW-Partition bekommen muß, damit es keine gegenseitigen Beeinflussungen gibt, wenn es mal kracht - und ab und zu kracht es. Jetzt muß diese Partition verkleinert werden und dann gehts weiter.

Heute Morgen (Samstag) wurde die Ryzen Server-Hardware in Düseldorf komplett getauscht, da der Server zu oft gemuckt hatte. Mal sehen, ob damit die Probleme aufhören.

Mit dem Ryzen 5 Sever (inzwischen leidlich stabil) und aktueller opensuse 15.5 habe ich das Handtuch geworfen. Ohne ganz spezielle Hilfe von Suse Fachleuten (was immer sie da am efi-boot-loader geändert haben) ist viel zu viel Zeit drauf gegangen. Und ich mache das seit 1995 - angefangen mit Suse 5.0.

Webtropia bietet "für Profis" nur eine überalterte opensuse 15.2 Installation aus vergangenen Zeiten an. (Nachtrag : Daß es mit den Folge-Versionen opensuse 15.4 und 15.5 einige unerwartete Problem ab, wußte ich zu dem Zeitpunkt noch nicht.)

Ein versuchtes stufenweises "upgrade" ist auch hier schief gegangen. Eines ist auf jeden Fall sicher, sollte einer der Linux Anbieter ein YAST ähnliches Verwaltungs- Werkzeug auf die Beine stellen, ist Suse ein für alle mal out und tot.

Jedesmal ging beim Upgrade etwas schief und es dauerte Tage (und viele Nächte), das zu verstehen und zu reparieren. Und das freie Programm "webmin" ist keine Alternative, da hakt es auch überall. Ein letzter Hoffnungslauf, habe soeben einen weiteren Intel i5 dedicated root Server für 45.- Euro / Monat beauftragt. Also mal sehen.

Der neue Intel i5 6-Kern Server ist nach bereits 2 Stunden am Netz - aber noch nicht voll in Aktion. Das Basis System - die DOM-0 - ist nach vielen Wirrungen (das sind die Upgrades) bei der opensuse Version 15.5 angekommen und funktioniert. Auch die erste virtuelle Maschine, also der erste viruelle Server - ist installiert und braucht noch eine IP Nummer. So langsam geht es voran - sehr langsam. Ich muß auf den Support warten.

Auch da geht's nur langsam voran. Der Museen-Websever gibt den ersten "Ton" von sich, doch die Museen-Datenbank hält sich noch versteckt.

Langsam kristallisiert sich heraus, warum das alles solange dauert. Die vorhandenen Datensicherungen sind alle unter Linux in einem "tar.gz"-Format erzeugt worden und wenn diese gepackten Dateien mit Filetransfer-Tools vom Düsseldorfer Server (im "ascii-Modus") auf unsere NAS-Server hier in Wiesbaden transferiert werden, (und man nicht aufpasst !!! - es müsste "binary-Modus" eingestellt sein) gehen sie kaputt.

Das fällt so lange nicht auf, wie wir diese Backup-Daten auf dem dem Linux Server prüfen und auspacken und rücksichern und uns freuen, daß es ja funktioniert hatte. Doch die gespeicherten Dateien hier bei uns unter Windows mal auszupacken, das kam bislang nicht vor. - Ein selbst verschuldeter dicker Fehler. Zum Glück sind einige lesbare wichtige Fragmente der Server separat gesichert worden. Es geht weiter.

Nachdem jetzt die beiden (DNS-) Name-Server neu aufgesetzt sind, (Achtung : jetzt sogar mit eigenem https-Zertifikat) https://213.202.211.174 und https://89.163.241.3/ ist unser Mailserver an der Reihe und dann kommt der Webserver dran. So zwischendurch kommt ein Gesundheits-Gau dazu, eine kleine Lebensmittelvergiftung, die mich 4 Tage ausser Gefecht gesetzt hatte.

Und noch ein Problem"chen" : Auf fast allen vorhandenen Sicherungen im xxxx.tar.gz Format sind die sogenannten symbolischen Links mit den originalen Dateien ersetzt worden (ein ziemlich blöder Fehler) und so kommen riesige Datenmengen bei den Übertragungen zustande, die überhaupt nicht mit der Realität übereinstimmen.

Der Mailserver läuft auch wieder - aber der Museen-Webserver sträubt sich mit allen "Tricks" gegen seine Wiederbelebung. Das hat mit den Optionen der verschiedenen Archiv- Programme zu tun, die mit unendlich vielen Funktionen sogar über 40 Jahre erfahrene Admins ins Schwitzen bringen. Jetzt soll der zukünftige Server erstmal auf einer lokalen Workstation hier bei uns in Wiesbaden zum Laufen kommen.

Die Assoziationen (nur die Abläufe !) mit dem GAU in Tschernobyl häufen sich, wenn auch bei uns zum Glück mit völlig unproblematischen Auswirkungen. Dort war bei einem periodischen Notstrom-Test für die Reaktorkühlung (das Aggregat zur Stromerzeugung wurde gezielt abgeschaltet) das 1. Reserve- Notstrom- Aggregat (auch ein Dieselmotor) nicht mehr angesprungen, dann das 2. Aggregat auch nicht - und - völlig unerwartet - das Haupt-Strom- Aggregat auf einmal "auch" nicht mehr !!!. Dann hatten "Sie" dort richtigen irreparablen Stress - bis damals zur tödlichen Kernschmelze. Wir machen einfach mal nur eine Museen-Pause, (aber auch unfreiwillig).

Der Mailserver nimmt wieder alle e-mails an und ich kann sie auch mit dem Thunderbird abrufen sowie weiter versenden. Der neue i5 Server ist bezüglich der 4 Sub-IP Adressen auch repariert und der Umzug kann (könnte) beginnen. Alle Webseiten sollen dazu auch auf "https" umgerüstet werden, um manchen Browser Standard-Einstellungen zu entsprechen.

Leider Fehlanzeige - Der neue Intel i5 Server ist schon wieder völlig anders. Er hat nämlich zwei 250GB SSDs, ..... aber nicht die SSDs, die Sie kennen, nein, es sind die neuen hypermodernen "NVME- Steckkarten", die zwar irrsinnig schnell sind (3 x so schnell wie schnelle Festplatten) - aber wieder völlig anders "ticken". Und schon gehen über Jahre funktionierende Arbeitsschritte und Funktionen (und wieder mal unvorhergesehen) nicht mehr. Es ist zum ko....... So langsam wird der ganze Zirkus nur noch nervig.

Wie wollen wir hier in Deutschland unser Land mit solcher Technik digitalisieren ?

Auch wenn diese neuen NVME- SSD-Speicher super schnell sind, noch hat das System Macken und wir bekommen wieder zwei SATA Festplatten in unseren Server.

Die originale Datenbank ist nach wie vor intakt erhalten, doch die neueren mysql/mariadb Engines zeigen Fehler über Fehler an. Dennoch kann ich mit dem Administrator "phpmyadmin" auf alle Datenbank-Felder zugreifen. Jetzt wird das CMS-Frontend angepaßt. Dann "könnten" die Seiten (mit Einschränkungen) wieder laufen.

Die benutzte PHP Version 5.5.14 auf dem Server mit dem PHP5-mysql Modul hat ein neues mysql-i API, ein notwendiges "application programming interfaqce" zur Datenbank und damit können die Folgeseiten der jeweiligen Startseiten nicht angesprochen werden. Also muß ich weiter suchen, was bei dem php-Upgrade noch alles geändert wurde.

Manchmal kann man sich tot suchen, weil es beim Suchen in mehreren Suchmaschinen zu viele Fundstellen gibt. Nach einigem Suchen habe ich endlich das (hoffentlich geniale) "check"-Programm gefunden, das mir die (update-) Fehler in unseren vorhandenen php-Programmen automatisch analysiert, anzeigt und evtl. sogar repariert.

Es hat aber viele viele Stunden gekostet, diesen "Code-Schnüffler" (mit Namen "php-codesniffer" 3.7.2) endlich funktionsfähig zu installieren und am Ende war es (plötzlich) ganz einfach (wenn man weiß wie). Die php-Versionen unserer php-Programme müssen auch von Stufe zu Stufe repariert werden. Es wird noch ein paar Tage dauern. Und die Nächte kommen auch wieder dazu.

Zur Funktion dieses typo3 CMS (unserer Museen-Datenbank) werden im sogenannten "Core" Bereich etwa 700 php-Programme angeboten. Wieviele ich davon reparieren oder upgraden muß, ist noch offen. Einige dieser Programme / Scripte haben etwa 20 Kilobyte Code, wenige andere sogar 90 Kilobyte und der php-codeSniffer erkennt in einem solchen Programm bis zu 7.000 Warnungen und Fehler. Es ist und wird also nicht trivial.

.