Herzlich willkommen zu meinem Vortrag Still Not Super Heroes, also Untertitel, was die Open Source Admins lieber nicht verraten würden. Fangen wir mal an, wer sind die Open Source Heroes? Also wir sind die Admins der Open Source Infrastruktur, also ein Großteil dessen,

was Sie hinter irgendwas.opensource.com finden. Große Ausnahmen sind Bildservice, Backzilla und OpenQA. Und ich bin einer von diesen Admins. Und zwar schon in der Vortragserkündigung, dass man sein Popcorn mitbringen muss. In den letzten Jahren haben wir die Open Source Infrastruktur deutlich verbessert, klar.

Aber es ist jetzt perfekt, natürlich nicht. Sonst hätten die Admins langweile und ich könnte den Vortrag nicht halten. Wie gesagt, ich bringe ja auch einen Popcorn Vortrag. Die Jäger würden es vielleicht sogar ein Büterät nennen. Und Zwecksgag wechsle ich jetzt mal kurz auf Englisch.

However, the heroes will need their glasses. You know these. Und ich fange mal mit etwas an, für das wir einige Gläser gebraucht haben, als es noch online war, nämlich Connect Open Source Org.

Ursprünglich mal gedacht als eigenes Social Network für Open Source und wurde dann aber tatsächlich nur benutzt zur Verwaltung der Open Source Mitglieder als Member. Problem an der Sache, das System war alt und unmaintained. Also Source Linux Enterprise 11, wer es noch kennt.

Und ja, dann kam halt irgendwann einer von den Admins. Das ist zwischenzeitlich unsicher, müssen wir abschalten. Problem an der Geschichte, irgendwie müssen wir unsere Mitglieder verwalten. Gab dann reichlich Diskussionen auf der Mailing-Liste.

Was könnte man als Ersatz benutzen? Wie kann man die Mitglieder verwalten? Gab auch ein paar Ideen, aber wie man es halt so kennt von Mailing-Listen, Ideen ja, Aktivitäten eher null. Ergebnis an der Sache, Connect läuft und läuft und läuft. Wir brauchen es halt. Bis dann eines Tages tatsächlich jemand den Stecker gezogen hat.

Bedeutet dann gleichzeitig erst mal, wir sind den letzten Slay 11 los. Hurra. Aber wir brauchen immer noch einen Ersatz. Und wir haben dann tatsächlich auch einen gefunden. Vielleicht nicht perfekt, aber es funktioniert, erfüllt seine Aufgabe.

Was wichtig ist, leicht zu maintainen. Und sogar falls wir die Datenbankstruktur mal ändern müssen, ist auch kein Problem. Das geht auch ganz leicht. Und die Lösung ist diese da, PHP MyAdmin. Ja, klingt einfach, aber es funktioniert.

Warum? Mitglieder-Databank ist im Wesentlichen Benutzer-Name, E-Mail-Adresse, IRC-Nickname und ja, das war's. Also deswegen, warum da irgendwelche komplizierte Lösungen aufsetzen, weil wir einfach nur eine kleine Datenbank im Einsatz haben. Und wenn jemand Mitglied werden will, dann gibt es noch unser Ticketsystem auf Code Open Source.

Und so ganz nebenbei bemerkt, manchmal hilft es, wenn man statt große Mailing-Diste-Diskussionen einfach nur die fünf Leute anschreibt, die tatsächlich zuständig sind und mit denen dann die Lösung ausnobelt. Dann kommt nämlich auch was raus aus der Diskussion.

Und nachdem wir jetzt endgültig Connect Open Source los sind, also ein Fossil weniger, gehe ich mal weiter mit etwas recht Neuem. Nämlich, wir hatten im Juni die Open Source-Konferenz in Nürnberg und vielleicht hat es der eine oder andere mitbekommen, es gab da auch eine Fedora-Hedge, also quasi eine Art Mini-Konferenz von Fedora.

