Dotaz: Přechod na Linux

[Petr Fiedler]

Dobrý večer všem,

        definitivně jsem se rozhodl, že z bezpečnostních důvodu přejdu na Linux jako na svůj primární systém. Hodlám to udělat jak na desktopu, tak na notebooku. Rozhodl jsem se pro Debian. Chtěl bych docílit toho, abych měl jak na pc, tak na ntb zašifrovaný systémový SSD disk, který by měl být rozdělen na /, /var a /home. V systémech bych pak chtěl mít KVM, protože kvůli jedné aplikaci nemůžu Windows zcela opustit - Wine tu aplikaci zobrazuje nepřijatelně. Tady je pár otázek, které mám a budu rád, když poradíte:

1. Nedávno mi při instalaci Debianu na externí disk instalátor hlásil, že při vytváření oddílů došlo ke špatnému zarovnání a vytvořil mi oddíly tak, že na začátku disku bylo relativně dost volného místa. To byla výjimka? Co s tím? Mám ty oddíly předpřipravit v GParted? Jak? Oba SSD mají 500 GB.
2. Chci šifrovat celý disk. Musím použít LVM? Pokud ne, je lepší jej použít, nebo ne?
3. Když nainstaluji Debian např. na desktop, půjde pak s ohledem na šifrování vytvořit zálohu Clonezillou a obnovit jí na druhý stroj?
4. Chci mít v pc i ntb stejná data. Syncuji tedy obousměrně oba stroje na síťový disk, který je zapojen do Raspberry s Raspbianem. Půjde nějak nastavit, aby např. při startu desktopu probudil desktop Raspberry a nějaký skript s heslem v desktopu by zadal heslo do RPi, to by naběhlo a v RPi by byl další skript, který by odemčel šifrovaný síťový disk, provedla by se sync a při vypnutí desktopu by se opět vše vypnulo?

        Jinak velice rád uvítám jakoukoliv dobrou radu.

---

---

Odpovědi

[Aleš Kapica]

Počkej do zítřka. Mám rozepsaný blogpost, co by tě mohl nasměrovat dál.

[Petr Fiedler]

Tak jo, fajn :)

[Aleš Kapica]

Jo teď ale koukám, že nechceš dualboot, ale kompletně to vykynožit. V takovém případě nech dělat instalátor co chce. Pokud máš dost paměti, tak stačí jeden oddíl. Pokud chceš provozovat virtuál, můžeš si udělat pro sichr na každém z těch disků swap – zkrátka aby byly ty disky symetrické. Osobně bych použil Btrfs v raid1 a na šifrování se z vysoka vykašlal, protože to jen zvedne režii a k ničemu to není.

Na Clonezillu bacha. Můžeš taky splakat nad výdělkem.

Sdílení souborů mezi dvěma zařízeníma je lepší řešit spíš přes externí NAS a nějaké NFS nebo CIFS. Jinak se to dá řešit na úrovni aplikace, ale je to oser.

[Petr Fiedler]

Pokud máš dost paměti, tak stačí jeden oddíl. Pokud chceš provozovat virtuál, můžeš si udělat pro sichr na každém z těch disků swap ...

Na obou strojích mám 16 GB RAM, takže podle mne paměť stačí.

Sdílení souborů mezi dvěma zařízeníma je lepší řešit spíš přes externí NAS a nějaké NFS nebo CIFS. Jinak se to dá řešit na úrovni aplikace, ale je to oser.

Na to teď nemám finance. Mně prostě stačí, že když např. v desktopu vytvořím nějaký soubor, tak se syncne na ten síťový disk a při spuštění ntb se do toho ntb stáhne. Takže chci vlastně mít stejné soubory v obou strojích a na tom síťovém disku. A taky alespoň využiju RPi, které má navíc nízké provozní náklady.

[Josef Kufner]

LVM je fajn, neboť ho umístíš do šifrovaného oddílu (LUKS) na disku a v něm pak vyrobíš všechny oddíly. Ve výsledku se to pak bude ptát na heslo jen jednou. Doporučuju držet se výchozího nastavení. Prostě v instalátoru zvol, ať se šifruje celý disk. Rozdělení na /, /var a /home je zbytečné, ale nic tomu nebrání.

Alternativou je udělat několik LUKS oddílů a do nich dát po jednom filesystému. Buď pak budeš zadávat hesla pro každý zvlášť, nebo si někam uložíš klíče k nim a zadávat budeš heslo jen k tomu oddílu s klíči. Nebo uložíš klíče nějak úplně jinak.

[Petr Fiedler]

Rozdělení na /, /var a /home je zbytečné, ale nic tomu nebrání.

Před pár dny jsem tady četl, že se někomu docela rychle zaplňoval disk daty. Blaazen v tom vláknu podotkl podle mě docela dobrou věc.

[Josef Kufner]

Jo, to je jeden z příjemných efektů, které to má. Ale jinak je s tím spíš otrava, hlavně když netrefíš vhodné velikosti oddílů.

[Petr Fiedler]

No, já tomu nerozumím tak jako ty, ale viděl bych to cirka nějak takto:

/       30 GiB
/var     1 GiB
/home  434 GiB

Co ty na to?

[Blaazen]

1GB /var je málo. Používám Chakra (to je rolling update distro založené na Archu) a jen /var/cache/pacman/pkg má 3,6GB a /var/log má 440MB. Nějaké větší aktualizace můžou postahovat i 1GB (velké jsou balíky plasma, tex, kernel, wine, libreoffice). Mám /var asi 5,5GB. Naproti tomu mám / jen 12GB, ale skoro plný. Dal bych / tak 15, max. 20GB. Nemám ovšem čerstvé zkušenosti s jinými distry.

[Petr Fiedler]

Tak mě na těch prá GiB vůbec nezáleží. Klidně můžu mít /var velké 10 GiB. Žádný problém. A /home bych tedy sundal na 20 GiB. Na data budu mít sejně pořád mnohem více prostoru, než potřebuji.

Každopádně díky za rady.

A ještě se tě zeptám: Jak ti rolling update šlape? Je to spolehlivé? Mě právě na Debianu Stable mimo jiné láká ta konzervativnost a odladěnost.

[debian+]

Debian stable .... skor si daj testing ... inac fajn.

[Petr Fiedler]

Proč je podle tebe lepší Testing, než Stable?

[Josef Kufner]

Stable už vychází celkem často, cca po dvou měsících. Takže to je celkem jedno.

[dobrák od kosti]

Děláš chybu mistře, / a když tak /home na jednom disku. Situace by byla jiná na více discích. / 30 je málo pokud budeš chtít instalovat 3D hry. / na min. na 50% a /home taky cca tak, důležitá data raději zálohuj na jiné (třeba externí) disky.

[Petr Fiedler]

3D hry instalovat nebudu. Data zálohuji na druhý disk, který je v pc (plotnový).

[dobrák od kosti]

OK, dej teda alespoň 80 na / těch 30 je dnes málo i tak pokud s tím chceš vydržet tak 5 let. S tím / narozdíl z vyhazováním svých dat z /home bude brzo problém, fakt. Když by jsi opravdu chtěl samo /var tak pokud na tom nebudeš chtít kompilovat office tak cca 5GiB ale fakt je to zbytečné a výkon na jednom disku to nezvedne. Steně tak /home. Zajímalo by mě proč ten /home vůbec chceš samostatný? V době kdy nebyly live distra oddělený /home na jiný disk mělo smysl když se něco na / posralo, ale dnes v tom smysl nevidím, na jednom disku.

[Petr Fiedler]

S tím / narozdíl z vyhazováním svých dat z /home bude brzo problém, fakt.

Proč?

[dobrák od kosti]

Protože vyhazovat věci z / nebo dodatečné napojování disků na oddíly kterým dojde místo už bude větší pakárna.

[Petr Fiedler]

Já si teda s Linuxem „hraju“ teprve asi tři roky, ale nikdy se mi nestalo, že by systém přesáhl 15 GB. Tedy nutno podotknout, že data jsem kvůli dual bootu měl sdílená s Windows na datové partyšně, takže v /home jsem nic neměl, ale přes 15 GB jsem prostě nikdy nešel. Nechápu, čím myslíš, že by se mohl 30 GiB / zaplnit?

[Petr Fiedler]

... Ale jinak je s tím spíš otrava ...

Josefe, mohl bys mi prosím tě vysvětlit, jaké jsou s tím ještě problémy krom toho, když netrefíš velikost oddílů?

[Blaazen]

Když netrefíš velikosti, tak pomocí KDE Partition Manageru musíš zvěšit/zmenšit velikosti oddílů, což je obzvlášt zábava na 5400 otáčkovém disku. Jiná otrava s tím snad ani není.

[Josef Kufner]

A je to trochu problém, pokud nemáš někde dost místa, aby ta změna velikosti mohla proběhnout.

Btw, můj /var na notebooku má necelých 10 GB. Ale klidně tam nějaký ten gigabajt přibude, když se po delší době stahují aktualizace.

[Josef Kufner]

… tedy, teď zrovna mi tam leží 7 GB aktualizací (již nainstalovaných nových verzí balíčků) a čekají na smazání

[Petr Fiedler]

Tak dám /var 20 GiB a hotovo. Místa mám k dispozici přehršle. Nebo mám ještě raději přidat?

[dobrák od kosti]

