Dirks Logbuch

Hallo Dirk,

von mir gibt es ganz klar eine Empfehlung für Plan D. Zumindest um es einfach mal zu versuchen. Hintergrund ist nämlich, dass ich genau in einer ähnlichen Situation bin/war wie du und dieses Setup nun seit einigen Jahren sehr zufrieden betreibe.

Als Desktop setze ich auch auf Fedora Workstation (sowohl beruflich als auch privat), daher ist es für mich die wartungsärmste Lösung auch auf den meisten meiner Server Fedora einzusetzen. Ich weiß einfach, was mich erwartet. Ich kenne die Versionen. Kenne den Update Zyklus, etc. Ich habe gemerkt, wenn man das gleiche OS auf dem Server wie auf dem Desktop einsetzt, wirkt alles deutlich harmonischer. Die Versionen sind gleich. Curl wurde mit den gleichen Optionen kompiliert, OpenSSL ist in der gleichen Version vorhanden, ... Es sind diese Kleinigkeiten, die mir als Admin das Leben indirekt einfach leichter machen. Ich kann daher nur wärmstens empfehlen, das einfach mal zu testen. Die Erfahrung ist es wert.

Ein Release Upgrade mache ich einmal im Jahr. Das ist für mich absolut ok. Meist sogar schon relativ zeitnah nach einem neuen Release. Wenn schon das Upgrade auf den Deskop Systemen (habe mehrere) problemlos funktioniert hat, was es bei Fedora sogar in Vergangenheit immer getan hat (im Gegensatz zu Ubuntu oder Centos, was ja gar keinen Upgrade Pfad bereit stellt), dann habe ich da auch bei meinen Servern wenig Sorge.

Software kommt meist auf dem Fedora Repo. Zumindest das klassische wie postfix, nginx, mariadb etc. Nur für wenige Pakete setze ich Fremdquellen ein. PostgreSQL, weil ich dort während eines Upgrades keine Versionssprünge möchte, die mache ich manuell. Bareos als Backup Tool (was ich selbst kompiliere und als eigenes Repo betreibe). Ebenso Zabbix, was ich auch selbst kompiliere.

Daher ich bin sehr zufrieden mit Fedora in der Server Variante. Ich hatte früher auch mehr CentOS im Einsatz, war aber nie wirklich glücklich damit. CentOS ist zwar ein RHEL Klon, aber halt doch kein RHEL. Es fehlen einfach ein paar Sachen. Updates kommen später. Es gibt keine security advisory (a la yum update --security), es gibt Bugs, die RHEL nicht hat. Fedora ist für mich deutlich näher an RHEL (was ich sehr schätze von der Qualität her) als CentOS. So blöd es auch klingen mag. Es kommt aber aus dem gleichen Haus und man merkt einfach deutlich, dass an Fedora die gleichen Leute arbeiten wie an RHEL. Daher stimmt da vermutlich einfach auch die Qualität.

Gruß
Paul

Es ist ja auch manchmal einfach die Neugierde mal was Neues auszuprobieren, die uns antreibt .

Ich kann es aber gut nachvollziehen, dass man sich dies in Ruhe überlegen muss. Auch bei mir es der Mailserver, der die wichtigste Rolle einnimmt. Daher lege ich da besonderen Wert auf Stabilität und Qualität. Andere Systeme sind mir zwar auch wichtig (Gitlab, Nextcloud, Wiki, ...), aber das sind aktiv genutzte Systeme. Die sind wichtig, wenn ich sie aktiv nutze. Daher lässt sich dort auch einfacher mal was ausprobieren (z.B. in Kubernetes). Der Mailserver muss 24/7 laufen, auch wenn man nicht aktiv etwas macht, sollen Mails ankommen. Gerade das war ein Grund gewesen, auf Fedora zu setzen. Denn einem System, was ich jeden Tag einsetze, vertraue ich auch. So sehr ich Kubernetes/Docker mag, bei einem Mailserver kommt es bei mir z.B. nicht ins Haus. Ich möchte da keine zusätzlichen Layer haben, die das Setup unnötig kompliziert machen und im Zweifel das Debugging erschweren.

