AIX DLPAR logok (Dynamic Logical Partitioning )

AIX

Az AIX es a POWER hardver kozott egy Linux alapu appliance, a HMC (Hardware Management Console) kozvetiti az eroforrasokra vonatkozo informaciokat.A topologia 


AIX OS
   \ rsct daemon (IBM.DRM) <-[LAN]- HMC RSCT stack -[HMC LAN]-> FSP/hypervisor (hardver)
                                      |
                                     user

A folyamat

  • A user DLPAR muveletet kezdemenyez (pl 4GB memoria elvetele) a HMC feluleten keresztul
  • A HMC kiadja az eroforras-allokacios utasitast a hardvernek a hdwr_svr daemonon heresztul ('low level'), ezt a kerest a Linux alapu FSP (Flexible Service Processor) a management halozaton TCP/IP-n fogadja es a belso soros porton tovabbitja a firmware-nek.
  • Ha a firmware visszaszol, hogy rendben, a HMC egy masik daemonja (IBM.LparCmdRMd ?) az RMC protokollon keresztul, 'publikus' TCP/IP kapcsolaton at jelzi a valtozast az AIX OS-nek es megvarja, hogy az utasitast az operacios rendszer lekezelje, ha tudja
  • Az AIX-en futo IBM.DRM processz elinditja a drmgr-t, ami az adott utasitast vegrehajtja.
  • Ha ez is lefutott, az AIX is visszajelez a HMC-nek

Az egeszben engem az erdekel, hogy mikent lehet az egyes komponensek muveleteit nyomon kovetni, ezert irom most ezt a bejegyzest.

HMC

/var/hsc/log/evt_processor.log

Ez egy plaintext log, elvileg read-only a hscroot szamara (masik userrel fut), tehat egyedul ennek lehet bizonyito ereje. Sajnos ezt kicsit alaassa, hogy nagyon nehez az adott user sessiont felgongyoliteni, hiszen jellemzoen a hscrootot hasznalja mindenki.

Rengeteg adat van benne, egy konkret log ott, ahol keves a DLPAR muvelet:
- 4 honap: 450.000 sor, 18MB

Kell az LPAR ID meg a gep sorozatszama, ebbol lehet osszerakni az egrepnek a sort, a firePropertyChange() hivasa jelenti a tenyleges muveletek lefutasat. 


# egrep "firePropertyChange.*Name=\"5\*9117-MMA\*10ABCDE.*Mem" evt_processor.log

Ebbol aztan konkretan ilyen sorok szarmaznak: 


2010-07-29 15:19:57.382 [Thread-104] CVOBJPVT :: com.ibm.hmc.cv.mom.CvPartitionProvider.firePropertyChange() with id = 
com.ibm.hmc.cv.mom.CvPartition[CreationClassName="IBMHSC_Partition", Name="5*9117-MMA*10ABCDE"], 
propertyName = CurAllocMem, oldValue = 24576, newValue = 22528

Szepen latszik, hogy ez jelen esetben 2GB elvetelet jelenti az adott LPAR-tol. A logban odatekerve sokkal tobb info is van, de ezt mar felesleges lenne ide beszurni. Ugye milyen szep, hogy ez az egesz Java?

---

/var/hsc/log/cimserver.log

Brutalisan debug szinten fut, es nagyon porog (~700k sor/ora kb 50 LPAR eseten), rotalva van, a tomoritett logok a /var/hsc/log/cimLogs/ ala kerulnek. Nem is hiszem, hogy nagyon kellene.

Authentikacio es a parancsok futtatasa a cimserver.logban van... Az alabb lathato DLPAR muvelet pl benne van, sot a fentiek is, csak mivel sokkal tobb az info, ezert nehezebb benne visszakeresni (a HMC-n restricted bash van, gunzip, zgrep nincs benne... sot meg atiranyitas sincs).

Amit a belepesekrol meg lehet tudni: az ssh, illetve a webUI login is bekerul a syslogba: 


# grep HMC /var/log/messages

Nov  8 20:20:01 hmc HMC: User hscroot has logged on from location 10.1.1.1 to session id 5.  The user's maximum role is "hmcsuperadmin".
Nov  8 20:20:01 hmc HMC: User hscroot of session 5 is using user interface "Tree Style".
Nov  8 20:21:37 hmc HMC: User hscroot has logged off from session id 5 for the reason:  The user logged off.

Utobbit egy HMC paranccsal is meg lehet nezni: 


# lssvcevents -t console

Aztan hogy ezt hogyan lehet a HMC belso logjaira kivetiteni...

