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

.

Nicht nur bei jungen EDV-Genies, auch bei den alten EDV-Hasen ist sofortiges Protokollieren - also alles notieren, das teilweise oder gar nicht geht bzw. das plötzlich doch geht - unabdingbar wichtig.

Dazu ist die Materie viel zu komplex und zu umfangreich. Bei mir sind es hunderte von "outlook"- Karteikarten in nach Themen strukturierten Bereichen, weil ich da ganze Verzeichnisse recht komfortabel nach Schlüsselwörtern durchsuchen kann sowie alle dort untergebrachten Links sofort aufrufbar sind.

Am Ende kostet nämlich das Suchen und Auswerten der google- Fundstellen viel mehr Zeit als das eigentliche Reparieren, vor allem, wenn es nicht funktioniert. In vielen Foren wird aus mir unerklärlichen Gründen auf das Datum verzichtet. Der Leser kann kaum abschätzen, wie alt der "Geistesblitz" ist und ob er überhaupt noch funktioniert.

Und der verblödete "Tip", doch erst mal die Handbücher zu lesen, ist wirklich destruktiv. Nach der "Seite 700" von nur "einem" Handbuch wisssen Sie als Leser gar nicht mehr, was sie eigentlich gesucht hatten. Da ist die Suche in Suchmaschinen ein klein wenig sinnvoller.

hier fehlt noch einiges.........
.

Bei der Installation eines Host-Betriebssystems auf einem ganz neuen leeren Server kann man entweder die Angebote des Datacenter Betreibers (bei uns myloc-webtropia Düsseldorf) nutzen oder eigene "Versuche" unternehmen.

"myloc" bietet als Neu-Installation nur die uralte "Opensuse Version 15.2" an, wobei die zur Zeit ca. 3 bis 4 Jahre alt ist und eigenlich bereits "verboten" gehört. Im Moment (Aug. 2023) wäre die Version 15.6 aktuell.

Also was tun ? Nach mehreren "unerfolgreichen" Versuchen mit der automatischen myloc- Installation mit RAID-1 und später auch ohne RAID habe ich mich entschieden, selbst händisch mit der Installation der Version 15.3 zu beginnen. Diese Version lief bei mir nachweislich als Xen- oder KVM- Host- Betriebssystem bis zum (eigen verschuldeten) Absturz völlig problemlos und nahezu unsichtbar.
.

Ein sogenannter "dedicated root server" - also eine wirklich völlig autarke PC-ähnliche Hardware - und nur für mich ganz alleine - läßt sich immer per Management- Web-Interface mit einem sogenannten "rescue Betriebsystem" starten. Solch ein betrioebssystem wird über das Netzwerk in den Hauptspeicher geladen uund ist völlig unabhängig von der lokalen Festplatte. Sonst wäre eine Installation bzw. Fernsteuerung und Reparatur von Wiesbaden aus gar nicht machbar.

In dieser speziellen "debian" rescue Variante (genannt "grml") kann ich in einer im RAM-Speicher neu anzulegenden "virtuellen KVM-Maschine" ein Installations- Medium (bei uns zum Beispiel eine 4,1 GB große opensuse 15.3 ISO-Datei) aus dieser Datei heraus starten und dieses System ganz am Anfang auf der (den) zukünftigen Server-Platte(n) installieren. Doch diese Installation (aus einer virtuellen maschine heraus) "sieht" die eigentliche Hardware gar nicht und muß sich mit der virtuellen Ebene der Hardware (insbesondere des essentiell wichtigen Netzwerk- Treibers) abfinden. Das muß dann später wieder repariert / korrigiert weden.

Wenn die eigene händische Installation - wie auch immer - nach mindestens 40 Minuten durchgelaufen war, muß das installierte Betriebssystem erstmalig aus dem Boot-Sektor dieser Platte starten, vorerst in der im rescue System erstellten VM.

Doch das ist nur ein Teil der Wahrheit, weil diese VM immer noch von der ursprünglichen Installations- ISO-Datei aus dem RAM-Speicher (problemlos und erfolgreich) gestartet wird und aus dem opensuse-Menü aus diesem bereits gestarteten Boot-System jetzt direkt der (restliche) Start von der zugeordneten Platte beginnt.

