Skip to content

Server OS LifeCycle

linux

Meine Server laufen seit etwa fünf Jahren unter CentOS 7. In der Zeit gab es ordentlich Updates und tatsächlich keine Probleme, die auf der Software basierten.

Eigentlich läge damit CentOS 8 als neues Betriebssystem für die Server nahe. Allerdings schreibt schon Michael Kofler, dass CentOS 8 über sechs Wochen ohne Updates war und wirft Oracle Linux in die Waagschale.

Das hört sich auf den ersten und zweiten Blick komisch an, ist es auch. Aber Oracle bietet sein Linux als FLOSS-Lösung an, die gratis ist, solange man kein System hat, bei dem man für den Support durch Oracle bezahlt. In dem Fall werden alle Instanzen kostenpflichtig. Komisches Modell, oder?

Nebenbei: Ich nutze sehr gerne VirtualBox, ebenfalls von Oracle, da muss man aufpassen, dass sich die Lizenzbestimmungen mit der Nutzung des Extension Packs ändern.

Also, was tun?

Der Vorteil von CentOS war und ist, dass es sehr lange (rund zehn Jahre) unterstützt wird und tatsächlich bin ich auch noch nicht in der Not zu wechseln. Der Support für CentOS 7 läuft erst am 30. Juni 2024 (Tabelle) aus, also erst in viereinhalb Jahren. Der Nachteil ist, dass CentOS über die Lebenszeit garantiert, API-kompatibel zu bleiben, was zum Teil in sehr alter Software resultiert (Tabelle bei DistroWatch. Das wiederum bedeutet, dass man reichlich Fremdrepositories verwenden muss - bei mir EPEL, die Remi-Repostitories für PHP und Repos für MariaDB - um halbwegs aktuelle Webanwendungen betreiben zu können. Das Web ist voll von Fragen, wie man eine bestimmte Software unter CentOS zum Laufen bekommt.

Also Plan A ist, bei CentOS zu bleiben. Die "Synergien" zwischen dem, was ich beruflich mache(n muss), nämlich Red Hat Enterprise Linux zu betreiben, und dem, was ich dann privat mache, sind schon sehr gross. Bedingung dafür wäre, dass es regelmässiger Updates gibt.

Plan B wäre, die Distribution zu wechseln, hier bieten sich quasi sofort Ubuntu und Debian an, wobei ich im Fall eines Wechsels zu Debian tendieren würde.

Es gibt natürlich noch einen Plan C, das wäre ein Docker (bzw. Podman) basiertes Setup. Mich würde sehr reizen, das mit Alpine Linux als Basis zu versuchen. Eine Alternative könnte sogar Fedora Core OS sein.

Kein Plan D, aber eine interessante Alternative könnte tatsächlich Fedora in der Server-Variante sein. Allerdings sind die Wechsel zwischen den halbjährlichen Releases schon sehr drastisch und bedürfen der ständigen Nacharbeit (vermute ich). Fedora auf dem Desktop ist super (langweilig), das funktioniert einfach richtig gut, selbst mit aktiviertem SELinux sind keine Nacharbeiten nötig.

Jetzt Ihr. Was wären Eure Empfehlungen? Viel wichtiger als "was" wäre mir das "warum" Ihr ein bestimmtes Server-OS empfehlt. FreeBSD oder OpenBSD wären auch noch nachdenkenswerte Varianten.

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Paul am :

*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

Dirk Deimeke am :

*Wow! Vielen Dank für Deinen ausführlichen Kommentar!

Ich muss das, was Du geschrieben hast, erst einmal sacken lassen.

Elementar für mich ist der Mailserver, da darf einfach nichts schief gehen. Wenn mal eine Webseite nicht erreichbar ist, komme ich bzw. auch meine Frau, die selbständig ist, gut damit zurecht, aber Mail muss immer laufen.

Tatsächlich schätze ich auch Fedora als sehr stabiles Betriebssystem. Vielleicht werfe ich noch einmal eine handvoll Gedanken darauf.

Paul am :

*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.

Dirk Deimeke am :

*Ganz grosse Klasse, vielen Dank für den ausführlichen Kommentar. Du bringst mich gerade ins Nachdenken, das ist super.

Du schreibst "Denn einem System, was ich jeden Tag einsetze, vertraue ich auch." - in dem Fall müsste es bei mir Solaris 11 oder RHEL 7 sein (oder CentOS 7 bleiben). Fedora nutze ich nur auf meinem privaten Notebook und auf einem Jumpserver.

Bezüglich Mailserver möchte ich gerne von SpamAssassin, Amavis und OpenDKIM weg und stattdessen rspamd einsetzen.

Neben TLSv1.3 ist HTTP/2 (was es auch schon seit 2015 gibt) natürlich auch ein Thema. Es hat nie in CentOS 7 Einzug gehalten. Klar, man kann fast alles mit Software Collections abbilden, aber die Verwendung fühlt sich nicht richtig an, da muss ich Dir wirklich recht geben. Ich finde es auch recht umständlich gelöst.

Allerdings muss ich sagen, dass ich mit den Repositories "PHP von Remi" und "MariaDB vom Hersteller" sehr gut fahre und nie Probleme hatte. Ein komplett geeignetes OS braucht aber sicher keine Fremdrepositories oder PPAs ...

CentOS 8 schaue ich mir erst an, wenn die Updates sauber funktionieren und auch die Announce-Mailingliste wieder mit CentOS 8 gefüllt wird, dort findet man bis auf das Update auf 8.1 aber nichts. CentOS-Stream ist die "Beta-Version", das möchte ich dann doch nicht auf einem produktiven Server haben.

In Summe gibt es ja eine handvoll Alternativen. Es gibt keine perfekte Lösung, aber es bleibt die Frage, welche Lösung der perfekten möglichst nahe kommt.

Ulf Volmer am :

*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.

Dirk Deimeke am :

*Auf der anderen Seite bleibt die hohe Stabilität. Ich hatte in den vergangenen fünf Jahren keinerlei Software-Probleme. Das ist enorm selten und das hatte ich weder mit Debian, noch mit Ubuntu.

Was würdest Du denn auf dem Server einsetzen, Ulf?

Ulf Volmer am :

*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

Markus am :

*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? :-)

