"Mondanám hogy szőke, de sötét mint az éjszaka"

Azt hiszem írtam már ezen a blogon párszor, hogy az ember egy idő tán meglehetősen magasra emeli a mércét ha arról van szó, hogy min is lepődik meg X évnyi pályafutás után de sose mondja senki, hogy még ilyenkor se tudja kiverni semmi a biztosítékot.. Avagy amikor az ember azt hinné, hogy mélyebbre már nem lehet süllyedni, de valaki még is megtalálja a Mariana-árok mélyén a dugót, kihúzza azt, és a lezúduló víztömeg őt is magával ragadja..

Azok a pillanatok amikor az emberi hülyeség extra adag szorgalommal párosul.
Na ez is egy ilyen volt..

A történet ott kezdődik, hogy a /app_fs filerendszer elérhetetlenné vált a rendszeren, és valaki meg (hogy hogy nem) szerette volna viszont látni. Az ember ilyenkor megnézi az alap dolgokat (nincs e overmount, elérhető e a VG egyáltalán, mountolva van e az FS), majd konstatálja, hogy valami tényleg nem kerek:

server1:root:[/] # mount |grep -c /app_fs
0
server1:root:[/] # lsvg -l appvg |grep applv       
applv              jfs2       320     320     1    closed/syncd  /app_fs
server1:root:[/] # lslv -l applv
applv:/app_fs
PV                COPIES        IN BAND       DISTRIBUTION  
hdisk7            320:000:000   27%           000:089:089:089:053 
server1:root:[/] # lsvg -p appvg
appvg:
PV_NAME           PV STATE          TOTAL PPs   FREE PPs    FREE DISTRIBUTION
hdisk2            active            319         0           00..00..00..00..00
hdisk3            active            1599        0           00..00..00..00..00
hdisk4            active            799         0           00..00..00..00..00
hdisk5            active            959         0           00..00..00..00..00
hdisk6            active            319         32          00..00..00..00..32
hdisk7            missing           447         127         90..00..00..00..37

Őő... Jaj... Na szóval.. Van az FS, ami épp closed-ban van (ez meg is magyarázza hova tűnt a filerendszer :)), ami épp a hdisk7en terül el, ami meg kopp hiányzik az lsvg szerint.. AIX mit tud minderről?

server1:root:[/] # lsdev -Cc disk
hdisk0 Available  Virtual SCSI Disk Drive
hdisk1 Available  Virtual SCSI Disk Drive
hdisk2 Available  Virtual SCSI Disk Drive
hdisk3 Available  Virtual SCSI Disk Drive
hdisk4 Available  Virtual SCSI Disk Drive
hdisk5 Available  Virtual SCSI Disk Drive
hdisk6 Available  Virtual SCSI Disk Drive
hdisk7 Available  Virtual SCSI Disk Drive

server1:root:[/] # lspv |grep appvg
hdisk5          00c3b9f4e1709f60                    appvg           active
hdisk2          00c5effd70395ab2                    appvg           active
hdisk3          00c5effd7c2e18d2                    appvg           active
hdisk4          00c3b9f4aeed3ccd                    appvg           active
hdisk7          00c3b9f4b2a59c9b                    appvg           active
hdisk6          00c3b9f47a309de6                    appvg           active

Él és virul, minden szép, akkor meg mi a fene? Olvassunk már rá a VGDA-ra...

server1:root:[/] # for i in $(lsvg -p appvg |awk '/hdisk/{print $1}');do echo "$i \c";readvgda /dev/$i|grep vg_id;done    
hdisk2 vg_id:           00c5effd00004c000000010da807da15
hdisk3 vg_id:           00c5effd00004c000000010da807da15
hdisk4 vg_id:           00c5effd00004c000000010da807da15
hdisk5 vg_id:           00c5effd00004c000000010da807da15
hdisk6 vg_id:           00c5effd00004c000000010da807da15
hdisk7 vg_id:           00c5effd00004c0000000110796187ae

őőő.. What?? Na szóval.. van egy PV, elérhető, elvileg része a VG-nek, gyakorlatilag meg nem (más a vg_id)... Kis gondolkodás hogy is lehet ez, majd szembejött a megvilágosodás hangos kürt szóval: Ezt a PV-t valaki más is használatba vette!

Tekintve, hogy Virtual diszk, így spuri a VIO-hoz, majd gyors lekérdezések után elő is jött a bűnös probléma:

padmin:vios:[/home/padmin] $ lsmap -all |grep -p hdisk108
VTD                   server2_hdisk4
Status                Available
LUN                   0x8700000000000000
Backing device        hdisk108
Physloc               U7311.D20.0637FDC-P1-C02-T1-W5005076801302EA8-L19000000000000

VTD                   server1_hdisk7
Status                Available
LUN                   0x8400000000000000
Backing device        hdisk108
Physloc               U7311.D20.0637FDC-P1-C02-T1-W5005076801302EA8-L19000000000000

És valóban.. És akkor mit csinál a másik gépen a PV?

server2:root:[/] # lspv
hdisk0          00c3b9f42b11232e                    rootvg          active 
hdisk1          00c3b9f4724a36f5                    rootvg          active 
hdisk2          00c5effd70926735                    dbvg        active 
hdisk3          00c3b9f418b7da43                    dbvg        active 
hdisk4          00c3b9f4b2a59c9b                    dbvg        active 
hdisk5          00c3b9f47715582b                    dbvg        active 

Na most alapjáraton ilyenkor jut eszembe tanult kollégám szava járása miszerint: "Some people just need a hug... around their neck... with a rope."

Egy óriási mázlink volt csak.. Ez:

server2:root:[/] # lspv -l hdisk4
server2:root:[/] # 

Tehát.. Ott a másik szerver, valaki idióta kiassignolta ugyan azt a LUN-t neki, majd berakta egy másik VG-be, ami felül is vágta a VGDA-t, de mákunkra nem használja ezen felül semmire, így a PV-n lévő adat a VGDA-t leszámítva sértetlen.

# Azt azért jegyezzük meg, hogy valaminek az ilyen nagyságrendű elcseszése is igen nagy erőfeszítésbe telik, ugyan is mind a VIO szerver, mind az AIX közli, hogy "Ez mintha már használatban lenne, úgy hogy ha biztos vagy a dolgodban, akkor a -force-ot add még meg a parancshoz" ergo 2x is szorgalmas hülyének kell lennie valakinek, hogy ezt összehozza..

Na jó.. akkor a kérdés már csak az, hogy hogy is varázsoljuk vissza a PV-t a helyére..
A hivatalos megoldás kb annyi, hogy "Reméljük van backupod az FS-ről, mert az FS-t/LV-t törölni kell, kiszedni a PV-t mind a 2 VG-ből (a 2. szerveren menni fog, az eredetin csak félig), szedd le a VIO-ról a LUN zónázást, majd aztán extendvg-vel rakd vissza a PV-t az eredeti VG-be, hozd létre a filerendszert, aztán backupból töltsd vissza az adatokat".

Na ez pont az amit nem akarunk :) (Meg ez a blog bejegyzés se született volna akkor meg).. A mi célunk, hogy az adatokat élve visszaszerezzük. A hogyan már jobb kérdés. Ami tiszta az az, hogy az új VG-ben nem maradhat a PV, úgy hogy onnan szedjük ki, aztán meg a VIO-ról szedjük le a LUN allokációt, hogy csak a source szerveren legyen a PV elérhető.

A következő "elméleti" lépés pedig az lenne, hogy rakjuk vissza a VGDA-t az érintett PV alá..
Ennek kivitelezése némi kis elméleti háttérismeretet igényel:
- AIX alatt minden VG felépítése azonos (az elmélet legalább is, a kivitelezésben vannak némi eltérések)
- Minden VG-ben lévő PV tartalmazza a VGDA-t (A PV elején), amely leírja, hogy a VG alatt pontosan milyen PVID-jű diszkek találhatók, azokon belül melyik PV-n milyen LV-k (és milyen kiosztásban) helyezkednek el, van e LV tükrözés (mirroring), és hasonló úri huncutságok.
- Ergo a dolog szépsége, hogy mindenki tud többé kevésbé mindenkiről mindent, 1-2 dolgot leszámítva, és csak 1-2 alapvető dolog különbözik

# Megjegyzem azért, hogy van a VGDA-ban 1-2 olyan adat is, ami meglehetősen szemétnek minősül és PV-nként eltérhet, de azokkal most nem fogok foglalkozni
Na szóval a feladat a következő: Fogjunk a VG-ből egy egészséges diszket, pakoljuk át a VGDA-ját a hibás PV-re, írjuk át azt ami PV specifikus, aztán imádkozzunk, hogy minden menni fog

!!! Had ne mondjam, hogy ez a módszer véletlenül és semmilyen körülmény között sem támogatott hivatalosan, így ha valakinek van IBM-es szerződése az inkább nyisson PMR-t ha tényleg fontos adatról van szó!!!

Akkor kezdjük az első lépést.. VGDA átmásolás.. Hogy ezt meg tudjuk csinálni 1x is tudnunk kell a VGDA méretét, ez viszont VG típusonként más, úgy hogy tudni kell a VG típusát is :) Ehhez kell egy VG-n belüli PV, amin még minden rendben van, legyen ez mondjuk a hdisk2 (mert csak, amúgy bármelyik másik jó lenne)

