CentOS ist tot, lange lebe CentOS Stream

[foo_1337]

Hätte RedHat NIE die Versprechen bezüglich CentOS8 haben, hätte keiner Centos8 eingesetzt und die Kunden und damit wir keinen Stress.

Welche Versprechen hat RedHat zu CentOS8 gegeben?

 

[snaxilian]

Was meinste was passieren würde wenn NGINX morgen den Betrieb einstellen würde oder Apache oder Wordpress etc.

Dann passiert das Gleiche was bei vielen vielen anderen Open Source Projekten passiert ist, nämlich eins der folgenden drei Dinge:

• im besten Fall finden sich andere Maintainer und das Projekt lebt weiter
• Das alte Projekt "stirbt" aber wird unter anderem Namen geforkt und weiter geführt von anderen Maintainern
• Das Projekt "stirbt" und erhält halt keinerlei Patches und Fixes mehr. Verwendung im Status Quo möglich oder eigene interne Weiterentwicklung und Pflege falls gewünscht.

CyanogenMod ist da z.B. ein schönes Beispiel. Oder ZFS und mysql nachdem Oracle Sun gekauft hat.

RedHat hat andere Dinge versprochen

RedHat wird wohl kaum x Jahre Support für CentOS versprochen haben.

Ist das so unverständlich dass das ein Problem ist?

Natürlich ist das ein Problem aber mehr oder weniger ein hausgemachtes Problem. Man/ihr/eure Kunden gingen davon aus, dass es so weiter geht wie bisher und bei den letzten Versionen und hat sich auf das nicht-verbindliche Versprechen/Aussagen der CentOS Maintainer verlassen.
Natürlich kann ich den Ärger nachvollziehen wenn man zur Fehlersuche nicht mehr mal eben kostenlos einen Testcluster parallel hochziehen kann ohne direkt Lizenzen kaufen zu müssen

Im Sommer konnte man z.B. schon im Blog von Herrn Kofler nachlesen, dass die Langzeitunterstützung von CentOS 8 wertlos ist: https://kofler.info/centos-8-wertlose-langzeitunterstuetzung/
Wobei er da auch nur zu dem Zeitpunkt bereits öffentlich bekannte Informationen zusammen fasst.

Ja, SLES ist für manche eine Alternative und wenn man YaST konsequent links liegen lässt und lieber ein passendes Config-Management-Tool seiner Wahl nimmt, dann ist es sogar brauchbar und nicht so teuer wie RHEL in der Lizenzierung.

Rocky Linux hat nach wie vor kein Releasedatum und afaik sind es für Rocky weniger Maintainer als noch für CentOS und wenn CentOS es schon nicht hin bekam zeitnah Patches zu portieren und ein Release raus zu bringen: Warum sollte es Rocky jetzt plötzlich schneller schaffen?

 

[foo_1337]

nginx war sowieso nicht das beste Beispiel, weil das Ding schon lange kommerzialisiert war und mittlerweile von F5 gekauft wurde. Nginx als Reverse Proxy wird aktuell von vielen bereits durch envoy proxy ersetzt, weil gewisse Dinge nur noch bei nginx Plus verfügbar sind und die Kosten vergleichweise hoch sind (teurer als RHEL )

 

[Skysnake]

Ganz offiziell von RedHat...
Meldung

What does this mean for CentOS?​

CentOS Stream is parallel to existing CentOS builds; this means that nothing changes for current users of CentOS Linux and services, even those that begin to explore the newly-released CentOS 8.

RedHat hat also selbst zur Vorstellung von CentOS Stream gesagt das alles beim bekannten Modell bleibt und die Angaben zum Support für CentOS8 haben ja auch Support bis 2029 versprochen. Bis halt zu jenem schicksalhaften Tag an dem RedHat Center gekillt hat indem das Supportende auf 2021 vorverlegt wurde.

Müssen wir ehrlich über obige Sache reden? Also das das bitte zu beweisen ist? Sorry, aber das begibt sich auf ne Ebene die Friss oder Stirb heißt, nachdem man dich in ne Sackgasse geführt hat...

