News Linux: Debian 7 Wheezy erhält LTS-Unterstützung

fethomm

Commander
Registriert
Okt. 2012
Beiträge
2.597
Drei Jahre nach seiner Veröffentlichung geht die Unterstützung für das als Oldstable bezeichnete siebte Debian-Release Wheezy an das LTS-Team über. Damit ist die normale Lebenszeit eines Debian-Release zu Ende. Das LTS-Team kümmert sich noch zwei Jahre bis zum 31. Mai 2018 um die Software.

Zur News: Linux: Debian 7 Wheezy erhält LTS-Unterstützung
 
Hat sich mal jemand die Mühe gemacht die verschiedenen LTS-Angebote zu vergleichen? Ich habe nur mal aufgeschnappt, dass es bei Ubuntu mit dem Paketsupport auch gar nicht so rosig sein soll.

Ich wurde z.B. kürzlich ziemlich desillusioniert von RHEL/CentOS, als ich feststellen musste, dass der Kernel von EL6 (Support bist 2021) nicht fit für Docker gehalten wird (offiziell kein Support mehr für Docker), was aus meiner Sicht ein absolutes Unding ist angesichts der Bedeutung von Docker.
Zudem ist die Python2-Version auf 2.6, was auch langsam beginnt Probleme zu bereiten (hatte schon einen konkreten Bug bzgl. TLS SNI in Ansible, welches sehr abhängig von Python ist, für den sich glücklicherweise ein workaround fand und erst gestern habe ich eine deprecation warning für 2.6 von einem Python-Cryptomodul gesehen).

Als ich den Artikel las, erwartete ich eine große Zahl von wichtigen Paketen, die eventuell nicht mehr unterstützt würden. Als ich die Liste dann sah, war ich erleichtert. Das ist nun wirklich alles Schnulli, den entweder keiner (mehr) braucht oder den man in einem Docker-Container laufen lassen kann. Vielleicht mausert sich Debian ja zur guten Wahl für Server.

Durch Docker ist man heute eigentlich gar nicht mehr so abhängig von dem Paketsupport der Host-Distro, aber der Kernel muss eben entsprechend fit gehalten werden.
 
Zuletzt bearbeitet:
Vielleicht ne naive Frage, aber wenn du eh Kernel und alle möglichen Pakete updaten willst - was spricht gegen ein Upgrade?
 
Heutzutage sicherlich weniger, als noch vor 5 Jahren. Ich verbinde dist-upgrades mit Totalausfällen (Kernel Panic usw.) und unerwartetem Wegbrechen von Funktionalität (z.B. kein sysvinit mehr sondern systemd). Wenn sowas auf einem System geschieht, was mit viel Aufwand händisch hingeklöppelt wurde (sowas war normal und ist es vielerorts sicher heute noch), dann kann da schon einiges verloren gehen.

Es ist einfach mit mehr Risiko verbunden, als ein normales Update und diese Risiken sind zudem schwerer einzuschätzen, gerade wenn die neue Version so einschneidende Veränderungen wie systemd bringt. Dementsprechend musst du den Zahlenmeister überzeugen, dass es das Risiko wert ist und man darin investieren sollte. Für einen Server, den man sein Eigen nennt und um den kein anderer weint, kann man dieses Risiko leichter selbst tragen, aber das ist eben leider nicht immer so.

In Zeiten von infrastructure as code ändert sich das natürlich. Man arbeitet mit "Wegwerf-Servern", die man jederzeit frisch bootstrappen kann. Die Lebenszeit einer solchen Instanz kann im Bereich von Tagen liegen und man braucht nahezu gar keine Pakete mehr auf dem OS, sondern nur noch einen Docker-Daemon und ein paar Tools zur Steuerung der Container-Landschaft (siehe CoreOS). Aus dieser Perspektive ist LTS recht unnötig.

So verbreitet ist das aber, glaube ich, noch nicht. Die klassischen, handgeklöppelten Server werden noch eine Weile ihr Dasein fristen und für dieses Szenario, finde ich, sollten gewisse Pakete anständig gepflegt werden. Vielleicht ist das subjektiv, aber Pakete wie Python, httpd, varnish, nginx, et al., sind meiner Meinung nach ein Muss.

Meine Ansicht ist sicherlich sehr Server-lastig. Für Desktop bin ich Freund von rolling release und häufigen Updates. ;)
 
@fuyuhasugu