server1:root:[/] # readvgda /dev/hdisk2 |grep type
.....    readvgda_type: smallvg
vgtype:         0

# Némi kis segítség a VGDA méretének megállapításában:
# Small VG: 17x 128K
# Big VG: 71x 128K
# Scalable: 548x 128K

Jó.. Most hogy tudjuk mi és merre csináljunk egy backupot a jelenlegi VGDA-ról (igen, amit előzőleg nulláztunk, de akkor is legyen lehetőség visszaállítani ami volt), aztán vágjuk is felül :)

server1:root:[/] # dd if=/dev/hdisk7 of=/tmp/hdisk7.smallvg.vgda.save bs=128K count=17
17+0 records in
17+0 records out
server1:root:[/] # dd if=/dev/hdisk2 of=/dev/hdisk7 bs=128K count=17
17+0 records in
17+0 records out

A következő egyedi azonosító a PV ID-ja lenne (nem összekeverendő a PVID-val), ami megmondja, hogy az adott diszk hányadik is a VG-n belül. Ehhez első körben meg kell keresni, hogy az adott adat hol is tárolódik (VG-nként máshol, de mindig az LVM leíró környékén). Én általában az első 1000 szektorcsoportot keresem végig:

server1:root:[/] # lquerypv -h /dev/hdisk2 0 1000 |grep LVM
00000E00   5F4C564D 00C5EFFD 00004C00 0000010D  |_LVM......L.....|

Szupi.. Tehát 0E00 körül keződidik az LVM leíró része.

Akkor most nézzük meg mi van azon a környéken:
server1:root:[/] # lquerypv -h /dev/hdisk2 e00 40
00000E00   5F4C564D 00C5EFFD 00004C00 0000010D  |_LVM......L.....|
00000E10   A807DA15 00001074 00000832 00000088  |.......t...2....|
00000E20   000008C2 013FFEFF 00000100 00010019  |.....?..........|  
00000E30   00000008 00000080 000008BA 001E0000  |................|

Na most ebből lehet nem sok derül ki annak aki nem tudja mit keressen, de ha összenézzük ugyan ezt a többi diszk VGDA-jával, akkor remélhetőleg már könyebben rájön mindenki hol is van a kutya elásva:

server1:root:[/] # for i in $(lsvg -p appvg |grep -v hdisk7 |awk '/hdisk/{print $1}');do echo $i;lquerypv -h /dev/$i e00 40;done
hdisk2
00000E00   5F4C564D 00C5EFFD 00004C00 0000010D  |_LVM......L.....|
00000E10   A807DA15 00001074 00000832 00000088  |.......t...2....|
00000E20   000008C2 013FFEFF 00000100 00010019  |.....?..........|  <= '0001' a 0x0E2C címnél
00000E30   00000008 00000080 000008BA 001E0000  |................|
hdisk3
00000E00   5F4C564D 00C5EFFD 00004C00 0000010D  |_LVM......L.....|
00000E10   A807DA15 00001074 00000832 00000088  |.......t...2....|
00000E20   000008C2 063FFEFF 00000100 00020019  |.....?..........|  <= '0002' a 0x0E2C címnél
00000E30   00000008 00000080 000008BA 001E0000  |................|
hdisk4
00000E00   5F4C564D 00C5EFFD 00004C00 0000010D  |_LVM......L.....|
00000E10   A807DA15 00001074 00000832 00000088  |.......t...2....|
00000E20   000008C2 031FFEFF 00000100 00030019  |................|  <= '0003' a 0x0E2C címnél
00000E30   00000008 00000080 000008BA 001E0000  |................|
hdisk5
00000E00   5F4C564D 00C5EFFD 00004C00 0000010D  |_LVM......L.....|
00000E10   A807DA15 00001074 00000832 00000088  |.......t...2....|
00000E20   000008C2 03BFFEFF 00000100 00040019  |................|  <= '0004' a 0x0E2C címnél
00000E30   00000008 00000080 000008BA 001E0000  |................|
hdisk6
00000E00   5F4C564D 00C5EFFD 00004C00 0000010D  |_LVM......L.....|
00000E10   A807DA15 00001074 00000832 00000088  |.......t...2....|
00000E20   000008C2 013FFEFF 00000100 00050019  |.....?..........|  <= '0005' a 0x0E2C címnél
00000E30   00000008 00000080 000008BA 001E0000  |................|

Ha megfigyelitek, akkor az VGDA leírók ezen része szinte teljesen egyezik, kivétel a 0x0E2D címen lévő érték, ami szépen növekszik 1től 5ig.. Na most ha még emlékeztek a post elejére, akkor 6 PV volt hivatalosan ebben a VG-ben:

server1:root:[/] # readvgda /dev/hdisk2 |grep pv_id |cat -n
     1  pv_id:          00c5effd7c2e18d2
     2  pv_id:          00c5effd70395ab2
     3  pv_id:          00c3b9f4aeed3ccd
     4  pv_id:          00c3b9f4e1709f60
     5  pv_id:          00c3b9f47a309de6
     6  pv_id:          00c3b9f4b2a59c9b 

Tehát, a PV ID (!=PVID) a hiányzó diszkünknél a 6os lesz, amit vissza is kéne írni a megfelelő pontra.. dd-vel ez megoldható, de ahhoz decimálisan tudnunk kell a pontos poziciót:

server1:root:[/] # echo "ibase=16; E2D" |bc
3629

3629.. Jó. Akkor írjuk is be a helyére a megfelelő értéket:

server1:root:[/] # echo "\06" | dd of=/dev/hdisk7 bs=1 count=1 seek=3629
1+0 records in
1+0 records out

Ez után jön akkor a tényleges PVID. Ha még emlékeztek, akkor erre anno mutattam is egy módszert, amit ismét elő is szedek, és visszaírom az eredetileg a PV-n lévő PVID-t:

A script maga:

server1:root:[/] # cat /tmp/chpvid.sh
#!/usr/bin/ksh
pvid=$1
disk=$2
set -A a `echo $pvid|\
awk ' {
 for (f=1; f <= length($0); f=f+2) {
 print "ibase=16\nobase=8\n"toupper(substr($0,f,2))
 }
}'|\
bc 2>/dev/null`
/usr/bin/echo "\0"${a[0]}"\0"${a[1]}"\0"${a[2]}"\0"${a[3]}"\0"\
${a[4]}"\0"${a[5]}"\0"${a[6]}"\0"${a[7]}"\0\0\0\0\0\0\0\0\c"|\
dd bs=1 seek=128 of=/dev/$disk

A futtatás módja:

server1:root:[/] # sh /tmp/chpvid.sh 00c3b9f4b2a59c9b hdisk7
16+0 records in
16+0 records out

Visszaellenőrzés:

server1:root:[/] # od -A n -j 128 -N 8 -x /dev/hdisk7
         00c3 b9f4 b2a5 9c9b

VGDA ellenőrzés:

server1:root:[/] # for i in $(lsvg -p appvg |awk '/hdisk/{print $1}');do echo "$i \c";readvgda /dev/$i|grep vg_id;done    
hdisk2 vg_id:           00c5effd00004c000000010da807da15
hdisk3 vg_id:           00c5effd00004c000000010da807da15
hdisk4 vg_id:           00c5effd00004c000000010da807da15
hdisk5 vg_id:           00c5effd00004c000000010da807da15
hdisk6 vg_id:           00c5effd00004c000000010da807da15
hdisk7 vg_id:           00c5effd00004c000000010da807da15

Még mielött tényleg bármit is csinálnánk nézzük meg, hogy minden tényleg úgy van ahogy volt:

server1:root:[/] # lsvg -p appvg
appvg:
PV_NAME           PV STATE          TOTAL PPs   FREE PPs    FREE DISTRIBUTION
hdisk2            active            319         0           00..00..00..00..00
hdisk3            active            1599        0           00..00..00..00..00
hdisk4            active            799         0           00..00..00..00..00
hdisk5            active            959         0           00..00..00..00..00
hdisk6            active            319         32          00..00..00..00..32
hdisk7            missing           447         127         90..00..00..00..37

Aztán térdre imára, és varyon-oljuk vissza a VG-t:

server1:root:[/] # varyonvg appvg
server1:root:[/] # lsvg -p appvg
appvg:
PV_NAME           PV STATE          TOTAL PPs   FREE PPs    FREE DISTRIBUTION
hdisk2            active            319         0           00..00..00..00..00
hdisk3            active            1599        0           00..00..00..00..00
hdisk4            active            799         0           00..00..00..00..00
hdisk5            active            959         0           00..00..00..00..00
hdisk6            active            319         32          00..00..00..00..32
hdisk7            active            447         127         90..00..00..00..37

Hoppá... alakul a molekula :) Nézzük mi van szeretett filerendszerünkel:

server1:root:[/] # mount /app_fs
Replaying log for /dev/applv.
mount: /dev/applv on /app_fs_rest: Unformatted or incompatible media
The superblock on /dev/applv is dirty.  Run a full fsck to fix.

