Skip to content

Rolle von Linux Distributionen

gedanken Ich weiss, dass das eine streitbare Meinung ist und bin auf Eure Ansichten gespannt.

Meiner Meinung werden Distributionen zunehmend keine Rolle mehr spielen.

Meine privaten Server laufen auf CentOS 7 und ich werde sie auf Ubuntu 20.04 migrieren.

Um aktuelle Applikationen unter CentOS betreiben zu können, habe ich zusätzliche Repositories aktivieren müssen. Andere Applikationen - es sind genau zwei - betreibe ich mit Containern unter Docker, wohlgemerkt nicht das Docker aus CentOS, sondern die Community-Edition von Docker selber. Weitere Repos sind die Remi-Repositories (für PHP), EPEL und MariaDB. Ja, ich kenne die Software Collections, ich habe aber vom Einsatz abgesehen, weil sie sich nicht so "sauber" in das System integrieren, wie die anderen Repos.

Zwischenfazit: Je länger die Laufzeit einer Distribution ist, desto mehr "Kunstgriffe" muss man unternehmen, um aktuelle Applikationen betreiben zu können. Das bedeutet im Umkehrschluss, dass von der Basis-Distribution immer weniger "übrigbleibt".

Jetzt ist es aber so, dass auch nicht alle Applikationen mit neueren Paketversionen zurechtkommen. Meine Blogsoftware tut sich beispielsweise mit neuen PHP-Versionen schwer, das Entwicklungsteam ist einfach zu klein. Das führt dazu, dass man mindestens zweigleisig fahren muss.

In der Firma setzen wir Red Hat Enterprise Linux ein, weil es die Distribution mit den meisten Zertifizierungen für Business-Software ist. Einer der Gründe dafür ist, dass die Firma über einen langen Zeitraum API-Kompatibilität garantiert. Das ist für Business-Software toll, für aktuelle "Free/Libre Open Source Software" (FLOSS) oder Eigententwicklungsn aber nicht.

Das führt unter anderem dazu, dass wir den Applikationen beibringen, dass sie ihre Applikation bitte möglichst unabhängig vom Basisbetriebssystem betreiben sollen, um von unseren Patchzyklen unabhängig zu sein. Wir würden gerne häufiger Patchen, aber wir bekommen die Downtimes nicht. Bei uns durchlaufen die Patches auch die verschiedenen Betriebsstufen und müssen wenigstens zwei Monate in Acceptance sein bevor sie in Produktion gehen.

Wenn ich die Zeit hätte, würde ich privat auf Alpine Linux wechseln und alles mit Containern betreiben, im Basis-OS würde dann nur ein Reverse-Proxy (Caddy, beispielweise) und vielleicht die Datenbanksoftware laufen.

Das gilt für den Desktop in einem ähnlichen Mass. Da kommt zum Basisbetriebssystem noch die Desktopumgebung dazu, die vielleicht von "der Distribitution" bereit gestellt wird. Applikationen kommen mehr und mehr in Distributions-übergreifenden Formaten wie Snaps, Flatpaks oder AppImages.

Die Kehrseite ist, dass wir dadurch von Unix-Errungenschaften wie Shared Libraries Abstand nehmen und das Patching dadurch ungleich aufwendiger wird. Bei einer Schwachstelle in einer Shared Library muss ich sie nur ein Mal patchen, bei Containerformaten, gekapselten Applikationen und autonomen Anwendungen muss ich jede einzelne Instanz aktualisieren (lassen).

Der Gewinn ist ungleich grösser, wenn Anwendungen - wie oben beschrieben bereit gestellt werden - laufen sie auf jeder Distribution, die die Laufzeitumgebung zur Verfügung stellt. Das wiederum beschert den Entwicklern die Möglichkeit, ihre Anwendung für alle Distributionen gleichzeitig bereitstellen zu können.

In Summe führt das dazu, dass das Basis-Betriebssystem nur noch sehr klein sein muss und eine deutliche kleinere Rolle als bisher spielt.

Trackbacks

workpress.plattform32.de am : PingBack

