Automatisierung von Inventory Scout

Sie verwenden bisher Inventory Scout noch gar nicht oder nur gelegentlich manuell? Sie wollen Inventory Scout automatisiert auf allen Systemen laufen lassen, mit möglichst wenig Aufwand?

Dann sollten Sie sich unseren Artikel Automatisierung von Inventory Scout in der Rubrik Artikel / AIX anschauen. Dort wird anschaulich beschrieben welche Schritte nötig sind, um Inventory Scout automatisiert auf Systemen ablaufen zu lassen. Im Download-Bereich haben wir das Skript run_invscout zur Verfügung gestellt, das im Artikel beschrieben ist. Das Skript erlaubt von einem NIM-Server aus, mit nur einem Aufruf das aktuellste catalog.mic File von IBM herunterzuladen, auf beliebig viele NIM-Clients zu kopieren, auf den NIM-Clients einen Lauf von Inventory Scout zu starten und dann anschließend die Microcode Survey Upload Files von den NIM-Clients einzusammeln. Als letztes werden die Upload Files nach IBM MDS hochgeladen zur Analyse.

SUMA Proxy-Konfiguration

Um SUMA mit Proxy zu konfigurieren gibt es im Web eine Reihe von Dokumenten. Einige der älteren Dokumente beschreiben noch die Konfiguration von Proxies über Attribute von SUMA:

# suma -c -a HTTP_PROXY=http://10.0.0.1:49000
0500-019 The -a flag entry HTTP_PROXY=http://10.0.0.1:49000 is not valid. (main, /usr/sbin/suma [767])
0500-009 An error occurred attempting to save configuration settings. (main, /usr/sbin/suma [768])
# suma -c -a HTTPS_PROXY=https://10.0.0.1:49000
0500-019 The -a flag entry HTTPS_PROXY=https://10.0.0.1:49000 is not valid. (main, /usr/sbin/suma [767])
0500-009 An error occurred attempting to save configuration settings. (main, /usr/sbin/suma [768])
# suma -c -a HELLO=world
0500-019 The -a flag entry HELLO=world is not valid. (main, /usr/sbin/suma [767])
0500-009 An error occurred attempting to save configuration settings. (main, /usr/sbin/suma [768])
#

Leider werden die Attribute HTTP_PROXY und HTTPS_PROXY von SUMA nicht mehr unterstützt. Dies ist auch in der Manual Page von SUMA dokumentiert!

# man suma
...
HTTP_PROXY and HTTPS_PROXY
     Proxy server and port to use for the HTTP or HTTPS transfers. The SUMA command shares
     the proxy connectivity settings with the Electronic Service Agent\u2122. The HTTP or HTTPS
     proxy service configuration can be set up through the SMIT Create/Change Service
     Configuration menus (use fastpath smitty srv_conn) that allow the server
     specifications such as IP address, port number, and an optional user ID and password.
     SUMA no longer supports the settings of the HTTP_PROXY and HTTPS_PROXY parameters.

Die Proxy Konfiguration wird von ESA (Electronic Service Agent) übernommen. D.h. aber auch das Proxies über ESA konfiguriert werden müssen. Hierzu muss das Fileset bos.ecc_client.rte installiert sein. Dieses sollte aber installiert sein, da es ein Prerequisite für bos.suma ist.

Konfiguriert werden, können die Proxies entweder mittels SMIT oder über die Kommandozeile. Wir zeigen zunächst die Variante über die Kommandozeile:

# /usr/ecc/bin/config_conn_path -c PRIMARY -y HTTP_PROXY -t YES -a 10.0.0.1 -x 49000
###########################################################

Testing HTTP Proxy Service Configuration

Performing HTTP Proxy Connectivity Test ... SUCCESS
#

Die IP-Adresse des Proxy wird mit der Option ‚–a‚ angegeben, die Port-Nummer mit der Option ‚–x‚. Wenn ein Benutzer zur Authentifizierung notwendig ist, kann dieser mit der Option ‚–u‚ angegeben werden (das Passwort wird interaktiv abgefragt). Die Option ‚–t YES‚ sorgt dafür, das unmittelbar ein Verbindungs-Test gemacht wird, der hier erfolgreich war.

Neben der primären Verbindung (PRIMARY), können optional auch noch eine sekundäre (SECONDARY) und tertiäre (TERTIARY) Verbindung konfiguriert werden. Die aktuelle Konfiguration, z.B. für die primäre Verbindung kann man sich wie folgt anschauen:

# /usr/ecc/bin/config_conn_path -d PRIMARY
#type:ttyport:modem_type:primary_location:secondary_location:prefix:host:port:userid
HTTP_PROXY::::::10.0.0.1:49000:
#

Das Schlüsselwort ‚PRIMARY‚ kann mit ‚p‚ abgekürzt werden.

Ein Verbindungs-Test kann jederzeit mittels Option ‚–t YES‚ oder ‚–t y‚ gestartet werden:

# /usr/ecc/bin/config_conn_path -c p -t y
###########################################################