Na jó.. ez várható volt.. Adjuk meg amit kér:

server1:root:[/] # fsck /dev/applv
The current volume is: /dev/applv
Primary superblock is valid.
*** Phase 1 - Initial inode scan
*** Phase 2 - Process remaining directories
*** Phase 3 - Process remaining files
*** Phase 4 - Check and repair inode allocation map
*** Phase 5 - Check and repair block allocation map
File system is clean.
Superblock is marked dirty; FIX? y
All observed inconsistencies have been repaired.

Aztán próbáljuk meg újra:

server1:root:[/] # mount /app_fs
server1:root:[/] # 

Profit :))

Mickey egér, HACMP, meg a többiek..

Némileg úgy érzem most magam, mint ahogy régen a BBC stábja érezhette magát, amikor is 1946ban (állítólag, bár egyesek szerint ez is kacsa) ismét ott folytatták az ominózus Mickey Mouse történetet, ahol anno 1939 Szeptember 1.-jén abbahagyták.

Ok, némileg túlzó a kép, de azért nekem is volt 1-2 komolyabb harcom az elmúlt 1-2 hónapban, munkahely váltás, költözés külföldre, meg ami vele jár.. Szóval nem volt eseménytelen az elmúlt időszak, ami sajna a blog rovására is ment láthatólag.
Na de viszont most megpróbálom azt amit anno a BBC-sek is - folytatni ahol abbamaradt minden, mintha misem történt volna..

Na szóval.. Aktuális problémánk tárgya egy HACMP-s node, ahol a clcomdES daemon fölött elkezdtek körözni a keselyűk, ugyan is ránézésre halottnak nézett ki..
Az AIX kommandó az újraélesztést megkezdte, de a beteg nem reagált a kezelésre:

[server:root:/home/root:] lssrc -s clcomdES
Subsystem         Group            PID          Status 
 clcomdES         clcomdES                      inoperative
[server:root:/home/root:] startsrc -s clcomdES
0513-059 The clcomdES Subsystem has been started. Subsystem PID is 7033284.
[server:root:/home/root:] 
[server:root:/home/root:] lssrc -s clcomdES   
Subsystem         Group            PID          Status 
 clcomdES         clcomdES                      inoperative

Az orvosi lapot átnézve kiderült, hogy betegünk valószínű még is él, csak vagy kómába esett, vagy önmagán kívül van:

[server:root:/:] tail -1 /var/hacmp/clcomd/clcomd.log 
Mon Jan 28 15:03:18 2013: bind (../../../../../../../src/43haes/usr/sbin/cluster/clcomd/clcomd.c:5533): Address already in use

Persze minderről a hatóságok semmit nem tudtak..

[server:root:/var/hacmp/clcomd:] ps -ef |grep clcom 
    root 5480538 7143926   0 15:05:31  pts/1  0:00 grep clcom 

.. csak annyit, hogy a clcomdES által gyakran használt erőforrásokat valami tényleg épp fogja:
# Kis magyarázat: a clcomdES által használt default port a 6191

[server:root:/var/hacmp/clcomd:] netstat -Aan |grep 6191 |grep LISTEN
f10006000243c398 tcp4       0      0  *.6191             *.*                LISTEN

Ilyenkor általában csak odasétál az ember az illetékes besúgóhoz, megkéri hogy mondja már meg ki jár rá a dugi csokira, de szomorúan kell konstatáljuk, hogy halvány lila fogalma nincs:

[server:root:/var/hacmp/clcomd:] rmsock f10006000243c398 tcpcb
getprocdata: malloc failed

Na jó... Ha a szokványos eszközök nem mennek, akkor tényleg muszáj lesz nekünk is bemocskolnunk a kezünk, és megnézni hogy a Disc-réten mi ROMolhatott el..

Kezdjük is a kernellel, ha már a gyanúsítgatásnál tartunk ("Ahol a kormány, ott van a gáz.."). Aki olvasta eddig a blogomat annak ez a fordulat azt hiszem nem lesz komolyabb meglepetés :)
Akinek még is, annak javaslom az itt emlegetett módszerek és parancsok áttanulmányozását a folytatás előtt

Na szóval.. a netstat megsúgta nekünk, hogy a f10006000243c398-es dugi csokira jár rá a kis szellemünk, úgy hogy kezdjünk el az után nyomozni első körben:

[server:root:/var/hacmp/clcomd:] kdb
(0)> ns
Symbolic name translation off
(0)> si f10006000243c398 tcpcb |grep ACTIVE
F100070F01012000 16456*clcomd   ACTIVE 004812E 0031166 00000003184E1400   0 0014

(0)> proc F100070F01012000 |head
              SLOT NAME     STATE      PID    PPID          ADSPACE  CL #THS

F100070F01012000 16456 clcomd   ACTIVE 004812E 0031166 00000003184E1400   0 0014

Hoppá.. Tehát a socketet még is csak egy clcomd fogja, de akkor miért nem vették észre a nyomozó kollégák??

(0)> hcal 004812E
Value hexa: 0004812E          Value decimal: 295214

[server:root:/:] ps -fp 295214
     UID     PID    PPID   C    STIME    TTY  TIME CMD
       -  295214       -   -                     - <exiting>

Ja kérem.. Ez itt egy megrendezett öngyilkossággal egybekötött biztosítási csalás.. Na keressük meg a cinkosokat:

(0)> proc F100070F01012000 |grep THREAD
THREAD..... threadlist :F100070F10807300 
THREAD..... threadcount:00000014  ........... active     :00000002

(0)> th F100070F10807300 |head
                SLOT NAME     STATE    TID PRI   RQ CPUID  CL  WCHAN

F100070F10807300 32883  ZOMB  0731E3 03C    0         0  

NAME................ 
WTYPE............... WZOMB    
.................tid :00000000000731E3  ......tsleep :FFFFFFFFFFFFFFFF
...............flags :00000000  ..............flags2 :00000000
...........pmcontext :00000000
DATA.........pvprocp :F100070F01012000 

Hoppá.. Nekromancia, vagy mifene? Ki mozgatja a szálakat?

(0)> th F100070F10807300 |grep prev 
LINKS.....prevthread :F100070F10008C00 
LINKS.....prevthread :0000000000000000

(0)> th F100070F10008C00 |head
F100070F10008C00  140 clcomd   SLEEP 08C029 03C    4         0  F100070F010121B8 

Jó.. 1 megvan.. Vannak még?

(0)> th -n clcomd
                SLOT NAME     STATE    TID PRI   RQ CPUID  CL  WCHAN

F100070F10007C00  124 clcomd   SLEEP 07C0ED 03C    4         0  F1000110129D9A70 01125380 
F100070F10008C00  140 clcomd   SLEEP 08C029 03C    4         0  F100070F010121B8 

Aham.. szóval 2 fő process, 1-1 threaddel.. Na és ők épp mit csinálnak?

(0)> f F100070F10008C00
pvthread+008C00 STACK:
[0005EEF4]ep_sleep+000128 (0000000000056DA0, A0000000000090B2 [??])
[0014384C]kexitx+000F6C (??)
[0015AAD8]kexit+000080 ()
[kdb_get_virtual_memory] no real storage @ FFFFFFFF3FFFE40

(0)> f F100070F10007C00
pvthread+007C00 STACK:
[002FF8C0]slock+0006A4 (00000000002E0268, 80000000000090B2 [??])
[00009558].simple_lock+000058 ()
[002CB3D0]j2_rename+000188 (??, ??, ??, ??, ??, ??, ??)
[00408C34]vnop_rename+0002B4 (??, ??, ??, ??, ??, ??, ??)
[0046A8F4]rename+00030C (??, ??)
[0486570C]my_rename+0001C4 (0000000020023728, 00000000200C149C)
[00003810].svc_instr+000110 ()
[kdb_get_virtual_memory] no real storage @ 200C0FD8
[10013190]log_printf+0002FC (00000000, 00000000, 00000000, 00000000,
   00000000, 00000000, 00000000, 00000000)

Az egyik épp ki akar lépni, de azért még vár egy kicsit (tapsra talán, meg nem mondom), de a másik már érdekesebb: Ott a jelek szerint épp valami JFS2-es FS alatt volt valami átnevezősdi, ami valahogy még is csak megbicsaklott..
És hiába tűnt ez az elején HACMP hibának, a bizonyítékok alapján ez inkább tűnik AIX issue-nak.. A pénz csak pénz, a stack az meg csak stack na..
Azok alapján meg az ügy erősen hajaz az alábbi hibák egyikére:
- IZ96928
- IZ40258
Na most ha megnézitek, akkor azért ezek a bűnügyi megelőző kezelések nem épp a legfrissebben szabadult bűnözőkre lettek kitalálva (avagy jó régi patchekről van szó).. Úgy hogy ha már itt tartunk nézzük már meg, hogy ezt a drágát melyik korból szalajthatták?

[server:root:/:] oslevel -s
5300-08-08-0943