Dirk Deimeke am :

*Hallo Markus!

Die mitgelieferte PHP-Version ist meiner Meinung nach für jeden ein Thema.

Fedora hat meiner Ansicht nach den grossen Nachteil, dass es zum Teil sehr drastische Veränderungen vornimmt, wie beispielweise der Wechsel des "Default-Python" von 2 auf 3, ohne Möglichkeit, das mit Bordmitteln ("update-alternatives") zurückzusetzen. Auf dem Desktop finde ich das nicht so dramatisch, auf einem Server wo viele Skripte laufen, die selbst geschrieben wurden, kann das fatale Folgen haben.

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. Sie lassen sich bewusst nicht festlegen. Leider sind die Freeze-Zeiten zum Teil sehr lang.

Bei mir hat auch schon ein Debian-Upgrade meinen Mailserver zerlegt als der Wechsel von Dovecot 1.x auf 2.x stattgefunden hat. Deswegen hatte ich mir auch einmal andere Systeme angeschaut. Da ich damals sehr aktiv bei Ubuntu war, ist es natürlich Ubuntu geworden, was nach meinem Weggang 2011 wieder zu Debian und später zu CentOS geworden ist.

Zur OpenRheinRuhr gehe ich in jedem Fall, wenn sie stattfindet. Ich habe das Thema übrigens bereits in einem Vortrag zur Sprache gebracht.

Markus am :

*"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.

Dirk Deimeke am :

*Gerne!

Aber das ganze könnte sicher ein Update vertragen, vielleicht auch mit praktischen Erfahrungen.

Jörg am :

*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

Dirk Deimeke am :

*Hallo Jörg!

Mein Arbeitsplatzrechner ist ein Windows 10 virtual Desktop, aber ich habe Zugriff auf zwei Jumpserver in unterschiedlichen Netzbereichen, die ich via xRDP erreichen kann. Auf denen ist Gnome, KDE und XFCE installiert, was sich die User je nach Gusto auswählen können (war vorher NoMachine). Ich selber habe nur ein grosses PuTTY-Window mit Tmux und Xpanes ...

Debian In-Place-Upgrades waren für mich auch mal ein Thema, allerdings nervte (Vergangenheitsform) es mich, das alle zwei Jahre machen zu müssen. Leider bin ich mit einem auch einmal grandios gescheitert. Ich möchte nicht ausschliessen, dass das an mir gelegen haben könnte, auch wenn ich immer noch glaube, alles richtig gemacht zu haben.

Für mich war das Thema Snapshots vor Upgrades übrigens - neben Problemen bei Hetzner - der Grund, auf virtuelle Server zu setzen.

Synergieeffekte sehe ich für mich nur, wenn ich im RHEL-Umfeld bleibe oder aufgrund von Solaris vielleicht zu FreeBSD wechsele. Ansonsten wären das Einzelkunstwerke, da ich ansonsten keinen Berührungspunkte (ausser dem Buch, an dem ich mitschreibe) mit anderen Systemen habe.

"Dinge nicht mit nach Hause nehmen" ist natürlich auch ein guter Grund, kann mir aber nicht passieren, da sich die Settings und die Anwendungszwecke fundamental unterscheiden.

RHEL: Wir benutzen RHEL weil wir für die Businesssoftware in der Firma ein zertifiziertes Betriebssystem brauchen, mehr Gründe gibt es nicht. Die Zertifizierungen gibt es nur für RHEL und manchmal auch für SLES, selten für Ubuntu. Der Support ist leider nicht so toll und das Subskriptionsmangement mit dem Satellite ist eine Katastrophe.

