Canonical verlengt ondersteuningsduur Ubuntu 14.04 en 16.04

Canonical breidt zijn Extended Security Maintenance-aanbod uit naar de lts-releases van Ubuntu 14.04 en Ubuntu 16.04. Dat betekent dat klanten met een abonnement tien jaar ondersteuning vanaf de releasedatum krijgen.

De uitbreiding van de levensduur van de Ubuntu-versies maakt dat de ondersteuning van 14.04 Trusty Tahr nu in april 2024 in plaats van in april 2022 eindigt en dat die van 16.04 Xenial Xerus in april 2026 in plaats van in april 2024 ten einde is. Ubuntu 14.04 en 16.04 verschenen in respectievelijk 2014 en 2016.

In beide gevallen gaat het al om zogenoemde long term support-releases. Canonical heeft om de twee jaar lts-releases op zijn planning staan. Ubuntu 18.04 LTS was in 2018 de eerste versie die als onderdeel van een Extended Security Maintenance-aanbod tien in plaats van vijf jaar ondersteuning kreeg.

Dat aanbod is nu dus uitgebreid naar de oudere releases, waarmee ook gebruikers van deze software langere tijd beveiligingsupdates en kernel-livepatches tegemoet kunnen zien. Volgens Canonical krijgen ze zo extra tijd om hun upgradeplannen te implementeren.

De verlengde ondersteuning betreft alleen fixes voor kwetsbaarheden die de aanduiding 'hoog' en 'kritiek' krijgen. Bij Ubuntu 14.04 LTS betreft de ondersteuning de 64bit-x86-versie, terwijl bij 16.04 LTS s390x, Arm64 en x86-64 ondersteund wordt. Voor enterprisegebruikers gaat het om betaalde ondersteuning, maar voor persoonlijk gebruik is ESM onderdeel van het Ubuntu Advantage Essential-abonnement, dat gratis is voor individuen met een maximum van drie systemen.

Release	Releasedatum	End-of-life (geen updates na deze datum)
Ubuntu 14.04 (Trusty Tahr)	April 2014	April 2024 (was april 2022)
Ubuntu 16.04 (Xenial Xerus)	April 2016	April 2026 (was april 2024)
Ubuntu 18.04 (Bionic Beaver)	April 2018	April 2028 (ongewijzigd)
Ubuntu 20.04 (Focal Fossa)	April 2020	April 2030 (ongewijzigd)

Reacties (64)

[thePiett]

Aan de ene kant mooi om te zien, aan de andere kant is dit uitstel van executie voor luie sysadmins

[divvid]

sysadmins kunnen soms gedwongen worden legacy zaken te blijven ondersteunen, b.v. in langlopende (>10y) onderzoeken waar het van groot belang is dat de analyse software intussen niet veranderd. Als dat alleen op een bepaalde versie van een OS draait ben je dus als sysadmin niet lui, maar moet je naar een creatieve oplossing zoeken.
Bij ons draait er b.v. een WinXP in een container om een oud meetapparaat te ondersteunen. Vervanging zou 230k+ kosten om na afloop van de huidige meetcyclus nooit meer gebruikt te worden. Ergo, management zegt: doet's ff creatief voor je sysadmin salaris.

[Pathogen]

Tsja, als je iets goed kunt isoleren is dat op de lange termijn gewoon een robuuste oplossing. Tenzij je tegen Y2K-achtige zaken aanloopt natuurlijk.
Een compleet op zichzelf staand WinXP ecosysteem is echt geen ramp. Maar als je zoiets op je netwerk gaat toelaten is het weer wél vragen om problemen.

Overigens, ik hoop dat je antwoord zoiets was als: voor 10% van de kosten doe ik het wel

[GekkePrutser]

Inderdaad, je moet het ook niet enger maken dan het is... Op elk netwerk is er genoeg onveilige zooi te vinden. Bijvoorbeeld apparaten met firmware die nooit wordt geupdate. Printers, camera's, enz. Het wordt zelfs alleen maar erger met de wildgroei van slecht doordachte IoT troep. Het is een gegeven waar je mee om moet gaan. Afschermen, eigen VLAN, internet toegang beperken enzovoorts. Het idee dat alles maar met alles moet kunnen praten is sowieso een beetje passe.

Bij ons in de fabrieken hebben we ook veel oude OS'en omdat er machines bij horen die miljoenen kosten en een levensduur van 10-20 jaar hebben. Wat we doen is die gewoon compleet afschermen. Meestal hebben ze helemaal geen netwerktoegang nodig om te werken (in die tijd was internet nog niet echt een gegeven), de meeste communicatie gaat serieel. Dus gewoon airgapped waar het het netwerk aangaat. Waar wel netwerk nodig is, wordt dit dichtgetimmerd met het broodnodig en eventueel nog systemen voor gezet die wel veilig te houden zijn.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 07:57]

[Calypso]

