30.8.2023 - Die Chronik der Wiederbelebung der Museen-Seiten

Das ist die Kernfrage, die jetzt oft - von allen Seiten - gestellt wird.
.

1. Das erste Argument ist, es ist kein kommerzielles Projekt, es ist ein kulturelles freiwilliges Arbeiten als Ehrgeiz-Aufgabe für die Allgemeinheit - und zwar kostenlos. Damit ist es kein Notfall.
   
   
2. Das Zweite ist, die technischen Zusammenhänge in dieser EDV mit Content-System und Datenbank sind dermaßen komplex, daß man sich (als einzelner Macher) mit seinen Gedanken zu schnell in irgendwelchen gedanklichen Sackgassen verliert.
   
   
3. Das Dritte ist, ich wollte viel zu schnell mehrere Veränderungs- / Upgrade- Schritte in den Software-Componenten überspringen.
   
   
4. Das Vierte ist die enorme Lebensdauer dieser Museen-Seiten von ca. 13 Jahren, ohne daß an den Software- "Fundamenten" etwas Wesentliches verändert wurde.
   
   
5. Das Fünfte ist gewichtiger : Die regelmäßige (und sehr zeitaufwendige) Prüfung der automatischen Datensicherungen auf einem zweiten nackten Linux-Server sind vor Jahren eingeschlafen, - es hatte ja immer funktioniert. Und jetzt, da die Sicherungen gebraucht wurden, kamen die tückischen Fehler ans Licht. Sicherlich ist das ein dämliches Eigentor, aber nach 12 Stunden intensiver Redaktionsarbeit am Tag hat auch der motivierteste Admin und Redakteur keine Lust mehr.

.

 für die vielen Angebote von neuen Kontakten und von Kollegen, die sich gerne an dieser Aufgabe beteiligen wollen. Nach dem weiter unten beschriebenen ganz kleinen Erfolgserlebnis möchte ich hier vorher ein paar Grundlagen zusammenstellen, die später den php-Programmieren und weiteren (redaktionellen) Mitmachern den Einstieg erleichtern sollen.

Nach dem frühen Einstieg ins Web-Publishing in 2002, so heißt das auf "Denglisch", wurde Microsofts "Frontpage 98" (sogar auf einem Linux-Server !!!) zu schwerfällig und zu langsam, das war in 2003.

Die Auswahl eines (freien) Redaktionssystems in 2004 und 2005 war bereits mühsam. Keines konnte unsere Gedanken und Vorstellungen (ich kalkulierte damals schon mit über 10.000 Seiten) so recht befriedigen. Auch mit typo3 war der Anfang bescheiden.

Erst die Version 4.2.1 und später bis 4.2.17 brachte den finalen Durchbruch eine wirklich echten Redaktions-Systems.. Angelehnt an die (uralten) Schrift-Satz- und Layout- Erkenntnissen der FAZ Redaktion aus den 1950er Jahren haben wir das Aussehen gestaltet und nun gings los.

Aus 1.800 Seiten wurden 5.000 Seiten, dann 12.000, dann 18.000 und in 2023 sind es über 45.000 Seiten und das mit über 29.700 Bildern (die habe ich gestern zufällig mal während der Datensicherung aufgelistet) wuchs der Content gewaltig.

Das CMS typo3 System funktioniert hervorragend. Da geht ein später Dank an den Dänen "Kasper Skaarhoj" mit russischen Wurzeln, der in 2001 die Grundlagen für dieses geniale typo3 Konzept gelegt hatte.
.

Die Nachteile eines solchen komplexen Systems gab es natürlich auch. Unser typo3 ist nämlich abhängig von der Programmiersprache oder Scriptsprache "php" (Version 5.2 und besser/höher). Aber wieviel besser oder höher ? Bei der Version 5.6.40 hört die 5-er Version auf und es wird in der nachfolgenden php 7.x Version vieles anders.

Die Linux- Betriebssysteme passen die jeweiligen php Versionen an ihre jeweiligen Grundlagen an und irgendwann gibt es nur noch php 7.4 oder 8.2 und damit läuft bei unserem typo3 gar nichts mehr. Es ist "incompatibel".

Eine Rückwärtskompatibilität von php 7.x auf 5.x ist sehr mühsam und wird eigentlich nicht gewünscht, wegen der erkannten "Löcher" im System.
.

Blicken wir auf unsere Serverbasis (die Hardware) und dort auf die Zusammenhänge. Wir begannen mit einem PC mit 450 MHz AMD Prozessor mit 2 GB RAM. Das war toll und es lief dort opensuse 9.x oder 10.x - sehr stabil und typo3 war bereits recht schnell.