Wie gesagt das ist unterste Schublade und genau das worüber sich die Leute zurecht aufregen. Man wurde verarscht... die hätten einfach nur sagen müssen es ist vorbei und gut ist...

Und bezüglich der Updatelücke. Ja die ist da, aber die war früher vertretbar erst mit CentOS 8 wurde es jetzt bedenklich. Aber ein Schelm wer dahinter Absicht vermutet. Das würde RedHat ja nie machen..... oh wait...

Ergänzung (29. Dezember 2020)

@snaxilian
Rocky hat ne Chance weil ein Kopf von CentOS dahinter steht und eben viele Wissen wie wichtig ein unabhängiger downstream ist. Rückblickend hat man sich von RedHat bei CentOS einlullen lassen. Hinterher ist man aber immer schlauer. Zumindest nicht war eigentlich begeistert das RefHat da einsteigt. Die CentOS Entwickler hätten ja näher an die RedHat Entwickler drücken können was alles einfacher und schneller macht... aber denkste...

Wie gesagt, das Centos8 an sich stirbt ist nicht DAS Problem sondern das Timeing.

Und btw Oracle ist wohl für HPC keine Alternative. Es ist kein bugtobug rebuild und am Kernel wird wohl auch geschraubt. Das ist also wertlos da Dinge gegen den Kernel gebaut werden müssen... war mir leider so bisher auch nicht bewusst.

Btw an Rocky könten sich die großen Labs hängen inkl Cern etcpp, weil die Alternativen fehlen. Quasi der Rücktritt von Scientific Linux Tod

Ergänzung (29. Dezember 2020)

Man wird aber schauen müssen ob man die CentOS Entwickler zur Abwanderung bewegen kann. Ich würde sagen aussichtslos ist es nicht. RedHat hat sich da halt echt was geleistet...

 

[foo_1337]

Zu OEL: Du musst nicht deren unbreakable kernel benutzen, das steht dir frei. Und es ist 100% RHEL kompatibel, userland + kernel. Nicht mehr und nicht weniger als CentOS. Du kannst, wenn du an den CentOS SRPMS nichts verändert hast oder einen custom kernel verwendest, direkt auf OEL wechseln. Es wird alles so laufen wie vorher, garantiert. Vorsicht ist lediglich geboten, wenn man z.B. Spacewalk nutzt, aber das Ding ist eh weg vom Fenster
Oracle stellt dir Minor Releases innerhalb von 5 Werktagen bereit und Errata in der Regel innerhalb eines Werktages. Auch wenn ich den laden nicht mag würde ich jedem dringend anraten zu OEL anstatt zu Rocky (wenn es denn jemals so weit ist) wechseln. Ansonsten kannst du dich ja noch bei Project Lenix umschauen
Von den wenigen CentOS Entwicklern sind einige direkt bei RedHat angestellt, eher unwahrscheinlich, dass die wechseln.

 

[Skysnake]

Lenix kommt von ner Cloud Firma. Da lässt man lieber die Finger von. Die Branche ist zu wankelmütig.

 

[andy_m4]

RedHat hat andere Dinge versprochen und jetzt so knall auf Fall kommt das nach einer der großen Messen der Branche.

Redhat hält Versprechen auf RHEL. Da hast Du einen Vertrag. Auf den kannst Du Dich im Fall des Falles berufen.
Wenn Redhat pleite geht oder sowas nützt Dir das zwar auch nichts, aber es ist deutlich mehr als nur ein reines Versprechen.

Bei CentOS (egal wie stark die von Redhat unterwandert sind oder nicht) hast Du halt nur das Versprechen. Offiziell ist es nur ein Community-Projekt und die haben auch nie was anderes behauptet.

Scientific Linux hat man zugunsten CentOS aufgegeben, was an sich die richtige Entscheidung war.

