HMC upgrade - Generációs problémák

Előző blogbejegyzésemben megemlítettem, hogy "szerintem" a HMC upgrade-ről nem lehet tartalmasan írni, mire egyik ismerősöm rámutatott arra, hogy hiába nem olyan hajmeresztő a téma, attól még neten nem hogy magyarul, de angolul sincs normális dokumentáció ilyen jellegű HMC upgrade-ről távoli upgrade-et tekintve. Így hát vettem a bátorságot és azt gondoltam, hogy ha másért nem, hát azért is leírom, hogy mivel is jár egy ilyen szintű upgrade előkészítése, kivitelezése, illetve mily buktatók vannak amire nem árt figyelni. Hosszú post következik, mindenki készítsen elő 1 hétre való hideg élelmiszert, meg konzervet :)))

Na szóval.. A feladat a következő: Adott egy csomó, pár generációval régebbi HMC, amik mind-mind valami über-fontos rendszert támogatnak (hogy ez mennyire fedi a valóságot az más kérdés - a customernek mindig minden über fontos). További információ, hogy a HW típusok, illetve a telepített HMC verziók is meglehetősen eltérőek, illetve minimalizálni kéne az onsite support nyújtotta lehetőségeket (a lehetőség adott, csak épp fizetni kell érte, amit meg valahogy az ügyfelek sose akarnak, mondván hogy "Hát azért fizetünk téged, hogy megcsináld.." )

Ezzel a felemelő tudattal lássuk hát mis is lehet tenni és hogyan.
1x is, nézzük, hogy a neten milyen információk érhetőek el jelenleg, avagy miből élünk:
Upgrading the HMC from Version 4.3, 4.4, or 4.5 to Version 6.1.3
Upgrading the HMC from Version 6.1.2 (or Later) to Version 7.3.2

Ezek a leírások szépen le is írják, hogy hogyan kéne a HMC-ket upgrade-elni, de hogy-hogy nem csak a local DVD-RAM-ra támaszkodnak, ami meg nekünk most nem sokat segít (hacsak nem tudunk valakit rábírni, hogy fizesse az utazási költséget, meg biztosítsa a fizikai hozzáférést az érintett HMC-khez). Egy dologra viszont azért még is használhatóak: Kb kideríthető, hogy az upgrade útvonal valami ilyesmi kéne legyen:
4.x-> 6.1.3 (plusz a szükséges fixek) -> 7.3.2 -> 7.7.x (jelenlegi latest)

Na persze ez önmagában még nem elég: Van egy olyan sajnálatos része is a dolognak, hogy a HMC által managelt box(ok) alatt futó firmware-nek is kompatibilisnek kell lennie a HMC-vel, különben az képtelen lesz kommunikálni az FSP-vel, minek következtében a HMC nem fogja tudni managelni a boxot (ergo pont azt a funkcionalitást veszítjük el, amiért a HMC-t tartjuk). Így sajna figyelembe kell vegyük azt is, hogy HMC upgrade előtt a boxok FW-je is megfelelő szinten legyen.

Ebben segítenek az alábbi doksik:
- Supported combinations for HMC and Power 5 Server code: http://www14.software.ibm.com/webapp/set2/sas/f/power5cm3/sftablep5.html
- Minimum FW levels: http://www-912.ibm.com/s_dir/slkbase.NSF/1444e529a72ba96486256a6400681992/c69799b70a28578c8625712c004fe06b?OpenDocument
- HMC 7.3.x es afölött: http://www-933.ibm.com/support/fixcentral/firmware/supportedCombinations
- Power5,P590, p505: http://www14.software.ibm.com/webapp/set2/sas/f/power5cm3/supportedtable2.html
- Power5, exlcuding p590, p595: http://www14.software.ibm.com/webapp/set2/sas/f/power5cm3/supportedtable1.html

További hasznos infó az, hogy jelenleg mely HMC verziók támogatottak is:

https://www-304.ibm.com/webapp/set2/sas/f/power5cm/eoss.html

.. illetve hogy mely HMC-k pontosan meddig is húzhatók fel:

AIX, VIOS and HMC Facts and Features (17. oldal)

Na most mindez után egy pillanatra álljunk meg.. Ugye azt mondtam, hogy azért itt akad 1-2 elég régi generációs masina is, ami azért magával von 1-2 meglehetősen fontos dolgot:
- Ha a HMC nem 1 mai darab, akkor valószínű, hogy a managelt box se.
- Ha a managelt box nem 1 mai darab, és még mindig alacsony HMC mellett üzemel, akkor a firmware se lehet épp a legfrissebb
- Ha upgrade-elni kell egy régebbi HMC-t, hogy supported szinten legyen, akkor az az alábbi dolgokat jelentheti:

- Vagy egy Power4es vasunk van aminél a legmagasabb elérhető szint a 3.3.7 (még ez év végéig támogatott)

- Vagy Power5ös, ami azt jelenti, hogy a HMC-nk 4.5.x-től bármelyik azóta kiadott HMC szóba jöhet

# Kis megjegyzés - Power6-Power7 nagyon nem jöhet szóba, tekintve, hogy azok annyira nem régiek, meg azokhoz min HMC v7.3.x dukál ..

- Ahhoz hogy egy p5-ös gépet (jelenleg; 2012.08.21) támogatott szintre felhúzzunk az alábbi HMC-k valamelyikével kell rendelkezzünk:

    - 7310-C05,7310-CR3 -> 7.7.x

    - 7310-C04,7310-C03, 7310-C02 -> 7.3.x

- Power5 alatt jelenleg egyik supported HMC se támogatja a régi FW-ket (Release 240 elöttiek), ergó az FW upgrade-et tuti nem ússzuk meg (Distruptive upgrade ==> Teljes box leállást igényel, így minden LPAR-t le kell kapcsolni mielőtt ennek nekiállunk)

Ha Power4ünk van, akkor könnyű dolgunk lesz (feltéve, hogy min 3.3-as szinten van a HMC). Ha viszont Power5-ről beszélünk (és a fent említett 5 modell valamelyikével áldott meg minket a sors), akkor már macerásabb helyzetben találhatjuk magunkat, tekintve, hogy abban az esetben a 4.5.x HMC se elképzelhetetlen.