Und ich bin ja ein großer Fan von Zusammenarbeit zwischen Distributionen. Aber trotzdem, so sehr ich Fedora mag, gibt es Grenzen. Zum Beispiel, wenn Sie unsere Konferenz-Webseite kaputt machen, stellt sich heraus, im April guckt jemand auf die Events Open Source-Org

Warum Internal Surfer Error? Mit der Fehlermeldung im Bild, also ein Template Error, mit undefined-Method Gravatar-URL vor Nil-Glas. Klar, Nil ist Null in Ruby, wer es nicht kennt.

Dass es für Null keinen Gravatar gibt, verstehe ich ja noch, aber warum Null? Schauen wir erstmal in die Vorlage, die den Fehler verursacht hat. Also man sieht, da wird blind links auf eine Eigenschaft des Speakers zugegriffen. Aber durch nirgends einen Check gibt es überhaupt einen Speaker.

Und in dem Fall war halt tatsächlich der Speaker nicht vorhanden. Stellt sich raus, Punkt 1, jemand hatte die Fedora-Hedge als Highlighted Event markiert, deswegen überhaupt das Problem. Und genau, dann guckt man mal in die Datenbank.

Die Fedora-Hedge hatte ein Sub-Meter, nämlich Nil-Gumpa. Aber sie hatte keinen Speaker, deswegen Nil. Bitte die beiden nicht verwechseln. Und das zu reparieren war dann relativ leicht. Die Vorlage-Datei checkt jetzt zuerst, ob es überhaupt einen Speaker gibt, bevor sie irgendwelche Eigenschaften verwendet.

Auch etwas relativ Neues. Im englischen Open Source Wiki gibt es ein neuer header, wo drin steht, dass wir ein Versionsupdate gemacht haben. Das war an Ostern. Und ja, manche Sachen brauchen halt ihr Zeit. Habe ich dann auch festgestellt beim Datenbank-Update,

nämlich das Update auf die Testinstanz hat zwei Tage gedauert, bzw. hätte, wenn ich nicht vorher Steuerung C gedrückt hätte. Allerdings wusste ich auch, die Tests in einer lokalen VM waren relativ schnell, so eine Viertelstunde oder so. Was macht man dann?

Man zieht schnell noch ein MySQL hoch. Und plötzlich geht es auch schnell. Stellt sich raus, ein Galearer-Cluster liefert zwar Hochverfügbarkeit, aber keine Schreibgeschwindigkeit. Also gerade bei Update-Skripte ist das schrecklich. Auch noch ganz lustig beim Wiki-Update.

Die anderen Wikis haben zu, sagen wir mal, lustige Ergebnisse geführt. Also der Screenshot zeigt jetzt die Hauptseite vom alten englischen Wiki, also olden open source org. Also zumindest, was das Update-Skript für die Hauptseite hält.

Sprich, man sieht ja am Inhalt, das war mal eine Diskussionsseite. Und das muss ich mir dann noch einmal im Detail angucken. Also im Moment läuft es jetzt halt noch mit der alten Version. Und für die lokalisierten Wikis gab es auch diverse lustige Probleme, wo dann das Update-Skript behauptet, dass Inhalte ungültig sind. Ich soll sie bitte löschen.

Kann man ja machen, aber dann ist kein Wiki mehr übrig. Macht also auch keinen Sinn. So, dann Nürnberg. Nächster Punkt. Gab es im November 2020 einen Stromausfall. Kommt ja mal vor, dann sehen halt die Lichter aus. Heißt aber auch, dass das SUSE-Data-Sender vom Strom abgeschnitten war

und die Batterie halten eben nicht ewig. Und deswegen waren dann auch einige open SUSE-Services down. So weit, so gut. Strom kommt zurück. Die Surfer buden wieder, die VMs starten. Alles gut. Schön wär's.

Vor uns open source org hat dann Mails geschickt an die Admins, dass es die Datenbank nicht erreichen kann. Also eine Mail pro Request oder anders ausgedrückt sehr viele Mails. Naja, immerhin nicht der letzte Tisch für unsere Mailserver. Aber warum kann das Forum eigentlich die Datenbank nicht erreichen?