Aber bei 1.000 Seiten war das noch kein echtes Kriterium. Irgendwan bekamen wir die ersten peiswerten gebrauchten Compaq Proliant DL380 Server mit 2 mal 800 MHz CPUs und 8GB RAM. Die typo3 CMS Version 4.2.17 lief damit erstaunlich schnell und begeisterungsfähig stabil - über Monate !!.

Dann ein erster Versuch, auf die typo3 Version 4.5 "upzugraden". Es mißlang nicht nur, die gleiche "Kiste" (wir hatten mehrere dieser Server gebraucht aufgekauft) war stinklangsam.

Die typo3-ler (die source-Entwickler) versteckten sich (wir sollten einfach die Hardware auf 12 Kerne und 16 GB RAM "ausbauen") und wollten diese dummen Meckereien der gesamten Community aussitzen.

Dennoch war Voraussetzung zum Upgrade auf die danach folgende typo3 Version 6.x - "die ja jetzt viel besser sein würde" - ein stufenweises "upgraden". Nach 4 Wochen haben wir auch da das "Handtuch geworfen" und blieben bei unserer letzten (von uns bereits leicht modifizierten) typo3 Version 4.2.17. Mit dem Leistungsumfang war ich absolut voll zufrieden.
.

Inzwischen hatten wir auch eine amerikanisch/"russische" Suchmaschine Namens "mnogosearch" installiert und bekamen ganz "unglaubwürdige" Antwortzeiten bei gigantischen Abfragen.

Beim Suchen nach dem Namen "Grundig" kamen 6.000 !! Fundstellen (Antworten) in 0,06 Sekunden. Unser Datenbestand war duch Übernahme mehrerer ganz dicker Film-Bücher und Hifi-Magazinen mit vielen tausend Seiten bereits gewaltig auf über 30.000 Seiten gewachsen.

Unser typo3 funktioniert nach wie vor (Sommer 2023) super toll und wir hatten in keiner Weise irgend einen Leidensdruck, weder das Betriebsystem opensuse 12.3 zu ändern noch auf irgend eine neuere typo3 Version aufsteigen "zu müssen".

Alleine die Gefahr, daß immer mehr unserer chinesischen und russischen und sonstigen fernöstlichen "Freunde" nur noch darauf aus sind, uns Schaden zuzufügen, zwingt zum Nachdenken - zumindest beim Betriebssystem.
.

Der Strom wurde immer teurer und auch unsere damalige 34 Mbit/s Glasfaser-Datenleitung von unserem Serverraum in Wi-Bierstadt nach Frankfurt wurde für mich langsam (finanziell) untragbar. Wir mussten unsere Server "optisch" verkleinern und in ein Serverhousing umziehen. Dort kostete der Platz (sogenannter Rackspace) das Geld. Und wir bekamen neue (gebrauchte) flachere Server mit 8 Kernen und an die 3 GigaHertz CPUs. Jetzt konnten wir die Hardware-Server "virtualisieren". Das Schlüsselwort dafür heißt "XEN" oder "KVM".

Virtualisieren bedeutet, ich kann einen einzelnen "Hardware"-Server so einrichten, daß er mehrere "Software"-Server "bewirtet", sogenannte "virtuelle Maschinen", = VMs. Und sinnbildlich unten drunter werkelt ein Linux-Gastgeber, der Wirt bzw. der Host. Wird der Host aber gekillt, sind alle VMs oben drüber platt. Also dort muß eine sichere Software, eine aktuelle Version (bei uns von opensuse) installiert sein.
.

Das Upgrade von 15.3 auf 15.4 hatte auch funktioniert, das von 15.4 auf 15.5 jedoch nicht - ohne ersichtlichen Grund. Und damit fing das unerwartete Dilemma an. Bislang konnte man ausgehend vom Host-Betriebssystem mit dem Virtualisierungs-Manager in eine leere VM ein xbeliebiges Betriebssystem installieren und dann sofort loslegen.

Und da ich durch Unaufmerksamkeit das alte 12.3 Betriebssystem der Museenseiten überschrieben hatte, wäre es doch ein Leichtes, ganz schnell mal die alte opensuse 12.3 dort wieder drüber zu installieren und die Sicherung einzuspielen, alles kein Problem, dauert 1 Stunde - dachte ich ..........

Doch mit den opensuse Versionen ab 15.0 als Host-Betriebssystem ging das nicht mehr, auch nicht von einer lokalen ISO Datei aus. Ich bekam keinen alten oder neuen virtuellen Gast mit einer alten opensuse 12.3 zum Laufen.

Auch waren die alten opensuse "Repositorys" weg, das sind die öffentlichen Server mit den Datei-Verzeichnissen zum Installieren aller nur möglichen Software-Versionen aus dem Internet heraus. Jetzt ging die elende Sucherei los.

