Názory k článku
Canonical nabízí placenou 12letou podporu pro Ubuntu 14.04 LTS a novější

Praktická služba, ale kolik lidí, resp. spíš asi firem ji reálně zaplatí? Lepší mi přijde přejít na něco dosud podporovaného (např. Ubuntu 22.04).

Nevidím mnoho důvodů podporovat takto staré distribuce. Více než 10 let staré? Co je to za software, když potřebuje tak starý systém? Není něco špatně v samotné filosofii? Nemají takové věci žít v nějakém sanboxu? Nestačilo by vybrat jenom pár vybraných verzí pro podobné "dinosaury"?

Vidíš to perspektivou člověka, co spravuje jednotky strojů mimo skutečně ostrou produkci.

U desítek strojů mi třeba upgrade všech serverů trval skoro dva roky. Protože ono to znamená hodně testování a příprav. A když máš velice diverzifikované prostředí, tak toho testování máš opravdu hodně. Potom musíš naplánovat výpadky služeb a stejně zjistíš novou sadu problémů, protože testovací prostředí třeba není pod stejnou zátěží, jako ostré.

U stovek strojů je to ještě horší.

Automatizace je v tomto případě hezká věc, používal jsem ji, ale na major upgrade distribuce jsem si automatizovaně netroufl u celé farmy serverů najednou. Měl jsem vše připravené pro jednotlivé stroje, ale jak píšu níže - vždy to znamená přípravu, testování a plánování výpadku.

Upgrade serveru není žádná povinnost.

S Ubuntu jsem se spálil v okamžiku, kdy jsem jednou upgradoval na příští major verzi a po upgradu se ukázalo, že borci z Canonicalu zrušili podporu Xen a místo toho doporučují jen a pouze KVM. Jenže mi za zapomněli říct, kdo to má pořád stíhat, když se všechno původně doporučené hned zase mění na cosi jiného. Opravdu je celkem nepříjemné tuhle změnu zjistit, když jste zrovna upgradovali server, na kterém je několik desítek zákazníckých Xen virtuálů.

Od té doby nikdy nic neupgraduju.

Ona i ta stará verze je dobrá a funguje, tak proč na to sahat? Že skončila podpora? Stejně žádné nové funkcionality nepotřebuju.

Někdy se sice stane, že se ve Wordpress složkách začnou objevovat jakési záhadné nové soubory s příponou PHP a náhodným názvem, ale stačí je smazat a jede se dál. Zákazníci jsou spokojení, že je neotravuju s nějakými servisními výpadky a pochvalují si, jak všechno krásně šlape. Upgrady se přeceňují, není to potřeba. A navíc se můžu kolegům pochlubit krásným uptime, kdy rekord mám přes 10 let! A furt to jede jako nové! Jó Linux, ten šlape, tohle by se na Windows stát nemohlo!

Tohle je velmi nebezpečná věc a jako zákazník bych od vás utíkal, co by mi linky stačily. Nechávat systém děravý a bez záplat znamená, že je jen otázkou času, kdy se zákazníkům na ta data někdo podívá zblízka a třeba si je odnese.

To už říkal zootechnik Ing. Václav Kašpar: „Děláš velkou chybu, Jaromíre. To se ti vymstí.“

"a jako zákazník bych od vás utíkal"

To je videt, ze si nikdy nevidel zadnou korporatni infrastrukturu. Z lonska mam takovy zazitecek prave na toto tema. Aneb konec supportu OS, a tudiz poptavka u dodavatele prislusneho SW na presun na novy OS ....

Vysledek? Bezi to jak to bylo, a nic se presunovat nebude.

Protoze se z toho vyklubala ve finale kompletni reimplementace, protoze pouzivana verze SW neni na novejsim OS podporovana (a ani na nem nefunguje), a ta co je, prozmenu funguje uplne jinak, a tudiz by se vse kompletne muselo prekopat ... naceneno na nejakych 5M.