Hintergrund:
Für den Start eines Linux-Betriebssystems von einer Festplatte gibt es mehrere Varianten. Man kann einen sogenannten Master-Boot-Record (MBR) erzeugen oder eine eigene kleine Boot-Partition (1GB) anlegen oder ein Boot-Verzeichnis in der zukünftigen "root" Umgebung (50GB) spezifizieren.

Bei efi ist das dann noch anders. Da gibt es eine klitzkleine efi Bootpartition ganz am Anfang der Platte mit nur 8 MegaByte. Der YAST-Installer von opensuse muß das alles abfragen und eine entsprechende Boot-Konstellation anbieten, die dann später auch bootfähig "wäre". - Haben (hatten) Sie (böser Mensch) aber andere Vorstellungen von einer professionellen Festplatten-Konfiguration, kommt hundert mal der Fehler, "so würde das kein bootfähiges System" werden. (Ein "warum" wird nicht verraten.)

Nach dem nächtelangen Ausprobieren "aller" 1000 Möglichkeiten und kurz vor dem Sprung aus dem Fenster akzeptieren sie dann doch den vorgeschlagenen YAST- Ur-Vorschlag, - und sei er (für unsere Zwecke) noch so unsinnig oder unbrauchbar (das warum kommt später dran). Und wieder ist ein Tag und eine Nacht rum.

Hat der Bootvorgang dieser Installation dann (endlich) einmal oder sogar mehrmals hintereinander geklappt, ........

..... kommt die Stufe 2

Diese gesamte erste (von einer ISO-Datei aus startende) VM wird nun beendet (komplett aus dem Speicher gelöscht) und eine neue VM wird - aber jetzt mit anderen Optionen - wieder im RAM-Speicher angelegt, jetzt aber ohne die ISO-Datei, (die ja anfänglich beim Booten mitgeholfen hatte).

Diese neue VM soll - mit den speziellen "disk" Optionen beauftragt - das neu installierte Betriebssysstem jetzt wirklich direkt und von Grund auf von der eigenen Platte booten. Damit wird der Boot-Loader "grub2" direkt gefordert (oder angewiesen), ein Betriebssystem aus dem MBR oder der Boot-Partiton zu starten. Klappt auch das, (endlich !!! und sehr erfreulich) könnte es eigentlich im normalen Modus losgehen.

Doch während der Installalation in der VM hat der YAST-Installer nur eine virtuelle Netzwerkkarte (bzw. den virtuellen Chip) "gesehen bzw. erkannt" und diese Konfiguration in seine Dateien eingetragen.

...... darum brauchen wir die Stufe 3

Allermeist ist ein erster Start des Servers ohne rescue System - jetzt als eigenständiger Host - vordergründig unerfolgreich, weil die Netzwerk-Einstellung - ein falscher Netzwerk-Treiber - (noch) nicht stimmt. Der Server ist von außen erstmal nicht zu erreichen. - Auch das muß man mit Tricks reparieren. Deshalb ist nochmal der rescue-Modus hilfreich. Hierbei "mounte" ich mir die root-Partiton des opensuse Host-Betriebssystems in das Filesystem des virtuellen debian Betriebssystems und korrigiere die Netzwerk-Konfiguration.
.

Wir sind hier immer noch auf der untersten, der Host-Ebene und das Netzwerk meldet sich nicht.

Das rescue- (debian / grml) System und opensuse unterscheiden sich da deutlich. Wenn das debian/grml Betriebssystem im rescue Modus startet, wissen wir schon mal beruhigend, die Hardware ist (im Prinzip) in Ordnung. Sonst könnten wir die IP-Nummer des Servers hier von Wiesbaden aus gar nicht sehen. Auch hat debian den echten Netzwerk-Chip korrekt erkannt und konfiguriert. Also im Prinzip funktioniert es !!

Doch es soll (später) bei unserer von der Platte autark gestarteten opensuse Neu-Installation funktionieren - und dort "gehen die Uhren anders". Bei opensuse (eigentlich bei allen Linuxen) habe ich mehrere Netzwerk- Konfigurations- Dateien, in denen die einzelnen Werte und IP-Nummern eingetragen sind. Mit dem YAST Net-Konfigurator sehe ich aber nur eine sicherlich gute Oberfläche, wenn das System bereits läuft.

Und eigentlich braucht ein Netzwerk Zugang nur

(1) den richtigen Treiber (driver) für den Netzwerk-Chip
(2) die eigene eindeutige IP-Nummer
(3) die IP-Nummer für das Gateway nach Draußen
(4) die sogenannte Netzmaske
(5) und bei Bedarf eine oder mehrere Nameserver- IP Nummern.
.