Zum Glück habe ich jede Menge an i5 und i7 Hardware bei uns im Labor und konnte alle Varianten und Kombinationen ohne Virtualisierung hier auf je einer separaten 128GB SSD ausprobieren. Doch ganz schnell waren (wieder) zwei Wochen weg.
.

Ein keines Wunder (mit einer uralten opensuse 12.3 Version). Nachdem so vieles an Kombinations-Versuchen nicht geklappt hatte und mehrere Wochen unerfolgreich vestrichen sind, (die Laune war völlig im Eimer) also nochmal eine opensuse 12.3 auf einem einzelnen lokalen Test-Server hier bei uns installieren, auch wenn es - wie vor 2 Wochen - über 3 Stunden dauern würde.

In den opensuse Installations-Routinen wird nämlich öfter "irgendwas" im Internet nachgefragt. Ist der angefragte Server aber nicht mehr da, wartet das Install-Programm - manchmal bis zu 15 Minuten - pro Abfrage !!, da kommen dann 3 Stunden zusammen.

Gestern Abend mit genügend Tee und Plätzchen gut vorbereitet - dann auf einmal, es ging alles ratz fatz ! 15 Minuten und der Server hatte die erste Runde hinter sich. Jetzt war ich platt. Die 12.3 Repos sind wieder da !!!! Ganz plötzlichund ohne Kommentar. Und die Plätzchen wurde nicht gebraucht.

Bei uns im Haus ist alles mit Gigabit vernetzt, also mal schnell die noch funktionierenden Original-Daten und Sicherungen auf den Server aufgespielt und Apache2 und mysql installiert, alles in einer unglaublichen Geschwindigkeit - die Rücksicherung wäre jetzt vollzogen.
.

Nach einiger Zeit war auf diesem lokalen Test-Server mit der lokalen IP Nummer als URL wieder die Startseite eines meiner Webs aus der Datenbank zu sehen, aber die Folgeseiten noch nicht. Die Suche nach dem Bug ging weiter.

Im Backend von typo3 ist auch hilfsweise ein (Mini-) Anzeige-Modul eingebaut, welches mir alle meine Seiten (einzeln) samt der Bilder zeigen konnte, nur im Frontend gings noch nicht. - Und den Bug suche ich noch. - Gefunden - Aha, in der vhost Config war eine Zeile falsch. Es funktioniert wieder - endlich.
.

Um alle Anforderungen und Möglichkeiten solch eines Webservers wie des Apache2 an die jeweilige Verwendung anzupassen gibt es mehrere (besser gesagt ganz viele) Konfigurationsdateien. Nur um einige Dateien zu nennen, hier ein Anfang:
.

• /etc/sysconfig/apache2
• /etc/apache2/default-server.conf
• /etc/apache2/server-tuning.conf
• /etc/apache2/httpd.conf --- (das ist die wichtigste und längste Datei)
• /etc/apache2/listen.conf ---
  und natürlich die speziellen vhost-Dateien für die 4 Museen-Seiten und mehr,
  das sind die virtuellen Hosts - im Verzeichnis
• /etc/apache2/vhosts.d/............

.
Bei uns muß der Webserver mehr machen als nur (fertige statische) Seiten ausliefern. Er wird von draußen nach einer bestimmten Seite aus einer von mehreren Museen-Domains gezielt gefragt und muß dann mit Hilfe eines Datenbank-Verbindungsmoduls (in php programmiert) den Seitentitel finden und in eine sogenannte Page-ID übersetzen und aus der mysql Datenbank die zu dieser Page-ID gehörenden "Brocken" (die Content-Elemente) zusammensuchen, zu einer Seite "montieren" und als fertige statische Seite fertig formatiert mitsamt der kleinen Bilder ausliefern.

Um das zu leisten gibt es mehr als 300 zu konfigurierende Eigenschaften für den Webserver sowie das PHP-Umfeld und die mysql/mariadb Datenbank-Engine. Nur "1" einziger Fehler und nichts geht mehr - so einfach ist das.

Im Moment geht mein lokaler Test-Server wieder. Und den portiere ich jetzt nach Düsseldorf und passe ihn an, und schalte ihn online .... es ist ja erst 2 Uhr Morgens am 31.8.2023. Und die Augen werden müde - also Morgen gehts weiter.
.

Das Portieren einer teilweise funktionierenden lokalen Server-Installation in eine Virtuelle Maschine in Düseldorf :

Eigentlich sollte es ganz schnell gehen, doch es dauerte einen Tag und eine Nacht, bis ich es zum Laufen bekommen habe, Und es ist immer noch halbfertig.
.

.