Dotaz: Jednoduchý návod na inštaláciu Arch Linuxu s btrfs a luksom

[/dev/random]

Nejaký jednoduchý návod ako nainštalovať Arch Linux s btrfs a luksom pre root?

Odpovědi

[X]

Installation - Btrfs + LUKS2 + Secure Boot

[Andrej]

U většiny takových návodů se dá jedině volit mezi blátem nebo louží; každý má nějakou zásadní vadu, například že

• používá zbytečné (a zbytečně matoucí) LVM,
• používá škodlivý (SSD ničící) a zbytečný swap,
• zbytečně vytváří víc než 2 oddíly (1 pro UEFI, 1 pro data),
• vytváří vůbec nějaké oddíly na discích, ze kterých se nebootuje a na kterých tedy oddíly (GPT) nemají co dělat.

Jako jedna z nejméně blátivých louží mi přijde tohle, ale je třeba z toho vynechat všechno, co vytváří škodlivý a zbytečný swap. A když už zlo, tak aspoň to menší: Swap musí být soubor, ne oddíl.

[xxl]

Akorát že když máš více disků než jeden a chceš na nich vytvořit nějaký btrfs raid, tak na něm oficiálně swap v souboru nefunguje. Dá se to sice ošulit, ale nevím, jak je to spolehlivé.

[$]

Az ma hafo RAMky tak to stejne swapovat nebude, je to proste jen "pro vsechny pripady". Zase az je SSD mensi raze tak obetovat 64-128GB na swap muze byt vyhozene penize.

[Peter Golis]

SWAP veľkosti 64-128GB mi príde trošku cez čiaru. Nevychádza to z prastarého odporúčania že SWAP má byť cca 1.5 násobok RAM ktoré pochádzalo z minulého tisícročia a bolo pre rodinu OS Windows?

Napr. RH odporúča trošku iné čísla (Table 14.1. Recommended swap space). I keď tých prepočtov je veľa, závisí od využitia na ktoré je stroj určený.

[lertimir]

Prosím Tě, Anderji, proč to tak opakovaně tlačíš. Pak se smíchá, to co je rozumné s tím, co je diskutabilní, nebo přínos je tak malý, že je to v zásadě jedno.

U většiny takových návodů se dá jedině volit mezi blátem nebo louží; každý má nějakou zásadní vadu, například že

• používá zbytečné (a zbytečně matoucí) LVM,
• používá škodlivý (SSD ničící) a zbytečný swap,
• zbytečně vytváří víc než 2 oddíly (1 pro UEFI, 1 pro data),
• vytváří vůbec nějaké oddíly na discích, ze kterých se nebootuje a na kterých tedy oddíly (GPT) nemají co dělat.

Jako jedna z nejméně blátivých louží mi přijde tohle, ale je třeba z toho vynechat všechno, co vytváří škodlivý a zbytečný swap. A když už zlo, tak aspoň to menší: Swap musí být soubor, ne oddíl.

• LVM. Tady s Tebou souhlasím, že LVM je v podstatě zbytečné. V době subvolume nepřináší nic zásadního
• SWAP. Minulost, kdy paměť byla drahá a swap byl třeba na běh je opravdu zcela pryč. Ale na druhé straně bych ho nezatracoval, protože z mého pohledu má význam pro jednak hibernaci a za druhé je to rezerva, když je nějaký problém. Je zřejmé, že vzbudit systém z 32 nebo 64GB hibernačního swapu bude delší než boot, ale podstatné pro uživatele je, že systém je přesně ve stejném stavu, jak jej opustil. A otázka oddílu nebo souboru? No např. já jsem si udělal na dvou NVMe dva oddíly. Na jedněch je RAID0 a na nich swap a druhých system jako btrfs RAID1. To bych souborem neudělal. Ale pokud někdo honí swapem to, že mu chybí operační paměť na běžný provoz ničí si disk a měl by si koupit pamět. Ale na druhou stranu jestli normální 1TB NVMe má zápis něco jako 600 až 800 TB, tak při zápisu 200GB denně je to na 10 let.
• Dělení disku, GPT. Chápu že máš názor, že jakékoliv dělení fragmentuje volný prostor a je to v zásadě zbytečné. No máš pravdu, ale na druhou stranu ztráty, které tím vznikají, považuju za minoritní. GPT posune začátek dat na 1MB, což je nic. A dělení na oddíly, řekněme, že si někdo vyčlení samostatný /var, aby, když nastane nějaký problém a logy vystřelí v objemech, mu neucpaly datový disk. Ano jde to asi dělat jinými omezeními, ale takhle prostě obětuje nějaký datový prostor, který efektivně můžeš vyjádřit v penězích, za svůj čas k nastudování potřebných operací. A cena třeba odděleného 50GB prostoru není moc velká

[Petr Fiedler]

A dělení na oddíly, řekněme, že si někdo vyčlení samostatný /var, aby, když nastane nějaký problém a logy vystřelí v objemech, mu neucpaly datový disk.

To si dnes OS hlídá sám, ne? Ve výchozím nastavení by to mělo být tak, že pokud se zapíše do /var určitý objem dat, nebo se zaplní určité procento kapacity disku, tak se do /var přestane zapisovat. Alespoň před nějakým časem mi to tu někdo tvrdil. Ještě tam byla třetí podmínka, ale tu jsem už zapomněl.

[X]

To si dnes OS hlídá sám, ne? Ve výchozím nastavení by to mělo být tak, že pokud se zapíše do /var určitý objem dat, nebo se zaplní určité procento kapacity disku, tak se do /var přestane zapisovat.