A aktualizace samy o sobe? ... https://m.zive.cz/clanky/breznove-aktualizace-windows-server-zpusobuji-pady-radice-domeny-resenim-je-odinstalace/sc-3-a-227255

Mimochodem, vsimni si toho webu na kterym se o tom pise = to uz musi byt prus...

Petre, treba ve vyrobe leku existuji systemy ktere prochazeji validaci/kontrolou. Nasazeni takoveho systemu trva klidne nekolik let a vyrobce leku ruci za to, ze z toho systemu pokazde vypadne ve finale stejny lek. Jakakoliv zmena v systemu musi projit validaci/kontrolnim procesem ktery stoji cas a prachy. Myslenka upgradu pokazde kdyz vyjde nejaka nova verze distribuce je sice hezka ale v praxi z pohledu byznisu nikdo nebude vynakladat miliony $ na novou validaci (ty castky se skutecne pohybuji v radu milionu a nebo klidne desitek milionu dolaru). Tyhle systemy se obvykle davaji do samostatne izolovane site bez pristupu zvenci plus obvykle se implementuje monitoring zmen na urovni souboru, procesu, nebo klidne i na urovni databazovych zaznamu takze z pohledu bezpecnosti je fuk ze ten system je 20let stary a deravy jako cednik. Jako zakaznik si bezne kupujes leky nebo je dostavas na predpis a ty derave systemy jsou ti u zadele.

To je takový základ přečíst si changelogy mezi verzemi.

Aniž bych ti chtěl nějak lichotit musím napsat, že jsem nic debilnějšího fakt dlouho nečetl. Až jsem uvažoval o tom, jestli to myslíš vážně.

"Někdy se sice stane, že se ve Wordpress složkách začnou objevovat jakési záhadné nové soubory s příponou PHP a náhodným názvem, ale stačí je smazat a jede se dál."
Z toho jsem sel do kolen. A podle mne je to nejaky pokus o sarkazmus.

No ještě se tím chlub veřejně, že máš OS, kde jsou data zákazníků bez aktualizací, takže i záplat, gratuluji :)

Ten OS může být z venku oddělen.

Poptávka bude velká. Proto to ostatně dělají. Nám teď končí standardní podpora RHEL 7. Konec jeho života je známý od roku 2014, měli roky na přípravu. A to byste nevěřil, kolik zákazníků na něm i pár měsíců před plánovaným koncem závisí. Proto jsme oznámili prodlouženou podporu ještě o rok delší než dřív - 4 roky. Ta prodloužená podpora je dražší a i tak je poptávka velká. Pro mnoho firem to jsou pořád drobné oproti nákladům na upgrade systémů o několik let dřív.

Potvrzuji: přechod na RHEL 8 je u nás v běhu - čekalo se na to, až bude podpora dodavatele speciální aplikace a jejich RHEL8-ready verse dostatečně odladěná pro produkční prostředí.
Ty 4 roky jsou zatraceně svižné tempo.

Klient má 1500 fyzických serverů na RHEL 7 :-), harmonogram upgradu nám schválil teprve minulý měsíc. A v čem je problém? Používá se tam SW třetí strany, který má rpm jen pro 7 a musíme to přebalit ručně, SW je placený, podporovaný, ale nová verze na 8 znamená i migraci na jinou verzi, ta zase má jiné funkce... Začarované kolo.

A proč se to tak děje? Stabilita je velice důležitá, nové funkce se ocení, když se bude připravovat nová verze SW a ekosystému a nikoliv za běhu. Běžně děláme projekty na 5+ let životnosti, na tu dobu se kalkulují náklady, SW stack, lidi, pak se to nasazuje na desítky, stovky poboček. Před 5 lety RHEL 8 ještě nebyl.

Něco jiného je dělat online služby, kde mám vše dostupné a mohu pohodlně rolovat a updatovat a něco jiného je dělat lokální infrastrukturu pro průmysl, kde každý zásah musím složitě vyjednávat a plánovat, kde je ještě není běžné mít vše trojmo, abych mohl dělat upgrade bez omezení SLA a zvýšení rizikovosti.

