A következő címkéjű bejegyzések mutatása: Linux. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: Linux. Összes bejegyzés megjelenítése

2012. május 6., vasárnap

Murphy és a "jó" design

Elég mozgalmas volt ez az április, így nem sok időm volt blogolni bármiről is, de azért egy "emlékezetes" issue úgy érzem megérdemel annyit, hogy megmaradjon az utókornak.

Hol volt, hol nem volt (az óperenciás rendszeren is túl) volt egy szerver, aminek a design-ját okos emberek kialakították, és megítélendék jónak. Persze az okos emberek teljesen másra szánták a gépet mint amire azt később a customer nevű állatfaj elképzelte. Így alakulnak ki a természetben az olyan félvér állatfajok, amik inkább csak a hibáikkal tűnnek ki, mint sem a használhatóságukkal, és tuti biztos, hogy a lelkes adminisztrátorok előbb utóbb rájönnek, hogy az ilyen szerverek is inkább csak elrettentő példának jók, min tsem produktív dolgok futtatására, de hát a customert ez a legkisebb mértékben se szokta érdekelni, neki csak az a fontos, hogy az über-fontos dolgok menjenek a gépen..

Na most.. Ha még vannak olvasók akik nálam jobb emlékezettel vannak megáldva, akkor nekik lehet dereng valami a múltból, amikor a design hibákat ecsetelgettem, és már akkor is elmondtam, hogy az adott architect-nek jó rejszolást kívánok egy sajtreszelő társaságában, hogy ezt a design-t képes volt megálmodni

Hogy, hogy nem, most Áprilisban jött el az ideje annak, hogy Murphy ismét szórakozni akarjon, és kitalálta, hogy ez az igen fontos gép amúgy is billeg a szakadék szélén, hát miért ne lökjön rajta egy kicsit.. Persze ha már ott van, akkor a mentőalakulatok útjába is felállít 1-2 csapdát, mert az úgy még is csak nagyobb a FUN faktor.

A valóságban mindez a következőképp realizálódott:
Első körben a fenti design-ban szereplő RAID 5 tömb alól 2 diszk úgy gondolta, hogy őt már nem becsülik meg eléggé, így Seppuku-t hajt végre. "Mázlira" csak az Egyik diszk volt aktív, a másik csak Hotspare, így elméletben még itt nem kéne nagy problémának lennie. Így hát új diszk beszerez, hotplug manager elő, aztán cseréljük on-the-fly a temetőbe szánt Hotplug diszket, ahogy az a nagykönyvben is meg van írva.

Sajna azonban a Nagykönyvekkel mindig az a baj, hogy az emberek elfogadják a benne leírtakat egyfajta axiómának, ami -ha Murphy is a képben van- általában nem teljesen szokta lefedni a valóságot: Így hát persze így se minden úgy működött ahogy kellett volna.. Történt ugyan is, hogy a teljesen szabályosan kicserélt új diszket a rendszer nem volt képes lekezelni, mivel a régi konnekciós azonosítót valamiért nem akarta felszámolni.
Hogy szemléletesebb legyen a dolog, kb ezt látja a szerencsétlen adminisztrátor:
# sissasraidmgr -L -j1 -l sissas5
------------------------------------------------------------------------
Name      Resource  State       Description              Size                  
------------------------------------------------------------------------
sissas5   FFFFFFFF  Primary     PCI-X266 Ext Tri-x4 3Gb SAS RAID Adapter
 sissas6  00000000  AWC linked  Redundant cache protection for sissas5  

hdisk3    00FF0000  Degraded    RAID 5 Array            1135GB                 
 pdisk0   00000200  Failed      Array Member           283.8GB                 
 pdisk1   00000300  Active      Array Member           283.8GB                 
 pdisk3   00000500  Active      Array Member           283.8GB                 
 pdisk2   00000400  Active      Array Member           283.8GB                 
 pdisk4   00000600  Active      Array Member           283.8GB                 