Nein. war es nicht. Gut. Aus der jetzigen Perspektive lässt sich das für mich leicht sagen. :-)
Als Redhat damals bei CentOS eingestiegen ist hätte man schon misstrauisch werden können (Redhat war ja in den Jahren zuvor nie ein besonders guter Freund von CentOS). Aber gut. Damals konnte man das sich noch so hinbiegen, das es vielleicht gar nicht schlecht ist, wenn Redhat CentOS direkt unterstützt von wegen bessere Zusammenarbeit und so.
CentOS Stream ist ja jetzt auch keine neue Sache, hat man ja vorher schon initiiert. Da hätte man hellhörig werden sollen. AUch das alleine wäre kein Grund gewesen. Aber das es immer mal wieder Probleme/Zeitverzögerungen gab mit neuen RHEL-Versionen gleichzuziehen, fand ich selbst dann doch zunehmend bedenklich.

Es machte also schon vorher Sinn einen weiteren RHEL-Klon am leben zu erhalten, weil eben schon sichtbar war das nicht alles rund lief.

Das Problem ist Die Zeit die einem jetzt noch bleibt in Kombination mit dem Zeitpunkt.

Wie gesagt. Der Aufwand beschränkt sich im Wesentlichen darauf den einen RHEL-Klon durch den anderen zu ersetzen. Es besteht kein Grund in Panik zu verfalllen und alle CentOS 8 Installationen wegzuwerfen.

Stand jetzt gibt es keine Alternative zu CentOS. Oracle wird von genug abgelehnt werden und das zu Recht.

Es wäre zumindest eine schnelle Lösung. Das muss ja nicht dauerhaft dabei bleiben. Wie gesagt. RHEL ist RHEL. Um Zeit zu gewinnen, dafür reicht es auf jeden Fall. Egal wie man zu Oracle steht.

Ist das so unverständlich dass das ein Problem ist?

Ja. Ich sehe natürlich das Problem. Aber das ist erstens ein Problem was sozusagen zumindest zum Teil selbst verschuldet ist, da man sich 100%ig auf eine unverbindliche Zusage verlasen hat.
Zweitens ist das jetzige Problem keines, was grundsätzlich unlösbar ist. Wie wie schon gesagt: Man setzt ja auf Open Source weil man Abhängigkeiten minimieren möchte. Und jetzt ist sozusagen mal der Fall eingetreten, wo man das praktisch durchspielen muss. Und im Falle von CentOS ist das ja sogar noch ein Fall der relativ mild ist.

die Leute hinter rocky Linux werden das sicherlich wuppen, aber werden die das unter den aktuellen Verhältnissen ohne Messen/Konferenzen etcpp auch innerhalb der nächsten 3 Monate schaffen? Ich habe meine Zweifel.

Naja. So wie ich es verstanden hab ist ja Rocky Linux eine Initiative des CentOS-Gründers der selbst auch ziemlich angepisst über Redhats Entscheidung war.
Jedenfalls der Punkt ist: Das macht nicht irgendein Neuling (und ohnehin kein Einzelner, sondern einige andere CentOS Mitstreiter) der noch nie so ein Projekt gemacht hat, sondern jemand der sich auskennt. Und zwar auch genau mit der Thematik auskennt "Wie mach ich aus den Redhat-Quellen eine RHEL-kompatible Distribution."

Im Grunde kann man fast sagen: Rocky Linux wird das neue CentOS, weil die Ziele und die Leute die da drin sind die sind, die CentOS zu dem gemacht haben, was es heute ist. Ein neuer Name für eine altbekannte Distribution.

Die Voraussetzungen sind also schon mal nicht so schlecht.

Parallel muss man aber ja auch an Plan B arbeiten weil Rocky kann ja auch ne Bruchlandung hinlegen.

Plan B wäre (unter Beteiligung aller Profiteure) selbst etwas hochzuziehen und weil ein Jahr knapp dafür ist, Oracle Linux als Lückenfüller zu nehmen. Müssen aber letztlich die Beteiligten selbst wissen. Auch ob sie dafür das Budget aufbringen können/wollen. Wie gesagt. Umso größer die Gemeinschaft ist und umso mehr Systeme zu versorgen sind, umso mehr lohnt es sich ja ohnehin darüber nachzudenken.