> A to byste nevěřil, kolik zákazníků na něm i pár měsíců před plánovaným koncem závisí.

> Pro mnoho firem to jsou pořád drobné oproti nákladům na upgrade systémů o několik let dřív.

Je to tak. Svým způsobem je to pro mnoho open-source projektů dobrý způsob jak získat finance pro vývoj. Za údržbu nepodporovaných verzí jsou firmy nakonec ochotné platit největší peníze.

A díky tomu, že je to opensource, tak si můžou vydělat i třetí strany, ne jen firma zapůvodním OS a programy.

27. 3. 2024, 13:13 editováno autorem komentáře

Dříve byl normální styl vývoje aplikace takový, že byla stabilní, udržovaná, ale ne příliš vyvíjená větev (ve smyslu zpětné kompatibility), pak byla druhá větev vývojová, ta zase negarantovala tu zpětnou kompatibilitu. A jednou za čas se prostě tato vývojová větev prohlásila za stabilní, přešla do udržovacího režimu a vznikla nová vývojová větev.

Pak se začalo přecházet na styl rolling updates - prostě průběžně aktualizujte. Životní cyklus aktuálních větví se začal zkracovat a narostly tím nároky na administrátory - spravuji, například, Nextcloud - to je co týden nová verze a major verze jsou podporovány jen 12 měsíců. Podobně je na tom Gitlab, OpenShift, webové prohlížeče... Člověk pak nedělá nic jiného, než že plánuje odstávky kvůli údržbě.

Že tento stav začal vadit správcům a žádají delší cyklus podpory je vlastně logické. Ve firmě, kde tyto věci berou vážně, to znamená měsíce plánování a příprav, a pak sse jednoduše může stát, že když dojde na upgrade, tak už se instaluje stará verze místo ještě starší a ta nová je zase v nedohlednu.

Ono to totiž znamená otestovat novou verzi, vyzkoušet upgrade a kompatibilitu v testovacím prostředí, celé to provést ještě jednou v dev (nad ostrou aplikací v testovacím režimu) a až pak se dá plánovat upgrade produkce. A to už jsou klidně 4 měsíce v... A ten Nextcloud nebo OpenShift už vydává další verzi...

Takže je logické, že správci žádají delší podporu, protože současný styl vývoje na ně klade ohromné nároky.

26. 3. 2024, 11:09 editováno autorem komentáře

U Nextcloudu si můžete zaplatit Nextcloud Enterprise a dostanete podstatně delší podporu. Ona totiž ta dlouhodobá podpora není zadarmo. Dřív se tolik neřešila bezpečnost, takže se udělal release, maximálně se tam občas fixnul nějaký nepříjemný bug, ale jinak se to nechalo ležet víceméně ladem. Dnes je údržba čehokoliv podstatně náročnější a když to chce člověk zadarmo, musí se smířit s tím, že to má jinou cenu - časté upgrady.

Nechci zabředávat do konkrétních aplikací, jen uvádím příklad... A vysvětluji proč to zákazníci vyžadují a že jsou ochotni za to zaplatit je jen lepší...

Pokud vím, tak podobné věci nyní řeší i RedHat...

Co takhle použít Docker kontejnery?

A v čem ti to pomůže? Stejně musíš migrovat data, ověřit, že vše funguje, upgradovat monitoring, vše ověřit, zajistit odstávku služby atd. atd.

To částečně řeší problémy... Ale jen částečně. Měl jsem několikrát situaci, kdy se během minor aktualizace aplikace (v kontejneru) změnila verze použité knihovny pro přístup k externí komponentě - třeba Redis, databáze a podobně (není důležité která). A nově použitá verze obsahovala chybu, která se projevila jen za jistých specifických okolností, které nastaly.

