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.

 

LPAR-Tool in Aktion: Examples

Das LPAR-Tool kann HMCs, Managed Systems, LPARs und Virtual-I/O-Server über die Kommandozeile administrieren. Die aktuelle Version des LPAR-Tools (aktuell: 1.4.0.2), kann von unserer Download-Seite https://powercampus.de/download heruntergeladen werden. Eine Test-Lizenz, gültig bis 31. Oktober, ist enthalten. In diesem Beitrag sollen einige einfache, aber nützliche Anwendungen des LPAR-Tools gezeigt werden.

Eine häufig auftretende Frage in größeren Umgebungen (mehrere HMCs, viele Managed Systems) ist: wo befindet sich eine bestimmte LPAR. Mit dem LPAR-Tool kann diese Frage leicht beantwortet werden, hierfür gibt es das Kommando „lpar show„:

$ lpar show lpar02
NAME    ID  SERIAL     LPAR_ENV  MS    HMCS
lpar02  39  123456789  aixlinux  ms21  hmc01,hmc02
$

Neben dem Namen, der LPAR-ID und der Seriennummer wird auch das Managed System, hier ms21, und die zugehörigen HMCs, hier hmc01 und hmc02, gezeigt. Es können auch mehrere LPARs und/oder Wildcards angegeben werden:

$ lpar show lpar02 lpar01
...
$ lpar show lpar*
...
$

Wird kein Argument angegeben, werden alle LPARs aufgelistet.

 

Eine weitere Frage, die sich häufig stellt, ist der Status der LPAR oder LPARs. Auch dies läßt sich leicht beantworten, dieses Mal mit dem Kommando „lpar status„:

$ lpar status lpar02
NAME    LPAR_ID  LPAR_ENV  STATE    PROFILE   SYNC  RMC     PROCS  PROC_UNITS  MEM   OS_VERSION
lpar02  39       aixlinux  Running  standard  0     active  1      0.7         7168  AIX 7.2 7200-03-02-1846
$

Die LPAR lpar02 ist im Zustand Running, das verwendete Profil heißt standard, die RMC-Verbindung ist active und die LPAR läuft unter AIX 7.2 (TL3 SP2). Die LPAR besitzt 1 Prozessor Core, mit 0.7 Processor Units und 7 GB RAM. Die Spalte SYNC gibt an ob die aktuelle Konfiguration mit dem Profil synchronisiert wird (Attribut sync_curr_profile).

Natürlich lassen sich auch hier mehrere LPARs oder auch alle LPARs angeben.

Möchte man sehen, was das LPAR-Tool im Hintergrund macht, kann man bei den meisten Kommandos die Option „-v“ für verbose-only angeben. Es werden dann die HMC-Kommandos aufgelistet, es werden aber keine Änderungen auf der HMC durchgeführt. Hier die HMC-Kommandos die für die Status-Ausgabe abgesetzt werden:

$ lpar status -v lpar02
hmc01: lssyscfg -r lpar -m ms21
hmc01: lshwres -r mem -m ms21 --level lpar
hmc01: lshwres -r proc -m ms21 --level lpar
$

 

Als nächstes soll das Hinzufügen von zusätzlichem RAM gezeigt werden. Wir starten mit dem Status der LPAR:

$ lpar status lpar02
NAME    LPAR_ID  LPAR_ENV  STATE    PROFILE   SYNC  RMC     PROCS  PROC_UNITS  MEM   OS_VERSION
lpar02  39       aixlinux  Running  standard  0     active  1      0.7         7168  AIX 7.2 7200-03-02-1846
$

Die LPAR läuft und RMC ist aktiv, eine DLPAR-Operation sollte also möglich sein. Wir schauen zunächst nach, ob die maximal mögliche Speichergröße schon verwendet wird:

$ lpar lsmem lpar02
            MEMORY         MEMORY         HUGE_PAGES 
LPAR_NAME  MODE  AME  MIN   CURR  MAX   MIN  CURR  MAX
lpar02     ded   0.0  2048  7168  8192  0    0     0
$

Aktuell verwendet die LPAR 7 GB, maximal möglich sind 8 GB. Eine Erweiterung um 1 GB (1024 MB) sollte also möglich sein. Wir führen die Erweiterung durch, das notwendig Kommando ist „lpar addmem„:

$ lpar addmem lpar02 1024
$

