Planung zükünftige OS Strategie

sinux

Da Suse 16 nicht mehr weit ist und ich gelesen hatte das dieses OS dann sozusagen readonly werden soll würde ich gerne wissen ob dann vielleicht Debian näher in den Fokus rückt. Ich finde suse schleppt zu viel mit rum, wenn ich das Update sehe und die key aktualisiert werden, das dauert immer alles, geht bei Debian einfach schneller. Das ist jetzt nur ein Beispiel. Gut es ist eben Geschmackssache, fahr ich Trabbi oder BMW.... Man könnte auch sagen, Debian ist näher an den USA als Suse. Ich hoffe ja auf das nächste Grommunio Release hier, vielleicht benötigt man dann nicht mehr zusätzliche Scripts die tlw. noch rpm Paket für Debian benutzbar machen. Vielleicht wisst ihr da mehr?
VG sinux

WalterH

sinux Da Suse 16 nicht mehr weit ist und ich gelesen hatte das dieses OS dann sozusagen readonly werden soll ...

Ist ja auch ein Schutz gegen Viren. Ich habe nichts gegen ein read only OS.

hugh

Oracle, Alma, Rocky, ..., da ist rpm nativ und die werden von den Hostern breit unterstützt

crpb

fwiw, https://en.opensuse.org/Lifetime

sinux

Danke ich hab jetzt trotzdem Debian genommen zur Installation denn das Update key gezuppel unter SuSe dauert mir einfach zu lange. Auch das Yast ist für mich zu langsam... aber alles wie gesagt Geschmackssache. Wie kann ich das als gelöst markieren?

daniel

Ich würde gern diesen Thread nochmal aufgreifen und die zukünftigen Planungen zum OS Support anfragen.

Ich betreibe Grommunio auf EL9 und beobachte das Forum und Github bzgl. der aktuellen Probleme:

Webmail ist seit Monaten nicht mehr nutzbar, da ein Wechsel der EL9-Standard PHP-Version nötig wäre - in php-mapi-header werden Sprachkonstrukte verwendet, die unter dem von Redhat gepflegten PHP8 nicht vorhanden sind. Ein Wechsel auf Remi oder Appstream Modules geht wegen Abhängigkeiten der Grommunio RPMs nicht (Modul php_mapi ist gegen PHP 8.0 kompiliert).
https://community.grommunio.com/d/2313-webmail-error-500-internal-server-error/36
Aktuell passt im .spec File für python3-mattermostdriver eine Abhängigkeit für das Websocket-Modul nicht.
https://github.com/grommunio/admin-api/issues/60
Aktuell hilft hier nur ein rpmrebuild, was automatisierte Update-Prozesse blockiert.

Der Einfluss der Community ist hier auf "Fehler melden" beschränkt, die Github Issues liegen teilweise sehr lange.

Bzgl. EL10 gibt es eine laufende Diskussion, dass der Support noch nicht final gegeben ist, aber gerade aufgebaut wird. In dem Zusammenhang wird das PHP8-Thema auch angesprochen - für mich als EL9 User würde ich es als Strategie "aussitzen" bezeichnen:
https://community.grommunio.com/d/2404-el10-unresolvable-dependencies/5
Ich befürchte, dass EL10 nach einem guten Start früher oder später wieder in ähnliche Probleme bzgl. des PHP-Supports laufen wird, da m.W. in EL10 die PHP Version 8.3 auf 10 Jahre einsetzen wird, wie in EL9 die Version 8.0.

Als Ausweichmöglichkeit denke ich schon länger über einen Wechsel auf Container-Betrieb nach - dort hätte Grommunio die Wohlfühlumgebung von SuSE. Mir erscheint aber aus der Dokumentation und Aktivität im Github-Repo für die Container-Beschreibungen das Betriebsmodell auch eher ein Stiefkind zu sein (von mir aber ungetestet).