Inderdaad; het probleem had ik in m'n sysadmin periode ook. Software die (om wat voor reden dan ook) moest blijven draaien, en tja, als dat enkel werkt onder een oudere versie... Vergeet niet dat management/klant voor elke reden dat jij geeft om iets uit te faseren er even zo vrolijk meerdere weet te verzinnen waarom niet. En eigenlijk hebben ze soms nog gelijk ook; waarom bijv. dure nieuwe Oracle licenties aanschaffen, terwijl je nog oude hebt en je geen ondersteuning behoeft.

[Snow_King]

Lui? Soms is een upgrade gewoon echt niet nodig. 5 jaar is in veel omgevingen gewoon echt heel krap, voordat je het weet ben je er al doorheen.

Je gaat namelijk niet op dag 1 na de release upgraden van Ubuntu 16.04 naar 18.04, dat doe je vaak als 18.04.2 uit is na ongeveer een jaar. Dan ben je een jaar aan het upgraden en heb je effectief dus nog 3 jaar op 18.04 alvorens je naar 20.04 zou willen.

'Don't fix what ain't broken', soms werken systemen gewoon prima. Als de hardware in orde is, de software gepatched is, waarom moet je dan perse upgraden?

Zolang security fixes maar door komen lijkt mij dat prima.

[Loller1]

Oké, kunnen we even focussen op hoe een onzin dit centiment is?

Soms is een upgrade gewoon echt niet nodig.

Een upgrade *is* nodig als de versie waarop je zit geen ondersteuning meer krijgt.

'Don't fix what ain't broken', soms werken systemen gewoon prima. Als de hardware in orde is, de software gepatched is, waarom moet je dan perse upgraden?

Omdat de software na het einde van de ondersteuning niet meer gepatched is en per definitie dus "broken" is.

Het hele gedoe met "if it ain't broken, don't fix it" is pure onzin met betrekking tot EOL van software. Niet ondersteunde software op kritieke systemen is een no-no, het *is* broken per definitie. Dat het broken is omdat de software-ontwikkelaar er geen ondersteuning meer voor wilt bieden doet er niet toe, dat wist men al jaren op voorhand en je kan niet verwachten dat een ontwikkelaar oneindig ondersteuning blijft bieden voor oude versies.

Wil je het fixen? Dan ga je naar een nieuwe versie. Blijf je op een oude versie? Dan *is* het broken. Het is niet "ain't broken".

[Snow_King]

Als er met extended support nog fixes voor komen, dan krijgt het nog steeds updates en ondersteuning. Daarmee is het dus niet EOL.

We hebben er in de IT-wereld echt een handje van dingen heel snel EOL te verklaren. Dat is gewoon niet altijd bij te houden.

[HollowGamer]

We hebben er in de IT-wereld echt een handje van dingen heel snel EOL te verklaren. Dat is gewoon niet altijd bij te houden.

Omdat het gewoon erg snel gaat, het is een tak waarbij ontwikkelingen niet stil staan.
Net zoals in de zorg kan je wel vast blijven houden aan gewoontes, maar je moet ook nieuwe dingen proberen en ontdekken.

Veel mensen houden vast aan hun gewoontes en spreuken als "if it ain't broken, don't fix it", terwijl we juist vooruit willen met z'n allen. Als we met die gedachten de energie/milieu ingaan dan is de wereld te klein. 10 jaar ondersteuning is meer dan lang genoeg, 5 jaar is al lang. De stap naar iets nieuws of anders, wordt dan ook ontzettend groot. Bedrijven moeten zelf weten wat ze doen, maar persoonlijk zou ik liever kleine stapjes blijven zetten dan stil blijven staan.

M.a.w. gebruik die 10 jaar ondersteuning, maar blijf daarnaast ontwikkelen, dan doen veel bedrijven fout.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 07:57]

[brigges]

[...]
terwijl we juist vooruit willen met z'n allen.

Wie is we? Uiteindelijk is bedrijfsvoering die de afweging maakt of risicos van verouderde apparatuur wordt geaccepteerd.

Voornamelijk in de wereld van OT zie je dat veel systemen met installaties worden meegeleverd. Er zijn nog bedrijven waar PDP-11 onderdeel uitmaken van een kritische proces. Deze vervangen door bijv Windows? In welk belang? ALs het doet wat het moet doen en zolang je zorgt dat niemand bij die PDP kan het risico prima geaccepteerd worden.

[HollowGamer]

Ik ben niet bekend met al die termen, zo te zien is het een oud framework?

Dan praten we wel over een hele andere tak van sport, vaak draaien zaken die lang moeten meegaan al een aangepast OS zoals Windows CE of kernel/distros. Daar is deze 10 jaar nog veel te kort voor, denk aan vliegtuigen, kerncentrales of machines. Het merendeel is daar ingericht voor één specifieke taak.

Waar ik het hier voornamelijk over heb zijn systemen die worden gedraaid in doorsnee bedrijven, onderwijs en overheid. Als je leest dat bedrijven daar nog altijd miljoenen betalen voor oude niet ondersteunde software, dan kom je weer terug op mijn vorige reactie.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 07:57]