Na jó.. Akkor ez után nézzük mit is lehet távolról egy nyomorult internet hozzáféréssel csinálni.
Alap járaton ugye adott a fix/service pack telepítésének lehetősége, ami viszont nem jelent verzió ugrást (mondjuk egy 3.3.x-> 3.3.7 telepítéséhez ez még bőven elég). Ahhoz, hogy verziók között tudjunk ugorni (6.x->7.x) szükségünk van az úgy nevezett "alternate disk installation" nevű módszerre (vagy akik AIX-földről jöttek annak az alt_disk_boot lehet ismerősebb). A probléma ezzel csupán annyi, hogy ez a parancs csak az 5.2.1-es verzió óta érhető el, következés képen ha version 5.x, vagy afölött vagyunk akkor még van remény (verzión belül tudunk ugrálni mint mondtam, ergo 5.x-ről fel tudjuk húzni remote 5.2.1ig a HMC-t), ha viszont egy v4.x HMC-vel hozott össze a sors, akkor kötelezően szükségünk lesz valakire aki helyben felhúzza a HMC-t egy számunkra kellemes szintre (Ennyit a customer elvárásairól ez esetben :D Mázlira 4.x-ről direkt lehet ugrani 6.1.2-re local DVD-RAM-al, tovább viszont a firmware függőségek viszont nem.)

További "kellemes" problémaforrás, hogy amennyiben a 7310-C03 HMC-vel hozott össze a sors minket, úgy nem csak a box(ok) FW upgrade-je miatt kell fájjon a fejünk, hanem a HMC BIOS upgrade-je (!) miatt is, mielőtt fel akarnánk az vinni v6.1.x vagy afölé (amihez szintén helyi technikus kell :))
https://www-304.ibm.com/support/customercare/sas/f/hmcl/bios/home.html

# Kis segítség: az 'lshmc -b' paranccsal meg lehet nézni milyen verziójú BIOS fut a HMC-nk alatt

Na akkor összegezzük hogy mit is kéne csinálni:
- Ha a sors egy 7310-C03 HMC-vel hozott össze, akkor onsite technikus segítségével a BIOS-t fel kell upgrade-elni, mielőtt bármit is csinálnánk
- Ha egy v4.x HMC-vel hozott össze a sors, akkor szintén onsite technikus segítségét kell kérjük, hogy a HMC-t 6.1.2 felhúzza
- Ha a HMC-nk meg a 3.3.x idők elötti verzión fut, akkor local technikus fog ismételten csak kelleni:

http://www-304.ibm.com/webapp/set2/sas/f/hmc/p4lpp/related/tip001_upgrade2to3.html

http://www-304.ibm.com/webapp/set2/sas/f/hmc/p4lpp/related/hmc31tohmc337.html

- Ha a HMC-nk v3.3.x verzión fut, akkor nincs mitől félnünk, a standard update process-t alkalmazva

http://www.www-304.ibm.com/webapp/set2/sas/f/hmc/power4/download/v33.Update.html

http://www-01.ibm.com/support/docview.wss?uid=isg3T1012428

- Abban az esetben ha a HMC-nk minimum v5.x-en fut, akkor az upgrade path a következő lesz:

- 5.1.0 -> 5.2.0 /* update */

- 5.2.0 -> 5.2.1 /* update */

- 5.2.1 -> 6.1.2 /* altdiskboot */

- 6.1.2 -> 6.1.3 (+ javítások) /* update */

- Firmware upgrade Release 240-re az összes HMC által managelt boxon

/* ajánlott upgrade a 240_382. Innen konkurensen lehet ugrani a latest 240_418-as verzióra */

- 6.1.3 -> 7.3.4 /* altdiskboot */

- 7.3.4 -> 7.7.7 (amennyiben lehetséges) /* altdiskboot */

- 7.7.7 -> 7.7.7.2 (amennyiben lehetséges) /* update */

Szükséges file-ok:

3.3.5 -> 3.3.7 (update) / HMC_Update_V3R3.7.zip

3.3.7 Corrective Service Fixes / U808917.zip, U810401.zip, U814685.zip, U860526.zip

4.x -> 6.1.2 (onsite only) / HMC_Recovery_V6R1.2_1.iso, HMC_Recovery_V6R1.2_2.iso

5.1.0 -> 5.2.0 update / HMC_Update_V5R2.0_1.zip, HMC_Update_V5R2.0_2.zip

5.2.0 -> 5.2.1 update / HMC_Update_V5R2.1_1.zip, HMC_Update_V5R2.1_2.zip

5.2.1 -> 6.1.2 - netinstall / bzImage, disk1.img, disk2.img, disk3.img, initrd.gz

6.1.2 -> 6.1.3 update / HMC_Update_V6R1.3_1.zip, HMC_Update_V6R1.3_2.zip, HMC_Update_V6R1.3_3.zip, HMC_Update_V6R1.3_4.zip

6.1.3 Corrective Service Fixes / MH01082.zip, MH01110.zip, MH01127.zip, MH01128.zip, MH01168.zip

6.1.3 -> 7.3.4 - netinstall / bzImage, disk1.img, disk2.img, disk3.img, hmcnetworkfiles.sum, initrd.gz

7.3.4 -> 7.7.7 - netinstall / bzImage, disk1.img, disk2.img, disk3.img, hmcnetworkfiles.sum, initrd.gz

7.7.7.0 -> 7.7.7.2 update / HMC_Update_V7R770_SP2.iso

7.7.7.2 Corrective Service Fix / MH01367.iso

Ha eddig tudtál követni (és a tervezésnek minden kellemes percét kiélted már), akkor most jön arra a kérdésre a válasz, hogy akkor mit és hogyan.
Kezdjük talán a hivatalos dokumentációval:

Remote upgrade from HMC 5.2.1 using network images

Upgrading or installing HMC V7 over a network

Feltételezve, hogy eljutottunk arra a szintre, hogy a HMC-nk valóban távolról upgrade-elhető, nézzük hogy hogyan is kéne ennek elvileg lezajlania:
- Nulladik körben kell egy szervert találni, ami a HMC-vel viszonylag jó hálózati kapcsolattal bír, lehetőleg a tűzfal nem blokkolja az FTP/NFS kapcsolatokat, és fel tudjuk rá tölteni az összes szükséges Firmware és HMC update/upgrade file is.

