In den letzten Tagen dreht sich meine Internet-Blase zu einem großen Teil rund um das nahende Ende von CentOS-Linux. Um nicht in mehreren Blogs die gleichen oder ähnliche Kommentare zu hinterlassen, habe ich mich entschieden, in diesem einen Artikel meinen Senf dazu zugeben.
Aus Transparenzgründen weise ich ausdrücklich darauf hin, dass ich Mitglied der Red Hat Accelerators bin (siehe „Zu meiner Person„). Meine Meinung ist jedoch grundsätzlich meine eigene. Diese kann mit den Ansichten von Red Hat übereinstimmen, muss es aber nicht und tut es auch nicht immer.
Die Meldungen, dass das Ende von CentOS Linux naht, haben mich weder überrascht, noch enttäuscht. Überrascht bin ich nicht, da ich mich schon bei der Ankündigung von CentOS Stream gefragt habe, wie lange beide Projekte parallel existieren können bzw. wann Red Hat die Unterstützung des einen Projekts zu Gunsten des anderen beendet. Und um enttäuscht zu sein, habe ich CentOS nicht lange genug verwendet und mich nicht in der Gemeinschaft organisiert. Freuen tut es mich allerdings auch nicht, wenn ein so robustes Projekt ein Ende hat.
Ziemlich unglücklich fand ich die Kommunikation durch Red Hat. Dabei ist denke ich mehr Porzellan kaputt gegangen, als nötig war. So ist es wenig verwunderlich, dass die CentOS-Community aufgebracht ist und sich in den Kommentarspalten in Rage schreibt.
So ist die Rede davon, dass Red Hat auf Weisung von IBM bei CentOS das Licht ausgemacht hat; dass CentOS auf dem Altar der Kommerzialisierung geopfert wird, um die Profite von Red Hat und IBM zu steigern. Ja, man könnte fast meinen, die Welt geht unter. Ich finde, das ist alles Quatsch.
Zumal ich nicht glaube, dass Nutzer des kostenlosen CentOS jetzt alle RHEL-Subkriptionen kaufen werden. Für viel wahrscheinlicher halte ich es, dass sich diese Nutzer den zukünftigen kostenlosen RHEL-Klonen zuwenden oder zu anderen kostenlosen Linux-Distributionen wechseln werden.
In meiner Wahrnehmung hat Red Hat bisher seine Eigenständigkeit nach dem Kauf durch IBM behalten. Ob IBM etwas mit der Entscheidung zu tun hatte, weiß ich nicht. Glauben tue ich es jedenfalls nicht. Letztendlich hat das CentOS-Projekt im hauseigenen Blog bekannt gegeben, den Fokus auf CentOS Stream zu verlagern. Übrigens sind nur 4 von 10 Sitzen im CentOS Governing Board von Red Hattern besetzt.
Etliche Kommentare hinterlassen bei mir den Eindruck, die dazugehörigen Autoren würden glauben, sie hätten ein Recht auf kostenlose Software der Enterprise-Klasse. Dabei beinhaltet Open Source nach meinem Verständnis die Freiheit der Quelltexte und das Recht, aus diesen ausführbare Programme zu erstellen. Eine Pflicht, dass ein Unternehmen für den ganzen Spaß bezahlt und diese Aufgabe für mich übernimmt, kann ich hingegen nicht daraus ableiten. Von daher kann ich die Empörung nur teilweise nachvollziehen.
Dabei ist die Binärkompatibilität von CentOS, Oracle Linux, CloudLinux OS, Centos Stream und evtl. bald Rocky Linux zu RHEL doch auch ein Vorteil. Sollten sich Anwendungen, die auf einer dieser Distributionen laufen, sich doch selbst im Binärformat ohne großen Aufwand auf die jeweils anderen übertragen lassen. Ganz ehrlich, einen Wechsel von Debian zu OpenSUSE stelle ich mich schwieriger vor.
In meinen Augen stehen ausreichend gute und stabile Alternativen für Menschen zur Verfügung, die es sich nicht leisten können, für Enterprise-Software zu bezahlen.
Also CentOS, mach es gut. Es war schön mit dir. Mit deinen Nachfolgern wird es sicherlich auch wieder viel zu erleben geben.
Vorwarnung: Dieser Artikel wird euch vermutlich nicht interessieren, wenn ihr nicht zufällig die gleichen Anforderungen an eine Linux-Distribution für den Desktop stellt wie ich. Mir selbst dient dieser Beitrag als Sammlung von Informationen und zum Vergleich von Distributionen, um schlussendlich eine neue Distribution für meinen Desktop-PC und meine beiden Notebooks auszuwählen. Falls euch langweilig ist oder ihr neugierig seid, dürft ihr natürlich gerne weiter lesen. ;-)
Updatevom 10.02.2020 TL;DR: Ich habe mich nach dem LinuxDay AT 2019 für Debian 10 (Buster) entschieden.
Umfeld
Auf meinen privaten Geräten läuft seit 2006 Ubuntu. Die Geräte haben dabei selten eine Neuinstallation erlebt, sondern wurden meist per Distribution-Upgrade auf eine neue Release aktualisiert. Leider klappt letzteres in jüngerer Vergangenheit zunehmend schlechter und unzuverlässiger. Eine Neuinstallation ist inzwischen einem Upgrade vorzuziehen, da sie meist schneller durchgeführt ist und weniger Nacharbeiten nach sich zieht.
Neben den zunehmenden Problemen mit dem Distribution-Upgrade hat mir Canonical in der jüngeren Vergangenheit ein wenig zu viel an meiner Lieblingsdistribution herumgepfuscht bzw. sie ver(schlimm)bessert. Dies ist der Auslöser, mir mal eine Alternative für den Desktop-Einsatz zu suchen.
Bei meinen Geräten handelt es sich um einen älteren Desktop-PC und zwei ThinkPads (T410 und X201). Dazu gesellt sich in der Peripherie noch ein Brother DCP-540CN, ein Synology DS213air. Alle Komponenten sind in das WLAN-Heimnetzwerk eingebunden. Die Hardware ist alt, doch funktioniert sie noch tadellos und erfüllt ihren Zweck. Daher möchte ich sie gerne noch einige Jahre weiter nutzen.
Anforderungen
Beruflich bin ich im BITS, dem Hochschulrechenzentrum der Uni Bielefeld, tätig und betreue dort diverse IT-Dienste und Themen. Da ich also bereits einen sehr großen Teil des Tages mit der Wartung, Pflege, Entstörung und (sofern noch Zeit ist) der Weiterentwicklung dieser Dienste verbringe, möchte ich mich daheim so wenig wie möglich mit diesen Tätigkeiten aufhalten. Die regelmäßige Installation von Sicherheits-Aktualisierungen ist obligatorisch, doch auf lange Fehlersuche und Behebung möchte ich daheim gerne verzichten.
Bei mir gilt Stabilität vor Bleeding Edge. Ich benötige nicht ständig neue Funktionen und die aktuellste Upstream-Version. Wenn eine Anwendung meine Anforderungen erfüllt und mit Sicherheits-Aktualisierungen versorgt wird, reicht mir das völlig aus.
Aktuell bieten mir die unter Ubuntu 16.04 LTS verfügbaren Anwendungen die Funktionalität, die ich benötige. Die auszuwählende Distribution sollte die entsprechenden Versionen in gleicher oder aktuellerer Version bereitstellen können. Sollte nur eine ältere Version einer Anwendung verfügbar sein, ist dies nicht automatisch ein Ausschlusskriterium. In diesem Fall ist die Anwendung zu testen, ob sie meinen Anforderungen genügt.
Ich wünsche mir einen möglichst großen Unterstützungszeitraum. Ubuntu bietet in den Versionen mit Long Term Support eine Unterstützung für 5 Jahre an. Damit bin ich bisher ganz gut gefahren und möchte mich deshalb in diesem Punkt nur ungern verschlechtern.
Bewertungskriterien
Wie ihr oben gelesen habt, habe ich keine knallharten und messbaren Anforderungen definiert, sondern lediglich Punkte genannt, die mir wichtig sind. In den folgenden Abschnitten werde ich mir eine Auswahl von Linux-Distributionen etwas näher ansehen und diese zuerst auf dem Papier und anhand meiner Erfahrungen miteinander vergleichen. Dabei bewerte ich folgende Kriterien:
Release-Zyklus
Support-/Life-Cycle
Paketverfügbarkeit und Versionsstand
Community
Für vorstehend genannte Kriterien vergebe ich Punkte nach folgender Tabelle. Dabei gehen alle Kriterien mit gleicher Gewichtung in das Endergebnis ein, sodass die Distribution mit den meisten Punkten am besten zu mir passen sollte.
Punkte
Beschreibung
0
gefällt mir/funktioniert sehr schlecht
1
gefällt mir/funktioniert schlecht
2
Ist in Ordnung
3
gefällt mir/funktioniert gut
4
gefällt mir/funktioniert sehr gut
Als Referenz dient mir Xenial, für welches meine Bewertungstabelle wie folgt aussieht:
Anmerkung: Bitte beachtet, dass dies hier eine sehr vereinfachte Form einer Bewertungstabelle für meinen privaten Zeitvertreib ist. Als Entscheidungstabelle für die Arbeit ist dieses Format ganz sicher nicht geeignet.
Ausgewählte Distributionen im Vergleich
Für den hier stattfindenden Vergleich habe ich mir folgende Distributionen angesehen (alphabetisch sortiert). Warum genau diese? Nun, entweder kenne ich sie schon oder sie wurden mir von Arbeitskollegen empfohlen.
Antergos
Arch Linux
CentOS
Debian
Fedora
Ubuntu
Antergos
Antergos basiert auf Arch Linux und folgt dem Rolling-Release-Prinzip. Ich möchte kein Rolling Release nutzen. Daher hört die Bewertung hier schon auf, da Antergos für mich nicht in Frage kommt.
CentOS wird aus den Quellen von Red Hat Enterprise Linux gebaut, zu welchem es binärkompatibel ist. CentOS ist nach eigenen Angaben ein Enterprise-Betriebssystem, welches mit langen Wartungszyklen aufwartet. So kann ein Release bis zu zehn Jahre genutzt werden, ohne dass Softwareversionen migriert werden müssen.
Zehn Jahre lang Ruhe. Das klingt verlockend. Grund genug, sich das aktuelle CentOS 7 auf dem Papier anzuschauen.
CentOS 7
Name
Wert
Bewertung
Unterstützungszeitraum
10 Jahre bis Juni 2024
4
Release-Zyklus
Alle 3-4 Jahre
3
Community
Forum und Mailingliste
2
Kernel
3.10.0
2
systemd
219
2
gnome-shell
3.28.3
3
Vim
7.4
2
Firefox
60.6.1
3
Thunderbird
60.6.1
3
Evolution
3.28.5
2
gThumb
3.3.4
2
Evince
3.28.2
2
Kile
2.1.3
3
TeXlive
2012
1
XSane
0.999
4
Summe
38
Debian
Debian ist ein von der Gemeinschaft entwickeltes freies Betriebssystem und mein heimlicher Favorit. Mir gefällt die Idee, mich neben einer RPM-basierten Distribution auf der Arbeit,Ubuntu importiert den Großteil seiner Pakete aus Debian Unstable. Für einen Teil dieser Pakete übernimmt nach dem Debian Import Freeze die Firma Canonical die Pflege. Der größte Teil landet hingegen in der Komponente universe, wo er von den MOTU betreut wird (oder gar nicht). Die Folge dieses Vorgehens: Wenn Pakete in Debian Unstable während des Debian Import Freeze kaputt und unbenutzbar sind, werden sie in die Ubuntu-Paketquellen importiert und bleiben mit großer Wahrscheinlichkeit für die Lebensdauer des jeweiligen Releases daheim mit einer DEB-basierten Distribution zu beschäftigen, um in beiden Paketformatwelten auf dem Laufenden zu bleiben.
Debian Stable steht in dem Ruf rock solid zu sein, was meinem Wunsch nach einer sehr stabilen Distribution entgegen kommt. Die Softwarepakete in Debian Stable gelten gemeinhin als sehr gut abgehangen. Kritiker bezeichnen sie auch als hoffnungslos veraltet. So lange sie die von mir gewünschte Funktionalität bieten, ist mir das Alter egal. Falls ich mich für Debian entscheide, werde ich auf die Veröffentlichung von Buster warten, welche mit folgenden Werten aufwartet.
Bei Fedora handelt es sich wiederum um eine RPM-basierte Distribution. Diese wartet mit recht aktuellen Softwarepaketen auf und gibt sich selbst als für Desktops, Workstations, Laptops und Server geeignet. Fedora wird auch gern als Testlabor für RHEL bezeichnet, da viele Entwicklungen, die sich hier etablieren konnten, später in RHEL übernommen werden.
Die Aktualität hat ihren Preis. So kommt Fedora mit recht kurzen Releasezyklen daher, was für mich ganz klar Punktabzug bedeutet.
Basierend auf Debian laufen die Ubuntu LTS Releases seit Jahren auf meinen Rechnern. Da ich mit dieser Distribution die meiste Erfahrung habe und dadurch auch einige ihrer Macken kenne, fällt es mir schwer, bei einer Bewertung neutral zu bleiben. Doch werde ich mir Mühe geben.
Ubuntu importiert den Großteil seiner Pakete aus Debian Unstable. Für einen Teil dieser Pakete übernimmt nach dem Debian Import Freeze die Firma Canonical die Pflege. Der größte Teil landet hingegen in der Komponente universe, wo er von den MOTU betreut wird (oder gar nicht). Die Folge dieses Vorgehens: Wenn Pakete in Debian Unstable während des Debian Import Freeze kaputt und unbenutzbar sind, werden sie in die Ubuntu-Paketquellen importiert und bleiben mit großer Wahrscheinlichkeit für die Lebensdauer des jeweiligen Release kaputt und unbenutzbar. Dieses Vorgehen halte ich persönlich für ganz großen Schwachsinn.
Als einzigartig hingegen empfinde ich die deutschsprachige Community ubuntuusers.de. Auch wenn hier in einigen Themen auch mal die Fetzen fliegen, ist der Umgangston doch überwiegend freundlich. Hier fand ich in der Vergangenheit stets wertvolle Hilfe bei kleinen und auch großen Problemen
Schlussfolgerung und selbstkritische Reflexion des Distributions-Vergleichs
Ubuntu 16.04 LTS
CentOS 7
Debian Buster
Fedora Rawhide
Ubuntu 18.04 LTS
38
38
40
36
37
Sieg nach Punkten für das hoffentlich bald erscheinende Debian Buster!
Dass mein heimlicher Favorit das Rennen gemacht hat, verwundert nicht. Nüchtern und bei Licht betrachtet muss ich gestehen, dass der oben stehende Vergleich Makulatur und nicht objektiv ist. So ist der Vergleich und die Bewertung von Software-/Paket-Versionen nicht geeignet, um zu bestimmen, wie gut meine funktionalen Anforderungen erfüllt werden. Dazu hätte es eines praktischen Tests der einzelnen Versionen bedurft.
So offenbarte ein praktischer Vergleich von kile in Version 2.9.91, dass mir dieses in der Benutzung deutlich schlechter gefällt, als die ältere Version 2.1.3. Und was für kile gilt, mag selbstverständlich auch für andere Anwendungen gelten.
Ein weiterer großer Schwachpunkt des Vergleichs ist der Punkt ‚Community‘. Aus persönlicher Erfahrung kenne ich nur die ubuntuusers.de wirklich gut, weil ich nur hier seit vielen Jahren selbst aktiv bin. Die Bewertung aller anderen Communities und Unterstützungsmöglichkeiten basiert auf deutlich weniger Erfahrungen und Teils sogar nur auf Hörensagen. Eine objektive Bewertung ist so natürlich nicht möglich.
Streng genommen handelt es sich bei dem angestellten Vergleich um Humbug und Mumpitz. Bitte nicht nachmachen!
Mir selbst reicht er jedoch als Indikator, dass das kommende Debian Buster meine Anforderungen daheim gut erfüllen könnte. Es wird daher nach der Veröffentlichung auf einem meiner Geräte installiert und in der Praxis erprobt.
Tja, wenn ich ehrlich bin, ist dieser Artikel wenig hilfreich. Zum Trost sei gesagt, dass er mir half, ein wenig die Zeit bis zum Release von Buster zu überbrücken.
Bei SELinux Booleans handelt es sich um kleine Schalter, mit denen sich das Verhalten der SELinux-Richtlinien beeinflussen lässt. Dieser Artikel knüpft an die „Einführung in das grundlegende Konzept von SELinux“ an und erläutert die Verwendung von SELinux Booleans anhand eines einfachen Beispiels.
Hinweis: Das Beispiel aus diesem Artikel wurde auf einem RHEL/CentOS 7.3 getestet. Unter CentOS 7.2 funktioniert die hier gezeigte Konfiguration nicht. Für Details wird auf das Topic[2. Solved SELinux Booleans and httpd_enable_homedirs] im CentOS-Support-Forum verwiesen.
Nach einem Neustart des Dienstes httpd sollte sich nun die Datei index.html aus dem Benutzerverzeichnis abrufen lassen. Statt dessen wird der Zugriff verweigert.
httpd_enable_homdirs –> off
In den Logdateien finden sich Hinweise, die auf SELinux als Ursache hindeuten.
[root@centos ~]# tail /var/log/audit/audit.log|grep AVC
type=AVC msg=audit(1480446615.354:844): avc: denied { getattr } for pid=23150 comm="httpd" path="/home/jkastning/public_html/index.html" dev="sda1" ino=1052157 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_user_content_t:s0 tclass=file
[root@centos ~]# tail /var/log/messages | grep SELinux
Nov 29 20:10:44 centos setroubleshoot: SELinux is preventing httpd from getattr access on the file /home/jkastning/public_html/index.html. For complete SELinux messages. run sealert -l 13419731-cedd-4433-abb7-b2e7715d5636
Um weitere Informationen zu erhalten, führen wir das Kommando aus /var/log/messages aus (Ausgabe gekürzt):
[root@centos ~]# sealert -l 13419731-cedd-4433-abb7-b2e7715d5636
SELinux is preventing httpd from getattr access on the file /home/jkastning/public_html/index.html.
***** Plugin catchall_boolean (24.7 confidence) suggests ******************
If you want to allow httpd to enable homedirs
Then you must tell SELinux about this by enabling the 'httpd_enable_homedirs' boolean.
You can read 'None' man page for more details.
Do
setsebool -P httpd_enable_homedirs 1
In der obigen Ausgabe wird neben der Ursache auch gleich die Lösung mitgeliefert. Nach der Aktivierung des SELinux Boolean httpd_enable_homedirs kann der Inhalt der Datei index.html im Webbrowser abgerufen werden.
In diesem kurzen Tutorial wird beschrieben, wie man einem normalen Benutzer das Recht einräumt, ein einzelnes Skript mit sudo auszuführen. Das Tutorial ist auf alle Linux-Distributionen anwendbar, welche sudo[1. sudo – Wikipedia] unterstützen.
Schritt 1: Skript und Benutzerkonto erstellen
Zuerst wird natürlich das Skript benötigt, welches der neue Benutzer später ausführen soll. Als Beispiel mag hier folgendes einfaches Beispiel dienen:
#!/bin/bash
echo "Hallo Welt."
Wichtig! Der Benutzer, welcher das Skript später ausführen soll, darf selbst keine Schreibrechte darauf besitzen. Andernfalls könnte er das Skript bearbeiten und durch eintragen von bash eine root-shell öffnen. Danke an Gerald für diesen wichtigen Hinweis.
Der Benutzer kann, sofern er nicht schon existiert, mit folgendem Kommando angelegt werden:
sudo adduser USERNAME
Schritt 2: /etc/sudoers konfigurieren
Um einem Benutzer das Recht zu verleihen, gibt es grundsätzlich mehrere Möglichkeiten.
Benutzer einer Gruppe hinzufügen
Auf vielen Linux-Distributionen existiert bereits eine Gruppe, deren Mitglieder die Berechtigung zur Verwendung von sudo besitzen. Unter Ubuntu ist dies z.B. die Gruppe ’sudo‘. Unter RHEL, CentOS und Fedora ist dies bspw. die Gruppe ‚wheel‘. Um welche Gruppe es sich konkret handelt, kann in der Datei /etc/sudoers nachgeschlagen werden. Dort findet sich auf einem Ubuntu 16.04 LTS z.B. folgender Eintrag:
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
Da dem Benutzer im hier beschriebenen Fall jedoch nur erlaubt werden soll, ein einziges Skript mittels sudo auszuführen, ist diese Methode ungeeignet.
Benutzer in /etc/sudoers
Um einem Benutzer das Recht zu gewähren, ein bestimmtes Skript oder Programm mit sudo auszuführen, kann der Benutzer wie folgt in die Datei /etc/sudoers eingetragen werden.
Wichtig! Die Datei /etc/sudoers sollte nur als root mit dem Kommando visudo editiert werden, da hiermit eine Syntaxprüfung erfolgt. Eine Beschädigung der Datei /etc/sudoers, z.B. durch Syntaxfehler, kann dazu führen, dass das gesamte System unbrauchbar wird.
# User privilege specification
USERNAME ALL=/path/to/script.sh
Mit obiger Zeile wird dem Benutzer ‚USERNAME‘ erlaubt, das Skript unter /path/to/script.sh mit sudo auszuführen.
Diese Methode ist bereits geeignet, um die gestellte Aufgabe zu lösen.
Datei unter /etc/sudoers.d/ erstellen
Unter aktuellen Versionen von Debian, Ubuntu, RHEL, CentOS und Fedora besteht die Möglichkeit, eine Datei im Verzeichnis /etc/sudoers.d/ zu erstellen, welche den Eintrag aus dem vorangegangenen Abschnitt enthält. Voraussetzung dafür ist, dass die Datei /etc/sudoers folgende Direktive enthält:
# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.d
Beachte: Das Zeichen ‚#‘ vor ‚includedir‘ stellt in diesem Fall kein Kommentarzeichen dar.
Diese Methode hat den Vorteil, dass die Datei /etc/sudoers unverändert bleibt und es bei Updates nicht zu einem Versionskonflikt kommen kann.
Fazit
Mittels /etc/sudoers ist es möglich, sudo-Berechtigungen granular an Benutzer zu delegieren. Neben dem in diesem Tutorial beschriebenen Beispiel existieren noch weitere Möglichkeiten. Beispiele dazu finden sich in der Manpage von sudoers.
