Bevezető - miért is csináltam?

6 db HDD-n használtam 2 ZFS poolt már vagy 4 éve Debian/Ubuntu alatt, desktopként. Úgy döntöttem, titkosítani szeretném a gépet, mert "mi van, ha ellopják". Történtek hibák, de megúsztam élve a ZFS zsenialitásának köszönhetően. Hozom a sztorit, tanulságként minden merész úttörő számára. ;-)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

DISCLAIMER

Nos, van ez a ZFS dolog. Hogy mi ez, és mire jó, stopperos kolléga már leírta az OpenZFS a mindennapokra című cikkében, a kezdőket, a dologgal ismerkedőket arra kérném, itt kezdjék, hogy értsék a továbbiakat.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

A ZFS-ről annyian mondták már, hogy jó dolog, hogy én is belevágtam. Még a FreeNAS-sal annak idején, 2011-12 körül, majd gyorsan NAS4Free-vel menve tovább - még dedikált NAS gépként - egészen addig húztam ezen hibamentesen (!), míg úgy nem döntöttem, lejövök desktopon is a Windows-ról és Linuxozok. Az azóta megújult PC-mre tehát felkerült a Linux és a diszkekre a ZFS.

OS-ként ősi szerelmemhez, a Debianhoz nyúltam, sokáig itt éltem, majd egy apt full-upgrade során, amikor elszállt valami az nVidia DKMS környékén és érzékenyen érintette a "user experience"-emet, úgy döntöttem, jó ez a közösségi disztró, de talán a Canonicalnál talán minőségibb egy release és annak tartalma. Az XFCE sem jött be maximálisan, úgyhogy Ubuntu lett, 1 hónap után a Gnome-ot kicsit elkezdve unni, már most ismét a Kubuntun gondolkodom (el is dőlt). Vissza a jó kis "tálcás OS"-hez, widgetekkel, asztali ikonokkal.

De ha már Linux újrainstall: néha attól tartok, hogy elviszik a gépet és életem nagy titkaiba belelesnek. Ami valljuk be, kellemetlen dolog. Nagyi, papi, családi fotók, emlékek, hobbi fotósként több ezer RAW fájl, és satöbbi. Ha viszik a PC-t, legalább "csak" ezen morogjak, azon ne, hogy látják is, mi van rajta.

Földszinti lakás, rács nélkül és nem biztonsági ajtó. Valószínűleg túlreagálom, jó a környék, van külső lépcsőházajtó is, de az ördög sosem alszik. Így döntöttem a teljes gép full titkosítása mellett - egy nem szokványos módszerrel megfűszerezve.

Ismét egy disclaimer: igen, mondják, hogy a 'RAID' az magas rendelkezésre állás, nem pedig életbiztosítás és a user error (értsd: törölsz valamit) ellen nem véd, vírus, egyéb szoftveres anomália ellen sem. Ugyanakkor van backupom az égően fontos dolgokról polcon is, felhőben is, mindazonáltal a ZFS RAID az adatintegritás-megőrző képessége miatt (is) van nálam használatban két vagy több diszkkel, ennek miértjére és hasznosságára a fentebb linkelt cikk ad választ.

Tehát biztonság. Legalább egy alap szint. Azt már messziről tudtam, hogy az alaplapi RAID felejtős, egy logikai összefűzés lényegében működik, de nem a legtutibb varázslás, Linux softraid is lenne még, de ZFS-sel össze sem hasonlítható még úgy sem, ha a dm-integrity-vel kombinálva az is tudna ma már integritást is biztosítani (azaz bit rot ellen véd, ami mondjuk CRC elektronika nélküli, jellemzően megfigyelésre szánt diszkeknél - WD Purple, Seagate Skyhawk - előferdülhet, ezeknek a firmware-e ugyanis nem "molyol" annyit hiba esetén a korrekción, mint egy NAS diszk, hiszen ész nélkül nonstop mentenie kell a kamerákból jövő adatot. Tehát kevesen tudják, de NAS célra surveillance firmware-ű HDD limitáltan ajánlott, 24 órát bírja, de itt meg is állt a történet, még a többdiszkes setupra sincsen mind felkészítve, pl. RV szenzorokkal).

Töprengtem, mi legyen, ZFS beépített titkosítás (hiszen tudja), vagy a jó öreg LUKS, végül utóbbira szavaztam, a ZFS bár titkosítani képes, hagy magáról nyomokat a HDD-n, én pedig ennél randomabb "szemetet" szeretnék láttatni a kedves érdeklődővel, aki elviszi-ellopja a masinát. Feltételezve, hogy nem valami forensics cégnél dolgozó kőkemény hacker, de alapvetően nem erre készül az ember és ők nem így szoktak betörni. :)

Nézzük, hogyan képzeltem el az egészet, és mi az alap felállás nálam.

Hardver, 'RAID', logika

Nem mondok újat: a ZFS-hez nagyon ajánlott az ECC memória. Erről lehet vitákat nyitni, milyen gyakran hibázik egy átlag Desktop PC, itt ez most off lenne nagyon, de én eleget tettem ennek és lecseréltem a tuning RAM-jaimat "átlagosabbra" ;)