Testing HTTP Proxy Service Configuration

Performing HTTP Proxy Connectivity Test ... SUCCESS
#

Alternativ kann man auch SMIT verwenden:

# smitty configure_primary
…
                       Create/Change Primary Service Configuration

Type or select values in entry fields.
Press Enter AFTER making all desired changes.


                                                        [Entry Fields]
  Connection type                                    [HTTP_Proxy]                     +
  Test service configuration                         [No]                             +

  If type is DIRECT_INTERNET, no entry required.

  If type is HTTP_PROXY,
          IP address                                 [10.0.0.1]
          Port number                                [49000]                            #
          Authentication user ID                     []
          Authentication password requested interact
  ively.


F1=Help               F2=Refresh            F3=Cancel             F4=List
F5=Reset              F6=Command            F7=Edit               F8=Image
F9=Shell              F10=Exit              Enter=Do

Ein kleiner Test zeigt, das SUMA mit den konfigurierten Proxies funktioniert:

# suma -x -a DisplayName=Test -a Action=Preview -a RqType=Latest
**************************************** (main, /usr/sbin/suma [990])
Performing preview download. (main, /usr/sbin/suma [991])
**************************************** (main, /usr/sbin/suma [992])
Partition id was unassigned; will attempt to assign it.
Partition id assigned value 6
Download SUCCEEDED: /export/nim/suma/installp/ppc/U861910.bff (main, /usr/sbin/suma [1048])
Download SUCCEEDED: /export/nim/suma/installp/ppc/U861907.bff (main, /usr/sbin/suma [1048])
Download SUCCEEDED: /export/nim/suma/installp/ppc/U861904.bff (main, /usr/sbin/suma [1048])
…
Total bytes of updates downloaded: 899671552 (main, /usr/sbin/suma [1048])
Summary: (main, /usr/sbin/suma [1048])
        367 downloaded (main, /usr/sbin/suma [1048])
        0 failed (main, /usr/sbin/suma [1048])
        34 skipped (main, /usr/sbin/suma [1048])
DEBUG: Closing file handles (SUMA::Messenger, /usr/suma/lib/SUMA/Messenger.pm [401])
#

AIX: Probleme mit Run-Time Linking

Vermutlich hat schon jeder einmal Probleme mit AIX und Run-Time Linking gehabt. Z.B. wenn ein Programm beim Aufruf mit dem folgenden Fehler abbricht:

$ progXY
exec(): 0509-036 Cannot load program progXY because of the following errors:
        0509-150   Dependent module libXXX.a(shr.o) could not be loaded.
        0509-022 Cannot load module libXXX.a(shr.o).
        0509-026 System error: A file or directory in the path name does not exist.
$

In unserem Artikel AIX und Run-Time Linking erklären wir die Abläufe beim Run-Time Linking, sowie mögliche Fehler. Wir zeigen wie man ausführbare Programme und Bibliotheken mit dem Kommando dump untersucht. Außerdem wird die Bedeutung der Variablen LIBPATH und LD_LIBRARY_PATH für das dynamische Linking erklärt.

WWPN von FC-Ports in der Open Firmware

 

Der folgende Beitrag beschäftigt sich mit WWPN von FC-Ports in der Open Firmware.

Port- und Node-WWN von FC-Ports lassen sich über die Open Firmware sehr leicht herausfinden, auch wenn das ioinfo Kommando bei neuer POWER9 Firmware nicht mehr verfügbar ist. Der Hardware-Aufbau eines POWER-Systems ist in der Open Firmware in Form eines Device Baums verfügbar. Hardware-Komponenten, wie PCI-Bridges, Prozessoren oder PCI-Karten werden als Device Knoten in diesem Baum abgebildet.

Mit dem Kommando „dev /“ kann man, beginnend mit dem Root-Knoten („/“ oder Slash), auf die Device-Knoten zugreifen:

0 > dev /  ok
0 >

In dem Device Baum kann man sich mit den Kommandos dev, ls und pwd ähnlich wie im Unix Dateisystem bewegen. Ein ls auf dem Root-Knoten zeigt alle verfügbaren Device Knoten (sowie einige „Package-Knoten“, auf die hier nicht eingegangen werden soll).

Durch Einrücken der Device Knoten wird die Hierarchie im Device Baum dargestellt:

0 > ls 
0000020939c0: /ibm,serial
000002094ae8: /chosen
000002094d60: /packages
000002094e58:   /disassembler
...0000020af578: /cpus
0000020b5200:   /PowerPC,POWER7@0
...
0000020ba640: /memory@0
...
00000226cad0: /pci@800000020000120
00000229d750:   /pci@0
0000022a0018:     /pci@2
0000022a28e0:       /ethernet@0
0000022b4a28:       /ethernet@0,1
0000022c6b70:     /pci@4
0000022c9438:       /ethernet@0
0000022db580:       /ethernet@0,1
000002277fd8: /pci@800000020000121
0000022ed7d0:   /fibre-channel@0
0000023026e0:     /fp
000002303240:     /disk
000002304de0:     /tape
000002306270:   /fibre-channel@0,1
00000231b180:     /fp
00000231bce0:     /disk
00000231d880:     /tape
...
ok
0 >

