Ú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:
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 # 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 :))
Mai nap esett meg velem a következő: Mountolni akartam egy távoli NFS-en keresztül kiosztott FS-t, de Murphy épp nevetős kedvében volt és az alábbi üzenettel örvendeztetett meg:
client # mount server:/export /mnt
nfsmnthelp: 1831-019 9.149.40.8: System call error number -1.
mount: 1831-008 giving up on:
server:/export
System call error number -1.
Hát jó.. akkor induljunk neki a szokásos problem determinationnek:
- Az NFS mountolás során első körben az alábbi dolgok történnek (a teljesség igénye nélkül):
A kliens lekéri az NFS szerver IP címét (mivel ugye nem IP-vel akartunk csatlakozni) a géptől. Ennek pontos módja ugye a /etc/netsvc.conf-ban, illetve a /etc/resolv.conf-ban van tárolva.
Ha sikerül neki feloldani az IP címet, akkor megpróbál a távoli géppel egy standard RPC kommunikációt kiépíteni (port 111), majd az adott erőforráshoz (amit én hülye mountolni akarok) hozzáférni. Ezt persze vagy hagyja a szerver vagy sem. Ettől függetlenül azért ez nem egy lépéses játék -> csak az előbb felsorolt dolgokat 3 főbb pontra bontanám:
- IP feloldás
- RPC kommunikáció
- Resource hozzáférés (ide kapcsolnám az authentikációt is)
Persze ezek mellett még van jó pár dolog, de most így első körben azokkal nem törődök.. Nézzük át, hogy a fenti folyamatokhoz szükséges beállítások hogy is vannak:
- Nézzük meg, hogy a /etc/netsvc.conf hogy is próbálkozik a név feloldással:
Aham.. szóval ez jónak tűnik. Mind a szerver, mind a kliens a /etc/hosts-ot nézi első körben (local), majd megy a bind felé (IPv4en), ahogy az szerver esetén várható is.
Akkor nézzük tovább. van e bármiféle IP feloldás
client # host server
server is 192.168.1.10 server # host client
client is 10.1.0.20
A host szerint van (ne feledjük el, hogy a host parancs a /etc/netsvc.conf szabályain keresztül nézi ki az IP-t, ahogy azt általában az alkalmazások is teszik). Tekintve, hogy az alkalmazásoknak amúgy is a local felé kell fordulniuk 1x, így ezeket az IP-ket kénytelenek leszünk elfogadni (persze azért nem árt ellenőrizni, hogy a 2 IP valós e - ergo, hogy nincs e elszúrva a /etc/hosts-unk)
Akkor ezek után nézzük meg, hogy a standard hálózat él e mondjuk (sima ICMP, de a teszt erejéig jó lesz)
client # ping -c1 server
PING server (192.168.1.10) 56(84) bytes of data.
64 bytes from server (192.168.1.10): icmp_seq=1 ttl=243 time=75.6 ms
--- server ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 75.690/75.690/75.690/0.000 ms
server # ping -c1 client
PING client (10.1.0.20) 56(84) bytes of data.
64 bytes from client (10.1.0.20): icmp_seq=1 ttl=243 time=75.6 ms
--- client ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 75.690/75.690/75.690/0.000 ms
Az ICMP csomagok szépen átmennek, ergo a 2 gép eléri egymást.
# Note - jelen esetben a 2 gép 2 külön hálón van, viszont rálátnak egymás hálózataira, így ennek nem szabadna hibának lennie.
Persze lehet hogy van még tűzfal a 2 között, így nem árt ellenőrizni azt se, hogy a kliens rálát e a szerverre, és annak szolgáltatásaira:
Ez alapján én azt mondanám, hogy gyönyörűen látja a kliens amit kell. Ráadásul a showmount kimenetéből láthatjuk azt is, hogy az adott megosztás mindenki számára elérhetőnek kéne lennie.. Ezt azért ha lehet nem árt tényleg leellenőrizni is:
server # lsnfsexp
/export -rw
Ez alapján tényleg azt mondom, hogy ennek így jónak kéne lennie. (ha ezek közül valami nem megy, akkor nyomban gyanakodhatunk firewall/routing, vagy valami network típusú hibára )
2. lépésben szoktam nézni a rendszer (jelen esetben AIX) specifikus függőségeket.
Az egyik ilyen alap függőség, hogy az adott mappa (ahova mountolni akarunk) létezik e (tudom triviális, még is sokszor megszivatja az embert ,ha figyelmetlen):
server # ls -ld /mnt
drwxrwxrwx 229 root system 20480 07 Jun 13:05 /mnt
Persze általában ezt nem nézzük ennyire be, így a következő amire figyelni kell az az NFS beállítások mind a kliens, mind a szerver oldalon. Ezek közül is 2 van, ami az authentikációért felelhet (az NFS szabályokon felül) olyan módon, hogy kötötté teszik a standard portok használatát:
client # nfso -a |grep port
nfs_use_reserved_ports = 0
portcheck = 0 server # nfso -a |grep port
nfs_use_reserved_ports = 0
portcheck = 0
Általában illik a szerver és a kliens oldalnak ezen beállításokban egyezniük, mert ha nem az simán okozhat ilyesmi hibát. Sajna azonban itt nem ez a helyzet.
Ha ezek után se szokott menni, akkor szoktam azt a randa játékot játszani, hogy azt hiszem, hogy nem én, hanem az NFS szerver a hülye, így simán megpróbálom törölni, majd újra létrehozni az NFS megosztást ( tudom, Windows-os beütés, de néha működik)
server # smitty rmnfsexp server # smitty mknfsexp
A probléma ott van, hogy nálam ezek után se működött a dolog, így végső kétségbeesésként megpróbálkoztam egy teljes NFS restartal :) - ki tudja, hátha beragadt valami:
server # stopsrc -g nfs server # stopsrc -s portmap server # rm -rf /etc/state /etc/rmtab /etc/xtab server # startsrc -s portmap server # startsrc -g nfs server # exportfs -a
A gáz onnan indult, hogy még ezek után se ment a játék.. Más kliensek gond nélkül fel tudták csatolni a megosztást, de ez az 1 makacsul nem engedett.
Ekkor döntöttem el, hogy akkor nézzük meg mélyebbről is a játékost - tracelgessünk kicsit:
Fejvakarás, töprengés... Wattafák... Vissza az alapokhoz..
Az stimt, hogy a kapcsolat kialakításához kell egy IP kapcsolat (ami megy is az előző lekérések alapján), viszont belegondolva van az NFS-nek egy olyan funkciója, hogy "reverse name lookup". Ez a funkció elvileg arra hivatott, hogy garantálja, hogy a kliens a szerverrel, illetve a szerver a kliensel beszél az által, hogy a kapcsolat felépítésekkor leelenőrzi azt, hogy a kiépülendő kapcsoalat valóban a 2 fél között jönne e létre.
Ezt valahogy úgy próbálja megcsinálni, hogy:
- A kliens valahogy feloldja a szerver IP címét, majd erre megpróbál csatalakozni
- A kapcsolat során elküldi azt, hogy ő kicsoda, illetve mi is az IP címe
- A szerver reigsztrálja a kérést, majd megnézi, hogy a kliens az ő névfeloldása alapján valóban az e, akinek állítja magát (ergo csinál vissza fele is egy névfeloldást)
- Amennyiben a feloldott IP egyezik azzal, ahonnét jött a kapcsolat akkor megy tovább a kapcsolat kiépítésével
- Természetesen a kliens is eljátsza ugyan ezt (hiszen RPC kommunikációról beszélünk), és ha már ott jár, akkor a szervertől kapott azonosítóval megnézni, hogy valóban jó géppel akar e autholni
Ez security oldalról tényleg értelmes dolog.. Hiába van egy világnak megosztott NFS megosztásom, attól még nem akarom, hogy ezt valaki kihasználva bármi csúnyaságot csináljon. Szerver esetében ugye átalában a netsvc.conf alatt a local az elsődleges rule, így ez miatt erősen ajánlott, hogy mind a kliens, mind a szerver tudjon a másik pontos címéről a /etc/hosts alatt.
A probléma az, hogy ugye ezt ellenőriztük fentebb.. Őőő.. vagyis nem teljesen.. Mint mondtam a vissza azonosítás oda vissza irányul -> Kell az is, hogy a gép önmagáról is "hiteles" adatot küldjön.. És itt volt a kutya elásva: A szerver oldalon a 'server' más IP címmel volt felvéve a /etc/hosts alatt (az ok egyszerű: A 'server' alapból egy másik alhálózatért felel, és azokat a kapcsolatokat meg csak ezen keresztül érheti el).
Ez miatt viszont az egész reverse name lookup meghiusul, mi meg nézhetjük a földön gyülekező hajtömegetet és a ráncokat a tükörbe..
A megoldás ezek után adná magát: Írjuk át a szervernél a /etc/hosts-ban a 'server' IP címét.. A probléma az, hogy ebben a környezetben, ahol a szerver másik alhálóért is felel (vagy inkább azt tekinti elsődlegesnek) ezt nem teheti meg az ember, mert a végén másik kliensel szúr ki.
Akkor viszont marad a másik útvonal: Ki kéne kapcsolni ezt a biztonsági funkciót.. A kérdés csak, hogy hogyan.
Nos.. a vicc a következő: A mountolás ezen fázisában ezért a funkcióért az rpc.mountd felel a szerver oldalon.. Ennek meg a vicc kedvéért van egy nem nagyon dokumentált kapcsolója, amit az ODM alá felvéve gyönyörűen lehet semlegesíteni ezt a működést. Az átállítás módja kb így néz ki:
server # stopsrc -s rpc.mountd server # chssys -s rpc.mountd -a "-x" server # startsrc -s rpc.mountd
Ez után, akkor próbálkozunk újra:
client # mount server:/export /mnt client # mount |grep mnt
server /export /mnt nfs3 12 Jul 08:59
Elkezdtem dolgozni az XIV-s scriptemen (amit még az előző postomnál megemlítettem) és úgy gondoltam, hogy milyen jó is lenne, ha kb úgy működne a script, mint az SDD/SDDPCM pcmpath/datapath parancsa (egy vezérlő parancs, amivel mindent administrative taskot szépen meg lehet csinálni).
Megyeget is szépen a fejlesztés (első körben még csak a query parancsok), és el is jutottam a 'query essmap' részhez, ahol is le lehet kérni a connection detaileket (az adott LUN melyik SAN Rack, melyik Module, melyik portján közlekedik felénk - hasznos kis információ hibakeresés esetén)..
Ez ugye pcmpath/datapath alatt valahogy így néz ki:
test_server@root:/ # datapath query essmap|head -3
Disk Path P Location adapter LUN SN Type Size LSS Vol Rank C/A S Connection port RaidMode
------- ----- - ----------- ------ ----------- ------------ ---- ---- --- ----- ---- - ----------- ---- --------
vpath0 hdisk6 6p-08-02[FC] fscsi3 xxxxxxx0400 IBM 2107-900 32.8GB 4 0 0004 29 Y R1-B3-H1-ZA 200 RAID5
Ami nekem ebből kellett az az 'R1-B3-H1-ZA'. Ugyan ezt akarom én is megvalósítani az XIV-s scriptem 'query essmap' részénél.. Na de nézzük hogyan...
Mint kiderült - ezt is ki lehet bányászni ODM-ből (CuPath alatt connection attributum utolsó 3 karaktere), de sajna ezt már nem lehet 1 az 1ben konvertálni ahogy néztem (vagy csak még nem jöttem rá pontosan hogyan).
Sebaj mondom, az XIV is nagyban épít az MPIO-ra, ahogy az SDDPCM is, annak meg van pcmpath parancsa, ami ezeket az infókat gyönyörűen kiadja, úgy hogy akkor induljak ki abból, nézzük össze az adatokat, és akkor az alapján dolgozzunk.
Némi kis keresgélés után kiderült, hogy SDDPCM alatt ugyan úgy a CuPath alatt kell keresni az adatokat, csak ott nem a végén, hanem kicsit máshol, de ugyan úgy megvan. Így aztán elkezdtem írni egy kis scriptet ami ezeket összegyűjti nekem, és amiből aztán majd egy kedves kis mátrixot csinálhatok, hogy mi és merre..
Aztán ahogy gyűltek az adatok észrevettem, hogy ugyan ezen kiosztás érvényes az SDD esetében is és ott meg a datapath alatt ugyan úgy elérhetőek ezek a Connection infók, szóval kicsit kibővítettem a scriptem, hogy lekezelje az SDD-os ODM bejegyzéseket is (ez kivételesen már a CuAt alatt van) és összeszedtem amit tudtam.
Az eredmény: Egy egész kellemes kis script:
#!usr/bin/ksh
SDDPCM=0
SDD=0
export ODMDIR=/etc/objrepos
if [ `lslpp -l |grep -wc devices.sddpcm` -gt 0 ]
then
SDDPCM=1
MAIN_COMMAND="pcmpath"
fi
if [ `lslpp -l |grep -wc devices.sdd` -gt 0 ]
then
SDD=1
MAIN_COMMAND="datapath"
fi
$MAIN_COMMAND query essmap > /tmp/$MAIN_COMMAND.query.essmap
for i in $(awk '{print $14}' /tmp/$MAIN_COMMAND.query.essmap |sort|uniq |grep ^R);do grep -w $i /tmp/$MAIN_COMMAND.query.essmap |head -1;done |awk '{ sub("path", ""); print $1,$2,$14}' > /tmp/connection.check
while read LINE
do
if [ $SDDPCM -eq 1 ]
then
set -A array $LINE
DISK=$(print ${array[0]})
CONN_PATH=$(print ${array[1]})
CONNECTION=$(print ${array[2]})
# In case of SDDPCM 11-13 contain the right identifiers in CuPath
CONN_IDENTIFIER=$(odmget -q "name=$DISK and path_id=$CONN_PATH" CuPath|awk -F "\"" '/connection/ {print $2}'|cut -c 11-13)
elif [ $SDD -eq 1 ]
then
set -A array $LINE
DISK=$(print ${array[1]})
CONNECTION=$(print ${array[2]})
# In case of SDD
CONN_IDENTIFIER=$(odmget -q "name=$DISK and attribute=ww_name" CuAt|awk -F "\"" '/value/ {print $2}' |cut -c 13-15)
fi
Na mondom éljen.. Megvan minden szépen ahogy kell.. Nézzük ezt össze az XIV-s kapcsolatokkal.. És kopp - XIV alatt jóvolta több kapcsolat van, mint amiket én kigyűjtöttem, ami azt jelenti, hogy ez a mátrix max részben használható jelenleg..
Most bújom a DS8000 és az XIV Architecture guide-jait, hogy megnézzem milyen durva különbségek vannak még amiről tudnom kéne :)))
Stay tooned :)
Szerk:
na végül erre is fény derült :))
- > DS8000 series alatt a Bay1-8 az a DS hátán elhelyezett I/O enclosure-öknek felelnek meg (SG246452 PDF 44. oldal), míg XIV esetében ez kicsit másként néz ki: Igaz, hogy jóvolta több kapcsolódási lehetősége van, viszont Fibre kapcsolatra csupán 6 I/O module-ja van (SG247659 PDF 81. oldal) amelyek számozása Module 4-9ig tart (ergo Bay1-4 variáció itt totál kiesik). Minden module rendelkezik 4-4 portal kapásból, amiket aztán rá lehet kötni a közeli Fibre switchre.
Ez után viszont akkor ez azt jelenti, hogy az SDD/SDDPCM-nél megszokott konnekciós ábrázolás bukott, helyette valami ilyesmi használható XIV esetén:
Ergo jelen esetben akkor ez a kapcsolat a Rack 1, Module 4 1. portjáról jön ( az ODM-ben a számozás 0-3ig van, az XIV-n meg 1-4ig, ergo ott azt 1el kell növelni), tehát a nevezéktan valami ilyesmi lehetne: R1-M3-C1
(Az SDD/SDDPCM query essmap outputja végén lévő ZA/ZB/ZC/ZD(?) elvileg a Fabric-et jelöli. Annak még megpróbálok utánajárni, hogy kinyerhető e valahogy :)
Te hogy kérdezed le egy XiV-ról kapott LUN ID-ját, illetve, hogy melyik XiV-ról is jön az adott LUN?
Nos.. Az alapvető válasz egyszerű: A HAK csomagon belül elérhető az xiv_devlist parancs, amit megfelelően felparaméterezve ('xiv_devlist -o all', vagy 'xiv_devlist -v') kidobja nekünk az összes XIV-hez csatolt LUN információját, abból meg kedvünk szerint szűrhetünk grep-el, awk-al, akármivel.. Nincs is ezzel baj.. Na jó... egy kicsi még is - ez a módszer iszonyat de lassú (de legalább színes),főleg ha scripteléshez is szeretnénk valamely adatot használni, arról ne is beszéljünk mi van akkor, ha sok diszkünk van az XiV-hez csatolva (lassú == csiga)
Úgy hogy kicsit elkezdtem turni, hogy hogy is lehetne ezt sokkal gyorsabban megvalósítani.. Nos.. VAN MEGOLDÁS.. Bár jól eldugták..
Az utat ahogy eddig eljutottam nem írom le (legyen elég annyi, hogy szívatós, főleg ha rászámolom, hogy a nyomozás egyik szakaszában a teljes rootvg-t végiggreppeltem az adott string után kutatva :)), úgy is inkább az eredmény érdekli az embereket..
Akkor lássuk hát:
Alapjáraton megszoktam, hogy mind SDD,SDDPCM,MPIO drivereknél az adott LUN ID-ja kinyerhető az ODM-ből.. Erre szolgál ugyan is az unique_id attributum (odmget-el, vagy lsattr-al lekérhető). XiV-s diszknél (hiába támaszkodik félig meddig az MPIO-ra) ez mintha mégse lenne így meg (az elején legalább is nagyon nem így tünt). De nézzük meg közelebbről ezt a stringet..
Az adott ODM attributumban persze semmi hasonló nincs.. Egészen addig amíg az ember el nem kezdi boncolgatni.. Mint kiderült: Ott van az.. Csak nézzük kicsit másként azt a stringet:
261120017380005660F32072810XIV03IBMfcp
Na akkor mit is bányászhatunk ki:
0566 - Ez az XiV boxunk azonosítójának utolsó 4 jegye (jelen esetben) hexában tárolva -> 1382
0F32 - Ez pedig a LUNID-nk szintén hexában tárolva -> 3890
/* Azt majd még meg kéne nézni, hogy a 0-ák a string elején mennyire konstansak, de jelen esetben nálam erre nem volt szükség */
Ergo akkor némi kis scripteléssek ki lehet szedni az aktuális azonosítókat, immár kifejezetten gyorsabban:
#Edit:
Az ODM entry-ben lévő '2810XIV' utal arra, hogy XiV-s LUN-ról van szó. Ugyan ez DS8k box esetében is megtalálható, csak akkor a '2107900'-es stringre kell figyeljünk
Nézegettem google-n, de 0 találat volt erre az issue-ra, szóval gondoltam leblogolom a megoldást :)
Na szóval. Ha valaki abban a "szerencsében" részesült, hogy XiV-s Storage-ot kell használnia, és ne addj isten az alábbi hibaüzenetet kapja a kliens oldalon:
# lsxiv -v
XIV Non-MPIO ODM device entries are inconsistent for hdisk0. Please contact your IBM service representative to reinstall the XIV support packages.
reinstall a jó anyját, helyette nézzük meg hogy az adott disk alatt a scsi_id nem e duplikálódott:
# lsattr -El hdisk0 |grep -c scsi_id
2
Tehát de... Ez viszont azt jelenti, hogy az ODM-ünk valószínű nem épp normális, úgy hogy kicsit nyomozzunk a PdAt körül, mivel ez felel a listázandó attributumokért..
Nagyszerű.. Akkor most futassuk ismét az lsxiv-t :)
# Megjegyzés: amennyiben az unique_id lenne duplikáltan, akkor "XIV ODM device entries are inconsistent ..." hibaüzit kapjuk btw..
Igen.. Ilyen is van.. Héten egy AIX 5.2-5.3-as Alternate install-al egybekötött migrációval foglalkoztam, ahol is az rsct subsystem, és annak függőségei eléggé makacsok voltak. A történek kb ott kezdődik, hogy az alternate install lefutott, és mivel semmi sem tökéletes, így az új rendszert bebootolva az fogadott, hogy hát 1-2 fileset-et nem bírt a drágája átmigrálni 5.3ra.. Uccu neki, ilyenkor nincs mit tenni, neki kell állni kézzel javítani.
Az egyik ilyen makacskodó állat volt az rsct.basic.. Tekintve, hogy az installer se tudta átdobni az 5.3-as AIX-nek szükséges levelre(2.4.x.y), így én se csodálkoztam amikor ezt így nekem se akarta.. Akkor hát nem volt más, előre, induljon a dózer. http://pastebin.com/f19dad711
Ezek után akkor elő az 5.3-as AIX base fileset-jeit, majd a 3. CD-ről dobjuk fel a 2.4-es rsct.base-t. Ekkor ért az első meglepetés: Az rsct.basic-nek függősége az rsct.core.. Jó hát ha ilyen igények vannak, akkor azt teljesíteni kell.. első CD, rsct.core, felrak, örül, vissza rsct.basic-hez.. http://pastebin.com/f5e9a9057
Mi van??? Fel akarom rakni a base-t (2.4.4.0), és közli velem, hogy neki dependency a 2.4.11.0???? Ez hülye.. De hát jó.. Ki tudja milyen lábbal kelt fel a szerver.. Csináltam egy mappát, belepakoltam az base filesetet, meg mindent ami a 2.4.11.0-nak kell:
$ > ls -l
total 983456
-rw-r--r-- 1 root system 26586 Jul 01 20:21 .toc
-rw-r--r-- 1 root system 29831168 Jul 01 20:10 rsct.basic
-rw-r--r-- 1 root system 307200 Jul 01 20:11 rsct.basic.hacmp.2.4.1.0.U
-rw-r--r-- 1 root system 191488 Jul 01 20:11 rsct.basic.hacmp.2.4.10.0.U
-rw-r--r-- 1 root system 197632 Jul 01 20:11 rsct.basic.hacmp.2.4.11.0.U
-rw-r--r-- 1 root system 307200 Jul 01 20:11 rsct.basic.hacmp.2.4.2.0.U
-rw-r--r-- 1 root system 166912 Jul 01 20:11 rsct.basic.hacmp.2.4.2.0.bff
-rw-r--r-- 1 root system 167936 Jul 01 20:11 rsct.basic.hacmp.2.4.4.0.bff
-rw-r--r-- 1 root system 171008 Jul 01 20:11 rsct.basic.hacmp.2.4.5.0.bff
-rw-r--r-- 1 root system 173056 Jul 01 20:11 rsct.basic.hacmp.2.4.6.0.bff
-rw-r--r-- 1 root system 172032 Jul 01 20:11 rsct.basic.hacmp.2.4.7.0.bff
-rw-r--r-- 1 root system 191488 Jul 01 20:11 rsct.basic.hacmp.2.4.8.0.bff
-rw-r--r-- 1 root system 29132800 Jul 01 20:11 rsct.basic.rte.2.4.1.0.U
-rw-r--r-- 1 root system 51982336 Jul 01 20:12 rsct.basic.rte.2.4.10.0.U
-rw-r--r-- 1 root system 52751360 Jul 01 20:12 rsct.basic.rte.2.4.11.0.U
-rw-r--r-- 1 root system 40960000 Jul 01 20:12 rsct.basic.rte.2.4.2.0.U
-rw-r--r-- 1 root system 29413376 Jul 01 20:12 rsct.basic.rte.2.4.2.0.bff
-rw-r--r-- 1 root system 29537280 Jul 01 20:12 rsct.basic.rte.2.4.4.0.bff
-rw-r--r-- 1 root system 40118272 Jul 01 20:12 rsct.basic.rte.2.4.5.0.bff
-rw-r--r-- 1 root system 48615424 Jul 01 20:12 rsct.basic.rte.2.4.6.0.bff
-rw-r--r-- 1 root system 47081472 Jul 01 20:12 rsct.basic.rte.2.4.6.2.bff
-rw-r--r-- 1 root system 49917952 Jul 01 20:12 rsct.basic.rte.2.4.7.0.bff
-rw-r--r-- 1 root system 50698240 Jul 01 20:12 rsct.basic.rte.2.4.8.0.bff
-rw-r--r-- 1 root system 204800 Jul 01 20:12 rsct.basic.sp.2.4.1.0.U
-rw-r--r-- 1 root system 121856 Jul 01 20:12 rsct.basic.sp.2.4.10.0.U
-rw-r--r-- 1 root system 120832 Jul 01 20:12 rsct.basic.sp.2.4.11.0.U
-rw-r--r-- 1 root system 204800 Jul 01 20:12 rsct.basic.sp.2.4.2.0.U
-rw-r--r-- 1 root system 119808 Jul 01 20:12 rsct.basic.sp.2.4.2.0.bff
-rw-r--r-- 1 root system 119808 Jul 01 20:12 rsct.basic.sp.2.4.4.0.bff
-rw-r--r-- 1 root system 119808 Jul 01 20:12 rsct.basic.sp.2.4.5.0.bff
-rw-r--r-- 1 root system 119808 Jul 01 20:12 rsct.basic.sp.2.4.6.0.bff
-rw-r--r-- 1 root system 120832 Jul 01 20:12 rsct.basic.sp.2.4.7.0.bff
-rw-r--r-- 1 root system 120832 Jul 01 20:12 rsct.basic.sp.2.4.8.0.bff
Szava nem lehet, gondoltam én.. Hát még is volt: http://pastebin.com/f7d0ae795
Óóó éljen.. Miért is lenne jó az élet..A 2.4.11.0-nak most meg szintén függőségi baja van, csak mostmár a 2.4.0.0-ra! Gondolom őt elfelejtették arról tájékoztatni, hogy a base az 2.4.4.0..
Na innentől meg had ne mondjam mi jött.. manuális .toc file hegesztés, ODM, meg ami belefér.. Mindhiába.. Aztán a végső megoldás a következő lett: telepítsük az egész bagázst ( függőségektől, meg mindenestül ) from scratch, hátha attól megnyugszik a drágája.
- Tehát első körben akkor vissza a tervező asztalhoz, ismét legyalulni mindent, ami rsct-ből fentvolt.
- Hozzunk létre egy mappát, amiben az összes rsct-hez füződő játékos ott áll szépen katonasorban:
$ > ls -l
total 126080
-rw-r--r-- 1 root system 3864 Jul 01 20:32 .toc
-rw-r--r-- 1 root system 29831168 Jul 01 20:24 rsct.basic
-rw-r--r-- 1 root system 2580480 Jul 01 20:30 rsct.compat.basic
-rw-r--r-- 1 root system 519168 Jul 01 20:37 rsct.compat.clients
-rw-r--r-- 1 root system 31616000 Jul 01 20:39 rsct.core
- Aztán térdre imához, majd telepítsük az egész hóbelebancot (1x csak preview-ban): http://pastebin.com/f5fd7bd81
Majd élesben is: http://pastebin.com/f993d1c7
Juuuhhéééé.. innen már lehet upgrade-elni az összes file-setet a már meglévő patch-ekkel egészen fel 2.4.11.0-ig :))