Dafür gibt es eine spezielle Datei im Verzeichnis /etc/udev/rules.d/ mit Namen
"70-persistent-net.rules".

Dort stehen mehrere Variablen mit Fragezeichen und einem "*". Die richtigen Bezeichnungen anstelle des Sternchens holt sich das Betriebssystem erst beim Start und bindet dann automatisch den richtigen Treiber für den erkannten Netzwerk-Chip in sein System ein.

Ist aber - warum auch immer - in dieser Datei der falsche Treiber bereits fest eingetragen (also kein Fragezeichen), suchen Sie sich tot, bis Sie diesen Bug gefunden haben. Auch darf dort erstmal kein Name für den Netzwerk-Port eingetragen sein. YAST kann das nicht korrigieren, zeigt aber auch keine Fehler an.

YAST erstellt einfach einen neuen eth2 Port oder einen eth3 Port, der bei uns aber niemals funktioniert hatte, weil es ihn gar nicht gibt. Wir haben nur einen einzigen Netzwerk-Chip.
.

Diese Datei(en) stehen bei suse im Verzeichnis /etc/sysconfig/network/
.

1. config
2. ifcfg-eth0 >>>> das ist die wichtigste Datei
3. ifcfg-lo
4. ifroute-eth0 (ab und zu gabs diese Datei nicht)
5. routes (komischerweise steht mal was drinnen und mal nicht - mal ist es ein Link mal eine Datei ???)

.
Und ... jedoch ein kleiner Fehler in einer der andern Dateien und auch geht nichts mehr.

Um auch auf dem Host weitere Software zu installieren, muß das DNS- System (die Namensauflösung der Domains) funktionieren. Sie brauchen mindestens einen (funktionierenden) Nameserver. Bei uns muß es ein Nameserver aus dem dortigen Düsseldorfer Netzwerk sein.

Meine Wiesbadener Nameserver aus dem Vodafone Netzwerk erlauben nämlich keine (fremden) Abfragen aus den Düsseldorfer myloc Netzen meiner Server. Also ein erfolgreiches "nslookup" in Wiesbaden ist zur Kontrolle unbrauchbar.

Weiterhin muß man unbedingt wissen, diese DNS-Server- IP-Nummer - die im Düsseldorfer Server-Netzwerk dann verwendet werden, stehen nicht in /etc/resolv.conf.

Dieser Datei-Eintrag ist nur ein symlink auf "/var/run/netconfig/resolv.conf". - Dieses Verzeichnis wurde bei uns nie gesichert, weil dort in /var/ eigentlich nichts Relevantes an veränderbaren Daten stehen "sollte".

Aber man wird klüger ......
.

Weiterhin kommt hinzu, daß in jeder der "virtuellen maschinen" noch eine wichtige Zeile von Hand in ifcfg-eth0 eingebaut werden muß !!!. Denn jede meiner Sub-IP-Nummern wird von draußen kommend gnadenlos auf die Server-IP (Haupt-) Nummer geroutet. Erst das "Point to Point Protokoll" knüpft die funktionierende Netzwerk-Verbindung der VM runter zum Host.

POINTOPOINT='213.202.254.1' (zeigt der VM den Weg auf das Gateway nach draußen)

Diese obige Zeile (die ist nur in den VMs) wird zwar bei Änderungen durch YAST nicht gekillt, doch öfter stimmt dafür der Rest nicht mehr und wieder - nichts geht mehr.

Eine weitere Zeile (in allen ifcfg-xxx Dateien) kann Manches reparieren, warum weiss ich auch nicht :

REMOTE_IPADDR='213.202.254.1' (das ist immer die Gateway-Adresse)

Sonderbar : Diese Zeile in die über Tage streikende "Mailserver VM" eingetragen wirkte Wunder. Auf einmal war die IP-NUmemr "von draußen" (aus Wiesbaden) zu sehen.
.

Die Neu-Installation mit ganz gezielt spezifizierten Eigenschaften des opensuse Host- Betriebssystems auf RAID-1 gespiegelten Platten habe ich nie hinbekommen. Entweder bin ich wirklich zu blöd oder es geht in den Versionen Leap 15.0 bis 15.5 nicht. Vorher in der 42.3 ging es !!!!

