„Also diese Businesssoftware braucht RHEL oder Centos, weil das 6 Jahre eine stabile Umgebung garantiert.“
Solche Sätze kennt man vermutlich in der IT Szene zu Hauf, auch ich habe das schon von Kunden gesagt bekommen, die z.b. einen EPages Server betreiben wollten.
Sicher, aus Unternehmenssicht ist so ein Langzeitsupport erstmal eine gute Idee, allerdings genau bis zu dem Tag, an dem die 6 Jahre um sind. Für Großunternehmen ist da sicherlich kein Problem, da die Monate vorher eine Agentur beauftragen, die das auf einer neuen LTS Version zum Laufen bekommen sollten, für viel Geld übrigens.
Kleine Unternehmen werden den Tag verfluchen, an dem Ihnen Ihr IT-Betrater das aufgeschwatzt hat. Ich habe auf unseren Servern bereits 8 OS Upgrades durchgeführt, was alle 6 Monate ansteht und kann daher aus Erfahrung sagen, daß die vergleichsweise winzigen Änderungen, von sagen wir mal F22 auf F23, den Kunden überhaupt nicht auffallen. Selbst bei größeren Sachen, wo sich die PHP Version von 5.4 auf 5.5 geändert hat, hatten die meisten Kunden keine Probleme, weil deren Softwareupdates sauber eingespielt waren und schon lange vor unserer Umstellung, die neuen PHP Versionen verkraftet haben. Nur die Kunden mit Webanwendungen ohne Updates, die mußten von Hand ran und die 3 störensten Änderungen am Code selbst vornehmen, was aber dank der wenigen Änderungen pro OS Upgrade, immer nur wenig Zeit in Anspruch nimmt.
Dazu kommt, daß Projekte wie Typo3 / WordPress / Joomla in kurzen Zyklen entwickelt und aktualisiert werden, so daß es schon aus diesem Grund angeraten ist, mit diesen Updates mitzugehen. Kleine Änderungen sind im Alltag von kleinen Unternehmen zudem wesentlich leichter zu stemmen und zu koordinieren, als massive Änderungen nach 6 Jahren. Davor kapitulieren die Unternehmen dann nämlich und lassen die Agenturen für viel Geld komplett neue Versionen Ihrer Shops aufsetzen. Merke: Wer ständig auf Stand bleibt, spart am Ende viel Geld.
Deswegen halte ich LTS aus meiner Erfahrung für den falschen Weg. Dabei ist es eigentlich egal, ob es sich um Server oder Desktops handelt, am Ende geht viel Zeit und Geld drauf, wenn das LTS abgelaufen ist.
Das kann ich leider bestätigen.
Schlimmer noch finde ich das es anscheinend manch einem „zu viel“ Geld kostet das Programm anzupassen zu lassen und man deshalb lieber auf dem alten OS sitzen bleibt.
In einem Großunternehmen, wie bei uns, ist das vlt nun eher weniger von Bedeutung da hier diverse Abteilungen für die nötige Sicherheit sorgen, dennoch werden auch genügend Kleinunternehmer das so halten.
Ich kann deine Grundidee verstehen, trotzdem halte ich es persönlich nicht für sinnvoll in einer Produktivumgebung auf non-LTS zu setzten. Das hat einen einfachen Grund, non-LTS Releases haben einen sehr kurzen Supportzeitraum. Ubuntu beispielsweise supportet non-LTS nur noch 9 Monate, wenn ich in dieser Zeit nicht dazu komme meine Systeme zu aktualisieren, weil gerade ein großes Projekt ansteht oder, warum auch immer, gerade keine Zeit dazu da ist, stehe ich am Ende des Tages mit Servern da, die nicht mehr mit Sicherheitsupdates versorgt werde. Wenn man bei LTS Servern natürlich wartet, bis der Support fast abläuft sag ich dazu nur, selbst schuld 😉 Wer hält einen denn davon hab schon währen der Supportlaufzeit auf die nächste veröffentlichte LTS zu wechseln?
Ubuntu unterstützt die LTS Version 5 Jahre lang. Sprich man kann/muss erst, wenn man 14.04 LTS einsetzt, im April 2018 oder im Januar 2019 auf Ubuntu 18.04 aktualisieren
Es ist aber jedem selbst überlassen ob er LTS Versionen einsetzt oder nicht und ob er updatet oder nicht
Für eine kleine Anzahl an Servern oder eine grosse Anzahl identischer Server mit gleicher Applikation mag das gehen.
Wenn Du den Testaufwand einrechnest und davon ausgehst, dass Serverupdates / Upgrades durch alle Stages (Engineering / Development / Test / Acceptance / Production) durchgeführt werden, dann ist es „auf einmal“ sinnvoll, auch langfristig unterstützte Versionen einzusetzen.
Anders gäbe es auch ein Terminproblem, alle Applikations- und Plattform-Teams unter einen Hut zu bringen. Erfahrungsgemäss machen selbstgeschriebene Applikationen weniger Probleme als gekaufte Software.
Wir haben eine zwar vom OS her eine hetrogene Umgebung, aber ein Kuddelmuddel am Webapps, auf Tomcat, Apache & Docker verteilt. Klappt an sich ganz gut mit dem 6 Monate Rythmus von Fedora.
Wir machen das so, daß Testserver mit Livedaten drauf 6 Monate Versuchskaninchen sind, also gleich die brandaktuelle Version haben und nach 6 Monaten ziehen die Produktionsserver nach. Dann hat man ein halbes Jahr Testumgebung und ein halbes Jahr Updates aus dem Repo. Die Testserver upgraden dann auf die nächste Version und das geht immer so weiter. Meisten sind das nur zwei, drei Anweisungen die man außer dem „dnf upgrade“ Kommando zusätzlich machen muß, weil Pakete wegfallen, oder neue dazu kommen. Die meiste Zeit, während der Wartung, warte ich nur darauf, daß die Pakete runtergeladen und installiert werden 😉
Noch besser finde ich Rolling Distributionen. Dort plätchern die Updates nach und nach rein und man kann sich dann gezielt darum kümmern.