Jah.. Jó.. Ez a TL/SP még anno 2009 Novemberében lett kiadva.. Az se ma volt.. Had ne mondjam azóta mennyi fix kijött, jah meg az 5.3as AIX hivatalos supportja is lejárt 2012 Áprilisában.
Na szóval itt rendesen el vannak egyesek maradva.. És hiába kérdezik meg az SWG-sek (software group) hogy tuti minden patch fent van e, attól még a hülye AIX admin csak abból főzhet amit a konyhában talál (amíg ki nem derül, hogy a Műanyag tálba lévő melegítendő kaját lehet még sem a sütőn kellett volna megpróbálni felmelegíteni).

Tanulság: Ha tetszik, ha nem tessék már azokat a rohadt rendszereket frissíteni (és nem csak a security miatt)

HACMP failover issue - Unable to unmount the filesystem

Az ember egy idő után már hajlamos azt hiszi, hogy azért nem lehet könnyen meglepni, ha már egy csomó szívást átélt, meg már a kdb-s bugyrokat is megjárta.. Hiába tudjuk, hogy Murphy csak az ilyen jelekre vár, mindig azt hisszük, hogy fel tudjuk venni vele a kesztyűt.. Aztán az ember szembe kap egy általánosnak tűnő problémát, elkezdi a saját kis módján investigálni, majd akkor koppan amikor rájön, hogy valami mégse úgy megy ahogy kéne, vagy valami még így is van amire nem gondolt előzőleg.

Ez se volt most másként.. Felhívtak kollégák, hogy lenne egy HACMP failover probléma: Szegény RG nem tud átállni, és meg kéne már nézni, hogy mi a rákért nem..
Hát jó.. hacmp.out túrás , és elég gyorsan szembejön az első gyanús jel:

***************************
Nov 3 2012 19:42:13 !!!!!!!!!! ERROR !!!!!!!!!!
***************************
Nov 3 2012 19:42:13 cl_deactivate_vgs: Failed varyoff of appvg.

Aham.. na jó.. nézzük mi van még itt, ami miatt ez előjöhetett:

+app_rg:cl_deactivate_vgs(5.910):appvg[vgs_varyoff+282] varyoffvg appvg
0516-012 lvaryoffvg: Logical volume must be closed.  If the logical
        volume contains a filesystem, the umount command will close
        the LV device.
0516-942 varyoffvg: Unable to vary off volume group appvg.

Ahh.. haladunk.. Mi törpént az FS-el?

+app_rg:cl_deactivate_fs(.160)[fs_umount+58] umount /var/mqm/RGmount
umount: error unmounting /dev/RG_LV: Device busy
+app_rg:cl_deactivate_fs(2.160)[fs_umount+66] : At this point, unmount of /var/mqm/RGmount has not worked. So,
+app_rg:cl_deactivate_fs(2.160)[fs_umount+67] : Send a SIGKILL to all processes having open file
+app_rg:cl_deactivate_fs(2.160)[fs_umount+68] : descriptors within this logical volume to allow
+app_rg:cl_deactivate_fs(2.160)[fs_umount+69] : the umount to succeed.
+app_rg:cl_deactivate_fs(2.160)[fs_umount+71] date '+%h %d %H:%M:%S.000'
Nov 03 19:38:46.000
+app_rg:cl_deactivate_fs(2.160)[fs_umount+72] fuser -k -u -x /dev/RG_LV
/dev/RG_LV:   782460(wasRGuser)  782460(wasRGuser)  868596(wasRGuser)  868596(wasRGuser)  938078(wasRGuser)  938078(wasRGuser) 1081448(wasRGuser) 1081448(wasRGuser)
+app_rg:cl_deactivate_fs(2.740)[fs_umount+73] fuser -c -k -u -x /var/mqm/RGmount
/var/mqm/RGmount:
+app_rg:cl_deactivate_fs(3.260)[fs_umount+74] date '+%h %d %H:%M:%S.000'
Nov 03 19:38:47.000
+app_rg:cl_deactivate_fs(3.260)[fs_umount+77] : Wait 2 seconds for the kills to be effective
+app_rg:cl_deactivate_fs(3.260)[fs_umount+79] sleep 2
+app_rg:cl_deactivate_fs(5.260)[fs_umount+82] : Unmount of /var/mqm/RGmount failed. If the force option can be used, try it here.
+app_rg:cl_deactivate_fs(5.260)[fs_umount+84] [[ -n '' ]]
+app_rg:cl_deactivate_fs(5.260)[fs_umount+99] (( 0 == 57 ))
+app_rg:cl_deactivate_fs(5.260)[fs_umount+123] (( 0 == 60 ))
+app_rg:cl_deactivate_fs(5.260)[fs_umount+52] ((count++ ))
+app_rg:cl_deactivate_fs(5.260)[fs_umount+52] (( count <= 60))
+app_rg:cl_deactivate_fs(5.260)[fs_umount+55] : Try to unmount the file system
+app_rg:cl_deactivate_fs(5.270)[fs_umount+56] date '+%h %d %H:%M:%S.000'
+app_rg:cl_deactivate_fs(5.270)[fs_umount+56] : Attempt 2 of 61 to unmount at Nov 03 19:38:49.000
+app_rg:cl_deactivate_fs(5.270)[fs_umount+58] umount /var/mqm/RGmount
umount: error unmounting /dev/RG_LV: Device busy.

Ez a fázis már az application stop után van, ergo a HACMP joggal van felháborodva, hogy miért nem szabad már a device, ha ő azt át akarja adni a másik node-na.. Sebaj, 5.3 óta fel van készítve a HA erre is, gyenge fuser -kux az LV-re megoldja.. fuser -ckux után látszik, hogy tényleg nem maradt process ami használná az FS-t, úgy hogy semmi gáz, mehet az umount..
De álj.. Megint device busy?? Na innen indul a vicces rész.. Főleg amikor az ember eljut a logban eddig:

+app_rg:cl_deactivate_fs(194.630)[fs_umount+56] : Attempt 61 of 61 to unmount at Nov 03 19:41:58.000
+app_rg:cl_deactivate_fs(194.630)[fs_umount+58] umount /var/mqm/RGmount
umount: error unmounting /dev/RG_LV: Device busy
+app_rg:cl_deactivate_fs(194.760)[fs_umount+66] : At this point, unmount of /var/mqm/RGmount has not worked. So,
+app_rg:cl_deactivate_fs(194.760)[fs_umount+67] : Send a SIGKILL to all processes having open file
+app_rg:cl_deactivate_fs(194.760)[fs_umount+68] : descriptors within this logical volume to allow
+app_rg:cl_deactivate_fs(194.760)[fs_umount+69] : the umount to succeed.
+app_rg:cl_deactivate_fs(194.760)[fs_umount+71] date '+%h %d %H:%M:%S.000'
Nov 03 19:41:58.000
+app_rg:cl_deactivate_fs(194.770)[fs_umount+72] fuser -k -u -x /dev/RG_LV
/dev/RG_LV:
+app_rg:cl_deactivate_fs(195.300)[fs_umount+73] fuser -c -k -u -x /var/mqm/RGmount
/var/mqm/RGmount:
+app_rg:cl_deactivate_fs(195.810)[fs_umount+74] date '+%h %d %H:%M:%S.000'
Nov 03 19:41:59.000
+app_rg:cl_deactivate_fs(195.810)[fs_umount+77] : Wait 2 seconds for the kills to be effective
+app_rg:cl_deactivate_fs(195.810)[fs_umount+79] sleep 2
+app_rg:cl_deactivate_fs(197.810)[fs_umount+82] : Unmount of /var/mqm/RGmount failed. If the force option can be used, try it here.
+app_rg:cl_deactivate_fs(197.810)[fs_umount+84] [[ -n '' ]]
+app_rg:cl_deactivate_fs(197.810)[fs_umount+99] (( 60 == 57 ))
+app_rg:cl_deactivate_fs(197.810)[fs_umount+123] (( 60 == 60 ))
+app_rg:cl_deactivate_fs(197.810)[fs_umount+126] : Out of retries to unmount /var/mqm/RGmount. Game over, man, game over.
+app_rg:cl_deactivate_fs(197.810)[fs_umount+128] cl_echo 25 'cl_deactivate_fs: Failed umount of /var/mqm/RGmount.\n' cl_deactivate_fs /var/mqm/RGmount

A "Game over, man, game over" kedves kis üzenet a fejlesztőktől, és meg meg is mosolyogtatna ha nem látnám, hogy szegény HA-m 61x próbálta meg lenyomni a szerencsétlen FS-t de mind végig Device busy-t kapott.

OS oldalról elnézve az FS valóban ott van a mount alatt, és ha én akarom leszedni akkor ugyan azt kapom:

server@root:/ # mount |grep RGmount
         /dev/RG_LV     /var/mqm/RGmount   jfs2   Nov 03 19:22 rw,log=INLINE
server@root:/ # fuser -cux /dev/RG_LV
server@root:/ # umount /var/mqm/RGmount
umount: 0506-349 Cannot unmount /dev/RG_LV: The requested resource is busy.

Na akkor áljunk meg itt picit.. Mi az amit érdemes megnézni ilyenkor?
- Használja e valami az FS-t

- Megtettem, nem dobott semmit..

- Haszmálja e az LV-t valami?