Es ist bei mir daher auch eine recht klassische Umgebung (Postfix, Dovecot, MariaDB, Amavisd, Spamassassin, Roundcube). Die läuft mit Fedora wunderbar, weil es keine Fremdquellen benötigt (Roundcube kommt von Upstream, aber das ist ok).

Ursprünglich lief der Mailserver mit CentOS 7. Am Anfang war das auch noch völlig ok als die Software noch einigermaßen aktuell war. Mit der Zeit fingen dann aber so langsam die Probleme an. PHP 7 war da und die Performance Gewinne wollte man ja schon mitnehmen. Mit den SCLO Pakete ging das ja sogar noch einigermaßen. Wirklich toll hat sich das aber nie angefühlt. Komplett externe Quellen wollte ich nicht einsetzen, dann hätte ich mir das LTS Konzept auch gleich sparen können. Das Hauptproblem kam dann aber mit dem Fehlen von TLSv1.3 (aufgrund der alten OpenSSL Version) und so eine Kernkomponente tauscht man nicht einfach mal so aus. Selbst als TLSv1.3 dann stabil wurde, war CentOS 8 (auch RHEL8) noch gar nicht in Aussicht. Das war dann der Punkt, bei dem ich wusste, auf Dauer wirst du mit CentOS nicht glücklich. Unsere Branche ist so schnelllebig, da hat man früher oder später immer wieder die Situation, dass man updaten möchte, aber es nicht kann, weil das OS da nicht mitspielt. Das war der Zeitpunkt, an dem ich dann auch bei meinem Mailserver auf Fedora gewechselt bin (andere Systeme liefen dann vorher schon mit Fedora, aber die hatten noch nicht diesen hohen Stellenwert).

Mittlerweile gibt es ja auch CentOS-Stream, was aktuellere Pakete verspricht. Hast du das mal in Erwägung gezogen? Ich hatte mal kurz drüber nachgedacht, aber aktuelle Pakete habe ich ja jetzt schon bei Fedora und CentOS-Stream geht ja mehr in die Rolling Release Ecke. Da ist mir dann ein festes Release wie bei Fedora dann doch etwas lieber.

Ansonsten hat ja CentOS die Update Problematik mittlerweile auch behoben und liefert wieder. Die scheinen ihre internen Systeme komplett umgestellt zu haben. Für mich hat das aber immer noch einen faden Beigeschmack und bin ganz froh, nicht mehr komplett abhängig zu sein von diesem (Community) Projekt. Ok, mit Fedora habe ich auch eine gewisse Abhängigkeit, aber Fedora hat mich dafür bis her noch nie so enttäuscht . Und selbst wenn. Wenn man nicht nicht so sehr auf eine alte LTS angewiesen ist, findet man schneller wieder ein neues Zuhause.

Das Updateproblem mit CentOS 8 war ziemlich bescheiden, ja.

Das betrifft in ähnlicher Form aber auch CentOS 7 und zwar jedes Mail, wenn RH ein neues Servicepack herausbringt. Dann dauert es, bis die CentOS- Kollegen wieder Security- Updates liefern können.

Für relevante Sachen würde ich also in der Tat kein CentOS einsetzen.

Für Server würde ich RHEL einsetzen, wenn es was kosten darf.
Sonst (nach pers. Priorität sortiert) Debian, Ubuntu, OL, Opensuse Leap.

Viele Grüße
Ulf

Hallo Dirk,

ich stelle mir seit zwei Wochen genau die selbe Frage. Meine Desktops sind Fedora-WS und das seit Core 3. Also schon eine kleine Ewigkeit. Bei mir laufen drei CentOS7 Server sehr problemfrei nativ auf verschiedener Hardware. Einer ist der Firmenserver für meinen Vater, einer ist mein Homeserver (beide mit LAMP, Nextcloud, Samba, Postfix, dovecot-IMAP, minidlna, TFTP und NFS) und der andere ist ein guter alter HP Microserver N54L als Spiel-Hardware. Oft "schmerzt" mir vor allem PHP bzw. der Nextcloud. Mittlerweile nehme ich die PHP-Pakete aus den SCL.
Ich habe mir die Update-Verzögerung von CentOS8 gar nicht so zu Herzen genommen, da auf den Mailinglisten später erklärt wurde warum das alles so lange dauerte. Das kleine Team dort gibt schon mächtig Gas aber manches ist halt sehr aufwendig.
Ich wollte eigentlich jetzt bald auf CentOS 8.1.1911 umsteigen.
Nun überlege ich doch seit einiger Zeit hin und her und schwanke eigentlich mehr zwischen Fedora-Server oder Debian. Manchmal ist LTS gar nicht so gut, da man u.U. lange sehr alte Software hat oder für aktuellere "basteln" muss (Dritt-Repos o.ä). Je nach dem können kurze Releasezyklen zu weniger Nacharbeit führen, da dann die Versionssprünge auf einen Schlag oft nicht so groß sind. Der Sprung von PHP wäre bei CentOS 7->8 z.B. regulär von 5.4 auf 7.2.
Es werden durch die Aktualität von Fedora ggf. dann gleich auch Bugs beseitigt oder Features hinzugefügt, wie es das mit einem LTS so einfach nicht geben würde. Debian ist da an manchen Ecken schon mal etwas träger.