LTS bedeutet nur eine verlängerte Versorgung mit Sicherheitsupdates und nicht das ständige einbringen der aktuellsten neuesten super-duper-software. Das würde allein bei der Stärke der LTS-Teams absurd anmuten.

Tumbleweed schrieb:
Hat sich mal jemand die Mühe gemacht die verschiedenen LTS-Angebote zu vergleichen?

http://www.pro-linux.de/artikel/2/1782/linux-distributionen-mit-langzeitunterstuetzung-lts.html

Das fand ich ganz hilfreich und bin danach von Ubuntu 14.04 auf CentOS 7 umgestiegen.
Mit Epel und Nux lässt sich ein durchaus Multimedia- und Steam-taugliches System draus machen, mal abgesehen davon das man auch aktualisierte Pakete der gängigen Server-Software bekommt :)

Wenn man das System nicht um diese Paketquellen erweitert steht man von Seiten RedHat natürlich bzgl. Docker und Co. im Regen, da die natürlich auf V7 verweisen da mit jedem Jahr der Support von V6 dünner wird (sonst wäre ein derartig langer Support kaum realisierbar), den heftigsten Abfall gibt es da natürlich seit dem neuen Realease, welches ebenfalls das Schicksal ereilen wird mit der Veröffentlichung von CentOS 8.
 
Zuletzt bearbeitet:
Gibt es eine Möglichkeit auf Jessie upzudaten OHNE dass von vorherein Systemd mit drauf kommt?
Ich frag' nur weil ich mal meine Raspi-Installation damit zerschossen habe.
 
Wir habe noch zwei Server mit Debian 7 am laufen liegt aber auch nur daran weil wir aktuell noch nicht dazu gekommen sind zu Upgraden. Früher oder später wird dies eh passieren müssen da Drupal 8 min. PHP 5.6 will und das gibt es nur mit Jessie. Klar könnte man es installieren aber heute sind upgrades kein Problem mehr. Man sollte halt wie immer ein vollständiges Backup machen.

Deswegen kann ich LTS Releases heute nicht mehr verstehen. LTS ist ein überholtes Konzept aus alten Tagen an dem Sicherheit, bei selbst geschriebener Software, keine Rolle gespielt hat und man einmal etwas in PHP geschrieben hat und das hielt für 10 Jahre. Das ist heute nicht mehr so und man sollte von diesem Denken weg kommen. Heute ist wichtig Updates zu entwickeln und seine Software stetig zu verbessern und zum Teil schon auf neue Versionen vorzubereiten. Alles was wir heute schreiben sollte problemlos oder mit sehr kleinen Anpassungen unter PHP 7 laufen und bei Python sind wir auch weg von 2.x und auf 3.x.

@Nebula123

Nein nicht möglich. Aber du kannst es deinstallieren:

http://without-systemd.org/wiki/ind...systemd_from_a_Debian_jessie/sid_installation

Wobei wir haben div. Debian 8 installationen und ich kann erhlich gesagt kein Unterschied feststellen.
 
Schnitz schrieb:
LTS bedeutet nur eine verlängerte Versorgung mit Sicherheitsupdates
Wie gerade auf mehreren IT-Seiten thematisiert wurde, trifft eben das nur in sehr eingeschränktem Maße zu.

und nicht das ständige einbringen der aktuellsten neuesten super-duper-software.
So weit, wie z.B. LibreOffice manchen notwendigen oder zumindest selbstverständlichen Funktionen von MS Office hinterherhängt, ist es gerade im Büroalltag recht wichtig eine einigermaßen aktuelle Version des Offic-Paketes zu benutzen. Und die Assoziation "super-duper-software" kommt einem da ganz bestimmt nicht. ;-)

Cool Master schrieb:
aber heute sind upgrades kein Problem mehr.
Was bei verschiedenen Updates auf eine neuere KDE-Version plötzlich alles nicht mehr ging bzw. was systemd z.T. für Probleme macht, weil Abhängigkeiten nicht geklärt sind (Zuständigkeiten sowieso nicht) usw. usf.