[brigges]

Waar ik het hier voornamelijk over heb zijn systemen die worden gedraaid in doorsnee bedrijven, onderwijs en overheid. Als je leest dat bedrijven daar nog altijd miljoenen betalen voor oude niet ondersteunde software, dan kom je weer terug op mijn vorige reactie.

Voor die systemen geld ook het bovenstaande. Alleen zullen de afwegingen anders zijn.

BTW: PDP-11 is een computer. Nog ouder dan de PC-XT. Dus niet te vergelijken met een framework zoals Django etc. Draait op DecNet (protocol) en 64k geheugen.

Ook voor onderwijs/overheid/bedrijven geldt de afweging risico versus impact.
Merk vaak een verschil in beleving tussen een webdevver en beheerder van complexe systemen. Webdevvers (niet denegrerend bedoeld) zijn gewend aan een snel veranderende omgeving. Vandaag is het Ruby on Rails, morgen is het Django (als voorbeeld). Echter dit is geen graadmeter voor de gehele ICT omgeving van IT en in mindere mate OT systemen.

[HollowGamer]

Ik bedoel ook een oud computer model, heet dat niet een framework/main nog iets? Denk dat dit wel werkt met een cliënt/server model?

Anyway, ook in het onderwijs en overheden zie je (ook) verschuiven naar de cloud. Oude medewerkers gaan op pensioen, kennis ontbreekt en patches worden niet tijdig uitgevoerd (zie Exchange en Oracle).

Systeembeheerders vergeten vaak hun kennis te delen of blijven bij eigen oplossingen, dan is het risico van alles in de cloud stukken minder aanwezig en complex. Ik zeg niet dat de cloud deze medewerkers vervangen, absoluut niet zelfs, maar wel dat die wereld ook niet stilstaat.

Leuk dat ze dus 10 jaar+ Exchange draaien, maar het wordt daarna alleen nog maar ingewikkelder om over te stappen op iets anders.

[brigges]

Ik bedoel ook een oud computer model, heet dat niet een framework/main nog iets? Denk dat dit wel werkt met een cliënt/server model?

Je bedoelt waarschijnljik mainframe. Nee PDP is geen mainframe. Het is grofweg een PC uit de prehistory
met bijbehorende omvang.
https://upload.wikimedia....ommons/e/ee/Pdp-11-40.jpg

Verder is het verband tussen oude medewerkers en niet tijdig uitvoeren van patches niet erg aanemelijk. Ook jongere medewerkers patchen niet... al dan niet geblokkeerd door het management. Want daar gaat het vaak fout.

[GeroldM]

Banken en COBOL is ook een goed voorbeeld. Lang geleden hebben veel banken elk miljoenen geinvesteerd in software, geschreven in COBOL, op oude apparatuur om zeer betrouwbaar handelingen uit te voeren op de financiën van hunzelf en hun (grote) klanten.

Betrouwbaarheid die klaarblijkelijk niet gehaald kan worden met moderne hardware en software. Banken investeren niet graag opnieuw miljoenen om wat ze al hebben opnieuw te creeeren. Risk/reward afweging. En men haalt liever 80-jarige programmeurs uit de motteballen om software te blijven ontwikkelen en als mentor jongere mensen op te leiden in dat soort omgevingen, want dat is uiteindelijk goedkoper/gemakkelijker.

Ook zijn er genoeg oude gebouwen met klimaatsbeheer-systemen die draaien op een oude versie die niet kan worden ge-upgraded. Dan zijn de consequenties dus niet: even zonder een web-ontwikkel omgeving zitten vanwege het uitvoeren van patches en herstarts, maar al het (internationale) geldverkeer plat of maar even een gebouw omstoten of compleet uit moeten hollen om het oude klimaatsysteem te verwijderen, een nieuw systeem terug te plaatsten en renoveren.

Een heleboel kosten, ongemak en consequenties. Je zal moeten praten als 2 of 3 brugmnannen tegelijkertijd om zo'n software vervangings-project door Management te loodsen.

In mijn optiek is het beter om een besturingssysteem/server na max 5 jaar te upgraden, opnieuw op te bouwen of te vervangen. Maar heb er ook geen moeite mee om voor te stellen dat er genoeg omgevingen zijn waar dit simpelweg geen optie is.

[Mastofun]

en de andere kant kost het te veel voor de legacy data te importeren in de nieuwe database/programma. Laat dat maar staan, dat hebben we "toch niet veel nodig".
jaren later zit je dan met de gebakken peren omdat er iets niet meer werkt van die server

[Sandor_Clegane]

EOL is echt zo'n onzin term, net of dat software slijt...... Het is juist het enige dat we als mensheid hebben gemaakt dat zich juist niet hoeft te houden aan fysieke regels die gelden voor alle andere materialen.

[jetspiking]