Fedora: weil ich es seit Urzeiten auf dem Desktop kenne, es nahezu immer brandaktuell ist und bei mir seit jeher super läuft.
Debian: weil es zwar nicht so aktuell ist aber aktuell genug und von den Releasezyklen genau zwischen Fedora und CentOS liegt. Debian hat ja ca. alle zwei Jahre ein Majorrelease.
Momentan schlägt das Pendel mehr Richtung Debian. Da habe ich auch beruflich sehr gute Erfahrung mit. Stabil laufen sie meiner Erfahrung nach alle gleich gut.

Berichte bitte mal für was Du dich letzlich entschieden hast und wenn Du magst auch warum.
Wäre das für dich dann nicht ein Thema für einen Vortrag für die ORR2020? Warum Short-Term manchmal besser als Long-Term sein kann? Ist bestimmt für einige User im privaten Bereich interessant. Sollte die ORR dieses Jahr stattfinden würdest du doch bestimmt wieder dorthin kommen, oder?

"Es wäre ein Irrtum zu denken, dass es alle zwei Jahre ein neues Debian-Release gibt. Ein neues Release ist fertig, wenn es fertig ist. Es hat auch schon drei Jahre oder auch nur eines gedauert bis ein neues Release fertig war. "
Das weiß ich natürlich. Deswegen schrieb ich ja "ca."

Jetzt wo ich den Vortrag sehe: Den kenne ich sogar.
Danke Dir.

Hallo Dirk,

gern gebe ich ebenfalls meine Meinung zum Besten.

Wie Paul sehe ich Vorteile durch Synergieeffekte bei Nutzung der gleichen Distribution auf Server und Desktop.

Beruflich setzen wir in Sachen Linux bei uns im Hochschulrechenzentrum auf Red Hat Enterprise Linux. Ich/Wir sind grundsätzlich zufrieden damit. Zwar gibt es immer mal wieder Kritik, diese richtet sich jedoch meist gegen Linux als Betriebssystem und weniger gegen die gewählte Distribution.

Und ich nutze im Büro tatsächlich einen "RHEL 7 Server with GUI" aus einer Red Hat Developer Subscription als Arbeitsplatzrechner. Es gibt sicherlich schönere bzw. besser geeignete Distributionen für den Desktop, jedoch zählen für mich die von Paul angeführten Synergieeffekte durch die gleichen Versionen bei Programmen und Bibliotheken.

Privat nutze ich auf Server und Desktop mittlerweile Debain, nachdem ich mich vor einiger Zeitlange mit der Wahl herumgequält habe.

Ich betreibe zusammen mit zwei ehemaligen Kollegen einen Root-Server. Wir haben uns auf Debian (stable) als Betriebssystem geeinigt. Für mich spricht für Debian, dass es historisch gute und stabile Upgrade-Pfade auf die nächste Version bietet. Während wir im Rechenzentrum einfach neue virtuelle Server provisionieren, Dienste migrieren und die alten VMs deprovisionieren, haben wir halt nur einen Root-Server im Netz und wollen nicht jedes Mal, wenn es eine neue Version der Distribution gibt, einen weiteren Server anmieten. Daher haben wir der Wahl einer Distribution mit stabilen und erprobten In-Place-Upgrades einiges an Gewicht beigemessen.