Důvod pro přechod na novou verzi dané knihovny nebyl, prostě si to jen vývojáři nepohlídali. NE-kontejnerová varianta bez problémů fungovala i se starší verzí dané knihovny. Chyba se projevila po migraci dat na novou verzi, přičemž downgrade není možný. Kdybych ten upgrade důkladně neotestoval, co bych dělal? Dat tam bylo požehnaně a obnova ze zálohy (kterou jsem měl) by trvala desítky hodin kvůli zajištění konzistence dat.

To mi vůbec nedává smysl. Když se dala použít jedna verze knihovny mimo docker, dala se vyměnit v dockeru.

Aplikace byla distribuována jako balík nebo jako docker image. Mimochodem, extrémně zprasený. Ale furt to byla snadnější cesta, než udržovat instalaci z balíku.

Build vlastního docker image s funkční knihovnou byl pak hrozný voser. Na to jsem se vykašlal, protože by mne museli platit výrazně lépe. Navíc, ztrácíš do jisté míry kompatibilitu s upstreamem. Prostě jsem počkal, až vydají image, který bude obsahovat opravenou verzi knihovny.

u jednoho projektu právě kvůli openshift máme dva týmy souběžně každý přípravuje upgrade na jinou verzi.

Zásadní jsou hlavně jakkékoliv změny, protože to znamená spoustu zásahů do dokumentací, spousty migrací, spousty koordinace s týmy, které to používají.

Také mi to začíná vadit a s láskou vzpomínám na openBSD, škoda, že dnes už v produkci vídám jen pár mohykánů.

S cloudem to je ještě větší problém, oznámení pár měsíců dopředu, že se něco mění a stará verze už nebude. Teď zrovna v týdnu MS PowerBI, skvělé, migrace není podporována, takže se musí napsat proces vlastní.

"S cloudem to je ještě větší problém"

A ve finale zjistis, ze nejpouzivanejsi funkcnost v nove verzi chybi, neni ani nijak jednoduse nahraditelna, a i ty mene pouzivave veci jsou schovane ve 25 urovni dynamicky se menicich obrazkovych nesmyslu. V ramci proaktivniho vyvoje (pripadne dalsi podobny zmrdspeak) se ti pak nove (zcela zpetne nekompatabilni) verze budou rolovat ... treba kazdeho 1/2 roku.

Kdyz vemes zivotni cyklus OS, tak nejmene 2 roky po uvedeni verze je nepouzitelny, plny tristnich bugu, nema smysl ho ani testovat. Teprve pak se v korporatu zacne testovat kompatabilita aplikaci a infrastruktury = nejmene + dalsi 2 roky. A teprve kdyz to vsechno klapne, tak mozna po 5 letech muzes mit +- nasazeno do provozu.

Samozrejme muzes se na to vyprdnout a risknout to ... a dopadnes jak zaslouzis.

A ve výsledku zjistíte, že máte v core aplikaci customizace, které dodavatel té aplikace v nové versi neumí, protože přešel na jinou komponentu, neboť ta stará má po end-of-life a není pro ni náhrada. Takže než někdo kvůli customizacím uvede ještě novější versi, s jinou komponentou, máte ve firmě díky after EOL komponentě i after EOL versi aplikace na after EOL OS a udržujete to na after EOL železe.

Jup, a zjisti se to tyden pred nasazenim te nove verze ... ;D

Našim zákazníkům v tomto v určitých případech pomohly kontejnery, u našich desktopových konkrétně flatpaky. Třeba odvětví animačních studií je hodně rigidní. Tam dodavateli trvá roky vydat software pro novou verzi OS a pak ještě studia zásadně nemění software během produkce filmu, což může být klidně až dva roky. A pak už začínají mít problém zase s podporou hardwaru, protože nové ovladače se do RHELu backportují jen v prvních 5 letech, pak už se jen opravují chyby.

Flatpak jim umožní tu jednu aplikaci, která pořád závisí na RHEL 7, hodit do kontejneru s tímto systémem a oni zatím můžou upgradovat všechno ostatní. V tom kontejneru se to líp spravuje po EOL i z pohled bezpečnosti. Aplikaci se nemusí dát přístup k síti, pokud ho nepotřebuje, omezí se jí přístup do hosta atd...