Omdat de software na het einde van de ondersteuning niet meer gepatched is en per definitie dus "broken" is.

Ik vind deze definitie vrij vreemd omschreven. Software is niet 'broken' wanneer de ondersteuning stopt, Software is 'broken' wanneer het niet meer werkt naar behoren, vergelijkbaar met de definitie van 'stuk'.

Sommige Software hoeft niet altijd ondersteund te worden, dat blijft werken. Wellicht sluit het niet meer aan bij de moderne gebruikerswensen en is het minder toegankelijk geworden, maar om de Software dan direct af te schrijven is misschien een verkeerde stap.

[divvid]

Sommige Software hoeft niet altijd ondersteund te worden, dat blijft werken. Wellicht sluit het niet meer aan bij de moderne gebruikerswensen en is het minder toegankelijk geworden, maar om de Software dan direct af te schrijven is misschien een verkeerde stap.

Zelfs nog onlangs tegen gekomen bij een hobby project voor een vereniging, geschreven in 2001. In 2014! kwam de vereniging langs omdat de bijbehorende winXP machine was overleden. We hebben gelukkig de data nog uit de database kunnen trekken, maar wat was het een gezeik om de PDFs goed te genereren in een moderner systeem.(daar was 4D best sterk in).
Letwel, we hadden in 2003 al gezegd dat ze de boel moesten vervangen

[akooijman]

Hebben ze toch ruim tien jaar de kosten van nieuwe software en hardware bespaard.

[CH4OS]

'Don't fix what ain't broken', soms werken systemen gewoon prima. Als de hardware in orde is, de software gepatched is, waarom moet je dan perse upgraden?

Dit is een oude mentaliteit, vandaag de dag komen dagelijks exploits uit voor van alles, je kunt (ook als sysadmin) niet meer verschuilen achter 'maar het werkt toch, upgraden is niet nodig'. Dat is anno 2021 echt een recipe for disaster.

Daarnaast kan het best zijn dat een upgrade juist bepaalde zaken opeens wel support, waarvoor je eerst middels third party repositories of applicaties, scripts e.d. support erin moest hacken, waar dat op een nieuwere versie niet per se hoeft. Denk dan bijvoorbeeld aan nieuwe drivers die in de kernel toegevoegd zijn.

Ook kan upgraden het werk proces verbeteren, stil zitten (wat je met een "Don't fix what ain't broken" mentaliteit basicly doet) doet anno 2021 in dat op zicht eigenlijk niets anders als technical debt toevoegen, iets wat je niet wilt en brengt veiligheidsrisico's met zich mee.

[Reactie gewijzigd door CH4OS op 23 juli 2024 07:57]

[Mijzelf]

[...]
Dit is een oude mentaliteit, vandaag de dag komen dagelijks exploits uit voor van alles, je kunt (ook als sysadmin) niet meer verschuilen achter 'maar het werkt toch, upgraden is niet nodig'. Dat is anno 2021 echt een recipe for disaster.

Is dat zo? Ik lees zoveel over zerodays dat het me lijkt dat volledig ondersteunde/gepatchte software net zo min veilig is als niet ondersteunde software waarvan geen veiligheidslekken bekend zijn.

[CH4OS]

Dat ze niet bekend zijn betekend niet dat ze er zijn en vrijwaart je zeker niet van een hoog patchlevel te hebben.

[Mijzelf]

Dat ze niet bekend zijn betekend dat 'een hoog patchlevel hebben' geen zin heeft. Tenzij een patch voor bekend minor probleem x tevens groot onbekend probleem y oplost. Maar voor hetzelfde geld introduceert hij juist een onbekend groot probleem y.

[CH4OS]

Ik zeg dan ook niet dat een hoog patchlevel hebben zinloos is, ik zeg juist dat het juist meerwaarde biedt als je het wel zou hebben. De "Don't fix if it ain't broken" regel zet je eigenlijk de poten en de kop in het zand, maar heb je dus nog wel de verantwoordelijkheid te zorgen dat het patchlevel zo hoog mogelijk is.

[Snow_King]

Eens, maar secrurity updates komen gewoon uit met extended support, waarom moet je dan perse van versie 16 naar 18 ipv gewoon een gepatchde 16 blijven draaien?

[CH4OS]

Zie mijn edit. Er kunnen best operationele of performance redenen zijn bijvoorbeeld. Daarnaast heeft een nieuwere versie weliswaar net zo lang support, maar eindigt wel op een later moment, je bent dus gewoon langer verzekerd van (security) updates. Voor de hardware maakt het niet veel uit, al hebben nieuwere kernels vaak ook meer en betere drivers aan boord.

[brigges]

[...]
Dit is een oude mentaliteit, vandaag de dag komen dagelijks exploits uit voor van alles, je kunt (ook als sysadmin) niet meer verschuilen achter 'maar het werkt toch, upgraden is niet nodig'.

Dat is toch ook wat Snow-king aangeeft...
"Zolang security fixes maar door komen lijkt mij dat prima. "

