Home of the LPAR-Tool
Tips und Tricks für AIX
IBM hat den URL für das FLRT Lite Daten-File geändert. Über die alte URL:
https://www14.software.ibm.com/support/customercare/flrt/liteTable
kann das Daten-File nicht mehr bezogen werden. Die neue URL ist:
https://esupport.ibm.com/customercare/flrt/liteTable
Für Nutzer unseres Skripts show_life_cycle haben wir die aktualisierte Version des Skripts mit dem neuen URL in unserem Download-Bereich zur Verfügung gestellt.
(Vielen Dank an Lutz Leonhardt für den Hinweis.)
Eine triviale Frage über die wir kürzlich gestolpert sind:
Wie groß ist denn der interne JFS2 Log aktuell?
Die Größe des internen JFS2 Logs muss die folgenden beiden Bedingungen erfüllen:
Beim Anlegen eines JFS2 Dateisystems mit internem Log, wenn keine Log-Größe (-a logsize=Value) angegeben wird, werden standardmäßig 0.4% der Dateisystem-Größe verwendet. Der Wert 0.4% ist in der Manual Page zu crfs dokumentiert.
Aber, wie groß ist denn der interne JFS2 Log gerade?
Diese Information liefert das Kommando dumpfs. Es erwartet als Argument entweder den Mount-Punkt eines JFS2 Dateisystems oder die Geräte-Datei des unterliegenden Logical Volumes. Das Kommando listet den Superblock, sowie eine Reihe weiterer Verwaltungs-Informationen auf. Die Ausgabe kann bei größeren Dateisystemen sehr lang sein. Da wir nur an dem JFS2 Log interessiert sind, empfiehlt es sich die Ausgabe durch das Kommando grep zu filtern:
# dumpfs /data | grep -i log aggregate block size 4096 log2 of aggregate block size 12 LVM I/O Transfer size 512 log2 of LVM transfer size 9 log2 of block size/transfer size 3 Aggregate attributes J2_GROUPCOMMIT J2_INLINELOG log device 0x8000002700000001 log serial number 0x26 Inline Log: 541065216 (132096); 1024 fsck Service Log number of blocks: 50 Extendfs Inline Log Working Space: 541065216 (132096); 1024 #
Der letzte Wert in der Zeile „Inline Log:“ gibt die Größe des internen Logs in Blöcken an. Die Blockgröße des Dateisystems findet man in der Zeile „aggregate block size“. In unserem Falle hat der interne Log eine Größe von 1024 Blöcken, zu jeweils 4096 Bytes. Dies ergibt eine Größe von 4 MB (1024 * 4 KB).
Für den Fall das ein externer Log verwendet wird, sieht die Ausgabe wie folgt aus:
# dumpfs / | grep -i log aggregate block size 4096 log2 of aggregate block size 12 LVM I/O Transfer size 512 log2 of LVM transfer size 9 log2 of block size/transfer size 3 log device 0x8000000a00000003 log serial number 0xb Inline Log: 0 (0); 0 fsck Service Log number of blocks: 50 Extendfs Inline Log Working Space: 0 (0); 0 #
Der interne Log hat die Größe 0 Blöcke.
Allerdings ist dies nicht die einfachste Möglichkeit. Chris Gibson weist auf die Option „-q“ des Kommando lsfs hin, welche für JFS und JFS2 Dateisysteme zusätzliche Informationen anzeigt:
# lsfs -q /filesystem Name Nodename Mount Pt VFS Size Options Auto Accounting /dev/fslv01 -- /filesystem jfs2 1048576 -- no no (lv size: 1048576, fs size: 1048576, block size: 4096, sparse files: yes, inline log: yes, inline log size: 4, EAformat: v1, Quota: no, DMAPI: no, VIX: yes, EFS: no, ISNAPSHOT: no, MAXEXT: 0, MountGuard: no) #
Die Größe des Inline Logs wird dort direkt in MB angegeben (inline log size: 4).
Die Größe des internen JFS2 Log festzustellen ist also mit dem richtigen Kommando (dumpfs lsfs) kein Problem!
Ab AIX 7.2 unterstützt NIM die Verwendung von HTTP. Hierzu gibt es den neuen NIM-Service Handler nimhttp (Port 4901). Dies bietet die Möglichkeit YUM Repositories auf einem NIM-Server mit Hilfe dieses NIM-Service Handlers zur Verfügung zu stellen. Die Repositories müssen hierzu unterhalb des Document-Root (standardmäßig /export/nim) abgespeichert werden. Der Zugriff von einem AIX-Client aus kann dann über HTTP erfolgen.
Die Repositories müssen dazu auf dem AIX-Client unter /opt/freeware/etc/yum/yum.conf oder /opt/freeware/etc/yum/repos.d konfiguriert werden. Alle verfügbaren YUM Operationen werden auf diesem Wege unterstützt.
Wird auf dem NIM-Server ohnehin nimhttp genutzt, entsteht hierdurch kein zusätzlicher Aufwand.
Im Folgenden ist die Konfiguration für die Verwendung von YUM mit nimhttp gezeigt.
Voraussetzung ist zunächst das der NIM-Service Handler nimhttp auf dem NIM-Server aktiv ist:
aixnim # lssrc -s nimhttp Subsystem Group PID Status nimhttp 19136996 active aixnim #
Sollte nimhttp noch nicht aktiviert worden sein, kann dies im einfachsten Fall mit Hilfe des Kommandos nimconfig auf dem NIM-Server nachgeholt werden:
aixnim # nimconfig -h 0513-077 Subsystem has been changed. 0513-059 The nimhttp Subsystem has been started. Subsystem PID is 19136996. aixnim #
Hinweis: Die Konfiguration von nimhttp wird an anderer Stelle gezeigt.
Für Testzwecke legen wir unter /export/nim (Document-Root) eine kleine Text-Datei auf dem NIM-Server an:
aixnim # echo "testfile for nimhttp" >/export/nim/testfile aixnim #
Als nächstes überprüfen wir auf dem NIM-Client die Funktionalität indem wir mit dem NIM-Client Kommando nimhttp die angelegte Test-Datei vom NIM-Server herunterladen:
aix01 # nimhttp -f testfile -o dest=/tmp -v nimhttp: (source) testfile nimhttp: (dest_dir) /tmp nimhttp: (verbose) debug nimhttp: (master_ip) aixnim nimhttp: (master_port) 4901 sending to master... size= 46 pull_request= "GET /testfile HTTP/1.1 Connection: close " Writing 21 bytes of data to /tmp/testfile Total size of datalen is 21. Content_length size is 21. aix01 #
(Die Option ‚-v‘ sorgt für den gezeigten Debugging-Output.)
Die Testdatei wurde unter /tmp/testfile abgespeichert.
Ein weiterer Test mit dem Kommando curl (verfügbar über die AIX-Toolbox) zeigt ebenfalls das nimhttp erfolgreich für den Download von Daten verwendet werden kann:
aix01 # curl http://aixnim:4901/testfile testfile for nimhttp aix01 #
Die Verwendung von nimhttp für den Zugriff auf YUM-Repositories sollte also prinzipiell möglich sein.
Wir haben Kopien der von IBM bereitgestellten Repositories der AIX-Toolbox auf unserem NIM-Server in den folgenden Verzeichnissen abgelegt:
/export/nim/aixtoolbox/RPMS/noarch AIX_Toolbox_noach (AIX noarch repository)
/export/nim/aixtoolbox/RPMS/ppc AIX_Toolbox (AIX generic repository)
/export/nim/aixtoolbox/RPMS/ppc-7.1 AIX_Toolbox_71 (AIX 7.1 specific repository)
/export/nim/aixtoolbox/RPMS/ppc-7.2 AIX_Toolbox_72 (AIX 7.2 specific repository)
Damit ein AIX Client System auf diese Repositories zugreifen kann, müssen diese in der YUM Konfiguration hinterlegt sein. Wir haben der Einfachheit halber die Repositories in die Konfigurations-Datei /opt/freeware/etc/yum/yum.conf eingetragen:
aix01 # vi /opt/freeware/etc/yum/yum.conf [main] cachedir=/var/cache/yum keepcache=1 debuglevel=2 logfile=/var/log/yum.log exactarch=1 obsoletes=1 [AIX_Toolbox] name=AIX generic repository baseurl=http://aixnim:4901/aixtoolbox/RPMS/ppc/ enabled=1 gpgcheck=0 [AIX_Toolbox_noarch] name=AIX noarch repository baseurl=http://aixnim:4901/aixtoolbox/RPMS/noarch/ enabled=1 gpgcheck=0 [AIX_Toolbox_72] name=AIX 7.2 specific repository baseurl=http://aixnim:4901/aixtoolbox/RPMS/ppc-7.2/ enabled=1 gpgcheck=0 aix01 #
Alternativ kann für jede Repository auch ein eigenes repoid-File unter /opt/freeware/etc/yum/repos.d angelegt werden.
Der entscheidende Eintrag ist jeweils das Attribut baseurl. Hier wird als URL http verwendet. Dem Hostnamen des NIM-Servers wird mit Doppelpunkt getrennt die Port-Nummer von nimhttp (Port 4901) mitgegeben. Der Pfad ist dann relativ zu /export/nim (Document-Root) auf dem NIM-Server.
Ein Auflisten der verfügbaren YUM-Repositories mit dem Kommando yum zeigt die erwarteten Repositories:
aix01 # yum repolist repo id repo name status AIX_Toolbox AIX generic repository 2740 AIX_Toolbox_72 AIX 7.2 specific repository 417 AIX_Toolbox_noarch AIX noarch repository 301 repolist: 3458 aix01 #
Um zu demonstrieren das auch das Installieren von RPMs auf diesem Wege mit nimhttp möglich ist, zeigen wir die Installation von wget:
aix01 # yum install wget Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package wget.ppc 0:1.21.1-1 will be installed --> Finished Dependency Resolution Dependencies Resolved ======================================================================================================== Package Arch Version Repository Size ======================================================================================================== Installing: wget ppc 1.21.1-1 AIX_Toolbox 703 k Transaction Summary ======================================================================================================== Install 1 Package Total size: 703 k Installed size: 1.4 M Is this ok [y/N]: y Downloading Packages: Running Transaction Check Running Transaction Test Transaction Test Succeeded Running Transaction Installing : wget-1.21.1-1.ppc 1/1 From wget-1.21.1 onwards, symbolic link of wget in /usr/bin is removed. The binary is shipped in /opt/freeware/bin. Please use absolute path or add /opt/freeware/bin in PATH environment variable to use the binary. Installed: wget.ppc 0:1.21.1-1 Complete! aix01 #
Das AIX-System muss nicht zwingend ein NIM-Client sein, da YUM nicht auf NIM zurückgreift. YUM verwendet lediglich den vom NIM-Master bereitgestellten http-Server. Die AIX-Version spielt ebenfalls keine Rolle, der AIX-Client kann unter AIX 7.1 oder AIX 7.2 laufen.
Hinweis: Für AIX 7.3 wird anstelle von YUM der Dandified YUM (DNF) verwendet.
AIX-System mit direkter Internet-Anbindung
AIX-System ohne direkte Internet-Anbindung
Dependent module /opt/freeware/lib/libcrypto.a(libcrypto.so) could not be loaded
db-4.8.24-3.ppc conflicts with file from package db4-4.7.25-2.ppc
Welche Repositories sind verfügbar?
Konfigurieren von existierenden Repositories
Hinzufügen eines lokalen Repositories
Repository mit HTTP- oder HTTPS-Zugriff
Repository mit HTTP- oder HTTPS-Zugriff über Proxy-Server
Erzeugen einer lokalen Repository
Das Kommando „oslevel –s“ zeigt den höchsten vollständig installierten Service-Pack auf einem AIX-System an, z.B.:
$ oslevel -s 7100-05-05-1939 $
Es kann aber ohne weiteres ein höherer Service-Pack installiert sein (allerdings nicht vollständig). Am einfachsten lässt sich das mit „oslevel –qs“ überprüfen:
$ oslevel -qs Known Service Packs ------------------- 7100-05-06-2028 7100-05-06-2016 7100-05-06-2015 7100-05-05-1939 7100-05-05-1938 7100-05-05-1937 7100-05-04-1914 7100-05-04-1913 7100-05-03-1846 7100-05-03-1838 … $
Die Ausgabe zeigt das 7100-05-06-2028 installiert ist. Allerdings gibt es Filesets die nicht auf den Stand von 7100-05-06-2028 aktualisiert wurden, weshalb eine niedrigere Version bei „oslevel –s“ angezeigt wird.
Möchte man wissen welche Filesets einen niedrigeren Stand als 7100-05-06-2028 haben, kann „oslevel –s –l“ verwendet werden:
$ oslevel -s -l 7100-05-06-2028 Fileset Actual Level Service Pack Level ----------------------------------------------------------------------------- openssl.base 1.0.2.1801 1.0.2.2002 openssl.license 1.0.2.1801 1.0.2.2002 openssl.man.en_US 1.0.2.1801 1.0.2.2002 $
Die OpenSSL Filesets sind also noch in einer älteren Version (1.0.2.1801) installiert und müssten auf 1.0.2.2002 aktualisiert werden, damit der Service-Pack 7100-05-06-2028 vollständig installiert ist.
Wir hatten kürzlich einen kleineren Ausfall auf einem unserer Systeme. Benutzer konnten sich nicht mehr einloggen und Benutzer konnten eine Web-GUI nicht mehr benutzen. Das Problem trat sporadisch immer mal wieder auf und verschwand dann wieder. Während dieser Zeiten fanden sich im Syslog jede Menge Meldungen der folgenden Art:
Mar 4 07:56:05 aix01 daemon:err|error secldapclntd: LDAP failed to bind to server aixldapp11. Mar 4 07:56:05 aix01 daemon:err|error secldapclntd: LDAP failed to bind to server aixldapp12. Mar 4 07:56:10 aix01 daemon:err|error secldapclntd: LDAP failed to bind to server aixldapp11. Mar 4 07:56:10 aix01 daemon:err|error secldapclntd: LDAP failed to bind to server aixldapp12. ...
Diese Meldungen deuteten daraufhin, das beide LDAP-Server zeitweise nicht erreichbar waren. Untersuchungen der Logs auf den beiden LDAP-Servern ergaben aber keine Verbindungsversuche, die zurückgewiesen worden sind. Und auch eine Untersuchung der Firewall-Logs ergab das die Firewall hier keine Pakete zu den LDAP-Servern geblockt hat.
Wir haben daraufhin einen Case bei IBM eröffnet und bekamen auch prompt Anweisungen für das Aufsetzen eines speziellen LDAP-Tracings zurück. Allerdings ist das Problem dann nicht mehr aufgetreten, und somit konnte durch das Tracing auch die Ursache nicht ermittelt werden.
Das betreffende System ist über das Internet erreichbar und daher wurde die Anzahl der ephemeral Ports aus Sicherheitsgründen eingeschränkt. Nur etwa 1500 ephemeral Ports sind über die Firewall erlaubt und auf AIX konfiguriert (tcp_ephemeral_high und tcp_ephemeral_low). Wir haben auf einem Test-System dann nachgestellt was passiert wenn die verfügbaren ephemeral Ports ausgeschöpft sind. Es kam dann sofort zu den obigen Meldungen, sobald der LDAP-Client eine neue Verbindung aufmachen möchte.
Eine Ursache für die LDAP Client Fehlermeldung „LDAP failed to bind to server“ kann also auch die Nichtverfügbarkeit von ephemeral Ports sein!
Ab AIX 7.2 TL4 bzw. VIOS 3.1.1.10 gibt es für physikalische FC-Adapter das neue Attribut „label“. Dieses Attribut kann vom Administrator auf eine beliebige Zeichenkette (maximal 255 Zeichen) gesetzt werden. Auch wenn das Attribut nur informativen Character hat, kann es in PowerVM Virtualisierungsumgebungen äußerst nützlich sein. Hat man eine größere Anzahl von Managed Systems, ist nicht immer klar erkennbar an welche FC-Fabric ein bestimmter FC-Port angebunden ist. Das lässt sich natürlich in der Dokumentation der eigenen Systeme nachschauen, ist aber doch mit einem gewissen Aufwand verbunden. Einfacher ist es, wenn man diese Information direkt mit den FC-Adaptern verknüpft, was das neue Attribut „label“ auf einfache Weise erlaubt. Unter AIX:
# chdev -l fcs0 -U -a label="Fabric_1" fcs0 changed # lsattr -El fcs0 -a label -F value Fabric_1 #
Auf Virtual-I/O-Servern kann das Attribut auch über den padmin-Account gesetzt werden:
/home/padmin> chdev -dev fcs1 -attr label="Fabric_2" -perm fcs1 changed /home/padmin> lsdev -dev fcs1 -attr label value Fabric_2 /home/padmin>
Das Attribut ist auch für ältere FC-Adapter definiert.
Bei konsequenter Verwendung des Attributes „label“ kann man jederzeit für jeden FC-Adapter online feststellen, an welche Fabric der Adapter angebunden ist. Dazu muß lediglich einmal für jeden FC-Adapter diese Information hinterlegt werden.
(Hinweis: Für AIX 7.1 wurde das Attribut „label“ nicht implementiert, zumindest nicht bis 7.1 TL5 SP6.)
In Teil III unserer Artikel-Reihe „AIX LVM: Mechanik von migratepv“ zeigen wir wie inkorrekte Spiegelung von Logical Volumes online korrigiert werden kann. Dazu sind lediglich die Kommandos migratelp und migratepv, sowie ein gutes Verständnis der Arbeitsweise dieser Kommandos notwendig.
Hier die Links zu den Artikeln der Reihe:
AIX LVM: Mechanik von migratepv (Part I)
Der Versuch ein ungespiegeltes LV in einer VG mit Mirror Pools anzulegen resultiert in dem folgenden Fehler:
# mklv -t jfs2 -p copy1=DC1 datavg01 10 0516-1829 mklv: Every mirror pool must contain a copy of the logical volume. 0516-822 mklv: Unable to create logical volume. #
Die Ursache ist das Attribut Mirror Pool Strictness der VG, welches auf ‚super-strict‚ gesetzt ist. Im Artikel Mirror Pools: Verstehen der Mirror Pool Strictness wird die Bedeutung der Mirror Pool Strictness anhand von Beispielen untersucht.
Beim Anlegen eines gespiegelten Logical Volumes ist die folgende Fehlermeldung aufgetreten:
# mklv -c 2 -t jfs2 datavg01 10 0516-1814 lcreatelv: Mirror pools must be defined for each copy when strict mirror pools are enabled. 0516-822 mklv: Unable to create logical volume. #
Ursache dafür ist das die Mirror Pool Strictness für die Volume Group gesetzt ist. In dem Artikel Mirror Pools: Verstehen der Mirror Pool Strictness wird dies genauer untersucht und erläutert.
Viele IT-Umgebungen betreiben Ihre Systeme in mehr als einem Rechenzentrum. Um im Falle eines Ausfalls eines kompletten Rechenzentrums trotzdem keinen Datenverlust zu haben, werden die Daten zwischen 2 oder mehr Rechenzentren gespiegelt. Die Spiegelung kann dabei durch das Storage realisiert sein (storage based mirroring) oder durch einen Volume Manager (LVM im Falle von AIX) auf dem Server (host based mirroring). Im Artikel Mirror Pools: Einführung betrachten wir Spiegelungen mittels AIX Logical Volume Manager und Mirror Pools. Dabei soll gezeigt werden, wie mit Hilfe von Mirror Pools das korrekte Spiegeln von Logical Volumes realisiert werden kann. In größeren Umgebungen mit vielen Physical Volumes ist das Einhalten einer korrekten Spiegelung ohne Mirror Pools schwierig und für den Administrator eine Herausforderung.