Možná ti chtěl říct, že /var je oddíl, kde jsou jak už název napovídá proměnlivá data, jednou je potřeba hodně místa jindy i třeba 1-3 GB stačí, proměnlivá data ale méně četně měněná narozdíl třeba od /tmp nikoli /var/tmp. Pro mě za mě, si dej na /var i 15GB ale připravíš se povětšinu času o ztrátu diskového prostoru.

[dobrák od kosti]

/var je adresář nebo složka nebo cesta,

[Petr Šobáň]

A jakej je v tom rozdíl?

V linuxu je všechno soubor

[vencour]

Pokud to chápu dobře, diskuse je o tom, zda jeden souvislý disk nebo více oddílů.
Sám už jsem v gentoo dělal symlink na stažené soubory balíčkovacího systému (/usre/portage/distfiles) na druhý disk, když jsem potřeboval víc místa na noťasu.

[Petr Šobáň]

Jsem zastáncem na soukromém PC pokud má jeden HDD nic nerozdělovat. U malých kapacit se to nevyplatí.

U PC co má rychlý SSD a plotnový HDD tak mám na SSD systém kde je efi oddíl a rozdělen na polovinu kde je linux/windows a na plotnovém disku je /home jiný plotnový HDD je pro windows.

Samozřejmě něco jiného je server který se nevypíná a má více disků které se za chodu mění atd.... Tam rozdělování na různé disky pod LVM a pod má smysl.

[k3dAR]

ja na vsech svejch NB/PC pouzivam LVM i kdyz jde o 32GB SSD nejde jen o rozdeleni co jednoduse zamezi zaplneni vsecho "jednou casti", ale i o LV snapshot, apod...

[Aleš Kapica]

Od té doby co je Btrfs v mainline, jsou LVM snapshoty přežitek.

[k3dAR]

blbej vtip... btrfs je v mainline 10let a takovou dobu ho krome btrfs vyvojaru pouziva jen par experimentatoru a psychopatu
pro pouziti normalnich lidi se da uvazovat mozna tak ~2 roky a u nekterych ta doba jeste ani neprisla...

[Petr Fiedler]

nobody,

dám hodně na tvůj úsudek. Co bys udělal na mém místě? Např. ext4+LUKS+LVM, nebo btrfs+LUKS? Mě se fakt líbí, že nepřijdeš o data. Ale má to jistě spoustu dalších aspektů.

[k3dAR]

na mem miste bych dal LUKS/LVM/EXT4, na tvem miste mozna LUKS/BTRFS kdyz te to laka, ale pak bych se zamaril zaroven vice i na zalohovani a otazka na co zalohovat, jestli NAS s EXT4 nebo take BTRFS

kdyz nebudes resit RAID, tak cast BTRFS problemu/podivnosti odpada, pocitej ale napr. s tim ze se budes hure dopatravat k tomu kolik mas volne misto, jednak BTRFS tim ze resi deduplikaci, pak tim ze pouziva subvolumes, mozna se to zmenilo ale pred casem si nemohl na "tuknuti" zjistit presne ze mas volno 10GB jako kdyz udelas "df -h /" u ext4...

[Aleš Kapica]

A zástupy BFU co ho mají v synology a ani o tom neví.

[dustin]

Zajímavé https://www.synology.com/cs-cz/knowledgebase/DSM/tutorial/General/What_was_the_RAID_implementation_for_Btrfs_File_System_on_SynologyNAS

[Aleš Kapica]

Nádherná demonstrace toho, jak nepochopili jak ten raid vlastně funguje. Aneb – nepochopili jsme, tak zpátky na stromy.

[lertimir]

No myslím, že to není nepochopení, spíše reagují na to, že mnoho uživatelů 4 diskových jejich nasů požaduje funční RAID 5 s výslednou kapacitou 3 disků. A to je skutečně něco, co BTRFS RAID zatím nedokáže poskytnout. Takže postaví MD RAID 5 a nad tím počítají BTRFS checksumy.

A tady je podstaná otázka, jak se k rozvoji RAID 5/6 staví vývojáři. Připadá mi že to není prioritní cíl.

[Aleš Kapica]

Nezlobte se na mě, ale než použít MD RAID5, to už bych se fakt raději střelil do nohy.

[lertimir]

Proč? Pokud to nejsou výkonově zatížená data, pouze je třeba je držet s rozumnou mírou zabezpečení, což dosahuje pravidelně projetím scrub a raid-check , tak ta pravděpodobnost, že o ně přijde je malá.

[k3dAR]

a pak treba BTRFS RAID1 (dle vzoru jednoho psychopata by se to asi melo spise oznacit za MatlAID1), kterej pri pouziti vice nez 4 disku nenahrava vse na 4 disky, ale vzdy jen na "nejake" 2 z tech 4...

pak je zajimave ze nejdriv Synology davas jako vzor toho kdo btrfs take pouziva, kdyz ti ale nekdo da odkaz ze nevyuzival radeji BTRFS RAID, ale pouzivaj BTRFS nad MDRAID, tak uz Synology najednou neni vzor

[vencour]

Když to jde, tak i na noťas dávam 2x linux, gentoo a něco k tomu. Dělam to tak posledních cca 12 let. Je to jednodušší než se spolíhat na to, že mam s sebou rescue flashku. Plus mam připravenou rezervu na případný test.

[lertimir]

No jak se to vezme. Protože patřím mezi psychopaty podle Kedar, jelikož používám BTRFS všude už asi 4 roky a na SSD už asi 7 let, tak mimální je oddělit swap (ať již pro hibernaci nebo na desktopu jako paměťovou rezervu) samozřejmě oddíl na SSD a také mít oddělený systém od dat považuji pořád za výhodné, primárně systém umožnuje snapshotovat před a po aktualizaci nebo ještě průběžně, takže jsem významně omezil problém, který po aktualizaci může nastat. lze se triviálně vrátit. A oddělení umožňuje i jednoduchou změnu distribuce, což jsem se za těch cca 7 let rozhodl sice jen jednou, ale nemusel jsem se o data starat. dokonalé snapshotování systému má opensuse (nicméně je třeba si to projít aby se snapshoty nezaplnil disk), v Archu podobné nastavení chtělo celkem více ruční práce.

[k3dAR]

to sem oznacil pro pouziti 10let se 7 ses v rozsahu mezi experimentatorem (Ty spis nez psychopatem) a normalnim uzivatelem
jinak btrfs snapshoty pri aktualizaci/instalaci balicku pres apt umoznuje i *buntu/Mint diky balicku apt-btrfs-snapshot
pripadne rucni snapshot dle potreby delavam i s LVM/EXT4 (jiste by to take slo automatizovat vcetne prislusnych grub polozek pro start predchoziho stavu...)

[lertimir]

Jenže pak tam musíš mít btrfs, který nemáš rád. Ruční snapshoty na LVM jsou něco úplně jiného. LVM snapshot je udělat rychle zazálohovat a smazat. Pokud bys měl na LVM vytvořených třeba 15 snapshotů v různých časech, tak se ti systém zastaví, BTRFS je to jedno, jen si musíš hlídat abys měl na oddílo dost místa, aby se tam vešla veškerá data. (ale to jistě víš). Nevím přesně co umí apt-btrfs-snapshot, ale myslím, že openSUSE má zvládnuté snapshoty na zcela jiné úrovni než jakákoliv jiná distribuce. Má je propojené a zcela funkční s menu GRUBu. To znamená, že v grubu máš standardní malé menu s položkami aktuálním jádrem a rozšířenými možnostmi. Nicméně v rozšířených možnostech máš volby "spustit snapshot" a mužeš si vybrat který, spustit jej a vyzkoušet jestli je to ten správný návrat, a "Vrátit se na snapshot" kdy se vše ve FS vrátí na snapshot a vše novější se zapomene. Provedení snapshotů je zapíše a propracuje do funkčních struktur Grubu. Spustit snapshot funguje i při katastrofě. Jednou se mi před lety podařilo na manželčině notebooku spustit "distribution upgrade" a byl jsem unaven a nezkontroloval volný prostor předtím a v průběhu instalace upgrade došlo místo. chvili jsem se to pokoušel neúspěšně opravovat, a pak hledal jak z toho ven. Tehdy jsem ani nevěděl že tuhle možnost tam grub má, a našel v něm předchozí snapshoty a jednoduše jsem našel snapshot před upgadem, bootl jej, vytvořil místo a provedl upgrade správně. Proto mám rád GRUB. Tohle neuděláš na UEFI, tam když si zmrvíš jádro nastává boj. Tady se snapshoty a provázáním snapshotů do bootu jsi v klidu.

[lertimir]