# Jó tanács: Érdemes egy kb 50 MB-os file-t SCP-vel feltolni a HMC-re tesztelni, hogy a hálózat milyen sebességet képes nyújtani.

- Első körben csinálunk valami nyamvadék backupot ha tudunk:

- HMC v3.x sajna csak local DVD-RAM-ra tud bármilyen backupot küldeni, így ott ha lehet, akkor kérjünk meg valakit, hogy rakja be a szükséges optikai lemezt a helyére. Ha ez nem megoldható akkor egyik jó kollégám mondásával élve "Don't be afraid to be a cowboy", persze azért a "Kockázatokról, és lehetséges mellékhatásokról kérjük értesítse ügyfelét, vagy jogász ismerősét", csupán a kényelmetlen kérdések elkerülése végett.

- HMC v4.x óta van lehetőség a "Critical Console Data"-t egy NFS szerverre feltolni, amit meglehetősen tudok is ajánlani (hogy pontosan miért azt kicsit később)

- Második körben én komolyan azt tanácsolom, hogy ha lehet akkor az alábbiak közül minél többet tartsunk készenlétben:

- PESH jelszó (vagy épp kedvenc rbash escape modszer, ha ismersz ilyet) a HMC-nkhez (mind a 7.3 előtti, mind az utáni PESH jelszó)

- Onsite technikus (aka local support) ha valami tényleg balul ütne ki

- 3. körben szintén egy jó tanács: Mielőtt elkezdünk upgrade-elgetni, indítsuk újra a HMC-t. Hogy miért?

- Nem szeretem amikor X napja/hónapja beragadt processek szívatnak meg

- Jobb leellenőrizni, hogy a HMC egyáltalán képes e magától talpra állni (a restartot meg amúgy se ússzuk meg, szóval inkább még az elején derüljön ki ha valami gáz van, mintsem arra gyanakodjunk, hogy az update/upgrade szúrt el valamit)

- Induláskor 1-2 diagnosztikai rutin azért lefut, szóval ha van valami gáz, akkor ha mákunk van még elcsíphetjük a /var/log/messages-ben.

- Érdemes lehet még kicsit kipucolni a HMC-n 1-2 dolgot is mielőtt elkezdjük felforgatni a mindenséget :)

- Event-ek lezárása: chsvcevent –o closeall

- Logok ürítése: chhmcfs –o f –d 0

/* Ezzel a lépéssel amúgy nem teljesen értek egyet auditálhatósági szempontból, de ki ki ítélje ezt meg maga. */

- Mindezek után jön az, hogy akkor update/upgrade-eljünk. Attól függően, hogy verzión belül maradunk e, vagy épp ugrunk más-más módszert kell alkalmazni:

- alternate disk install:

saveupgdata -r disk
getupgfiles -h $SERVER -u $USER -d $SOURCE_DIRECTORY
chhmc -c altdiskboot -s enable --mode upgrade
hmcshutdown -r -t now

- Update: (ISO vagy zip file-okból)

Távoli szerverről: updhmc -f /$FILE_FULL_PATH -h $SERVER -r -t s -u $USER -i

Előzőleg feltöltött file-ból: updhmc -f /$FILE_FULL_PATH -h $SERVER -r -t l -c

