„Das Wiki ist wieder da!“ Und alle so …

[Auge]

Hallo

… Yeah! \o/

Danke, dass ihr die Zeit und die Nerven aufbringt, um (hier speziell) die Infrastruktur am Laufen zu halten beziehungsweise wieder in Gange zu bringen.

👍👍👍

Was war die Ursache für den Ausfall (soweit das öffentlich kommunizierbar ist)?

Tschö, Auge

[Rolf B]

Hallo Auge,

Zeit und Nerven

Das waren weniger unsere Zeit und Nerven als die bei Manitu! Nachdem weder Dedlfix noch ich an den Server 'rankamen, habe ich deren Support-Postfach angeschrieben.

Ursache

Partieller Stromausfall (eine Sicherung hat ausgelöst) im Manitu RZ, ausgelöst durch ein defektes Netzteil (ob bei uns oder anderswo, weiß ich nicht). Betroffen waren nach Aussage von Manitu einige wenige Server. Vermutlich war das die Rumpelkammer mit den Antiquitäten, denn Wowbagger wird dieses Jahr 10 Jahre alt! Gepaart mit Silvester/Neujahr dauerte es dann insgesamt etwas länger, und ich denke mir, dass nach einem Netzteilschaden eines Servers erstmal gründlich geschaut wird, ob dadurch im betroffenen Kämmerlein Rack noch etwas kaputt ging. Vor allem, wenn Uralt-Blech betroffen ist.

Meine Supportmail am Silvesternachmittag führte zu einem Mailkontakt mit Manuel Schmitt - Chef von Manitu - und ich hätte einen Notfalleinsatz beauftragen können, habe aber in meiner „Selbstherrlichkeit“ als 2. alleinvertretungsberechtigter Vereinsvorstand entschieden, dass Selfhtml nicht so wichtig für die Welt ist, als dass wir dafür einen Techniker vom Silvestertisch hätten wegjagen (und unser Vereinskonto um 180€/Stunde erleichtern) müssen.

Manitu hat aber offenbar auch ohne bezahlten Notfallauftrag am Neujahrstag daran gearbeitet, denn abends am 01.01. um ca 19:00 ging es wieder.

Auch hier nochmal mein Dankeschön an Manitu für den Feiertagseinsatz!

Der Server ist deshalb so alt, weil bisher kein Bedarf für eine Grunderneuerung bestand. Nach 10 Jahren sieht es aber doch etwas kritischer aus, denke ich, und unser Serverbetriebssystem ist auch nicht mehr das frischeste. Aber Dedlfix und ich haben kaum Zeit, um einen Nachfolger von Wowbagger aufzusetzen. Vor allem habe ich nicht genug Know-How dafür. Wenn jemand, den wir schon eine Weile kennen, genug Erfahrung hat, um uns qualifiziert dabei zu helfen, würde ich das gerne annehmen. Der Job wäre:

• Server mit aktuellem OS aufsetzen (Dedlfix empfahl Debian), sofern das nicht eh schon der Hoster macht

• Per Automatisierung (z.B. Puppet oder Ansible)

  • Bereitstellen eines Mailservers (derzeit Postfix und Dovecot)
  • Bereitstellen eines Git Servers, z.B. für src.selfhtml.org. Wir nutzen derzeit Gitolite
  • Bereitstellen von Apache und PHP, und darauf ein aktuelles Mediawiki
  • Bereitstellen einer LetsEncrypt Anbindung dafür

• Übertragen der existierenden Mailpostfächer

• Übertragen der aktuellen Mediawiki-Daten von Test- und Hauptwiki auf das neue Mediawiki

• Portieren der Selfhtml-Extension und -Skin auf das neue Wiki

• Umschalten der Selfhtml-Domain auf den neuen Server mit minimaler Downtime (was vermutlich mit den LetsEncrypt-Zertifikaten in Konflikt steht...)

Vermutlich kommt noch einiges dazu, wenn jemand Interesse hat, würde ich mit ihr/ihm und Dedlfix einen Workshop zur Planung machen wollen.

Andererseits müssen wir auch mal schauen, ob ein Rootserver überhaupt für uns nötig ist und ob wir nicht mit einem XL-Webhosting klarkommen.

Rolf

[Auge]

Hallo

Danke für die umfassende Auskunft.

Tschö, Auge

[Raketenwilli]

Wenn jemand, den wir schon eine Weile kennen, genug Erfahrung hat, um uns qualifiziert dabei zu helfen, würde ich das gerne annehmen.