Positiv ist, dass es eine wahnsinnig stabile Basis ist. Wir empfehlen Applikationen, ihr eigenes Environment mitzubringen, weil RHEL zu alt ist. Damit machen sie sich auch unabhängig von Betriebssystem-Updates. Eigentlich ähnlich wie bei Docker, nur dass die Applikationen nicht in Containern sind.

Wir sind zwar ein sehr kleines Team (und suchen aktuell einen neuen Kollegen), habe aber aufgrund von Automatisierung alles sehr gut im Griff. Anders wären die Themenfelder Linux, Linux on Azure, Red Hat Virtualisation, OpenShift und Lehrlingsausbildung mit derzeit 3.4 Personen nicht zu stemmen.

Jörg am :

*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. :-)

Dirk Deimeke am :

*Auf den CLT austauschen, ist in jedem Fall gut.

Ihr habt vermutlich auch andere Subscriptions (Site License?) als wir. Das macht vieles einfacher.

Was ist denn Deine Meinung zu RHEL?

Jörg am :

*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

Dirk Deimeke am :

*Wenn Ihr keine Campus-wide-Subscription habt, würde mich interessieren, wie Ihr die Repos aktuell haltet. Nehmt Ihr einen Host, packt dort alle Subscriptions drauf und ladet Ihr mit dem dann alles herunter ("Repo-Mirroring")?

Die Transaktionshistorie - inklusive undo - ist wirklich ein Alleinstellungsmerkmal, da muss ich Dir Recht geben. Solaris ist mit einer grossen Menge an Software deutlich aktueller als RHEL.

Wie kannst Du mit dem Support zufrieden sein, wenn Dein Case nicht mehr bearbeitet wird? Dass der Support nicht so toll ist, liegt sicherlich daran, dass gutes (!) Personal fehlt. Leider ist es auch so, dass der erste Level des Supports unsere Anfragen nicht beantworten kann, wir haben aber keine Chance, den zu überspringen und erklären jedes Mal aufs neue unser Setup. Es gäbe durchaus Dokumentationsmedien, wo ein Red Hatter das nachlesen könnte, wenn es seitens Red Hat gepflegt werden würde.

Bei Community, Philosophie und Menschen bin ich wieder bei Dir. Bezüglich Bluewashing bin ich ebenfalls bei Dir.

Ansible ist bezogen auf Änderungen bei "minor versions" eine Katastrophe. Da stimme ich Dir ebenfalls zu.

Es gibt für mich einen Unterschied in meiner Verwendung eines Server-OS und in der Verwendung in der Firma. In der Firma setzen wir bis auf EPEL keine Fremdrepositories ein. Das müssen wir auch nicht, weil die Business-Anwendungen für RHEL zertifiziert sind und diese nicht brauchen.

Allerdings gibt es mittlerweile auch einige Apps, die Inhouse entwickelt werden. Den Entwicklern sagen wir, dass sie alles, was sie zum Betrieb brauchen, bitte mitbringen sollen (Beispiel Java) und schwups sind wir bei Containern und in Konsequenz dann auch OpenShift.

Privat setze ich vor allem Webanwendungen auf gemieteten Servern ein und da ist CentOS/RHEL deutlich zu langsam mit den Updates. Die Alternative sind Fremdrepositories oder Docker-Container - ich benutze beides.

Jörg am :

*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

Dirk Deimeke am :

*Dein Vortrag ist "selbstverständlich" schon in meinem Kalender :-)

Vielen Dank für Deinen Blogartikel. Wir müssen das einmal intern diskutieren, ob wir nicht wechseln wollen. Über welchen Weg baust Du neue Systeme? Cobbler?

Einfrieren von Repos mache ich bei anderen (non-RHEL) Systemen mit "cp -lra", der einige Nachteil ist, dass man Repos anpassen müsste. Da wir aber Betriebsstufen-Weise patchen, reicht je ein Verzeichnis für Current/ Engineering/ Development/ Test/ Acceptance/ Production.

Bezüglich Support kann ich nur sagen, dass sich gerade alle Hersteller nicht unbedingt mit Ruhm bekleckern.

Jörg am :

*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.

Dirk Deimeke am :

*Wir sind auf Hyper-V und stagen via PXE-Boot, Templating geht da "aus Gründen" nicht.

Der RHV-PoC war erfolgreich, daher ist hier auch Besserung in Sicht.

Wir müssen Pakete zwei Monate in Acceptance haben, bevor wir in Produktion gehen. Das mag sich aber ändern in nächster Zeit.

Eine Bank hat da vielleicht noch einmal besondere Anforderungen.

Jörg am :

*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. ;-)

Dirk Deimeke am :

*Wir patchen Betriebsstufen komplett, Applikationen können sich in Ausnahmefällen weigern.

Jetzt, da ich Deinen Vortrag komplett kenne, brauche ich ja nicht mehr kommen. 8-)

Jörg am :

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

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