> customizace, které dodavatel té aplikace v nové versi neumí, protože přešel na jinou komponentu,

A nebo prostě tam původní vývojáři už nepracují, taky běžné. Noví se v tom starém kódu nevyznají.

Trošku ironicky, tá "after EOL" verzia aplikácie an "after EOL" OS (my máme ešte stále cez desiatku RHEL 5.11 a aspoň dvakrát toľko RHEL 6.10 na už asi obstarožnom fyzickom železe) často funguje úplne spoľahlivo (t.j. chýbajúca podpora vlastne nevadí), a s novou sú len samé problémy (staré známe chyby boli nahradené novými, ešte neznámymi). S migráciou je toľko práce, že to nikto nechce schváliť (a dať rozpočet), ale zase z inej časti korporátu frfľú, že sú stále v prevádzke nepodporované verzie, ale tým to skončí.

jedu poměrně dost na upstreamu různých OS a určitě bych to nenazval tristním stavem.

U klientů vidím ale jiný problém a důvod proč to tak dlouho trvá a tak dlouho se čeká. Je tam spousta ruční práce, spousta přezvatých tutoriálů a navodů. Ten kdo systém připravuje zpravidla s tím moc pracovat neumí, je to někdo jiný než ten kdo to dělal před rokem a když nefunguje příkaz z dokumentace, je v koncích, nerozumí tomu, aby našel jiné řešení obratem. Všechno testování je ruční až poloruční, automatizace když už je, tak jen formou dávkových příkazů. V takovémhle prostředí dělat nějaký výraznější upgrade je prostě těžké a trvá to dlouho.

Do toho ještě vstupuje běžný enteprise SW, který se vyznačuje haldou špatně napsaných bash a java scriptů na různé obsluhy, konfigurace a přípravy prostředí, na starty a vypnutí služeb. Zpravidla to má spousty hardcodovaných cest a hodnot, které je potřeba dodržet.

;D ... mam mimo dalsich krasek pod palcem SW, ktery ma konfiguraci zadratovanou pri instalaci, takze ji potom uz nijak normalne nezmenis. K tomu samozrejme dalsi bonus, ze se "aktivuje". Jenze ta verze kterou zakaznik pouziva se uz aktivovat neda. A ted si predstav, ze tohle potrebujes prenyst na jiny OS.

Jako udelal sem to, po tom co sem stravil par mesicu hackovanim ty veci. Ve finale sem to defakto cracknul. Zakaznik chtel, zakaznik mel, ale levny to nebylo. Vyhoda je, ze ted uz se to da vpodstate naprasaka kamkoli zkopirovat ... a neprotestuje to.

Jiste, mohli by nasadit novejsi verzi, jenze ta neumi prave to, co pouzivaji, zato umi spoustu veci, ktere nanic nepotrebuji.

BTW: Kdyz sme u toho, vnstat (najdes bezne v distrech) ... to ve verzi 1x byla trivialni primitivni vec ... spoustena cronem, ktera ti bywoko rekla kolik dat ti tak nejak tece pres iface. Jednoho krasneho dne prisla aktualizace na 2x ... a ja se divil, proc to dop... nefunguje. A ona z toho frikulinska setrvale bezici servisa, delajici vsechno mozne i nemozne, kterou vubec nanic nepotrebuju.

Podotykam ze si samozrjeme to kolo umim napsat sam, ale rikal sem si proc to delat, kdyz to uz nekdo udelal ze ... takze sem bloknul aktualizace a nahodil zpet v1. A toto se deje porad a neustale s vetsinou SW.

Prave du nahodit starou verzi adobe readeru, protoze ta aktuelni me uz se... neustalymi popupy na tema kup si tohle, nebo tamto, tuhle mas uzasny naprosto nesmyslny frikulinsky funkce ...