Hm. Sollte ich da vorsichtig den Finger heben?

Falls das der Fall ist eine Warnung: Ich bin viel auf Dienstreisen.

• Per Automatisierung (z.B. Puppet oder Ansible)

Das ist etwas, was ich nicht kann - und einen Grund dafür auch nicht sehe. Denn Ihr habt da, glaube ich 3, Server... warum sollte man sich die Hindernisse und Beschränkungen auferlegen welche eine solche Software notwendig mit sich bringt? Einfacher, weniger störanfällig oder sicherer wird es auch nicht.

Andererseits müssen wir auch mal schauen, ob ein Rootserver überhaupt für uns nötig ist und ob wir nicht mit einem XL-Webhosting klarkommen.

Im Hinblick auf …

https://github.com/sitaramc/gitolite/tree/master

a dedicated userid to host the repos (in this document, we assume it is "git", but it can be anything; substitute accordingly) this user id does NOT currently have any ssh pubkey-based access

ideally, this user id has shell access ONLY by "su - git" from some other userid on the same server (this ensure minimal confusion for ssh newbies!)

… muss es (wohl) mindestens ein virtueller Server sein. Denn den Extra-User (für Git) kann wohl die Verwaltungsssoftware für die Webhosting-Angebote regelmäßig nicht „abbilden“.

[Rolf B]

Hallo Raketenwilli,

Sollte ich da vorsichtig den Finger heben?

Sehr gerne. Du wärest fachlich wohl unser Idealkandidat 😍

Denn Ihr habt da, glaube ich 3, Server...

Im Prinzip ja, aber der mit dem Forum „gehört“ Christian Kruse und von den beiden anderen (Winnetou und Wowbagger) ist nur einer aktiv und hostet das Wiki und das Testwiki. Diese Gebrüder W. gehören abgelöst.

Vielleicht sollten wir mal vorsichtig aneinander fühlen, wenn Matthias wieder da ist. Warst Du schonmal auf unserem Discord Server?

Rolf

[Julius]

Hallo Raketenwilli,

• Per Automatisierung (z.B. Puppet oder Ansible)

Das ist etwas, was ich nicht kann - und einen Grund dafür auch nicht sehe. Denn Ihr habt da, glaube ich 3, Server... warum sollte man sich die Hindernisse und Beschränkungen auferlegen welche eine solche Software notwendig mit sich bringt? Einfacher, weniger störanfällig oder sicherer wird es auch nicht.

Das sehe ich anders: Auch da ist eine Automatisierung hilfreich. Man kann damit das Setup dokumentieren (muss man sowieso, dann auch gleich formalisiert!). Außerdem kann man dann den Server einfach und schnell neu aufsetzen, bereits bestehende Automatisierungen wieder verwenden oder Setups zu Testzwecken replizieren.

Viele Grüße
Julius

[Raketenwilli]

Außerdem kann man dann den Server einfach und schnell neu aufsetzen, bereits bestehende Automatisierungen wieder verwenden

Das wird „schwierig bin unmöglich“ sobald sich die Versionen der Software und Betriebssysteme ändern. Ich nenne mal die zahlreichen Unterschiede zwischen Apache 2.2/2.4, Python 2/3 und nicht zuletzt den Übergang von SystemV-init zu Systemd.

Vorliegend sind es 2 Server - ich denke wirklich, da mit ansible & co. drauf zu hauen macht die Sache viel zu aufwändig und mit Verlaub fehlerträchtig. In der Zeit, die ich brauchen würde um zahlreiche ansible-Konfigurations-Dateien anzupassen und neue Skripte zu schreiben konfiguriere ich ein paar Server mehr manuell bzw. mit copy & paste der Konfigfuration und benötigter Daten.

oder Setups zu Testzwecken replizieren.

Dann versuche mal - zu Testzwecken - mit ansible einen identisch funktionierenden Was-auch-immer-Server mit RedHat(oder Rocky), einen mit Debian(oder Ubuntu) und einen mit OpenSuSE einzurichten und so an einen LDAP-Server zu hängen, dass deren PAM diesem vertraut. Wie „schnell“ wirst Du fertig?