Vorschau anzeigen

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

tux. am :

*Meine Meinung:

Dieser Containerunsinn ist ein Sicherheitsrisiko (u.a. eben wegen Shared Libraries, die dann nicht mehr einfach vom System gepatcht werden können, sondern pro Container laufen - mit denselben Implikationen wie Electron, das ja immer mit einem veralteten Chromiumkern arbeitet...) und eins der vielen Indizien dafür, dass die Linuxwelt sich immer mehr an Windows orientiert. Sogar Programme kommen jetzt schon als Klickediklick-Rundum-sorglos-Paket daher. Nur noch eine Frage der Zeit, bis reguläre Paketverwaltungen ganz abgeschafft werden. Und dann?

Ich habe Linux vor neun Jahren fast komplett hinter mir gelassen, ein Ausflug zu Void/Gentoo vor zwei Jahren hat mich auch kaum noch begeistern können. Es mag die Dateisystemstruktur von Unix abbilden (bzw. seitdem in einigen Distributionen alles nach /usr verschoben worden ist, stimmt sogar das nicht mehr), aber darüber hinaus ähnelt es Windows zusehends mehr. Da nehm ich doch direkt das Original.

Auf meinen Servern laufen illumos (Ex-OpenSolaris) und BSD. Systeme aus einem Guss - und Container nur da, wo ich sie brauche. Und die verwaltet mir dann das System und kein Drittanbietergefrickel... :-)

Dirk Deimeke am :

*Illumos und BSD arbeiten auch mit Containern, nämlich Zonen und Jails. Damit bist Du dann auch bei Containern unter Linux - Implementierungsdetails einmal ausser acht gelassen.

Die heutige Entwcklungsgeschwindigkeit lässt sich mit bestehenden Konzepten nicht mehr abbilden. Da müssen dann andere Konzepte her.

Welche Konzepte hättest Du?

tux. am :

*Mit dem Unterschied, dass diese „Container“ Teil des Systemkerns sind und keine Hipstersoftware mit eigenen Angriffsvektoren voraussetzt... :-)

Die Entwicklungsgeschwindigkeit ist eigentlich „ausreichend“ für mich - allerdings warte ich meine Handvoll Server auch nach wie vor mit ein paar handgeklöppelten und mundgeblasenen Shellscripts. Ich gebe ungern die Kontrolle aus der Hand. Beim Thema Anwendungssoftware kommt der riesige Overhead hinzu.

Meine Software funktioniert in den meisten Fällen auch plattformübergreifend, schlimmstenfalls musst du sie nur noch mal kompilieren. Dafür hängt dann da kein Rattenschwanz an Abhängigkeiten dran, die du auf deinem System schon zigmal hast, aber unbedingt ein weiteres Mal (im „Container“) installieren musst, damit meine Software läuft. Ich freue mich ja für jeden, der Plattenplatz verschenken kann. Ich gehöre nicht zu diesen Menschen.

Wobei ich eigentlich den Sicherheitsaspekt schon für ausreichend überzeugend hielt.

Dirk Deimeke am :

*Es braucht für Container keine Hipster-Software wie "Docker".

Es gibt eine Software, die sich darum kümmert, Kernel-Features wie beispielsweise Namespaces und Control Groups verwaltbar zu machen. Es ging auch ohne, wäre nur wesentlich komplexer.

OS-Level Virtualization

Welchen Sicherheitsaspekt meinst Du, wenn Du mal Docker aus der Gleichung raus und SELinux oder AppArmor plus Kernel Capabilities rein nimmst?

Container laufen im Userkontext und haben dort den gleichen Level an Unsicherheit wie Applikationen, die im Userkontext laufen.

tux. am :

*All diese Software hinter deinem Link - chroot ausgenommen - braucht im Linuxbereich zusätzliche Software von Drittanbietern. Mit „Sicherheitsaspekten“ meine ich insbesondere: Wie stellst du sicher, dass in deinen Containern immer aktuelle Sicherheitspatches installiert sind? Im Artikel steht ja schon völlig richtig:

QUOTE:
Bei einer Schwachstelle in einer Shared Library muss ich sie nur ein Mal patchen, bei Containerformaten, gekapselten Applikationen und autonomen Anwendungen muss ich jede einzelne Instanz aktualisieren (lassen).


In der Regel hängen Container usw. aber nicht direkt am Paketmanager deines Systems. Darauf bezieht sich das.

Dirk Deimeke am :

*Ah, verstehe. Unterschiedliche Sichtweisen.

Für Anwendungen, die in Distributionen enthalten sind, passt das sehr häufig. Auch da gibt es genügend schlechte Beispiele.

Bei allen anderen Anwendungen muss ich mehr oder weniger manuellen Aufwand betreiben, um sie aktuell zu halten.

Sei es, dass ich neu übersetzen muss, einen Container neu bauen muss, eine neue Version vom Hersteller benötige, oder was auch immer.

Problem: Ich benutze nicht ausschliessliche Software, die bei der Distribution dabei ist. Das gilt sowohl privat wie auch beruflich.

tux. am :

*Deshalb fügen Container meiner Meinung nach vor allem mehr Komplexität und Risiken hinzu. Mit einer Handvoll Shellscripts oder notfalls so was wie Ansible (oder einer Distribution wie GuixSD oder NixOS, deren Konfiguration jederzeit reproduzierbar ist) wärst du da vermutlich besser dran.

tux. am :

*Kann man mit den von mir angesprochenen Lösungen - besser als mit Containern. ;-)

Dirk Deimeke am :

*Nee, man kann beides skripten, vor allem, wenn man selber die Container baut.

Jörg am :

*Ob Container die Rolle von Linux-Distributionen verändern werden, ist eine spannende Frage.

Aus Sicht der Software-Entwicklung sehe ich in den neuen Paketformaten (Flatpak, Snap, AppImage) und der Bereitstellung als Container-Image durchaus Vorteile. Auf diesem Wege ausgelieferte Software ist auf vielen Linux-Distributionen ohne weitere Anpassungen lauffähig. Im Vergleich dazu empfinde ich die klassische Pakettierung als Alptraum. Finde ich als Software-Entwickler keinen Paketbetreuer, der meine Anwendung für (s)eine Distribution pakettiert, muss ich mich entweder selbst darum kümmern, oder meine Anwendung wird unter der Distribution nicht verfügbar sein.

Nun ist Softwarepakettierung unter Linux nicht gerade vergnügungssteuerpflichtig und die Zahl der Paketbetreuer aller Distributionen nimmt gefühlt ab.

Daher glaube ich, dass die neuen Paketformate und Container-Images einen Anreiz bieten, mehr Software für Linux anzubieten. Das man dabei wieder die Qual der Wahl zwischen etlichen Alternativen hat, ist glaub ich ein Problem, das so alt wie der Linux-Kernel selbst ist.

Für mich als Sysadmin spielt es keine große Rolle, ob ich jetzt Container auf meinem System ausführe, die schlecht bis gar nicht gewartet/aktualisiert werden, oder ob ich mein System nicht aktualisieren darf, weil die schlecht gewartete Anwendung, die darauf installiert ist, dann nicht mehr läuft. Ich wünsche mir, dass mein Betriebssystem Werkzeuge mitbringt, um auch Gammel-Software, ob sie nun im Container läuft oder nicht, bestmöglich administrieren und beschränken zu können. Nun kenne ich den Solaris-/BSD-Werkzeugkasten nicht gut, glaube aber, dass bei Linux noch Luft nach oben ist.

Ich sammel erst seit kurzer Zeit praktische Erfahrungen mit dem Betrieb von Container-Insanzen (siehe Kanboard im Container und darauf folgende Artikel). Dabei konzentriere mich auf rootless-Container mit Podman. Mir gefällt dabei, dass ich ohne großen Aufwand eine Anwendung in einer isolierten Umgebung mit minimalen Rechten bzw. Capabilities betreiben kann. Das liegt jedoch auch daran, dass die mit den klassischen Software-Paketen ausgelieferten Systemd-Service-Units viele Möglichkeiten zur Beschränkung ungenutzt lassen. Dies müsste nicht so sein.