Ook upgraden is een afweging van effort/kosten versus het risico.
Upgraden omdat er een nieuwe versie uit is, is iets wat beheerders wel willen maar
niet altijd het belang is van het primaire proces.

[elmuerte]

Maar denk bijvoorbeeld wel aan nieuwe performance issues en bugs die toegevoegd zijn in de nieuwe software.
Stock 2004 LTS is bijvoorbeeld af te raden als je de Intel GPU driver gebruikt, er is een grote kans dat je systeem regelmatig vastloopt.
Maar dat terzijde vraag ik me wel af of je als systeem beheerder goed bezig bent als je 1 LTS achter loopt. Draait het dan ook op hardware van die leeftijd? Of zijn er andere exotische requirements.

[CH4OS]

Draait het dan ook op hardware van die leeftijd? Of zijn er andere exotische requirements.

Met Linux zullen hardware eisen niet heel gauw toenemen.

[EraYaN]

Linux de kernel misschien niet maar userland holt ook gewoon hard door hoor. En als je bepaalde functies wil gebruiken dan zul je er toch echt aan moeten geloven en die grote boze nieuwe hardware aanschaffen.

[divvid]

Dat Stock 20.04 probleem heeft heel wat geld gekost, juist omdat iemand wilde upgraden on het upgraden

[ataryan]

1995 belde net; ze wilden hun novell sysadmin terug

5 jaar is ongeveer 4 eeuwen in IT tijd

/waterfall much ?

[Reactie gewijzigd door ataryan op 23 juli 2024 07:57]

[Hackus]

Je gaat namelijk niet op dag 1 na de release upgraden van Ubuntu 16.04 naar 18.04, dat doe je vaak als 18.04.2 uit is na ongeveer een jaar. Dan ben je een jaar aan het upgraden en heb je effectief dus nog 3 jaar op 18.04 alvorens je naar 20.04 zou willen.

'Don't fix what ain't broken', soms werken systemen gewoon prima. Als de hardware in orde is, de software gepatched is, waarom moet je dan perse upgraden?

Zolang security fixes maar door komen lijkt mij dat prima.

Je zegt het zelf, nu waar 21.10 voor de deur staat, kun je al tenminste op 18.04 LTS zitten.
14.04 is echt oud, net als mensen die nu nog op Windows 7 draaien

[GeroldM]

Zelf draai ik meerdere Linux servers (bare metal). Upgraden van die systemen werkt op zich prima. Voor het besturingssysteem zelf, bedoel ik dan. Echter is het vaker wel dan niet zo dat extra software en/of configuraties compleet zijn verwijderd na de upgrade. Dus moet je weer van voren af aan beginnen. Hopelijk zijn de benodigde handelingen en configuratie-keuzes goed genoeg gedocumenteerd, zodat je, waar nodig, deze weer opnieuw kan toepassen.

Maar ja, als je dan toch alles kwijtraakt, dan installeer je de server maar beter helemaal opnieuw.

En helaas, maar waar, daar krijg je niet altijd genoeg tijd en/of geld voor, men wil niet zolang zonder de functionaliteiten van die server zitten en men wil/kan niet investeren in een extra server.

21.10 is geen LTS versie, dus is het niet slim om een server met LTS versie te upgraden naar een niet-LTS versie als je weet dat 22.04 LTS al in ontwikkeling is en 18.04/20.04 gewoon updates ontvangen.

[Hackus]

Zelf draai ik meerdere Linux servers (bare metal). Upgraden van die systemen werkt op zich prima. Voor het besturingssysteem zelf, bedoel ik dan. Echter is het vaker wel dan niet zo dat extra software en/of configuraties compleet zijn verwijderd na de upgrade. Dus moet je weer van voren af aan beginnen. Hopelijk zijn de benodigde handelingen en configuratie-keuzes goed genoeg gedocumenteerd, zodat je, waar nodig, deze weer opnieuw kan toepassen.

Maar ja, als je dan toch alles kwijtraakt, dan installeer je de server maar beter helemaal opnieuw.

En helaas, maar waar, daar krijg je niet altijd genoeg tijd en/of geld voor, men wil niet zolang zonder de functionaliteiten van die server zitten en men wil/kan niet investeren in een extra server.

21.10 is geen LTS versie, dus is het niet slim om een server met LTS versie te upgraden naar een niet-LTS versie als je weet dat 22.04 LTS al in ontwikkeling is en 18.04/20.04 gewoon updates ontvangen.

21.10 is geen LTS, dat weet ik wel. Geef het aan in tijdsbestek in Linux taal
14.4 en 16.04 is gewoon oud, en daar gaat het artikel over. (verlengen ondersteuning)

[CAPSLOCK2000]

Lui? Soms is een upgrade gewoon echt niet nodig. 5 jaar is in veel omgevingen gewoon echt heel krap, voordat je het weet ben je er al doorheen.

