Support-Zeiträume¶
Betriebssysteme¶
Wir setzen für den überwiegenden Teil der von uns betriebenen Server Linux ein.
Die Open-Source Natur dieses Systems, in Kombination mit seiner starken Verbreitung, stellt sicher, dass Sicherheitslücken und andere Probleme nach ihrer Entdeckung zeitnah behoben werden. Da hier keine einzelne Firma die komplette Kontrolle über Linux ausübt wird sichergestellt, dass jedes Problem , für dessen Behebung jemand bereit ist ausreichend Zeit oder Geld zu investieren, auch behoben wird.
Im Linux-Bereich gibt es dann verschiedene, sog. Linux-Distributionen. Diese packen die Software in einer verwendbaren Form zusammen, liefern regelmässig Updates aus, pflegen stabile Versionen von Software nachdem die Quell-Projekte zu neueren Versionen weitergezogen sind, halten nach welche Versionen welche Sicherheitslücken und anderen Fehler beinhalten,…
Manche Distributionen sind für spezielle Aufgaben entwickelt, beispielsweise Knoppix als Live-CD/DVD das komplett ohne Installation auf Festplatte arbeitet oder Core OS als minimalistische Distributionen zur Verwendung mit Docker.
Da nicht jede Distribution Tausende von Software-Paketen selbst pflegen möchte werden spezialisierte Distributionen oft als Ableger der großen, generalisierten Distributionen entwickelt.
Es gibt zwei wesentliche Arten wie Distributionen mit Updates umgeben. Zum einen gibt es die sog. Rolling Release Distributionen. Diese fügen neue Versionen von einzelnen Software-Paketen hinzu sobald diese verfügbar sind. Dies ermöglicht die Verwendung der neuesten Features, aber auch neue Fehler treten natürlich unter Umständen zuerst hier auf. Außerdem muss die Konfiguration der Software angepasst werden wenn eine neue Software-Version dies erfordert. Diese Art von Distributionen wird im wesentlichen auf Desktop-Systemen von erfahrenen Entwicklern eingesetzt, welche in der Lage sind die dabei auftretenden Fehler und notwendigen Anpassungen selbst durchzuführen.
Die andere Art der Distributionen mit Updates umzugehen sind die sog. Point Release Distributionen. Diese bringen alle paar Monate oder Jahre eine neue Version heraus. In dieser finden sich dann vergleichsweise aktuelle Software-Pakete. Zwischen den Versionen dagegen werden nur Sicherheitslücken und Fehler behoben. Neue Features und Änderungen die Konfigurations-Anpassungen notwendig machen bleiben dagegen aussen vor. Dadurch soll die Stabilität der Systemen, auf denen diese Linux Distributionen laufen, erhöht werden.
Diese Distributionen unterstützen Software oft auch noch für ein paar Jahre nachdem die Quell-Projekte eine Version bereits als veraltet ansehen und ihre eigene Unterstützung auf neuere Versionen beschränken.
Einige bekannte Linux-Distributionen sind z.B.
| Name | Updates | basiert auf |
|---|---|---|
| Debian testing | Rolling Release | |
| Debian stable | Point Release | Debian testing |
| Debian LTS | Point Release | Debian stable |
| Ubuntu | Point Release | Debian testing |
| Ubuntu LTS | Point Release | Debian testing / Ubuntu |
| Fedora | Point Release | |
| RedHat Enterprise Linux | Point Release | Fedora |
| Centos | Point Release | RedHat Enterprise Linux |
| openSUSE | Point Release | |
| SUSE Linux Enterprise | Point Release | openSUSE |
| Gentoo | Rolling Release | |
| Arch | Rolling Release |
Bei saltation werden aktuell im wesentlichen Debian, Ubuntu, RedHat Enterprise Linux und Centos eingesetzt. Wenn uns die Wahl überlassen wird, welche Distribution zum Einsatz kommen soll, so wägen wir die vorhandenen Anforderungen ab und wählen diejenige aus, welche diese am besten erfüllt.
Wenn mehrere Distributionen in Frage kommen so wählen wir in der Regel Debian stable. Dies geht nach dem Ablauf der regulären Support-Zeiträume automatisch in Debian LTS über, allerdings sollte das System in dieser Lebensphase nicht mehr für neue Server eingesetzt werden um übermässig häufig Updates zu vermeiden.
Ein Einsatz von Distributionen über den Support-Zeitraum des Herstellers hinaus ist nicht zu empfehlen und wir vermeiden dies wo immer möglich. Die typische Linux-Distribution enthält mehrere Tausend Software-Pakete und Hunderte Millionen Zeilen an Quell-Code. Davon sind einige Hundert Software-Pakete auf dem typischen Server-System und 1000-2000 Software-Pakete auf dem typischen Desktop-System installiert.
Unter normalen Umständen wird jedes einzelne dieser Pakete zunächst von einem eigenen Projekt entwickelt. Diese Projekte bestehen manchmal aus einzelnen Personen, manchmal auch aus großen Teams, je nach Umfang der Software. Diese Projekte betreuen meinst nur die aktuellste Version einer Software und ein paar weitere Versionen. Manchmal sind dies die nächst-älteren Versionen, manchmal auch spezifisch ausgewählte LTS (Long Term Support) Versionen.
Da diese Projekte für die Software selbst meist nur auf Spendenbasis bezahlt werden oder von einzelne Firmen die ein großes Interesse am Erfolg einer Software haben einzelne Entwickler bezahlen, sind die Resourcen hier natürlich begrenzt. Alte Versionen werden daher irgendwann nicht mehr unterstützt.
Dies bewegt sich bei den meisten Projekten zwischen Wochen und Monaten, für LTS-Versionen maximal im Bereich von 2-3 Jahren.
Um Software auch längerfristig in einer stabilen Version einsetzen zu können, d.h. in einer Version die Kompatibilität mit anderen Anwendungen bewahrt und deren Konfiguration nicht nach jedem Update angepasst werden muss, wird diese Wartung der Software für einen längeren Zeitraum von Linux-Distributionen übernommen.
Die Distributionen übernehmen neben der Behebung oft auch die Aufgabe der genauen Verfolgung, welche Fehler und Sicherheitslücken für ein gegebenes Software-Paket existieren, ob Fehler in neuen Versionen auch alte Versionen betreffen.
Hier arbeiten dann Hunderte, Tausende oder mehr Personen zusammen um die Pflege der Software-Pakete zu gewährleisten. Oft kennen diese Personen die Pakete nicht so gut wie die Entwickler aus dem Quell-Projekt aber für die Behebung vieler Fehler und Sicherheitslücken ist dies auch nicht unbedingt notwendig. In vielen Situationen reicht es hier auch aus, vorhandenen Code zur Behebung von Fehlern und Sicherheitslücken an die ältere Version der Software anzupassen. Einzelne Teams und Personen betreuen hier oft Dutzende von Software-Paketen gleichzeitig.
Mit zunehmendem Alter der Distributionen konzentrieren sich mehr und mehr der freiwilligen Helfer auf neuere Versionen der Software oder der Distributionen und die Distributions-Teams zur Wartung der Software werden kleiner. Fehlerbehebungen beschränken sich auf schwerwiegende Sicherheitslücken und Fehler.
Nach dem Support-Ende einer Distribution werden also Pakete oft von den eigentlichen Entwicklern der Software schon lange als veraltet angesehen, die meiten Distributions-Entwickler fokussieren ihre Resourcen auch bereits seit einiger Zeit auf neurere Versionen und selbst das Nachhalten welche Probleme die alten Versionen der Software betreffen werden mit dem Support-Ende abgeschaltet oder jedenfalls nicht mehr aktualisiert.
Diese Arbeit, die normalerweise von einer Vielzahl an Personen geleistet wird kann natürlich keine einzelne Firma mal eben nebenbei übernehmen, egal wie wichtig die Systeme sind um die es geht. Daher nimmt durch den Einsatz einer Distribution nach dem Support-Ende das Risiko von nicht behebbaren Fehlern und von Angreifern verwendbaren Sicherheitslücken stark zu.
Dies lässt sich inbesondere, aber nicht nur, bei Systemen mit Datenschutz-relevanten Informationen nicht verantworten, da z.B. die DSGVO hier klare Vorgaben macht.
Daher sollte ein regelmässiges Update des Betriebssystems, etwa alle 2-4 Jahre, in langfristige Projekte eingeplant werden. Da neuere Betriebssysteme natürlich nicht mit alten Projekten kompatibel sind (z.B. weil sie eine neuere PHP-Version mitbringen) sind dann oft auch Anpassungen an der Anwendung notwendig.
Eine regelmässig Anpassung der Version ermöglicht es auch, Update-Probleme in kleineren Häppchen anzugehen. Wenn Probleme bei einem Update auftreten, ist es von Vorteil nicht alle Probleme der letzten 6-8 Jahre auf einmal lösen zu müssen sondern immer nur 2-3 Jahre auf einmal.
Kleinere Versions-Updates der einzelnen Software-Pakete in einer Distribution, insbesondere Sicherheitsupdates, müssen natürlich viel häufiger eingespielt werden (mind. 1 mal pro Woche), diese erfordern aber normalerweise keine Anpassungen an der Anwendung. Maximal erfordern einige dieser Updates einen kurzen Neustart des Servers. Wir können gern ein wöchentliches Wartungsfenster vereinbaren in dem diese Updates durchgeführt werden sollen um den Verwaltungsaufwand zu minimieren.
Debian Linux¶
Debian hat ein System aus Versionsnummer und Codenamen für jede Version. Die Codenamen sind den Toy Story Filmen entnommen. Außerdem hat jede halbwegs aktuelle Version von Debian eine Bezeichnung ihrer Funktion im Debian Lebenszyklus. Diese Bezeichnung ändert sich wenn eine neue Version von Debian heraus kommt.
Neue Software-Pakete die in Debian aufgenommen werden landen zunächst in Debian unstable (Codename ist immer sid). Dort werden Sie dann auf ihre Funktion getestet. Hier können sich Versionen finden die nicht zusammen passen und Pakete können sogar auch wieder entfernt werden.
Nach der ersten Abnahme werden die Pakete dann in Debian testing übernommen. Der Codename von Debian testing ist der Codename der nächsten Version von Debian die in der Zukunft veröffentlicht wird. Einige Monate vor der Veröffentlichung der neuen Version wird hier ein sog. Feature Freeze verhängt, d.h. ab diesem Zeitpunkt dürfen Entwickler nur noch Fehler beheben.
Wenn alle schwerwiegenden Fehler behoben sind wird die neue Version dann als Debian stable veröffentlicht. Zu diesem Zeitpunkt wird aus der alten Debian stable Version dann Debian oldstable und aus der Version davor Debian oldoldstable.
Das Debian Projekt unterstützt dann die alte Version von Debian stable noch für etwa ein Jahr weiter. Danach wird die Unterstützung vom Debian LTS Projekt übernommen, welches einen eingeschränkten Support leistet, in der Regel für etwa zwei weitere Jahre. Pakete die aus den neueren Debian-Versionen in eine ältere Version portiert wurden (backports) werden vom LTS-Projekt nicht unterstützt.
Aktuell (September 2018) sieht das ganze z.B. so aus
| Version | Funktion | Codename | Support |
|---|---|---|---|
| 7.x | oldoldstable | wheezy | kein Support |
| 8.x | oldstable | jessie | Support durch LTS-Projekt |
| 9.x | stable | stretch | Support durch Debian-Projekt |
| 10.x | testing | buster | noch in Entwicklung |
| unstable | sid | Teil des Entwicklungs-Prozesses |
Die Verwendung von Debian ist kostenlos.
Weitere Informationen finden Sie hier
Ubuntu Linux¶
Ubuntu ist ein Ableger von Debian und jede neue Version basiert auf den jeweils zum Beginn der Entwicklung aktuellen Debian testing Paketen. Natürlich fliessen auch einige Eigen-Entwicklungen aus vorhergehenden Ubuntu-Versionen mit ein.
Ubuntu bringt alle 6 Monate (April und Oktober) eine neue Version heraus. Die Versionsnummer ist dabei immer aus den letzten beiden Ziffern des Jahres und dem Monat zusammen gesetzt (z.B. die Version im April 2018 hat Version 18.04, die Version im Oktober 2018 hat Version 18.10).
Normale Ubuntu Versionen werden etwa 9 Monate unterstützt.
Alle zwei Jahre, jeweils in geraden Jahren ist die April-Version von Ubuntu ein Long Term Support Version (Ubuntu LTS). Diese wird länger unterstützt. Wenn wir Ubuntu bei saltation einsetzen so beschränken wir dies in der Regel auf diese LTS-Versionen.
Diese Kern-Pakete der LTS-Versionen werden 5 Jahre unterstützt, weitere Pakete sind verfügbar und werden 3 Jahre unterstützt. Einzelne, besonders problematische Pakete, haben Sonder-Regelungen mit kürzerer Unterstützung.
Ubuntu-Versionen haben neben der Versions-Nummer immer noch einen Code-Namen, dieser setzt sich aus einem Adjektiv und einem Tiernamen zusammen. Für eine gegebene Ubuntu-Version beginnen beide mit dem gleichen Buchstaben. An Stellen wo ein Debian-artiger Codename aus einem Wort benötigt wird steht das Adjektiv allein für die jeweilige Ubuntu-Version. Die Buchstaben sind in alphabetisch aufsteigender Reihenfolge von Version zu Version.
| Version | Support | Codename | Debian Codename |
|---|---|---|---|
| 16.04 | LTS | Xenial Xerus | xenial |
| 16.10 | normal | Yakkety Yak | yakkety |
| 17.04 | normal | Zesty Zapus | zesty |
| 17.10 | normal | Artful Aardvark | artful |
| 18.04 | LTS | Bionic Beaver | bionic |
Die Verwendung von Ubuntu ist kostenlos.
Wir setzen Ubuntu auf Kundenwunsch ein, bevorzugen aber Debian wenn der Kunde selbst keine besonderen Vorlieben hat und keine sonstigen Einschränkungen existieren.
Weitere Informationen finden Sie hier
RedHat Enterprise Linux¶
RedHat Enterprise Linux (RHEL) ist eine kommerzielle Linux-Distribution. Die Verwendung von RHEL erfordert eine Lizenz um Updates und ggf. Support von RedHat zu erhalten.
RedHat Versionen setzen sich aus einer Major Version (z.B. die 7 in 7.6) und einer Minor Version (z.B. die 6 in 7.6) zusammen. Pakete werden über eine Major Version hinweg stabil gehalten. Kleinere Änderungen und neue Features passieren im Rahmen der Minor Versions Updates.
Zwischen den Major Versionen liegen mehrere Jahre. Minor Versionen kommen in der Regel 1-2 mal pro Jahr heraus. Es gibt keinen festen Zyklus wann diese Versionen herauskommen.
Die günstigste Lizenz beinhaltet nur Updates für die jeweils neuste Minor Version einer Major Version. Support im Sinne von Tickets oder Telefonanrufen ist nur in den höheren Lizenzstufen enthalten. Auch Updates für ältere Minor Versionen sind für manche davon erhältlich (i.d.R. nicht für die .0 Version).
RedHat unterteilt seine Unterstützung in mehrere Phasen. Der volle Support und auch einige der Leistungen, wie z.B. Updates für ältere Minor Versionen, ist nur in der ersten Phase erhältlich. Diese dauert 5 1/2 Jahre. Auch Support für aktuelle Hardware wird nur in dieser Phase eingebaut.
In der nächsten Phase, welche 1 Jahr dauert, wird der Support schon stärker zurück gefahren. Hier gibt es zwar noch Sicherheits-Updates und schwerwiegende Fehler werden behoben, für Systeme die direkt auf Hardware laufen wird allerdings nur noch sehr eingeschränkt entwickelt. Dies ist normalerweise die Phase in der der Umstieg auf eine neue Major Version empfohlen wird.
Danach kommt noch eine weitere Phase von 3 1/2 Jahren mit Sicherheitsupdates und der Behebung von Fehlern, aber ohne neue Hardware-Unterstützung. Hier wird nur noch garantiert dass die Version auf virtuellen Maschinen weiter läuft.
Nach diesen insgesamt 10 Jahren ist es zwar noch möglich weiteren Support von RedHat zu kaufen (gegen Aufpreis), allerdings nur für bestehende Systeme, ohne Sicherheitsupdates, Hardware-Support, Fehlerbehebung und mit dem einseitigen Recht von RedHat’s Seite diesen Support jederzeit kündigen zu können.
Generell verwenden wir RHEL nur dann wenn eine besondere Anforderung von Kundenseite besteht. Aufgrund der langen Support-Zeiten sind die Pakete in RHEL oft stark veraltet im Vergleich zu anderen aktuellen Distributionen. Auch die Anzahl der Pakete ist deutlich reduziert.
Wir bestehen natürlich auch darauf, dass mindestens eine Lizenz pro System für Updates vorliegt wenn RHEL eingesetzt werden soll. Ohne diese Lizenz ist es nicht sinnvoll möglich ein RHEL einzusetzen da weder Sicherheits-Updates und Updates zur Fehlerbehebung noch neue Software installiert werden können.
Weitere Informationen finden Sie hier
Centos¶
Ist ein Lizenz-Kauf von RHEL nicht gewünscht aber andere Erwägungen schliessen trotzdem Debian oder Ubuntu aus und lassen nur RHEL zu (z.B. alte PHP-Version) so ist es möglich statt dessen Centos zu verwenden. Diese Distribution basiert auf den von RHEL veröffentlichten Paketen und entfernt dort im wesentlichen das Branding.
Centos versucht sehr kompatibel mit RHEL zu bleiben, ist aber nicht identisch.
Updates werden ebenfalls für 10 Jahre zur Verfügung gestellt und Major-Versionen sind an RHEL angelehnt.
Centos verwenden wir bei saltation wenn Software auf alten Versionen weiter laufen muss so lange ein Ersatz entwickelt wird oder wenn wir interne Test-Systeme benötigen deren Produktiv-Version auf RHEL läuft.
Aufgrund der stark veralteten Versionen (identisch zu RHEL) empfehlen wir den Einsatz von Centos nicht für Neu-Entwicklungen wenn sich dies vermeiden lässt.
Weitere Informationen finden Sie hier
