2011. június 20., hétfő

Linux - "Full" disk encryption

Úgy esett, hogy a hétvégémet rászántam, hogy a Thinkpadomon lévő Ubuntu alapú rendszert átpatkoljam, hogy a rajta lévő összes adat encrypted legyen (éljen a security).. Hát.. Valahogy nem úgy ment, ahogy vártam :)

A terv a következő volt:
- LiveUSB alól készítek egy backupot a futó rendszeremről
- Alternate install bebootol, majd az alól újrahúzom a rendszerem immár Encrypted LVM-el (LUKS), majd az LVM-en belül létrehozom az LV-ket, amiket meg aztán mountolgatok a megfelelő pontokra
- Backupból visszahozok minden fontosabb adatot, illetve az összes telepített programomat is, ha már ott tartok
- Profit..

Csak hát Murphy (plusz az én felkészületlenségem is részben) nem így gondolta.. nézzük mi is történt a valóságban.

- Backup:
A kiszemelt 40 GB-os USB-s vinyó (amit a backup céljára kiszemeltem) sajna csak 1 USB csatlakozóval rendelkezett, a hozzá illő tápcsatalakozót nem mellékelték. Ettől függetlenül persze a gép szépen látta az eszközt, sőt írni is hajlandó volt rá.. A probléma onnan indult, amikor random időközönként leszakadozott, így téve lehetetlenné, hogy backupot csinálhassak rá. Ez azért is volt problémás, mert hogy a közelben már csak egy gép volt, az is Windows.. Sebaj mondom, csinálok egy SMB megosztást, oda meg áttolok mindent.. Persze ahhoz, hogy a file attribútumokat megtartsam ezt úgy tudtam csak levezényelni, hogy mindent egy tar-ba toltam bele.. Így lett a végén egy közel 37 GB-os tar file-om.. De legalább volt backup.. De persze úgy voltam vele, hogy 1 backup nem backup (főleg nem ha tar), így biztosra mentem, és csináltam egy teljes dd mentést is a diszkről, ami szintén a Win-es gépen foglalt helyet a művelet végeztével. Így már úgy éreztem, hogy bármi történjék, nem lehet baj (max visszahúzok mindent bitre pontosan ahogy volt a dd backupból)

- Telepítés
Mivel a rendszer ubuntu alapú, így az elképzelésem a következő volt: leszedem az alternate install-t (a grafikus telepítő nem támogat se LUKS-ot, se LVM-et), majd azzal megcsinálom. Tekintve, hogy a művelet végén amúgy is vissza akarok pakolni minden applikációt ami eredetileg fent volt, így lényegében csak az alapok érdekeltek. Így hát fogtam magam, leszedtem az alternate telepítőt, majd unetbootin-al felpakoltam USB-re (optikai lemezt már jó ideje nem szeretek ilyenre használni). Az első probléma ott volt, amikor a rendszer jelezte, hogy nem találja a CD meghajtót.. Néztem is nagyokat, hogy akkor most wattafák..
A problémára az első talált megoldás az lett, hogy a pendrive-on lévő Lucid mappát át kell nevezni stable-re (ami amúgy egy symlink lenne, csak persze FAT32-őn ez így nem megy), az majd megoldja a problémát. Szóval át TTY2-re, átnevez, "CD" újrainicializálás, és ment tovább.. Éljen..
A következő dilemma ott jött amikor particionálni kellett a rendszert.. A régi partíciós kiosztásom a régebbi migrálások miatt amúgy is elég kusza volt, így úgy gondoltam, hogy most már kicsit rendszerezünk is. Először viszont el kellett döntsem milyen filerendszert használjak az LVM miatt..

Szivem szerint Reiser4-et raktam volna majdnem mindenhova, de az sajna nem része a telepítőnek (ahogy a Brtfs és a ZFS se), így az alábbi lehetőségeim maradtak
- A 10.4es Lucid alatt támogatott modern filerendszerek, amelyeket növelni is lehet az alábbiak:
- ext4 - ezt személy szerint kerülöm, mint a rossz pénzt - az egyetlen filerendszer, amely fsck-ja képes a teljes FS-t a lost+found alá száműzni
- XFS - Ezt sajna csak növelni lehet (azt legalább online), csökkenteni nem
- ReiserFS - Lehet növelni, és csökkenteni is (ezt sajna csak offline), viszont a tapasztalatok alapján XFS jobban teljesít notebook-on.