*unknwn*  00000700  RWProtected Array Candidate            N/A                 
pdisk5    00000700  Missing     Disk                   283.8GB
Na szóval.. Vagy egy hdisk3 néven létező RAID 5 tömbünk, ami épp Degrad állapotban leledzik, mindez a sissas5 adapteren. Van 2 halott diszkünk (pdisk0,pdisk5), ami közül pdisk5-öt igyekszünk épp kicserélni, ami jelenleg épp Missing státuszban leledzik. A pdisk5 kapcsolati címén (00000700) azonban van még egy diszk, ami épp RWProtected, amúgy meg unknown (tehát a rendszer nem tud róla semmit). Így meg persze még neki se lehet állni új Hotspare-t definiálni (hogy aztán azt majd bedobjuk a pdisk0 helyére)

Na ez az a rész, amiről a nagykönyv nem ír semmit (Murphy viszont a Pop-corn egy részét már elfogyasztotta).. Ergo akkor nincs más, csak kidobni a vak hitet, és menni az ember saját feje után.
Első körben az előzőleg kicserélt diszk-et kivéve a slotból lehetőség nyílt az unknown device "elvesztésére" ám a rendszer pofátlan módon ragaszkodott a pdisk5 jelenlétéhez, attól függetlenül, hogy az már közel, s távol nem volt a gépben. Külön poénként ezt a meggyőződését még akkor se volt hajlandó elfelejteni amikor a pdisk5-öt 'rmdev -dl'-el lelőttem, majd a config managert (cfgmgr) futtattam, mivelhogy az rendkívül ragaszkodóan visszahozta a pdisk5-öt "Available" státuszban (a RAID vezérlő persze még mindig Missing-nek látta).

Na akkor itt álljunk meg egy picit.. Felmerül a kérdés -gondolom- az olvasóban, hogy biztosan a jó diszk lett kihúzva? Igen, ez volt az első felmerülő kérdés bennem is, de többszöri vizsgálat után is csak az jött ki, hogy valóban a jó diszket piszkálom és az AIX (VIO, de a lényegen semmit nem változtat) az aki foggal körömmel ragaszkodik ahhoz a diszkhez.

Fejvakarás, cseresznyefák, és wattafák.. Avagy csak fák.. Kinek mi esik jól.. Murphy közben a Pop-corn mellett már elindította a háttérben a Kokaku Kidotai (Ghost in the Shell) OST-t is, mert ehhez a jelenethez ez illik a legjobban..

Adminisztrátor részről persze teljes értetlenség, keresés, látott e már valaki valami ilyesmit? Aztán szembejön ez a bug, és fény gyúlik a katakombákban : IZ72353 - SAS PDISK DISPLAYED AS *UNKNWN* AFTER REPLACE/REBUILD APPLIES TO AIX 6100-03

Jah hogy úgy... Hát úgy.. A gáz csak annyi, hogy a patch magában nem elérhető (mivel VIO-ról beszélünk, így csak VIO frissítéssel együtt oldható meg a csótányirtás), így (mivel már mindenki a hátunk mögött van, és a messzeségben már a mesterlövészek is a mi monitorunkat lesik a fejünk mellett) a leggyorsabb megoldás a restart marad. Persze előtte minden kliens azonnal állj, addig a VIO se mozduljon semerre..

Restart, öröm és boduttá.. A pdisk5 végre defined-ban jön fel, sőt az újonnan beletett vinyót is már látja a rendszer.. Sínen vagyunk mint József Attila..
HotPlug diszk megformáz 528 Byte Szektor mérettel, majd a pdisk0 kipöccintése után nyomban be is áll a helyére az immár hamvaiból feltámadt pdisk5 Főnix madár, indulhat az Array Rebuild, semmi ok a pánikra, minden a Ctrl billentyű alatt van

Hátradőlünk, és szépen várjuk, hogy a tömb újjáépítése befejeződjön. A háttérben viszont Murphy ráadást követel, így hát újabb szám zendül fel a hangszórókból.