Má to jedinou nevýhodu, zabírá to místo. Ale na druhou stranu, když už poklesla cena SSD tak že slušný 500G disk pořídím do 3k tak věnovat třeba 80G-100G na systém s jeho snapshoty není zase tak problém aspoň pro mne. (zkus si suse ve virtuálu a uvidíš jak se s ním snapshotuje. (i manager snapshotů v yastu je přijemný, samozřejmě vše se dá řídit snapperem z command line).

[Aleš Kapica]

Zbytečné opičky. Btrfs snapshoty si můžeš klidně čas od času promazat sám. A pokud neděláš často velké změny, tak ti ani nezaberou moc místa. A co je velká změna? Stáhneš pár filmů, mezi tím uděláš několik snapshotů. filmy sice smažeš. Ale ve snapshotech ti straší dál.

[Petr Fiedler]

Zbytečné opičky. Btrfs snapshoty si můžeš klidně čas od času promazat sám. A pokud neděláš často velké změny, tak ti ani nezaberou moc místa. A co je velká změna? Stáhneš pár filmů, mezi tím uděláš několik snapshotů. filmy sice smažeš. Ale ve snapshotech ti straší dál.

Kdybys měl ale /home jako subvolume, tak by to bylo v pohodě, ne?

[Aleš Kapica]

Abys mohl snapshotovat /home, tak ho musíš mít jako subvolume.

[k3dAR]

urcite, kdyz mas /home jako oddelene btrfs subvolume, nebo jako oddelene LVM LV, tak kdyz udelas snaphost / tak samozrejme v nem neni nic z oddeleneho /home

[Petr Fiedler]

Tak to je pohodička, ne?

[Josef Kufner]

Však ono by to jinak ani nedávalo smysl. Jen zbývá otázka, co s /var – tam je uživatelských dat spousta, ale rozbít se to může taky. Asi to bude chtít druhý subvolume.

[Petr Fiedler]

Přesně to mám v plánu.

[Aleš Kapica]

Chyba pánové! Na subvolume má být celý systém, ne jenom vybrané adresáře. Jinak to moc nedává smysl.

[k3dAR]

nejde o to ze nemam rad btrfs, spis nemam rad fanatiky(nerikam ze Ty) co pisou ze "nic jineho neexistuje", + sam jeho nasazeni jeste odkladam...

o nevyhode mnozstvni LVM snapshotu vs vyhode mnozstvi BTRFS snapshotu vim a psal sem
myslim ze sem zminoval nekde i vyhodu btrfs auto snapshotu v grum menu dostupnych, mel sem za to ze to prave umi i apt-btrfs-snapshot, ale nevim, vyzkousim ve virtualu...

[Petr Fiedler]

Klidně můžu dát na / 30 GiB a na /var 30 GiB. Pohoda! Nebo klidně i víc.

[Petr Fiedler]

Akorát tedy přemýšlím o tom, jak to bude s TRIMem? Když vytvořím zvláštní oddíl pro /var, tak aby se data na SSD nezapisovala stále do stejných buněk, nebo jak se tomu říká?

[SpaceExplo]

Rozdeleni na partition nema s TRIMem nic spolecneho. SSD je (narozdil od HDD) uplne jedno, kam jaka data patri, uklada si je podle sve vlastni logiky.

[Petr Fiedler]

Tak to je fajn, díky.

[Andrej]

… který by měl být rozdělen …

Proooooooooooooooooooooooooooooooooč? Zásada číslo 1: Nedělit, nedělit, nedělit. A když se to provalí, tak zase nedělit. Tohle dělení je nakažlivá choroba z 90. let minulého století, která v dnešní době prostě nedává smysl.

Nedávno mi při instalaci Debianu na externí disk instalátor hlásil, že při vytváření oddílů došlo ke špatnému zarovnání a vytvořil mi oddíly tak, že na začátku disku bylo relativně dost volného místa.

Oddílům je dobré se vyhnout. Na UEFI je doporučený počet oddílů 2 (UEFI FAT a zbytek); na starém BIOSu jeden jediný. Pak se člověk vyhne většině překvapení kolem zarovnání dat.

Chci šifrovat celý disk. Musím použít LVM?

Ne. Na šifrování je LUKS. LVM nemá s šifrováním nic společného.

Pokud ne, je lepší jej použít, nebo ne?

Ne. Čím méně vrstev, tím lépe. Na desktopu a notebooku je počet use case pro LVM spočitatelný nikoliv na prstech jedné ruky, nýbrž jedním prstem. V drtivé většině případů není LVM potřeba.

Když nainstaluji Debian např. na desktop, půjde pak s ohledem na šifrování vytvořit zálohu Clonezillou a obnovit jí na druhý stroj?

Nevím, co je clonezilla. Na zálohy je rsync. Tím půjde vytvořit cokoliv kdekoliv odkudkoliv kamkoliv. Pokud jde o nízkoúrovňové zálohování disků, LUKS kontejner v souboru lze (přes loopback, příkaz losetup) otevřít naprosto přesně stejným způsobem jako LUKS kontejner v diskovém oddíle.

Chci mít v pc i ntb stejná data. Syncuji tedy obousměrně oba stroje na síťový disk, který je zapojen do Raspberry s Raspbianem. Půjde nějak nastavit, aby např. při startu desktopu probudil desktop Raspberry a nějaký skript s heslem v desktopu by zadal heslo do RPi, to by naběhlo a v RPi by byl další skript, který by odemčel šifrovaný síťový disk, provedla by se sync a při vypnutí desktopu by se opět vše vypnulo?

To první samozřejmě jde.

To druhé, tedy automatické vypínání, je podivný nápad, ke kterému může být těžké najít řešení. Systémy unixového typu jsou optimalizované na maximální uptime a spolehlivost. Nejsou stavěné na to, by se náhodně na povel vypínaly. K tomu vypínání neexistuje důvod, pokud k tomu stroji nezíská přístup nepřítel s kapalným plynem. A pokud takový nepřítel existuje … no, pak není snadné se s tou hrozbou vypořádat v amatérských podmínkách a možná je pak stejně všechno fuk.

[GeorgeWH]

Zase si im usiel?

[Andrej]

Nějaké kloudné argumenty by byly, nebo se jen snažíš napodobit místní anonymy?

[Petr Fiedler]

… který by měl být rozdělen …

Proooooooooooooooooooooooooooooooooč? Zásada číslo 1: Nedělit, nedělit, nedělit. A když se to provalí, tak zase nedělit. Tohle dělení je nakažlivá choroba z 90. let minulého století, která v dnešní době prostě nedává smysl.

Když jsem instaloval Windows, tak jsem si rozdělil disk na oddíl pro Winloader, oddíl pro systém (C:) a datový oddíl (D:). Po nainstalování systému jsem provedl zálohu celého disku. Pak jsem nakopíroval data na datový oddíl a zašifroval zaváděcí a systémový oddíl. Když se Windows rozbily, mohl jsem rovnou ze zálohy obnovit zaváděcí oddíl a systémový oddíl a datům se nic nestalo. Kdybych neměl datový oddíl, tak bych musel nabootovat z Live, zkopírovat data, což by trvalo, pak obnovit systém a pak ta data nakopírovat zpátky. Takže z tohoto důvodu. I když v nevím, jestli by to v Linuxu takto šlo. U Windows můžeš šifrovat až po instalaci, takže si můžeš udělat zálohu a pak teprve šifrovat. V Linuxu to takto myslím nejde a nevím, jestli by šlo vytvořit obnovitelnou zálohu šifrovaného disku.

Teď si ale uvědomuji, že by to takto řešit už možná ani nebylo potřeba. Tenkrát jsem moc nezálohoval a nesyncoval. Udělal jsem zálohu vždy ručně např. jednou za 3 měsíce. Takže tenkrát hrozila ztráta dat a bylo výhodnější oddělit data od systému. Dnes mám nastavenou synchronizaci dat na síťový disk, která se provede vždy po startu stroje (několikrát denně) a ještě mám nastaveno, aby se mi dvakrát týdně provedla přírustková záloha na zálohovací disk, který mám v pc. A ještě se data ze síťového disku syncují do notebooku, takže dnes ztráta dat asi nehrozí a možná bych tedy disk dělit nemusel.

Ale když o tom přemýšlím, tak mít oddělený /var by mohlo být užitečné, když se ti právě něco zblázní a genaruje to log za logem. Nedávno tu někdo psal, že mu to za den zaplnilo celý disk. Takhle by to zaplnilo pouze oddíl /var.

A taky kdybych při obnovení systému ze zálohy nemusel obnovovat data, protože by byla sólo na /home, tak by se zbytečně neničil SSD disk.

Pokud ne, je lepší jej použít, nebo ne?

Ne. Čím méně vrstev, tím lépe. Na desktopu a notebooku je počet use case pro LVM spočitatelný nikoliv na prstech jedné ruky, nýbrž jedním prstem. V drtivé většině případů není LVM potřeba.

Já vlastně dynamický oddíl na nic nepotřebuji. Jde mi hlavně o spolehlivost. Pokud to bude bez LVM stabilnější, tak to preferuji a nevadilo by mi, i kdybych musel zadávat heslo vícekrát.

[Andrej]

Já vlastně dynamický oddíl na nic nepotřebuji.

Ten nepotřebuje nikdo; dynamickou alokaci místa má na starosti filesystém, ideálně Btrfs. Tam si člověk může vytvářet subvolumes a další libůstky, aniž by si předem nějak dělil disk. Dělení disku vždy nakonec znamená, že někde nebude místo, když ho uživatel potřebuje, a někde se naopak bude místem plýtvat. Proto byly někdy v 60.–70. letech vynalezené filesystémy, aby se s místem dobře hospodařilo, ale bohužel to trvalo až do 21. století, než se dostaly do současné podoby (ZFS, Btrfs), která s místem opravdu rozumně hospodaří a zároveň umí pracovat s dnešními velikostmi disků [TB], která s sebou nese silent data corruption a další zajímavosti..

Jde mi hlavně o spolehlivost. Pokud to bude bez LVM stabilnější, tak to preferuji a nevadilo by mi, i kdybych musel zadávat heslo vícekrát.

Bez LVM nebude nic stabilnější; o to vůbec nejde. U Linuxu není potřeba řešit otázku, jestli je nějaká abstrakce nad úložištěm stabilní. Je. Prostě je. Jediná otázka je, jak flexibilní je takové využití volného místa a jestli nabízí něco zajímavého navíc. Například opravdový RAID (ne pouze AID), dynamickou alokaci místa bez jakéhokoliv explicitního zásahu atd. Obojí nabízí například Btrfs, zatímco LVM nic z toho nemá. (Zdánlivě má RAID, ale ve skutečnosti jde pouze o AID, který se rozsype při první silent data corruption.)

Když jsem instaloval Windows, tak jsem si rozdělil disk na oddíl pro Winloader, oddíl pro systém (C:) a datový oddíl (D:). Po nainstalování systému jsem provedl zálohu celého disku. Pak jsem nakopíroval data na datový oddíl a zašifroval zaváděcí a systémový oddíl. Když se Windows rozbily, mohl jsem rovnou ze zálohy obnovit zaváděcí oddíl a systémový oddíl a datům se nic nestalo. Kdybych neměl datový oddíl, tak bych musel nabootovat z Live, zkopírovat data, což by trvalo, pak obnovit systém a pak ta data nakopírovat zpátky. Takže z tohoto důvodu. I když v nevím, jestli by to v Linuxu takto šlo. U Windows můžeš šifrovat až po instalaci, takže si můžeš udělat zálohu a pak teprve šifrovat. V Linuxu to takto myslím nejde a nevím, jestli by šlo vytvořit obnovitelnou zálohu šifrovaného disku.

Na úrovni filesystému můžeš zálohovat a šifrovat cokoliv. Například v Btrfs si můžeš udělat atomický snapshot filesystému a z něj pak pomocí rsync všechno zazálohovat na jiný (nejlépe šifrovaný) filesystém, třeba NFS4 někde na síti, externí disk nebo tak.

Pokud jde o nízkoúrovňovou fyzickou zálohu celého disku, jak už jsem psal, pomocí LUKS můžeš otevřít loopback soubor s obrazem toho disku stejným způsobem, jakým bys otvíral normální disk. Jenom je otázka, proč něco takového dělat, když fyzické zálohování disku s sebou zbytečně bere i volné místo.

Teď si ale uvědomuji, že by to takto řešit už možná ani nebylo potřeba. Tenkrát jsem moc nezálohoval a nesyncoval. Udělal jsem zálohu vždy ručně např. jednou za 3 měsíce. Takže tenkrát hrozila ztráta dat a bylo výhodnější oddělit data od systému. Dnes mám nastavenou synchronizaci dat na síťový disk, která se provede vždy po startu stroje (několikrát denně) a ještě mám nastaveno, aby se mi dvakrát týdně provedla přírustková záloha na zálohovací disk, který mám v pc. A ještě se data ze síťového disku syncují do notebooku, takže dnes ztráta dat asi nehrozí a možná bych tedy disk dělit nemusel.

tar --listed-incremental je taky možnost, pokud jde o přírůstkové zálohy.

Ale když o tom přemýšlím, tak mít oddělený /var by mohlo být užitečné, když se ti právě něco zblázní a genaruje to log za logem. Nedávno tu někdo psal, že mu to za den zaplnilo celý disk. Takhle by to zaplnilo pouze oddíl /var.

To vůbec není potřeba. Btrfs umí kvóty na úrovni subvolume. Takže /var může být omezený na určitou velikost, ale když člověk jednoho dne potřebuje zazálohovat a transformovat tu jednu obrovskou PostgreSQL databázi ve /var, povolení dalšího místa je triviální záležitost, jeden příkaz, hotovo. Žádné složité změny velikostí oddílů a filesystémů v nich. Proto vždycky doporučuji: nedělit.

A taky kdybych při obnovení systému ze zálohy nemusel obnovovat data, protože by byla sólo na /home, tak by se zbytečně neničil SSD disk.

Ano. Přesně k tomu slouží subvolumes a Btrfs send / receive. A nevyžaduje to žádné a priori dělení disku. Kořen může být subvolume (což je super pro sdílení jednoho filesystému mezi několika distribucemi na tomtéž počítači, pokud to uživatel chce), /home může být subvolume, /var by měl být subvolume, /etc by mohl být subvolume, třeba pro účely nějakého zálohování a snapshotování, atd.

[Petr Fiedler]

Přesvědčil jsi mě. Disk tedy dělit nebudu a půjdu do btrfs a subvolumes

Tady mi Aleš Kapica radí, abych (snad to chápu dobře) navedl na temp místo diskového oddílu ramdisk. Na obou strojích mám 16 GB RAM a ani náhodou je nevyužívám. Co ty na to, udělat to takto?

[ewew]

Dúfam, že si najdeš aj technicku podporu pre dynamické filesystémy.

[jiwopene]

Pokud máte 16 GB RAM, pak bych do toho šel určitě. Já to používám pro kompilaci Linuxu (je to rychlejší než z disku).

Můj /etc/fstab:

none /mnt/ram tmpfs size=3G 0 0

none neznamená vůbec nic – jen vyplňuje 1. sloupec, kde je který disk připojit (můžete si tam napsat cokoliv).

/mnt/ram je kam to připojit (tu RAM). Pro Vás to bude /tmp.

tmpfs je typ filesystému (tenhle dynamicky alokuje místo v RAM a dovoluje swapování). Existuje i ramfs, který určitě nechcete, protože nepodporuje swap, nemá omezenou velikost a jsou tu asi i jiná omezení.

size=3G jsou možnosti oddělené čárkou. Výchozí size (tedy omezení velikosti) je půlka RAM. Pro /tmp asi chcete něco jako size=12G,mode=1777, kde 1777 jsou oprávnění. 1 je tzv. sticky bit, což znamená že přistupovat (např. mazat) smíte jen ke svým souborům a když je vytvoříte, jsou automaticky vaše. 777 znamená, že smí přistupovat kdokoliv.

První nula souvisí s programem dump (nepoužívat) a druhá souvisí s kontrolou FS (nekontrolovat).

Dá se to použít na jakémkoliv počítači, protože tmpfs použije swap místo RAM, když je třeba.

[Petr Fiedler]

Díky, díky, díky :)