- Ez az amit a HACMP is megnézett, és aminek amúgy több értelme is van, mint az FS-t nézni -> van 1-2 olyan parancs ami az LV-ket cseszteti direktben, ergo ha a /dev/LV-re ráengedünk egy fuser-t akkor azokat is meg tudjuk fogni.. A HA 1x ezeket le is gyilkolta, viszont utána már nem talált semmit

- Nincs e submount az adott FS alatt

- Amennyiben egy másik FS van a lemountolandó alá felhúzva, úgy persze, hogy a kernel nem engedi nekünk az umountot (Ilyenkor a submountot kell első körben leszedni). Ezt könnyen ellenőrizhetjük is a mount paranccsal, de itt sajna ez se játszik, mivel nem volt egy submount se

- AIO/CIO használatban van?

- Ezen a rendszeren konkrétan pont egyik sincs, viszont ezek is képesek ilyen szintű lockokat összehozni. Viszont a HA épp ezért is próbálkozik 61x (ami itt közel 3 percig ment is), hogy az ilyen dolgokkal se legyen gáz, ha ne adj isten az AIO/CIO nem volt elég gyors adott pillanatban. Mint látható ez itt szintén nem jött be.

- Named Pipe?

- Egzotikum, viszont nem szabad figyelmen kívül hagyni.. Alapvetően Inter-process communication célokra szolgál olyan esetekben ahol a jogosultság szeparáció nem teszi lehetővé a normális IPC kommunikációt direkt memórián keresztül (Hozzáteszem, hogy ez inkább a régebbi appoknál bevett eljárá. Az AIX jó ideje tud direktben memóriában adatot átadni különböző jogosultsági szinteken futó alkalmazásoknak Shared Memory-n keresztül (szintén az IPC része). Ilyen esetekben az applikáció képes egy ilyen "pipe" file-t létrehozni, és sima chmod-os/ACL-es megoldással másik user alatt futó applikációnak átadni az adatot direktben. A probléma ezekkel viszont annyi, hogy nincs tényleges file írás/olvasás, mivel az egész hóbelebancot az AIX memórián belül képes lezongorázni, így meg a fuser se veszi észre, hogy a háttérben szopatják a népet, mivel az fopen/fwrite/fclose és hasonló eventekre figyel főként.

Persze kérdés, hogy hogy járunk ezeknek utána.

- Egyik módszer a http://p1ngw1n.blogspot.hu/2012/02/fuser-nemileg-maskent.html-ban felvázolt módszer

- Másik meg az lsof :)

Mivel az első módszert anno már lefedtem, így maradjunk az egyszerűbbnél, és nézzük, hogy az lsof-el mit is látunk ilyenkor :)

server@root:/ # lsof |grep /var/mqm/RGmount
runmqlsr_  933958 wasRGuser    6u  unix              35,13                0t0 5255524237690535936 /var/mqm/RGmount/qmgrs/APILOT!PRT!QMGR/@qmpersist/spipe/ccc.933958
runmqlsr_  933958 wasRGuser    9u  unix 0xf100020000837c08             0t1728                     /var/mqm/RGmount/qmgrs/APILOT!PRT!QMGR/@qmpersist/spipe/pmpipe
runmqlsr_  933958 wasRGuser   12u  unix 0xf100020000736408             0t1852                     /var/mqm/RGmount/qmgrs/APILOT!PRT!QMGR/@qmpersist/spipe/pmpipe
amqzmgr0  1093830 wasRGuser    8u  unix              35,13                0t0 5255524237690535936 /var/mqm/RGmount/qmgrs/MQRG/@qmpersist/spipe/pmpipe
amqzmgr0  1200368 wasRGuser    8u  unix              35,13                0t0 5255524237690535936 /var/mqm/RGmount/qmgrs/APILOT!PRT!QMGR/@qmpersist/spipe/pmpipe
runmqlsr_ 1605678 wasRGuser    6u  unix              35,13                0t0 5255524237690535936 /var/mqm/RGmount/qmgrs/MQRG/@qmpersist/spipe/ccc.1605678
runmqlsr_ 1605678 wasRGuser    9u  unix 0xf100020002275408             0t1728                     /var/mqm/RGmount/qmgrs/MQRG/@qmpersist/spipe/pmpipe
runmqlsr_ 1605678 wasRGuser   12u  unix 0xf100020001ee7808             0t1852                     /var/mqm/RGmount/qmgrs/MQRG/@qmpersist/spipe/pmpipe

BINGO.. Innen már akkor csak akkor gyilkolásznunk kell :)

server@root:/ # kill -9 933958 1093830 1200368 1605678
server@root:/ # umount /var/mqm/RGmount
server@root:/ #

Innen pedig tovább lehet akkor lökni a HA-t is a túloldalra

A történet tanulsága:
- lusta embereknek kötelező az lsof (az experteknek meg a kdb :))
- A HACMP (attól függetlenül, hogy az idők során szinte mindenre próbálták felkészíteni) se tud mindent lekezelni
- A fejlesztőknek is van humora :)
- Murphy lehet, hogy köcsög mindig, de valahogy még is az ilyen szívásokkal tanulja meg az ember, hogy mennyire is halandó, és lényegében így tanulja csak meg azokat a leckéket, amikre más nem lenne képes megtanítani (se iskola, se oktatás, se certifikációk)

Ami a nagykönyvben nincs leírva..

Vannak helyzetek, amikor az ember elkezd azon agyalni, hogy a hivatalos utakon kívűl vannak e mások is.. Utak, amiken szintén el lehet indulni, és amin keresztül el lehet jutni A-ból B pontba.. Lehetőleg még gyorsabban is, vagy kevésbé fájdalmasan 1-1 issue alkalmával..
És vannak alkalmak amikor az ember igen is az ilyen utakon akar járni, főleg ha rájön, hogy azok sokkalta kifizetődőbbek, mint a hivatalosak. Na ez az eset pontosan ilyen volt :)

A szituáció adott: Van egy JFS2 filesystem, kellemes kis 2 TB-os mérettel, alatta "egy pár" LUN-al (diszkkel), és egy csúnya üzenettel az errpt-ben, miszerint:

server # errpt |head -2
IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION
E86653C3   0723123112 P H LVDD           I/O ERROR DETECTED BY LVM

Nem kell sokat találgatnotok -> Igen, az az I/O error az adott 2 TB-os FS-re jött.. Tekintve, hogy az FS DS8K-s LUN-okra építkezik így ez még viccesebbé teszi a helyzetet, mivel ez csak az alábbi scenario-k között jöhet létre:
- Disk management issue (ez esetben a driver szopat)
- Fibre adapter issue (már ha nincs normális redundancia)
- Disk locking issue (ha ne adj isten a LUN több helyre van kizónázva, és más is használja az adott LUN-t, főleg ha még írni is akar rá)
- SAN box oldali issue (a DS oldali kötet hibás ottani adapter, vagy diszk hiba miatt)

Egyik se kellemes, mit ne mondjak..
Az első amit ilyenkor tudnunk kell, hogy a hiba milyen körülmények között jön elő. Jelen esetben annyit kell még tudni, hogy csak 1 LUN-ja jött a hiba, de arra állandóan, így az első 2 hibalehetőséget nyomban ki is lehet zárni (a driver CSAK 1 diszket nem köhög meg, hanem akkor konzisztensen szívatja az összeset, a HBA meg dettó nem hajlamos kispécizni magának LUN-okat :)).

A másik 2 lehetőség felderítéséhez meg a Storage szerveren kell turkálni ami meg jelen esetben másik team hatásköre volt, ám némi kis nyomozás után kiderült, hogy a zónázással nincs gond, viszont a kiosztott LUN alatt lévő fizikai réteg bizony kehés, ergo azt ők gyorsan orvosolják..

Egy részről ez jó mert egy elég komoly hibát sikerül megoldani, más részről viszont kliens oldalon (igen, nálam) még mindig ott az a fránya kis probléma, minek eredete, hogy nem férek hozzá az adatomhoz, és esélyes, hogy a javítás után se tudnék, ergo ezt nekem is valahogy orvosolni kéne..

A kérdés persze, hogy hogyan.. A probléma ugyan is az, hogy van minimum 1 blokkom a diszken, amit garantáltan nem tudok olvasni, azt kitiltani nem tudom, migrálni szintúgy nem (pont az olvasási hiba miatt), szóval 2 szék között sikerült a pad alá kerülnöm.. Ilyen esetben a hivatalos megoldás az lenne, hogy töröljem az FS-t, hozzam létre újra (és figyeljek, hogy az a LUN véletlenül se legyen ismét része az új FS-nek), majd backup-ból restore-oljam.. Ok, de 2 TB adatról beszélünk, a restore sok idő, a downtime meg drága..

Így hát adott a kérdés - hogy a francba minimalizáljuk a downtime-ot? Ez a kis leírás kb egy scenario-t mutat be arra amit sikerült kiötlenem :)

Na szóval.. Mondtam, hogy a migrálás zsákutca.. Ezt persze nem hasra ütés alapján merem kijelenteni, hanem fájdalmas tapasztalatból, ugyan is sikerült így járjak az adott LUN-al:

server # migratepv vpath59 vpath91
0516-076 lmigratelv: Cannot remove last good copy of stale partition.
Resynchronize the partitions with syncvg and try again.
0516-812 migratepv: Warning, migratepv did not completely succeed;
all physical partitions have not been moved off the PV.

őő.. Egen.. Egy próbát megért, be is bukott.. (akinek a vpath nem lenne ismerős -> tekintve, hogy DS-ről beszélünk, így SDD driver megy az AIX alatt, ami meg hdisk-ek helyett vpath-okat használ) Megnézve a VG/LV adatokat meg ilyen randaságok jöttek szembe:

server # lsvg -l appvg |grep applv
0516-1147 : Warning - logical volume applv may be partially mirrored.
applv         jfs2       8192    9216    9    open/stale    /appdata

A VG PP size-a 256 MB, az FS pont 2 TB (8192 PP), és 9216 PP-nyi hely van felhasználva, tekintve, hogy az egyik PV-t épp át akartuk migrálni egy 9. 256 GB méretű LUN-ra (ami alapjáraton a LUN mirrorozását jelenti). Sajna a partíció open/stale helyzetben van, és ezen egy syncvg se segít

server # syncvg -l applv
0516-934 /usr/sbin/syncvg: Unable to synchronize logical volume applvg.

Ez a helyzet már magában is vicces, mivel nyomban plusz egy problémát hoz be a képbe, miszerint "Hogy a francba szedjem le a mirrort arról a LUN-ról".. unmirrorvg nem segít, az teljes VG-re van, rmlvcopy se, mert az meg teljesen kimirrorozott LV-re használható csak (itt meg csak 2 PV van "mirrorban" a 9ből), más hivatalos módszer meg nincs (vagy csak nekem nem jut eszembe)..

Ha viszont még valaki emlékszik, akkor én írtam egy módszerről anno, hogy hogy is lehet LV-t csökkenteni Na.. Ez a módszer most épp kapóra jön, csak kicsit másként kell használni, de a recept hasonló:

- Olvassuk ki az LV mappolását egy külön file-ba
- Szűrjük le, hogy mit akarunk kiszedni az LV alól
- Umountoljuk az FS-t (és tegyük closed-ba így az LV-t)
- Dobjuk ki ami nem kell
Ez kb így nézett nálam ki:

server # lquerylv -L $(getlvodm -l applv) -r > /tmp/mapfile
server # grep $(lspv |grep -w vpath91|awk '{print $2}') /tmp/mapfile >/tmp/mapfile2
server # wc -l /tmp/mapfile2
     1024 /tmp/mapfile2
server # umount /appdata
server # lreducelv -l $(getlvodm -l applv) -s 1024 /tmp/mapfile2

Ezt még persze megfejelhetjük egy fsck-val mount előtt, de itt még nem lesz probléma garantáltan.. Viszont innentől az FS visszaáll open/syncd-be :)

server # lsvg -l appvg |grep applv
applv         jfs2       8192    8192    8    open/syncd    /appdata

Ezzel egy problémát megoldottunk, viszont az eredeti még mindig megvan.. Viszont a fenti koktél némileg másként keverve itt is segíteni tud -> a módszer használható PP-k/LP-k teljes "lecserélésére" is ha összekombózzuk az lextendlv-vel :) A módszer kb így néz ki:

- 1x is pakoljunk át mindent amit tudunk a hibás LUN-ról (diszkről, ha úgy jobban tetszik) egy másik használható LUN-ra
- A pakolás közben 1, vagy több LP garantáltan nem fog átmenni, de nem is kell, elég ha a használható adat átballag a másik helyre
- Miután megvan, hogy mely LP-k nem teljesen elérhetőek, azokat kidobjuk a fenti módon
- Majd ezután ugyan annyi LP-t adunk az új diszkről, csupán az LP számozásra kell figyeljünk
Ennek a módszernek egyik nagy előnye, hogy nem kell a teljes FS-t backupból visszahozni, a másik oldalról viszont az elvesztett PP-ket üres PP-vel fogjuk feltölteni, ami meg elég durva adatvesztést/adatinkonzisztenciát jelent, amit viszont valahogy le kell kezelni. Tekintve, hogy az adat már most se nagyon elérhető, így ez még mindig a leghasználhatóbb útvonal a hiba javításához (lehet dönteni, hogy az adat nem elérhető, vagy 0-val van feltöltve -> restore mind a 2 esetben kell).

Ehhez persze tudni kell, hogy mely file-ok lesznek érintettek, ergo be kell vetni még 1-2 plusz lépést, hogy tudjuk mi és merre.. A legegyszerűbb erre az, hogy a file-okból egy checksum-ot generálunk (az legalább végigmegy a file-okon, és nem az attribútumok alapján próbál tájékozódni) a művelet előtt, majd utána, aztán összevetjük a kettőt egy diff-el, majd ami változott azt visszahozzuk backupból. Ez alapján a fenti terv az alábbi módon módosul:

- Checksum generálás minden FS-ben lévő file-ról
- LP-k migrálása egy másik LUN-ra (vpath91 a mi esetünkben) az eredeti LUN-ról (vpath59)
- FS umountolása (LV closed-ba tétele)
- Hibás PP-k/LP-k kidobása (azaz, ami marad a migráció után)
- Új "üres" PP/LP hozzáadása az LV-hez
- Újabb checksum generálás a file-okról
- A 2 checksum kimenet összevetése
- TSM restore a változott file-okról
Parancsokra lebontva ez az alábbi módon néz ki:

server # find /appdata -type f -exec sum {} \; >/tmp/checksum1
server # lslv -m applv |grep vpath59 > /tmp/applv_lslv_out
server # for i in $(awk '{print $1}' /tmp/applv_lslv_out);do migratelp applv/${i}/1 vpath91;done
....
server # lquerylv -L $(getlvodm -l applv) -r |grep $(lspv |grep -w vpath59|awk '{print $2}') > /tmp/mapfile_remove
server # umount /appdata
server # export LP_ERRORS=$(wc -l /tmp/mapfile_remove|awk '{print $1}')
server # lreducelv -l $(getlvodm -l applv) -s ${LP_ERRORS} /tmp/mapfile_remove
server # sed "s/$(lspv |grep -w vpath59 |awk '{print $2}')/$(lspv |grep -w vpath91|awk '{print $2}')/g" /tmp/mapfile_remove > /tmp/mapfile_add
server # lslv -m applv |grep -w vpath91 |awk '{print $2}' |sort -n|tail -1
1022
 # Azon LP-k száma, amit sikerült átmigrálnunk a migratelp-vel a vpath91re
server # vi /tmp/mapfile_add  
 # Itt kell átírjuk az LP számozást, nehogy ütközzön az előzővel (tehát a 2 LP-nk (Ennyi volt az $LP_ERRORS nálam) száma 1022 fölött kell legyen. 
 # Én maradtam az 1023 és az 1024-nél :)
server # lextendlv -l $(getlvodm -l applv) -s ${LP_ERRORS} /tmp/mapfile_add
server # fsck /dev/applv
The current volume is: /dev/applv
Primary superblock is valid.
*** Phase 1 - Initial inode scan
*** Phase 2 - Process remaining directories
*** Phase 3 - Process remaining files
*** Phase 4 - Check and repair inode allocation map
*** Phase 5 - Check and repair block allocation map
server # mount /appdata
server # find /appdata -type f -exec sum {} \; >/tmp/checksum2
server # diff /tmp/checksum1 /tmp/checksum2 > /tmp/checksum_difference
server # for FILE in $(awk '/^</ {print $3}' /tmp/checksum_difference);do dsmc rest $FILE;done

... PROFIT ...

# A folyamat persze feltételezi azt, hogy az FS alatt nem történik ilyenkor más változás, ergo az applikációs team-et a folyamat alatt illik távol tartani.. Viszont ez a módszer egész türhetően levitte számomra a visszaállítandó adat mennyiségét 2 TB-ról 3,2 GBra (2 db 256 MB-os PP sérülés volt az adott PV-n, azok közül az egyik meg pont egy nagyobb file-ban, ergo azt teljesen vissza kellett állítani)

Mi is történt? Kicseréltünk 2 LP-t 1 LV alól, úgy hogy azt a hivatalos módszerekkel elvileg meg se lehet oldani (legalább is nem ilyen módon). Mindebben pedig a legszebb, hogy az egészből az FS szinte alig vesz észre valamit, max némi adat nullázódik ki, de azt meg TSM-ről visszahozzuk..

Azt azért persze hozzá kell tennem, hogy ez a módszer véletlenül se támogatott hivatalosan, és ha az IBM support észreveszi, hogy nem a normál módon járunk el, akkor az ebből fakadó hibákra semmiféle felelősséget nem vállal, szóval óvatosan játszadozzon ezzel a módszerrel bárki is, és csak is saját felelősségre!

***********
Némi kis bónusz - ha az lvextend előtt kérjük le az LV állapotát, akkor ilyen kellemes helyzetben találhatjuk magunkat :))

server # lsvg -l appvg |grep applv
0516-1147 : Warning - logical volume applv may be partially mirrored.
applv         jfs2       8192    8190    8    open/stale    /appdata

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 :)