A moziban ilyenkor kezdenének el villogni a piros villogók, felharsognának a szirénák, és valami kis rangú emberke kétségbe esve megszólalna, hogy "Sir, Something is wrong!" (Thank you, Caption obvious). A valóságban azonban az embert csak egy ilyen hibaüzenet fogadja a fekete putty ablak mögött:
# sissasraidmgr -L -j1 -l sissas5
------------------------------------------------------------------------
Name      Resource  State       Description              Size                  
------------------------------------------------------------------------
sissas5   FFFFFFFF  Primary     PCI-X266 Ext Tri-x4 3Gb SAS RAID Adapter
 sissas6  00000000  AWC linked  Redundant cache protection for sissas5  

hdisk3    00FF0000  Failed      RAID 5 Array            1135GB Rebuild Failed 04
 pdisk5   00000700  Failed      Array Member           283.8GB                 
 pdisk4   00000600  RWProtected Array Member           283.8GB                 
 pdisk3   00000500  RWProtected Array Member           283.8GB                 
 pdisk2   00000400  RWProtected Array Member           283.8GB                 
 pdisk1   00000300  Failed      Array Member           283.8GB                 

pdisk0    00000200  RWProtected Array Candidate        283.8GB

Őőő.. 'nyádat... Újratervezés..
- A pdisk5 most lett kicserélve, leformázva, leellenőrizve, így az garantáltan nem lehet halott (hacsak nem a vezérlő halt meg, de akkor már az ima is édeskevés lesz)
- A pdisk1re eddig nem jött egy hibajelentés se, így azt vessük górcső alá.
- Az errpt entry-jeit elnézegetve (54E8A127 error code (DEVICE OR MEDIA ERROR), ha valakit érdekel) az összes hibajegy a pdisk1-el megegyező Serial ID-ra jön, így tételezzük fel, hogy a pdisk5 Failed státusza az újraépítés során tapasztalt pdisk1 hibájának mellékhatása csak.

Ezzel viszont egy újabb probléma üti fel a fejét: A RAID5 tömb egyszerre csak 1 aktív diszk halált bír ki, kettőt már nem. Amennyiben a pdisk1-et is ki kell cserélni, akkor kalap,kabát, búcsút lehet mondani az adatainknak, mert 3 diszkből már nem engedi a vezérlő se helyreállítani a tömböt (Én megpróbáltam, de hát ez nem linux).
Egy mázli volt - amennyiben az ember újraindítja ebben a fázisban a VIO-t, akkor a SAS RAID vezérlő újra megpróbálja a tömböt össze-eszkábálni, ami viszont kitűnő alkalmat teremt arra, hogy az ember megpróbálja menteni ami menthető.

És itt most álljunk meg ismét egy pillanatra.
- Adott egy fél lábbal már a sírban lévő RAID5 tömb
- A tömbön lévő adatok egy része már garantáltan nem elérhető, tehát a disaster recovery elkerülhetetlen (ugye van disaster recovery plan? :) Megsúgom, az ilyen rendszereknél rendszerint nincs.. Itt a remek alkalom, hogy most fejben összeüss egyet, és imádkozz, hogy az a minimális backup process ami eddig volt elégséges legyen :D )
- Ha mindenképpen kell DR, akkor minek akarok én menteni bármit is?

Nos, a válasz némileg komikus: Az egyik kliens egy Linux rendszer (SLES 10), amely system VG-je 1 VIO-n található LV-re lett ráhúzva (az LVM kell, ha az ember normálisan akarja skálázni a meglévő erőforrásokat, szóval ez még érthető is). Ahhoz, hogy ezt visszaimádkozzuk 3 út maradt:
- Csinálni egy low level mentést byte szinten a "Guest" System VG-jét tartalmazó PV-ről (azaz a VIO-n lévő LV-ről) valahova a RAID tömbön kívűl, és azt megpróbálni visszatölteni amint az új RAID tömbünket kénytelenek voltunk újra kreálni
- Csinálni egy FS szintű backupot (SLES gyárilag tud ilyet), a RAID tömb 0ról való építése után pedig felhúzni egy alap SLES rendszert, és arra visszatölteni az itt készült backup-ot
- Megpróbálni csinálni egy bootolható ISO file-t, azt odaadni a VIO-nak, majd mint CD/DVD-t kiallokálni a kliens felé, és arról visszatölteni az adatokat (Standard Linux környezetben ez szépen megy is, de amúgy vannak direkt erre a célra elkészített programok is, mint pl a Mondo Rescue)