A dá se to tak použít na LVM+LUKS+ext4?

[Josef Kufner]

LUKS + LVM + Ext4.

Jo, nijak se to nevylučuje – tmpfs ani ostatní připojené file systémy nijak nesahají na to, kam jsou pripojené.

[Petr Fiedler]

Vše jsem v /etc/fstab nastavil pesně podle tvého návodu a zdá se, že to funguje :) Jen v /tmp byly kromě ram vidět i nějaké 4 adresáře. Tak jsem je smazal, rebootoval a po naběhnutí systému tam zase byly 2 adresáře - ssh-něco a pulse-něco. To je v pořádku? Já právě myslel, že se tam nic nebude ukládat a vše bude v té paměti.

[Josef Kufner]

Však jo, je to v paměti. Odpoj /tmp a zmizí to. Připoj a už se to nevrátí.

[Petr Fiedler]

Však jo, je to v paměti. Odpoj /tmp a zmizí to. Připoj a už se to nevrátí.

Ať dělám co dělám, nedaří se mi to. Mohl bys mi sem prosím tě dát příkazy (syntax)?

[Aleš Kapica]

Když z toho máš otevřené soubory, tak to pochopitelně neodpojíš. Musíš zastavit démony co to používají, jako např. systemd Tzn. že pokud tvůj systém používá systemd, tak to neodpojíš. Tudíž to platí pro systém, co používá klasický init. Ale stejně – proč bys to dělal?

[Petr Fiedler]

Ale stejně - proč bys to dělal?

No, to co se mi na /tmp/ram líbilo a to proč jsem se rozhodl to takto používat bylo to, že je to rychlejší a že se noopotřebovává SSD. A tak bych chtěl, aby bylo VŠECHNO v /tmp/ram, a ne něco v /tmp/ram a něco v /tmp. To IMHO postrádá logiku.

[jiwopene]

Můj /etc/fstab obsahuje tohle (část s /tmp):

none /tmp tmpfs size=16G,mode=1777 0 0

[Petr Fiedler]

Ale stejně – proč bys to dělal?

Samozřejmě máš pravdu. Špatně jsem pochopil řádek o připojném bodu a místo /tmp jsem do /etc/fstab zadal /tmp/ram a pak mi vadilo, že v /tmp je něco mimo adresář /ram. Už jsem to opravil a je to v pořádku.

[Aleš Kapica]

P.S.: Základní rozdíl mezi /tmp na blokovém zařízení oproti RAM je v tom, že se jeho obsah po restartu zahodí. Takže pokud máš zvyk si něco odkládat do /tmp na někdy, tak o to přijdeš. Na druhou stranu se ti nestane, že by se ti kvůli nahromaděným blbostem v /tmp zapráskal disk.

[dustin]

Některé distribuce /tmp při startu mažou.

[Petr Fiedler]

P.S.: Základní rozdíl mezi /tmp na blokovém zařízení oproti RAM je v tom, že se jeho obsah po restartu zahodí. Takže pokud máš zvyk si něco odkládat do /tmp na někdy, tak o to přijdeš. Na druhou stranu se ti nestane, že by se ti kvůli nahromaděným blbostem v /tmp zapráskal disk.

To se mi na tom právě líbí.

[jiwopene]