Denn letztlich muss man sich vergegenwärtigen das selbst wenn man jetzt zu Rocky Linux oder irgendeinem anderen Projekt greift (SLES-Klone) das wieder nur so eine Community-Geschichte ist, die nicht mehr als unverbindliche Zusagen machen kann.
Da kann man sich halt überlegen: Lebt man mit dem Risiko (so hat mans bisher gemacht, man war sich aber offenbar nicht überall des Risikos wirklich bewusst) oder macht man sich unabhängig.

Abgesehen von alle dem kann man sich aber auch an Rocky Linux beteiligen. Man muss nicht abwarten bis da irgendein Ergebnis bei rum kommt. Man kann selbst sozusagen Teil des Prozesses werden (und dann auch viel besser abschätzen wie und ob sich die Sache entwickelt).

Was wäre auch generell eine Sache die man sich überlegen könnte. Das wenn man sowas wie ein RHEL-Klon nicht schon selbst stemmen will oder möchte, das man sich dann sagt:
Wenn ich CentOS, Rocky Linux (or whatever) schon exzessiv einsetze, dann beteilige ich mich auch in irgendeiner Form an dem Projekt.

Dann bleiben 9 Monate um die ganze Migration zu planen mit jedem Kunden, Wartungsfenster zu vereinbaren und die Kunden zu migrieren. Da steckt durch die Verifikation nen Arsch an Arbeit dahinter und jeder will ja vor Supportende fertig sein...

Wie gesagt: Das Schöne an den Klonen ist ja, das es sich darauf beschränkt ein paar Konfigurationsdateien auszutauschen. Wenn ihr das in 9 Monaten nicht getestet und ausgerollt kriegt, dann solltet ihr eure Berufswahl überdenken. :-)

RedHat tut sich da keinen gefallen, weil Sie sich gerade ihren Ruf für Stabilität und Verlässlichkeit ruinieren. Das werden die noch zu spüren bekommen weil Leute aufgrund mangelndem Vertrauens abwandern werden.

Das kann natürlich sein. Ich denk auch, das man kurzfristig damit einen positiven Effekt hat (Leute wechseln zu RHEL) aber langfristig es eher negativ ist. Man wird sehen.

Vielleicht ist das ja mal die Gelegenheit generell darüber nachzudenken, wie man das in Zukunft handhabt. Hast Du ja auch selbst gesagt (mal in Richtung SLES gucken oder so).

 

[Skysnake]

Naja, es ist schon noch ein bischen mehr als einfach austauschen. Man muss ja die ganzen repos noch umziehen und halt schauen ob es wirklich bugtobug kompatibel ist oder nicht.

Zudem besteht hat noch dir Gefahr das RedHat die Clone verhungern lässt weil sie die Sourcen erst mit x Wochen Verspätung raus bringt. Und damit muss man nach der Aktion leider rechnen....

Kann also auch mit den besten Leuten und genug Geld ein Fehlschlag werden...

Ansonsten müssen wir halt mal noch schauen wies mit den CentOS Container images weiter geht. Das ist ja auch noch vollkommen unklar. Zumindest für die Software die ich entwickle ist das extrem wichtig. Klar man könnte einfach das RedHat Base Image verwenden, aber da muss man nur warten bis man dafür auch bezahlen darf...

Und für uns sind halt noch Dinge wie die default configs und die build Parameter für den Kernel wichtig. Da schleicht sich schnell mal auch ne Abweichung ein. Vor allem wenn es wie hier unter Zeitdruck passieren muss.

Da kann man sich auch nicht drauf verlassen, dass das schon tun wird, sondern mussbes wirklich durchspielen. Je nachdem kann man ja auch auf irgend nen Bug stoßen und wenn dann der 1MW+ Cluster für X Stunden Rum steht ist keiner begeistert... das kostet nämlich Geld. Also lieber vorher testen. Die Maschinen kann man ja auch nicht einfach aus machen sondern muss die wahrscheinlich leer laufen lassen für das Update. Das erfordert aber 2-4 Wochen Vorlauf. Dann muss man die eigenen Leute da haben etcpp.