A baj csak az volt, hogy mind3 út buktatókkal volt kikövezve:
- Bootolható ISO készítés: Az elmélet jó, de az egyik verzióban fel kéne raknom a Mondo Rescue (vagy azzal egyenértékű) progit, ami sajna PPC-re nem elérhető. A Debian féle módszer még működne is, de sajna a pSeries gépeken a boot loader nem grub, hanem Yaboot, ami meg nyomban úgy kezdi, hogy külön FAT16 típusú partíció neki, ami az ISO image-em szempontjából így nem járható.
- Az FS szintű backup azért necces, mert egy teljesen új rendszer felinstallálása szükséges hozzá, ami meg iszonyat nagy macera.
- A low-level (dd) szintű backup tűnt a legjobbnak (és akkor még az LVM struktúra is megmarad), ám amennyiben a RAID5 tömb ezen belül hibásodott meg, akkor meg megint ott vagyok ahol a part szakad..

Nem volt mit tenni: Úgy döntöttem, hogy amit lehet menteni kell (lehetőleg minél többféle képen), mivel a jelenlegi állapotot tutira újra is kell építeni. Tehát csináltam egy dd szintű mentést (LPAR lekapcsolva természetesen), meg egy FS szintűt is, felkészülve a legrosszabbra (az applikációs adatokért nem tudtam semmit se tenni, azt majd remélhetőleg a standard backup process által készített backup lefedi az adat visszaállítás során)

Ez után jött a másik 2 diszk cseréje (pdisk0, pdisk1), majd a halott RAID tömb törlése, és egy új készítése. Mindeközben sűrű miatyánk Mekka irányába..
Amint az új RAID tömb elkészült (immár hiba nélkül) lehetett visszahozni a régi LVM struktúrát, majd nekilendülni az adat visszaállításnak..
És igen.. Mázlim volt.. nettó 40 perc alatt a ~100 GB-os system VG-ről készített dd backup visszatöltődött (yaboot-al együtt), és az LPAR képes volt felbootolni (igaz RC 2ig nem jutott el, de ezen már lehetett segíteni), ergo már csak a tényleges applikációs adatok visszatöltése maradt vissza (meglepő módon azok visszatöltése közben nem nagyon akadt probléma)

Tapasztalatok a jövőre nézve:
- Ha tényleg über fontos adatról/alkalmazásról beszélünk, akkor erőltessük már meg magunkat, és a környezetet tényleg redundánsan alakítsuk már ki
- A RAID 5 addig jó, amíg kevés diszk van alatta. A tömb növekedésével együtt növekszik a teljes tömb meghalásának esélye is (mivel nagyobb az esélye, hogy 1 időn belül 2 aktív diszk hal ki, ahogy itt is történt (nagy eséllyel a használt diszkek ugyan abból a sorozatból valóak, ergo közel ugyan annyi idő alatt is halnak meg))
- Disaster recovery plan még akkor se árt ha van, ha amúgy a rendszer nem indokolja azt meg. A probléma a jelen setuppal az, hogy nem nagyon lehet rá 100%-os plan-t készíteni (ami effektíven használható lenne), a bootolható backup hiánya miatt (személyes véleményem szerint SLES pSeries-re nem való)
- Nagykönyv lehet, hogy létezik, de inkább tekintsünk rá amolyan "Kalóz Kódexként" ami inkább csak útmutatás, mintsem sérthetetlen szabály.. Valami úgy is valamikor el fog romlani, amire persze hogy nem leszünk felkészülve
- A szokásos halandzsa - update, update, update. Tudom, hogy az überfontos applikáció überfontos uptime-al kell üzemeljen, de kalkuláljunk már maintenance window-t is a rendszerhez, hogy az ilyen hülye önszopatásoktól megkíméljük magunkat.
- Murphy sose alszik, és mindig pörgős zenét hallgat :)