Tehat a kovetkezo infok vannak:
- syslogban: user, IP, login/logout datum, HMC session ID (pl "5")
- cimserver logban: IP, timestamp, PID (pl "Thread-96--955188"), egy ismeretlen ID (pl "7c12e656-d90f-1000-8ac5-000d600b11ea"), ILLETVE a lefuttatott muveleteknel a Java thread ID

AIX

drmgr: syslog local1 facility

/var/adm/ras/syslog

Vagy ahova be van allitva (default: nincs log!). Itt ilyeneket lehet latni egy DLPAR muvelet lefutasa soran: 


Nov  7 14:05:03 hostname local1:info DRMGR:  ==== Start: MEM Removal operation ====
Nov  7 14:05:03 hostname local1:info DRMGR: Starting CHECK phase for mem Remove operation.
Nov  7 14:05:03 hostname local1:info DRMGR: Phase CHECK started for scripts,kernel extensions and applications.
Nov  7 14:05:03 hostname local1:info DRMGR: Starting CHECK phase for Scripts.
Nov  7 14:05:03 hostname local1:info DRMGR: Completed the phase for Scripts.
Nov  7 14:05:03 hostname local1:info DRMGR: Starting the phase for kernel extensions.
Nov  7 14:05:03 hostname local1:info DRMGR: Completed the phase for kernel extensions.
...
Nov  7 14:07:17 hostname local1:info DRMGR:  ~~~~ End: DR operation ~~~~

cfgmgr: alog cfglog

/var/adm/ras/cfglog

Binaris log, amiben a cfgmgr (AIX device manager), azaz a kernel es a driverek szintjen torteno muveletek nyomait latjuk, viszont sajnos a timestamp lenyegeben hasznalhatatlan. Szerencses esetben a file datuma elarulhat valamit. Az alog paraccsal olvashato.

Az elejen latszik az aktualisan lefuttatott parancs, sajnos a drmgr nem teljesen dokumentalt es user altal abszolut csak vegszukseg eseten futtathato: 


CS 1716320 471056 /usr/sbin/drmgr -r -c mem -q 32 -w 5 -d 1
C4 1716320 get_sub_arg returning:0x2ff22e1b(5)
C4 1716320 get_sub_arg returning:0x2ff22e20(1)
C4 1716320 DBG level var:0xffffffe1 bp_tmp:1
CS 1716320 471056 /usr/sbin/drmgr -r -c mem -q 32 -w 5 -d 1
C4 1716320      p_specified: 0 p_arg:
C4 1716320      badargs: 0
C4 1716320      operation: 2 (1:add, 2:remove)
C4 1716320      drc-names: **
C4 1716320      timeout value (in seconds) : 300
...

A vege fele viszont van timestamp es ott az eroforras mennyisege is, itt 4GB: 


C4 1716320 invoke_DR_scripts: command:3, bp_resource:mem
C4 1716320 user_time:300, current time: 0x4cd010f6, DR start time: 0x4cd010f6
C4 1716320 DR Timeout value:300, Current time: 0x4cd010f6, DR start time: 0x4cd010f6, Remaining Time:300
C4 1716320 get_remaining_time returning: 300
C4 1716320 Invoking script (/usr/lib/dr/scripts/all/wpar_drs) with command (checkrelease)
C4 1716320 invoke_one_DR_script: entry->command:3, timeout:10, script idx:2, resource name: mem
C4 1716320 set_env_vars: entry: cmd : checkrelease
C4 1716320 set_env_vars: exit: DR_FORCE=FALSE DR_MEM_SIZE_REQUEST=4096 DR_TRUE_MEM_SIZE_REQUEST=4096 DR_MEM_SIZE_COMPLETED=0 DR_TRUE_MEM_SIZE_COMPLETED=0 DR_FREE_FRAMES=0x60ea DR_PINNABLE_FRAMES=0x30d5ec DR_TOTAL_FRAMES=0x700000 DR_TRUE_TOTAL_FRAMES=0x700000

Kar, hogy a timestampekbol sok ertelmes nem jon ki (se epoch, se mmddHHMM): 


# echo 4cd010f6 | tr -s [[:lower:]] [[:upper:]] | bc
53301156
  • 5113 megtekintés

( LGee | 2010. 11. 08., h – 22:14 )

Tudom, hogy ez igy onmagaban nem sokra jo, de legalabb elkezdtem leirni, amiket talaltam.

( lx | 2010. 11. 09., k – 01:24 )

Teljesen rendben van az a ts, csak hiányzik a bc-nek az ibase=16:


{ echo ibase=16; echo 4cd010f6 | tr -s '[[:lower:]]' '[[:upper:]]' ;} | bc | awk '{print strftime("%c\n", $1)}'
Tue Nov 2 14:24:06 2010