Konfig:
- ASUS TUF GAMING B550-PRO
... egy MSI B450M-MORTAR-t váltott. A VRM bivaly és teszteken jól szerepelt, én is járattam benne pár hónapig R9-5950X-et (egy állat az a proci), betonstabil lap. Az MSI magasról tesz az ECC támogatásra (legalábbis amikor néztem a lapjait), az ASUS már B450-ek óta simán tudja. ZFS esetén tehát nem kérdés, ASUS (vagy ASROCK, többieket nem néztem). Vagy eleve szerver lap, szerver gép, lehet ezt fokozni, de nem akartam helyből felszálló süvítő valamit a dolgozószobába, illetve desktop módban használom, nem 7/24, bár volt, amikor ment egy hétig, simaliba.
- AMD Ryzen 3-3100
... alap órajelen, Precision Boost auto-n, ennyi. Tökéletes még játékra is, nemhogy ilyen desktop/NAS célra.
- 2 x 16 GB Samsung DDR4-2400 ECC UDIMM
... No, ez különleges. Túl azon, hogy természetesen "unregistered" ECC UDIMM kell egy mezei desktop-ba, ezek a RAM-ok a híres, tuningra alkalmas B-Die chipeket tartalmazzák. Más ne tegye ezt, én vétel óta így használom hibátlanul: ECC:OFF módban (hogy lássam ha hibázik picit is) meghúztam, feszt csak épphogy kapott, és 3500-on vagyok velük, bőven az ECC:OFF mellett érzékelt hibázási határ alatt. ECC:ON és erre rájön még +1 réteg béke. Azóta sincs egyetlen corrected error-om sem, nemhogy uncorrected. A poén kedvéért elvittem ECC:OFF-ban még tovább, elkezdett Memtest-ben hibázni kicsit, de még működött... erre ráaktiválva az ECC-t, ezt még tudta korrigálni a RAM, a Linux logok alapján (és Memtest is kisimult). Tehát az ECC gyönyörűen működik, teszi a dolgát, így nincsen szükségem Xeon-ra. A RAM húzásának amúgy semmi de semmi értelme, pláne nem egy ilyen konfigban, ami nem játékgép, de úgy voltam vele, néha játszok is, bár szerintem 1%-ot se hoz... meg vállvonós.. próbáljuk ki. Ti ne tegyétek. ;) Lehet ekézni, ez van, én szóltam. ;)
- 3 x 8 TB Seagate NAS HDD
- 1 x Intel 250 GB SSD
... sokat ment, még bírja, ő az OS + swap. Még. (Lásd később) ;)

Van egy PCI3.0 8x LSI kontrollerem is, IT módba flash-elve, de nem használom, az alaplapi SATA portok száma elegendő a SATA SSD-imhez és a 3 db HDD-hez. Ha mondjuk 4 diszkem lenne, RAID6 vagy RAID10 felállásban, kettőt alaplapra dugnék, kettőt pedig a kontrollerre, így bármelyik SATA vezérlő hibáját is túlélné a ZFS-em (2 diszk kihalhat adatvesztés nélkül). Eddig nem mentem most, RAID6-nak 5 vagy 6 HDD körül-felett látnám értelmét. Egyszer SSD-kből kirakom valszeg, egy marék 2 T-set készülök úgyis venni és leváltani a HDD-ket, nem hangos vinyók, de engem zavar akkor is..

Apropó, mirror, RAIDZ1:
RAIDZ1-et setupoltam a 3 db HDD-re, ez a pool így 1 diszk elhullása esetén még használható, ennyi elég nekem, sokan nem javasolják a RAID5-jellegű felállást + ott a híres "write hole", ha elszáll az áram, na, itt az sincs... illetve vagy 6 éve élek már RAIDZ1-en (RAID5-ön), és HDD bővítésekkel minden manipulációkkal, verzióváltásokkal, titkosításokkal stb… együtt még mindig él a pool és hibátlan. :)

LUKS2 és egy kis agyalás

Ugyebár mondtam, hogy titkosítani szeretném a teljes gépet és LUKS-ra szavaztam (LUKS2, de igazából innentől LUKS-ozok végig, ha nem gond).

Van tehát 1 ZFS poolom, RAIDZ1, 3 db HDD-vel. Az elméletem az volt, hogy egyenként a HDD-ket kiveszem a ZFS poolból, titkosítom, majd a titkosított meghajtót feloldva, a feloldott "virtuális" eszközt adom vissza a poolnak, az resilveringgel felépíti azt, és ollé. Adatok megmaradnak, 1 HDD pipa, jön a többi, ugyanígy... egyesével mind a 3.

Elsőre az azonnal látszott számomra, hogy a RAIDZ1-ből egyet kivéve a hibatűrés megszűnik, még használható a pool, adatvesztés nincs, de erre van némi esély, amikor az újra visszaadott eszközt elkezdi resilverelni, hiszen olvasással ugyan, de beterheli a másik kettőt. Többek között ezért sem ajánlják a RAID5-öt, de figyelembe véve, miket tartok rajta, számomra megfelelő egyensúlyt jelent egy 3-diszkes RAIDZ1 tárhely és megbízhatóság/védelem tekintetében + akkor az adatok integritása is pipa.

Tekintettel arra, hogy ezek 0 szektoráthelyezett, 100/100-as garis Seagate-ek, megkockáztattam a dolgot. (Van backup-om ezekről egyébként, offline, gépen kívül).