Wobei das halt der "einfache" Weg ist. An sich würde man gerne da ein Rolling Update machen ohne den Cluster anhalten zu müssen. Das macht aber für mich deutlich mehr Arbeit wie du sicherlich verstehen kannst. Da dürfen ja dann wirklich keine Fehler passieren...

Die Grundlagen für Rolling Update wurden gelegt, aber ob man das bei so einer Änderung wirklich machen will...

 

[andy_m4]

Zudem besteht hat noch dir Gefahr das RedHat die Clone verhungern lässt weil sie die Sourcen erst mit x Wochen Verspätung raus bringt. Und damit muss man nach der Aktion leider rechnen....

Wie schon gesagt. Ne Langzeitstrategie sollte man sich so oder so überlegen. Die ist aber erst Recht nicht innerhalb eines Jahres gebacken, daher muss man vernünftigerweise natürlich gucken, was man jetzt macht, damit man Januar 2021 nicht mit heruntergelassenen Hosen da steht.

Worin ich halt wenig Sinn sehe ist jetzt wieder auf CentOS 7 zu wechseln um sich mehr Zeit zu erkaufen, um dann später dann noch mal eine große Umstellung machen zu müssen.

Ob Redhat tatsächlich den Weg geht irgendwann mal die Sourcen zurückzuhalten bzw. verspätet rauszugeben glaub ich aber nicht. Nicht weil ich Redhat so einen Move nicht zutrauen würde, sondern weil das eine explizite Forderung der Copyleft-Lizenzen wie der GPL ist.
Und wenn sie damit irgendwie Sch**ße machen dann sind sie nicht nur rechtlich angreifbar, sondern dann ist es wirklich das Todesurteil für Redhat. Weil wie gesagt. Der wichtige strategische Vorteil von Open-Source ist ja gerade das niemand den Kram für sich vereinnahmen kann.

Spätestens dann würde es auch zu einem Fork von RHEL kommen, weil halt (zumindest jetzt noch) sehr viele von CentOS abhängen.

Kann also auch mit den besten Leuten und genug Geld ein Fehlschlag werden...

Klar. Kann es . Ne 100%ige Garantie hast Du nicht. Wie gesagt: Selbst wenn Du ne RHEL-Subskription hast ist das keine 100% Garantie.

Ansonsten müssen wir halt mal noch schauen wies mit den CentOS Container images weiter geht. Das ist ja auch noch vollkommen unklar. Zumindest für die Software die ich entwickle ist das extrem wichtig. Klar man könnte einfach das RedHat Base Image verwenden, aber da muss man nur warten bis man dafür auch bezahlen darf...

Mit den Containern ist es halt so eine Sache. Es nützt Dir ja nix, wenn Du einfach nur das was Du bisher gemacht hast in einen Container tust. Daraus ergibt sich kein wirklicher Effekt (naja; bis auf das Du Container zwischen Hardware hin und herschieben kannst; aber das ist ja nicht das, worum es hier geht).

Bei Containern geht es ja eher darum eine Anwendung mit all ihren Abhängigkeiten zu bündeln. Du hast letztlich in dem Container gar kein vollständiges System oder so, sondern nur das was die Anwendung braucht.

Das zieht aber wiederum andere Probleme nachsich. Im Grunde ist es ja gut wenn man genau eine Langzeit-Distribution hat und die Anwendungen die darauf laufen sind alle für genau die Distribution "zertifiziert" (jedenfalls auf irgendeine Weise sichergestellt, das die damit auch läuft).

Packst Du Deine Anwendungen in Container wird es ja nicht automatisch besser, weil Du jetzt eben nicht mehr auf eine Systemumgebung zurückgreifst, sondern mehr oder weniger für jeden Container getrennt gucken musst, das da alles gerade vor bleibt. Du spartst dann zwar dich großartig ums Host-System zu kümmern weil Deinem Container (so ziemlich) egal ist worauf er läuft. Aber hast dann halt die die Pflege der Container.
Im Optimalfall kümmert sich der darum der eh die Anwendung baut. Liefert der die in Containern aus und kümmert sich auch darum, das die stets in Ordnung sind, dann biste fein raus.
Müsste man alles alleine umsetzen würdest Du keinen Aufwand sparen, sondern ggf. sogar noch mehr haben.