Azért ebben ne legyél annyira biztos. Nálam legalábbis totál mást ad ibase-zel és a nélkül: 


$ echo 4cd010f6 | tr -s [[:lower:]] [[:upper:]] | bc
49901096
$ { echo ibase=16 ; echo 4cd010f6 | tr -s [[:lower:]] [[:upper:]] ; } | bc
1288704246

Jav, és persze más, mint ami nálad van.

Sajnos nem. _Valamit_ csinál a hexával az alap megadása nélkül is, de nem jövök rá, hogy mit.

$>uname -a
AIX vaclpar02 3 5 00CBA8004C00
$>lslpp -w /usr/bin/bc
File Fileset Type
----------------------------------------------------------------------------
/usr/bin/bc bos.rte.misc_cmds File
$>lslpp -l bos.rte.misc_cmds
Fileset Level State Description
----------------------------------------------------------------------------
Path: /usr/lib/objrepos
bos.rte.misc_cmds 5.3.12.0 COMMITTED Miscellaneous Commands

$>bc
4CD010F6
53301156
F
15
FF
165
ibase=16
4CD010F6
1288704246
F
15
FF
255

ugh... tenyleg elegge el lehettem foglalva, most nezem, miert nem epoch lett a hexabol!! 


2128    alog -o -t cfg | tail -100
2129    alog -o -t cfg
2130    echo 4cd010f6 | tr -s [[:lower:]] [[:upper:]]
2131    echo 4cd010f6 | tr -s [[:lower:]] [[:upper:]] | bc
2132    echo "ibase:16;4CD010F6" | bc
2133    date +%s
2134    w

Kettospont volt az egyenlosegjel helyett, a hiba meg nem tunt fel ;-)

Perlben konnyu osszerakni egyetlen sorba:

# echo "4cd010f6\\c" | perl -wle '$decimal = hex(<STDIN>); print scalar localtime($decimal)'
Tue Nov 2 14:24:06 2010

Ezt a tr-es baromsagot meg ideje lesz elfelejtenem.

( Zahy v | 2010. 11. 09., k – 07:20 )

Abban a restricted bash környezetben van esetleg env parancs (*) ? (Amugy ha jól tudom, lehet benne átirányítani, bár csak korlátozottan:

man (pd)ksh:
redirections that create files can't be used.

Az már más kérdés, hog a ksh93 és a bash manjából is hiányzik az a kitétel, hogy "amelyek létrehoznak fájlt".)

(*) Egyelőre a env és az ln parancsokkal tudok kijönni restricted shell-ből, de ez utóbbihoz kell még egy nem teljesen jól beállított PATH is, míg az előbbihez nem. Mondjuk a PATH legvégén van egy ilyen: $HOME/bin, akkor teljesen triviális: 


$ ln -s /bin/sh ~/bin/nemrestricted.sh
$ nemrestricted.sh

És máris kijöttél a restricted shell-ből.

Itt nem lehet kijonni, nincs env, ln meg... hahaha, szep is lenne.
Atiranyitas meg a /dev/null-ba sem megy.

Egyaltalan valami alias-szeruseget irni is csak ugy tudok, hogy egy rnvi nevu editorral letrehozok egy file-t, amiben a sorokban function-oket hozok letre, aztan read-del huzom be oket.

Amugy ez egy 'sima' rbash.

Megnéztem kicsit jobban az átirányítást. Volt egy olyan rémképem, hogy talán átirányításban nem lehet elérési utat adni, de akárhogy is játszottam vele, akár helyi, akár máshol levő, akár létező, akár nem létező - nem ment se rbash-sal, se rpdksh-val. A ksh93-t már meg se próbáltam, de ezek szerint a pdksh man-oldala kicsit pontatlan. (Vagy én nem találtam meg az a helyzetet, ahol tényleg neki van igaz.)

Shellvaltozokba torteno atiranyitas es shellvaltozo stringmanipulaciok is korlatozva vannak?

(ha sed, *awk nincs, akkor eleve egy beteg dolog csovezetekek es adat ki-be scp/rcp nelkul logokat elemezni... *grep -p viszont anno logfeldolgozasnal jol jott tobbsoros bejegyzeseknel. Mar nem emlekszem, hogy HMC-n vagy logexport utan egy teljes aix-on kovettem-e el)

http://www.youtube.com/watch?v=QXz7-BNC6jw
http://nocirc.org/

Amikor megszaladt az ssh, és logok a fagyásig feltöltöttek mindent, kolléga egy közönséges knoppix live cd-vel tisztította ki a dzsuvát, és ugyanaz segített, amikor módosítani kellett a HMC által kitalált X drivert, mert rosszul találta ki.

Akár binárist is másolhatott volna rá...