Apropó, álljunk meg egy szóra: NAS-ban megfigyelésre szánt WD Purple, mert "az is bírja a 7/24-et"? Felejtsétek el. Legalábbis ZFS nélkül, de amúgy is. A Seagate NAS vinyók firmware-e CRC hibadetektálást is alkalmaz (akárcsak a WD RED-eké), ergo, ha nem ZFS-en vagyok, alacsony szinten akkor sem érint engem egy bit flip, de ennek low-levelsége miatt mégis ZFS-ezek azért + ugye a ZFS nem csak fájlrendszer, hanem egy logikai kötetkezelő is, tehát a flexibilitás... A WD Purple firmware nem tartalmaz CRC-t, ellenőrzőt: ott, ha bit flip történik a HDD-n, azt szó nélkül felolvassa és mi mit sem tudunk az adat integritásáról. Ennek oka van, felhasználásban: egy megfigyelő rendszerekbe tett HDD éjjel-nappal ír. Ha egy szektort fizikai hiba, fejpozicionálási pontatlanság, bármi egyéb miatt nem tud írni vagy olvasni, mennie kell az írással tovább, a hibát figyelmen kívül hagyva. Nem állhat le maszatolni percekre, mint egy integritás-prioritású NAS HDD, hogy ajjaj, ott mintha valami nem lenne kerek, hanem írnia kell ész nélkül, megállás nélkül, amikor több kamera képe is nonstop csorog be rá. Ha bármikor kell visszajátszáskor a felvétel és abban Purple esetén hiba van itt-ott, max. kap egy kis kockásodást a videó, vagy ilyesmi, lehet észre sem vesszük, de nem áll meg az élet. Tehát megfigyelő rendszerekben Purple jellegű vinyót kell használni (NAS HDD-t semmiképp), és fordítva: hobbi vagy komolyabb NAS-ban Purple-t: vagy csakis ZFS jellegű integritás ellenőrző fájlrendszerrel, vagy egyáltalán ne. Volt pár korrekcióm CKSUM oszlopban már egy Purple-ös mirroron, mind a Purple oldalán, pedig 100/100 és 0 tartalékszektor-áthelyezett vinyó SMART és HD Sentinel alapján. Erre jó ügyelni. A bit flipet okozhatja a kozmikus sugárzástól kezdve gyenge táp, áramhálózatban valami pici anomália, nem tudom, ilyen mélyen nem értek az alaplap elektronikájához (más sem szerintem), mindenesetre nem gyakori jelenség, de mint ilyen, létezik.

Elrettentő: így ne csináld!!!

Lássuk, hogyan NE csináld, ha Te fogsz hasonló online titkosítós konverziókba.
Elrettentő példa, bár én eddig jól megúsztam, köszönhetően a ZFS kreativitásának.

RAIDZ1:
- 3 x 8 TB Seagate NAS HDD (Ironwolf)

Megjegyzés: korábban a mirroron azért választottam két külön márkájú HDD-t, hogy ha van szórás köztük, vagy szériahiba, rejtett hiba, akármi az egyiken, akkor az ne két ugyanolyan "mindjárt megdöglő" diszket érintsen. Ez a diverzifikálás ajánlott ZFS és hagyományos RAID-ben is, ha a meghajtók fizikai és főleg logikai paraméterei nagyjából egyeznek. (Itt ez a helyzet, 4K advanced format mindkettő, cache méret, sebesség, minden ugyanolyan és bájtra pontosan akkorák méretben is logikailag, tehát kiváló ilyen célra, de ha egyikük picit kisebb lenne a másiknál, a kicsi méretet használná duplán a ZFS).

Nos, innentől úgy gondoltam, okos vagyok, belevágtam. :)

Teendő: RAIDZ1 pool alól kivenni egy HDD-t, titkosítani, majd visszaadni alá a titkosított kötetet a /dev/mapper-ből, és várni, míg befejezi a resilver-t.

- zpool remove nem működött top level vdev akármi miatt (erről nem szeretnék külön fejezetet nyitni), a lényeg, hogy offline-ba kellett tennem a kiszemelt diszket (ekkor nem ír rá és nem olvas, szigorúan érintetlenül hagyja)
- cryptsetup luksFormat-tal létrehoztam rá titkosított kötetet (--sector-size=4096 AF miatt), header fájlt ilyenkor generál, előtte pedig csináltam neki egy 4096 bájtos key fájlt, ezzel a kulccsal titkosította le a diszket
- ilyenkor még nem írja végig a fizikai lemezt random adattal a rendszer, így tehát köv. lépés:
- cryptsetup Luksopen-nel megnyitni, /dev/mapper-ben megjelent a feloldott titkosított réteg, és ezt dd-vel nullákkal teleírtam, hogy az alatta lévő fizikai meghajtón a LUKS így az egészet csurig írja random adattal
- kapcsolók: --header fájlnév.bin illetve --key-file fájlnév.bin, így a LUKS fejléc (16 MB) és kulcs (4096 bájt) az SSD-n a /root-ban tárolva jelenleg, magyarul a HDD csak és kizárólag avatatlan szem számára ismeretlen random adattal van tele, csurig.
- miután végigment éjjel a virtuális feloldott "lemez" nullával teleírása:
- zpool replace poolnév régidiszk újdiszk
- itt poolnév a pool-om neve, régi diszk /dev/disk/by-id/... (wwn alapján megyek teljes diszk használatakor), új diszk pedig ugyanennek a titkosított-feloldott /dev/mapper -es megfelelője

Mindig kivettem egy diszket offline-ba és cryptsetup inicializálás + /dev/mapper eszköz megnyitás után replace-szel visszaadtam azt a poolnak... igen, a ZFS tud offline eszközt replace-elni, nem igazán esett le neki, hogy amúgy ugyanazt a fizikai eszközt kapja vissza, csak került közbe egy LUKS2-es titkosítás is ... szóval így 3x kockáztattam a teljes pool életét (hiszen csak 1 hibát visel el, és én ezt létre is hoztam neki, még egy nem fért volna bele). RAIDZ2 (RAID6) felállás esetén már simább liba a művelet, én most merész voltam, Ti ne legyetek :)

Az újra ép és ONLINE poolon ezután ugyanezt eljátszottam a többiekkel: mindig a következő vinyót tettem offline-ba, titkosítás, teleírás, majd az így előállt mapper eszközt visszaadtam a poolnak replace-szel.

Azért vannak meglepik, nálam egyből jött is (ezt még a 2-diszkes mirroromon mutatom, egy Seagate és egy WD Purple):

pool: zfsmirror
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Sun Nov 22 07:54:51 2020
2,08T scanned at 248M/s, 748G issued at 87,2M/s, 2,60T total
750G resilvered, 28,15% done, 0 days 06:13:55 to go
config:

NAME STATE READ WRITE CKSUM
zfsmirror DEGRADED 0 0 0
mirror-0 DEGRADED 2 0 0
replacing-0 DEGRADED 18 0 0
ata-ST4000VN000-1H4168_Z301T3M2 OFFLINE 0 0 0
z301t3m2 ONLINE 0 0 18 (resilvering)
wcc4e5ns38e5 DEGRADED 4 0 16 too many errors