Man sollte halt wie immer ein vollständiges Backup machen. ... Deswegen kann ich LTS Releases heute nicht mehr verstehen. LTS ist ein überholtes Konzept
Alleine um sich oben genannten Ärger nicht alle halbe Jahre oder gar noch öfter antun zu müssen, sind LTS notwendig. Für einen Heimrechner oder einen dedizierten PC auf dem ein bisschen PHP gemacht wird, ist das recht egal, für die meisten Sachen ist aber einfach der Aufwand zu groß, eben weil i.a. nicht alles glatt geht und auch immer wieder größere Änderungen einfließen, sei es grub(2) oder systemd auf der Betriebssystemebene oder Anwendungssoftware wie KDE o.ä. Es sind oft nur vglw. kleine Änderungen, die dem Programmierer überhaupt nicht als Problem auffallen (z.B. Änderung der Ordnerstruktur der programmspezifischen Dateien), die dann aber doch zu nicht zu vernachlässigenswerten Problemen führen.

aus alten Tagen an dem Sicherheit, bei selbst geschriebener Software, keine Rolle gespielt hat und man einmal etwas in PHP geschrieben hat und das hielt für 10 Jahre. Das ist heute nicht mehr so und man sollte von diesem Denken weg kommen.
Du meinst die Software, die wir als ersten Versuch in der Mittelstufe zusammengezimmert haben? Bei mir gab es zwar auch danach noch welche, aber das waren nur Steurungsrechner mit Spezialhardware, die definitiv keinen Netzzugang bekamen und die auch mit dem einen Softwaretask vollkommen ausgelastet waren. Multitasking verbot sich da schon wegen der Echtzeitfähigkeit.
Apropos 10 Jahre Haltbarkeit: deine Argumentation liest sich ein wenig wie ein Plädoyer für geplante Softwareobsoleszenz.
 
Zuletzt bearbeitet:
Cool Master schrieb:
Deswegen kann ich LTS Releases heute nicht mehr verstehen. LTS ist ein überholtes Konzept aus alten Tagen an dem Sicherheit, bei selbst geschriebener Software, keine Rolle gespielt hat und man einmal etwas in PHP geschrieben hat und das hielt für 10 Jahre. Das ist heute nicht mehr so und man sollte von diesem Denken weg kommen.

In Bezug auf Debian und Ubuntu gebe ich Dir Recht.

In Bezug auf RHEL/SLES trifft dies nicht zu. Es gibt genügend Firmen/Behörden die alte Fachanwendungen mit aufgeblähten Datenbanken über eine Dekade betreiben. Nur wurde die Fachanwendung einst entwickelt und ist seitdem eingefroren - dann macht man ein Dist-Upgrade und merkt: "Mist - 500 Abhängigkeiten nicht erfüllt - aber die Entwickler der Fachanwendung von 1999 sind mittlerweile alle tot! :eek:" (Worst-Case aber das habe ich tatsächlich schon so erlebt) Und eine Doku geschweige hinweise im Quellcode (sofern offen) sind nicht vorhanden. Da braucht man schon eine gewisse Sicherheit.

Und jetzt hast Du genau diesen Fall: Fachanwendung auf RHEL5 von 2007, willst dann 2014 auf RHEL7 upgraden und merkst: "Mist - nach 7 Jahren und zwei Versionssprüngen ist der Aufwand immens - da ist eine neue Fachanwendung + Migration der DB deutlich billiger als den alten Kram anzupassen. Aber Super: Dafür habe ich ja noch 3 Jahre Zeit da RHEL5 bis 2017 Support erhält!"

fuyuhasugu schrieb:
Wie gerade auf mehreren IT-Seiten thematisiert wurde, trifft eben das nur in sehr eingeschränktem Maße zu.

Das ist richtig. Aber gerade im Server-Bereich sind viele nicht in LTS eingeschlossene Pakete von Anfang an außen vor - und man sollte das System sowieso härten, wenn man es ernst meint.
 
Zuletzt bearbeitet:
Pupp3tm4st3r schrieb:

Schrieb ich ja das es möglich ist aber wollen wir nicht da Upgrades praktisch kein Problemmehr machen.

fuyuhasugu schrieb:
Was bei verschiedenen Updates auf eine neuere KDE-Version plötzlich alles nicht mehr ging bzw. was systemd z.T. für Probleme macht, weil Abhängigkeiten nicht geklärt sind (Zuständigkeiten sowieso nicht) usw. usf.

Da wir nur Server mit Debian betreiben haben wir kein Desktop daher kann ich da nichts zu sagen. Wir haben zwar auch einige Desktops mit Debian aber da läuft Gnome und auch da gilt nie Probleme gehabt mit dem Upgrades. Sei es von 5 auf 6 von 6 auf 7 oder von 7 auf 8.