Mivel az XFS-el vagyok a legjobban megelégedve, így úgy gondoltam, hogy ahol lehet (és nem számítok FS csökkentésre) úgy ott azt használom, máshol marad a Reiser.. Ergo az az alábbi stratégiával álltam elő:
/dev/sda1 - /boot (ext2) - 120 MB ( Ugye a GRUB 2 se tud encryptált kötetről bootolni, szal a /boot kénytelen a LUKS-on kívül lenni)
/dev/sda2 - Encrypted Volume (LUKS)
Az encrypted Volume-on belül pedig fogtam magam, és létrehoztam egy LVM-et, azon belül egy rootvg nevű VG-t, alatta pedig az alábbi LV-ket:
- datalv - /data (ReiserFS) - 20 GB
- homelv - /home (XFS) - 20 GB
- rootlv - / (ReiserFS) - 12 GB
- swaplv - SWAP (2 GB)

A biztonság kedvéért azért még hagytam 5 GB-ot a VG-ben kiosztatlanul, hogy ha kell akkor ne adj isten valakinek oda tudjam majd adni.
Miután ezt megcsináltam a telepítő közölte, hogy márpedig neki ezeket az adatokat fel kell írnia a diszk-re, és tuti biztos vagyok e abban, hogy én ezt komolyan akarom.. Magamban még1x átgondoltam a helyzetet, megbizonyosodtam, hogy minden szükséges óvintézkedést megtettem (backup!!!), majd úgy éreztem, hogy üsse kavics, a Vasárnap 13 óra pont alkalmas arra, hogy szeretett gépem OS-ét végérvényesen kibelezzem...
Ubuntu fel is írta az adatokat, majd váratlanul egy olyat szólt, hogy:
"Couldn't detect codename for release."
Ahogy nézem azért nem csak nekem kedveskedett már ez az üzenet..
Innen pedig a telepítő úgy gondolta, hogy nem is érdemes továbbmenni.

Na akkor vissza a kályhához... Újabb keresés, miközben az öröm a plafonon, hogy a partíciós tábláim is a levesben vannak már.. Aztán a megoldás is szembejött: A 'cdrom-detect/try-usb=true' bejegyzést is be kell szúrni az unetbootin által létrehozott menü entry-k közé.