Mir ist nicht bekannt, inwieweit Debian 13 bereits unterstützt wird, bzgl. SuSE wurde hier ja bereits die Diskussion eröffnet. Lt. Doku (https://docs.grommunio.com/admin/roadmap.html) nur Debian 12.

Bitte nicht meine Auflistung als "Anklage" verstehen. Mir fehlt der Einblick, wie die mittel- bis langfristige Planung bzgl. OS Support bei Grommunio aussieht. Ein Feedback von denjenigen, die hier Einblick haben, wäre klasse.

WalterH

Das hatte ich hier im Forum schon einmal geschrieben. Die Appliance mit SUSE ist die am besten unterstützte Version. Dann kommen Debian 12 und vermutlich 13, aber ich habe selbst noch kein System auf Debian 13. Danach kommt lange nichts und dann folgen die anderen Betriebssysteme. Das hängt mit der Auslastung der Entwickler zusammen. Leider benötigt jedes Betriebssystem einen anderen Installer, eine andere glibc usw. Auch der Unterschied zwischen Debian 12 und Debian 13 ist gewaltig. Linus Torvalds hat das schon 2014 auf der Debian-Konferenz in Portland, Oregon, mit Enttäuschung angesprochen. Das macht es für die Entwickler extrem schwer, viele Distributionen zu warten, auch wenn sie dazu bereit sind. Wenn man Windows als Vergleich heranzieht (hat Linus 2014 auch erwähnt) dann funktioniert ein Installer auf allen Plattformen also Win 10, Win 11, Server 2016 bis 2025. Das macht es für die Entwickler deutlich einfacher.
Disclaimer: Das ist meine persönliche Meinung zu diesem Thema.

daniel

@WalterH Danke für die schnelle Antwort - das deckt sich auch alles mit meiner Wahrnehmung.

Ich finde mit Deinem Input die Frage noch relevanter, ob das Thema Container überdacht werden sollte. EL9 hat mit podman eine super Umsetzung für den Betrieb und Ihr könntet Entwicklerressourcen bei EL9/10 und ggfs. Debian sparen, wenn es bspw. tägliche Container Builds für die Einzelkomponenten (gromox, sync, web, admin-api/ui) in einer Registry gäbe. Wichtig fände ich, dass es kein "großes Image" mit postfix, etc. ist - das kann man dann über Compose selbst zusammenbauen.

WalterH

Ich kenne derzeit keine einzige Installation mit Container, bei unseren Kunden ist das kein Thema.

stefan_o

Ich hatte Grommunio jetzt mehrere Jahre auf einem Debian 11 und dann 12: Es läuft nicht besonders gut, ich erinnere mich z.B. das Grommunio irgendwo im system eine (in Debian ungültige) Konfigurationsdatei abgelegt hatte die viele andere Dinge außerhalb von Grommunio gestört hatte. Ganz davon abgesehen das es sehr viel Frickelei ist, den nginx so zu konfigurieren, das neben Grommunio darüber noch was anderes läuft. Grommunio ist wie es mir scheint darauf ausgelegt, das System alleine für sich zu haben.
Ich habe jetzt Debian 13, dort habe ich in Incus eine VM erstellt, darin Grommunio aus der ISO installiert, die VM danach in einen Container konvertiert und bis jetzt scheint das gut zu laufen. Ein Incus Container kombiniert die Vorteile von Docker-Containern und VM, du hast ein komplett eigenes isoliertes OS, das aber auf dem Host-Kernel läuft und damit mit nativer Geschwindigkeit und ohne feste Ressourcenzuteilung (man muss z.B. nicht X GB RAM für eine VM reservieren).
Wer nur Grommunio laufen (oder noch andere VMs/Container) hat kann auch Proxmox nehmen, verwendet die gleiche Technik, aber Proxmox will ebenfalls das gesamte System für sich, Incus ist dafür gedacht zusätzlich zu anderen Diensten auf einem Host zu laufen.

@WalterH
Ich gebe dir Recht das die Auslieferung von Binaries für Linux die auf beliebigen Distributionen laufen sollen wirklich problematisch ist. In macOS gibt es ein einfaches Argument für compiler/linker mit dem man die Mindestversion festlegen kann, auf der das Programm laufen soll (wenn man dann eine API verwendet die es in der Version noch nicht gab bekommt man einen Fehler). Unter Linux geht das nicht so einfach, man muss entweder eine alte Distribution als "kleinsten gemeinsamen Nenner" zum kompilieren nehmen oder den Compiler und die libc selbst für eine spezifische libc Version kompilieren (crosstool-NG macht diesen Prozess relativ einfach). Aber dann kommen noch die anderen Bibliotheken wie GTK und Qt...
Es wäre wirklich gut wenn man hier einen Standard für alle Distributionen schaffen könnte, so dass man so kompilieren/linken kann das alle Distributionen die neu genug sind das Programm ausführen können. Und alle Bibliotheken die nicht Teil des Standard sind muss man entsprechend mitliefern oder statisch linken.
Aber Grommunio hat noch ein viel größeres Problem: Es ist nicht ein Programm, sondern mehrere Programme die vor allem diverse Fremdsoftware verwenden (nginx, postfix, PHP, MariaDB). Bei einem Vergleich zu Windows musst du also berücksichtigen, dass du dort auch verschiedene Versionen von HTTP und SMTP Servern hast, verschiedene PHP Versionen etc. Und dann ist Windows-Entwicklung auch nicht mehr einfacher. (meine persönliche Meinung)

WalterH

stefan_o das neben Grommunio darüber noch was anderes läuft.

Das ist das Hauptproblem! Der Server wo grommunio läuft, ist ein Mailserver - nur ein Mailserver - sonst nichts, darauf hat nichts andere zu laufen. Wenn man andere Dienste als die grommunio Dienste laufen lassen will, eine zusätzliche VM aktivieren. Eine Debian Lizenz kostet nichts und auch eine Open SUSE Lizenz ist kostenlos im Gegensatz zu Windows. Und die 4 GB RAM die das OS benötigt, sollte man haben.

stefan_o

Es wäre gut wenn das am Anfang in der Installationsanleitung stehen würde:
"Important: grommunio will reconfigure and use many services of the OS. It is highly recommended to start with a fresh installation of the OS and not use the system to provide any service (for example web or file server) outside of grommunio to avoid problems with grommunio and other services interfering. If you need to run other services on the host it is recommended to install grommunio inside a virtual machine or a container"

WalterH

In der Dokumentation steht so was, habe ich mal gelesen. Was aber auch zu sagen ist, wenn der Admin damit umgehen kann, kann der Admin ja auch andere Dienste darauf laufen lassen aber dieser Admin muss wirklich - Betonung auf wirklich, gut sein, sonst gibt es nur Probleme.

Andy

WalterH wenn der Admin damit umgehen kann, kann der Admin ja auch andere Dienste darauf laufen lassen

Und da das mit all den anderen Belangen in einer laufenden Umgebung schwer wird und sich Admins nicht nur um "sowas" kümmern können, würde ich strikt davon abraten. Ein natives Grommunio-System sollte für sich laufen oder als VM, was letztlich vergleichbar ist.

Als Kurzgeschichte, ich hatte vor Jahren z.B. Owncloud und Nextcloud auf diese Weise nativ auf Mischdienstsystemen laufen, aber auch noch weitere Applikationen. Das ganze "gerichtete" System läuft eine Weile und nach diversen Updates, Anpassungen, anderen Installationen war der Spass meist vorbei und man hatte wieder Konflikte. Letztlich bedeuted das aber immer zeitlicher Aufwand, egal, wie umfangreich nun.

PiotrPan

WalterH: Operativ muss man sich dennoch die Frage stellen ob man am falschen Ende spart, wenn man (virtuelle) Hardware aus Wartungs- und Kostengründen minimal halten will, dem gegenüber aber die Komplexität nur vergrößert. Letzteres sehe ich als deutlich größeres Problem insbes. für (personell) ressourcenschwache (auf Kurzsicht ) "kosteneffiziente" Betriebe. Wie oft gibt es beim Wechsel / Update breaking changes die dann mit Patchstau und co enden, sofern man denn beim Update überhaupt weiss, welche potentiellen Abhängigkeiten man überhaupt betrachten muss.

Am Ende muss es jeder für sich entscheiden, viele der Wünsche an "kann in der Doku bitte stehen" sind basics die Standards wie ITIL implizit fordern, selbst wenn man es nur als Denkanstoß und nicht nur als akademische Compliance betrachtet. (Wir sind zu klein für sowas, den Overhead von ITIL und co können wir uns nicht leisten vs. wir brauchen viel Technologie damit wir unsere Arbeit besser machen können).

Daher wäre auch bei der Produktauswahl (ich brauche etwas != Exchange mit gleichem Featureset) auch zu betrachten ob Make or Buy (ich habe kein SLES, ich brauche ein anderes OS vs. ich lasse es machen) oder ein anderes Produkt dann in der Gesamtschau die bessere Wahl ist.

stefan_o

Ich würde sagen ein wirklich guter Admin findet Wege, dass er da nichts anderes drauf laufen lassen muss 🙂
Abgesehen natürlich von Hilfsdiensten/Ergänzungen/Tools etc. die für den Mailserver vorgesehen sind.

daniel

Eure Argumente sind korrekt. Ich vertrete den Standpunkt, dass der Admin selbst die Bewertung treffen sollte, was er auf einen Serer nimmt und was er trennen kann bzw. will. Da spielen div. Themen eine Rolle (Know-How, Budget, Use Cases der Software, vorhandene Umgebung, Security, usw.).

In meinem Fall muss ich mich als Exot outen: ich betreibe Grommunio CE als private Mailserverumgebung in einem public gehosteten vServer mit anderen Diensten auf EL9 und schätze sowohl die Features von Grommunio als auch den Fokus auf Security. Die o.g. Admin-"Frickelei" hab ich m.E. im Griff und bin für mein Privatprojekt nicht willig, mehr Budget in Form von mehreren vServern bereitzustellen. Darum wird Grommunio sich ein OS mit anderen DIensten teilen müssen, solange ich es einsetze.
Mir ist aber auch klar, dass erstmal der zahlende Kunde die Referenz ist - und dort wird eine separate VM bei den wenigsten ein großes Thema sein.
Und dass ich seit gut 20 Jahren von SuSE ins Lager der Rothüte gewechselt bin und dort mein Know-How liegt, ist auch nicht Euer Thema ;-).