errors: 1 data errors, use '-v' for a list

Bizony-bizony. A jó kis WD40PURX és annak 100/100-as mivolta ellenére egy kis bithiba "valahol". Tehát most minden létfontosságú adatom épp ezerrel másolódik vissza a Seagate NAS vinyóra, ők vannak így mirrorban, miközben történt egy kis korrigálhatatlan hiba - hiszen ez most még csak 1-lábú mirror, hibát észlelni tud, de javítani már nem.

Hozzáteszem, megdöglött a tápom ezt követően pár napra rá, de SATA kábeltörésem is volt :D, úgyhogy 99.99% nem a HDD, pláne, hogy Sentinel ultra makura jelentette + írás-olvasás surface teszt, fullfull jó.

-v-vel kérve le a státuszt, megmondta, mi a bibi. Lássuk így a kimenetet.

state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Sun Nov 22 07:54:51 2020
2,08T scanned at 240M/s, 778G issued at 87,7M/s, 2,60T total
780G resilvered, 29,28% done, 0 days 06:06:00 to go
config:

NAME STATE READ WRITE CKSUM
zfsmirror DEGRADED 0 0 0
mirror-0 DEGRADED 2 0 0
replacing-0 DEGRADED 18 0 0
ata-ST4000VN000-1H4168_Z301T3M2 OFFLINE 0 0 0
z301t3m2 ONLINE 0 0 18 (resilvering)
wcc4e5ns38e5 DEGRADED 4 0 16 too many errors

errors: Permanent errors have been detected in the following files:

/mnt/zfsmirror/.../DCIM/Camera/VID_20181108_180151.mp4

Nos, ott az érintett fájl, ami resilver végén hibás lesz 1 vagy több ponton. Mint fájl, ott lesz, létezni fog, a ZFS szépsége, hogy ettől még elérhető marad a motyó, csak ... az van benne, amit beolvasott. Bumm. Majd látjuk, mi maradt belőle. Hálaistennek ez egyrészt video, tehát megúszhatom pár képkocka kimaradással, 1 pici kockásodással, majd ránézek.. másrészt bár a mirroron van, tudok nélküle élni + backup van kint polcon, ez pont családi videó.

Nem győzöm hangsúlyozni a cold backup meglétét az életveszélyesen fontos adatokról :)

Így csináld - ha ugyanilyen dolgokon agyalsz

Ha hasonlón agyalsz, hogy LUKS-al titkosítanál, és rajta ZFS, ahogy rengetegen is csinálják a világban amúgy, és működik... pár tipp, trükk, infó:

- LUKS2-zz titkosításkor (cryptsetup luksFormat --type luks2 ...)

- a fizikai szektorméretekkel egyező sector size-ot adj meg titkosításkor (cryptsetup luksFormat ... --sector-size ... ), és ez lehet 512 vagy 4096, utóbbi advanced format esetén

- zpool-t ha kreálsz, 512 sector méretű lemezen, bár auto-detektál a ZFS, ashift=9 paramétert érdemes kézzel beadni neki, advanced format meghajtó esetén ashift=12 -t (kettő a tizenkettediken).

- mirror vs. RAIDZ1: meglévő RAIDZ1 pool elemeit nem tudod mirrorhoz hasonló módon +1 HDD-vel ideiglenesen ellátni, míg egyet offline-olsz titkosítás célból. A HDD offline-ra tevésével, kivételével rizikót vállalsz RAIDZ1-gyel, hogy resilver alatt valami nem lesz kerek a nonstop olvasós, nagyobb igénybevétel miatt. Ha van 4 diszked és kicsit is fontosabb Neked az ezekre tett adat, mint nekem e példában, akkor RAIDZ2-zz!!! (RAID6 ekvivalens). Ez 2 diszk bukását is megengedi, persze 2 diszknyi kapacitást is buksz. Opció még 4 lemez esetén RAIDZ2 helyett a RAID10-ekvivalens setup, tehát eszközök mirrorba, és ők utána stripe-ba, a mirrorokat pedig ideiglenesen fel "illene" bővíteni 3-diszkesekre, míg a két eredeti HDD-iket titkosítod és resilver-ek lemennek.

- érdemes a LUKS header (fejléc) nélkül titkosítani minden HDD-t, a headert pedig külön tárolni + dupla (szintén kódolt) backup róluk valami félbiztonságos helyen, különben örökre is bukhatod az adataidat, ha Te magad sem férsz később hozzájuk. Én egy hosszú-bonyi, de régóta betéve tudott jelszavammal védett 7z archívba tettem a key és header fájlokat és a Protonmail rendszerében email-ben mellékletként elküldtem magamnak. :) Aki nem ismeri, járjon utána, mit tud. Svájc, CERN-ből lepattant privacy-központú cég, én nem egy Snowden vagyok, így nekem ez már nagyon jó (jobb, mint egy Gmail). Most már van ProtonDrive is, hasonlóan agyontitkosítva náluk minden...

- a cryptsetup luksOpen parancsnál, amikor feloldasz egy titkosított kötetet, a ZFS miatt érdemes konzisztensen mindig ugyanazt a /dev/mapper-be kerülő nevet használni. Esetemben a HDD-k szériaszámának utolsó blokkját használtam erre, kisbetűkkel, ez látszik a lentebbi kimeneten is. Így, ha egyszer egy OS-összeomlás, vagy bármi egyéb miatt akár live Linux-ból, akár egy újabb Linuxból szeretnéd a poolt importálni a feloldott diszkekkel, tudni fogod, hogy "annak idején" mi is volt a mapper device neve (amit a ZFS mint eszköznevet tárol el). Ez csak hasznos dolog, nem kötelező, de így van "rend" később is szerintem, és egyszerűsíti az életet.