Wir überprüfen den Erfolg, indem wir das Kommando „lpar lsmem“ noch einmal starten:

$ lpar lsmem lpar02
           MEMORY         MEMORY         HUGE_PAGES 
LPAR_NAME  MODE  AME  MIN   CURR  MAX   MIN  CURR  MAX
lpar02     ded   0.0  2048  8192  8192  0    0     0
$

(Übrigens: falls die aktuelle Konfiguration nicht mit dem aktuellen Profil synchronisiert wird, Attribut sync_curr_profile, dann aktualisiert das LPAR-Tool auch das Profil!)

 

Virtuelle Adapter lassen sich mittels „lpar lsvslot“ auflisten:

$ lpar lsvslot lpar02
SLOT  REQ  ADAPTER_TYPE   STATE  DATA
0     Yes  serial/server  1      remote: (any)/any connect_status=unavailable hmc=1
1     Yes  serial/server  1      remote: (any)/any connect_status=unavailable hmc=1
2     No   eth            1      PVID=123 VLANS= ETHERNET0 XXXXXXXXXXXX
6     No   vnic           -      PVID=1234 VLANS=none XXXXXXXXXXXX failover sriov/ms21-vio1/1/3/0/2700c003/2.0/2.0/20/100.0/100.0,sriov/ms21-vio2/2/1/0/27004004/2.0/2.0/10/100.0/100.0
10    No   fc/client      1      remote: ms21-vio1(1)/47 c050760XXXXX0016,c050760XXXXX0017
20    No   fc/client      1      remote: ms21-vio2(2)/25 c050760XXXXX0018,c050760XXXXX0019
21    No   scsi/client    1      remote: ms21-vio2(2)/20
$

Das Beispiel zeigt neben virtuellen FC- und SCSI-Adaptern auch einen vNIC Adapter in Slot 6.

 

Als letztes zeigen wir noch das Starten einer Konsole für eine LPAR:

$ lpar console lpar02

Open in progress 

 Open Completed.

…

AIX Version 7

Copyright IBM Corporation, 1982, 2018.

Console login:

…

Die Konsole kann mit „~.“ beendet werden.

 

Natürlich kann das LPAR-Tool noch viel mehr.

Fortsetzung folgt.

 

LPAR-Tool 1.4.0.1 verfügbar (inklusive Testlizenz)!

Im Download-Bereich steht ab sofort die Version 1.4.0.1 unseres LPAR-Tools mit einer gültigen Test-Lizenz bis 31.10.2019 zum Download bereit. Die Lizenz ist in den Binaries direkt enthalten, es muss also kein Lizenz-Key eingetragen werden. Die enthaltene Test-Lizenz erlaubt die Benutzung des LPAR-Tools für bis zu 10 HMCs, 100 Managed Systems und 1000 LPARs.

TCP-Verbindungsabbrüche wegen „max assembly queue depth“

Kürzlich hatten wir häufige Programm-Abbrüche von einigen Java-Client Programmen. Im Java Stack-Trace war folgendes zu finden:

[STACK] Caused by: java.io.IOException: Premature EOF
[STACK]           at sun.net.www.http.ChunkedInputStream.readAheadBlocking(Unknown Source)
[STACK]           at sun.net.www.http.ChunkedInputStream.readAhead(Unknown Source)
[STACK]           at sun.net.www.http.ChunkedInputStream.read(Unknown Source)
[STACK]           at java.io.FilterInputStream.read(Unknown Source)

Das Problem tritt in der Klasse ChunkedInputStream in der Methode readAheadBlocking auf. Im Source Code der Methode findet man:

558 /**
559 * If we hit EOF it means there's a problem as we should never
560 * attempt to read once the last chunk and trailers have been
561 * received.
562 */
563 if (nread < 0) {
564 error = true;
565 throw new IOException("Premature EOF");
566 }

Der Wert nread wird kleiner 0, wenn das Ende des Datenstroms erreicht ist. Dies kann auch passieren wenn die Gegenseite die Verbindung unerwartet schließt.

Die Serverseite war in diesem Fall ein AIX-System (AIX 7.1 TL5 SP3). Eine Überprüfung der TCP-Verbindungen auf Abbrüche (Drops) mittels netstat ergab:

$ netstat -p tcp | grep drop
        361936 connections closed (including 41720 drops)
        74718 embryonic connections dropped
                0 connections dropped by rexmit timeout
                0 connections dropped due to persist timeout
                0 connections dropped by keepalive
        0 packets dropped due to memory allocation failure
        0 Connections dropped due to bad ACKs
        0 Connections dropped due to duplicate SYN packets
        1438 connections dropped due to max assembly queue depth
$

Demnach gab es 1438 Verbindungsabbrüche wegen Erreichen der maximalen TCP Assembly Queue Tiefe (max assembly queue depth). Die Queue Tiefe wird über den neuen Kernel Parameter tcp_maxqueuelen konfiguriert, der als Fix für den CVE-2018-6922 eingeführt wurde (siehe: The CVE-2018-6922 fix (FreeBSD vulnerability) and scp) . Der Defaultwert ist 1000. Bei größeren Paket-Laufzeiten kann es zum Überlauf der Queue kommen.

Nach einer Erhöhung des Kernel-Parameters tcp_maxqueuelen sind keine Verbindungsabbrüche mehr aufgetreten.

LPAR-Tool mit Test-Lizenz bis 15.09.2019

Im Download-Bereich steht ab sofort die Version 1.3.0.2 unseres LPAR-Tools mit einer gültigen Test-Lizenz bis 15.09.2019 zum Download bereit. Die Lizenz ist in den Binaries direkt enthalten, es muss also kein Lizenz-Key eingetragen werden. Die enthaltene Test-Lizenz erlaubt die Benutzung des LPAR-Tools für bis zu 10 HMCs, 100 Managed Systems und 1000 LPARs.

ProbeVue in Action: Überwachen der „Queue Depth“ von Platten

Platten und Storage Systeme unterstützen Tagged Command Queueing, d.h. angeschlossene Server können mehrere I/O Aufträge an die Platte oder das Storage-System senden ohne zu Warten das ältere I/O-Aufträge fertig sind. Wieviele I/O-Aufträge man an eine Platte senden darf, bevor man warten muss das ältere I/O-Aufträge abgeschlossen wurden, kann über das hdisk Attribut queue_depth unter AIX konfiguriert werden. Für viele hdisk Typen ist der Wert 20 für die queue_depth der Default-Wert. In der Regel erlauben die meisten Storage-Systeme aber noch größere Werte für die Queue-Depth.

Mit Hilfe von ProbeVue lässt sich die Auslastung der Platten-Queue sehr leicht beobachten.

Ab AIX 7.1 TL4 bzw. AIX 7.2 TL0 unterstützt AIX den I/O Probe Manager. Damit lassen sich auf einfache Weise Ereignisse im I/O Stack von AIX tracen. Wird ein I/O vom Platten-Treiber gestartet, so geschieht dies über die Funktion iostart im Kernel, der Request wird an den Adapter-Treiber weitergegeben und geht dann über den Host-Bus-Adapter an das Storage-System. Das Bearbeiten der Antwort wird von der Funktion iodone im Kernel übernommen. Der I/O Probe-Manager unterstützt (unter anderem) Proben an diesen Stellen:

@@io:disk:iostart:read:<filter>
@@io::disk:iostart:write:<filter>
@@io:disk:iodone:read:<filter>
@@io::disk:iodone:write:<filter>

Als Filter kann z.B. ein Hdisk Name wie hdisk2 angegeben werden. Die Proben-Punkte lösen dann nur Ereignisse für die Platte hdisk2 aus. Damit lässt sich schon einmal eine Aktion durchführen wann immer ein I/O für eine Hdisk beginnt oder endet. Damit könnte man z.B. messen wie lange eine I/O Operation dauert oder auch einfach nur mitzählen wieviele I/Os ausgeführt werden. In unserem Beispiel waren wir aber an der Auslastung der Platten-Queue interessiert, d.h. der Anzahl I/Os die an die Platte gesendet aber noch nicht abgeschlossen wurden. Der I/O Probe-Manager besitzt für die I/O Ereignisse  iostart und iodone die Builtin-Variable __diskinfo mit den folgenden Feldern (https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.genprogc/probevue_man_io.htm):

name          char*     Name der Platte
…
queue_depth   int       Die Queue-Depth der Platte (Wert aus der ODM)
cmds_out      int       Anzahl der ausstehenden I/Os
…