Het ligt nogal aan je definitie van "nodig".
Mijn insteek is dat je productie omgeving de 'huidige' versie moet draaien (uiteraard met wat marge voor upgrades). Zodat op het moment dat een systeem niet meer mag of kan veranderen het nog een aantal jaren mee kan en je niet direct zonder ondersteuning komt te zitten.

In mijn omgeving weet ik dat (sommige) data nog jaren bewaard moet worden en dat de bijhorende applicatie ook moet functioneren om die data te kunnen lezen. Dus op het moment dat de "bussiness" er klaar mee is (en eigenlijk niet meer wil investeren) moet het nóg 5 jaar mee (soms zelf langer). Sterker nog, vaak wordt er geredeneerd dat de applicatie nog maar 2 jaar mee hoeft en dat ze dus nu wel kunnen stoppen met het dure onderhoud en dat het support contract ook al opgezegd kan worden. Om er dan pas achter te komen dat de software nog 5 jaar beschikbaar moet blijven om aan onze wettelijke verplichtingen te voldoen.
Vroeg of laat doet zich een probleem voor (beveiliging of anders) en dan zit iedereen helemaal klem. Het OS is verouderd, de applicatie loopt achter, er is geen support contract en de kennis is de organisatie al weer verlaten. In theorie kun je opnieuw ondersteuning kopen en/of de leverancier inschakelen maar dat kost klauwen met geld, niet in het minst omdat je eerst jaren aan achterstallig onderhoud moet wegwerken.

Dan moet je dus pakweg iedere 2 jaar een major upgrade doen. Ik weet dat men dat erg vaak vindt, maar ik weet ook dat upgrades alleen maar moeilijke worden hoe langer je wacht. Als het niet aan de software zelf ligt dan komt het wel door de mensen. Na 5 jaar is de kennis van de software weer flink weggezakt, als ze uberhaupt nog werken. Hoe vaker je het doet hoe makkelijker het wordt.
Uiteraard moet je wel goed testen maar ook dat is makkelijker als er niet te veel tegelijk veranderd. Daarbij moet je tegenwoordig eigenlijk toch al zorgen voor goede tests en monitoring.
Liefst heb je het hele upgrade/installeer proces zelfs zo veel mogelijk geautomatiseerd zodat je niet afhankelijk bent van vergeetachtige mensen die fouten maken. Als het dan toch helemaal geautomatiseerd en goed gemonitored is dan is vaak upgraden ook niet meer lastig.
Nu snap ik dat niet iedereen zo ver is met z'n infrastructuur (ahum) maar dit is in mijn ogen waar je naar moet streven.
Uiteraard moet je er ook naar streven om nooit in die situatie te komen en je hele lifcycleplan zo goed op orde te hebben dat je nooit met verouderde zooi komt te zitten. Maar ik heb meer vertrouwen in patches die nu worden geinstalleerd dan de belofte om dat over 5 jaar te doen.

Je gaat namelijk niet op dag 1 na de release upgraden van Ubuntu 16.04 naar 18.04, dat doe je vaak als 18.04.2 uit is na ongeveer een jaar. Dan ben je een jaar aan het upgraden en heb je effectief dus nog 3 jaar op 18.04 alvorens je naar 20.04 zou willen.

Het is wederom meer wensdenken dan de praktijk, maar idealiter heb je de test versie van zo'n OS al lang getest zodat je weet dat je geen problemen gaat hebben op het moment dat het in productie gaat. Alles wordt in openheid ontwikkeld en direct beschikbaar gemaakt voor testen. Als je daar pas mee begint op het moment dat OS klaar en bevroren is ben je eigenlijk te laat.

'Don't fix what ain't broken', soms werken systemen gewoon prima. Als de hardware in orde is, de software gepatched is, waarom moet je dan perse upgraden?

Zolang security fixes maar door komen lijkt mij dat prima.

Alle software is kapot, je weet het alleen nog niet.

Ik ben het op zich met je eens dat security patches belangrijker zijn dan features, maar het onderscheid is niet altijd duidelijk. Veel bugs worden opgelost zonder dat er beseft wordt dat er ook security implicaties waren.

[The Zep Man]

Of voor overwerkte sysadmins die hier geen tijd en middelen voor krijgen.

[JackBol]

Aan de ene kant mooi om te zien, aan de andere kant is dit uitstel van executie voor luie sysadmins

Het ligt echt niet aan de sys-admin. Een 'sudo dist-upgrade -y' heb je zo ingetypt.
Het zijn de applicatie owners die geen toestemming geven voor een OS update.

[divvid]

mooi. Veel analyse software wordt geschreven wordt door PhD's en postdocs die kort na het uitbrengen van de software elders gaan werken en dus hun tool nooit meer updaten. Onlangs kwam ik nog zo'n tool tegen die met geen mogelijkheid onder iets anders dat U16.04 draaide, maar wel noodzakelijk was voor een studie (die ook sinds 2016 loopt voor 10 jaar). Tijd/geld voor echt uitpluizen is er niet. Gelukkig draait het netjes in een singularity container. Ik vrees alleen dat we dit veel vaker gaan tegen komen.