Stellt sich raus, die war down. Also, wir benutzen Galera. Das ist MariaDB als Multimaster Setup. Und eigentlich gedacht für Hochverfügbarkeit. Aber wenn dann mal alle Nodes gleichzeitig ausfallen,

dann zieht's Galera vor, nicht zu starten, bevor es dann irgendwie in einem korrupten Status startet und Datenverlore gehen oder wie auch immer. Das übliche Problem halt. Naja, wie gesagt, verhindert Datenverlust oder dass man den alten Stand verwischt hat für sehr. Aber man muss dann halt manuell eingreifen

und wenn es blöd läuft, hat man dann auch gleich mehrere Stunden Downtime, bis so wieder alles synchron ist. Und ja, also unsere Datenbank-Admins hatten ihren Spaß dabei. Immerhin, sie hatten schon Übungen, nämlich ein paar Monate vorher hat mal einer von der Admins, die Gloria Hiddeg, noch mal kernel update

alle Datenbanknode gleichzeitig zu repute. Gleiches Problem. Und deswegen, wie gesagt, Hochverfügbarkeit ist ja ganz nett, aber ich würde mir dann doch wünschen, dass es die Situation verbessert und nicht verschlimmert. Und vielleicht sollte man mal darüber noch denken, ob es da andere Lösungen gibt, die sinnvoller sind.

So, aber der Stromausfall hatte noch eine nette Nebenwirkung. Jetzt frage ich erst mal in die Runde, kennt jemand zufällig Beans-Open-Zusorg? Vermutlich nicht. Warum? Das ist ein netter Hintergrunddienst, nämlich ein Matomo mit Web-Statistiken.

Und es stellt sich dann raus, also auch ein paar Monate vor dem Stromausfall hat jemand das Matomo auf eine neue VM umgezogen und alles gut, alte VM runtergefahren. Und ja, noch im Stromausfall ist aber die alte VM wieder hochgefahren, war anscheinend etwas schneller, hat sich die IP gegrallt.

Deswegen, also klar, jetzt ist die alte VM tatsächlich auch disabled, dass sie nicht noch mal hochfahren kann. Und was macht man noch so im Stromausfall? Never waste the crisis. Und einer von unsere Community-Admins hat danach gleich gefragt,

wann könnte man bitte den nächsten Stromausfall haben, so zum Testen? Was auch immer ganz lustig ist, wenn dann jemand sich meldet, ich kann mich nicht mehr per SSH einloggen, in dem Fall zum Nameserver in Provo. Na ja, schauen wir mal.

SSH habe ich auch nicht mehr geschafft, aber immerhin aber noch erreichbar über Salt. Was macht man dann? Ich nenne es inzwischen die Salt-Backdoor, nämlich es gibt einen netten Saltbefehl CMT dort dran. Dann stoppt man mal die Firewall. Ist bei nicht erreichbar schon mal ein netter Versuch.

Es hat tatsächlich geholfen. Stellt es raus, blick in die Firewall-Config. Also man sieht, da gibt es die Internal Zone, die SSH erlaubt, die Monitoring erlaubt und so weiter. Und es gibt eine öffentliche Zone, die nur DNS erlaubt. Macht ja so weit Sinn.

Problem an der Geschichte? Schauen wir mal, wo die Interfaces stehen. Also wenn man dann das Private Interface in die Public Zone steckt, erklärt, warum SSH nicht geht. Und wenn wir es schon von Salt haben,

benutzen wir es für Konfigurationsmanagement. Und wer sich das mal angucken will, was wir da so machen, unser Salt-Report ist öffentlich auf Code Open Source. Ihr könnt da gerne reingucken, Pull-Requests machen. Da freuen wir uns immer drüber. Und wir benutzen Salt für immer mehr Dienste und Surfer.

Und als Beispiel, unsere Mail-Surfer sind jetzt seit ein paar Monaten komplett gesoldet. Aber es gibt immer noch einige Surfer, die zu Fuß gemanagt werden. Und ja, macht dann halt Spaß in der Administration. Und was eigentlich recht gut ist, in unserem Salt-Report gibt es bisher keine Commits,