Vor Debian haben wir einige Jahre Ubuntu LTS betrieben. Hier stellten sich nach den Distributions-Upgrades jedoch vermehrt Nacharbeiten bei den Diensten ein. Inzwischen installiere ich ein Ubuntu lieber neu, als es auf die nächste Version zu aktualisieren. Das macht bei nur einem Server nur bedingt Spaß.

Daheim nutze ich ebenfalls Debian (stable). Eben wegen der Synergieeffekte. Darüber hinaus möchte ich den Kontakt zur Debian-Gemeinschaft auf diesem Wege aufrecht erhalten. Nicht zuletzt kann ich so Privat- (Debian) und Berufsleben (RHEL) ganz gut voneinander trennen. Dies hilf mir Probleme aus dem Büro nicht mit nach Hause zu nehmen.

Du hast in deinem Artikel geschrieben, dass ihr auf der Arbeit RHEL mach(en müss)t. Was hältst du denn grundsätzlich davon?

Viele Grüße
Jörg

Meine Erfahrungen mit dem Red Hat Support sind bisher überwiegend positiv. Wobei wir ausschließlich RHEL einsetzen. Also kein OpenShift, kein Ansible Tower und kein Satellite, etc.

Das der Satellite ein Thema für sich ist, habe ich jedoch schon aus mehreren Runden gehört. Jemand riet mir sogar dazu ihn nicht ohne externe Beratung einzurichten. Ich könnte sonst zu schnell abgeschreckt werden. Daher habe ich Spiegelserver und Patchmanagement mit zwei selbstgestrickten Projekten gelöst, die zumindest unsere Anforderungen gut abdecken.

Über die Stellenanteile, mit denen wir Linux betreiben, mag ich hier nicht schreiben. Wir können uns dazu jedoch gern auf den diesjährigen Chemnitzer Linux Tagen austauschen.

Hallo Dirk,

tatsächlich haben wir (noch) keine Campus Wide Subscription, da die Anzahl unserer Systeme und der Anteil vom Red Hat Portfolio, den wir nutzen, dafür einfach zu gering ist.

Wir haben einen Mix aus RHEL Standard Subscripions für physische Systeme bzw. 2 VMs und RHEL Standard Datacenter Subscriptions für einen vSphere-Cluster. Wir nutzen wie gesagt aktuell ausschließlich RHEL und keine weiteren Lösungen wie Ansible Tower, Satellite, JBOSS, etc.

RHEL ist meiner Meinung nach eine sehr gut gepflegte Distribution und sehr stabil. Es enthält viele Kleinigkeiten, die es mich anderen Distributionen vorziehen lassen. Darunter z.B. die Transaktionshistorie des Paketmanagers und die Bereitstellung von Advisories, die mir eine gezielte Installation von RHSA, RHBA bzw. RHEA ermöglichen. Nichtsdestotrotz reicht es z.B. an Solaris 10 bzw. 11 in meinen Augen nicht heran.

Mit dem Support bin ich grundsätzlich zufrieden. Gleichzeitig habe ich den Eindruck, dass sich um das Customer Portal kaum jemand kümmert. Da habe ich einen Case, der wird während meines Berufslebens glaube ich nicht mehr bearbeitet.

Ich mag die Community, Philosophie der Firma und die Red Hatter, dich ich bisher persönlich kennengelernt habe. Dies hat mich auch zu den Red Hat Accelerators gebracht.

Daher hoffe ich, dass Red Hat auf Dauer ein "Bluewashing" erspart bleibt.

Darüber hinaus habe ich den Eindruck, dass es Red Hat an manchen Stellen an Personal fehlt. Einzelne Stellen scheinen schwach besetzt und überarbeitet zu sein. Doch ist dies nur mein Eindruck und ich mag mich auch täuschen.

Mit der Entwicklung von Ansible bin ich nicht sehr zufrieden. Mich nerven Änderungen an der Syntax bei Minor-Release-Updates. Soetwas gehört sich in meinen Augen einfach nicht. Red Hat könnte hier in meinen Augen deutlich mehr Einfluss nehmen, um gegenzusteuern. Schließlich engagieren sich etliche Mitarbeiter der Firma in der Ansible-Gemeinschaft und das Projekt macht einen Teil des Portfolios aus, der enormes Wachstumspotenzial hat.