Jó-jó, de mi van Linux újratelepítésnél?

Linux újratelepítés esetén, ahogy ma is tettem, a teendők:

1. alap rendszer telepítés, /boot egy titkosítatlan partícióra, root már titkosítva (legalábbis Debian Testing esetén). Testinget használok, mert az előző rendszerem is az volt, és "sajnos" felfrissítettem a ZFS poolom verzióját a legújabbra, a Linux Mint pedig ugatott, hogy ő a 2-es ZFS-t nem ismeri, hiba itt-ott-amott a poolban, persze, ő még csak 0.8.3-nál jár, vagy hol (Ubuntu LTS alapú). Talán a Mint Edge, mint legfrissebb 'rolling' verzió... de maradok Debian Testingen.

2. Titkosított HDD-k feloldása először. Nézzük, mink van, header és key fájlokat már leszedtem a Protonmail-ről, és a fájlokat korlátoztam, hogy csak a root férjen hozzájuk. Egy /root/luks2/zfsraidz1 könyvtárba tettem a fájlokat.

Fájlok listázása, hogy terminál képernyőn legyenek nekem a wwn számok, annak idején titkosításkor wwn mentén neveztem el a fájlokat, így egyértelműen azonosíthatom később, melyik HDD-hez melyik key és header fájl tartozik.

root@desktop:~/luks2/zfsraidz1# ls -la
total 49172
drwx------ 2 root root 4096 Jun 18 20:22 .
drwx------ 4 root root 4096 Jun 18 20:13 ..
-rw------- 1 root root 16777216 Mar 21 2021 header_0x5000c500c4026a8f.bin
-rw------- 1 root root 16777216 Mar 23 2021 header_0x5000c500c4029c75.bin
-rw------- 1 root root 16777216 Mar 10 2021 header_0x5000c500d50df969.bin
-rw-r--r-- 1 root root 4096 Mar 21 2021 key_0x5000c500c4026a8f.bin
-rw-r--r-- 1 root root 4096 Mar 21 2021 key_0x5000c500c4029c75.bin
-rw------- 1 root root 4096 Mar 10 2021 key_0x5000c500d50df969.bin

3. lemezek feloldása LUKS-szal, itt a parancs végére is megadom a wwn számot, így azon a néven kerülnek be /dev/mapper alá a diszkek:
root@desktop:~/luks2/zfsraidz1# cryptsetup luksOpen /dev/disk/by-id/wwn-0x5000c500c4026a8f --type=luks2 --key-file=/root/luks2/zfsraidz1/key_0x5000c500c4026a8f.bin --header=/root/luks2/zfsraidz1/header_0x5000c500c4026a8f.bin 0x5000c500c4026a8f
root@desktop:~/luks2/zfsraidz1# cryptsetup luksOpen /dev/disk/by-id/wwn-0x5000c500c4029c75 --type=luks2 --key-file=/root/luks2/zfsraidz1/key_0x5000c500c4029c75.bin --header=/root/luks2/zfsraidz1/header_0x5000c500c4029c75.bin 0x5000c500c4029c75
root@desktop:~/luks2/zfsraidz1# cryptsetup luksOpen /dev/disk/by-id/wwn-0x5000c500d50df969 --type=luks2 --key-file=/root/luks2/zfsraidz1/key_0x5000c500d50df969.bin --header=/root/luks2/zfsraidz1/header_0x5000c500d50df969.bin 0x5000c500d50df969

A tab-ot a számok végén egy karaktert visszatörölve érdemes nyomogatni, hogy meggyőződjetek arról, jól írjátok-e, bár vágólapra téve fentebbről őket nincs hiba, azért, ha nem az elvárt viselkedést hozná (pl. nem egészítené ki a .bin-nel a fájl nevét), gyanakodnék, hogy valamit benéztem. Ez csak praktikum.

4. ZFS telepítése:
sudo apt install zfs-dkms zfs-zed zfsutils-linux

Nézzünk egy zpool status-t, most, hogy feloldva a diszkek. Nem a pool miatt, hanem hogy van-e egyáltalán ZFS-ünk a telepítést követően :)

root@desktop:~/luks2/zfsraidz1# zpool status
no pools available

Biztonsági ellenőrzés: megvan mindhárom feloldott HDD a /dev/mapper-ben? Igen, ott vannak.
root@desktop:~/luks2/zfsraidz1# ls -la /dev/mapper
total 0
drwxr-xr-x 2 root root 160 Jun 18 20:29 .
drwxr-xr-x 19 root root 3800 Jun 18 20:29 ..
lrwxrwxrwx 1 root root 7 Jun 18 20:27 0x5000c500c4026a8f -> ../dm-2
lrwxrwxrwx 1 root root 7 Jun 18 20:28 0x5000c500c4029c75 -> ../dm-3
lrwxrwxrwx 1 root root 7 Jun 18 20:29 0x5000c500d50df969 -> ../dm-4
crw------- 1 root root 10, 236 Jun 18 19:31 control
lrwxrwxrwx 1 root root 7 Jun 18 20:24 sam870evo1t -> ../dm-1
lrwxrwxrwx 1 root root 7 Jun 18 19:31 sdb1_crypt -> ../dm-0

4. Pool felismerhetőségének, importálhatóságának ellenőrzése (ez még nem végzi el, csak csekkol egyet):

root@desktop:~/luks2/zfsraidz1# zpool import
pool: zfsraidz1
id: 684849134314292699
state: ONLINE
status: The pool was last accessed by another system.
action: The pool can be imported using its name or numeric identifier and
the '-f' flag.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-EY
config:

zfsraidz1 ONLINE
raidz1-0 ONLINE
0x5000c500c4026a8f ONLINE
0x5000c500c4029c75 ONLINE
0x5000c500d50df969 ONLINE

