Beleolvastam, nem mindet olvastam el, de gratulálok, na az ilyen cikkek eléggé hiányoznak már innen, amikor tényleg kidolgozod a cikk témáját.
Az pedig, hogy nem mentél bele a ZFS-be annyira, nem is baj azzal legalább kettő ilyen cikket ki lehetne tölteni, csak azzal hogyan működik.
Mindenesetre, szuper, el fogom olvasni, köszi a munkádat.
hozzászólások
hallador
(addikt)
Krugszvele
(aktív tag)
7zip archív helyett esetleg egy veracrypt kötetbe tenni a titkosított headert?
pro-kontra? A 7zip-re nincsen már valami törés, vagy backdoor?
Köszi, örülök, hogy tetszett. Ez csak 1 út a sokból, kinél hogy néz ki a rendszer ugye, lehet ezt tényleg még jobban tekergetni, de nagyjából így kerek.
Ma még mindig ott tartok, hogy 24 karakteres kézi jelszóval oldom fel az USB pendrive boot-ját Grub után, mikor bootol a linux, ez feloldja az SSD-n lévő LUKS titkosított gyökét partíciót, folytatódik a boot folyamat, feloldódik a 3 HDD és él a rendszer.
Múlt héten scrub-oltam (sacc. kéthavonta scrub-olok egyet), szokásos 0 error.
Teszi a dolgát a konfig, én pedig nyugodtabban alszom.
Nemsokára költözök végre jobb környékre, de ez már így marad
Lehet van rá törés, nem is tudom.. a semminél több.
Veracrypt jogos, sőt.. régen a Truecrypt-el játszottam el hasonlót, Windows alatt anno. A cégből mentett adataim mai napig TC konténerben, Veracrypt feloldja persze. Jó ötlet.
Amúgy ha tényleg így betörő/lopás ellen akarom védeni a motyót (adatokat), igen pici az esélye, hogy az email fiókom akarná header fájlokért törni, úgy, hogy ez kis túlzással szinte lehetetlen egy security-heavy cégnél és termékeinél, ahol az adatokhoz még ők sem férnek hozzá (és én ezt elhiszem nekik. Nekik igen)... szóval akár kódolatlan zipben is lehetne a header és key fájl, ha most azt nézzük, mi ellen csináljuk meg ezt a kicsit nyakatekert, de annyira nem is vészes setup-ot.
Amúgy nagyon poén, amikor a pendrive-ot kihúzom, minden előjel nélkül bootol SSD-ről Windows-ba (Starcraft-ozok jókat néha), nyitom a lemezkezelőt és azonnal dobja fel, mindhárom HDD-mre, hogy ezeken semmi nincs, de még partíciós tábla sem, kreáljon-e.
Na ilyenkor kell vigyázni és - nyilván - ezt elutasítani.
Szóval aki ezt a gépet vitte, vasnak, az anyagilag egész jól jár, de amúgy jó eséllyel arra sem jön rá, hogy a 3 diszk adott esetben értelmes adattal szinte tele, nemhogy nekiálljon küzdeni vele, kb. Mission Impossible. A védelem legelső frontvonala maga a megtévesztés.
Lehetne fokozni hogy USB-be dugható M.2 SSD-t használok boot mellett gyökérre is, na akkor végképp nem rakná össze egy avatatlan szem a dolgot, hogy értelmes adat lehet egyáltalán a 3 diszken. Lát egy legális Windows-t, 1-2 legális játékot és 3db "üres" HDD-t.
Következő irományom elosztott fájlrendszer lesz, Gluster (zfs-el kombinálva).
Ez parádés !
Össze kellett kaparni, mire mindent felhomályosítottam magamban....
"Mindent"
szrk:
mint valami ördöglakat
[ Szerkesztve ]
ledgeri
(nagyúr)
Nézz utána, de ha leveszed windowson belül a betüjelét a lemezeknek, amiket neki nem kéne látnia, akkor nem fog pop-up-olni, hogy nincs semmi számára érthető rajtuk
[ Szerkesztve ]
Nem sokat nyitom már meg a lemezkezelőt, de köszi a tippet. Ha ismét.. rápróbálok.
Hát figy, működik. ZFS-nél szokták mondani, hogy direktben kell neki odaadni a drive-ot, hogy "lássa" annak paramétereit, talán még SMART-ot is, nem tudom.. passz. Erről nem szoktam leállni vitázni másokkal.
Én azt tudom, hogy megoszlik a szakma véleménye, stackoverflow-tól kezdve mindenhol csak azt látom, hogy rengetegen évek óta simán ráteszik teljes lemeztitkosítás esetén a LUKS által kreált virtuális rétegre a ZFS-t és azt tekinti VDEV-nek. Szerintem zseniális. Ha bit flip történne fizikailag legalsó rétegben, az beolvasáskor szar LUKS szektort eredményezne, a szar LUKS szektor pedig lényegében egy "bad sector"-ként jelentkezik a /dev/mapper-ben lévő feloldott virtuális eszközön, azt meg lekezeli ZFS, mert ráírja a jó adatot (ha tudja, mert nem súlyos fizikai hiba), ez a jó adat pedig ugyanígy a jó titkosított kóddal, jó szektorként újra kiíródik lentebb, így a fizikai rétegre ráíródik ugyanaz az értelmetlen random adat, ami eredetileg is ott volt, csak flippelődött egy bit. Nem nagy kunszt, tehát még a self-healing is működik, titkosítás mellett is, mindaddig, míg a másik meghajtó pöpec és az ott lévő adat + 2 db checksum alapján el tudja dönteni, melyik adat ténylegesen a jó. 2- vagy többtagú mirror, raidz1, raidz2, raidz3 esetén is ez a jótékony tulajdonság adott.
A RAW fájljaim már amúgy nem tudom, hanyadjára költöznek , elsőként 0.x-es alapverzióként kezdte mindenem 3db 2T-s WD Green-en.
( )
Aztán mikor elhullott egy, meg mégegy (később), letettem erről, a green sem ajánlott NAS célra, meg a nonstop fejparkoltatás anno, ahh, itt volt 1-2 nyűg ezekkel. Ezután jöttek a 4T-s Seagate NAS-ok + WD Purple + WD Red, 6 diszk összesen, végül - most is ezeken élek - 3x 8T Seagate Ironwolf (NAS). Mindig úgy bővítettem a poolt diszkenként, hogy betettem az új HDD-t, LUKS-al belőttem, majd az így /dev/mapper -ben létrejött eszközt adtam be neki, a régi HDD-t "replace"-elve. Mikor a 3. HDD cseréje is lement, az autoexpand=on miatt a pool méretem automatikusan felugrott a bővített méretre.
Ha lenne pincém, ahol nem zavar a kicsit nagyobb géphang, valószínűleg kreálnék raizd2 típusú pool-t úgy 6-8 db HDD-vel aztán jónapot. A sebesség nem téma.
Cache, SLOG továbbra sincs, minek. Csak a szinkron írásokat gyorsítja, média tartalomra felesleges - nekem legalábbis, adatbázist pedig nem futtatok, VM-eket sem, a pool-on..
[ Szerkesztve ]
Carasc0
(őstag)
Több helyen nagyon tudálékos és nagyképűen (leginkább önteteltséget sugárzó) megfogalmazott leírás. A világmegváltó tudatzavarral bíró tinik fogalmaznak így. Ha nagyon fiatal vagy elnézhető. Vagy ha szakmailag elismertséget szerzett nagy ember vagy elnézhető.
De így nem lehet elismerni semmilyen szakmai tudást. Bocs.
[ Szerkesztve ]
Nézd, a stílus maga az ember, de egy szakmai cikket lehet olvasni hasznos és haszontalan módon is...
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.
Meglehetősen. A kutyát nem fogja érdekelni a lakásod
Gratulálok.
Esetleg annyi javaslat, hogy a beütött parancsokat emeld ki új bekezdésbe monospace vagy programkóddal, hogy jobban kiemelkedjenek.
"- LUKS2-zz titkosításkor (cryptsetup luksFormat --type luks2 ...)"
Helyett:
- LUKS2-zz titkosításkor:$ cryptsetup luksFormat --type luks2 /dev/ESZKÖZ
A zpool remove raidz esetén nem működik, valamint csak top level vdev-et lehet eltávolítani: van egy 2x2 mirror pool-od és az egyik mirror vdev-et ki akarod venni. Ekkor az azon lévő adatokat átírja a bennmaradó mirror-re és egy mappingot hoz létre a régi adathely és az új adathely között. Egy ilyen furcsa állapotban lesz a pool, de ahogy az adatok frissülnek úgy a mapping tábla mérete is szép lassan a 0 felé fog tartani.
Es a cikk ala odakopsz egy olyan kommentet ami tokeletesen megfelel a leirasodnak, vegtelenul arrogans okoskodas
[ Szerkesztve ]
Köszi !
Azóta annyi változott, hogy átmigrálódtam 4x14T Seagate Exos SAS vinyóra (raidz1 továbbra is, lehet bővítek +2 diszkkel és akkor raidz2, csak hova teszem ezt a millió adatot, még fejvakarós, bár csak fele van még tele), .. jött egy alkalmi vétel. Alapvetően továbbra is favorit a motyó, 400-550 Mb/sec körül írogat-olvasgat kevés seek mellett, mikor milyenje van, bőven kielégítő nekem.
Samba-val volt kissé nyűg összehozni, sőt, nagyon nagy nyűg.. de ha jól emlékszem, az lett a megoldás, hogy a Linux saját SMB stack-jét használtam és a pool-on zfs-en pedig offoltam.
Linuxon a saját sambát kell használni.
A trükk, amit keresel, hogy 2 új lemezt raid0-ba rakod. Arra felmásolsz mindent (zfs send | zfs recv), és bízol benne, hogy a scrub nem dob hibát. A felszabaduló 4 lemezből csinálsz egy raidz2-t, de úgy hogy még két 13T méretűre allokált fájlt hozzáadsz. Itt nincs foglalás, Amikor létrejön, akkor azonnal offline-ba rakod a két fájlt, hogy ne kezdjen rá írni. Visszamásolsz mindent, majd a 2 fájlt kicseréled a raid0 lemezeire.
Legalább 2 helyen lehet adatveszés, de ez az egy lehetőség van ha nincs több lemezed.
Igen, ez necces menet lesz. Kösz a tippet, vad dolog, de kivitelezhetô. Még alszom rá egyet. Ha bukik a dolog, nagy a rizikó. Esetleg vmi kölcsön diszk vagy nem tudom, majd kifaggatom cimbiket.
Említetted h Linuxon ?
Mi a másik még ? BSD ? Mert látom, Windows-ra is megy a portolás, de arról semmi infóm igazából, lehet be van késve rendesen..
FreeBSD-re működik a zfsből a samba. Windows nincs még kész, ne is várj rá. Hamarabb lesz mac-re.
No, még mindig jó a pool, de a minap berágtam a Samba-ra és a nyögvenyelôs auth-ra, NFS v4-el osztottam az Android tv-nek a Kodi alá a motyót, végre 1 portot elég nyitni ehhez szerver oldalon (azaz nem is tudtam, hogy a jó ideje kint lévô v4 már tudja ezt) + overhead sincs annyi, mint Samba esetén.
Ott pusztuljon meg a Samba és a Microsoft, ahol tud.
Illetve szeretném ezt a 4 diszkes pool-t kicsit szofisztikálni majd, alátenni 2-3 SSD-t, caching, log, nem is tudom, mivel lenne érdemes kiterjeszteni úgy, hogy
1. az is konzisztens legyen, ha kell (tehát mirror)
2. a pool az adatokat a 4 HDD-vel is megôrizze, ha az összes SSD-t leveszem róla, úgy is.
3. Gyorsuljon (nyilván), nem feltétlen szekvenciálisban, hanem sok kb. 50-100 megás fájl ráírása-visszaolvasása esetén. (Fényképezôgép raw-k, írja az Explorer, olvassa az Adobe Bridge az elônézetikhez, de lehet maradok 4 HDD-vel így nyersben és a teljes képkidolgozási folyamatot abszolválom elôtte az SSD-ken, aztán ha már nem molyolok velük, áttolom a NAS-ra).
3.1 Könyvtárbeolvasás. Minden start/reboot után ha belépek a fotós mappámba, tele könyvtárakkal, úgy recseg és tölt az egész, hogy pislogok.. eltelik 2-4 hosszú mp, mire felnyalja az alkönyvtárakat és mutatja ôket az Intézô. Utána már villám (RAM cache).
Egy elképzelésem már van fejben, még finomodik..
[ Szerkesztve ]