2011. augusztus 9., kedd

VirtualBox - hogy én mennyire szeretlek

Új ötlettől vezérelve úgy gondoltam, hogy felrakom a Linux (Ubuntu 10.04 LTS) alá a legújabb virtualbox-ot (4.1 build 73209),aztán abban meg majd futtattatok jó kis VM-eket, amiken meg kényem-kedvem szerint kísérletezgethetek. Mivel a kernel egy 2.6.38-10es PAE kernel volt (32 bit), így az OSE verzió már nem tudott felmenni (az még mindig csak 3.1-es, az meg ezzel a kernellel nem kompatibilis), ergo mentem a szokásos úton: A virtualbox.org-ról letöltöttem a 10.04-hez való 32 bites .deb-et, feltettem, majd elkezdtem játszadozni a virutális gépekkel.

Nem is volt ez gond egészen addig, amíg úgy nem gondoltam, hogy mára elég is lesz, sleep-eljük le a notit, aztán menjünk haza -> Itt ugyan is úgy gondolta a gépem, hogy ő nem megy el aludni, helyette dob egy kernel panic-ot.. Na gondoltam szupi, a legtöbb adat hála az égnek mentve van, szóval majd otthon megnézem, addig is full kikapcs.
Itthon aztán elkezdtem nézegetni, hogy ki és hogy, majd kb fél órás bug vadászat és tesztelgetés után kijött, hogy a probléma bizony a vboxdrv modul körül forog: Amennyiben a modul aktív a sleep pillanatában, úgy a kernel dob egy hátast.

Így első gondolatom az volt, hogy semmi gond, fogom magam és szimplán kilapátolom a modulok közül a Virtualboxos modulokat, amikor meg visszajön akkor visszatöltetem.. Ezt kb a következő módon követtem el:
A /etc/pm/sleep.d alatt létrehoztam egy 12virtualbox file-t a következő tartalommal:
#!/bin/bash
case "$1" in
	hibernate|suspend)
		for i in vboxpci vboxnetadp vboxnetflt vboxdrv; do rmmod $i;done
		;;
	thaw|resume)
		for i in vboxdrv vboxpci vboxnetadp vboxnetflt;do modprobe $i;done
		sleep 1
		;;
	*)
		;;
esac
Tesztelés, és lám - így tényleg megy is a játék.. A probléma ezzel a megoldással viszont az, hogy amennyiben fut egy virtuális gép, úgy a gép -persze hogy- nem bírja kilőni a modulokat, úgy hogy ebben az esetben még mindig gáz van.. Szóval goto #dolgozoasztal...
Kis keresés után bele is botlottam az alábbi szálba: http://www.virtualbox.org/ticket/9305
Itt egész szépen ecsetelik is, hogy ez bizony tényleg a 4.1-nek a hülyesége, sőt a végén még oda is biggyesztik, hogy Jul. 28-al commitálták is a változást, és hogy a következő release-ekben ez bent is lesz.. Szupi.. Csak hogy az a release még sehol nem jött ki, szóval innentől vagy "csináld magad", vagy várj.. Én az előbbi mellett döntöttem, így az alábbi játékot játszottam el:
sudo su -
cd /usr/share/virtualbox/src/vboxhost/vboxdrv
wget http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/virtualbox-modules/files/virtualbox-modules-4.1.0-vboxbug9305.patch
patch -p1 < virtualbox-modules-4.1.0-vboxbug9305.patch 
/etc/init.d/vboxdrv setup
ls -l /lib/modules/$(uname -r)updates/dkms/vboxdrv.ko

Ez után jött egy újabb sleep teszt, és láss csodát - így már futó VM esetén is szépen le tud sleepelni a gép... Öröm és bóduttá... Az viszont biztos, hogy most egy jó ideig nem akarok vbox-ot frissíteni, hacsak valami tényleg nem indokolja azt meg..

2011. július 23., szombat

SFTP - Couldn't canonicalise: Permission denied