Máte tam mít /tmp a ne /tmp/ram

[Petr Fiedler]

Ano, už je to opraveno. Uvědomil jsem si to, když jsem četl tenhle tvůj příspěvek. Díky :)

A budu rád, když mi nebudeš vykat.

[ewew]

Ten nepotřebuje nikdo; dynamickou alokaci místa má na starosti filesystém, ideálně Btrfs. Tam si člověk může vytvářet subvolumes a další libůstky, aniž by si předem nějak dělil disk. Dělení disku vždy nakonec znamená, že někde nebude místo, když ho uživatel potřebuje, a někde se naopak bude místem plýtvat. Proto byly někdy v 60.–70. letech vynalezené filesystémy, aby se s místem dobře hospodařilo, ale bohužel to trvalo až do 21. století, než se dostaly do současné podoby (ZFS, Btrfs), která s místem opravdu rozumně hospodaří a zároveň umí pracovat s dnešními velikostmi disků [TB], která s sebou nese silent data corruption a další zajímavosti..

A načo je dobré dynamické alokovanie priestoru. Jedine na zdržovanie disku.

Bez LVM nebude nic stabilnější; o to vůbec nejde. U Linuxu není potřeba řešit otázku, jestli je nějaká abstrakce nad úložištěm stabilní. Je. Prostě je. Jediná otázka je, jak flexibilní je takové využití volného místa a jestli nabízí něco zajímavého navíc. Například opravdový RAID (ne pouze AID), dynamickou alokaci místa bez jakéhokoliv explicitního zásahu atd. Obojí nabízí například Btrfs, zatímco LVM nic z toho nemá. (Zdánlivě má RAID, ale ve skutečnosti jde pouze o AID, který se rozsype při první silent data corruption.)

Stabilnejšie to bude, pretože menej kódu kde môže byť chyba.

Pokial viem tak RAID by nemal porušiť data na druhom disku pokial sa nové data nezapíšu. Porušenie dát môže nastať v prípade, že sa dá synchronizácia poľa ale toto pravdepodobne závisi na správcovy. Ale keď správca vynutí znovu zaradania disku do poľa ale tam je navine ta osoba nie nástroj ako taký.

Na úrovni filesystému můžeš zálohovat a šifrovat cokoliv. Například v Btrfs si můžeš udělat atomický snapshot filesystému a z něj pak pomocí rsync všechno zazálohovat na jiný (nejlépe šifrovaný) filesystém, třeba NFS4 někde na síti, externí disk nebo tak.

Pokud jde o nízkoúrovňovou fyzickou zálohu celého disku, jak už jsem psal, pomocí LUKS můžeš otevřít loopback soubor s obrazem toho disku stejným způsobem, jakým bys otvíral normální disk. Jenom je otázka, proč něco takového dělat, když fyzické zálohování disku s sebou zbytečně bere i volné místo.

Bude potom možné aj použiť nástroj, ktorý hladá súbory na základe znakov daného typu súboru ?

To vůbec není potřeba. Btrfs umí kvóty na úrovni subvolume. Takže /var může být omezený na určitou velikost, ale když člověk jednoho dne potřebuje zazálohovat a transformovat tu jednu obrovskou PostgreSQL databázi ve /var, povolení dalšího místa je triviální záležitost, jeden příkaz, hotovo. Žádné složité změny velikostí oddílů a filesystémů v nich. Proto vždycky doporučuji: nedělit.

A čo keď ta kvôta zlyha ?

Ano. Přesně k tomu slouží subvolumes a Btrfs send / receive. A nevyžaduje to žádné a priori dělení disku. Kořen může být subvolume (což je super pro sdílení jednoho filesystému mezi několika distribucemi na tomtéž počítači, pokud to uživatel chce), /home může být subvolume, /var by měl být subvolume, /etc by mohl být subvolume, třeba pro účely nějakého zálohování a snapshotování, atd.

A znova to premiešavanie dát s systémom.

[Petr Fiedler]

Taky zajímavé! Chmm ...

[Josef Kufner]

Asi nejlepší řešení je použít btrfs a dát si systém, temp a home na samostatné subvolumes. Pak můžeš dělat snapshoty systému před upgrade pro snadný rollback. Narozdíl od oddílů není potřeba řešit velikost, neboť volné místo sdílejí.

[Aleš Kapica]

Jestli má dost paměti, je lepší na temp navěsti místo diskového oddílu ramdisk. Pro samostatné subvolume je výhodné především pro systém. Může si ho pak snapshotovat před nějakou větší aktualizací při instalací. Home na samostatné subvolume – proč ne.

[Josef Kufner]

Pokud je systém v jednom subvolume, pak musí být home ve druhém. Jinak to nejde.

[Petr Fiedler]

@Josef Kufner&Aleš Kapica:

Když jsem četl o nedostatcích btrfs, bál jsem se ho použít. Ale na druhou stranu si říkám, že když mi jej oba doporučujete, tak vám asi šlape dobře. Asi to tedy zkusím.

Vandrovník mě nahlodal pro LVM. Šlo by tedy:

1. Použít btrfs+LVM
2. Musel bych vytvořit subvolume pro /home?
3. Jak na /temp navedu ramdisk? Už při instalaci?
4. Zatím řeším jen desktop. Budu na něm mít Legacy. Instalátoru Debianu se nelíbilo, že mám šifrovaný oddíl s kořenovým adresářem a chtěl po mně, abych vytvořil nešifrovaný /boot. Půjde nějak s využitím LVM udělat, aby bylo šifrované vše? Nedávno mi k3dAR pomáhal udělat šifrovanou flešku s Mintem, která byla EFI/Legacy a tam bylo šifrované vše.

[Kit]

Tuším, že tady byla kdysi zmínka o tom, že když máš BTRFS, tak už nepotřebuješ LVM, protože BTRFS už má vše potřebné.

[Josef Kufner]

Na btrfs nefungují swap soubory. Takže je potřeba mít swapovací oddíl, aby například fungovala hibernace (uspání na disk). Na to se hodí LVM, aby to bylo šifrované najednou a odemykalo se to společně. Můžeš ale LVM vynechat a mít swap šifrovaný samostatně.

Nešifrovaný /boot je rozumná volba, neboť Grubu to šifrování moc nejde (nabootuje, ale trvá mu to dloooouho).

Určitě chceš bootovat po UEFI, ale bez Secure Bootu. Na legacy bootování se vybodni. Takové nastavení ochrání tvá data před zlodějem, ale na evil maid útok to chce rozchodit Secure Boot a mít všechno podepsané. To si ale nech na dlouhé zimní večery.

[Petr Fiedler]

Nešifrovaný /boot je rozumná volba, neboť Grubu to šifrování moc nejde (nabootuje, ale trvá mu to dloooouho).

Netroufnu si oponovat, protože tvoje a moje znalosti, to je jako sto a jedna, ale ta šifrovaná fleška co mám (USB 3.0) mi bootuje ralativně rychle a přitom to odemyká GRUB.

Určitě chceš bootovat po UEFI, ale bez Secure Bootu. Na legacy bootování se vybodni. Takové nastavení ochrání tvá data před zlodějem, ale na evil maid útok to chce rozchodit Secure Boot a mít všechno podepsané. To si ale nech na dlouhé zimní večery.

Ne, nespletl jsem se. Měl jsem na mysli opravdu Legacy. Mám totiž takovou divnou MB (Gigabyte Z170-D3H). V BIOSu se sice dvě položky dají přepínat UEFI/Legacy, ale nikdy v životě se mi nepovedlo nic nainstalovat jako UEFI. A Secure Boot už vůbec nemá. To mě právě dost štve, jinak bych samozřejmě bez váhání šel do UEFI&Secure Boot. Che, a to je ta MB stará jen něco přes 3 roky. Vždy, když jsem instaloval do dual bootu Mint a spustil jsem instalaci jako UEFI, tak mi to psalo, že FW tohoto počítače spustil instalaci v režimu kompatibility a že na pc je další OS a jestli budu dál pokračovat v instalaci, tak že pravděpodobně jeden ze systémů nepůjde zavést. I když teď si uvědomuji, že to bylo vždy možná tím, že jsem (asi) neměl Windows nainstalované jako UEFI, nevím.

[Petr Fiedler]

Nešifrovaný /boot je rozumná volba, neboť Grubu to šifrování moc nejde (nabootuje, ale trvá mu to dloooouho).

Tak jsem ti to Josefe změřil. Zadal jsem heslo a doba od stisknutí enteru po objevení se plochy odpovídá 27 vteřinám. To bych řekl, že je hodně slušné, když ještě vezmu v potaz, že jde o flešku 3.0 s max. rychlostí čtení 80 MB/s. SSD mi čte 540 MB/s. To by teda byl fofr :)

Teď se mi s tím nechce šachovat, ale zítra sundám kšandy z SSD, aby na mě instalátor zase nekřičel a zkusím spustit instalaci Linuxu s UEFI. To jsem zvědavý.

Tak zatím ...

[Josef Kufner]

Zadal jsem heslo a doba od stisknutí enteru po objevení se plochy odpovídá 27 vteřinám.

Však říkám, že to trvá dlouho.

[Aleš Kapica]

Pokud chce používat uspávání, tak ano – pak má smysl nechat místo na swap. Ale pro mne osobně to je o ničem. Stejně většinou původní myšlenku zapomenu, než se k tomu zas dostanu.