wo irgendwo das Wort UPS drin vorkommt. Also von daher scheint Salt eine ganz gute Idee zu sein. Was allerdings ein Problem sein kann, und das ist tatsächlich schlimmer, als ein Surfer zu Fuß zu managen ist, wenn ein Surfer mit Salt gemanagt ist.

Und jemand kommt dann und macht irgendeinen Hotfix von Hand und schreibt es aber nicht in die Salt-Konfig zurück. Sprich, wenn man dann das nächste Mal ein Salt-High-State ausführt, also quasi das aus dem Konfigurationsmanagement erwenden will. So, goodbye Hotfix.

Oder anders ausgedrückt, eine Salt-Zeitbombe. Ich habe jetzt auch schon erwähnt Code Open Source Org. Was ist das? Also, das ist eine Gitforge, also so etwas Ähnliches wie GitHub oder GitLab. Also die Software nennt sich Pescher.

Ist ein Open Source Code Hosting System. Und es gibt auf Code Open Source Org unter anderem auch von allen Paketen in Tumbleweed Dissourcer, wo man sich dann relativ gemütlich zum Beispiel über die Git-Historie auch gucken kann, wie sich die entwickelt haben. Und was an dem Code Open Source Org natürlich auch wichtig ist,

wie bei jedem Dienst, es funktioniert. Ja, meistens. Gibt dann halt mal abgelaufenes SSL-Zertifikat, stellt sich raus, das Zertifikat wurde erstellt direkt auf der VM mit Dehydrated.

Soweit so gut. Aber vielleicht wäre es eine gute Idee gewesen, dass man auch noch den Dehydrated Timer enable, dass es dann auch tatsächlich erneuert wird. Und ja, einmal Dehydrated, von Hand auf Rufe geht es wieder, und jetzt ist sogar der Timer eingeschaltet. Spaß am Rand. Es gibt die ETC Dehydrated Domains TXT,

die war leer. Und es gibt interessanterweise eine Datei namens Sold Domains TXT, wo die Domains tatsächlich drinstehen. Aber um das Ding abzurunden, steht die Datei natürlich nicht im Sold. Genau.

Auch ganz interessant, wir haben unsere Mailing-Liste umgestellt auf Mailman 3. Und da gab es dann bei der Open-Source-Konferenz war ja vorher auch nicht eine Folie im Vortrag von Sarsi. Und der hat dann auch tatsächlich während dem Vortrag, also bei der Online-Konferenz,

die Migration vom Mailing-Liste-Archiv laufen gehabt. Und man sieht ja schon, das ist einfach eine Folie voll mit Passwörtern. Was bedeutet das jetzt in der Praxis? Zum einen einige lustige Erkenntnisse. Zum Beispiel Mails aus der Zukunft.

Also ich erinnere mich an Mails von 2036 und sogar 2094. Also halt ein falscher Dateheader. Das blöde, die Lotto-Zahle fehlen. Und wir hatten auch Spaß mit Zeilen, die mit From-Lehrzeichen anfangen, weil halt das M-Box-Format doch nicht so standardisiert ist, wie man es gern hätte,

sondern es gibt halt fünf Untervarianten. Und das eigentlich Spannendste an der Sache, die Links ändern sich. Also man sieht, die alten Archive waren Slash-Mailing-Liste-Name und dann ja ein Monat und eine Nachrichtennummer. Und das neue Archiv mit Postorius ist jetzt halt Slash-Archives

und dann der Listenname und dann ein Hashtag von der Mail. Genau. Und deswegen gibt es jetzt auf unserer Mailing-Liste-Surfer ein paar Redirects, dass die alten Links noch funktionieren. Also ein paar. So, ja, um die drei Millionen oder 340 MB.

Aber ja, was macht man nicht alles, um die Links funktionsfähig zu halten? Immerhin konnte man die Redirects automatisch generieren. So, dann erinnern wir uns an die Folie von zwei Jahren zurück. Da steht was von Easy Moderation. Ja, stimmt auch.