# Megjegyzések:
- Megoszlanak a vélemények, hogy az update-et console-ról, vagy az elérhető GUI-s (WebSM, Web-es) felületről érdemesebb e csinálni. Számomra a console gyorsabb (próbált már valaki WebSM-et futtatni 2 proxy mögül? :)), cserébe a GUI-s felület informatívabb (bár sikerült belefutnom olyan hibába, ahol viszont nem az elvárt módon működött, míg a parancssori megfelelője meg igen - erről később)
- Lehetőség van előzőleg a HMC-re feltöltött file-ból update-elni, de amennyiben alternate disk install-t is kell csinálnunk, úgy sajna csak az FTP szerver jön szóba hivatalosan. /* Nem hivatalosan root hozzáféréssel ezt meg tudjuk kerülni - erről is majd kicsit később)
- Ha jól rémlik 7.3.5-ös verzió óta van lehetőség a getupgfile parancsnál SFTP használatára a "-s" kapcsolóval
- Alternate disk install esetén, ha a saveupgdata parancsot elfelejtettük lefuttatni, vagy a parancs nem tudott mindent lementeni, akkor számoljunk vele, hogy a HMC nem fogja visszaállítani se az előzőleg létrehozott usereket, se a hálózati beállításokat, se az FSP-k kapcsolódási adatait => Lesz egy csupasz upgrade-elt HMC-nk, ami nemhogy nem managel egy boxot se, de még hálózatról se lesz elérhető. Ilyen esetben helyi technikus kell a hálózat beállításához és/vagy az előzőleg kreált "Critical Console Data" visszaállításához.

És akkor ami ezen felül még szerintem jó ha van:
- Egy alternativ session-ünk ahol monitorozni tudjuk, hogy épp hol tart a HMC (mondjuk az adat feltöltésben)

# getupgfiles parancs esetén a már letöltött file-ok a /hmcdump alá kerülnek

# updhmc parancs esetén a letöltött adat a /usr/local/hsc_install.images/ alá kerül

- Még jobb ha az a session root hozzáféréssel bír (na miért írtam a PESH-t?), ugyan is nem 1 olyan eset jött szembe, ahol igen is root hozzáférés kellett ahhoz, hogy a problémával tudjak valamit kezdeni.

Íme 1-2 példa:
- 3.3.7 alatt előjött hiba: az updhmc parancs elszáll az alábbi hibaüzenettel: "An error occurred while trying to run corrective services. Please check your entry and retry command."

- Megoldás: Nézzük meg a dátum beállításokat :) (Na jó, ezt root hozzáférés nélkül is lehet javítani (chhmc -c date -s modify), viszont a debughoz itt is kelett a root hozzáférés)

- 6.1.3 HMC alatt a saveupgdata parancs elhasal "Exception in thread "main" java.lang.NoClassDefFoundError: com/ibm/jcb/JCApplicationListener" hibával

- Megoldás: pakoljuk fel újra az alábbi javításokat ebben a sorrendben: MH01082, MH01110, MH01128, MH01127,MH01168 (Ne felejtsük el újraindítani a HMC-t mind1ik után). Ez még megy root hozzáférés nélkül.

- Majd töröljük a /tmp/saveupgrade.list file-t, és indítsuk újra a rendszert (a file törléséhez sajna már root hozzáférés kell)

# Kis kiegészítő információ: Ez a hiba több HMC-n is előjött, viszont a hibát ténylegesen csak a parancssorból hívott saveupgdata jelentette, a GUI alatt elérhető hasonló funkció vígan közölte, hogy minden rendben. Ez a "hiba" sajna egy meglehetősen kellemetlen restore-al javult csak meg, miután a site-on lévő technikus konstatálta, hogy a HMC semmiféle információt nem töltött vissza az upgrade process során.

- 7.3.4 alatt a getupgfiles az alábbi hibával elszáll: "The file bzImage appeared to be missing, or the transfer did not complete successfully, resulting in an incorrect file size or checksum. Please retry the operation." A parancs ismételt kiadása nem segít semmit.

- Megoldás: Valószínű betelt a /hmcdump FS. Kénytelenek leszünk manuálisan törölni a file-okat, majd megismételni a getupgfiles parancsot.

- Szintén 7.3.4 alatt sikerült egy olyan furcsaságba belefussak, hogy a hmcshutdown -r -t now kiadása után az SSH már leállt, illetve a HMC parancsok se működtek már, de a HMC valahogy mégse bírt ujraindulni magától: root console alól shutdown -r -t now segített csak.
- Verzió független issue: Volt szerencsém olyan HMC-hez is, ami ugyan látta a repository szervert, viszont a kapcsolat a 2 szerver között csodás 30 kb/sec-el tántorgott. Mit csinál ilyenkor az ember? Megpróbálja megszakítani a parancsot egy CTRL+C-vel, majd egy másik (immár gyorsabb szervert használva) helyről áttölteni az adatot. Na most a CTRL+C lenyomásával nincs is gond, az ember szépen vissza is kapja a terminálját.. Na de viszont amikor egy immár remélhetőleg gyorsabb helyről ismét elindítjuk a programot (illetve monitorozzuk is a folyamatot), akkor észre vehetjük hogy egyszerre több file is változik egyszerre. A dolog mögött pedig az áll, hogy a CTRL+C lenyomásakor a parancs ugyan vissza adja a parancssort, viszont a parancsot nem állítja le.

# Amennyiben ilyen helyzetbe kerülünk lehet simán jobban járunk ha root jogokkal kill-eljük a programot, és manuálisan scp-vel feltoljuk a csomagot a szükséges helyére (getupgfiles esetén ne feledkezzünk el a /hmcdump felmountolásáról se, ha esetleg le lenne csatolva)

# Pro tipp: Az alábbi paranccsal követhetjük, hogy milyen (avagy mennyi) process fut a HMC-nken root hozzáférés nélkül is: (számolni a 'grep -c'-vel tudunk :))

# for i in $(ls -d /proc/[0-9]* |sed 's/\/proc\///g'|sort -n);do echo -e "$i\t $(cat /proc/$i/status |grep Name |sed 's/Name://g') $(cat /proc/$i/cmdline)";done

Utolsó jó tanács:
- Ha valaki nagyon ragaszkodik a GUI-hoz, és van SSH hozzáférése a HMC-hez, úgy lehet megéri ha SSH tunnelezi a GUI eléréséhez szükséges portokat, majd a localhost megfelelő portjára csatlakozva manageli a HMC-t (főleg ha a HMC proxy vagy tűzfal mögött van):

- WebSM esetén:

# export TARGET=${HMC_SERVER_ADDRESS}
# ssh -L 9090:${TARGET}:9090 -L 9940:${TARGET}:9940 -L 9443:${TARGET}:9443 -L 30000:${TARGET}:30000 -L 30001:${TARGET}:30001 -L 30002:${TARGET}:30002 -L 30003:${TARGET}:30003 -L 30004:${TARGET}:30004 -L 30005:${TARGET}:30005 -L 30006:${TARGET}:30006 -L 30007:${TARGET}:30007 -L 30008:${TARGET}:30008 -L 30009:${TARGET}:30009 hscroot@${TARGET}
# /opt/websm/bin/wsm /* Majd a kapcsolódási adatoknál a szervernév localhost */

- Web-based GUI esetén:

# ssh -L 8443:${HMC_SERVER_ADDRESS}:443 hscroot@${HMC_SERVER_ADDRESS}
# firefox https://localhost:8443

# Figyelem - ez a módszer (sajna) nem használható az ASMI felület eléréséhez

Ezek után még csodálkozik valaki, hogy ennyi macera mellett a hivatalos doksik az onsite upgrade-et részesítik előnyben? :)

"Még jőni kell, még jőni fog egy jobb core.." - Népköltés..

Majd 3 hónap.. Ennyi ideje nem írtam erre e blogra semmit..
Nem azért mert szabadságon voltam, vagy mert elfelejtettem.. Egyszerűen nem volt miről írni ami erre a blogra tartozott volna (az, hogy hogyan lehet Monitoringot migrálni, meg HMC-t 4.4-rol 7.7re felupgrade-elni nem olyan jó alapanyag higgyétek el), vagy pedig szimplán olyan természetű volt amit a jelenlegi szerződésem nem enged meg (pedig jó lenne írni egy cikket róla.. ki tudja, majd 1x talán).
Hiába, ez van ha az ember nem foglalkozhat a hétköznapi adminisztrációval, hanem csak "project tevékenységekkel"

Ami azt illeti, a mostani téma se olyan nagy eresztés, de gondoltam azért még valakinek így is jól jöhet még ez.

Na szóval a helyzet: Adott egy core file a rendszeren (VIO szerver), ráadásul meglehetősen nagy méretben:

server@root # ls -l /core
-rw------- 1 root system 829566976 Jul 27 19:45 core

Igen, ez egy majd 800 MB-os darab, ráadásul a / FS alatt, amit a rendszer adminok nem véletlenül utálnak, legfőképp VIO szervereken.
A feladat: kideríteni, hogy:
- Mi dobta a core-t
- Miért dobta az a valami azt :)