Šifrování je podle mého názoru obsese. Většinou jste spíš naopak rádi, když toho máte minimum co vám v případě nějaké havárie brání při záchraně dat.

UEFI je hňupina. Jak už jsem psal, mám rozepsaný blogpost kde se o tom rozkecávám více, ale nestíhám psát – je toho teď zkrátka na zpracování a zdokumentování hodně.

[Josef Kufner]

Šifrování je podle mého názoru obsese. Většinou jste spíš naopak rádi, když toho máte minimum co vám v případě nějaké havárie brání při záchraně dat.

Pokud se jedná o notebook nebo telefon, který se nosí všude možně a je reálné riziko, že ho někdo ukradne, tak je to docela opodstatněná obava a rozumné řešení. Navíc instalátor i zbytek systému s tím počítá a funguje to zcela bez problémů (alespoň na Debianu). Jediné co, tak to stojí trochu výkonu.

[Aleš Kapica]

Šifrování je podle mého názoru obsese. Většinou jste spíš naopak rádi, když toho máte minimum co vám v případě nějaké havárie brání při záchraně dat.

Pokud se jedná o notebook nebo telefon, který se nosí všude možně a je reálné riziko, že ho někdo ukradne, tak je to docela opodstatněná obava a rozumné řešení. Navíc instalátor i zbytek systému s tím počítá a funguje to zcela bez problémů (alespoň na Debianu). Jediné co, tak to stojí trochu výkonu.

Možná jsem naivní, ale řekl bych, že vybrakování mých dat je mimo rozsah mentálních schopností těch, co tyhle věci kradou. A u projektů, v režimu utajení by mělo takové zařízení vždy fungovat pouze jako tenký klient.

Vaše osobní data jsou zcela nezajímavá a v případě krádeže o ně přijdete ať je disk šifrovaný, nebo ne. Prohlížet si je z dlouhé chvíle nejspíš nikdo nebude. Na to není čas.

[Pavel 'TIGER' Růžička]

Mám podobný názor, na data, které potřebuji chránit mám 8GB, šifrovanou flashku a je na ní hromada místa.

[Josef Kufner]

To je velmi nezodpovědný a hloupý přístup. Že to je zloději na nic je celkem možné, ale někdo další už může být mnohem šikovnější. Zajímavých a reálně zneužitelných dat se na mém disku nachází spousta a rozhodně nechci, aby se dostala kam nemají. Také by nějaká ta NDA s tebou nesouhlasila. A jsem si docela jist, že toto bude případ většiny lidí, kteří počítač používají trochu aktivněji.

A mimochodem, o data nepřijdu, neboť jsou denně automaticky zálohovaná a ta nejproměnlivější data se průběžně synchronizují.

[Petr Fiedler]

Původně jsem se do této debaty mezi tebou a Alešem nechtěl pouštět, protože jsem si nebyl jistý, jestli by to bylo k dobrému, ale když jste to tu tak rozvířili, tak bych zde rád uvedl, že to vidím de facto jako ty.

Abys v tom nebyl sám, noo.

[Aleš Kapica]

Také by nějaká ta NDA s tebou nesouhlasila.

To věřím, že by nesouhlasila. Protože základním cílem všech obhájců NDA je aby se náhodou někdo nedozvěděl, že většina jejich dat stojí za starou belu. Takže musí mlžit za každou cenu.

Realita je taková, že čím komplikovanější systém a opruz, tím větší pravděpodonost úniku dat. Mohl bych vyprávět řadu příkladů z korporátů, s nimiž se setkali mí přátelé.

A jsem si docela jist, že toto bude případ většiny lidí, kteří počítač používají trochu aktivněji.

V takovém případě by se svým počítačem asi museli chodit i spát, aby to jejich použití ve srovnání s tím mým vypadalo aktivněji.

[lertimir]

Nemám pocit, že by šifrování v grubu bylo pomalejší než v systému. Samozřejmě když mám nastavení iterace v PBKDF2 dlouhé tak to trvá dlouho. A za druhé když má šifrovaný boot tak se dešifrování děje 2 krát. jednou dešifruje grub aby načetl jádro a initramfs a po druhé to dělá initramfs na zbytek systému

[Josef Kufner]

Rozdíl tam je v (ne)použití nějakých lepších instrukcí, takže ve výkonu je hodně velký rozdíl. Nezkoumal jsem o co přesně tam jde, nějaké zmínky o iteracích jsem v bugreportech zahlédl, ale nechtělo se mi to řešit ani podrobněji zkoumat. Vlastně jsem Grub vyhodil a teď bootuju kernel rovnou z UEFI.

[lertimir]

Jenže to je něco zcela jiného. Pokud bootuješ přímo z UEFI tak nemáš žádnou jinou možnost než bootovat nešifrované jádro, protože do UEFI nedostaneš modul crypt, protože je příliž velký. Pokud bootuješ GRUB a asi je jedno jestli Legacy nebo UEFI, tak máš v GRUBu možnost mít tam i modul crypt, takže kromě GRUBu je zašifrované vše. A proč bych v crypt modulu neměl mít AES-NI instrukční sadu, tak to musel kompilovat magor, protože ta sada je v procesorech Intel nějakých 10 let a v AMD nějakých 8, ale samozřejmě možné to je. Mě boot žádné mimořádné zpoždění nedělá, kromě očekávaného díky dvojímu otevření šifrovaného oddílu.

[Josef Kufner]

Nešifrované jádro jsem začal bootovat rovnou, když jsem zjistil, že Grub nepotřebuju/nechci. Možná si s tím někdy pohraju. V Debianu právě ty AES-NI nejspíš chybí (nebo jsem to nezapnul).

[lertimir]

A u mne je to obráceně. Chci mit minimum nešifrovaných informací. Takže nešifrovaný je jedině GRUB. jednak je ho méně, a jednak nenese ani informaci jaké jádro bootuje.

[Aleš Kapica]

Je to sice z mého pohledu hardcore paranoia, ale takhle nějak si představuji "secure boot". A ne tu parodii co je v UEFI.

GRUB lze chránit heslem, základní moduly do něj zadrátovat a zbytek chránit přes cryptomount. Takže i kdyby se na ten disk někdo dostal, tak z něj data nevydoluje, pokud neví jak to je udělané.

[k3dAR]

to neni moc hardcore, bezne pouzivam sifrovanej / vcetne /boot, v boot ma grub menu a vetsinu modulu, nesifrovanej mam jen grub efi binarku v EFI oddilu... ktera se me zepta na klic k LUKS, nasledne natazenej (po jadre) initramfs uz mam nastavenej aby rootfs odemknbul automaticky a nemusel sem zadavat podruhe LUKS heslo
vice hardcore je jak psal nekde kolem Peter Gollis, mit ten GRUB podepsanej vlastnim klicem a z EFI vyhozene vychozi klice, to ale muj T420s nepodporuje...

[Josef Kufner]

A v čem to je více secure než když tam to jádro je? Evil-Maid útok zabere i na to. Jen místo jádra či initrd je potřeba nahradit Grub. Dokud hardware nepořeší bezpečnost spouštěného kódu (což řeší Secure Boot), tak je úplně jedno, že je na disku nešifrované jádro. Šifrování samotné ochrání proti odcizení stroje, ale neochrání proti (vícenásobnému) dočasnému zapůjčení a manipulaci s ním.

[k3dAR]

Jen místo jádra či initrd je potřeba nahradit Grub

odpovedel sis timto sam upravit initrd aby se zdalo ze zadavas LUKS heslo ale ono se zaroven pres internet oslalo utocnikovi (kterej ten initrd ti zamenil) je 1000x snadnejsi nez upravit GRUB EFI aby udelal totez...

[Josef Kufner]

Pokud někdo bude mít dost motivace na to, aby se obtěžoval s Evil Maid útokem, tak toto je to nejmenší.

[Aleš Kapica]

Příloha:

• naklady.png (5679 bytů)

Je dobré vědět, že takové možnosti existují.

Výsledek se je ale vždy dán vynaloženými náklady a kompromisem mezi mírou složitosti a úrovní zabezpečení. V příloze jsem si dovolil malý graf. Od určité úrovně se (navzdory vynaloženým nákladům) úroveň zabezpečení nezvyšuje, zato narůstá míra složitosti. A to je to oč mi jde – upozornit na tento fakt.

[Aleš Kapica]

Příloha:

• naklady.png (61651 bytů)

Ach jo. To je tak, když se narychlo vyrobí ilustrační graf a před importem se ho opomene zkontrolovat.

[k3dAR]

ehm, transparentni png na mem vychozim cernem pozani v prohlizeci vypadal zajimave, jen ruda linka a modrou hvezdickou na konci )

[k3dAR]

porad plati, ze upravit GRUB EFI na logovani LUKS hesla je 1000x komplikovanejsi nez upravit initramfs
tzn. u uprave initramfs pokud je ulozen nesifrovane staci 1000x mensi motivace "utocnika" a za par minut ma hotovo i kdyz to predtim nikdy nedelal

[Petr Fiedler]

Právě si čtu o subvolumes na btrfs a zjistil jsem, že jsou dva druhy:

• jako každý jiný adresář přístupný uživateli
• jako samostatně připojený souborový systém

Co z toho bych měl použít pro / a /home? Do /tmp dám ramdisk.

[Aleš Kapica]

Chápeš to blbě. Nejsou to dva druhy. Kde to prosím tě čteš?Subvolume na btrfs jenom vypadá jako adresář. Rozdíl je v tom, že si ho můžeš namountovat samostatně.