[jj71]

Die PhD's en postdocs die dat soort software schrijven zullen wel geen geoefende programmeurs zijn, want als je een programma schrijft wat alleen maar werkt op één specifieke versie van één OS dan doe je toch echt iets niet goed. Ik vraag me dan af wat voor specifieks er in die software zit waardoor het alleen maar op Ubuntu 16.04 zit...

[Mijzelf]

Da's niet zo moeilijk. Het probleem zit waarschijnlijk niet in het OS, maar in de meegeleverde libraries. Als de code is geschreven voor libqt.x.y zal hij niet draaien met libqt.(x+1), en mogelijk niet eens compileren.

[divvid]

dat is dus precies wat we ook geprobeerd hebben. Waarschijnlijk hadden we het uiteindelijk wel ergens aan de praat gekregen, maar alles in een container duwen was de minst kostbare oplossing

[divvid]

dat klopt, ze zijn zeker geen geoefende software schrijvers. Wat precies de onderliggende dependency was zijn we nooit achter gekomen, maar na een week proberen met andere linux versies hebben we het opgegeven en zijn we voor de container approach gegaan. Tijd/geld enzo.

[MartineEekhof]

Python 2.7

[Maurits van Baerle]

Dat is toch ook niet zo vreemd? Ze zullen specialisten zijn in vloeistofmodellen, molecuulstructuren, economisch modelleren etc. Niet in software development, dat is hun gereedschap en niet hun specialiteit.

[Verwijderd]

Gelukkig is ook niet iedere PhD of postdoc eentje in de richting van programmeren, er zijn genoeg complexe onderwerpen die heel goed worden begrepen door mensen die niet zo goed kunnen programmeren. Dan is het bij elkaar zoeken van de juiste libraries e.d. vaak genoeg, aangezien het er mee om gaat dat jouw unieke onderzoek software krijgt en niet of die software de meest stabiele/veelzijdige oid. is.

[GeroldM]

De requirements van specifieke libraries lijken me een groter probleem, in het geval van software die door PhD's en PostDoc's word geschreven. Zit je gigantische data poel ineens "gevangen" in dat soort libraries. Vaak is hun software geschreven in Python. En dat is nou ook weer niet de meest robuuste software als het gaat om upgrades, dus is dat ook een extra struikelblok.

[- peter -]

Tegenwoordig kan je toch wel docker gebruiken daarvoor denk ik? Dan kan het hoofd systeem gewoon geupdate worden en alleen de applicatie in 16.04 land blijven.

[divvid]

jup docker-->singularity

[ApexAlpha]

Docker gebruikt onder water dezelfde kernel. Dus als er iets in de kernel veranderd is dan zal je een VM moeten draaien. Kan alsnog, maar als je continu met (gevoelige) data in zo een systeem werkt is het wel fijn te weten dat het geupdate kan worden. Goede move dus van Canonical.

[CAPSLOCK2000]

mooi. Veel analyse software wordt geschreven wordt door PhD's en postdocs die kort na het uitbrengen van de software elders gaan werken en dus hun tool nooit meer updaten. Onlangs kwam ik nog zo'n tool tegen die met geen mogelijkheid onder iets anders dat U16.04 draaide, maar wel noodzakelijk was voor een studie (die ook sinds 2016 loopt voor 10 jaar). Tijd/geld voor echt uitpluizen is er niet. Gelukkig draait het netjes in een singularity container. Ik vrees alleen dat we dit veel vaker gaan tegen komen.

Ik snap hoe het gaat maar eigenlijk is dat natuurlijk falen van de organisatie. Je hebt jezelf afhankelijk gemaakt van een stuk software dat nooit in productie genomen had moeten worden. Als je de resources hebt om je commiteren aan een project dat 10 jaar gaat lopen dan zou je ook hebben moeten voorzien dat die software een probleem gaat zijn.
Dat bedoel ik natuurlijk niet als persoonlijk verwijt maar als falen van de organisatie. Zelfs zonder het over IT te hebben kun je weten dat je kenis moet vastleggen en voorkomen dat je afhankelijk wordt van een enkele persoon die zo kan vertrekken.

Wat ik IT'ers wel verwijt is dat ze dit soort situaties steeds weer accepteren en opnieuw laten ontstaan. Dat we steeds weer toelaten dat er software wordt gekocht/ontwikkelt zonder dat er resources zijn vastgelegd om die over langere tijd te beheren. De "u vraagt, wij draaien" insteek lijkt heel dienstbaar maar uiteindelijk ga je risico's aan waar je de organisatie tegen had moeten beschermen. Wij moeten veel beter worden in vooraf duidelijk maken welke resources er nodig zijn en, als die er niet zijn, de verantwoordelijkheid daarvoor niet stilzwijgend accepteren. Natuurlijk wordt het nooit ideaal en zijn er altijd zekere risico's die je maar moet accepteren, maar dat accepteren van risico's moet wel expliciet worden gedaan en door de partij die verantwoordelijk is voor de gevolgen (niet de IT-afdeling dus).