Container können eine Hilfe sein, aber das ist keinesfalls ein Selbstläufer so nach dem Motto: "Wir packen einfach alles in Container und damit sind unsere Probleme gelöst."

Da kann man sich auch nicht drauf verlassen, dass das schon tun wird, sondern mussbes wirklich durchspielen.

Ja. Muss man.
Ich sag ja auch nicht, das es von allein geht. Aber es ist machbar.

und wenn dann der 1MW+ Cluster für X Stunden Rum steht ist keiner begeistert... das kostet nämlich Geld.

Jaja. Kostet alles immer Geld und das hat keiner. :-)
Die haben doch alle vorher schön bei den RHEL-Subskription gespart. :-)
Ich wundere mich ja bei sowas, das sich bisher immer noch nicht die Erkenntnis herum gesprochen hat das bei IT sparen (man kann schon fast sagen: geizen) immer irgendwie so endet, das Du dann zum Schluss mehr Kosten hast als hättest Du es gleich ordentlich gemacht.

Gerade dieses (erschreckend häufige) übertriebene Kostensparen ist oft eine fragile Wette darauf, das schon alles glatt gehen wird. Ich find dann auch die Argumentation interessant: Na wenn wir hier zu viel Geld ausgeben dann können wir dies das und jenes nicht machen. Das mag ja auch stimmen. Aber was ist in dem Fall, wo die Wette nicht aufgeht? Das wird dann halt immer gerne verdrängt. Der Vorwurf geht auch nicht gegen Dich oder so, sondern eher an Deine Kunden die schon gleich mit expliziten Vorschlägen ankommen, wie man alles schön billig kriegt. :-)
Da hätte ich auch als Dienstleister kein gutes Gefühl, wenn das Budget schon so auf Kante genäht ist, ob ich dann überhaupt in vollen Umfang meine Kohle sehe. Gerade dann, wenn (wie in der IT gerne mal) was Unvorhergesehenes passiert bzw. man mit unerwarteten Problemen konfrontiert wird.

Die Grundlagen für Rolling Update wurden gelegt, aber ob man das bei so einer Änderung wirklich machen will...

No risk, no fun. ;-)

 

[Skysnake]

Na um die Kohle muss man sich keine Gedanken machen, wenn man das abliefert was man versprochen hat. Man darf halt nur nicht zu viel versprechen und bei so großen Deals wie Jülich etc da legt der Anbieter teils auch drauf. Das weiß jeder in der Branche...

Ist halt Half Price Computing aka HPC...

Die Leute wissen schon sich was Sie machen. Wenn etwas laufen muss, dann sind da auch Lizenzen mit eingeplant, wenn nicht dann aber nicht. Du kannst ja entweder ne Maschine 10-20% größer machen oder halt mit der Verfügbarkeit runter gehen. Mit nur 90% Verfügbarkeit fährst du ja noch immer besser. Und 90% ist nicht viel.

Und rein aus der Erfahrung raus ist das auch genau das richtige Vorgehen bisher gewesen um nach 5 Jahren die meisten Flops pro € zu bekommen. Am Anfang muss man ja die Performance zeigen und allgemein auch recht harte Stabilitätstests. So 98%+ Verfügbarkeit über 7-14 Tage sind normal. Da muss man schon gut aussortieren. Vor allem weil die letzten Jahre echt vermehrt Bananen Hardware von den Herstellern kommt. Das reift beim Kunden...

Wenn man 10 Server hat alles kein Problem aber bei 1000 sieht man halt auch sehr seltene Probleme ständig... selbst fucking Cat6 Kabel bekommt man heutzutage mit Fertigungsfehler....

 

[Skysnake]

Also das centos2o.sh Skript darf/kann man nicht einfach verwenden, wenn man eigene Kernel Module benutzt. Da wird nämlich der unbreakable Kernel installiert der statt nem 4.18 ein 5.x Kernel ist...