Jestli si chceš něco přečíst o Btrfs, tak se koukni co jsem o něm napsal do naší wiki.

[Petr Fiedler]

Chápeš to blbě. Nejsou to dva druhy. Kde to prosím tě čteš?

Btrfs.wiki.kernel.org. Je to hned z kraje článku.

Jestli si chceš něco přečíst o Btrfs, tak se koukni co jsem o něm napsal do naší wiki.

Díky! Vypadá to zajímavě a určitě si to nastuduju.

[Aleš Kapica]

No, tak jsi to blbě přečetl. Já teda o sobě soudím, že anglicky moc neumím, ale podle se tam píše:

K subvolume v btrfs lze přistupovat dvěma způsoby: jako k adresáři, který je přístupný pro každého uživatele, nebo jako samostatnému souborovému systému, který lze přimountovat (s využitím volby subvol, nebo subvolid)

[Petr Fiedler]

No, tak jsi to blbě přečetl. Já teda o sobě soudím, že anglicky moc neumím, ale podle se tam píše:

K subvolume v btrfs lze přistupovat dvěma způsoby: ...

No, já „umím“ anglicky patrně ještě méně než ty a proto používám strojový překlad. A překladač mi to přeložil takto:

„Subvolume v btrfs lze získat dvěma způsoby:“.

Tak se nediv.

[Josef Kufner]

Snapshot == read-only subvolume.

[Aleš Kapica]

To není pravda. To 'read-only' neplatí. Defaultně je snapshot po vytvoření 'read-write', což lze změnit volbou '-r' při jeho vytvoření. RW snapshot z RO vytvoříme jednoduše tak, že z toho RO snapshotu uděláme další snapshot.

[Aleš Kapica]

Snapshot == je subvolume, které sdílí data přítomná při jeho vytvoření se subvolume, ze kterého byl vytvořený.

Nově vytvořené subvolume s nikým data nesdílí.

[Petr Fiedler]

Aleši,

článek o btrfs, který jsi napsal je skvělý a jsem rád, že jsem jej četl a že bude v budoucnu z čeho čerpat. Díky.

Ještě jednou jsem to přehodnotil a rozhodl jsem se snad už s konečnou platností, že pokud je btrfs stabilní, tak jej budu používat. Mohl bys mi prosím tě napsat, jaké máš zkušenosti se stabilitou btrfs?

Vlastě bych byl rád, kdyby se vyjádřili i ostatní - Andrej, Josef Kufner i další.

[Aleš Kapica]

Vážný problém provázený ztrátou dat u ext4 několikrát, u btrfs nula. Používám ho od té doby co je v mainline kernelu.

Zrovna dnes jsem pustil scrub na svůj nejstarší Btrfs filesystem u mne doma. Původně běžel jako single Btrfs nad md raid6 ze 4x 2T disků. Teď je to už docela dlouho Btrfs raid 1 nad 6x 2T + 2x 4T. Uloženo 5,7Tb dat. Chyba na úrovni fs žádná.

Zkoušel jsem i Btrfs raid 5/6, ovšem ten HW nad kterým jsem s tím experimentoval byl už zralý na odpis. Nemělo smysl s tím ztrácet čas. Jen jsem si to chtěl vyzkoušet. Tenhle typ raidu měl svého času jeden velký problém - Grub2 ho (na rozdíl od raid1) neuměl přečíst, aby z něj mohl natáhnout kernel.

[Petr Fiedler]

Tak to je skvělé. Celý den trávím u pc čtením článků o btrfs a určitě jej začnu používat.

Mám pár otázek ohledně btrfs, na které jsem nenašel odpovědi. Zítra založím nové vlákno o btrfs a budu rád, když mi ještě pomůžeš.

A díky za informace :)

[Aleš Kapica]

Na tohle téma už tu bylo diskuzí víc než dost. A najdeš v nich určitě i odpovědi na své otázky. Tudíž nezakládej zbytečně další.

Když už, tak to sepiš alespoň jako blogpost.

[Petr Fiedler]

No nic, jdu to testnout na nečisto na sekundární disk. Mám sice pár nejasností např. ohledně šifrování, ale snad se to vystříbří. Na konec jsem se po přečtení článku o btrfs na Debian Wiki rozhodl pro ext4. Btrfs má IMHO své velké klady, ale taky zápory. Disk jsem se rozhodl šifrovat, ale LVM nepoužiji. Dělit budu na /, /home a /var.

Díky všem za rady a názory.

PS: Je to zatím na nečisto. Možná zkusím více instalací a ověřím si výhody a nevýhody v testovacím provozu. Takže jestli někdo bude chtít, klidně může nějakou radu, nebo postřeh ještě napsat.

[vandrovnik]

Díky LVM bývá snadnější přesun systému na jiný disk, zvětšení volume apod. Pokud nic z toho nebudete potřebovat, tak by LVM bylo opravdu zbytečné, já bych ho ale raději použil, protože nějaké ty přesuny většinou časem vždycky byly potřeba.

[Petr Fiedler]

Dovollím si tykat. Taky mi klidně tykej :) Způsobil ti někdy LVM komplikace?

[Kit]

Kdysi se mi (možná i 2×) vysypaly svazky z LVM po výpadku elektřiny. Daly se však dohledat, připojit znovu a jelo se dál.

[Petr Fiedler]

Tak jestli to byl jedniný (double) problém, tak to je v pohodě. Žádná hrůza.

[vandrovnik]

LVM samo o sobě mi nikdy problémy nezpůsobilo. Kdysi se mi jen při testování, když jsem šachoval právě s přesuny na jiné disky, stalo, že jsem přesunul data kupř. z md3 na md4, dal restart, ale md4 se po restartu samo nesestavilo, protože jsem po vytvoření md4 zapomněl spustit mkinitrd. LVM v tom ale bylo nevinně

[Petr Fiedler]

Tak to rád slyším.

[jiwopene]

Na dělení disku (když nestačí to, co má Debian v instalátoru) lze použít cfdisk či cgdisk, který asi má Debian přímo na instalačním CD (Stiskem Alt+F2 nebo Alt+F3 se přepne do shellu, Alt+F1 zpět, Alt+F4 je tuším log).

Pokud chcete stejná data (/home) na obou počítačích, lze použít třeba NFS (pozor, není šifrované! – viz dále), kterým se dají data tahat z druhého počítače. Netestoval jsem to, ale myslím, že by šlo použít NFS přes SSH.

Ta synchronizace „zadat heslo a synchronizuje se” je trochu problematická, protože už musíte být přihlášen (ideálně jí pouštět jen v shellu bez X.Org) a může se měnit konfigurace, což (někdy) znamená nutnost opětovného přihlášení. Druhý, větší problém nastane, když změníte jeden soubor na obou počítačích.

[Petr Fiedler]

Na dělení disku (když nestačí to, co má Debian v instalátoru) ...

Ono to určitě stači, ale tomu, kdo s tím umí. Já jsem např. dnes vytvořil v grafickém instalátoru dva zašifrované oddíly a pak jsem je nebyl schopen smazat.

Druhý, větší problém nastane, když změníte jeden soubor na obou počítačích.

To vím. Ve Windows jsem měl na pc i ntb app na sync, která se spouštěla jen po startu pc. Takže když jsem např. na desktopu změnil nějaký soubor a pak několikrát pustil ntb a změnil ten samý soubor, tak se při každém dalším spuštění ntb syncl na síťový disk a když jsem pak pustil pc, kolize byla na světě. Řešením podle mě je nastavit to tak, aby sync proběhla např. 1 minutu po přihlášení do systému a pak před jeho vypnutím. No, a člověk si pak musí pohlídat co dělá, když si náhodou (jednou za půl roku) pustí ve stejnou dobu pc i ntb. V tom problém nevidím. Spíš jde o to, jak to nastavit, aby se to celé dělo automaticky. Tzn. skripty+hesla v nich.

[SpaceExplo]

Na tu automatickou synchronizaci dat by sel pouzit Syncthing https://syncthing.net/

[Petr Fiedler]

Díky za tip. Já používám tohlea nedám na to dopustit.

On ale není problém čím, ale jak to zautomatizovat?

[Chytrex]

A opravdu nechceš zvážit možnost toho mít ty data vzdáleně na např Rasberry přes NFS? A je jedno zda si to NFS připojíš jako další filesystém do /mnt nebo si vytvoříš vzdálený home dir na tom vzdáleném úložišti, obé je snadnější než vymýšlet nějaké šílenosti se synchronizací.

Proč vlastně tak lpíš na synchronizaci, když sám víš že ti to dělá konflikty atd?

Z mého pohledu je opravdu rozumnější mít na raspberry nějaký systém klidně i bez gui, na něm běžící NFS a na ten se připojovat. Pokud ty data nehodláš používat z více míst zároveň, z mého pohledu se mi jeví možnost mít přístup k aktuálním datům lepší než synchronizace starých dat a řešení konfliktů.

[Petr Fiedler]

Já chci mít na obou strojích identická data, proto sync. Mít data jen na síťové disku nechci, protože ne vždy bude mít ntb přístup k síti a byl bych úplně bez dat. Navíc by byl problém se zálohováním síťového disku. RPi zvládá něco kolem 11,5 MB/s (reálně). Takže když mi má syncnout nějaký texťák, tak je to OK. Ale kdyby se měla někam posílat záloha stovek GB dat, tak by to RPi asi „zhořelo“.