Az első kérdésre alap esetben azt mondanám, hogy az errpt-ben nézzünk körbe, viszont most pont sikerült egy olyan helyzetbe bele fussak, ahol az errpt (más hibák miatt) már rotálódott, szóval más utat kell találni ennek kiderítésére. Sebaj, van 2 módszer is amit lehet használni:

1) - strings parancs: kicsit ügye fogyott, de azért még jól használható arra, hogy 1-2 környezeti adatot megismerjünk :)

server@root # strings /core | grep ^_=
 _=/opt/IBM/ITM/aix523/va/bin/kvaagent
 _=nY
 _=/usr/bin/grep
 _=/u
 _=/u

Ebből persze még nem lehet sok mindent levonni, de az a /opt/IBM/ITM/aix523/va/bin/kvaagent igen kecsegtetően néz ki.

2) - lquerypv: Az ember nem is gondolná mennyire de hasznos tud lenni ez a kis parancs, pedig meglehetősen sokoldalú, ha tudjuk mit és hol is keressünk :) Jelen esetben a 6E0 cím az ami minket foglalkoztat, ugyan is AIX alatt a core file-on belül mindig ezen a címen kell legyen az aktuális bináris neve, ami a core-t dobta:

server@root # lquerypv -h /core 6E0 16
 000006E0 61697844 61746150 726F7669 6465722D |aixDataProvider-|
 000006F0 36310000 00000000 00000000 00000000 |61..............|

aixDataProvider-61.. Ez persze nem sokat mond egy átlagos embernek, aki viszont dolgozott már ITM6 alatt VA agent-el az tudhatja, hogy ez az a process ami a kvaagent alatt fut szinte mindig, ergó jó nyomon járunk.

Nézzük a 2. kérdésre a választ.. Hogy került oda az a core.. Nos, ennek megállapításához több dolog is kell:
- Az aktuális bináris ami a core-t dobta (nem baj, azt az első lépésben már megtaláltuk, max a pontos helyét nem tudjuk még, de azt egy find se perc alatt megmondja :)
- DBX parancs azonos kernel és futtatókörnyezetben (Ez se gáz, max használjuk azt a gépet ahol az issue előjött :))
- Némi kis tudás, hogy mit is kéne nézni ...
- .. Illetve hogy hogy is kéne értelmezni..
Na haladjunk sorban, aztán meglássuk meddig jutunk..
- Na szóval, első pont: Az aktuális binárisunk.. Rövid find keresés, majd meg is találjuk a /opt/IBM/ITM/aix523/va/bin/aixDataProvider-61 alatt.
- Második pont: A dbx parancs a bos.adt.debug csomag része, ha nincs fent a gépen, akkor vagy feltesszük, vagy keresünk egy másik gépet ami megfelel a fenti kritériumoknak. Jelen esetben nekem épp fent volt a csomag :)
- Harmadik pont. Na itt jön a vicces rész. 1x is be kell hívjuk a core-t a dbx debuggerbe, majd meg kell néznünk hol is akadt el, aztán abból kitotózni, hogy mi volt a gond.
Kezdésként hívjuk be a dbx-et ay adott core file-ra:

server@root #  dbx /opt/IBM/ITM/aix523/va/bin/aixDataProvider-61 /core
 Type 'help' for help.
 warning: The core file is truncated. You may need to increase the ulimit
 for file and coredump, or free some space on the filesystem.
 [using memory image in /core]
 reading symbolic information ...warning: no source compiled with -g 
 
 Segmentation fault in . at 0x100286cc ($t1)
 0x100286cc (???) 7cc5212e stwx r6,r5,r4

Majd nézzük meg hol is hasaltunk el (where parancs):

(dbx) where
 get_diskstats() at 0x100286cc
 adp_get_diskstats(0x2ff21804) at 0x10005a88
 dt_CollectDiskData(0x3052a680, 0x30321748) at 0x1002d6a8
 dt_CollectData(0x3052a680, 0x30321748) at 0x10031b74
 itmTranslator(0x0) at 0x10032834
 main(0x1, 0x2ff21e40) at 0x1000619c

Na ez a legtöbb embernek nem mond semmit a kód ismerete nélkül (nyugi, az adminoknak se), viszont tökéletes kiinduló alap, hogy megnézzük, hogy ismert stack-ről van e szó (IBM jó szokása, hogy sokszor mellékelnek stack példát az ismert bugokhoz, így csak a stack ismeretével is el lehet indulni valamerre (Ha meg nem találunk semmit, akkor is rossz esetben a stack-el nyitni lehet egy PMR-t és hivatalos segítséget kérni).

Esetünkben mondhatni mázlink van: A 'get_diskstats adp_get_diskstats dt_CollectDiskData dt_CollectData itmTranslator site:ibm.com' google keresőszavak meglehetősen sok találatot adnak. A legjobb találat azt hiszem ez az oldal ahol 4 helyen is szinte azonos stack van (minimális eltérésekkel), így már csak arra kell rájöjjünk, hogy az oldalon említett IF0004 (version 6.2.2.2 FP4) valóban megoldja e a problémát. Ehhez persze nem árt tudni, hogy most épp milyen szinten van a progink :)

Erre ITM6 alatt 2 verzió van:
- Ha az UX agent is telepítve van, akkor /opt/IBM/ITM/aix526/ux/bin/itmver.sh script segítségével ki lehet kérni bármelyik agent verzió számát (sajna ez az én VIO-mon nem volt fent)
- A /opt/IBM/ITM/registry/ mappa alatt lévő file-ből ki lehet nézni a verziót direktben (grep a VRMF stringre) :)

server@root #  # grep VRMF /opt/IBM/ITM/registry/vaaix*.ver
 VRMF = 06220102

Jelen esetben ez a következőt jelenti: version 06.2.2.01.02 -> 6.2.2.1 FP02.

Bingó. /* Nem véletlenül standard policy az, hogy frissíts ha teheted, mert a hibák nagyja már esélyes, hogy javítva van */

Corrupt system dump - Nem bírja a rendszer, szívjál még egyszer..

Sajnos az elmúlt időszakban inkább project jellegű munkákkal kellett foglalkozzak (ami inkább a tervezési munkálatokat fed le), mint sem tényleges rendszer üzemeltetéssel (ami meg az esetleges hibák debugolását), így el kellett telnie némi kis időnek, míg valami fincsi problémára rá tehettem a kezem.
Most viszont végre sikerült valami kellemesbe is belekóstolnom :)