@WalterH Danke für das Feedback, dass Dir keine Kunden mit Containerisierung bekannt sind. Auch das ist naütrlich ein schlagendes Argument. Ich bin gespannt, ob sich der Demand hier in Zukunft evtl. ändern wird. Meine berufliche Wahrnehmung ist, dass das Thema Kubernetes durch die IT Systemhäuser auch langsam im Mittelstand ankommt. Und einen Docker-/podman-Host zu betreiben, ist wirklich keine Kunst mehr.

Andy

daniel mehr Budget in Form von mehreren vServern bereitzustellen

Das ist nicht notwendig. Auch wenn VM oder Docker verwendet wird, kann alles auf einem Server laufen. Der Invest ist von daher gleich Null.

PiotrPan

daniel : Viele Herausforderungen im Lebenszyklus bleiben aber durchaus, wie das Aktualisieren von Base-Images vs. Abhänigkeiten im Stack.

Am Ende eine Strategiefrage ob man für den eigenen Kontext etwas spart etwas in einer VM zu haben, oder in einem Container, oder als managed service (selbst wenn man eigene Admins hat oder es selbst ist).

AristonPost

Die Diskussion geht doch in die vollkommen falsche Richtung.
Walter's Kunden halten nicht von Containern. Das sind schon seit Jahren, wenn nicht Jahrzehnten genau die richtigen Kandidaten für SUSE. Ich sehe da keinen Grund, das zu ändern.