fuyuhasugu schrieb:
Apropos 10 Jahre Haltbarkeit: deine Argumentation liest sich ein wenig wie ein Plädoyer für geplante Softwareobsoleszenz.

Im Prinzip ja. Aber das muss es auch sein. In viel zu vielen Unternehmen läuft alte SW die längst nicht mehr ans Netz gehört. Man muss die Software halt pflegen. Einmal schreiben und vergessen ist heute total fahrlässig und sollte auch verboten werden. Es muss ja keine Major Upgrades geben aber wenn ich sehe, dass einige Unternehmen heute noch z.B. auf PHP 4 setzen kann ich das nicht wirklich nachvollziehen.

Schnitz schrieb:
In Bezug auf RHEL/SLES trifft dies nicht zu. Es gibt genügend Firmen/Behörden die alte Fachanwendungen mit aufgeblähten Datenbanken über eine Dekade betreiben. Nur wurde die Fachanwendung einst entwickelt und ist seitdem eingefroren - dann macht man ein Dist-Upgrade und merkt: "Mist - 500 Abhängigkeiten nicht erfüllt - aber die Entwickler der Fachanwendung von 1999 sind mittlerweile alle tot! :eek:" (Worst-Case aber das habe ich tatsächlich schon so erlebt) Und eine Doku geschweige hinweise im Quellcode (sofern offen) sind nicht vorhanden. Da braucht man schon eine gewisse Sicherheit.

Ja, wobei es das natürlich nicht geben würde wenn es inkrementelle Updates geben würde. Genau das meinte ich ja mit:

Heute ist wichtig Updates zu entwickeln und seine Software stetig zu verbessern und zum Teil schon auf neue Versionen vorzubereiten.

Schnitz schrieb:
Und jetzt hast Du genau diesen Fall: Fachanwendung auf RHEL5 von 2007, willst dann 2014 auf RHEL7 upgraden und merkst: "Mist - nach 7 Jahren und zwei Versionssprüngen ist der Aufwand immens - da ist eine neue Fachanwendung + Migration der DB deutlich billiger als den alten Kram anzupassen. Aber Super: Dafür habe ich ja noch 3 Jahre Zeit da RHEL5 bis 2017 Support erhält!"

Ja das ist halt wie immer ein zweischeidiges Schwert. Klar ist es super wenn man sich nicht drum kümmenr muss und es somit keine Kosten verursacht. Ich sehe es aber mittlerweile selber, dass man doch lieber pro Jahr noch mal ein paar Tausend Euro in die Hand nimmt und in Updates/Upgrades investiert.

Ich arbeite gerade an einem Verwaltungsprogramm und schreibe es aktuell in PHP 5.6. Allerdings bereite ich es schon auf PHP 7 vor, zumindest einige Module. Einfach weil dies mMn wichtig ist.
 
Zuletzt bearbeitet: (Zitate der richtigen Person zugeordnet ;))
Cool Master schrieb:
Ich arbeite gerade an einem Verwaltungsprogramm und schreibe es aktuell in PHP 5.6. Allerdings bereite ich es schon auf PHP 7 vor, zumindest einige Module. Einfach weil dies mMn wichtig ist.

Das ist eine sehr lobenswerte Einstellung!

Aber leider haben viele Projektleiter mehr für Quick-and-Dirty übrig ergo billig, was auch am fehlenden Verständnis dieser Leute liegt.
 
@Cool Master - du hast mich da bissl falsch verlinkt/zitiert :D
 
@Schnitz

Ja das war auch noch vor ein paar Jahren meine Einstellung. Seit dem ich aber die Projekte Leite habe ich da ein anderen Blick drauf. Klar es ist auf den ersten Punkt teurer well man mehr Mannstunden hat ABER in Zukunft erleichtert man sich so verdammt viel Arbeit das man praktisch für die Zukunft arbeitet und man beim PHP 7 Rollout binnen weniger Tage Up2Date ist. Ich lege auch extrem viel Wert auf Doku, Benutzerhandbuch und Kommentare im Code. Vor allem bei den Kommentaren bin ich sehr allergisch wenn die nicht vorhanden sind.

@Pupp3tm4st3r

Sorry, ist korrigiert.
 
Joar ist logisch deswegen sollte man das auch nicht machen :D Wie gesagt ich habe einige Server mit Jessie und ich habe überhaupt kein Unterschied zu Wheezy feststellen können.
 
Zurück
Oben