In der Beispiel-Ausgabe sind 2 FC-Ports zu sehen. Beide FC-Ports sind Söhne des Device Knotens pci@800000020000121, welcher direkt unter dem Root Knoten / zu finden ist.

Mit dem Kommando „dev /pci@800000020000121“ navigieren wir zunächst in diesen Knoten und lassen uns dann die Unter- oder Sohn-Knoten mittels „ls“ anzeigen:

0 > dev /pci@800000020000121  ok
0 > ls
0000022ed7d0: /fibre-channel@0
0000023026e0:   /fp
000002303240:   /disk
000002304de0:   /tape
000002306270: /fibre-channel@0,1
00000231b180:   /fp
00000231bce0:   /disk
00000231d880:   /tape
ok
0 >

Wir bewegen uns als nächstes in den Device Knoten des ersten FC-Ports fibre-channel@0.

Mit dem Kommando „pwd“ überprüfen wir kurz die Position im Device Baum und schauen uns mit „ls“ anschließend die verfügbaren Unter-Knoten an:

0 > dev fibre-channel@0  ok
0 > pwd /pci@800000020000121/fibre-channel@0 ok
0 > ls
0000023026e0: /fp
000002303240: /disk
000002304de0: /tape
ok
0 >

Jeder Device Knoten besitzt eine Anzahl von Eigenschaften (Properties), welche von der Art der unterliegenden Hardware-Komponente abhängen.

Die Eigenschaften eines Device Knoten lassen sich mit dem Kommando „.properties“ anzeigen lassen (der Kommando-Name beginnt mit einem „.„):

0 > .properties
ibm,loc-code            U5802.001.008C110-P1-C2-T1
vendor-id               000010df
device-id               0000f100
...
name                    fibre-channel
...
manufacturer            456d756c 657800
copyright               436f7079 72696768 74202863 29203230 30302d32 30313220 456d756c 657800
device_type             fcp
model                   10N9824
...
port-wwn                10000000 c9b12345
node-wwn                20000000 c9b12345
...
ok
0 >

Neben dem Location-Code wird die Port-WWN (port-wwn) und die Node-WWN (node-wwn) angezeigt.

Wer mehr über den Aufbau von WWNs wissen möchte, verweisen wir gerne auf den Beitrag: Zahlen: FC World Wide Names (WWNs)

Man kann natürlich auf dem gleichen Weg auch die MAC-Adresse eines Ethernet-Ports herausfinden. Mit „dev ..“ kann man sich im Device Baum eine Ebene nach oben bewegen, ganz wie in einem Unix Filesystem. Man kann aber auch abkürzen und gleich ganz nach oben gehen, was wir hier im folgenden tun, um uns dann noch einmal alle verfügbaren Device Knoten anzeigen zu lassen:

0 > dev /  ok
0 > ls 
...
00000226cad0: /pci@800000020000120
00000229d750:   /pci@0
0000022a0018:     /pci@2
0000022a28e0:       /ethernet@0
0000022b4a28:       /ethernet@0,1
0000022c6b70:     /pci@4
0000022c9438:       /ethernet@0
0000022db580:       /ethernet@0,1
...
ok
0 >

Wir suchen uns als Beispiel den Device Knoten /pci@800000020000120/pci@0/pci@2/ethernet@0,1 aus und lassen uns wiederum die Eigenschaften anzeigen:

0 > dev /pci@800000020000124/pci@0/pci@2/ethernet@0,1  ok
0 > pwd /pci@800000020000124/pci@0/pci@2/ethernet@0,1 ok
0 > .properties
ibm,loc-code            U5802.001.008C110-P1-C4-T2
vendor-id               00008086
device-id               000010bc
...
name                    ethernet
...
device_type             network
...
max-frame-size          00000800
address-bits            00000030
local-mac-address       00145eea 1234
mac-address             00145eea 1234
...
0 >

Die MAC-Adresse ist hier über die Eigenschaft mac-address verfügbar.

Möchte man den Device Baum verlassen, so geht dies mit dem Kommando „device-end„:

0 > device-end  ok
0 >

Wir hoffen dieser Beitrag über WWPN von FC-Ports in der Open Firmware war sowohl hilfreich als auch informativ.

Fehler: 0509-022 Cannot load module

Kürzlich haben wir auf einigen unserer Systeme yum aus der AIX Toolbox (www.ibm.com/support/pages/aix-toolbox-linux-applications-overview) installiert. Bisher hatten wir RPM-Pakete von Perzl (www.perzl.org) installiert. Bei dem Umstieg auf yum wurden einige RPMs mit Versionen aus der AIX Toolbox aktualisiert. Bei einigen der RPMs gab es in Folge Probleme mit dynamischen Bibliotheken.

Wir behandeln im folgenden eines der Probleme, das bei dem Programm curl aufgetreten ist:

$ curl
exec(): 0509-036 Cannot load program curl because of the following errors:
        0509-022 Cannot load module /opt/freeware/lib/libcurl.a(libcurl.so.4).
        0509-150   Dependent module /opt/freeware/lib/libcrypto.a(libcrypto.so) could not be loaded.
        0509-152   Member libcrypto.so is not found in archive 
        0509-022 Cannot load module curl.
        0509-150   Dependent module /opt/freeware/lib/libcurl.a(libcurl.so.4) could not be loaded.
        0509-022 Cannot load module .
$

Vor der Installation der RPM-Pakete hatte curl noch funktioniert. Das Kommando ldd zum Auflisten dynamischer Abhängigkeiten liefert eine ähnliche Fehlermeldung:

$ ldd /usr/bin/curl
/usr/bin/curl needs:
         /usr/lib/libc.a(shr.o)
         /opt/freeware/lib/libcurl.a(libcurl.so.4)
         /opt/freeware/lib/libz.a(libz.so.1)
         /unix
         /usr/lib/libcrypt.a(shr.o)
         /opt/freeware/lib/libcrypto.a(libcrypto.so)
ar: 0707-109 Member name libcrypto.so does not exist.
dump: /tmp/tmpdir31457524/extract/libcrypto.so: 0654-106 Cannot open the specified file.
         /opt/freeware/lib/libssl.a(libssl.so)
ar: 0707-109 Member name libssl.so does not exist.
dump: /tmp/tmpdir31457524/extract/libssl.so: 0654-106 Cannot open the specified file.
$

Die Datei /opt/freeware/lib/libcrypto.a ist ein Archiv und die Fehlermeldung sagt das in diesem Archiv das Shared Object libcrypto.so nicht existiert. Das lässt sich mit dem Kommando ar leicht überprüfen:

$ ar -X any tv /opt/freeware/lib/libcrypto.a
rwxr-xr-x     0/0     3036810 Apr 08 18:46 2014 libcrypto.so.1.0.1
rwxr-xr-x     0/0     3510308 Apr 08 18:41 2014 libcrypto.so.1.0.1
rw-r--r--     0/0     2012251 Apr 08 18:46 2014 libcrypto.so.0.9.7
rw-r--r--     0/0     2491620 Apr 08 18:46 2014 libcrypto.so.0.9.8
rwxr-xr-x     0/0     2921492 Apr 08 18:46 2014 libcrypto.so.1.0.0
rw-r--r--     0/0     2382757 Apr 08 18:46 2014 libcrypto.so.0.9.7
rw-r--r--     0/0     2923920 Apr 08 18:46 2014 libcrypto.so.0.9.8
rwxr-xr-x     0/0     3381316 Apr 08 18:46 2014 libcrypto.so.1.0.0
$

(Die Option „-X any“ sorgt dafür das sowohl 32– als auch 64-bit Objekte angezeigt werden)

Die Shared Library libcrypto.so befindet sich offensichtlich nicht in dem Archiv! Das Archiv gehört zum OpenSSL-Paket von Perzl:

$ rpm -qf /opt/freeware/lib/libcrypto.a
openssl-1.0.1g-1.ppc
$

Das OpenSSL Paket ist auch die Ursache für die Probleme beim Aufruf von curl und eventuell auch anderen Programmen. Bei den Paketen von Perzl gibt es ein OpenSSL-Paket, welches OpenSSL unterhalb von /opt/freeware zur Verfügung stellt. Die IBM Pakete aus der AIX Toolbox verwenden aber das vom Betriebssystem kommende OpenSSL unter /usr/lib. In der AIX Toolbox gibt es daher kein OpenSSL RPM Paket. Das OpenSSL-Paket von Perzl sollte entfernt werden.

# rpm –e openssl
#

Hat man RPM-Pakete (Perzl), die von OpenSSL abhängig sind, schlägt das Entfernen des OpenSSL RPMs natürlich fehl:

# rpm -e openssl
error: Failed dependencies:
            openssl >= 0.9.8 is needed by (installed) openldap-2.4.23-0.3.ppc
#

In diesem Fall gibt es 2 Möglichkeiten: entweder man deinstalliert das abhängige Paket ebenfalls, oder man aktualisiert das Paket mit einer Version aus der AIX Toolbox. Wir zeigen hier kurz den zweiten Fall:

# yum update openldap
AIX_Toolbox                                                                                   | 2.9 kB  00:00:00    
AIX_Toolbox_71                                                                                | 2.9 kB  00:00:00    
AIX_Toolbox_noarch                                                                            | 2.9 kB  00:00:00    
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package openldap.ppc 0:2.4.23-0.3 will be updated
---> Package openldap.ppc 0:2.4.46-1 will be an update
...

Is this ok [y/N]: y

...

Updated:

  openldap.ppc 0:2.4.46-1                                                                                           

Complete!
#

Anschließend kann das OpenSSL RPM deinstalliert werden:

# rpm -e openssl
#

Nun lässt sich auch curl wieder ohne Problem starten:

$ curl
curl: try 'curl --help' or 'curl --manual' for more information
$

Fazit: Beim Wechseln auf die AIX Toolbox sollte ein eventuell vorhandenes OpenSSL RPM deinstalliert werden!

 

Virtual Processor Folding

Eine einfache und direkte Möglichkeit zu sehen welche Prozessoren aktiv sind und welche Prozessoren aufgrund von „Virtual Processor Folding“ nicht verfügbar sind, ist der Kernel Debugger kdb.

Mit dem folgenden Kommando wird die gewünschte Information angezeigt:

# echo vpm | kdb
...
VSD Thread State.
CPU  CPPR VP_STATE FLAGS SLEEP_STATE  PROD_TIME: SECS   NSECS     CEDE_LAT

   0     0  ACTIVE      0 AWAKE        0000000000000000  00000000  00  
   1     0  ACTIVE      0 AWAKE        0000000000000000  00000000  00  
   2     0  ACTIVE      0 AWAKE        0000000000000000  00000000  00  
   3     0  ACTIVE      0 AWAKE        0000000000000000  00000000  00  
   4     0  DISABLED    0 AWAKE        0000000000000000  00000000  00  
   5    11  DISABLED    0 SLEEPING     000000005D9F15BE  0F77D2C6  02  
   6    11  DISABLED    0 SLEEPING     000000005D9F15BE  0F77D0C8  02  
   7    11  DISABLED    0 SLEEPING     000000005D9F15BE  217D3F61  02  

#

Die Ausgabe wurde auf einem System mit 2 Prozessor-Kernen und SMT4 erstellt. Die CPUs 4-7 sind DISABLED, das ist der zweite Prozessor-Kern (Core).

LPAR-Tool: welche LPARs haben keine RMC-Verbindung

Status und Konfiguration von LPARs sind regelmäßig benötigte Informationen bei der Administration von LPARs. Mit dem LPAR-Tool lassen sich Informationen wie Status, RMC-Status, Anzahl Cores, Größe RAM, OS-Version und andere Daten, sehr leicht und schnell ermitteln, auch bei hunderten oder tausenden von LPARs. Welche LPARs keine RMC-Verbindung haben, wird in einem der Beispiele gezeigt.

Alle folgenden Beispiele wurden auf einer Umgebung mit 10 HMCs, 50 Managed Systems und etwas über 500 LPARs durchgeführt. Zur Orientierung wie lange das LPAR-Tool benötigt, wurden jeweils die Laufzeiten der Kommandos mit time gemessen und angegeben.

Die Namen der LPARs wurden in den gezeigten Ausgaben manuell abgeändert und durch generische Namen lparXX und aixYY ersetzt.

Zunächst einmal der Status einer einzelnen LPAR:

$ time lpar status aix01
NAME   LPAR_ID  LPAR_ENV   STATE     PROFILE    SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
aix01  27       aixlinux   Running   standard   0     active    1      0.1         8192    AIX 7.1 7100-04-02-1614

real    0m0.210s
user    0m0.011s
sys     0m0.013s
$

Natürlich kann man auch mehrere LPARs angeben. Möchte man den Status aller LPARs (in unserem Falle etwas über 500 LPARs) wissen, läßt man einfach das Argument weg:

$ time lpar status
NAME    LPAR_ID  LPAR_ENV   STATE     PROFILE      SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
aix01   27       aixlinux   Running   standard     0     active    1      0.1         8192    AIX 7.1 7100-04-02-1614
aix02   1        aixlinux   Running   standard     -     -         1      -           8320    Unknown
...
lpar01  6        aixlinux   Running   standard     0     active    1      0.4         20480   AIX 7.1 7100-04-05-1720

real	0m18.933s
user	0m3.819s
sys	0m3.789s
$

Hierbei werden im Hintergrund vom LPAR-Tool mehr als 150 Kommandos (lshwres und lssyscfg) auf den HMCs abgesetzt!

Die Ausgabe soll jetzt eingeschränkt werden auf LPARs die gerade aktiv sind (state=Running). Hierzu gibt es die Option „-s„, mit der Kriterien für Attribute angegeben werden können, die erfüllt sein müssen. Nur LPARs die diese Kriterien erfüllen, werden ausgegeben:

$ time lpar status -s state=Running
NAME     LPAR_ID  LPAR_ENV   STATE    PROFILE    SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
aix01    27       aixlinux   Running  standard   0     active    1      0.1         8192    AIX 7.1 7100-04-02-1614
aix02    1        aixlinux   Running  standard   -     -         1      -           8320    Unknown
...
lpar01   6        aixlinux   Running  standard   0     active    1      0.4         20480   AIX 7.1 7100-04-05-1720

real	0m17.998s
user	0m3.692s
sys	0m3.647s
$

Wir wollen jetzt wissen, auf welchen dieser LPARs RMC nicht funktioniert/nicht aktiv ist. Die Option „-s“ erlaubt es beliebig viele Kriterien zu kombinieren. Es müssen dann alle angegebenen Kriterien erfüllt sein (logischen UND). Der RMC-Zustand findet sich im Attribut rmc_state:

$ time lpar status -s state=Running,rmc_state!=active
NAME     LPAR_ID  LPAR_ENV   STATE    PROFILE    SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
aix02    1        aixlinux   Running  standard   -     -         1      -           8320    Unknown
aix03    2        aixlinux   Running  standard   -     -         1      -           8320    Unknown
...
lpar07   4        aixlinux   Running  standard   0     none      1      1.0         4352    Unknown

real	0m19.057s
user	0m3.550s
sys	0m3.512s
$

Als weiteres Beispiel wollen wir wissen auf welchen LPARs AIX 7.1 TL5 installiert ist. Im Attribut os_version findet sich die OS-Version. Mit dem ‚~‚ Operator kann gegen einen regulären Ausdruck verglichen werden (ähnlich wie beim Kommando grep). Wir verwenden den regulären Ausdruck 7100-05:

$ time lpar status -s os_version~7100-05
NAME     LPAR_ID  LPAR_ENV  STATE    PROFILE    SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
aix14    14       aixlinux  Running  standard   0     active    2      0.2         16384   AIX 7.1 7100-05-02-1810
aix16    24       aixlinux  Running  standard   0     active    2      0.2         16384   AIX 7.1 7100-05-03-1846
...
lpar10   10       aixlinux  Running  standard   0     active    3      0.3         32768   AIX 7.1 7100-05-02-1810

real	0m18.212s
user	0m3.726s
sys	0m3.676s
$

Bisher haben wir immer das Default Ausgabeformat verwendet. Jetzt würden wir gerne alle Systeme auflisten, die noch unter AIX 6.1 laufen. Aber dieses Mal soll nur der LPAR-Name und die OS-Version ausgegeben werden. Hierfür gibt es die Option „-F„, mit der die gewünschten Ausgabe-Felder angegeben werden können:

$ time lpar status -s os_version~6100 -F name:os_version
aix39:AIX 6.1 6100-07-04-1216
aix46:AIX 6.1 6100-07-04-1216
...
lpar35:AIX 6.1 6100-09-05-1524

real	0m18.041s
user	0m3.619s
sys	0m3.699s
$

Wer lieber JSON-Output hat, kann dies ganz einfach mit der Option „-j“ erreichen, hier das gleiche Beispiel mit JSON-Ausgabe:

$ time lpar status -s os_version~6100 -F name:os_version -j
{
	"name": "aix39",
	"os_version": "AIX 6.1 6100-07-04-1216"
}
{
	"name": "aix46",
	"os_version": "AIX 6.1 6100-07-04-1216"
}
...
{
	"name": "lpar35",
	"os_version": "AIX 6.1 6100-09-05-1524"
}

real	0m21.247s
user	0m3.670s
sys	0m3.720s
$

Natürlich kann man nicht alle Attribut-Namen auswendig wissen! Das ist aber auch gar nicht notwendig, da man sich alle Attribut-Namen einfach anzeigen lassen kann. Man verwendet die Option „-f“ (Stanza-Format) und gibt eine beliebige LPAR an:

$ lpar status -f lpar19
lpar19:
	curr_lpar_proc_compat_mode = POWER7
	curr_mem = 8192
	curr_proc_mode = shared
	curr_proc_units = 0.3
	curr_procs = 2
	name = lpar19
	os_version = AIX 6.1 6100-09-05-1524
...
$

Über die Optionen „-h“ und „-m“ können die LPARs noch in Abhängigkeit von zugehöriger HMC und/oder Managed System ausgewählt werden.

Status aller LPARs mit zugehöriger HMC hmc01:

$ lpar -h hmc01 status

Status aller LPARs deren zugehörige HMC den Typ 7042-CR6 hat:

$ lpar -h 7042-CR6 status

Status aller LPARs deren zugehörige HMC den Typ 7042-CR6 hat und deren Name mit lpar beginnt:

$ lpar -h 7042-CR6 status lpar*

Status aller LPARs auf dem Managed System ms13:

$ lpar -m ms13 status

Status aller LPARs deren Managed System eine S922 ist:

$ lpar -m 9009-22A status

Die vorgestellten Auswahl- und Ausgabemöglichkeiten gelten für alle Ausgabe-Kommandos des LPAR-Tools (außer dem Kommando vios).

Das LPAR-Tool kann in unserem Download-Bereich heruntergeladen werden: https://powercampus.de/download

Das LPAR-Tool beinhaltet eine Test-Lizenz mit einer Gültigkeit bis zum 31. Oktober.

Eigene AIX installp-Pakete bauen (Teil 1)

In diesem Blog-Beitrag soll gezeigt werden, wie man unter AIX selber installp Pakete bauen kann. Die Benutzung des Kommandos mkinstallp wird dabei an einem einfachen Beispiel demonstriert. Komplexere Pakete werden in einem späteren Artikel behandelt.