5. Pool importálása akkor hát, hiszen minden oké. (Az export megtörtént, mikor az előző OS-sel a gépet lelőttem-újraindítottam, a -f kell és biztonságos is, nem fog a régi OS többet ehhez a poolhoz nyúlni, hisz legyaktam, így ezzel most már a mostani OS-é úgymond a pool szőröstül-bőröstül).

root@desktop:~/luks2/zfsraidz1# zpool import zfsraidz1 -f
cannot share 'zfsraidz1: system error': SMB share creation failed
root@desktop:~/luks2/zfsraidz1# zpool status -v
pool: zfsraidz1
state: ONLINE
scan: scrub repaired 0B in 1 days 08:38:02 with 0 errors on Tue Jun 7 22:47:53 2022
config:

NAME STATE READ WRITE CKSUM
zfsraidz1 ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
0x5000c500c4026a8f ONLINE 0 0 0
0x5000c500c4029c75 ONLINE 0 0 0
0x5000c500d50df969 ONLINE 0 0 0

errors: No known data errors

Itt volt egy kis nyafi, hogy SMB share-elni még nem tud, hát ja, még nincs fent SAMBA és az előző konfigban azzal együtt használtam a poolt, a metaadatokból itt is ezt tenné... majd alámocskolom egyszer, most nem kell.

A lényeg, hogy megvan a poolom, épen, egészségesen, 2-es verziós ZFS Linux-on és minden feature támogatva, minden ép.

LUKS kötetek boot alatti automatikus feloldása

Elérkeztem ahhoz a ponthoz, hogy lehetővé tegyem a header és key fájlok segítségével a titkosított lemezek feloldását boot legelején. A felállás a következő:

1. A gépen Windows van SSD-re telepítve, első partíció, és onnan is indul.

2. A Linux /boot-ja USB stick-en van titkosítás nélkül, egy plusz EFI partícióval, így ha az USB be van dugva a gép elejébe, a Debian bootol

3. jelszóval a / -t feloldaná (ami az SSD-n egy titkosított kötet, itt értelemszerűen key és header fájl mókolás nincs, a feloldókulcs a kézzel bepötyögött kód)

4. Debian indul, és hát ilyenkor fel kéne oldania a 3 db HDD-t, hogy azok titkosítatlan logikai rétegei megjelenjenek /dev/mapper-ben és ahogy a boot folyamat egyik következő lépésében a ZFS alrendszer is öntudatára ébred, már keresse is /dev/mapper-ben a 3 lemeznek megfelelő "diszket", hogy mountolja a poolt nekem a megfelelő könyvtárba.

Ez az automatikus titkosítás-feloldás az /etc/crypttab -ban történik, ez most szűz verzióban, / (gyökér) partíció titkosításával így néz ki:

root@desktop:~/luks2/zfsraidz1# cat /etc/crypttab
sdb1_crypt UUID=afa71100-675d-42ee-baa1-2a2ee159bdfb none luks,discard

Tehát 1 sor van benne, aztán jónapot.

1. oszlop: a titkosított eszköz neve /dev/mapper-ben majd

2. oszlop: abszolút elérési útvonal, vagy egyéb azonosítóval hivatkozás az eszközre (itt UUID alapján, így a meghajtók esetleges cserélgetése nem köp bele a levesbe)

3. oszlop: key fájl (mivel itt "none" áll, jelszót kér be feloldáskor)

4. oszlop: titkosítás típusa és én - lévén SSD - a discard-ot is használom, modern SSD-ken már nemigen kell az auto garbage collection / wear leveling miatt, itt ez arról szól, hogy nagyon kicsi biztonság-csökkenés mellett, ami szerintem egy földi halandónak belefér, a felsőbb, /dev/mapper rétegben kiadott TRIM utasítások végigmennek át a titkosított rétegen is a fizikai diszkig. Aki hiperparanoid, ne használjon discard-ot. Azt zárójelben érdemes tudni, hogy SSD titkosítása LUKS-szal annyiban különbözik az SSD gyári (natív, beépített, UEFI-ben aktiválható) titkosításától (ebben a kontextusban) :) , hogy discard hiányában az SSD nem tudja, mely blokkok szabadok ténylegesen és melyek nem, ugyanis a LUKS kriptográfiai réteg amikor dd nullázunk egy /dev/mapper-es feloldott eszközt, full random adatokkal teleírja a partíciót vagy teljes SSD-t. LUKS mellett discard-ot kihagyva a biztonság totál maxon marad, viszont a meghajtó jobban kopik, ha így tetszik. De szerintem ez marginális és otthoni felhasználás mellett mehet a discard nyugodtan a LUKS rétegnek is (meg majd fstab-ban is).

Nos, ebbe a crypttab-ba kellene belegyömöszölnünk a mi 3 HDD-nket is, hogy a boot folyamat során automatikusan feloldódjon a 3 diszk. Így a rendszerünk lényegében egy jelszavas / (gyökér) partíciós feloldással van "csak" védve, majd ezt átgondolom, jó-e így, vagy legyen a titkosítatlan /boot-on az SSD-s gyökér partíciónak is egy random generált kulcsa és headerje. Ugyanis, ha a gépet magára hagyom, az USB sticket kihúzom, előtte /boot-ot át-mountolom a feloldott SSD-n lévő /boot-ba, ergo míg fut a gép, nincs gond (míg nem frissítek valamit, de akkor visszadugom) :D, ha pedig USB nélkül indítja bárki, a Windows jön be és az illető max. sejti, hogy az SSD-n még van valami ismeretlen cumó, de ha csak nem valami Vérpista hekker, nemigen fog tudni mit kezdeni az egésszel. Meg amúgy sem feltétlen, ez nem egészen úgy működik, mint a filmekben, bár az eNeSA-t nem kérdeztem még ilyenekről... :)

No, akkor kreáljunk 3 újabb bejegyzést a cryptab-ba a 3 új HDD automatikus feloldásához:

root@desktop:~# echo "0x5000c500c4026a8f /dev/disk/by-id/wwn-0x5000c500c4026a8f /root/luks2/zfsraidz1/key_0x5000c500c4026a8f.bin luks2,header=/root/luks2/zfsraidz1/header_0x5000c500c4026a8f.bin" >> /etc/crypttab

root@desktop:~# echo "0x5000c500c4029c75 /dev/disk/by-id/wwn-0x5000c500c4029c75 /root/luks2/zfsraidz1/key_0x5000c500c4029c75.bin luks2,header=/root/luks2/zfsraidz1/header_0x5000c500c4029c75.bin" >> /etc/crypttab

root@desktop:~# echo "0x5000c500d50df969 /dev/disk/by-id/wwn-0x5000c500d50df969 /root/luks2/zfsraidz1/key_0x5000c500d50df969.bin luks2,header=/root/luks2/zfsraidz1/header_0x5000c500d50df969.bin" >> /etc/crypttab

Ellenőrzés: bent van minden szépen:

root@desktop:~# cat /etc/crypttab
sdb1_crypt UUID=afa71100-675d-42ee-baa1-2a2ee159bdfb none luks,discard
0x5000c500c4026a8f /dev/disk/by-id/wwn-0x5000c500c4026a8f /root/luks2/zfsraidz1/key_0x5000c500c4026a8f.bin luks2,header=/root/luks2/zfsraidz1/header_0x5000c500c4026a8f.bin
0x5000c500c4029c75 /dev/disk/by-id/wwn-0x5000c500c4029c75 /root/luks2/zfsraidz1/key_0x5000c500c4029c75.bin luks2,header=/root/luks2/zfsraidz1/header_0x5000c500c4029c75.bin
0x5000c500d50df969 /dev/disk/by-id/wwn-0x5000c500d50df969 /root/luks2/zfsraidz1/key_0x5000c500d50df969.bin luks2,header=/root/luks2/zfsraidz1/header_0x5000c500d50df969.bin

Egyébként úgy tudom, sima "luks" is mehetne típusba "luks2" helyett, de nem dobott hibát, így maradt.
No, innentől már reboot.
* * * * * * * * * * * * * * * * *

Újra itt. A gép az SSD feloldása (/) után vagy 1-2 mp-ig megrecsegtette a HDD-ket, ahogy feloldotta azokat + a ZFS felvette a poolt, és voilá:

root@desktop:~# zpool status
pool: zfsraidz1
state: ONLINE
scan: scrub repaired 0B in 1 days 08:38:02 with 0 errors on Tue Jun 7 22:47:53 2022
config:

NAME STATE READ WRITE CKSUM
zfsraidz1 ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
0x5000c500c4026a8f ONLINE 0 0 0
0x5000c500c4029c75 ONLINE 0 0 0
0x5000c500d50df969 ONLINE 0 0 0

errors: No known data errors

Fstab-bal nem kell törődnünk, mivel a /dev/mapper-be feloldott diszkek (aliasain) ZFS van és annak fájlrendszerbe mountolását a ZFS alrendszer végzi, a pool felismerődik, mount megtörténik és kész.

Tehát a crypttab-ban lévő 4 sorból csak az SSD-n lévő root partíció feloldása utáni /dev/mapper-ben létrejövő eszközre kell fstab-ban auto mount-olás (nyilván), a crypttab 3 db HDD-s bejegyzésére nem.

root@desktop:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/sdb1_crypt / ext4 discard,noatime,nodiratime,usrquota,grpquota,user_xattr,errors=remount-ro 0 1
# /boot was on /dev/sdh2 during installation
UUID=1870de57-00b1-406b-8606-f8eb96753f11 /boot ext4 discard,noatime,nodiratime 0 2
# /boot/efi was on /dev/sdh1 during installation
UUID=DF82-1624 /boot/efi vfat umask=0077 0 1

A discard-ot itt is alkalmaztam fstab-ban, hiszen SSD és ultra-paranoid nem vagyok, csak kicsit.

No, most viszont USB pendrive ki, vettem egy W10-et és illene lenne feltolni az SSD másik felén lévő rá várakozó partícióra. BattleField-ek sajnos nem szeretik a Linuxot :D

Záró szavak

Igen, lehetne ezt még agyonszofisztikálni, mindig van hova tovább. Ez a perfekcionistáknak, piszkálódóknak. Ne bántsatok :) ;) De egyrészt nem is maga a cél, hogy "úristen, félünk"... vezérelt a Linuxom (és PC-m) ily módú használata irányába, hanem inkább csak az, hogy miközben egy kissé komplexebbnek mondható setupot kreálok magamnak, nyugodtan alszom (idézőjelben), ha történik valami nagyon csúnya a géppel… de az egész folyamat közben rengeteget tanultam is, éjszakákat töltve manual-ok, manpage-ek mellett, mire összehoztam ezt a most optimálisnak nevezhető setup-ot.

Mondanom sem kell, a titkosítási réteg sem a procimat nem eszi meg, pláne nem a diszk sebességet...

Amire ügyelek jelen felállásban:
- a 3 db HDD kulcsa és headerje még 2 másik fizikai (offline) tárolón is megvan, nem csak a Proton rendszerében. Sosem lehet tudni, mit hoz a jövő, elvágódunk a felhő(k)től és annyi... Illetve magán a / (gyökér) SSD partíción is, ami titkosított szintén ugye (kézi jelszavas). A kézi jelszón majd agyalok, ez lényegesen gyengébb védelem jelenleg, mint a key + header mókolás a 3 db HDD-n, valszeg kiváltom ezt is key+header-rel a /root/luks2-ből a /boot/luks2-be áttéve (tehát az USB stickre)

