Rolle von Linux Distributionen
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 Eigenentwicklungen 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 Distribution" bereitgestellt wird. Applikationen kommen mehr und mehr in Distribution-ü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 bereitgestellt 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.
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
tux. am :
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 :
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 :
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 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 :
In der Regel hängen Container usw. aber nicht direkt am Paketmanager deines Systems. Darauf bezieht sich das.
Dirk Deimeke am :
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 :
Dirk Deimeke am :
Vor allem, wenn man das vereinheitlichen könnte.
tux. am :
Dirk Deimeke am :
Jörg am :
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 :
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 :
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 :
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 :
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 :
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 :
https://archive.fosdem.org/2020/schedule/event/riek_kubernetes/
Dirk Deimeke am :
Jörg am :
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 :
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 :
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 :
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 :
Dirk Deimeke am :
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.