Régen blogoltam ide, de úgy gondoltam hogy ez még jól jöhet az utókornak, szóval ...
.. Adott egy ősrégi Solaris szerver (az a fajta ami a múzeumba se való már, olyan régi), aminél azt a feladatot kaptam, hogy a Storage szerverek zónázásakor használt WWPN numbert kinézzem. Tekintve hogy ez számomra alap feladatnak hangzott (AIX adminként), így gondoltam gyorsan végzek is a feladattal.. Hát a francokat..
Na nézzük miért is.
1) Mint mondtam a gép meglehetősen régi:
root@server[] # uname -a
SunOS server 5.6 Generic_105181-39 sun4u sparc SUNW,Ultra-Enterprise
/* Csak a miheztartás végett - az 5.6ot (aka Solaris 2.6) 1997ben adták ki (bár 2006ig támogatott maradt) */
2) A google jelen esetben nem a barátod
Hiába akad google-n 1-2 használhatónak tűnő tipp*, attól még sajna ez kevés a boldogsághoz ha a tippek közül egyik se működik, mert vagy nem elérhető a parancs amire hivatkozik, vagy nem kapok kimenetet, vagy amit kapok az láthatóan hülyeség.
-> scli, fcinfo, prtpicl, lputil64 nem létezik
-> 'prtconf -vp | grep -i wwn' hülyeséget dob vissza
-> /var/adm/messages* alatt egy bejegyzes sincs amiben a wwn vagy wwpn benne lenne
-> 'luxadm -e port' szerint az összes adapter not-connected state-ben van ami abszolút hülyeség, viszont ez miatt a 'luxadm -e dump_map' se működik.
-> 'iostat -XMzxn' közli, hogy a -X, -z kapcsoló nem értelmezhető
* A leghasználhatóbb talán ez: http://www.sunsolarisadmin.com/hardware/how-to-find-the-wwn-world-wide-name-in-sun-solaris/
3) Nem mindegy hogy milyen adapter van a gépben és hogy milyen driver hajtja
Az egy dolog, hogy csak 1-2 hivatalosan támogatott kártya elérhető, de mocskos módon még az se mindegy, hogy azt a kártyát milyen Storage megvalósításhoz szeretnéd használni, mert mindegyik megvalósításnak más-más driver kell, azok meg hajlamosak meglehetősen válogatósak lenni a támogatott kártyák között.
Ehhez jön még hozzá, hogy nincs egységes tool a HBA-k kezelésére, hanem minden driverhez külön-külön utility set van ami így vagy úgy valósítja meg kb ugyan azokat a feladatokat (lscfg, de hiányoltalak én téged..)
4) Az se mindegy, hogy melyik verziójú drivered van fent
Mint utólag kiderült a 2. pontban leírt problémámba ay is erősen közrejátszott, hogz az idők során kiadott különböző driverek/toolok telepítési útvonala hajlamos volt időről időre változni, így ha nincs bent a $PATH-ban az adott tool akkor vagy tudod mi és hol van, vagy keresgélhetsz amíg meg nem találod (már ha tudod mit is kéne pontosan keresni)
Na szóval.. Ha tudni akarod, hogy hogy is kell megtekinteni egy HBA WWPN-jét, akkor:
- Tudnod kell, hogy pontosan milyen kártyáról van szó
- Tudnod kell, hogy az adott kártyát milyen driver hajtja
- Tudnod kell, hogy az adott driver tooljai hol találhatóak
- Tudnod kell, hogz a toolok közül melyik is alkalmazható a te általad megálmodott feladatra, és azt is hogyan.
Hát gyerekek. Aki a Linux alatt sír hogy mennyire össze van gányolva, és hogy mennyire de nem egységes, azt isten bizony odaültetném egy ilyen elé.
Na de vissza térve az én esetemre.
- Milyen HBA van a gépben?
root@server[] # prtdiag -v |grep SBus |grep sd
1 SBus 25 0 lpfs/sd (block) LP9002S
1 SBus 25 3 SUNW,fas/sd (block)
3 SBus 25 1 QLGC,isp/sd (block) QLGC,ISP1000U
3 SBus 25 2 lpfs/sd (block) LP9002S
3 SBus 25 3 SUNW,fas/sd (block)
5 SBus 25 1 QLGC,isp/sd (block) QLGC,ISP1000U
5 SBus 25 2 QLGC,isp/sd (block) QLGC,ISP1000U
5 SBus 25 3 SUNW,fas/sd (block)
- Lehet is nyomban válogatni, tekintve, hogy 2 is van. Az 1ik ránézésre valami QLogic cucc (sd driver-rel), a másik meg csak annyit mond magáról, hogy LP9002S. Kis google után utóbbiról kiderül, hogy 2Gbps Emulex Fibre channel adapter, míg az első egy sima SCSI vezérlő (így azzal most nem foglalkozok). Annyi segítséget a gép adott, hogy az Emulex kártyát az lpfs driver hajtja, így már csak azt kell kitalálni, a driverhez tartozó segédprogramok hol is találhatóak
- Első körben tudni kell a csomag nevét:
root@server[] # pkginfo |grep lpfs
system lpfs Emulex LightPulse FC SCSI/IP Host Bus Adapter driver
- Ebből kiindulva aztán érdemes megnézni, hogy mi is van a csomagban:
root@server[] # pkgchk -l lpfs|grep Pathname |egrep "bin|sbin"
Pathname: /usr/sbin
Pathname: /usr/sbin/lpfs
Pathname: /usr/sbin/lpfs/QS_fmw
Pathname: /usr/sbin/lpfs/REV_fmw
Pathname: /usr/sbin/lpfs/dfc
Pathname: /usr/sbin/lpfs/dfc32
Pathname: /usr/sbin/lpfs/dfc64
Pathname: /usr/sbin/lpfs/download_fmw_lpfs
Pathname: /usr/sbin/lpfs/lpsutil
Pathname: /usr/sbin/lpfs/lpsutil32
Pathname: /usr/sbin/lpfs/lpsutil64
Pathname: /usr/sbin/lpfs/resetqdepth
- Oksi. Akkor a /usr/sbin/lpfs mappában kéne körbenézni. Kérdés, hogy mi is használható ezek közül.
Az mondjuk kb tiszta, hogy a QS_fmw és a REV_fmw valami firmware féleség lehet, így azokhoz inkább nem nyúlok. A download_fmw_lpfs hasonló okok miatt esik ki (lekérdezni akarok, nem módosítani). A dfc-ből, illetve az lpsutil-ból a jelek szerint 3-3 file is elérhető: 1 központi, illetve 1-1 32/64 bit specifikus (Ránézésre a fő bináris feladata, hogy megítélje, hogy a rendszer 32 vagy 64 bites rendszeren fut e, és az alapján meghívja a szükséges binárist). Ezen felül van még a resetqdepth, ami a nevéből illetően piszkálni akar valamit, viszont mint kiderül lényegében csak egy script:
root@server[] # cat /usr/sbin/lpfs/resetqdepth
#!/bin/sh
# $Id: resetqdepth.sh 1.6 2001/03/07 00:12:00 mks Exp $
case $1 in
[0123456789]*)
;;
*) echo Usage: resetqdepth adapter_number
exit 1
;;
esac
/usr/sbin/lpfs/dfc > /dev/null <<!
set board $1
rqdepth
exit
!
exit 0
Természetesen ezt lefuttatni nem akarom, viszont a tény hogy a fentebb említett dfc parancsra támaszkodik egy EOF here tag-el ad némi reményt arra hogy esetleg valami belső parancs készletre támaszkodó programmal van dolgunk.
Így hát elindítva a dfc programot az alábbi kimenetben gyönyörködhetünk:
root@server[] # /usr/sbin/lpfs/dfc
LightPulse Engineering Debug Utility
Copyright (c) 1999, 2000 Emulex Network Systems, Inc.
Do not run this utility unless instructed by Emulex Technical Support
Found 0 PCI 2 SBUS adapters: onmask 3f58f offmask 1e7 Driver:4.21x1
Adapter 0: lpfs1 SBUS id df1095f0 Firmware:3.90A7 (R2F3.90A7)
Adapter 1: lpfs0 SBUS id df1095f0 Firmware:3.90A7 (R2F3.90A7)
cmd>
Szupi.. Szóval kapunk egy belső command line-t.. Nézzük mit lehet benne mókólni (és lehetőleg nem elszúrni :))
cmd> help
rdallpci wrpci wrhc wrhs
wrha wrca rdpci rdhc
rdhs rdha rdca rdmb
exit set rring rslim
riocb rrpi rbp rmemseg
mbox reset rbinfo nddstat
fcstat wslim wffreg rffreg
sdiag dbg rnode rdevp
instance lip linkinfo ioinfo
nodeinfo getcfg setcfg failio
outfcpio rqdepth ct hbaattr
portattr portstat dportattr wportattr
iportattr fcpmap fcpbind setmgmt
getmgmt rnid getevent resetstat
sendscsi refresh els getmpulse
setmpulse listn trace help
p
Sajna a fejlesztők arra már nem szánták rá magukat, hogy a help parancsot kibővítsék az alparancsok leírásával is, így némi kis próbálkozás után sikerül eljutnom csak az alábbi kimenethez:
cmd> linkinfo
Event 0x0 Up 0x1 Down 0x0 Multi 0x0
PortID 0x0 alpa 0x0 topology 0x4 state 0x1
ALPAmap 0:
Portname 10:00:00:00:ab:cd:ef:01 Nodename 20:00:00:00:ab:cd:ef:01
Na ez már végre az amit akartam.. Az egyedüli bajom csak az, hogy a parancs ismételt kiadásával ugyan ezt az eredményt kapom vissza, viszont ebben a gépben (ahogy fentebb is látható volt) 2 HBA kártya van.. Valahogy rá kéne venni a programot, hogy a másik kártya adatait is le lehessen kérdezni.
Ekkor ugrott be a fenti script, ami képes volt tetszőleges adapterre lefuttatni az rqdepth parancsot. Mindezt a set board $1 parancsal, úgy hogy nyomban mentem is vissza az újonnan megismert subshellem alá további tesztelésre:
root@server[lpfs] # ./dfc
LightPulse Engineering Debug Utility
Copyright (c) 1999, 2000 Emulex Network Systems, Inc.
Do not run this utility unless instructed by Emulex Technical Support
Found 0 PCI 2 SBUS adapters: onmask 3f58f offmask 1e7 Driver:4.21x1
Adapter 0: lpfs1 SBUS id df1095f0 Firmware:3.90A7 (R2F3.90A7)
Adapter 1: lpfs0 SBUS id df1095f0 Firmware:3.90A7 (R2F3.90A7)
cmd> set board 0
cmd> linkinfo
Event 0x1 Up 0x1 Down 0x0 Multi 0x0
PortID 0x633613 alpa 0x13 topology 0x3 state 0x6
ALPAmap 0:
Portname 10:00:00:00:ab:fd:08:04 Nodename 20:00:00:00:ab:fd:08:04
cmd> set board 1
cmd> linkinfo
Event 0x0 Up 0x1 Down 0x0 Multi 0x0
PortID 0x0 alpa 0x0 topology 0x4 state 0x1
ALPAmap 0:
Portname 10:00:00:00:ab:cd:ef:01 Nodename 20:00:00:00:ab:cd:ef:01
cmd> exit
Buli.. Igy mar szepen megy is minden, mint a karika csapás. Akkor már csak az maradt, hogy le is scriptljük a dolgot:
root@server[] # cat /tmp/emulex_wwpn_query.sh
#!/usr/bin/ksh
PACKAGE_NAME=`pkginfo |grep SCSI |egrep "lpfc|lpfs" |cut -d ' ' -f2`
DFC_PATH=`pkgchk -l $PACKAGE_NAME |grep Pathname |grep dfc$ |cut -d ' ' -f2`
while true
do
$DFC_PATH 2>&1 << !
exit
!
break
done |grep Adapter |cut -d ' ' -f 2 |sed "s/://g" |while read ID
do
$DFC_PATH 2>&1 << !
set board $ID
linkinfo
exit
!
done |grep Portname |cut -d ' ' -f 2 |sed "s/://g" |tr 'a-z' 'A-Z'
root@server[] # sh /tmp/emulex_wwpn_query.sh
10000000ABCDEF01
10000000ABFD0804
Trolloknak előre megjegyzem: ezen az ősrégi vackon a pipe feldolgozási sorrendje nem tudom miért de valahogy eltér a megszokottól; a $() nem működik, helyette van backtick (`), az viszont valamiért nem szeret több parancsot 1 soron belül látni; Talán pont a pipe-olás miatt az awk se működik úgy ahogy azt elvárnám, így fallbackeltem az ódivatú parancsokra, mint cut, grep, sed, tr (amit amúgy egy awk simán ki tudna váltani, viszont ha nincs ló, jó lesz a szamár is.. ).
Amúgy ha valakinek van ötlete, hogy while; do ... done módszeren kívül hogy lehet még greppelni egy here tag (jelen esetben !) után az ne fogja vissza magát :)