Aber... es gibt eben auch Kunden, die im Hier und Jetzt leben. Und für die sind Container nicht nur ein "Ding", sondern teilweise seit Jahren ein durchaus valides Betriebskonzept für Applikationen. Und anstatt dutzende von dysfunktionalen Build-Pipelines zu betreiben und bei jeder Gelegenheit das Fehlen von Entwicklerkapazitäten voranzustellen, wäre es vielleicht gar keine so dumme Idee, sich zu fokussieren.

Ich glaube niemand hat etwas dagegen, wenn nur SUSE und eine vernünftige Containerlösung zur Verfügung stehen, Damit meine ich natürlich keine Container-Monolithen mit systemd und anderen Verrenkungen. Die Komplexität von Grommunio und die Fehleranfälligkeit bei den Konfigurationen der Web-Frontends sind einzig und allein die Folge endloser Integrationsversuche, das in die Distributionsstandards zu pressen. IMHO eine vollkommene Zeitverschwendung.

Andy

AristonPost halten nicht von Containern

Da ist nun die Frage, ob damit Docker gemeint ist oder das verallgemeinert auch VM einschliesst. Mit Docker kann ich mich bei einfacheren Applikationen noch anfreunden, aber auch dort ist die Abhaengigkeit von einem Host "nur" nicht so gross gegenueber einer nativen Installation. Der Favorit ist von daher fuer mich die VM und das darin verwendete Linux halte ich dann fuer eher unerheblich.

Von daher ist die Appliance eigentlich die optimale Loesung.