Die Stärken von solchen „Überstülpungen“ liegen eindeutig darin, in einem Rechenzentrum schnell aus dem minimalen Grundsetup einer geklonten (virtuellen) Maschine dutzende bis tausende solcher für eine bestimmte Anwendung (Webserver, Datenbank, what else) hochzuziehen. Nur frage ich mich, ob es dafür z.B. wirklich ansible braucht, denn letztendlich kann man das mit einem simplen Skript auch anders, sehr viel einfacher, durchsichtiger und also weniger fehlerträchtig haben.

[Auge]

Hallo Jörg,

vorweg sei gesagt, dass ich keinerlei Erfahrungen mit Ansible oder anderen derartigen Automatisierungssystemen haben. Aber …

Vorliegend sind es 2 Server - ich denke wirklich, da mit ansible & co. drauf zu hauen macht die Sache viel zu aufwändig und mit Verlaub fehlerträchtig. In der Zeit, die ich brauchen würde um zahlreiche ansible-Konfigurations-Dateien anzupassen und neue Skripte zu schreiben konfiguriere ich ein paar Server mehr manuell bzw. mit copy & paste der Konfigfuration und benötigter Daten.

… ich möchte zu bedenken geben, dass eine Serverkonfiguration für SelfHTML, oder allgemeiner: nicht für dich allein, nicht so gestaltet sein darf, dass nur du sie vertehst. Ich denke, wer hier regelmäßig mitliest, weiß, dass du das quasi im Schlaf kannst. Wenn du die SelfHTML-Server neu aufsetztest, erledigtest du das mutmaßlich in vergleichsweise kurzer Zeit, zuverlässig und nach bestem Wissen und Gewissen so, dass die meisten Anderen es als „perfekt“ bezeichneten. Am Ende muss aber auch jemand anderes die Konfiguration nachvollziehen können, der darin nicht ganz so firm ist, wie du. Kann ja sein, dass du dann, wenn es wieder einmal pressiert ^[1], nicht verfügbar bist.

Ob ein großes Autonatisierungssystem dafür die Lösung ist, oder nicht, kann ich nicht beurteilen. Ich vermute, wie du auch, dass das wohl unnötig schwere Artillerie ist. Aber auch bei einer Installation und Konfiguration „mit einem simplen Skript“ muss dieses so gut dokumentiert sein, dass jemand anderes als du damit zurecht kommt.

Wahrscheinlich rede ich hier auch völlig umsonst davon, da ich davon ausgehe, dass du das Problem einer verständlichen Dokumentation kennst.

Tschö, Auge

---

1. Ich denke, du kannst dich auch an den großen Forumsausfall vor zwölf oder dreizehn Jahren erinnern. ↩︎

[Rolf B]

Hallo Auge,

de facto haben wir einen Server, Wowbagger. Der andere, Winnetou, ist unerreichbar und müsste komplett neu aufgesetzt werden.

Wie müssen das sicher diskutieren und ggf auch probieren, aber mein Favorit für Wowbagger 2.0 ist ein gemanagter Server.

Manitu bietet mit Webhosting XL für 10 € im Monat ein Paket, das nominell alles kann was wir brauchen. Das einzige, was "custom" ist, ist Mediawiki.

Linux, Mail, Backup, DB, Webmanagement, alles von Manitu. Die Frage nach Automatisierung würde sich damit erledigen.

Es mag eine Frage des Prestige sein, dass Selfhtml einen eigenen Rootserver hat. Diesen Schuh müssen wir dann aber auch ausfüllen können und da ist es bei unserem aktuellen Personal eher dünn. Das wird sicher ein Thema für Mannheim. Ob MV oder drumherum.

Rolf

[Julius]

Hallo Rolf,

Wie müssen das sicher diskutieren und ggf auch probieren, aber mein Favorit für Wowbagger 2.0 ist ein gemanagter Server.

Wenn das funktioniert, spricht auch nichts dagegen. Ohne dafür handfeste Belege zu haben: Je nach Anbieter und Zuschnitt des Pakets könnte SELFHTML was Datenverkehr und Rechenleistung angeht, bereits über dem liegen, was Shared Hosting leistet. Vielleicht kann Manitu hierzu vorab Auskunft geben, wenn man ihnen Informationen (Traffic, CPU- und Speicher-Auslastung der PHP-Prozesse) zukommen lässt. Unlimitierter Traffic muss nicht zwangsläufig wirklich unlimitiert sein, manche Anbieter behalten sich eine Kündigung vor, wenn es wirklich viel wird.

Es mag eine Frage des Prestige sein, dass Selfhtml einen eigenen Rootserver hat.