In deinem Artikel und in den Kommentaren hier wurde auch über den Einsatz von Webtechnologien gesprochen. Ich persönlich empfand Pakete wie Tomcat, PHP{-FPM} oder NGINX aus den Quellen einer Distribution fast immer als zu alt. Allerdings kann ich gut damit leben in diesen Fällen mit Upstream-Repos zu arbeiten. Falls ich kommerziellen Support benötige, gibt es heute durchaus eine Auswahl an Unternehmen, wo man diesen zukaufen kann.

Viele Grüße
Jörg

Guten Morgen,

zum Theme Repo-Mirroring empfehle ich dir, dich am 15.02.2020 um 11:00 Uhr im Raum V6 einzufinden. ;-P

Natürlich freue ich mich, dich in meinem Vortrag begrüßen zu können, doch möchte ich dich nicht so lange auf die Folter spannen. Nach einer Anforderungsbestimmung, habe ich eine Lösung mit RHEL-Bordmitteln gebaut. Diese habe ich auf meiner Seite in "RHEL Spiegelserver für arme Admins" beschrieben.

Bezüglich des nicht bearbeiteten Support-Case. Es handelt sich dabei um einen RFE, der für mich nicht Kriegsentscheidend ist. Darum bin ich da etwas nachsichtiger. An Themen die mir wichtig sind, wurde bisher mit Nachdruck gearbeitet und die Sachlage geklärt. Das heißt nicht, dass es jedes Mal eine schnelle Lösung für unser Problem gab. Allerdings sind wir auch kein strategischer Kunde.

Ich betreibe oder betreue noch eine ganze Menge Hard- und Software anderer Hersteller und kenne auch deren Support-Leistungen. Verglichen mit diesen, schätze ich den Red Hat Support noch als einen der besseren ein. Bei den übrigen fühle ich mich teilweise einfach verlassen.

Lieben Gruß aus Bielefeld
Jörg

Unsere Systeme basieren auf der RHEL-Minimalinstallation. Da fast alle unsere Hosts vSphere-VMs sind, habe ich eine RHEL-Minimalinstallation als vSphere Template abgelegt. Nach der Provisionierung aus dem Template, wird die Instanziierung und Aktualisierung von Ansible abgeschlossen.

Da wir nur sehr wenige physische Installation haben, führe ich diese per Hand von einem Boot-Medium durch (Minimalinstallation) und konfiguriere sie anschließend mit Ansible durch.

Wir haben aktuell tatsächlich die gleichen Paketversionen in all unseren Stages der RHEL-Repos. Es existiert hier für uns aktuell kein Grund dies feingranular zu steuern. Lediglich in den Stage-Repos, die unsere eigenen Pakete enthalten, transportieren wir diese gestaffelt nach Teststufen durch die Stages.

Bezüglich deiner Support-Erfahrung kann ich dir nur voll und ganz zustimmen.

Ja, eine Bank hat da sicherlich und hoffentlich noch ganz andere Anforderungen als eine Universität.

Die von dir beschriebenen Anforderungen kann mein armer Spiegelserver nicht so einfach umsetzen. Doch dafür ist er auch nicht gemacht.

Eine Verzögerung beim Transport durch Stages ist häufig ja sinnvoll. Wir können aufgrund unseres Patchmanagements darauf verzichten, da wir die Stages dort nach Phasen gestaffelt patchen und neustarten. Auch dieses wird sicher nicht ganz an eure Anforderungen heranreichen, falls es dich dennoch interessiert, darfs du hier einen Blick riskieren: Ansible: Patch-Management für Red Hat Systeme

Auch dazu werde ich auf den CLT2020 etwas erzählen.

Stimmt, dann kannst du die Zeit nuten, einen der vielen anderen interessanten Vorträge zu hören und mir anschließend darüber berichten.

Nur gut, dass wir uns hier bereits so ausführlich über meinen Vortrag unterhalten haben. Jetzt wo die Chemnitzer Linux-Tage ausgefallen sind, hättest du noch nicht mal die Chance gehabt ihn zu besuchen.

Mal schauen, ob in diesem Jahr die Open Rhein Ruhr und der Linux Day AT stattfinden. Dann reiche ich den Vortrag dort auch noch ein.

Viele Grüße
Jörg

Interessanter Beitrag.
Raspberry wäre auch eine interessante Alternative?