A történet előzménye röviden a következő: Adott egy nem épp up-to-date AIX rendszer, ami hirtelen dobott egy hátast, plusz a hozzá járó kernel dumpot, és ki kéne deríteni, hogy pontosan mi a fene lehetett a háttérben (az applikáció eléggé nem szereti a magasabb AIX levelt, így mielőtt ráböföghetném, hogy "AIX-et kéne frissíteni wazze" még be kell bizonyítanom, hogy valóban az AIX volt e a ludas). Tekintve, hogy az ilyen jellegű vizsgálódások annyira nem állnak tőlem távol, így örömmel kezdtem neki a probléma megoldásának, bár az örömöm nem tartott sokáig..

Kezdésként nézzük a helyzetet:

# oslevel -s
5300-08-02-0822

// No igen.. Ennek a TL-nek a hivatalos supportja még 2010 Áprilisában járt le, ráadásul még 2010 Májusban kiadtak hozzá az SP10-et. Ez az SP még 2008ban jött ki, szóval gondolhatjátok, hogy milyen régi applikáció futhat rajta, ami miatt még az AIX-et se merik upgrade-elni..

# errpt | head -3
IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION
67145A39   0325114513 U S SYSDUMP        SYSTEM DUMP
F48137AC   0325114213 U O minidump       COMPRESSED MINIMAL DUMP

Jó.. Szóval legalább az alapok meg vannak.. Nézzük, hogy mire számítsunk:

# errpt -aj 67145A39
---------------------------------------------------------------------------
LABEL:          DUMP_STATS
IDENTIFIER:     67145A39

Date/Time:       Mon Mar 25 11:45:00 NFT 2013
Sequence Number: 900224
Machine Id:      00CD98ED7C00
Node Id:         application_server
Class:           S
Type:            UNKN
Resource Name:   SYSDUMP         

Description
SYSTEM DUMP

Probable Causes
UNEXPECTED SYSTEM HALT

User Causes
SYSTEM DUMP REQUESTED BY USER

        Recommended Actions
        PERFORM PROBLEM DETERMINATION PROCEDURES

Failure Causes
UNEXPECTED SYSTEM HALT

        Recommended Actions
        PERFORM PROBLEM DETERMINATION PROCEDURES

Detail Data
DUMP DEVICE
/dev/dumplv
DUMP SIZE
            2147483136
TIME
Mon Mar 25 11:40:12 2013
DUMP TYPE (1 = PRIMARY, 2 = SECONDARY)
           2
DUMP STATUS
          -2
ERROR CODE
           0
DUMP INTEGRITY
This dump may be unusable - The alloc_kheap component is missing. 
This dump may be unusable - The alloc_other component is missing. 
This dump is incomplete - The end-of-dump component is missing. 

FILE NAME

PROCESSOR ID
           0

Tehát a rendszer váratlanul megállt, de a keletkezett dump nem teljes.. Innen indul a kihívás..

Tekintve, hogy van egy minidump-unk, így legalább abban reménykedhetünk, hogy abból ki tudunk valamit hámozni. Erre a legegyszerűbb az mdmprpt parancs.

# mdmprpt 
MINIDUMP VERSION 4D32
***************************************************
64-bit Kernel, 108 Entries

Last Error Log Entry: 
         Error ID: 9AA1914A      Resource Name: SYSVMM 
         Detail Data: 0000000042000000 00007FFFFFFFD080 
        F10001005DDD11F0 FFFFFFFFFFFFFFF3

This minidump is corrupted

Meg se lepődök.. Tekintve, hogy a dump-unk incomplete, így nem is vártam konzisztens dump-ot, bár a corrupt dump azt jelenti, hogy esélyünk nincs ezt az entry-t ellenőrizni. Egyedül annyi derül ki, hogy az utolsó jegyzett hiba a 9AA1914A error ID-ra mutat, ami a SYSVMM-hez köthető. Gyors segítség: VMM - Virtual Memory Manager, így innentől már sejthető, hogy itt valami memória művelethez köthető dolgon csúszott meg a rendszer. De azért nézzük meg, hogy a 9AA1914A error ID mit is takar a valóságban:

# grep -i 9AA1914A /usr/include/sys/errids.h
#define ERRID_DSI_MEMOVLY    0x9aa1914a /* A kernel memory overlay has been detected */

Memory overlay - teljesen fedi a VMM hatáskörét, úgy hogy eddig ez rendben is van.. Na de hogyan tovább? Ja igen.. Van még egy dumpunk. Ezt mentsük le a dump device-ról amíg lehet, aztán nézzük meg mit találunk benne:

# dd if=/dev/dumplv of=/dump_check/sysdump bs=4096 count=2147483136

// Itt megállnék egy pillanatra: Normális esetben a dump compression be van kapcsolva, ami azt jelenti, hogy a kiszedett dump-ot még ki is kéne tömöríteni a dmpuncompress paranccsal, jelen esetben viszont erre nem volt szükség, mivel a dump compression ezen a gépen nem volt bekapcsolva. Innentől lehet tippelni, hogy miért is nem fért el a dump, és hogy én ez miatt mennyire de boldog voltam.

# kdb /dump_check/sysdump
The specified kernel file is a 64-bit kernel
sysdump mapped from @ 700000000000000 to @ 70000007ffffe00
Preserving 1411195 bytes of symbol table
First symbol __mulh
Component Names:
 1)  minidump [2 entries]
 2)  dmp_minimal [9 entries]
 3)  dump_pad53 [1 entries]
 4)  proc [4101 entries]
 5)  thrd [7291 entries]
 6)  rasct [1 entries]
 7)  ldr [2 entries]
 8)  iplcb [1 entries]
 9)  errlg [3 entries]
10)  mtrc [98 entries]
11)  lfs [1 entries]
12)  bos [4 entries]
13)  ipc [7 entries]
Premature end of data in dump file.
Component Dump Table has 11523 entries
           START              END 