[MazDaMan1970]

Je moet eens weten hoeveel bedrijven er nog werken met MS Acces database-jes. Sterker nog; ik heb bij een bedrijf gewerkt waarbij een hele Kanban productie-database op MS Access draaide. Dat was een uit de hand gelopen hobby-project waar je nog jaaaaaren aan vast zat.

[BCC]

Legacy support, altijd een mooi verdienmodel

[bantoo]

Top, spaart me weer 2 jaar extra nutteloze upgrades uit voor mijn gebruik! Vooral fijn natuurlijk voor de mensen die nog op 14.04 zitten.

[wica]

Als je nog 14 gebruikt, loop je dan niet tegen allerlei problemen aan, Of los je dat op door gebruik te maken van PPA's?

[zordaz]

De systemen die nu nog op 14.04 zitten zijn doorgaans niet geupgraded om specifieke redenen. Het lijkt me niet dat dit de systemen zijn die allerlei nieuwe, specifieke software draaien waarvoor PPA's e.d. nodig zijn.

Overigens moet ik bij dit bericht ook denken aan de beweging die Canonical aan het maken is naar Snap voor steeds meer van hun software. Ik verwacht dat Ubuntu toe gaat naar een heel minimaal/kaal OS gebaseerd op .deb en de rest via Snap wil gaan doen. Los van de vraag wat je van Snap vindt, het maakt ondersteuning wel iets eenvoudiger voor Canonical en verklaart mogelijk deels dit besluit.

[UPPERKEES]

Daar kan Red Hat nog wat van leren met hun CentOS faal

[Maurits van Baerle]

Je maakt er een sneer van maar het zou me niets verbazen als de perikelen rond CentOS juist voor deze verandering gezorgd hebben.

Er zijn redelijk wat partijen op drift geraakt die voor de middellange termijn een alternatief voor CentOS zoeken. Die gaan dan natuurlijk niet overstappen op een oude versie van Ubuntu Server maar kunnen in hun overweging tussen bijvoorbeeld Ubuntu Server en Suse Enterprise Linux wel meenemen dat Ubuntu gebruikers van oude versies niet zomaar laat vallen.

De Linux desktop mag dan vaak hobbyisme zijn, aan de serverkant zit het grote geld en daar speelt klantenwerving en -binding een grote rol.

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 07:57]

[UPPERKEES]

Ja ik ben zelf een Red Hat fanboy. Maar denk dat die move van Red Hat juist Ubuntu in de hand speelt. OpenSUSE/SLES is er natuurlijk ook nog. En ja, er zijn distros zoals Alma en Rocky, maar dat moet zich eerst nog maar eens bewijzen.

[fockarty]

Of gewoon klanten die echt niet willen/kunnen/geen tijd hebben
Of klanten van je klant die geen tijd/zin hebben....

Kan wel zeggen dan zetten we alles uit maar das ook weer zo wat
Maar hell als admin (of hoster) ben je gewoon lui.. wereld is niet zwart/wit.

[FreshMaker]

Zo lastig is het niet..

Bewandel het pad wat voor jou het beste is.
Ik zorg voor recente updates/upgrades, gaat het niet dan gaat het niet, punt
Maar ik kan me geen minuut druk maken om wat anderen daarvan vinden, of het oppakken.
Niet mijn verantwoording.

Zolang mijn machines geen problemen veroorzaken, is mijn taak volbracht.
Een waardeoordeel vellen over andere sysadmins is zo'n nutteloze exercitie, want ze hebben allemaal hun eigen redenen.
Heeft niets met lui of onmacht te maken verder

[Qalo]

Jammer dat ik dit niet twee weken geleden eerder wist. Ik heb recentelijk Ubuntu 16.04 TLS van één van mijn oude laptops af gegooid en vervangen voor Debian 11 (Bullseye).

Voor bedrijven kan deze actie van Canonical een uitkomst zijn, maar voor particulieren is het niet echt een aan te raden oplossing, in die zin dat alleen het systeem en alles wat erbij hoort fixes en patches ontvangt. De geïnstalleerde software wordt volgens mij niet meegenomen in dit verhaal. Aan de softwarekant zit je dus opgescheept met oudere versies die niet verder voorzien worden van updates. Dan heb je dus een onderhouden systeem, maar een niet meer onderhouden (als voorbeeld) Firefox browser of Thunderbird e-mailcliënt.

Als ik het mis heb lees ik het graag.

[onno oliver]

Nou,
Mooi is dat heb ik wat oude Thinkpads geupdate om te kunnen gebruiken.
Soms heb je genoeg aan een terminal en Brouwser voor een CTF.
Ik heb een voorkeur voor oude zooi fijne toetsen borden en vallen minder op in het netwerk.bij pentesten.