Für mich persönlich jedenfalls nicht.
Ich denke, dass es einfach historisch so gewachsen ist. Früher war Shared Webhosting wohl einfach noch nicht so leistungsfähig wie heute.

Viele Grüße
Julius

[Auge]

Hallo

… Je nach Anbieter und Zuschnitt des Pakets könnte SELFHTML was Datenverkehr und Rechenleistung angeht, bereits über dem liegen, was Shared Hosting leistet.

Vorsicht!

Zitat von Rolf (Hervorhebung von mir):

… mein Favorit für Wowbagger 2.0 ist ein gemanagter Server.

Von Shared Hosting war nirgends die Rede.

Prinzipiell kennt Manitu auch den durch den SelfHTML-Server verursachten Traffic. Der SelfHTML-eigene Server steht ja bei denen und traffiziert in und durch deren Infrastruktur. Wenn SelfHTML bei ihnen einen gemanagten Server bestellt, sollten die wissen, worauf sie sich zu welchem Preis einlassen können.

Tschö, Auge

[MudGuard]

Hi,

Manitu bietet mit Webhosting XL für 10 € im Monat ein Paket, das nominell alles kann was wir brauchen. Das einzige, was "custom" ist, ist Mediawiki.

ist das Forum nicht auch in einer für Webseiten eher "unüblichen" Sprache geschrieben (also was anderes als PHP oder perl oder Java)?

cu,
Andreas a/k/a MudGuard

[Rolf B]

Hallo MudGuard,

das Forum ist von Christian in Eigenverantwortung mit eigenen Tools erstellt, nämlich Elixier. Kann außer ihm keiner von uns. Es ist open source, aber alien knowledge.

Wenn er ausfällt, stehen wir nackig da. Ob dedlfix da irgendwas tun kann, weiß ich nicht. Ich persönlich bin damit gar nicht glücklich, habe aber keine Alternative. Mit dieser Situation leben wir seit Ewigkeiten.

Rolf

[Camping_RIDER]

Aloha ;)

ist das Forum nicht auch in einer für Webseiten eher "unüblichen" Sprache geschrieben (also was anderes als PHP oder perl oder Java)?

Als kleines Addendum zu Rolfs Antwort, weil es meiner Meinung nach für deine Frage wesentlich ist:

Das Forum läuft auf einem ganz eigenen Server, der von Christian gemanaged wird (dedlfix hat auch Zufriff) und - soweit ich weiß - von Christians Arbeitgeber bezahlt wird (deshalb auch die zweite Sponsorennennung neben Manitu).

Man könnte also den Wowbagger mit Wiki, Blog und statischen src-Inhalten auf einen gemanagten Server oder ein Shared Webhosting übertragen (geeigneter Tarif mit genug Volumen vorausgesetzt) und am Forum würde sich nichts ändern.

Der Charme daran für den Verein: deutlich größere Ausfallsicherheit und deutlich weniger Abhängigkeit von Einzelpersonen und Gesamt-Manpower im Bereich Wiki und Blog und weniger technisch-fachliche Kompetenzen, die man im Verein auf Dauer abgedeckt halten muss, die Personaldecke ist auch in diesem Bereich dünn.

Im Forum bleibt die Abhängigkeit (ich verstehe Rolfs Bauchschmerzen damit gut), andererseits läuft das trotz Christians Vereinsaustritt seit Jahren geräuschlos.

Grüße,

RIDER

[Matthias Scharwies]

Servus!

Als kleines Addendum zu Rolfs Antwort, weil es meiner Meinung nach für deine Frage wesentlich ist:

Man könnte also den Wowbagger mit Wiki, Blog und statischen src-Inhalten auf einen gemanagten Server oder ein Shared Webhosting übertragen (geeigneter Tarif mit genug Volumen vorausgesetzt) und am Forum würde sich nichts ändern.

Der/das Blog läuft seit 2020 als Unterforum des CForums.

Danke für euren Input. Sobald wir das mit dem Makeover hinter uns haben, startet Rolf ein Developer Team mit Interessierten, so wie er es oben auch schrub.

Herzliche Grüße

Matthias Scharwies

[Camping_RIDER]

Aloha ;)

Als kleines Addendum zu Rolfs Antwort, weil es meiner Meinung nach für deine Frage wesentlich ist:

Man könnte also den Wowbagger mit Wiki, Blog und statischen src-Inhalten auf einen gemanagten Server oder ein Shared Webhosting übertragen (geeigneter Tarif mit genug Volumen vorausgesetzt) und am Forum würde sich nichts ändern.

Der/das Blog läuft seit 2020 als Unterforum des CForums.

Stimmt, danke für die Korrektur! Das hatte ich völlig ausgeblendet. Also läuft auf dem Wowbagger nur das Wiki und die statischen von src... eingebundenen Inhalte - und natürlich der Mailserver, der aber ja eh Probleme macht (oder das zumindest in der Vergangenheit gemacht hat), so dass auch bei dem eine Ablösung durch ein Webhosting-Paket wahrscheinlich wünschenswert wäre.

Danke für euren Input. Sobald wir das mit dem Makeover hinter uns haben, startet Rolf ein Developer Team mit Interessierten, so wie er es oben auch schrub.

Habe eben nachgelesen ob das geht. Ja, geht, nach §9.4 der Satzung - gut so.

P.S.:

Bei der Gelegenheit ist mir aufgefallen, dass im einleitenden Text vor der Satzung noch steht: „...außerdem wurde in der virtuellen Mitgliederversammlung vom 30.10.2021 §7 Abs. 4 [...] geändert. Die Bestätigung durch das Amtsgericht Dortmund steht noch aus.“

Letzteres ist falsch, das Amtsgericht hat die Bestätigung natürlich längst erteilt, ich habe wohl vergessen das damals noch mit Datum dort zu vermerken. Ich habe eben in meinen digitalen Unterlagen nachgeschlagen, die Bestätigung wurde mit Eintragung vom 16.11.2021 erteilt. Dort müsste also stattdessen stehen:

„...außerdem wurde in der virtuellen Mitgliederversammlung vom 30.10.2021 §7 Abs. 4 [...] geändert. Die Änderung wurde mit Eintragung vom 16.11.2021 durch das Amtsgericht Dortmund bestätigt.“

Danke!

Grüße,

RIDER

[Matthias Scharwies]

Servus!

Bei der Gelegenheit ist mir aufgefallen, dass im einleitenden Text vor der Satzung noch steht: „...außerdem wurde in der virtuellen Mitgliederversammlung vom 30.10.2021 §7 Abs. 4 [...] geändert. Die Bestätigung durch das Amtsgericht Dortmund steht noch aus.“

Letzteres ist falsch, das Amtsgericht hat die Bestätigung natürlich längst erteilt, ich habe wohl vergessen das damals noch mit Datum dort zu vermerken. Ich habe eben in meinen digitalen Unterlagen nachgeschlagen, die Bestätigung wurde mit Eintragung vom 16.11.2021 erteilt. Dort müsste also stattdessen stehen:

„...außerdem wurde in der virtuellen Mitgliederversammlung vom 30.10.2021 §7 Abs. 4 [...] geändert. Die Änderung wurde mit Eintragung vom 16.11.2021 durch das Amtsgericht Dortmund bestätigt.“

vielen Dank! Ich bin eh grad am Jahresabschluss dran und werde das alktualisieren.

Herzliche Grüße

Matthias Scharwies

[Camping_RIDER]

Aloha ;)

alktualisieren.

Jetzt bin ich ja schon echt lange dabei - aber den kannte ich auch noch nicht. ROFL^[1].

Grüße,

RIDER

---

1. Vokabel, voll cringe, die beweist, wie lange ich schon dabei bin. ↩︎

[Rolf B]

Hallo Janosch,

vielen Dank für deine Satzungsrecherche und den Hinweis auf den nötigen Nachtrag. Kann man das so verstehen, dass Dich die Innensicht des Vereins wieder interessiert?

Rolf

[Camping_RIDER]

Aloha ;)

vielen Dank für deine Satzungsrecherche und den Hinweis auf den nötigen Nachtrag. Kann man das so verstehen, dass Dich die Innensicht des Vereins wieder interessiert?

Jein. Das Interesse war ja nie weg, mein Austritt hatte ja andere Gründe.

In dem Fall wars akademisches Interesse weil ich über Matthias' Begriff "Developerteam" gestolpert bin und mich einfach interessiert hat, ob Nichtmitglieder dafür in Frage kommen. Und der Änderungsvorschlag, den ich mitgegeben habe, war mir deshalb so wichtig, weil das ein Versäumnis meinerseits aus 2021 war und ich ungern Versäumnisse aus der Vergangenheit unkorrigiert stehen lassen würde - ich verspüre für meine Amtsführung, auch wenn sie in der Vergangenheit liegt, selbstverständlich Verantwortung.