Wir hatten dann aus Versehen beim Umstieg die Mailing-Liste so eingestellt, dass nicht-Subscriber moderiert werden statt abgewiesen. Und führt halt dazu, dass dann die Weite Schlange voll waren mit Spam. Und ja, kann man löschen, klar. Stellt sich aber raus, das Web-Interface

braucht dann einen Moment, um den Spam zu löschen. Also so 20 Sekunden pro Mail. So, und jetzt machen wir das mal mit 20.000 Mails. Ich meine, kann man still machen. Und es passt auch immer noch auf Easy Moderation. Von Geschwindigkeit war ja nie das Brech.

Und auf jeden Fall. Und sein Mailing-Liste-Admin, wie immer, never waste a crisis. Und er hat dann nur gesagt, ja, wenn ich langweil hab, dann lösch ich halt mal wieder eine Portion Spam. Wäre ich therapeutisch. Aber am Schluss hat er dann doch tatsächlich geschrieben, dass das dann über Nummer hat.

Und inzwischen sind die meisten Mailing-Liste umgestellt, dass nicht-Subscriber direkt abgewiesen werden. Macht mehr Sinn. Mailman 3 ist auch noch lustig, weil er mit dem Python 3.6 in Leap noch gewisse Probleme hat. Und jetzt sind wir noch am Überliche.

Also Leap 15.4 hat ja auch Python 3.10 an Bord. Oder vielleicht machen wir auch gleich ein Update auf Tumbleweed. Schauen wir mal. So, waren wir schon beim Mail-Syn. SPF, kennt vielleicht einer oder andere. Also Sender Policy Framework. Vielleicht auch Source of Problems and Frustration.

Und ja, wir haben dann halt festgestellt, dass Mailing-Liste-Mails rausgeschickt werden mit einem Envelope from at OpenSuse.org statt List OpenSuse.org, was wir erwartet hätten. Auf der Mailman-Seite war alles richtig, aber die ausgehenden Relays haben die Doments umgeschrieben.

Ja, Konfigurationsfehler kommt vor. Führt halt dazu, dass das Bounce-Management de facto ausgeschaltet war. Also sprich, ungültige Mail-Adressen wurden nicht automatisch von der Mailing-Liste geworfen. Aber ja, klar, aber der Konfigurationsfehler könnte schon schnell behoben.

Umschreiben war vorbei. So weit, so gut. Nur beim Blick ins Log sehen wir dann, dass so um die 10% von den Mails, die man in Richtung Gmail schicken, rejected werden. Welche SPF-Failer? Und ja, im SPF-Eintrag steht halt,

welche Surfer dürfen Mails verschicken für die Domain. Stellt sich raus, ja, List OpenSuse.org hat einen SPF-Eintrag, aber da steht normalerweise nur die IPv4-Adresse drin. Und ja, die Mails, die dann halt über V6 rausgegangen sind, wurden halt abgelehnt berechtigterweise.

Und ja, Pluspunkt an der Sache, wir sind jetzt sicher, dass das Bounce-Management funktioniert, durch den kleinen Konfigurationsfehler wurden nämlich 370 Leute unsubscribed. So, vielleicht hat es ein oder andere mitgekriegt,

dass Download OpenSuse.org die komplette Technik ausgetauscht wurde. Vorher war es Mehrrohr-Brain, jetzt Mehrrohr-Cache. Also sprich, beides ein Redirektor zum passenden Mehrrohr, aber Mehrrohr-Cache halt mit einigen Verbesserungen. Und das Gute an Mehrrohr-Cache ist jetzt auch, dass wir mehrere Instanzen haben können.

Also es gibt jetzt eine in der EU, eine in den USA und so weiter. Und das ist fast zu langweilig für den Vortrag. Also der erste Fehler, der das vorgesagt hat, war relativ harmlos. Es gibt ja das Skript Tumbleweed-Kli. Also sprich, wer seit Tumbleweed gezielt auf eine bestimmte Version updaten will,