Noh akkor mai érdekes esetem a következő:
Tisztelt user a gépre gond nélkül be tud SSH-val jelentkezni:
p1ngw1n@Twitchy-Thinkpad:~$ ssh client_user@sftp_server
client_user@sftp_server's password:
[client_user@sftp_server:/home/client_user]
Csak hogy kerek legyen a kép: nézzük az SSH számára használt file-okat/mappákat is:
[client_user@sftp_server:/home/client_user] ls -ld ~
drwxr-xr-x 9 client_user staff 512 Jun 28 15:43 /home/client_user
[client_user@sftp_server:/home/client_user] ls -ld ~/.ssh
drwx------ 2 client_user staff 512 Jun 28 15:46 /home/client_user/.ssh
[client_user@sftp_server:/home/client_user] ls -l ~/.ssh
total 8
-rw------- 1 client_user staff 2428 Jun 27 11:26 authorized_keys
[client_user@sftp_server:/home/client_user] ls -la ~/.ssh
total 24
drwx------ 2 client_user staff 512 Jun 28 15:46 .
drwxr-xr-x 9 client_user staff 512 Jun 28 15:43 ..
-rw------- 1 client_user staff 2428 Jun 27 11:26 authorized_keys
A home mappa 755ön (ez jó: csak az ownernek van írási joga), a .ssh mappa 700 (perfect) és az alatta lévő authorized_keys file pedig 600as jogokkal ott is van, ami szintén teljesen megfelel a számunkra. A felhasználó igénye viszont az, hogy az SSH kapcsolat mellett még secure filetransfert is tudjon csinálni (SFTP), ami viszont (hiába megy a bejelentkezés) a jelek szerint nem akar menni:
p1ngw1n@Twitchy-Thinkpad:~$ sftp client_user@sftp_server
Connecting to sftp_server...
client_user@sftp_server's password:
Couldn't canonicalise: Permission denied
Need cwd
User persze minket piszkál, hogy Wattafák, mert ilyet még ő se látott.. Megnézve az SSH konfigot szépen látszik, hogy az sftp-server a /etc/ssh/sshd_config alatt engedélyezve van:
[root@sftp_server:/home/root] grep sftp /etc/ssh/sshd_config
Subsystem sftp /usr/sbin/sftp-server
Illetve az még rátesz egy lapáttal, hogy mi pedig szépen és hiba nélkül tudunk SFTP-zni a szerverre (ergo tűzfal, és hasonló mókák kilőve). Tekintve, hogy az SFTP is a 22 portot használná csak a kommunikációra (mint az SSH), így a felhasználó esetében is elvileg adott minden lehetőség arra, hogy belépjen.. Ehhez képest mégse ez a helyzet a jelek szerint....

Az már csak fokozza a "fun" faktort, hogy a verbose login szerint az authentikáció sikeres, ergo a user be tud lépni, de aztán az SFTP eldobja a kapcsolatot:
p1ngw1n@Twitchy-Thinkpad:~$ sftp -v client_user@sftp_server
Connecting to sftp_server...
OpenSSH_5.3p1 Debian-3ubuntu6, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to sftp_server [10.1.0.230] port 22.
debug1: Connection established.
debug1: identity file /home/p1ngw1n/.ssh/id_rsa type -1
debug1: identity file /home/p1ngw1n/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'sftp_server' is known and matches the RSA host key.
debug1: Found key in /home/p1ngw1n/.ssh/known_hosts:370
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/p1ngw1n/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/p1ngw1n/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
client_user@sftp_server's password:
debug1: Authentication succeeded (password).

debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.utf8
debug1: Sending subsystem: sftp
Couldn't canonicalise: Permission denied
Need cwd

client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Transferred: sent 2224, received 2248 bytes, in 0.3 seconds
Bytes per second: sent 6468.5, received 6538.3
debug1: Exit status 0
A hibaüzenet egyértelműen permission denied-ot mond, viszont a fenti listából is látszik, hogy az összes SSH/SFTP által használt file ownere maga a user, és az összes file-nak jók a jogosultságai, ergo itt valami megint nem kóser.