Es ist relativ einfach unter AIX installp-Pakete zu bauen. Benötigt wird dazu das Kommando /usr/sbin/mkinstallp. Sollte das Kommando nicht installiert sein, muß das Paket bos.adt.insttools nachinstalliert werden. Zum Bau von Paketen werden root-Rechte benötigt.

Zunächst legen wir an beliebiger Stelle ein Verzeichnis an, in dem das Paket gebaut werden soll:

# mkdir pwrcmps.installp.example
#

Das Paket soll ein kleines Shell-Skript enthalten:

# cat <<EOF >hello
#! /bin/ksh
print "hello world"
EOF
# chmod a+x hello
#

Das Skript soll später unter /usr/local/bin installiert werden. Zu installierende Files müssen relativ zum Build-Directory (bei uns pwrcmps.installp.example) an der selben Stelle stehen, wie später relativ zum root-Directory. Wir legen daher die notwendige Directory Struktur an und kopieren das Skript hello an die entsprechende Stelle:

# mkdir –p pwrcmps.installp.example/usr/local/bin
# cp hello pwrcmps.installp.example/usr/local/bin
#

Wir wechseln in das Build-Directory und starten das Kommando mkinstallp zum Bauen des Paketes:

# cd pwrcmps.installp.example
# mkinstallp
Using /export/src/installp/pwrcmps.installp.example as the base package directory.
Cannot find /export/src/installp/pwrcmps.installp.example/.info. Attempting to create.
Using /export/src/installp/pwrcmps.installp.example/.info to store package control files.
Cleaning intermediate files from /export/src/installp/pwrcmps.installp.example/.info.

************************************************************
|            Beginning interactive package input           |
|   * - required; () - example value; [] - default value   |
************************************************************

* Package Name (xyz.net) []: pwrcmps.installp
* Package VRMF (1.0.0.0) []: 1.0.0.0
Update (Y/N) [N]:
Number of filesets in pwrcmps.installp (1) [1]:

Gathering info for new fileset (1 remaining)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
* Fileset Name (pwrcmps.installp.rte) []: pwrcmps.installp.example
* Fileset VRMF (1.0.0.0) []: 1.0.0.0
* Fileset Description (some text) []: Example Fileset
Do you want to include a copyright file for this fileset? (Y/N) [N]:
Entering information for the USER part liblpp files
Do you want to include an installp pre_i/u script for this fileset? (Y/N) [N]:
Do you want to include an installp post_i/u script for this fileset? (Y/N) [N]:
Do you want to include a pre-deinstall Script for this fileset? (Y/N) [N]:
Do you want to include an installp pre_rm script for this fileset? (Y/N) [N]:
Do you want to include an installp config script for this fileset? (Y/N) [N]:
Would you like to create ROOT part? (Y/N) [N]:
Bosboot required (Y/N) [N]:
License agreement acceptance required (Y/N) [N]:
Include license files for pwrcmps.installp.example in this package (Y/N) [N]:
Do you want to specify Requisites using a file for this fileset? (Y/N) [N]:
Number of Requisites for pwrcmps.installp.example (1) [0]:
Number of filesystems requiring additional space for pwrcmps.installp.example [0]:

You should include any directories that you are creating in the file count.
(ie: For /usr/proj/myFile, enter 2; 1 for /usr/proj and 1 for /usr/proj/myFile)
Number of USR part files in pwrcmps.installp.example (1) [0]: 1
* 1 of 1. Directory or File Path (/usr/proj/myFile) []: /usr/local/bin/hello
Do you want to make this fileset relocatable? (Y/N) [N]:
Do you want to include an override inventory file for this fileset? (Y/N) [N]:
Do you want to add WPAR attributes to your fileset? (Y/N) [N]:


Using /export/src/installp/pwrcmps.installp.example/.info/pwrcmps.installp.template as the template file.
pwrcmps.installp 1.0.0.0 I
processing pwrcmps.installp.example
creating ./.info/liblpp.a
creating ./tmp/pwrcmps.installp.1.0.0.0.bff
#

Das fertige Endprodukt findet man im Unterverzeichnis tmp:

# ls –l tmp
total 8
-rw-r--r--    1 root     system         2560 Sep 25 09:49 pwrcmps.installp.1.0.0.0.bff
#

Beim Erzeugen des Paketes haben wir der Einfachheit wegen immer die Default-Werte bestätigt. Als Produkt-Namen haben wir pwrcmps.installp angegeben, und als Fileset-Namen pwrcmps.installp.example, jeweils mit der Version 1.0.0.0. Alle Dateien und Verzeichnisse des Pakets müssen explizit mit absolutem Pfad aufgelistet werden! Das kann bei einigen hundert Pfaden etwas unpraktikabel werden, lässt sich aber durch eigene Skripte vereinfachen und automatisieren.

Wir installieren das neu generierte Paket einmal, und überprüfen ob unser Shell-Skript auch installiert wird:

# installp -ad tmp/pwrcmps.installp.1.0.0.0.bff all
+-----------------------------------------------------------------------------+
                    Pre-installation Verification...