statt mit Super Dupe immer auf die neueste, der benutzt das. Und das Skript hat halt nicht erwartet, dass die Datei mit der Nummer vom neueste Tumbleweed-Snapshot plötzlich in Redirekt ist. Und ja, ich stand halt mal kurz aus der Kurve, weil Köln standardmäßig den Redirekt nicht folgt.

War aber relativ leicht zu fixen, also von daher kein Problem. Es gibt in unserer Infrastruktur eine Tradition, nämlich der eine oder andere kennt vielleicht den schönen Counter noch so und so viele Tage bis zum Open Source Release. Und die Tradition ist, der Counter geht bei fast jedem Release kaputt.

So, ich habe jetzt mal die Erinnerung von 15.3 auf 15.4 auf dem Bildschirm. Sieht ja eigentlich harmlos aus. Hat jemand eine Idee, was so schief gehen könnte? Also eigentlich nur Versionsnummer angepasst, Datum angepasst.

Aber trotzdem, Invalid Token. Ja, stellt sich raus. Genau, Python interpretiert Zahlen mit führenden Nullen als Oktal. Und die 02 war halt gültig. Aber 08 ist halt eine ungültige Oktaltal.

Also von daher, ich habe auch den Vortrag vorgestern bei der Linux User Group gehalten. Und da kam dann der Vorschlag, also bei der Behörde gäbe es jetzt eine neue Policy. Die Releases bieten spätestens im Juli und spätestens am siebte eines Monats.

Man kann natürlich auch einfach die führenden Nullen rauslöschen. So, und wir freuen uns natürlich immer über Unterstützung. Es gibt bei uns genügend Services, die man pflegen darf. Oder vielleicht will ja jemand etwas ganz Neues hochziehen.

Und deswegen, ihr dürft gerne bei uns mitmachen. Wir bieten so ziemlich alles, also von Archäologie bis hin zu Serviceverwalte mit Salt. Und so, im Prinzip ist die einzige Voraussetzung, man soll, wie sowas, Administration bedeutet, so die Grundlage.

Und den Rest lernt man dann schon mit der Zeit. Ich kann auch versprechen, man lernt auch einige Dinge, die man eigentlich gar nicht, wie sie wollte. Und natürlich hat man bei der ganzen Sache immer einen Haufen Spaß. Es gibt allerdings eine Art Eingangsprüfung bei uns, auch wenn das nie so geplant war.

Nämlich das Setup vom VPN-Zugang, das mal in unser internes Netzwerk kommt. Scheint schwieriger zu sein, als es eigentlich klingt. Warum? In der Theorie, es gibt eine Leitung in unserem Wiki, einfach nur Step-by-Step-Folge sollte funktionieren. Ja, in der Praxis haben dann die Leute doch verschiedene Wege gefunden, dass es doch nicht geht.

Und Sachen, die ich jetzt so mitgekriegt habe, waren zum Beispiel der Benutzernahme. Also sprich, unser VPN braucht ein Zertifikat und dann noch einmal Login mit Benutzernahme-Passwort. Ja, der Benutzernahme ist halt case-sensitiv. Und was sich dann auch herausgestellt hat, im SUSE-Netzwerk scheint UDP leicht kaputt zu sein.

Also spätestens, wann die SUSE-Leute dann auf TCP umgestellt haben, hat es tatsächlich funktioniert. Und wir hatten dann sogar einen neuen Hero, der hat dann etwas getrickst und hat einfach einen erfahrenen Hero eingeladen zum Griller.

Und wenn du schon da bist, ich bräuchte da noch einen VPN-Setup. Ich meine, ist hier nichts Schlimmes dabei. Und ich gehe davon aus, dass das Griller auch Spaß gemacht hat, also passt. Und wie man sieht, damit kommt man sogar in meinen Vortrag. Und ja, wenn euch das alles jetzt noch nicht abgeschreckt hat, also bisher ist hier noch niemand schreiend rausgerannt,

dann dürfen ja gern bei uns mitmachen. Und in diesem Sinn möchte ich mich bedanken. Zum einen bei den ganzen Admins, die unsere Infrastruktur am Laufe halten. Bei allen, die uns Infrastrukturprobleme berichten, zum Beispiel per Mail an Admin.at.opensuse.org.