Megnézve az SFTP kliens forrását (sftp-client.c) láthatjuk, hogy az alábbi kódrészlet felelős a hibaüzenetért, illetve az ellenőrzésért
do_realpath(struct sftp_conn *conn, char *path)
{
Buffer msg;
u_int type, expected_id, count, id;
char *filename, *longname;
Attrib *a;

expected_id = id = conn->msg_id++;
send_string_request(conn->fd_out, id, SSH2_FXP_REALPATH, path,
strlen(path));

buffer_init(&msg);

get_msg(conn->fd_in, &msg);
type = buffer_get_char(&msg);
id = buffer_get_int(&msg);

if (id != expected_id)
fatal("ID mismatch (%u != %u)", id, expected_id);

if (type == SSH2_FXP_STATUS) {
u_int status = buffer_get_int(&msg);

error("Couldn't canonicalise: %s", fx2txt(status));
return(NULL);
} else if (type != SSH2_FXP_NAME)
fatal("Expected SSH2_FXP_NAME(%u) packet, got %u",
SSH2_FXP_NAME, type);

count = buffer_get_int(&msg);
if (count != 1)
fatal("Got multiple names (%d) from SSH_FXP_REALPATH", count);

filename = buffer_get_string(&msg, NULL);
longname = buffer_get_string(&msg, NULL);
a = decode_attrib(&msg);

debug3("SSH_FXP_REALPATH %s -> %s", path, filename);

xfree(longname);

buffer_free(&msg);

return(filename);
}
A kód tényleges analizálása nélkül felhívnám a figyelmet egy fontos tényezőre, amit az SFTP csinál: A valós útvonalat (SSH2_FXP_REALPATH) ellenőrzi, nem pedig azt, hogy a file-ok amivel dolgozik valóban elérhetőek e.. Ez esetben ez azért is okozhatott gondot, mivel a user home-ja egy külön FS volt ->
Mint kiderült az SSH ezt a realpath ellenőrzést annyira komolyan veszi, hogy (szokásához híven) megy a saját feje után, és a mount point eredeti attributumait lekérve vizsgálja meg, hogy az vajon jó lesz e majd neki..
Csak hogy érthető is legyen a probléma:
[root@sftp_server:/var/adm] ls -ld ~client_user
drwxr-xr-x 9 client_user staff 512 Jun 28 15:43 /home/client_user
[root@sftp_server:/var/adm] mount |grep client_user
/dev/lv00 /home/client_user jfs Aug 02 03:51 rw,log=/dev/loglv00
[root@sftp_server:/var/adm] umount /home/client_user
[root@sftp_server:/var/adm] ls -ld /home/client_user
drw------- 2 root system 256 Dec 3 2009 /home/client_user
[root@sftp_server:/var/adm] chmod 755 /home/client_user
[root@sftp_server:/var/adm] mount /home/client_user
Pontosan - Az eredeti mount point-ra az adott usernak tényleg nincs semmiféle joga.. Miután átraktuk 755-re (root owner maradt!) nézzük az újjab tesztet:
p1ngw1n@Twitchy-Thinkpad:~$ sftp client_user@sftp_server
Connecting to sftp_server...
client_user@sftp_server's password:
sftp> quit
Aham.. Szóval így már megy -> szimpla reader jog kellett csak neki.. OpenSSH, én így szeretlek..

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)

2010. május 19., szerda

Tiny script - Putty settings converter