Miután ez megvan irány vissza a telepítő, majd ismét a particionálás , majd vártam, hogy most már azért tovább is menjen.. Mázlimra tovább is ment, és a rendszer nagyja fel is ment.. Aztán valamiért ismét elhasalt, de itt már nem nagyon érdekelt ez az apró részlet - felraktam a GRUB2-t is az MBR-re (illetve a /boot alá), és restartoltam..
És lőn csoda- működik.. Igaz nincs se grafikus környezet, se wifi, se hasonlók, de legalább az alap rendszer működött, és ez volt ami nekem számított.. Innen már azt hittem sima dolog lesz minden: Nagy erőkkel neki is szaladtam a restore-nak a backupból.. Pontosabban szaladtam volna, mert a CIFS-et a mount itt még nem ismerte (nem voltak fent a szükséges csomagok).. És itt ütött (nagyon) vissza a 37 GB-os tar file.. Win alól tudtam olvasni, de úgy nem tudtam használni, hogy az attribútumokat is megtartsa a file..
Ergo ismét vissza a tervező asztalhoz...
A dolog vége az lett, hogy a Win-es gépen létrehoztam egy Virtuális gépet (Virtualbox), azt a rendszert felbootoltam egy Live USB image-el (ott már volt SM támogatás), bemountoltam a Win-en kiosztott SMB megosztást, kicsomagoltam a /etc-t (mc), majd ismét összetaroltam, visszaraktam a másik tar file mellé, azt átvittem pendrive-on, és figyelve, hogy az fstab-ot véletlenül se írjam felül visszaállítottam a /etc tartalmát.. Innentől már megvoltak a régi repository-jaim, ergo simán ment az apt-get update is, és fel tudtam rakni a szükséges csomagokat. Ez után már be tudtam mountolni a távoli SMB megosztásom, és láttam is a backupom..
Újult erővel indultam neki a restore-nak, ám ismét utamat álta egy  rendkívül idegesítő dolog: az mc nem volt képes lekezelni ekkora tar file-t (folyamatosan I/O error-ra panaszkodott), én meg nem akartam a teljes tar-t kibontani a filerendszerekre 2 oknál fogva:
- Nem akartam felülírni semmiféle olyan file-t ami esetleg a kernelhez köthető, vagy a grubhoz, esetleg bármi máshoz ami az új rendszer részeként fontos lehet..
- Mint előbb is mondtam a mountokat kicsit átalakítottam, így most már 1-2 FS nem is volt elérhető ott ahol régen voltak, az újak alatt meg nem volt ennyi szabad hely..
180 fok, vissza a fő géphez, és a Virtualbox-ban futó linuxhoz: Hozzácsaptam ehhez a géphez egy 60 GB-os kötetet, majd a teljes backupomat kicsomagoltattam ide.
Amint ez kész lett kiszedtem azokat a mappákat/file-okat amiket nem szeretnék felülírni véletlenül se, majd (immár kissebb méretben) újabb tar file-okat hoztam létre, amit immár az mc is képes volt megenni.. Pontosabban nem egészen.. Az mc a jelek szerint allergiás a speciális karakterekre (főként a @-ra, amire váltig állítja, hogy hardlink akar lenni), így maradt a puritán 'tar -xv' megoldás, amit így már rá is mertem engedni a gépre, tekintve, hogy már kigyomláltam a problémásabb részeket.
A művelet végére sikerült mindent visszaállítani, a gépem be is bootolt szépen, felállt a rendszerem is, bár volt még 1-2 problémásabb dolog..
Ami nekem első körben probléma volt: a rendszer által felrakott kernel-lel már voltak régen inkompatibilitási problémáim, így ez volt az a pont amit még mindenképp meg akartam csinálni. Ekkor már kb éjfél volt, de úgy voltam vele, hogy ezt még befejezem, aztán holnap már tudok is dolgozni a géppel, max munkaidőben a többi kisebb dolgot megcsinálom.. Ergo nekiálltam egy frissebb kernelt telepíteni.. Ez volt a hiba... A friss kernel olyan gyönyörűen felülvágta az initrd-met, hogy öröm volt nézni.. A következő indulással pedig már a crypt be se töltődött, és bámultam a fekete busybox-ot 2 asztal fejelés között..
Itt voltam úgy, hogy ezt már nincs mese, valahogy meg kell csináljam, holnap ezzel a géppel dolgozni kell. Próbálgattam a grub paraméterekkel játszani, de gyorsan be kellett lássam, hogy ha az initrd-ben nincs benne az ami nekem kell, akkor itt semmiféle grubos fekete mágia nem segít. Így hát liveUSB ismét elő, gép bebootol, kómás fej felébreszt, és lelki szemeimmel bámulom a szakadék túloldalán lévő partot, amihez most ismét nekem kell felépítenem a hidat.. Ami kb így nézett ki:
Feloldottam a titkosítást:
# cryptsetup luksOpen /dev/sda2 rootvg
Aktiváltam a VG-t:
# vgchange -a y rootvg
Megnéztem, hogy minden megvan e:
# lvm vgs
VG #PV #LV #SN Attr VSize VFree
rootvg 1 4 0 wz--n- 55.77g 5.49g
# lvm lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
datalv rootvg -wi-ao 18.62g
homelv rootvg -wi-ao 18.62g
rootlv rootvg -wi-ao 11.18g
swaplv rootvg -wi-ao 1.86g
Bemountoltam a megfelelő FS-eket a /mnt/chroot alá:
# mount /dev/mapper/rootvg-rootlv /mnt/chroot
# mount /dev/sda1 /mnt/chroot/boot
# chroot /mnt/chroot
# mount -t proc proc /proc
# mount -t sysfs sys /sys
# mount -t devpts devpts /dev/pts
Ez után megnéztem hol is baxtam el.. Hát persze.. Én barom felülírtam a /etc/crypttab-ot, illetve a /etc/initramfs-tools/modules alatt se vettem fel az új dolgokat.. Erre bizony figyelni kellett volna.. Na mind1.. Pótoljuk akkor be..

# grep -v ^# /etc/crypptab
rootvg /dev/sda2 none luks,retry=1
# egrep -v "^#|^$" /etc/initramfs-tools/modules
aes-256
dm-crypt
dm-mod
sha256

