[Eisfair] Base-OS, Dinge zerbrechen (was: Tschuess Eisfair)

[Kay Martinen]

Am 30.08.25 um 08:16 schrieb Marcus Röckrath:
> Hallo Kay,
> 
> Kay Martinen wrote:
> 
>> Und ich hatte an verschiedenen Stellen im System den
>> Eindruck das Teile oder das Grundsystem von einem damaligen Ubuntu
>> übernommen wurden.
> 
> Das war auch meine Erinnerung, bevor als Grundsystem dann Alpine bei
> eisfair-ng genutzt wurde.

Dann stimmt es wohl, damals. Und davor sollen einige Sachen (E-1) von 
einem Red Hat übernommen worden sein wie ich dunkel erinnere. 
Upstream-sources vermutlich. Ob das immer noch so wäre weiß ich nicht. 
Bei RH gab's ja auch einige Umbrüche.

>> die Basis gewesen wäre. Dann wäre das update mit zwei 'apt' aufrufen
>> erledigt gewesen. Aber, man hätte beim EIS-Teil/Repo dann wohl auch mit
>> Upstream mit halten müssen bei den eigenen Abhängigkeiten - die dann auf
>> das Basis-system (Debian/Ubuntu/?)verweisen müßten. = Kontrollverlust
>> und mehr Arbeit.
> 
> Kritisch wird es dann, wenn das zugrundeliegende System Änderungen
> durchführt, auf die das aufbauende eisfair zwingend sofort parallel
> reagieren müsste.

Hmm. Also so Sachen wie den wechsel des init-systems, usr-merge, oder 
von lilo auf grub o.ä.

Alles auch bei anderen Distris schon passiert. Und IMHO mit ordentlich 
vorlaufzeit. Da sehe ich noch keine zwingende Notwendigkeit. Ein Mint 
hat hier z.b. den usr-merge lange optional angemahnt bis es dann obligat 
wurde. Ebenso ein Devuan und ein Debian das ich noch hatte.

> Wenn man aber als eisfair-Team auch irgendwie enger an das Team des
> Grundsystems angebunden ist, bekommt man sowas auch erst dann mit, wenn das
> Update gemacht wurde und gegebenenfalls - und dann auch gleichzeitig bei den

??? Das würde ich genau umgekehrt verstehen, das man bei engere Bindung 
so etwas schon kommen sieht bevor es akut würde und vorarbeiten könnte. 
Weil man dann auch näher am Entwicklungsprozeß dort wäre. Wenn man mit 
liest.

Anders wär's doch wenn man nur dessen System (Binär) als Basis nimmt und 
sonst nicht weiter involviert wäre. Also man eben KEINE engere 
Verbindung hätte. Dann kann ich mir schon vorstellen das man von 
Änderungen überrascht wird - wenn sie fertig sind und ausgespielt würden.

Und dann kann natürlich bereits jemand ein update von Distri-X geholt 
haben, und dazu Pakete von EIS-X die dann nicht passen und deren update 
dann Fehler wirft. Da kommt es dann m.E. primär drauf an ob man das 
fehlgeschlagene update zurück rollen kann, die fehlerhaften Pakete 
deinstallieren und das vorige zurück holt/reinstallieren kann. Das 
Gesamtsystem ist dann zwar nicht aktualisiert, sollte aber ansonsten 
gesund/Bootbar bleiben.

Dazu fällt mir ein das ich auch mal 5 oder mehr Kernel in der Boot-liste 
(Lilo/Grub) hatte und /boot einfach voll war - bis es die Möglichkeit 
gab einzelne alte Kernel zu deinstallieren. Und /boot dann bei 
Neuinstallationen auch vergrößert wurde.

> Anwendern - das Kind in den Brunnen gefallen ist, also bestimmte Dinge dann
> schlagartig kaputt sind - notfalls bis zum kompletten Serverausfall.

Das scheint mir nur dann kritisch zu werden wenn es um bootloader und 
kernel-eigenschaften und initrd ginge. Wie oft kommt das vor?

Wenn der kernel noch bootet kommt man doch zumindest in eine 
Reparatur-shell.

Und wenn dann [Hoppladiwutz] init durch systemd ersetzt worden wäre kann 
man vermutlich auf der Shell weiter reparieren - wenn nicht zusätzlich 
auch noch ein mißglücktes usr-merge links zerschmetterte. ;)

Machen wir uns mal nix vor. EISFAIR war sicherlich nie für 
Hochverfügbarkeit gedacht und ausgelegt. Dafür gibt es andere Lösungen. 
Ob die Downtime bei einem Privaten Serverchen nun 5 Sekunden (Failover?) 
oder 5 Stunden (bis Reparatur) beträgt scheint mir irgendwie kein 
Wichtiger Punkt zu sein. Und die Wege zur Reparatur sind m.E. in jedem 
Linux (Grund)System gleich und keine Besonderheit des EIS. Weil es 
letztlich auch nur EIN LINUX ist. Die EISFAIR-Schicht setzt ja später 
an/auf wenn der Kernel läuft.

Natürlich steckt der Teufel im Detail, es ist also wichtiger zu sehen 
WAS eigentlich abgelaufen ist bis zum Fehler/Ausfall - um ihn dann auch 
reparieren zu können. Und da erinnere ich mich wohl an einige Threads 
hier bei denen du und andere durch nachfragen das Problem fanden und 
eine Lösung hatten.

Aber: Hatte das in Jedem Fall mit EIS Eigenheiten zu tun oder hast du 
lediglich den Vorteil den EIS und was abläuft besser zu verstehen? Und, 
hätte das gleiche nicht auf jeder anderen Distri ebenso passieren 
können, vielleicht mit dem unterschied dort nicht sofort jemanden zu 
finden der das System so gut kennt?

Bye/
   /Kay

-- 
Posted via Leafnode