- az USB stick is meghibásodhat, bármi gáz lehet vele. dd-vel két másik sík ugyanolyanra (összesen 3 egyformát vettem) átmásoltam, bitről bitre copy. Nem gyakran upgrade-elek full rendszert, hogy kernelt is mókoljon az apt és /boot-ba is belenyúljon, de annyi tudatosság kell a dologhoz, hogy ha ilyen történik, akkor mindenképp manuálisan kell újra replikálni a meglévő, frissített USB sticket a két másikra. Az SSD-s gyökér partíció key és header fájlját majd felküldöm szintén ProtonDrive-ra magamnak, a többiekkel együtt ott meglesz. Ez azért is jó, mert Live Linux alól is feloldhatók így a drive-ok és végezhető bármilyen ideiglenes művelet, ha nincs rendszer telepítve, összeomlott, satöbbi.

- a most alkalmazott USB stickjeim kis pici 32G-s SanDisk Cruzer Fit-ek. Nagy, lassú, picike, ezt vettem még más célra korábban (kocsiba, autórádió USB-be) :) amit azóta eladtam, rajtam maradtak.. felhasználtam. /boot-nak pazarlás 32G, de tökmindegy, fillérekbe kerültek, amúgy tetű lassúak, de elég.

- korábban úgy akartam csinálni, hogy a gép fenekébe dugom a /boot-ot tartalmazó USB sticket, egy Kingston DataTraveler G4-et és kikötöm az asztalomhoz az USB lyuk magasságában. Ha a gépet kihúzza, észre sem veszi, hogy a pendrive kihúzódik az USB slot-ból és onnantól max. vasa van, adata az nincs. :) Aztán úgy voltam vele, egyszerűbb zsebre vágni vagy a lakásba máshova eltenni az USB kütyükét, amit elöl dugok be és tartok ott, mikor nem számítok veszélyre, amikor pedig igen, kiveszem és elteszem valahova a lakásba, olyan pici, hogy lehetetlen megtalálni, ez esetben szintén csak vasat visz a rabló.

(Nagyon paranoid vagyok? Igen. Lopták el bicajomat, 230k huss) :(

Ezt még tovább lehetne SIM kártya-alapú, PC házba épített Arduino-val és/vagy Raspberry Pi-vel szofisztikálni meg csűrni-csavarni, ahhhh, maradok a kőkorszaki módszernél, ez is overkill szerintem, de annyira nem bonyolítja az életem, hogy ne vállaljam be.

Lassan amúgy megint bővíthetem a poolt, a HDD-ket egyesével nagyobbra cserélni. Itt máris eszembe jut valami: ezt max. akkor, ha fokozatosan veszem meg a HDD-ket, nem egyszerre. Jobb ugyanis (szerintem) egyben megvenni őket, még ha fáj is a pénztárcának, egy új poolt létrehozni (akár új okosságokkal is tarkítva, kicsit még jobbra beállítva, vagy recordsize-zal játszol, bármi mással...), majd ebbe szimplán áttenni mindent a régiből. Bár a ZFS-re nem jellemző az erős fragmentáció, valamilyen szintű itt is van azért, így egy combos "defrag"-ot is letud az ember az ilyen módú átköltözéssel ahhoz képest, mint amikor egyesével cserélné ki a RAIDZ1 tagokat. A végén, ha minden oké, a régi poolra egy destroy és jöhet a gépből kiszedés. Teljes diszkes LUKS titkosítás előnye, hogy nem kell kinullázni dd-vel vagy egyéb eszközzel, bár én szoktam amúgy :D

Ha eddig eljutottál és kérdésed van, észrevételed, vagy Te máshogy csinálod, esetleg még jobb módszerek dual-boot-ra, hajrá, jöhet hsz-ben, szívesen veszem, okuljunk :)

És hogy a jövő mit hoz számomra? Nos, LSI SAS9217-8i kari be és kitömöm a gépet 2T-s SSD-kkel, esni nem fog az áruk, cserébe nem kopik, nem zümmög, a poolom ugye nem írás-intenzív, PCIe és kártya sávszélbe beleférnek bőven majd, szóval ... kíváncsi leszek. HDD-k mennek majd. Beszerzek pár SATA tápelosztót pluszba, aztán hajrá. 6 (alaplap) + 8 (LSI) SATA port az 14, ez RAIDZ2-ben (14-2)*2T = 24T tárhely, ami gyors, csendes, a ZFS pedig a Copy-on-Write stratégiájával natívan is SSD-barát, szóval ... nekem ez így tökéletes lesz egy csendes NAS-nak végre.

Az ASUS-nak pedig külön köszönet, hogy támogatja az ECC UDIMM-eken az ECC-t, és az működik is kiválóan.

Apropó, fontos: a ZFS-nek nem kell rahedli RAM, ha nem használja az ember a deduplikációt. 1G RAM-os gép úgy elviszi a 3x8T HDD-t, mint a szél. Nálam a felhasználás jellege miatt (vegyesbazár amúgy, kicsi és nagy fájlok is, sok szekvenciális-jellegű olvasás) nincs ZIL és SLOG eszköz, cache-ek, vagy bármi egyéb, a Linux kernel cache-el a szokásos módon és kész, a 3 db HDD küzd, mint disznó a jégen magában. Kiváló. Szóval tévhit, hogy falja a RAM-ot.

root@desktop:~# free -h
total used free shared buff/cache available
Mem: 31Gi 2.5Gi 27Gi 61Mi 1.5Gi 28Gi
Swap: 0B 0B 0B

(Fullos rendszer, Cinnamon, 2 böngésző, Tidal, Netflix, rahedli oldal nyitva...)

Legvégül: biztos csípi 1-2 emberke szemét, hogy nem sudo-ztam, hanem végig root-ból toltam. Amikor lusta vagyok, akkor így megyek be (asztali gép, nem ssh), ez van. :)

Remélem, azért valaki tudott okulni az én hibáimból.

És igen, a ZFS-re magára így explicit nem tértem ki, se snapshot-ok, se paraméter-hegyek, se egyéb... nem ez volt a cél most.