Das Feld cmds_out gibt an wieviele I/Os an die Platte gesendet wurden, für die das I/O noch nicht abgeschlossen ist (Antwort ist noch nicht beim Server angekommen).

Mit dem folgenden Code-Abschnitt ermitteln wir die minimale, maximale und durchschnittliche Anzahl an Einträgen in der Platten-Queue:

@@io:disk:iostart:*:hdisk0     // Nur I/Os für hdisk0 berücksichtigen
{
   queue = __iopath->cmds_out; // Anzahl ausstehende I/Os in Variable queue festhalten
   ++numIO;                    // Anzahl I/Os in der Variablen numIO mitzählen (wegen Durchschnittsbildung)
   avg += queue;               // Variable avg um Anzahl ausstehende I/Os erhöhen
   if ( queue < min )
      min = queue;             // Überprüfen auf Minimum und gegebenenfalls setzen
   if ( queue > max )
      max = queue;             // Überprüfen auf Maximum und gegebenenfalls setzen
}

Die ermittelten Werte geben wir dann einmal pro Sekunde mit Hilfe des Intervall Probe-Managers aus:

@@interval:*:clock:1000
{
   if ( numIO == 0 )
      numIO = 1;    // Verhindert Division durch 0 bei der Durchschnittsbildung
   if ( min > max )
      min = max;
   printf( "%5d  %5d  %5d\n" , min , avg/numIO , max );
   min = 100000;   // Zurücksetzen der Variablen für das nächste Intervall
   avg = 0;
   max = 0;
   numIO = 0;
}

Das vollständige Skript ist auf unserer Webseite zum Download verfügbar: ioqueue.e.

Hier ein Beispiel-Lauf des Skriptes für die Platte hdisk13:

# ./ioqueue.e hdisk13
  min    avg    max
    1      1      2
    1      1      9
    1      1      2
    1      1      8
    1      1      2
    1      1      2
    1      1      8
    1      1     10
    1      1      2
    1      1      1
    1      1     10
    1      1      2
    1      1     11
...

Das Skript erwartet die Angabe einer hdisk als Argument und gibt dann einmal pro Sekunde die ermittelten Werte für die angegebene hdisk aus.

In der Beispiel-Ausgabe sieht man das die maximale Anzahl der Einträge in der Platten-Queue 11 ist. Eine Erhöhung des Attributes queue_depth macht daher aus Performance-Sicht keinen Sinn.

Hier ein anderes Beispiel:

# ./ioqueue.e hdisk21
  min    avg    max
    9     15     20
   11     17     20
   15     19     20
   13     19     20
   14     19     20
   17     18     20
   18     18     19
   16     19     20
   13     18     20
   18     19     19
   17     19     20
   18     19     20
   17     19     19
...

In diesem Fall wird der maximale Wert 20 (die hdisk21 hat eine queue_depth von 20) regelmäßig erreicht. Eine Erhöhung der queue_depth kann in diesem Fall zu einer Verbesserung des Durchsatzes führen.

Das Beispiel-Skript lässt sich natürlich noch beliebig erweitern, man könnte z.B. noch den Durchsatz erfassen, oder die Wartezeit von I/Os in der Wait-Queue oder auch die Position und Größe jedes I/Os auf der Platte. Das dargestellte Beispiel zeigt wie einfach man Informationen zu I/Os mit Hilfe von ProbeVue ermitteln kann.

 

Zahlen: FC World Wide Names (WWNs)

Die meisten kennen WWNs als 64-bit WWNs, geschrieben als 16 hexadezimale Ziffern. Die Kenntnis das es verschiedene Formate bei den WWNs gibt und es auch 128-bit WWNs gibt ist nicht ganz so bekannt. In diesem Artikel sollen daher die verschiedenen Formate von WWNs kurz vorgestellt werden.

Der grundlegende Aufbau von 64-bit WWNs sieht wie folgt aus:

+---+----------------+
|NAA| NAME           |
+---+----------------+
4-bit 60-bit

Das 4-bit NAA (Network Address Authority) Feld gibt dabei den Typ der Adresse und das Format der Adresse vor.

Für das 60-bit NAME Feld gibt es eine Reihe von verschiedenen Möglichkeiten.

1. Format 1 Adresse (NAA = 0001)

+---+--------+------------------------+
|NAA|Reserved| 48-bit IEEE MAC Address|
+---+--------+------------------------+
4-bit 12-bit   48-bit