0000000000001000 0000000003E04050 start+000FD8
F00000002FF47600 F00000002FFDC940 __ublock+000000
000000002FF22FF4 000000002FF22FF8 environ+000000
000000002FF22FF8 000000002FF22FFC errno+000000
F100070F00000000 F100070F10000000 pvproc+000000
F100070F10000000 F100070F18000000 pvthread+000000
PFT:
PVT:
id....................0002
raddr.....0000000002000000 eaddr.....F200800090000000
size..............00080000 align.............00001000
valid..1 ros....0 fixlmb.1 seg....0 wimg...2
Unable to establish context with current thread
Unable to establish context with current thread
Unable to find kdb context
Dump analysis on CHRP_SMP_PCI POWER_PC POWER_6 machine with 32 available CPU(s)  (64-bit registers)
Processing symbol table...
.......................done
        ERROR: Unable to acess nfs_syms
(0)> where
Unable to establish context with current thread
Unable to establish context with current thread
[kdb_read_mem] no real storage @ F1000100100EE800
Unable to establish context with current thread
Unable to establish context with current thread
Unable to find kdb context
(0)> f
Unable to establish context with current thread
Unable to establish context with current thread
[kdb_read_mem] no real storage @ F1000100100EE800
Unable to establish context with current thread
Unable to establish context with current thread
Unable to find kdb context
(0)> stat
SYSTEM_CONFIGURATION:
CHRP_SMP_PCI POWER_PC POWER_6 machine with 32 available CPU(s)  (64-bit registers)

SYSTEM STATUS:
sysname... AIX
nodename.. application_server
release... 3
version... 5
build date May 12 2008
build time 23:42:11
label..... 0820A_53N
machine... 00CD98ED7C00
nid....... CD98ED7C
time of crash: Mon Mar 25 11:39:02 2013
age of system: 124 day, 7 hr., 56 min., 32 sec.
xmalloc debug: enabled
Debug kernel error message: A program has tried to store to freed or redzoned xmalloc memory.
Address at fault was 0xF10001005DDD11F0

Na akkor röviden: Az alap parancsok mind elhullanak azon oknál fogva, mert a dump-unk nem teljes, amúgy meg annyit tudunk meg mint előzőleg - memória kezelési gubancok vannak a háttérben.

Egy dolog viszont ott van amit talán lehet használni: a CDT adatok (component-dump tables), amit a kdb az elején jelzett is. Ami nekünk kelhet az jelen esetben a minidump, vagy az errlg tábla, tekintve, hogy ezek még talán tartalmazhatnak valami kis támpontot, hogy merre tovább.

Első körben én a minidump-ra koncentráltam:

(0)> cdt 1
Dump table entries in CDT:

CDT ENTRY VMHANDLE       ALIAS        ADDRESS LENGTH   NAME
  1     1 kernel             0000000002B1AA50 00000046 md head
  1     2 kernel             0000000002F1E9FC 00000E60 minidump

Tekintve, hogy a dump is tartalmazza a minidump-ot, így első körben az volt a tervem, hogy azt fogom kiszedni onnan, majd használható állapotba hozni, viszont egy részről ez -mint utólag kiderült- nem volt kivitelezhető (az okokat most nem tárgyalom), így más útvonalon kellett elinduljak
// Az minidump-al való mókolást szerintem majd egy külön blogban tárgyalom ha lesz rá érdeklődés

Mázlimra az AIX-nek van 1-2 beépített parancsa bizonyos típusú adatok kinyerésére a dump file-okból, csak ezeket valamiért a dokumentációk nem nagyon emlegetik. Az egyik ilyen parancs a dmp_minimal (ami még véletlenül sincs dokumentálva), a másik pedig az errdead (ami még úgy ahogy dokumentált).
Előző célja, hogy az elérhető minidump-ot kinyerje a dump file-ból, és megpróbálja azt értelmezni, utóbbi pedig a boot során keletkezett error logok kinyerésére használható a dump file-ból.

#  /usr/lib/ras/dmprtns/dmp_minimal /dump_check/sysdump|tail -15
traceback:
 iar:0000b920 unknown
  lr:002f7eac slock+148
addr:002f806c slock+308
addr:000090c4 unknown
addr:044901f8 store_packet+70
addr:04490880 pcd_output[DS]+98
addr:044473f8 en_output+1218
addr:0430974c ip_output_post_fw+1f50
addr:04309b04 ip_output+100
addr:0433bb44 tcp_output+2404
addr:0436d2a0 tcp_usrreq+17a8
addr:00223760 sosend+c88
addr:0023b2b8 send+4e0
addr:00003814 unknown

Na, legalább van egy stack-ünk. Megerősítésként azért nem árt átnézni az error logot is. Ehhez simán extractoljuk ki az error logot a dump-ból, majd adjuk oda az errpt-nek:

# /usr/lib/errdead -i ./errpt_out /dump_check/sysdump 
# errpt -i errpt_out
IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION
9AA1914A   0325113913 P S SYSVMM         INVALID MEMORY REFERENCE
77EED6D9   0325113913 U S SYSALLOC       Deferred-free or redzoned memory read

Hoppá. Emlékszik még valaki a 9AA1914A-es hibakódra? Igen, ez az amire az mdmprpt is panaszkodott. Legalább ez az infó is megvan akkor. Sajna azonban a 9AA1914A-es error logban nem sok használható infó van, viszont annál több a 77EED6D9-esben:

# errpt -i errpt_out -aj 77EED6D9
---------------------------------------------------------------------------
LABEL:          XM_READ_FREE
IDENTIFIER:     77EED6D9

Date/Time:       Mon Mar 25 11:39:02 NFT 2013
Sequence Number: 1
Machine Id:      00CD98ED7C00
Node Id:         application_server
Class:           S
Type:            UNKN
Resource Name:   SYSALLOC        

Description
Deferred-free or redzoned memory read

Probable Causes
LOADABLE SOFTWARE MODULE
SOFTWARE DEVICE DRIVER
OPERATING SYSTEM

Failure Causes
MEMORY ALLOCATION ERROR

        Recommended Actions
        PERFORM PROBLEM DETERMINATION PROCEDURES
        CONTACT YOUR LOCAL IBM SERVICE REPRESENTATIVE

Detail Data
Stack Trace
slock+11C
slock+304
[90C0]
store_packet+6C
pcd_output[DS]+94
en_output+1214
ip_output_post_fw+1F4C
ip_output+FC
tcp_output+2400
tcp_usrreq+17A4
sosend+C84
send+4DC
[3810]
-errSTKfrm-