Ob Container die Rolle der Distributionen verändern werden, hängt in meinen Augen entscheidend davon ab, wer in Zukunft die Container-Images baut und bereitstellt. Übernehmen dies zukünftig die Software-{Entwickler,Hersteller}, ändert sich sicher einiges für die Distributionen. Pakettierung und Container-Image-Bau sind hier dann nicht mehr notwendig. Verbleibt der Container-Image-Bau bei den Distributionen, änder sich deren Rolle nur geringfügig.

onli am :

*Ich glaube ja, die Distributionen werden genau durch die Entwicklung sogar noch wichtiger. Weil ganz viel von ihrer technischen Grundlage abhängt - auch wenn man Appimages etc benutzt will der Nutzer dafür ja Oberflächen haben und das bitte schön alles eingebundene auch läuft. Mehr noch als früher sollen diese Anwendungen dann auch aktuell sein. Aktuell zusammenzukriegen mit einem stabilen System ist schwierig und braucht dann schon Ausnahmedistributionen wie Void - während gleichzeitig Ubuntu die Einführung der Snaps durch Zwangsupdates verkackt hat. Genau solches Verhalten wird dann den Unterschied ausmachen, technische Exzellenz, was für Distros eine Riesenherausforderung sein wird.

Was scheinbar vorbei ist, ist die Epoche der Langzeitunterstützung. Das haben die Distributionen aber sowieso nie wirklich hinbekommen, da war doch immer ganz viel Software in den Repos schlicht kaputt. Stabil kaputt, aber eben kaputt. Und diesen Rückzugsstandpunkt "wir stabilisieren aber immerhin alles für die professionellen Admins", das bricht weg. Jetzt muss alles passen. Das wird spannend.

Dirk Deimeke am :

*Nein! Ich habe das nicht auf Container beschränkt. Das Wort Container scheint ein "Trigger" zu sein. Es geht nicht nur um Container. Es geht darum, dass Applikationen ihre eigene Runtime-Umgebung mitbringen und da sind Container eine Möglichkeit unter vielen das umzusetzen.

Am einfachsten ist das bei Java-Applikationen zu verstehen, die ihr eigenes Java mitbringen und nicht das vom Distributor paketierte benutzen.

Deine Beschreibung von Gammel-Software bringt das Dilemma auf den Punkt.

Ich bin Deiner Meinung, dass man noch viel mehr mit systemd machen könnte, insbesondere systemd-nspawn bietet viele Möglichkeiten, die noch gar nicht genutzt werden.

Bezüglich Deines Fazits, wer die Container bereitstellt, gebe ich Dir ebenfalls Recht. Bein uns in der Firma bekommen wir immer mehr Software als Container direkt vom Softwareanbieter.

Dirk Deimeke am :

*Dass die Distributionen im Desktop-Bereich immer wichtiger werden, glaube ich tatsächlich nicht.

Dadurch, dass die Anwendungen alles mitbringen, was sie zum laufen brauchen, kann ich problemlos zwischen Distributionen wechseln.

Man braucht von einer Distribution nur noch Kernel plus Userland bzw. Kernel plus Userland plus Desktop.

Ja, ich weiss, momentan ist es noch nicht so, aber der Trend ist erkennbar.

Dazu kommt, dass viele aktuelle Desktop-Applikationen über das Web angeboten werden und den Browser als Rich Client verwenden (egal auf welchem OS der Browser läuft).

Gerrit am :

*Du unterschätzt meiner Meinung nach wie sehr von Teilen der Community das bisherige System aus Paketverwaltung und geteilten Bibliotheken auf einen Sockel gestellt und für sakrosankt erklärt wird. Das betrifft sowohl den Desktop als auch Server. Viele sind nach vielen Jahr(zehnten) der Linux-Administration so betriebsblind, dass die Nachteile nicht mehr sehen oder sehen wollen.

Diese Vorurteile ggü. den neuen Formaten werden dann in Supportforen Neulingen um die Ohren gehauen, die das kaum einordnen können.