Majd akkor ismét generáljuk újra az initrd-inket:
# update-initramfs -k all -c
Aztán restart, és ima...
Mákom volt.. Ez megoldotta a problémák nagyját.. A rendszer felállt, bár jó pár dolog nem ment (wifi, aku kijelzés,hang, network manager).. Ekkor már kb hajnali 2 volt, így úgy gondoltam, hogy nem érdekel, ebből már "holnap" tudok valamit kezdeni munkaidőben is.. dhclient megy, IP-t tudok kérni a kábelen keresztül, a fontosabb appok mennek, ezeket a hülyeségeket meg majd megoldom alvás után.
"Másnap" aztán kicsit kipihentebb fejjel átgondoltam mi a fészkesért is mehetett szét így minden, hisz az initrd piszkálás előtt ezek még mentek.. Első körben azt hittem elfelejtettem valami modult még belepakolni, de visszanézve a régi modulok listáját nem nagyon találtam különbséget, így ezt kénytelen voltam elvetni.. Majd fejbe csapott az isteni szikra: Mindezt a sok hülyeséget a dbus irányítja most már (hald sajna már nincs), így azt kéne helyrecsapni.. Mázlimra az első próba megtette a hatását:
# dpkg-reconfigure dbus
Ez után minden ment ahogy annak kellett.. Öröm és bóduttá.. Ismét tudtam dolgozni..

De persze ez a sztori nem lenne teljes, ha itt befejezném.. Akárhogy is nézem, azért volt jó pár dolog amiket ki szeretnék emelni:
- A tar nem backup solution.. Hiába használható annak, attól még lehet egy rsync-el jobban jártam volna, vagy más megoldással
- Este, fáradtan ne kezdjem el a rendszer alapkövét (kernel) piszkálni, mert nem biztos, hogy kifizetődő
- Legközelebb inkább telepítsem újra az egész gépet 0ról, és úgy húzzam vissza a dolgokat. Igaz, hogy ez a megoldás működőnek látszik, viszont nem tudom hány problémás részt hagytam a gépben, ami később visszaüthet. Egy clean install lehet problémamentesebb lett volna.
- Mielőtt nekiállok valami hasonlónak, 1x csináljam azt meg egy virtuális rendszeren! Csak én lehettem akkora marha, hogy a tényleges rendszernek mentem neki tényleges "szimuláció" nélkül, ami sok kellemetlenségtől megkímélt volna, plusz alapból olyan tapasztalatokat szolgáltatott volna, amik révén a tényleges migrálás valóban probléma mentesebb lett volna ( bár az is igaz, hogy ha ott egy ilyen issue-ba belebotlok, akkor ott valószínű nem kezdek el ilyen keményen dolgozni, hogy mindent helyrehozzak amilyen gyorsan csak lehet, és valószínű  ez a project jó pár hetet késett volna)

2011. június 9., csütörtök

xivpath - pre-release

Ahogy az előző postomban is említettem dolgoztam egy kicsit egy 'xivpath' nevű datapath/pcmpath szerű programon, hogy egy kicsit megkönnyítsem a saját életemet az XIV adminisztráció kapcsán.
Nos.. A fejlesztés elérkezett a "pre-release" fázisba. Ebben a fázisban az általam megtalált hibák/bugok már javítva lettek, és nem tudok további olyan bugról, ami ténylegesen problémát tudna okozni, így elérkezettnek láttam az időt, hogy publikáljam a kódot (tekintve, hogy semmi confidential dolgot nem tartalmaz).
Amennyiben van XIV-s rendszere bárkinek, azt megkérném, hogy tesztelje a kódot, és amennyiben hibát talál bárhol, úgy vegye fel velem a kapcsolatot, hogy javíthassam azt.

Jah igen.. felhívnám a figyelmet arra, hogy a script csak Fibre Channel adapterekre lett felkészítve, mivel nem áll rendelkezésemre iSCSI-t használó kliens. Továbbá -remélem feleslegesen- kiemelném, hogy ez a script az XIV-s kliensekre lett készítve, így ha pl DS8K-n akarná valaki használni, akkor ne csodálkozzon ha nem azt kapja amit várt :)
Illetve a szokásos játék itt is fennáll: Ezt a scriptet én a saját kis szabadidőmben csináltam, ergo hivatalos support nincs rá, illetve az esetlegesen keletkezett kárért se tudok felelősséget vállalni, így tessék tisztességesen egy teszt környezeten tesztelgetni első körben (azért arra felhívnám a figyelmet, hogy a scriptnek elvileg nem szabadna semmiféle kárt okoznia, de sose lehet tudni :))

Update: Kicsit hivatalos formába öntöttem a dolgot, és felraktam a csomagot az alábbi címre:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/glukacs/resource/xivpath.tar.zip