Mint látható, a 2 parancs által szerzett stack kb azonos (annyi különbséggel, hogy az errpt az ismeretlen hívások helyére valami -nekünk irreleváns- címet illesztett be), így nyugodtak lehetünk, hogy jó nyomon járunk.

Jó, de innen hova tovább? Azt nem tudjuk megnézni, hogy a regiszterekben milyen adat volt, a forráskódhoz nem férünk hozzá, hogy tudjuk minek és hol is kéne pontosan lennie, csupán egy stack állapotunk van. Ez miatt általában azt szoktam mondani, hogy tessék utána járni, hogy van e olyan APAR, ami hasonló, vagy (ami még jobb) azonos stack-et produkál e, ugyan is ekkor szinte biztosak lehetünk, hogy abba a bug-ba sikerült belebotlanunk, de még hasonlót se találtam ami ilyesmi stack-et írt volna le (a 2 unknown hívás meg pláne nem segít semmit).

Na innentől általában egyenes út a software call felé, de szinte biztos, hogy ilyen dump-al ők se tudnak sokat kezdeni, plusz mivel enyhén outdated AIX level-t futtatunk, így csuklóból közölnék, hogy ez a verzió nem támogatott, illetve ajánlatos lenne azonnal update-elni, mivel azóta már jó pár javítás kijött, és hátha valamelyik erre is megoldást nyújtana.

// Itt akár be is fejezhetném ezt a blog bejegyzést, ugyan is technikailag már sok újdonságot nem fogok leírni, viszont akit érdekel a teljes történet, annak azért leírom, hogy hogy is folytatódik ez a kis történet.

Na szóval. A probléma ezzel a felállással innentől az, hogy az ember 2 szék között a pad alá kerül rövid úton, úgy hogy ez így nem játszható.
Van azonban még 1 kis aranyágacska, amin el lehet indulni: A stackben látható pcd_output hívás nem része a standard AIX hívásoknak, így kis kutakodás után sikerült kideríteni, hogy azt egy extended kernel module biztosítja, ami az IBM RealSecure Server-hez (aka ISS) tartozik, ami akkor szintúgy bekavarhat, úgy hogy ennek a szálnak is utána kell járni.

// Megjegyzés: az ISS egy extra védelmi réteget húz a hálózati kommunikáció elé, és monitorozza a hálózati forgalmat. Ha valami gyanúsat észlel, akkor azt elvileg képes megfogni, így biztosítva némi IDS funkcionalitást. Az outdated AIX verzióra való tekintettel ennek jelenléte még teljesen érthető is..

Első körben a kérdés az, hogy milyen modul biztosítja azt a hívást.. 2 lehetőség van ennek kiderítésére: Vagy rátámaszkodunk a naming convention-re, és azt mondjuk, hogy a pcd_output hívás valószínű valami pcd szerű driver hozza, vagy megnézzük, hogy az ISS csomagban van e, és ha igen, akkor milyen driverek vannak a csomagon belül.

# lslpp -l |grep ISS
  ISSXss.ServerSensor        7.0.0.0  COMMITTED  IBM RealSecure ServerSensor
  ISSXss.ServerSensor        7.0.0.0  COMMITTED  IBM RealSecure ServerSensor
  
# lslpp -f ISSXss.ServerSensor |grep driver
/usr/lib/drivers/
/usr/lib/drivers/pcd.ext

Na.. Így már biztosabbak lehetünk a dolgunkban. Következő kérdés, hogy a modul valóban be volt e töltve a dump pillanatában.. Irány vissza a kdb-be, majd listázzuk ki a betöltött modulokat, és szűrjünk arra amit találtunk:

(0)> lle -k |grep pcd.ext
  9 03EDDB00 0448C000 00016150 00080252 /usr/lib/drivers/pcd.ext

Bingo.. Tehát be volt töltve. Innentől akkor már csak az a kérdés, hogy ez okozta e a hibát, avagy az AIX. 100%-ra pontosan persze nem tudjuk megmondani, de azt azért érdemes megnézni, hogy az ISS-ünk is outdated-e.

Na itt kezdődött a következő problémám.. A hivatalos IBM javítások között a legfrissebb verzió a 7.0.42.2, a rendszeren viszont semmiféle utalás nincs a pontos verzióra nézve, csupán a csomag 7.0.0.0-ás verziószáma, ami viszont véletlenül se használható támpont.
A végleges megoldás végül az lett, hogy leszedtem a javítást az IBM FixCentral oldaláról, kicsomagoltam a base64 encode-olt telepítőt (így kaptam egy BFF csomagot), abból kibontottam a tényleges file-okat, és összehasonlítottam a checksum értékeket a rendszeren lévőkkel: Egyeztek -> Tehát ebből a programból legalább a legfrissebb verzió volt telepítve a gépre.

// Ez úton is üzenném minden programozónak, hogy valami nyamvadt verziózást rakjatok már bele a programotokba, különben lehetetlen lesz lekövetni, hogy épp mikor kell frissíteni az adott szoftvert.

Tehát a felállás innentől a következő: Van egy program, aminek a kernel module-ja szinte biztos, hogy szerepet kapott a hibában, viszont az a jelenlegi legfrissebb verzió, ergo vagy sikerült egy olyan bugba belebotlani, amire még vagy nincs javítás, vagy még nem is ismert, vagy tényleg az AIX outdated státusza okozta a galibát, és kompatibilitási hibával állunk szemben. Utóbbit sajna biztosra meg nem lehet mondani, mivel a hivatalos dokumentum véletlenül se taglalja, hogy van e TL/SP függősége, így nem maradt más hátra, mint közölni a customerrel, hogy nagy eséllyel tényleg frissíteni kéne az AIX-et (Minimum felrakni a legutolsó Service packot ehhez a TL-hez; azt az applikáció nagyobb eséllyel éli túl, mint mondjuk egy TL upgrade-et), bekapcsolni a dump compression-t, és ha az után is előjön a probléma, akkor újabb SW call-t nyitni. Ha ez nem kivitelezhető, akkor sorry, de ez egy olyan known risk amivel együtt kell majd élnie.

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