Ist also nicht so einfach zu machen wie man denkt.

Ansonsten hat wohl Oracle einiges bezüglich cloud Anwendungen etc gemacht. Also so lese ich das zumindest. Man wird also die Kernel Parameter überprüfen müssen.

Dazu kommt, das OL wohl von Mellanox und NVIDIA nicht supported werden. Muss mir das aber noch genauer anschauen mit den Versionen.

Wos aber wohl auch nen Unterschied gibt es in secure Boot. Also zumindest steht das in dem readme zum coreos2ol.sh Skript.

Kickstart geht aber wohl. Sooo einfach ist der Wechsel aber wohl nicht wie suggeriert. Das war leider auch meine Befürchtung.

 

[foo_1337]

Vor dem reboot: sudo grubby --set-default /boot/vmlinuz-4.18.0-240.1.1.el8_3.x86_64
Oracle hat nur im uek etwas gemacht, sonst nirgends.
https://www.mellanox.com/support/mlnx-ofed-matrix

OL ist dabei oder worum geht es?

 

[Skysnake]

Ich habe mal random nach Treibern gesucht. Wahrscheinlich auf nen "alten" gekommen.

Und ja, das ist leicht fixbar, man muss es aber wissen!

Naja, mal schauen, vielleicht mach ich mal den Wechsel auf nem Testsystem.

 

[Skysnake]

So ich habe mal ein Testsystem aufgesetzt und auf ol7 migriert. Hat soweit alles funktioniert. Aber ich habe mal direkt einen MCError nach ein paar Minuten bekommen. Maschine läuft noch, hatte ich bis jetzt aber noch nie auf der Kiste..

Zudem fehlen ein paar epel Pakete. Da hat CentOS scheinbar neuere Versionen und ein zwei fehlen komplett. Ist jetzt die Frage wie aufwändig es ist das gerade zu ziehen.

Ansonsten scheint es zumindest für uns erstmal keine größeren Probleme zu machen

 

[Skysnake]

Mal noch ein bisschen weiter geschaut. Die Kernel Parameter scheinen zwischen CentOS und Oracle nicht identisch zu sein. Für unsere Zwecke aber wahrscheinlich hinreichend gleich.

Könnte aber für einige problematisch werden. An sich müsste man aber noch schauen ob CentOS 7.9 die auch ändert... das hatte ich vergessen zu schauen

 

[Skysnake]

So nich ein bischen weiter geschaut. Die Unterschiede bei den Kernel Parametern kamen wohl daher das es unterschiedliche CPU Generationen waren, was ich nicht gesehen habe. Tuned hat dann wohl noch den Rest erledigt.

Was halt noch anders ist sind dir migitations. Das ist aber erstmal kein Problem.

Sieht also stand jetzt alles gut aus für mich.

Ich habe nur Bauchschmerzen wegen Oracle.... für CentOS 8 aber wahrscheinlich die Beste Option stand jetzt.

Zu Cuda etc habe ich inzwischen auch Support gefunden. Das war bisher wohl einfach nicht so auf dem Schirm

 

[andy_m4]

Ich habe nur Bauchschmerzen wegen Oracle....

Ich verstehe Dich :-)

für CentOS 8 aber wahrscheinlich die Beste Option stand jetzt.

Ja. Bleibt zu hoffen, das sich da bei den Alternativen zeitnah was tut, damit man Ausweichoptionen hat. Für den Fall der Fälle.

 

[Skysnake]

Ja, ein Container Base Image müssen die aber auch erstellen. Ich habe mir mal das RedHat Base Image angeschaut. Ich denke das können wir nicht einfach nutzen...

 

[konkretor]

Lebenszeichen vom Klon

https://www.heise.de/news/CentOS-Klon-Project-Lenix-wird-zu-AlmaLinux-5024151.html

 

[konkretor]

Rhel bietet kostenlose Lizenzen an

https://www.heise.de/news/Kostenloses-RHEL-statt-CentOS-5030972.html