Und ein spezieller Dank geht an all die, die aus Versee zu meinem Vortrag Beigedrache haben. Und in diesem Sinn, wenn es Fragen gibt, also egal ob jetzt speziell zu Themen aus dem Vortrag oder Infrastruktur bei Opensuse allgemein, gern.

Oh Gott, gibt es keine Fragen oder ertraut sich niemand?

Sieht aus wie wenn es tatsächlich keinen, doch?

Bist du glücklich?

Eher eine generelle Frage zu Opensuse. Was ist dieses ALP? Was soll das werden? Genau, also das ist quasi in der Entwicklung derzeit, also die nächste Version von Suse Linux Enterprise, aber komplett anders. Also die Planung ist ein Basissystem und alles andere in Container stecken.

Also wie sich das entwickelt ist im Moment noch offen, also alles noch im Testmodus und Entwerfmodus. Also vorher gibt es dann mal noch eine neue Liebversion, definitiv. Also die 15.5 ist geplant für nächstes Jahr.

Und ich denke, bis dahin sind wir dann auch schlauer, was mit dem ALP so passiert. Genau, also wiederhole ich gerade noch kurz den Hinweis. Also die Jastleute sind schon vorgeprescht und man kann jetzt Jast im Container

benutzen und kann damit quasi sein System administrieren, ohne dass man Jast installiert hat. Aus dem Container raus, genau. Ja, also ich denke, Tumbleweed dürfte in etwa so bleiben, wie es jetzt ist.

Ich habe gehört, dass ALP Lieb ersetzen soll auf mittelfristig. Warum Lieb und nicht Tumbleweed? Ja gut, man muss ja erst mal wissen, ALP ist ja gleichzeitig auch

der Nachfolger vom Suse Linux Enterprise und Lieb basiert ja auf Suse Linux Enterprise. Also sprich, die beiden sind gekoppelt, zumindest mal in derzeitigen Zustand. Ja, im Release Engineering Team und als Ergänzung dazu, ALP war die Idee von Suse. Das steht eigentlich für Adaptable Linux Plattform, genau.

Und dementsprechend, wir haben eine Working Group, damit der Community erstellt, damit man mit uns zusammen bei Lieb die gleichen Pakete verwendet wie Suse Linux Enterprise, dass man daran weiterentwickelt und Ideen sammelt.

Dementsprechend, es ist eine Suse Idee für Suse Linux Enterprise und weil Lieb die identischen Pakete verwendet wie Suse Linux Enterprise, sind wir auch davon betroffen und Tumbleweed soll separat von der Community weiterentwickelt werden.

Gibt es noch Fragen? Das ganze Prinzip ist ja sehr zukunftsorientiert und könnte es sein, dass dieses Weed-Only -Wood-Fire-System-System mit den Container-Applications drauf auch langfristig auf Tumbleweed eingesetzt wird?

Gibt es bisher keine Planungen und ganz ehrlich, ich will es nicht haben auf meinem Laptop. Also ich denke im Surfer-Bereich klingt es durchaus sinnvoll. Ob es jetzt im Bereich Workstation so sinnvoll ist, ja, zeigt sich noch.

Schauen wir mal, wenn es die erste Prototype gibt, wissen wir vermutlich mehr. Also auf jeden Fall denke ich mal, dass Tumbleweed bis auf weiteres so bleibt, wie es ist. Im Surfer-Bereich hat man ja Micro-OS. Zum Beispiel, ja, genau. Und Slee soll in dieser Richtung weiterentwickelt werden.

Genau, also, ja. Ja, Slee soll sich genau in diese Richtung Micro-OS weiterentwickeln. Die haben auch ein Slee-Micro inzwischen rausgebracht. Und man überlegt sich, wie man das dann weiterentwickelt und dann kombiniert.

Ich gucke mich gerade um. Gibt es noch Fragen? Es sieht nicht so aus. In diesem Sinn dann sage ich mal danke fürs Zuhören.