[Pavel 'TIGER' Růžička]

Tak si kup USB switch a měj to na USB disku. Rychlost přenosu bude úplně jinde, než na síti.

[Petr Fiedler]

Zdarec,

mě to teď funguje dobře a jsem s tím spokojen. Nechci nic měnit (sync). To, co chci změnit, jsou operační systémy na těch strojích. Jenže si s tím nevím rady. A taky se motám v tom, co použít za fs. Úplně nejraději bych to měl jak tu flešku, co mi s ní poháhal k3dAR. Tzn. hybrid (Legacy/EFI), LUKS, LVM a ext4 s tím, že bych měl zvlášť kořenový adresář, domovský adresář a var. Žádný swap a šifrovaný úplně celý disk. A na ntb ještě Secure Boot. Ale jak jsem psal, dost v tom plavu. V instalátoru Debianu (míním grafiku) to nastavit nejde a na netu nenacházím, co potřebuji.

Sync teď vůbec neřeším. Nemá to smysl. Budu to řešit, až na to budou připraveny oba stroje.

[Pavel 'TIGER' Růžička]

Ty mne donutíš přečíst si celé vlákno, já reagoval jen na ten sync. Takže nemám páru, v čem plaveš.

[Petr Fiedler]

Ušetřím ti čas.

Trochu to teď zredukuji jen na desktop a některé věci, na které je čas dám bokem. Chci nainstalovat Debian 9.5 Stretch na pc. Chci, aby disk uměl bootovat hybridně - Legacy/EFI bez Secure Bootu. Disk bych chtěl celý včetně EFI šifrovat - LUKS. No, a chci LVM, oddělený /, /var a /home. Včera jsem si cvičně zkusil instalaci bez LVM a šifrovaného EFI. Šifrované byly jen ostatní oddíly. Byl jsem rád, že jsem zvládl alespoň tohle, protože instalátor Debianu je mnohem složitější, než instalátor Mintu. A teď, v čem tedy plavu:

Nedokážu udělat, aby byl disk co se týče bootování hybridní - Legacy/EFI. A nedokážu to nainstalovat tak, aby bylo šifrované vše i s EFI. LVM jsem zatím nezkoušel do instalace nějak zakomponovat, ale to bych asi zvládl.

Tož tak

No, a na notebooku pak ještě k tomu všemu Secure Boot a pak ještě jendu věc, na kterou je zatím brzo.

[Aleš Kapica]

To v čem plaveš, je zrovna to o čem mám rozepsaný ten blog, jenže mezi tím řeším pro mne mnohem důležitější věci, takže dokončení se to stále posouvá. Nevím jestli jsi četl ten můj minulý blogpost o PXE, tak ten jsem psal s přestávkama víc jak 14 dní, a ještě s jeho finální podobou nejsem spokojen.

[SpaceExplo]

Ale ten syncthing by to mel prave umet delat automaticky.

[Petr Fiedler]

FreeFileSync taky syncuje automaticky.

[Pavel 'TIGER' Růžička]

Když na linuxu nepoužiji rsync, tak sahám po DirSync Pro.

[Petr Fiedler]

Nikdy jsem s tím nedělal, ale přijde mi to na jedno brdo s tím, co jsem uvedl.

Jinak rsync je samozřejmě naprostý základ a mám v plánu jej nastudovat, jen je toho prostě moc a nevím co dřív.

[Josef Kufner]

rsync je ale jen jednosměrná synchronizace – na zálohování výborné, ale na vícecestnou synchronizaci se to nehodí. Co takový NextCloud?

[jiwopene]

Já jsem např. dnes vytvořil v grafickém instalátoru dva zašifrované oddíly a pak jsem je nebyl schopen smazat.

Je to tam trochu rozbité. Pomohlo dd if=/dev/zero of=/dev/sdXx ... (smazání toho, co mu vadí – nespouštět!) .

[Petr Fiedler]

Díky, že sis dal tu práci :)

Co to máš za patičku?

[Petr Fiedler]

No nic, díky všem. Pár věcí jsem si upřesnil a v pár věcech ještě zatím tápu. Zítra zkusím hledat na netu a když nenajdu, položím nový dotaz.

Označuji jako vyřešeno.

Mějte se ...

[k3dAR]

vynecham reakce kolem btrfs, sam ho nepouzivam, zkusil jen jednou prekonvertovat ext4 na btrfs a dopadlo to spatne(coz sem tusil a pak mi i bylo logicky nekolikrat potvrzeno ze byl spatnej napad(i presto ze to byl oficialni nastrol na prevod)), ciste btrfs stale odkladam...

ad LUKS = za me urcite ano, nic vic k tomu nemam co rict, proste ano, stiznosti o rychlosti ignorovat

ad LVM = za me urcite ano pri pouziti ext4 (resp. pri nepouziti btrfs nebo zfs(s tim tez zkusenosti nemam)) LVM ma obrovskou vyhodu v tom, ze muzes "rozdelovat" ale nejsi tim omezovan, ja LVM pouzivam tam ze pres celej(kdyz nepocitam pripadne EFI oddil a pripadne BIOS oddil pro podporu LegacyBoot z GPT oddilu) disk udelam 1 oddil, ten zasifruju pres LUKS a ten celej udelam LVM PV (~fyzickej disk pro LVM), v tom celem udelam LVM VG a v nem udelam podle potreby ruzne LV, 1 pro /, 1 pro /boot, 1 pro /home, 1 pro /data, 1 pro swap, pripadne 1 pro /var... velikosti ale urcim dle odhadu/potreby, nikoliv abych cele VG pro ne rozdelil, tzn. ze ve VG pak zustane nepouzite misto... to se pak vyuzije jak pro LV snapshot (ulozeni aktualniho stavu oddilu, pak lze udelat pokus s instalaci neceho co zasahuje hodne do systemu a kdyz se neco podela tak se vratim k predchozimu stavu, kdyz ne, tak lvsnaphot smazu(u btrfs je vyhoda ze podobnych snaphostu muzes mit stovku a nijak to nebrzni, u LVM je lepsi pouzit jen 1 a ten pak zrusit kdyz neni treba), zaroven to nevyuzite misto v VG podle potreby casem pridavam nekterym LV, treba si reknu ze /home chci o par GB vetsi, tak ho zvetsim, to lze za chodu (= pripojenem lv oddilu): lvresize /dev/vg/home -L +2GB -r

ad /tmp v ram = to uz mas vyresene, tak jak to mas je to v pohode...

ad 15GB pro / = i kdyz bys nemel oddelenej /var muze to stacit (pokud mas oddelene /home, nebo to kam davas data), nekdo zminoval ze ve /var se mu kompiluje, to ale pujde o Arch, nikoliv Debian/*buntu/Mint, ty tam maji vetsi jen stazene balicky co si instaloval (lze je mazat: sudo apt clean(delam to po kazde aktualizaci rovnou a nic mi tam pak zbytecne nezabira misto) a pripadne virtualy pro KVM (virt-manager) coz je dobre tak ci tak dat mimo /), nebo mysql databaze (opet je lepsi je mit mimo / (mysleno kdyz nepouzijes samostantj /var)

ad oddelenej /var = je to dobre kdyz chces mit rootfs co nejmensi a/nebo kdyz se bojis ze ti nejakej bug cehosi zacne plnit logy a pak najednou zmrzne system, nejde nastartovat a musis resit livecd/usb abys to promazal... urcite bych ho ale nedaval zbytecne 30GB, protoze jestli se log zaplni do max, tak se zaplni jak pri 5GB var, tak pri 1000GB /var dulezite je to, ze to nesejme system, resp. zacne byt problem ze nema kam logovat, ale stale to muzes vyresit z beziciho systemu, zastavit logovani, presunout log jinam (nebo smazat kdyz hned zjistis co ho zaplnilo) vyresit problem, pustit logovani...

ad swap + LUKS = swap muze byt v LUKS/LVM/LV neni problem, nemusi se delat oddelen mimo LUKS, NAOPAK je to NEVHODNE, protoze pak kdyz mas uspane PC a nekde vezme tvuj disk, tak i presto ze je sifrovanej, tak z nesifrovaneho SWAPu muze vytahnout HROMADU informaci...

ad SSD jako mas USB3 = ten script luksuntu co vzesel z toho vlakna o sifrovani flash, muzes pouzit i na disk jen je hacek ze misto *buntu ted chces Debian, takze ta cast kdy to pousti *buntu instalator by se musela zmenit na pusteni Debian instalatoru

[trevor12]

ma smysl /tmp v ram kdyz mam ssd ? mam kubuntu a 8 gb ram

[Petr Fiedler]

IMHO je to rychlejší a neopotřebovává to SSDčko.

[Aleš Kapica]

Podle mě má, protože tím šetříš to ssd. Je to adresář na dočasné soubory. Pokud máš jenom 8GB RAM, tak si udělej to tom ssd swap – aspoň 8GB – a budeš v pohodě. Pokud bude nějaká aplikace pořebovat uvolnit paměť, tak se ty věci z /tmp přesypou do swapu, ale odpadne režie kterou by s tím měl FS. Při restartu se stejně zahodí.

[Petr Fiedler]

Podle mě to smysl má, ale pro jistotu bych si pokud nemáš vytvořil swap viz. poslední bod v tomto příspěvku.