Im Feld Reserved (12-bit) müssen alle Bits auf 0 gesetzt sein!

Beispiel:

1 000 00507605326d (Zur Verdeutlichung des Formats sind die Felder durch Leerzeichen getrennt)

 

2. Format 2 Adresse (NAA = 0010)

+---+---------------+-----------------------+
|NAA|Vendor Assigned|48-bit IEEE MAC Address|
+---+---------------+-----------------------+
4-bit  12-bit         48-bit

Das 12-bit “Vendor Assigned” Feld kann vom Hersteller beliebig verwendet werden.

Beispiel:

2 001 00507605326d (Zur Verdeutlichung des Formats sind die Felder durch Leerzeichen getrennt)

 

3. Format 3 Adresse (NAA = 0011)

+---+-----------------+
|NAA|Vendor Assigned  |
+---+-----------------+
4-bit 60-bit

Das Feld „Vendor Assigned“ (60-bit) wird vom Hersteller beliebig vergeben. Damit ist diese Art von Adresse nicht weltweit eindeutig und ist daher in der Praxis eher nicht anzutreffen.

Beispiel:

3 0123456789abcde (Zur Verdeutlichung des Formats sind die Felder durch Leerzeichen getrennt)

 

4. Format 4 Adresse (NAA = 0100)

+---+---------+--------------+
|NAA|Reserved | IPv4 Address |
+---+---------+--------------+
4-bit 28-bit     32-bit

Das Feld “IPv4 Address” (32-bit) enthält eine 32-bit IPv4 Adresse.

Beispiel für IP 10.0.0.1:

4 0000000 0a000001 (Zur Verdeutlichung des Formats sind die Felder durch Leerzeichen getrennt)

 

5. Format 5 Adresse (NAA = 0101)

+---+-------+-----------------+
|NAA| OUI   | Vendor Assigned |
+---+-------+-----------------+
4.bit 24-bit 36-bit

Das Feld OUI (24-bit) enthält die 24-bit vom IEEE zugewiesene ID (Organizational Unique ID).

Das Feld „Vendor Assigned“ (36-bit) kann wieder vom Hersteller beliebig vergeben werden.

Beispiel:

5 005076 012345678 (Zur Verdeutlichung des Formats sind die Felder durch Leerzeichen getrennt)

 

6. Format 6 Adresse (NAA = 0110)

Format 6 Adressen sind 128-bit Adressen und werden häufig für LUNs im SAN verwendet.

+---+-------+---------------+-------------------------+
|NAA|  OUI  |Vendor Assigned|Vendor Assigned Extension|
+---+-------+---------------+-------------------------+
4.bit 24-bit  36-bit          64-bit

Das Feld OUI (24-bit) enthält die 24-bit vom IEEE zugewiesene ID.

Das Feld „Vendor Assigned“ (36-bit) kann vom Hersteller beliebig vergeben werden.

Das Feld „Vendor Assigned Extension“ (64-bit) kann ebenso vom Hersteller beliebig vergeben werden.

Beispiel:

6 005076 012345678 0123456789abcdef (Zur Verdeutlichung des Formats sind die Felder durch Leerzeichen getrennt)

 

7. IEEE EUI-64 Adresse (NAA=11)

Bei diesem Adress-Format ist das Feld NAA auf lediglich 2-bit verkürzt, wobei NAA den Wert 11 hat.

+---+-------------+---------------+
|NAA|OUI shortened|Vendor Assigned|
+---+-------------+---------------+
2-bit 22-bit       40-bit

Das Feld “OUI shortened” (22-bit) ist dabei eine auf 22-bit gekürzte Version der vom IEEE zugewiesenen 24-bit ID.

(Die beiden niederwertigsten Bit des 1 Byte werden hierbei weggelassen und die verbleibenden 6-Bit werden um 2 Bit-Positionen nach rechts verschoben um Platz für die beiden NAA Bits zu machen.)

Das Feld „Vendor Assigned“ (40-bit) kann vom Hersteller beliebig vergeben werden.

Diese Art von Adressen werden häufig im Bereich Virtualisierung verwendet, z.B. wenn es um NPIV (N_Port ID Virtualization) geht.

Beispiel:

C05076 0123456789 (Zur Verdeutlichung des Formats sind die Felder durch Leerzeichen getrennt)