Ich bin mir deshalb nicht so sicher, ob sich die neuen Formate wirklich durchsetzen können.

Dirk Deimeke am :

*Vielen Dank Gerrit.

Das ist genau der Grund, weshalb ich von einer streitbaren Meinung gesprochen habe.

Das, was Du schreibst gilt im gleichen Mass für Verfechter von SystemV-Init und Gegner von SMF (Solaris) oder systemd (Linux).

Alles, was neu ist, muss Mist sein.

Gerrit am :

*Dabei ist mir gerade dieser Vortrag wieder eingefallen.
https://archive.fosdem.org/2020/schedule/event/riek_kubernetes/

Jörg am :

*Zum Thema alles Neue taugt doch nichts, habe ich mal eine interessante Erfahrung gemacht. In einem Kommunikationstraining habe ich mit einem SysInit-V-Verfechter die Rollen getauscht. Ich habe pro SysInit-V argumentiert und mein Kollege pro Systemd.

Sein Fazit war, dass nachdem er sich ein wenig damit beschäftigen musste, er es nicht mehr für ganz so großen Mist hält. Ich werte das als echten Fortschritt. :-)

Jörg am :

*Ja, Container sind ein Trigger-Wort.

Aber ich stimme dir im übrigen zu. Aus meiner Sicht macht es sowohl für Entwickler bzw. Softwarehersteller als auch Sysadmins Sinn, wenn eine Anwendung ihre Laufzeitumgebung mitbringt. Ich glaube, dass man damit am Ende einfach den geringeren Aufwand hat.

Und auch uns haben einzelne Unternehmen signalisiert, dass sie ihre Anwendungen zukünftig am liebsten als Container-Images ausliefern.

Ob ich Anwendungen nun aus n-{DEB,RPM}-Repos, m-Github-Repos oder z-Container-Registries beziehe, macht nach etwas Eingewöhnung keinen großen Unterschied.

Dirk Deimeke am :

*Das ist ein Riesenfortschritt.

Was die SysV-Verfechter verstehen sollten, ist, das systemd kein Programm ist, sondern ein Framework, in dem verschiedene Tools zu finden sind.

Dirk Deimeke am :

*Das denke ich eben auch.

Wenn auf unterster Stufe vielleicht nur eine Kernel-Schnittstelle und glibc als Abhängigkeiten hat, dann kommen wir zu dem, was ich meine.

Wenn man alles, was man benötigt, aus einer Distribution beziehen kann, super. Ansonsten baut man häufig eine Laufzeitumgebung an der Distribution vorbei.

Ob das nun durch Repositories ist, die nicht von der Distribution verwaltet werden oder durch Virtual Environments (Python; NodeJS, Ruby, Go haben das Problem verstanden) oder durch Parallelinformation verschieener Javaversionen (nur ein JAVA_HOME muss gesetzt werden) oder, oder, oder ...

Und genau in den Reigen passen dann auch Containertechniken.

Matthias am :

*Das lustige ist, dass in wirklich sicherheitskritischen Bereichen (KRITIS Sektor) der Einsatz von Docker problemlos genehmigt wird, während ich bei einer einfachen VM entweder sehr lang warten muss, oder so viel security overhead dazubuchen muss, dass die kleinste AWS oder Azure VM ca. 500 EUR / Monat kostet. Kein Witz.

Dirk Deimeke am :

*Bei uns ist es genau umgekehrt.

Applikationen auf einer VM müssen keinerlei Vorgaben erfüllen. Applikationen unter Docker haben einen Security-Overhead, der seinesgleichen sucht.

VMs unter Azure folgen bei uns den gleichen Regeln wie VMs intern. Wir haben einfach keine Public IPs, so dass die VMs nicht aus dem Internet erreichbar sind.

Kommentar schreiben

Gravatar, Favatar, Pavatar, Identica, Twitter, MyBlogLog Autoren-Bilder werden unterstützt.
BBCode-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
:'(  :-)  :-|  :-O  :-(  8-)  :-D  :-P  ;-) 
Formular-Optionen