Jedenfalls mußte ich notgedrungen den Umweg über den pauschalen initialen Vorschlag des YAST- Installers gehen und die ersten 3 Partitonen auf der "sda" Platte als (nicht gespiegelte) Kröte "schlucken". Und ich schlucke ungern "Kröten".

Eine "root"-Partition von 1,8 Terabyte !!! für das wichtige Host-Betriebssystem mit oder ohne RAID ist absoluter Schwachsinn. Dort brauche ich maximal 50 GigaByte. Auf dem Host läuft nur ein einziges wichtiges Programm, der Virt-manager, weiter nichts (bzw. nur etwas mehr Komfort).
.

Und bei den VMs ist das wiederum anders. Bei mir werden seit 20 Jahren das eigentliche Betriebssystem (root) und die Daten auf mindestens 2 Partitionen aufgeteilt.

Wenn Sie die Vorschläge des KVM- oder Xen- Virt-Installers zur Erstellung einer VM unverändert "durchklicken" (übernehmen), wird in der root-Partition im Verzeichnis /usr/xxx/irgendwas/ ein Container erstellt, durchaus 100 GB oder mehr groß.

In dieser "einen" Container-Datei - der neuen VM - können Sie dann ganz normal Ihr(e) Gast-Betriebssystem(e) mit beliebigen inneren Partitionen installieren und betreiben - so die Theorie.

Wird aber Ihr Host-Betriebssystem jemals angeknackst, kompromittiert oder gar geknackt, kommen sie an diese Conatiner auch nicht mehr ran. Dann ist alles im Eimer.

Ich habe da eine deutlich verlässlichere Variante für die VMs gewählt, und das seit über 20 Jahren. Das Host-Betriebssystem ist völlig autark ganz am Anfang der Platte mit (normalerweise) 3 "Primary Partitions". Die allererste Partition (nur 8 MB) bekommt den MBR eingetragen und die root-Partition hat allermeist völlig ausreichende !!! 50 GB, also keine 1,8 TB. Eine separate swap-Datei ist auch noch dabei.

Der gesamte Rest der Platte (bei uns ca 1,75 Terabyte je Platte) ist eine einzige RAW-Partiton, wobei beide Platten spiegelbildlich aufgebaut werden.

Dann wird darüber ein RAID1 gelegt und dort eine erweiterte RAW Partitionen mit weiteren logischen RAW Partitionen angelegt. Damit ist jede VM-Partition völlig selbständig und vom root- File-System unabhängig. Stürzt das root-System ab, kann es bedenkenlos neu installiert werden. Und hatte man die VM-XML Dateien für jede VM gesichert, bekommt man solch einen Absturz recht schnell wieder auf die Beine. Doch das muß man auch mal üben !!!!
.

Der YAST-Installer hatte eine "efi"-Boot-Partition vorgeschlagen, danach eine root-Partition von ca. 1,7 Terabyte und danach eine obligatorische swap-Partition - ganz am Ende der Platte - mit nur 2 (zwei) läppische Gigabyte.

Gerade bei Festplatten sollte die swap-Partition ganz am Anfang im schnellsten Bereich der Festplatten liegen (bei SSDs ist das anders). Also muß ich da eingreifen und die 1,7 Terabyte Riesenpartition verkleinern (shrinken). Dafür gibt es das Programm gparted.

Alle 3 Partitionen haben von Anfang an diese UUIDs, die im Boot-Loader eingetragen sind und auch in der wichtigen Datei "/etc/fstab"stehen und die beim Löschen weg wären. Darum die Partition(en) "verkleinern" und eben nicht löschen und dann neuanlegen.

Diese 3 Partitionen sind vorerst nur auf der ersten Platte (sda) und damit ohne RAID-1 erstellt. Das ist ein manko, aber anders hatte ich es nicht hinbekommen. Um später ein RAID-1 System für die neu anzulegenden VMs mit den wichtigen Daten sauber zu spiegeln, habe ich auf der 2.Platte (sdb) 3 exakt gleich große Dummi-Partitionen aber unformatiert und unbenutzt als Platzhalter erstellt. Somit beginnen die beiden großen "erweiterten" Partitonen auf "sda" und "sdb" völlig symmetrisch an der gleichen Stelle. Alles andere wäre in noch komplexeres Verwirrspiel.