Urcite? Jak?

[xxl]

To si dnes OS hlídá sám, ne? Ve výchozím nastavení by to mělo být tak, že pokud se zapíše do /var určitý objem dat, nebo se zaplní určité procento kapacity disku, tak se do /var přestane zapisovat.

Urcite? Jak?

Když už je disk úplně plný, tak se na něj dál nezapisuje.

Ale systemd žurnál odmazává nejstarší logy dřív, podle toho, jak je nastavený. Patrně po vzoru logovacího programu socklog, blahé paměti.

[lertimir]

To jo, ale když máš společný /var se rootem, tak při plném systému nenabootuješ.

[Petr Fiedler]

Takže pokud někdo nechce používat Btrfs, tak pro něj má smysl /var oddělit. Nebo to jde nějak pořešit?

[lertimir]

Zase bych nepanikařil, pytlíkování s varem se hlavně týká malých virtuálek. V současnosti považuji za normální a základní kapacitu disku 1TB. V době kdy i levné 1TB SSD stojí tisíc nemá naprosto smysl se bavit o menší kapacitě, protože ušetřím 400 mám půlku ušetřím 600 a mám jen 1/4 kapacity, za výrazně vyššího úsilí. A na druhou stranu když v 1TB udržuji, jako normální zaplněnost pod 70%, tak nějakých 300GB nezaplním rychle. logy jsou texty, při cca 150 znacích na záznam bych jich potřeboval na zaplnění 2 miliardy. To bych si mohl všimnout dříve a nebo mít trigery. V tom má Andrej pravdu, že už většinou dělit disk není třeba, to nač jsem u něj reagoval, že píše, že vždycky. Člověk si musí rozvážit, co fakticky chce a potřebuje.

[Petr Fiedler]

Nevím, jestli určitě. Hledal jsem teď tu reakci, ve které to bylo uvedeno, ale nenašel. Každopádně nikdo to tenkrát nevyvracel a tak žiju v domění, že to tak je. Než jsem sem o tom napsal, tak jsem se na to zeptal AI a ta mi to potvrdila. Tak teď nevím. Každopádně na netu o tom nic najít taky nemůžu. Kdyby to někdo objasnil, tak budu rád.

[xxl]

man journald.conf

[Petr Fiedler]

Thx

[lertimir]

No ale to máš jen logy z journald. Do /var/log bude psat samba, webserver, firewalld, logy btmp,utmp,wtmp, připadně audity (kdysi jsem ucpal systém, že jsem před víkendem zvedl úroveň logování auditních záležitosti a do pondělka bylo plno) nebo monitoring jako atop (to uznávám, že předvídatelně). A třeba do /var/lib/systemd/coredump to mohou najet dumpy, když něco začne padat. Ve /var/cache mám mnohem více dat než v logu, nebo kromě logu může systém hrnout notifikační maily a posílá-li je rootovi, pak bobtná /var/mail.

[X]

Mam pocit, ze jsem nedavno bez problemu zlikvidoval malou debian virtualku extenzivnim logovanim nginxu. Rotace logu bez sance, tak se ptam..

[Max]

Ještě je možnost to ošetřit např. pomocí kvót.
Zdar Max

[Petr Fiedler]

Myslíš s Btrfs (subvol + quotas)? Spíš to tu teď řešíme bez závislosti na fs.

[Max]

V tom případě viz níže, journald a logrotate.
Zdar Max

[xxl]

Já netvrdím, že systemd-journald je samospasitelný. Nicméně svoje logy umí automaticky zezadu odmazávat. A logování většiny služeb se do systemd logů nacpat dá.

A jestli se nepletu, tak jiné logovací programy povětšinou spoléhají na externí rotování/odmazávání logů, takže systemd-journald je z tohoto hlediska na tom lépe. Sám si disk nezaplní, protože i v defaultním nastavení má za úkol ponechat určitou část disku volnou.

Když něco začne padat, musíš se o tom dozvědět dřív, než to zaplní disk.

[Max]

Ještě doplním, že dost dalších logů se dřív řešilo přes logrotate, který umí definici max velikosti logu. Tudíž i služby, co neumí journald, lze částečně ošéfnout takto.
Zdar Max

[X]

V defaultu to osetrene je, ale nezabrani to rychlemu lokalnimu zaplneni napriklad chybou skriptu. Zadna real-time kontrola podle meho nazoru neni.

[Max]

Pak dává smysl použít kvóty na úrovni FS.
Zdar Max

[lertimir]

To máš pravdu. Ale začátek diskuse bylo Andrejovo: nikde nic nedělit, protože tím rozsekáváš volný prostor. A můj protiargument byl, že cena medií je tak nízká, že když tvůrce systému v nějakém případě oddělí třeba samostatný /var (nebo třeba když má web, kam uživatelé mohou něco vkládat, tak útočník může zkusit jestli systém nepoloží, když tam bude hrnout data) při instalaci, může to jednodušší, protože obětuje nějakou cenu media, za svůj čas na konfiguraci, zvláště když to tvůrce ještě nedělal a potřebuje něco nastudovat.

[iWant]

nikde nic nedělit, protože tím rozsekáváš volný prostor. A můj protiargument byl, že cena medií je tak nízká

Tak proc pro podradne data nepouzit rovnou jiny disk nez porcovat jeden? Pokud stroj zvlada jen jeden disk, tak tam bych taky nic nedelil a dulezita data zalohoval na externi disk.