je to největší problém debianu, instalovat nějaký balíček je minové pole, jestli náhodou nechytneš nějaký, který není udržovaný a obsahuje zranitelnosti.
Alpine linux odstraňuje balíčky po půl roce neaktivnosti, stává se to, že se aspoň o chybějícím správci dozví spousta lidí a často se toho někdo ujme, u debian vlastně ani nevíš, že instaluješ balíček, který nemá svého pána nebo naopak pán sice je, ale nemá aktivitu.
Vlastně to je i důvod proč u spousty projektů jsme z debianu odešli, protože udržovat whitelist bezpečných balíčků bylo příliš náročné.
Jeste vetsi minove pole je ale stav, kdy balik z repa proste zmizi... ano, nove si ho uz nikdo nenainstaluje, ale z uz nainstalovanych systemu to nevysublimuje a pokud nema prilis slozite zavislosti, s velkou pravdepodobnosti tam bude hnit hodne dlouho. Ono i bezny dist-upgrade po sobe dost casto zanecha hromadu pohrobku, typickym favoritem zde jsou ruzne lib*, ktere kdyz maji uz od instalace manual flag (i kdyz k rucni instalaci nedoslo), tak tam zustanou... a ejhle, potencialni diry plynouci z neaktualizovanych baliku jsou na svete...
tak balík může mizet třeba pro další distro release, že jo. Ale ano, pak to rozbije dist-upgrade a v tom je asi kámen úrazu, proč se to ještě nevyřešilo.
Zajistit determistický stav systémů (čistá instalace vs. postupná evoluce napříč flotilou) pro spousty linuxových distribucí (tím neřikám, že jiné OS to mají lepší) je velice obtížné.
V podstatě dnes jsme ve stavu, kdy nonstop běží proces, kdy se servery přeinstalovávají na čisto, tak abychom nedrželi léta nějaký pohrobek se spoustou zapomenutých stavů, aplikací a nastavení. Zároveň se snažíme mít z OS repositáře jen minimální počty balíků, tak aby se dalo lidsky je kontrolovat a spravovat.
Zajistit determistický stav systémů (čistá instalace vs. postupná evoluce napříč flotilou)
Pro tohle bych použil NixOS.org ale záleží, má to samozřejmě i nevýhody.
nix je skvělý, používám, ale třeba tam ještě chybí nějaké rozumné security skeny, kontroly zranitelností, kontroly opuštěných a neaktualizovaných balíků vč. zranitelností jejich závislostí. Tohle se teprve začíná řešit, dokonce na tom i spolupracuji v nějaké malé míře.
"Zajistit determistický stav systémů (čistá instalace vs. postupná evoluce napříč flotilou) pro spousty linuxových distribucí (tím neřikám, že jiné OS to mají lepší) je velice obtížné."
Zas až tak obtížné to dnes už tak není. Máme tu nejrůznější externí balíčkovací systémy (Snap, Flatpak a nepodceňoval bych v tomto ani pkgsrc) a pokud chcete vyloženě "deterministický stav", tak je tu Nix (jak tu někdo zmiňoval) a GNU provozuje Guix (což - asi aby se to nepletlo - je název zároveň pro deterministický balíčkovací systém (inspirovaný právě Nixem) a zároveň pro oficiální Linuxovou distribuci od projektu GNU, která je na tomto balíčkovacím systému založená).
A nebo můžete balíčkovacím systémům zamávat a použít rovnou Appimage pro danou aplikaci (pokud je tedy k dispozici).
Takže jak vidíte, možností je dost. Úplně jednoduché to sice není, ale "velice obtížné" už taky ne.
6. 9. 2024, 00:05 editováno autorem komentáře
dříve šel zajímavou cestou třeba coreos, dnes podobně pokračuje Fedora Silverblue, Slax od Tomáše Matějíčka je přesně to stejné, vždy startuje totožný systém a jeho stav je neměnný. Jednotný obraz se používá často v embedded, řada routerů a aktivních síťových prvků na linuxu to tak má také.
Snapy, flatpaky, pkgsrc jsou skvělé, ale bohužel málo penetrované, nesou s sebou ale obrovské velikosti, příprava samotných balíků je zatím pro vývojáře (což jsou typičtí producenti požadavků na nějaké závislosti) dost obtížná. Hlavní ale problém za mě je velikost, kde nám původně stačilo 20 GB na aplikace, potřebujeme najednou 500 GB, k tomu se váže o řád vyšší nároky na repository servery, různé skenery typu qualys běží neúměrně dlouho, initializace serverů trvá pak také dlouho. Tím to celé prodražuje infrastrukturu, nix to má navržené mnohem lépe.
Ano, jde to, cesty jsou, ale za mě to je pořád v kategorii obtížné a tak pořád většinou vidím staré paradigma s OS, lokálně instalovanými balíčky a hromadou pohrobků, které jsou časem zapomenuty. Udělat to jinak něco stojí.
ansible je imperativní, dělá jen co mu řekneš, když při změně zapomeneš starý soubor smazat nebo balík odinstalovat (to ale pořád nevyřeší jeho nainstalované závislosti), tak to tam prostě nechá.
S trochou péče to lze řešit – stačí si z dpkg -l vygrepovat starší balíčky. Ale je pravda, že pokud to člověk neřeší, je to problém.
Jak se "grepují starší balíčky"? Některé mají v názvu "deb12", tj. ví se, z jaké verze Debianu jsou, ale to je menšina.
Nebo tím myslíš třeba každý měsíc si ukládat dpkg -l a pak zaměřit pozornost na balíčky, které už rok nezměnily verzi?
6. 9. 2024, 12:59 editováno autorem komentáře
no, pak to dopadne tak, že děláš dpkg -l na čistém systému a mažeš z produkce vše, co je tam je navíc.
Není vůbec snadné to samostatně rozličkovat, u řady balíků, které se instalují jako závislost máš stejně uvedeno, že jsou instalovány přímo atd.
Samozřejmě, když se snažíš, nějak se s tím popereš, ale tak trochu bych čekal, že tohle budou OS dělat daleko lépe, protože prostě dnes je problém, když na systému zůstane nějaký starý SW, nastavení balíček, nikdy nevíš, kdy tam zůstane zapomenuto něco, co umožní systém kompromitovat.
Tak většina těch distribucí, kde si můžete koupit i komerční podporu (RH, SUSE, Ubuntu..). Jsou tam typicky jasně rozdělené repozitáře, kde je pak deklarováno, jestli poskytuje podporu vendor až do EOL té konkrétní verze, nebo komunita (a je to tvoje riziko).
jj, primo uzasny ... proto neni v gentoo ani takova kravina jako smokeping.
Distribuce se ma starat o funci zaklad a nestarat se o to, kdo jak aktualizuje jakej balik.
Jasně, a že to je léta rozbité a jsou v tom bezpečnostní díry a nikdo to nespravuje, tak to taky neřešit. Super myšlenka.
https://bugs.gentoo.org/631140
https://bugs.gentoo.org/602652
V RHELu má každý balíček svého placeného správce a máme smluvní závazek ho udržovat, takže tam se nemůže moct stát, že by zůstalo něco úplně bez údržby. Navíc těch balíčků máme asi jen 4 tisíce.
Obecně s tím má problém každá komunitní distribuce, ale zrovna u Debianu mi přijde, že jsou v odstraňování balíčků nejméně agresivní a taky nejméně selektivní v tom, co se do repozitářů dostane. Pořád mi přijde, že tam zůstává ta snaha zabalíčkovat celý svět, což už mnoho let neškáluje. Třeba Fedora je v obou věcech určitě agresivnější a extrém je potom ten RHEL, protože co se dostane do RHELu, u toho máte smluvní povinnost se o to 10+ let starat. A to už si člověk dvakrát rozmyslí, jestli to chce mít v repozitářích nebo ne.