Ansonsten kann ich nur das wiederholen, was ich schon mit dem Austritt schrub: Ich bleibe dem Projekt erhalten, aber nicht als Mitglied des Vereins.

Natürlich schließt das einerseits ein gewisses Interesse an der Innensicht des Vereins auch mit ein. Andererseits weiß ich auch wie in der Vergangenheit mit Initiativen umgegangen wurde, die ich unternommen habe, deshalb bleibe ich da zurückhaltend - und nicht zuletzt unverbindlich, weil ich mir weitere Enttäuschungen gerne ersparen möchte.

Darüber hinaus bin ich sowohl am Verein als auch am Projekt nach wie vor interessiert, ja, das war aber nie anders.

Grüße,

RIDER

[Julius]

Hallo Raketenwilli,

Außerdem kann man dann den Server einfach und schnell neu aufsetzen, bereits bestehende Automatisierungen wieder verwenden

Das wird „schwierig bin unmöglich“ sobald sich die Versionen der Software und Betriebssysteme ändern. Ich nenne mal die zahlreichen Unterschiede zwischen Apache 2.2/2.4, Python 2/3 und nicht zuletzt den Übergang von SystemV-init zu Systemd.

Natürlich muss man da Anpassungen vornehmen. Aber immerhin kann man einfach nachvollziehen, was die alte Konfiguration ist und diese in die neue Welt übertragen, ohne vorher Archäologie betreiben zu müssen.

Außerdem kann eine Wiederverwendung der Automatisierung bereits vor Ablauf des technischen Haltbarkeitsdatums erfolgen.

Vorliegend sind es 2 Server - ich denke wirklich, da mit ansible & co. drauf zu hauen macht die Sache viel zu aufwändig und mit Verlaub fehlerträchtig. In der Zeit, die ich brauchen würde um zahlreiche ansible-Konfigurations-Dateien anzupassen und neue Skripte zu schreiben konfiguriere ich ein paar Server mehr manuell bzw. mit copy & paste der Konfigfuration und benötigter Daten.

Da übertreibst du ein bisschen arg. Ich sehe in meinen minimalen Ansible-Anwendungen nur ein Inventory mit 5 Zeilen und (je nach Anwendung) n Playbooks.

Gerade dieses manuelle Kopieren ist extrem fehleranfällig. Wenn ich ein Ansible Playbook auf ein paar Server anwende, weiß ich, dass die Konfiguration auf den Servern exakt die selbe ist und keine Kopierfehler enthält. Und wenn nicht, führe ich das Playbook halt erneut aus.

Ein paar Pakete zu installieren, ein paar Konfigurationsdateien zu kopieren bzw. aus Templates zu bauen, ist mit Ansible wirklich kein Hexenwerk.

Außerdem erhalte ich völlig nebenbei die Vorteile von Infrastructure as code:

1. Sauber geschriebene Playbooks sind auch gleichzeitig die Dokumentation.
2. Dank 1.) weiß ich, dass meine Dokumentation auch tatsächlich dem Stand auf dem Server entspricht.
3. Ich kann das ganze in ein git-Repo werfen und so Änderungen nachvollziehen (vernünftige Commit-Messages mal vorausgesetzt).

oder Setups zu Testzwecken replizieren.

Dann versuche mal - zu Testzwecken - mit ansible einen identisch funktionierenden Was-auch-immer-Server mit RedHat(oder Rocky), einen mit Debian(oder Ubuntu) und einen mit OpenSuSE einzurichten und so an einen LDAP-Server zu hängen, dass deren PAM diesem vertraut. Wie „schnell“ wirst Du fertig?

Ich verstehe nicht ganz, worauf du hinauswillst. Wenn ich einen Produktiv-Server mit Distribution x in Version z habe, setzte ich zu Testzwecken natürlich auch genau auf diese, außer wenn ich die Migration zu Distribution y testen will.

Nur frage ich mich, ob es dafür z.B. wirklich ansible braucht, denn letztendlich kann man das mit einem simplen Skript auch anders, sehr viel einfacher, durchsichtiger und also weniger fehlerträchtig haben.

Wenn du dann anfängst, deine Skripte fehlertoleranter zu bauen oder idempotent zu bauen, fängst du an, Ansible nachzubauen.

Viele Grüße
Julius