Halott diszk, halott paging.. Mit is kezdjek veled..

Úgy nézem ez a Július tele lesz finomságokkal..
Mai nap például pont ez jött szembe:

server # errpt |head
IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION
16F35C72 0714150111 P H hdisk1 DISK OPERATION ERROR
16F35C72 0714150111 P H hdisk1 DISK OPERATION ERROR
16F35C72 0714145911 P H hdisk1 DISK OPERATION ERROR
16F35C72 0714145911 P H hdisk1 DISK OPERATION ERROR

Ohh, hát ezt ismerjük... Nézzük használjuk e:

server # lspv |grep -w hdisk1
hdisk1 0050db3a8c87dd2c psvg1 active

Használjuk.. szupi.. Akkor nézzük a szokásos mókát: Lebontom a tükröt, kiveszem a diszket a VG alól, aztán majd valamikor cseréljük a diszket.. De ehhez persze tudnom kell, hogy a tükör ép e.. Hát nézzük:

server # lsvg -p psvg1
0516-062 : Unable to read or write logical volume manager
record. PV may be permanently corrupted. Run diagnostics

őőő.. állj.. ez így már nem vicces..

server # lspv |grep -w psvg1
hdisk1 0050db3a8c87dd2c psvg1 active

Ja hogy nincs tükör??? Extra mód nem vicces.. Nézzük mi volt alatta, ha ne adj isten restore-olni kéne:

server # odmget -q parent=psvg1 CuDv

CuDv:
name = "paging00"
status = 0
chgstatus = 1
ddins = ""
location = ""
parent = "psvg1"
connwhere = ""
PdDvLn = "logical_volume/lvsubclass/lvtype"

Ohh.. mázli.. szal csak egy paging.. Szívroham el, de attól még él a probléma.. Nézzük akkor hogy is állunk:

server # lslv paging00
LOGICAL VOLUME: paging00 VOLUME GROUP: psvg1
LV IDENTIFIER: 0050db3a00004c00000000fc2d691d85.1 PERMISSION: ?
VG STATE: active/complete LV STATE: ?
TYPE: paging WRITE VERIFY: ?
MAX LPs: ? PP SIZE: ?
COPIES: ? SCHED POLICY: ?
LPs: ? PPs: ?
STALE PPs: ? BB POLICY: ?
INTER-POLICY: minimum RELOCATABLE: yes
INTRA-POLICY: center UPPER BOUND: 32
MOUNT POINT: N/A LABEL: None
MIRROR WRITE CONSISTENCY: ?
EACH LP COPY ON A SEPARATE PV ?: yes
Serialize IO ?: ?

server # lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto Type
paging01 hdisk2 psvg2 17344MB 1 yes yes lv
0516-062 : Unable to read or write logical volume manager
record. PV may be permanently corrupted. Run diagnostics
hd6 hdisk0 rootvg 3072MB 1 yes yes lv

Na erre szoktam mondani, hogy annyira nem biztató.. Na mind1.. tudjuk az LV (innentől fogva a Paging nevét) nevét, szedjük le róla a paginget..

server # chps -a n paging00
server # rmps paging00
0517-062 rmps: Paging space paging00 is active.
0517-061 rmps: Cannot remove paging space paging00.

server # swapoff /dev/paging00
server # rmps paging00
0516-062 lqueryvg: Unable to read or write logical volume manager
record. PV may be permanently corrupted. Run diagnostics
0516-912 rmlv: Unable to remove logical volume paging00.
0517-061 rmps: Cannot remove paging space paging00.

Ilyenkor jön az, hogy elevenítsük fel az "I love to say fuck" c. számot, mert bizony ez kibaxás...

Na mind1.. Ha nincs más, akkor csak az előre: Elő a hegesztő pákát, és hegesszük ki a rendszer alól az LV-t:

server # odmdelete -q name=paging00 -o CuAt
0518-307 odmdelete: 5 objects deleted.
server # odmdelete -q dependency=paging00 -o CuDep
0518-307 odmdelete: 1 objects deleted.
server # odmdelete -q name=paging00 -o CuDv
0518-307 odmdelete: 1 objects deleted.
server # odmdelete -q value3=paging00 -o CuDvDr
0518-307 odmdelete: 1 objects deleted.

Majd próbáljuk meg varyoffolni a VG-t:

server # varyoffvg psvg1
0516-062 lqueryvg: Unable to read or write logical volume manager
record. PV may be permanently corrupted. Run diagnostics

Na most akkor ment, vagy nem ment?

server # lspv |grep -w hdisk1
hdisk1 0050db3a8c87dd2c psvg1

Hoppá!! Nem aktív.. Fény az alagút végén :))

server # exportvg psvg1
server # lspv |grep -w hdisk1
hdisk1 0050db3a8c87dd2c None

Szuper :) Akkor nézzük a paginget is :

server # lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto Type
paging01 hdisk2 psvg2 17344MB 1 yes yes lv
hd6 hdisk0 rootvg 3072MB 1 yes yes lv

Éljen a magyar :)) Megy minden szépen tovább :) No outage, no issue :))

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)

"Pokoli" AIX adminisztrátor - LV decrease

Mai nap kolléga szögezte nekem a kérdést, hogy hogy is lehet AIX alatt LV-t csökkenteni (úgy, hogy az FS és az LV mérete nem egyezik meg). Nos.. Mint kiderült van egy hivatalos, meg egy kevésbé hivatalos mód is a kérdés megválaszolására (utóbbi a viccesebb), ezért gondoltam ezt meg is osztanám akkor már:
Adott a szituáció:
Van egy szimpla VG-nk, azon belül egy LV-nk, azon belül meg egy JFS2 filerendszer.. Eddig semmi szokatlan..

[test_server:root:/home/root:] lsfs -ql /kenny
Name Nodename Mount Pt VFS Size Options Auto Accounting
/dev/test2lv -- /kenny jfs2 524288 rw no no
(lv size: 524288, fs size: 524288, block size: 4096, sparse files: yes, inline log: no, inline log size: 0, EAformat: v1, Quota: no, DMAPI: no, VIX: no)

Az eredeti kérdésünk szerint az FS nem tölti ki teljesen az LV-t, így növeljük meg 1 PP-vel, hogy ezt elő is hozzuk:

[test_server:root:/home/root:] /usr/sbin/extendlv test2lv 1
[test_server:root:/home/root:] lsfs -ql /kenny
Name Nodename Mount Pt VFS Size Options Auto Accounting
/dev/test2lv -- /kenny jfs2 524288 rw no no
(lv size: 655360, fs size: 524288, block size: 4096, sparse files: yes, inline log: no, inline log size: 0, EAformat: v1, Quota: no, DMAPI: no, VIX: no)

A játék innen indul - állítsuk vissza az eredeti állapotot..
Hivatalosan ezt az alábbi módon kéne megtennünk:
Első körben az FS-t felnöveljük az LV méretére:

[test_server:root:/home/root:] chfs -a size=655360 /kenny
Filesystem size changed to 655360
[test_server:root:/home/root:] lsfs -ql /kenny
Name Nodename Mount Pt VFS Size Options Auto Accounting
/dev/test2lv -- /kenny jfs2 655360 rw no no
(lv size: 655360, fs size: 655360, block size: 4096, sparse files: yes, inline log: no, inline log size: 0, EAformat: v1, Quota: no, DMAPI: no, VIX: no)

Majd visszacsökkentjük az FS-t az eredeti méretére:

[test_server:root:/home/root:] chfs -a size=524288 /kenny
Filesystem size changed to 524288
[test_server:root:/home/root:] lsfs -ql /kenny
Name Nodename Mount Pt VFS Size Options Auto Accounting
/dev/test2lv -- /kenny jfs2 524288 rw no no
(lv size: 524288, fs size: 524288, block size: 4096, sparse files: yes, inline log: no, inline log size: 0, EAformat: v1, Quota: no, DMAPI: no, VIX: no)

A második módszer ennél kicsit veszélyesebb, de ennél fogva viccesebb is..
A felállás ugyan az, mint eddig:

[test_server:root:/home/root:] lsfs -ql /kenny
Name Nodename Mount Pt VFS Size Options Auto Accounting
/dev/test2lv -- /kenny jfs2 524288 rw yes no
(lv size: 655360, fs size: 524288, block size: 4096, sparse files: yes, inline log: no, inline log size: 0, EAformat: v1, Quota: no, DMAPI: no, VIX: no)

Nézzük meg a PP, és az LP összefüggéseket, csak hogy lássuk mink is van:

[test_server:root:/home/root:] lquerylv -L `getlvodm -l test2lv` -r
0057d91de041890e 3 1
0057d91ddb713a8c 54 1
0057d91de041890e 4 2
0057d91ddb713a8c 55 2
0057d91de041890e 5 3
0057d91ddb713a8c 56 3
0057d91de041890e 6 4
0057d91ddb713a8c 57 4
0057d91de041890e 2 5
0057d91ddb713a8c 53 5
Az egyszerűség kedvéért ugyan ez lslv-vel
[test_server:root:/home/root:] lslv -m test2lv
test2lv:/kenny
LP PP1 PV1 PP2 PV2 PP3 PV3
0001 0003 hdisk0 0054 hdisk1
0002 0004 hdisk0 0055 hdisk1
0003 0005 hdisk0 0056 hdisk1
0004 0006 hdisk0 0057 hdisk1
0005 0002 hdisk0 0053 hdisk1