Auf beiden Fest-Platten sda und sdb werden jetzt mit dem YAST Partitonierer kleine spiegelsymmetrische unformatierte !! Raw-Partitionen angelegt und jeweils zu einem ebenfalls unformatierten !! RAID-1 zusammengefaßt - und dort drinnen werden später pro VM weitere aber formatierte Einzelpartitionen erstellt.
Die Details kommen noch.

Es muß weiter gehen mit der Reanimation des Betriebs der Museen-Dantenbank - dem eigentlichen Kern der Aufgabe. Dort hatte ich irrtümlich den gesammten root-Bereich der "virtuellen maschine" überschrieben und damit gekillt und später auch noch den Host verändert und damit den gesamten Server abgeschossen. Zum Glück war der Datenbereich auf der 3. Partition der "virtuellen Museums-maschine" nach wie vor unangetastet und hoffentlich intakt.

Weiter vorne auf den Seiten hatte ich beschrieben, daß es mir tagelang oder wochenlang nicht mehr gelungen war, eine neue VM mit opensuse 12.3 oder 13.2 zu "füttern" (bzw. zu installieren).

Die Installation verschwand mitten drin hinter einem schwarzen Bildschirm und nichts ging mehr, nicht vor und nicht zurück. Auch kein Reboot oder Zwangs-Restart. Um zumindst die alte ehemals noch laufende Museen-VM zu reanimieren, wäre doch der einfachste Weg, die alte Konstellation wieder herzustellen.
.

Am 18.9.2023 ganz spät Nachts lese ich durch puren Zufall - auf der Suche nach einem ganz anderen Fehler -, wenn "dies oder jenes" bei der Installation auftritt, solle ich bei der Installation der Version 12.3 ganz am Anfang nicht den Default-Modus oder den Text-Modus auswählen und auch keinen der anderen über 20 Grafik-Modi, sondern "No KMS" anklicken und dann würde "es" durchlaufen.

Was ist KMS, nie ausprobiert, und auch nichts darüber gefunden.
.

Das habe ich natürlich sofort mal ausprobiert, Nachts um 2.oo, also die opensuse 12.3 DVD als ISO (4,5 GB groß) in mein Host- /tmp/ Verzeichnis geholt und eine Dummi-VM Installation angestoßen ....

und siehe da, das funktioniert wirklich, zwar wieder mit weiteren Macken, aber zumindest die Installation läuft wirklich durch. Doch unter der Xen Virtualisierung kommt diese VM nicht mehr hoch - die VM startet nicht ????

Das ändert natürlich meine Strategie komplett, weil die DNS-Server und der Mail-Server bereits wieder auf neuen Suse Systemen laufen. Ich muß nämlich die Virtualisierung von Xen auf KVM umbauen, weil auch anderes nicht lief. Dort hatte die suse version 12.3 problemlos funktioniert.

So laufen die Tage und Nächte aus den Fingern .........
.

Also doch wieder zuerst die alte Museen- CMS-Version mit opensuse 12.3 installieren, dann erst über Upgrades von opensuse und php nachdenken ......

Um ganz sicher zu gehen, daß ich da nicht wieder in ein offenes Messer rein laufe, habe ich auf beiden Servern jeweils eine VM mit 12.3 instaliert und die kleinen Macken bereinigt und die auf dem Inhaus Test-Sever hier in Wiesbaden laufende opensuse 12.3 Testinstallation zu portieren versucht. Doch so geht das nicht, es ist zu aufwendig, das alles zu reparieren.

Einfacher war es, eine neue VM mit Hife der wieder gefundenen 12.3 "Repos" zu installieren und den Webserver und mysql und php5 von dort ebenfalls neu zu installieren. Wieder kamen ganz merkwürdige Eigenschaften zutage, die ich vorher nicht kannte und die wieder eine Nacht gekostet hatten.

Nach der Installation startete diese VM ganz normal. Aber nach den vorgeschlagenen 12.3 Updates aus dem Repo war es schon wieder zuende, nichts ging mehr. Die VM kam nicht mehr hoch. Also nochmal eine "Reparatur" der installierten Version starten und es ging plötzlich wieder.

Nach zwei weiteren Tagen unter Zuhilfenahme des lokalen Vergleichs- Test-Servers hier in Wiesbaden habe ich es geschafft. Die Mysql Engine startet und der Webserver auch.

Die weitere Reparatur von nur ein paar Kleinigkeiten dauerte dann doch wieder ein paar Stunden.
.

.

Vorerst nicht, die Zeit ist weggelaufen..............

.