Windows-Linux migráció során született nálam az igény, hogy a Windows alatt használt putty-s beállításaimat valahogy át kéne pakolni linux alá ( tekintve, hogy elég sok szerver volt felvéve, így mindet manual ismét felpakolni elég nagy macera lett volna ). Ezen igény kielégítésére született az alábbi kis scriptecske. Gondoltam publikálom hátha még valakinek jól jön:
http://pastebin.com/TYxfLXFL
A folyamat kb a következőképp néz ki:
- Windows alól első körben ki kell exportáljuk a putty-s beállításainkat a registryből ( regedit.exe /e putty_settings.reg HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions )
- A kiexportált .reg file-t át kell konvertáljuk UTF16ról valami emberibb formátumba ( UTF-8, CP-1250 ). Ehhez én a lokális gépen notepad++-t használtam, de ha cygwin alá felrakjuk az iconv-t azzal is megy ( megoldható lett volna egy perl alatti iconv modul include-olása, de mivel az is külső modult igényelt volna, így azt elvetettem )
- A scriptben megadjuk a .reg file helyét ( éljen a hardcoding :D (Jó tudom.. Lusta voltam megírni, hogy megkérdezze :))
- A scriptet futtatva ( nálam épp cygwinből, de elvileg activeperl is használható ) az aktuális mappába legenerálja nekünk a linux alatt használható file-okat
- A generált file-okat a ~user/.putty/sessions mappa alá bepakolva már is a helyükön lesznek a session-ök :)
Amire figyelni kell:
- Ha van beállítva logolás, akkor linux alatt azt ildomos átlőni ( egy sed szerintem totál megteszi erre a célra )
- A használt kulcsfile-t érdemes szintén átlőni
For the trolls:
Nem mondom, hogy szép, vagy hogy nem lehetne rajta fejleszteni, csupán egy szerintem elégséges alap az adott feladat ellátására. Viszont ha van bárkinek bármilyen javaslata ( kódolás során megejtett hibák főként ) amiből érdemes tanulni azt most is szívesen fogadom.

2009. november 19., csütörtök

PCMCI GlobeTrotter + Pannon mobilNET

Kis note magamnak, mert 1,5 napig szívtam mire rájöttem hol és mit szúrok el :)
1. is: gnome-ppp,kppp,network-manager - kukába velük => Éljen a konzol!
2. : pppd tökéletesen megfelel a feladatra
3. : A konfigok:
# cat /etc/ppp/peers/pannon
/dev/noz0
115200
idle 7200
lock
crtscts
modem
noauth
replacedefaultroute
defaultroute
user pannon
password pannon3g
connect "/usr/sbin/chat -V -f /etc/ppp/peers/pannon-chat"
noipdefault
usepeerdns
# cat /etc/ppp/peers/pannon-chat
ABORT BUSY
ABORT 'NO CARRIER'
ABORT VOICE
ABORT 'NO DIALTONE'
ABORT 'NO DIAL TONE'
ABORT 'NO ANSWER'
'' ATZ
OK-AT-OK AT+CGDCONT=1,"IP","net"
OK "ATD*99***1#"
CONNECT ''
4. : pppd call pannon, és megy minden mint a kis angyal ( már ha a nozomi driver szépen berántotta a kártyánkat => ls -l /dev/noz* ):
# tail -12 /var/log/syslog
Nov 18 20:09:17 thinkpad pppd[7073]: pppd 2.4.5 started by root, uid 0
Nov 18 20:09:19 thinkpad pppd[7073]: Serial connection established.
Nov 18 20:09:19 thinkpad pppd[7073]: Using interface ppp0
Nov 18 20:09:19 thinkpad pppd[7073]: Connect: ppp0 <--> /dev/noz0
Nov 18 20:09:20 thinkpad pppd[7073]: CHAP authentication succeeded
Nov 18 20:09:20 thinkpad pppd[7073]: CHAP authentication succeeded
Nov 18 20:09:25 thinkpad pppd[7073]: Could not determine remote IP address: defaulting to 10.64.64.64
Nov 18 20:09:25 thinkpad pppd[7073]: Cannot determine ethernet address for proxy ARP
Nov 18 20:09:25 thinkpad pppd[7073]: local IP address 84.224.129.85
Nov 18 20:09:25 thinkpad pppd[7073]: remote IP address 10.64.64.64
Nov 18 20:09:25 thinkpad pppd[7073]: primary DNS address 217.79.128.40
Nov 18 20:09:25 thinkpad pppd[7073]: secondary DNS address 217.79.128.45
Segítségért köszönet a http://hup.hu/node/51762 threadnek, illetve a http://mgsm.hu/other_html/wap_mms.html oldal készítőinek az APN adatokért :)