Na szóval.. 1 FS, 5 LP, és 10 PP (azaz LVM mirror).
Hogy teljes legyen a kép, még kérjük ki az LV azonosítóját is

[test_server:root:/home/root:] getlvodm -l test2lv
0057d91d00004c0000000128b0057d95.17

Na és akkor innen indul a móka: Mind azt amit eddig kikértünk rakjuk bele egy file-ba:

[test_server:root:/home/root:] lquerylv -L `getlvodm -l test2lv` -r |awk '{a[i++]=$0} END {for (j=i-1; j>=0;) print a[j--] }' > /tmp/mapfile

Alapvetően az awk-os mókára nem lenne szükség (amúgy tac-ot emulál a drágája), viszont itt direkt azt akartam, hogy az utolsó LP-hez tartozó bejegyzések a file elején helyezkedjenek el.
És akkor innen induljon a móka:

[test_server:root:/home/root:] lreducelv -l `getlvodm -l test2lv` -s 2 /tmp/mapfile

Majd a visszaellenőrzés:

[test_server:root:/home/root:] lslv -m test2lv
test2lv:/kenny
LP PP1 PV1 PP2 PV2 PP3 PV3
0001 0003 hdisk0 0054 hdisk1
0002 0004 hdisk0 0055 hdisk1
0003 0005 hdisk0 0056 hdisk1
0004 0006 hdisk0 0057 hdisk1
[test_server:root:/home/root:] lsfs -ql /kenny
Name Nodename Mount Pt VFS Size Options Auto Accounting
/dev/test2lv -- /kenny jfs2 524288 rw no no
(lv size: 524288, fs size: 524288, block size: 4096, sparse files: yes, inline log: no, inline log size: 0, EAformat: v1, Quota: no, DMAPI: no, VIX: no)

Kis magyarázat: Az lreducelv parancs AIX alatt a map file alapján töröl PP-ket az adott LV-ből. A -s paraméterrel tudjuk megmondani, hogy pontosan hányat is töröljön (2 kellett jelen esetben a mirroring miatt), viszont van egy olyan rossz szokása, hogy a map file elejétől indul, és az onnan felvett értékekkel dolgozik (jelen esetben az első 2 sorban meghatározott PP került törlésre (ha nem fordítottam volna meg a map file-t, akkor az első 2őt törölte volna, ami nagyon nem lett volna egészséges))
Amire még figyelnünk kell: Ez a parancs nem csak az ODM-ben turkál, hanem magában a VGDA-ban is, így óvatosan a használatával, tekintve, hogy ha nem figyelünk, akkor könnyen kitudunk hozni egy ilyesmi állást is :)

[test_server:root:/home/root:] lslv test2lv
LOGICAL VOLUME: test2lv VOLUME GROUP: testvg
LV IDENTIFIER: 0057d91d00004c0000000128b0057d95.17 PERMISSION: read/write
VG STATE: active/complete LV STATE: opened/syncd
TYPE: jfs2 WRITE VERIFY: off
MAX LPs: 512 PP SIZE: 64 megabyte(s)
COPIES: SCHED POLICY: parallel
LPs: 0 PPs: 0
STALE PPs: 0 BB POLICY: relocatable
INTER-POLICY: minimum RELOCATABLE: yes
INTRA-POLICY: middle UPPER BOUND: 32
MOUNT POINT: /kenny LABEL: /kenny
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes
Serialize IO ?: NO

=> Ez a leírás inkább csak olyan érdekesség képen született, tessék a hivatalos utat használni ilyen esetben :)

AIX - VG varyon failed.. - Avagy amikor Murphy nagyot mosolyog..

Na de vajon miért.. (költői kérdés).. avagy - ez az a helyzet, amibe nem szívesen kerülök, mint system admin (amúgy sikerült megoldani, csak gondoltam postolom ezt is :))
# > lspv |grep -w hdisk10
hdisk10 00c3f43e8eff2532 None

# > readvgda hdisk10 |grep pv_id
pv_id: 00c3f42e99549e58
pv_id: 00c3f42e99549fef
pv_id: 00c3f42e9954a259
pv_id: 00c3f42e9954a3ee
pv_id: 00c3f42e9954a587
pv_id: 00c3f42e9954a716
pv_id: 00c3f42e9954a982
pv_id: 00c3f42e9954ab07
pv_id: 00c3f42e9954ad78
pv_id: 00c3f42e9954aeff
pv_id: 00c3f42e9954b162
pv_id: 00c3f42e9954b2f1
pv_id: 00c3f42e9954b47c

A szitu az volt, hogy kb 150 diszk keringőzött a gépen, amiből mint fentebb látható 13 egy VG-hez tartozott.. Sajna a gépen -nem részeletezem miért - az összes diszk PVID-ja törölve lett (kiv a rootvg-hez tartozók), ergo a VG-ket a VGDA adatok alapján kellett helyrevágni.
A dolog pikantériáját az adta, hogy a readvgda/lqueryvg segítségével meg tudod nézni melyik diszk mely diszkkel volt közös VG-n belül (vgda-n belül a vg_id sokat tud ebben segíteni), viszont ez után még 2 problémával szembe kell nézz:
- Az 1ik az, hogy a PVID-kat attól még vissza kéne rakni (VGDA-ba nem írunk), különben a VG-t az istennek se lehet varyon-olni
- A másik az, hogy az embernek figyelnie kell arra is, hogy a megfelelő PVID-t a megfelelő diszkre írja vissza (az, hogy még mondjuk fél napja -hasraütök- a hdisk10es az XY PVID-t bírtokolta, az még nem jelenti azt, hogy az a hdisk10 ugyan az a hdisk10 amit most látsz, ergo nem lehet benne biztos, hogy az XY PVID-t erre a diszkre kell visszaírd..
Az első problémára a megoldás kicsit vicces... A PVID fizikailag tárolódik a diszken, így azt felül lehet vágni egy mókásan felparaméterezett dd-vel .. a módszer kb így néz ki:

#!/usr/bin/ksh
pvid=$1
disk=$2
set -A a `echo $pvid|\
awk ' {
for (f=1; f <= length($0); f=f+2) {
print "ibase=16\nobase=8\n"toupper(substr($0,f,2))
}
}'|\
bc 2>/dev/null`
/usr/bin/echo "\0"${a[0]}"\0"${a[1]}"\0"${a[2]}"\0"${a[3]}"\0"\
${a[4]}"\0"${a[5]}"\0"${a[6]}"\0"${a[7]}"\0\0\0\0\0\0\0\0\c"|\
dd bs=1 seek=128 of=/dev/$disk

A 2. probléma már gázosabb.. megvan, hogy mely 13 diszk van benne a VG-ben (sőt még a VG nevét is tudjuk valahonnan), de attól még nem tudjuk melyik diszk melyik PVID-t kéne birtokolja.. Nos.. ez az a pont, ahol a jól dokumentált rendszer csak a jó rendszer - előkaptam a régi doksikat, és a LUNID-k alapján (vagy lokál diszk esetén lokációs adat alapján) összerendezhető, hogy minden diszk az e akiről tudjuk.. Ha ez megvan, akkor a fentebb leírt módszerrel a megfelelő PVID-k visszavarázsolhatók a megfelelő diszkekre, és ismét lehet varyon-olni..

AIX - FS, VG check - mini-script

Volt a környéken egy probléma, amit úgy érzetem egyszerűbb lescriptelni, mint sem darabonként végignyálazni.. Ennek eredményeként született meg az alábbi kis scriptecske:
http://pastebin.com/f7af22dc8
Mire is jó?
- Megnézi, hogy a definiált VG-k közül melyek vannak auto-varyonra állíta, ha nincs, akkor warningot dob ( A PowerHA-s VG-k külön vannak lekezelve, mert ott pont hogy nem szabad autovary-onban lennie a VG-nek :))
- A VG-ben definiált LV-kben elhelyezkedő FS-eket megnézi, hogy automountra raktuk e, ha nem akkor szintén warningot dob.
Az ellenőrzések mind a gép által tárolt információk alapján történnek, semmiféle írás, vagy beavatkozás nem történik a rendszeren ( ez eléggé látszik ott is, hogy szinte minden az ODM-ből jön, meg a /etc/filesystems-ből )
Természetesen a script által visszaböfögött infók csak tájékoztató jellegűek, így nem árt, ha az ember kicsit még átnézi a kapott adatokat ( pl régebbi GPFS VG-ket is megtalál, amiket viszont nem szabad piszkálni, illetve PowerHA esetén a hearthbeat-re használt VG-k is ugyan ebben a kalapban vannak ). Nekem arra volt jó, hogy kb 60-70 szervert ne kelljen darabonként végignézzek :)
Ha esetleg másnak is kell, akkor használja egészséggel :)
u.i.: Nem mondom, hogy szép, nem mondom, hogy nem lehetne jobb, de a célnak részemről megfelelt :)