+-----------------------------------------------------------------------------+
Verifying selections...done
Verifying requisites...done
Results...

SUCCESSES
---------
  Filesets listed in this section passed pre-installation verification
  and will be installed.

  Selected Filesets
  -----------------
  pwrcmps.installp.example 1.0.0.0            # Example Fileset

  << End of Success Section >>

+-----------------------------------------------------------------------------+
                   BUILDDATE Verification ...
+-----------------------------------------------------------------------------+
Verifying build dates...done
FILESET STATISTICS
------------------
    1  Selected to be installed, of which:
        1  Passed pre-installation verification
 ----
    1  Total to be installed

+-----------------------------------------------------------------------------+
                         Installing Software...
+-----------------------------------------------------------------------------+

installp:  APPLYING software for:
        pwrcmps.installp.example 1.0.0.0

Finished processing all filesets.  (Total time:  1 secs).

+-----------------------------------------------------------------------------+
                                Summaries:
+-----------------------------------------------------------------------------+

Installation Summary
--------------------
Name                        Level           Part        Event       Result
-------------------------------------------------------------------------------
pwrcmps.installp.example    1.0.0.0         USR         APPLY       SUCCESS   
# which hello
/usr/local/bin/hello
# hello
hello world
#

Wir erweitern jetzt unser Skript und lassen die Meldung „hello world, how are you“ ausgeben.

# vi usr/local/bin/hello
…
print "hello world, how are you"
#

Das Paket soll nun neu gebaut werden, allerdings wollen wir die Version auf 1.1.0.0 erhöhen. Natürlich könnten wir das Kommando mkinstallp wieder interaktiv starten und alle notwendigen Informationen erneut eingeben, das ist aber sehr aufwändig und auch nicht notwendig. Das Kommando mkinstallp unterstützt die Angabe eines Template-Files mit allen notwendigen Informationen. Beim Bau der ersten Version unseres Paketes wurde ein solches Template-File unter .info/pwrcmps.installp.template generiert. Wir kopieren dieses Template-File direkt in das Buildroot-Directory und benennen es dabei um in template:

# cp .info/pwrcmps.installp.template template
# cat template
Package Name: pwrcmps.installp
Package VRMF: 1.0.0.0
Update: N
Fileset
  Fileset Name: pwrcmps.installp.example
  Fileset VRMF: 1.0.0.0
  Fileset Description: Example Fileset
  USRLIBLPPFiles
  EOUSRLIBLPPFiles
  Bosboot required: N
  License agreement acceptance required: N
  Include license files in this package: N
  Requisites:
  USRFiles
    /usr/local/bin/hello
  EOUSRFiles
  ROOT Part: N
  ROOTFiles
  EOROOTFiles
  Relocatable: N
EOFileset
#

Das Template-File enthält die von uns interaktiv gemachten Angaben. Wir ändern in diesem Template-File die Versions-Nummer von 1.0.0.0 auf 1.1.0.0:

# vi template
…
Package VRMF: 1.1.0.0
…
  Fileset VRMF: 1.1.0.0
…
#

Wir versuchen nun die Version 1.1.0.0 zu bauen, indem wir mkinstallp mit der Option –T (für Template) und dem Template-File template starten:

# mkinstallp -T template
Using /export/src/installp/pwrcmps.installp.example as the base package directory.
Using /export/src/installp/pwrcmps.installp.example/.info to store package control files.
Cleaning intermediate files from /export/src/installp/pwrcmps.installp.example/.info.
0503-844 mkinstallp: Cannot overwrite existing
        /export/src/installp/pwrcmps.installp.example/.info/pwrcmps.installp.template file.
#

Es kommt eine Fehlermeldung, das Template-File unter .info kann nicht überschrieben werden. Das .info-Verzeichnis wird beim Build-Prozess immer wieder neu angelegt und kann daher einfach gelöscht werden, bevor der nächste Build-Prozeß gestartet wird:

# rm -rf .info
# mkinstallp -T template
Using /export/src/installp/pwrcmps.installp.example as the base package directory.
Cannot find /export/src/installp/pwrcmps.installp.example/.info. Attempting to create.
Using /export/src/installp/pwrcmps.installp.example/.info to store package control files.
Cleaning intermediate files from /export/src/installp/pwrcmps.installp.example/.info.

Using template as the template file.
0503-880 mkinstallp: This file /usr/local/bin/hello
        already exists as a system file.
pwrcmps.installp 1.1.0.0 I
processing pwrcmps.installp.example
creating ./.info/liblpp.a
creating ./tmp/pwrcmps.installp.1.1.0.0.bff
#

Die neue Version des Paketes ist wie gehabt unter tmp zu finden:

# ls -l tmp
total 16
-rw-r--r--    1 root     system         2560 Sep 25 10:08 pwrcmps.installp.1.0.0.0.bff
-rw-r--r--    1 root     system         2560 Sep 25 10:35 pwrcmps.installp.1.1.0.0.bff
#

Auf diese Weise lassen sich leicht Änderungen vornehmen und dann anschließend paketieren.