Das Kommando chrctcp

chrctcp

Unter AIX wird der System Resource Controller (SRC) zum kontrollieren von Subsystemen und Subservern verwendet. Die Kommandos lssrc, startsrc und stopsrc dürften jedem AIX Administrator bekannt sein. Nicht ganz so bekannt ist das Kommando chrctcp mit dem Subsysteme, die über /etc/rc.tcpip gestartet werden, verwaltet werden können. Durch Nutzung dieses Kommandos kann das Editieren des Start-Skriptes /etc/rc.tcpip vermieden werden. Die meisten Administratoren kennen und verwenden nur die Optionen „-a“ (add/activate), „-d“ (delete/deactivate) und „-S“ (start, stop or restart subsystem). Das Kommando chrctcp hat aber über die Optionen „-c“ (change) und „-s“ (show) noch mehr Funktionalität zu bieten, was von SMIT auch genutzt wird. (Letztlich wurde chrctcp wohl auch eigens für die Verwendung durch SMIT geschrieben.)

Eine Reihe von Subsystemen wird beim Booten über /etc/rc.tcpip gestartet. Allerdings nur wenn es einen Eintrag der folgenden Form im Skript /etc/rc.tcpip gibt:

start /usr/sbin/inetd "$src_running"

Soll ein bestimmtes Subsystem beim Booten nicht gestartet werden, muss das entsprechende Subsystem in /etc/rc.tcpip auskommentiert werden:

#start /usr/sbin/inetd "$src_running"

Im Prinzip kann die Änderung mit einem Editor durchgeführt werden. Es gibt aber über das Kommando chrctcp einen viel eleganteren Weg. Das Kommando chrctcp kann die Datei /etc/rc.tcpip automatisiert editieren. Soll ein bestimmter Dienst beim nächsten Booten nicht mehr gestartet werden, kann chrctcp mit der Option „-d“ verwendet werden, um den Dienst auszukommentieren:

# chrctcp -d inetd
# grep /usr/sbin/inet /etc/rc.tcpip
#start /usr/sbin/inetd "$src_running"
#

Dies hat keinen Einfluß auf das aktuell laufende Subsystem. Möchte man das laufende Subsystem zusätzlich stoppen, kann man entweder zusätzlich das Kommando „stopsrc –s“ verwenden, oder, was deutlich einfacher ist, einfach die Option „-S“ von chrctcp zusätzlich verwenden:

# chrctcp -S -d inetd
0513-044 The /usr/sbin/inetd Subsystem was requested to stop.
#

Das Subsystem wird in /etc/rc.tcpip auskommentiert und zusätzlich wird das eventuell laufende Subsystem gestoppt.

Ähnlich kann man vorgehen, wenn man einen bisher ungenutzten Dienst aus /etc/rc.tcpip nutzen möchte. Um den entsprechenden Eintrag zu aktivieren, kann die Option „-a“ verwendet werden:

# grep /usr/sbin/inetd /etc/rc.tcpip
#start /usr/sbin/inetd "$src_running"
# chrctcp -a inetd
# grep /usr/sbin/inetd /etc/rc.tcpip
start /usr/sbin/inetd "$src_running"
#

Hinweis: Der Eintrag ‚#start /usr/sbin/inetd „$src_running“‚ muss schon in auskommentierter Form an der richtigen Stelle in der Datei stehen!

Soll nicht nur die Datei /etc/rc.tcpip angepasst werden, sondern der Dienst auch sofort gestartet werden, kann wieder die Option „-S“ zusätzlich verwendet werden:

# grep /usr/sbin/inetd /etc/rc.tcpip
#start /usr/sbin/inetd "$src_running"
# chrctcp -S -a inetd
0513-059 The inetd Subsystem has been started. Subsystem PID is 5636582.
# grep /usr/sbin/inetd /etc/rc.tcpip
start /usr/sbin/inetd "$src_running"
#

Im folgenden bleiben wir exemplarisch beim inetd als Beispiel. Das Beschriebene gilt aber in gleicher Weise für andere Subsysteme.

Dienste wie inetd, syslogd und andere besitzen häufig Optionen und Argumente, die beim Start angegeben werden können. Z.B. bietet inetd die folgenden Optionen und Argumente:

-d   Versenden von Debugging Informationen an syslogd

-6   Unterstützung von IPv6

file  Angabe einer Konfigurationsdatei die anstelle von /etc/inetd.conf verwendet werden soll.

Mit dem Kommando chrctcp und der Option „-s“ lassen sich die verwendeten Optionen und Argumente anzeigen:

# chrctcp -s inetd
#debug_mode:ipv6_mode:config_file
no:no:
#

Die Beispiel-Ausgabe zeigt das Debugging und IPv6 deaktiviert sind und keine alternative Konfigurationsdatei angegeben wurde.

Mit der Option „-c“ (change) kann man die Optionen und Argumente ändern. Attribute können mit der Option „-f“ angegeben werden. Als Beispiel aktivieren wir Debugging und erlauben IPv6:

# chrctcp -c inetd -f debug=yes -f ipv6=yes
# grep /usr/sbin/inetd /etc/rc.tcpip
start /usr/sbin/inetd "$src_running" " -d  -6 "
#

Ein Blick in /etc/rc.tcpip zeigt das der Start von inetd um die Optionen „-d“ (Debugging) und „-6“ (IPv6) ergänzt wurde! Geändert wurde aber wieder nur die Start-Datei /etc/rc.tcpip, ein eventuell schon laufender inetd bleibt von der Änderung unberührt:

# ps -ef|grep ine[t]d
    root  5636582  4587924   0 18:34:47      -  0:00 /usr/sbin/inetd
#

Wie beim Aktivieren und Deaktivieren von Subsystemen kann auch beim Ändern die Option „-S“ verwendet werden:

# chrctcp -S -c inetd -f debug=yes -f ipv6=yes
0513-044 The inetd Subsystem was requested to stop.
0513-059 The inetd Subsystem has been started. Subsystem PID is 5636584.
#

Der Dienst wird dann gestoppt und sofort wieder gestartet. Natürlich dann mit den geänderten Optionen und Argumenten:

# ps -ef|grep ine[t]d
    root  5636584  4587924   0 18:49:25      -  0:00 /usr/sbin/inetd -d -6
#

Die beim nächsten Booten verwendeten Optionen und Argumente lassen sich mit der Option „-s“ auflisten:

# chrctcp -s inetd
#debug_mode:ipv6_mode:config_file
yes:yes:
#

Etwas unglücklich ist die Tatsache, das die im Header angezeigten Bezeichnungen (debug_mode, ipv6_mode, config_file) nicht ganz mit den zu verwendenden Attributnamen übereinstimmen. Die korrekten unterstützten Attributnamen im Falle von inetd sind debug, ipv6 und file.

In einem der nächsten Beiträge werden wir die unterstützten Attribute für weitere Subsysteme einmal auflisten und tabellarisch zur Verfügung stellen.

Pfad zum Executable eines laufenden AIX Prozesses herausfinden

Wurde ein Prozeß nicht mit absolutem Pfad gestartet, dann ist es überraschend schwierig den absoluten Pfad für das zugehörige Executable herauszufinden.

Wir demonstrieren dies am Beispiel von Splunk:

$ ps -ef |grep splun[k]d
    root  7143802  5702116   0   Apr 23      - 23:26 splunkd --nodaemon -p 8089 _internal_exec_splunkd
    root 31916484  7143802   0   Apr 23      -  0:00 [splunkd pid=7143802] splunkd --nodaemon -p 8089 _internal_exec_splunkd [process-runner]
$

Beim Start des Prozesses mit der PID 31916484 wurde zusätzlich das Argument 0 abgeändert.

Ein Teil der Informationen zu einem Prozeß sind über das Prozeß-Dateisystem /proc verfügbar. Da Splunk unter der Kennung von root läuft, sind root-Rechte notwendig, um auf die Informationen unter /proc zum Prozeß zuzugreifen.

Unterhalb von /proc gibt es für jeden aktiven Prozeß ein Unterverzeichnis mit der PID als Verzeichnisname.

# ls -l /proc/31916484
total 32
-rw-------    1 root     system            0 Apr 28 15:17 as
-r--------    1 root     system          128 Apr 28 15:17 cred
--w-------    1 root     system            0 Apr 28 15:17 ctl
lr-x------   38 root     system            0 Apr 28 13:31 cwd -> /root/
dr-x------    1 root     system            0 Apr 28 15:17 fd
dr-xr-xr-x    1 root     system            0 Apr 28 15:17 lwp
-r--------    1 root     system            0 Apr 28 15:17 map
-r--------    1 root     system            0 Apr 28 15:17 mmap
dr-x------    1 root     system            0 Apr 28 15:17 object
-r--r--r--    1 root     system          448 Apr 28 15:17 psinfo
lr-x------   48 root     system            0 Apr 28 09:02 root -> /
-r--------    1 root     system        12288 Apr 28 15:17 sigact
-r--------    1 root     system         1520 Apr 28 15:17 status
-r--r--r--    1 root     system            0 Apr 28 15:17 sysent
#

Im Unterverzeichnis object ist neben den geöffneten Dateien auch das Executable verfügbar:

# ls -l /proc/31916484/object
total 854216
-r-xr-xr-x    1 root     system    194980846 Nov 16 2019  a.out
-r-xr-xr-x    1 bin      bin           10749 Sep 21 2015  jfs2.10.5.103039
-r--r--r--    1 bin      bin        12858422 May 28 2019  jfs2.10.5.225767
-r-xr-xr-x    1 bin      bin           77411 Mar 25 2021  jfs2.10.5.4157
-r-xr-xr-x    1 bin      bin        13438344 Jul 27 2021  jfs2.10.5.4205
-r--r--r--    1 bin      bin         1351386 Mar 09 2021  jfs2.10.5.4209
-r--r--r--    1 bin      bin           80450 Jul 27 2021  jfs2.10.5.4220
-r-xr-xr-x    1 root     system    194980846 Nov 16 2019  jfs2.10.9.139342
-r-xr-xr-x    1 root     system      3487967 Nov 12 2019  jfs2.10.9.155672
-r-xr-xr-x    1 root     system       228087 Nov 12 2019  jfs2.10.9.155673
-r-xr-xr-x    1 root     system      2688333 Nov 16 2019  jfs2.10.9.155675
-r-xr-xr-x    1 root     system       901800 Nov 12 2019  jfs2.10.9.155677
-r-xr-xr-x    1 root     system      4256593 Nov 12 2019  jfs2.10.9.155679
-r-xr-xr-x    1 root     system       568791 Nov 16 2019  jfs2.10.9.155684
-r-xr-xr-x    1 root     system      6166802 Nov 12 2019  jfs2.10.9.155685
-r-xr-xr-x    1 root     system      1239656 Nov 12 2019  jfs2.10.9.155686
-r-xr-xr-x    1 root     system       124218 Nov 16 2019  jfs2.10.9.155690
#

Die Datei a.out repräsentiert dabei das Executable. Ein Zugriff auf diese Datei wird auf die Datei des Executables umgeleitet. Mit dem Kommando istat lassen sich Informationen wie Inode-Nummer und Gerät (Dateisystem) des Executables heraufinden:

# istat /proc/31916484/object/a.out
Inode 139342 on device 10/9     File
Protection: r-xr-xr-x  
Owner: 0(root)          Group: 0(system)
Link count:   1         Length 194980846 bytes

Last updated:   Tue Jul 27 07:15:40 CEST 2021
Last modified:  Sat Nov 16 01:23:05 CET 2019
Last accessed:  Thu Apr 28 10:38:13 CEST 2022

#

Die Inode-Nummer des Executables ist 139342. Das Dateisystem ist das Dateisystem auf dem Gerät mit der Major-Nummer 10 und der Minor-Nummer 9 („device 10/9“).

Man könnte nun erst einmal das Gerät durch eine Suche unter /dev herausfinden:

$ ls -l /dev | grep "10,  9"
brw-rw----    1 root     system       10,  9 Jul 27 2021  hd10opt
crw-rw----    1 root     system       10,  9 Apr 05 13:36 rhd10opt
$

und dann das zugehörige Dateisystem über df ermitteln:

$ df | grep hd10opt
/dev/hd10opt    12582912   7527920   41%    33349     4% /opt
$

Allerdings geht dies noch einfacher. Man kann einfach den Pfad für die a.out Datei bei df angeben:

# df /proc/31916484/object/a.out
Filesystem    512-blocks      Free %Used    Iused %Iused Mounted on
/dev/hd10opt    12582912   7527912   41%    33349     4% /opt
#

Das gesucht Dateisystem ist das /opt-Dateisystem. Nun kann man mit einer Suche nach der Inode-Nummer 139342 in /opt den absoluten Pfad zum Executable herausfinden:

# find /opt -inum 139342
/opt/splunkforwarder/bin/splunkd
#

Der Prozeß mit der PID 31916484 führt also das Executable /opt/splunkforwarder/bin/splunkd aus.

Mit einem kleinen Trick kann man die Suche auch deutlich abkürzen. Dazu benötigt man eine Shell als Benutzer root. In dieser Shell öffnet man die a.out explizit mittels exec und einer (freien) Descriptor-Nummer:

# exec 5</proc/31916484/object/a.out
#

Unsere aktuelle Shell hat damit das Executable geöffnet (über den Filedescriptor 5)! Nun lässt man sich mit dem Kommando procfiles die offenen Dateien dieser Shell anzeigen. Dabei benutzt man die Option „-n“, welche die absoluten Pfade von Dateien anzeigt, die zu einem Filedescriptor gehören:

# procfiles -n $$
19136808 : ksh
  Current rlimit: 10000 file descriptors
   0: S_IFCHR mode:00 dev:10,4 ino:4463 uid:0 gid:0 rdev:21,3
      O_RDWR | O_NOCTTY  name://dev/pts/3
   1: S_IFCHR mode:00 dev:10,4 ino:4463 uid:0 gid:0 rdev:21,3
      O_RDWR | O_NOCTTY  name://dev/pts/3
   2: S_IFCHR mode:00 dev:10,4 ino:4463 uid:0 gid:0 rdev:21,3
      O_RDWR | O_NOCTTY  name://dev/pts/3
   5: S_IFREG mode:0555 dev:10,9 ino:139342 uid:0 gid:0 rdev:0,0
      O_RDONLY size:194980846  name:/opt/splunkforwarder/bin/splunkd
   10: S_IFREG mode:0444 dev:10,5 ino:124151 uid:0 gid:0 rdev:0,0
      O_RDONLY size:5875  name:/usr/lib/nls/msg/EN_US/ksh.cat
   63: S_IFREG mode:0600 dev:10,4 ino:41933 uid:0 gid:0 rdev:0,0
      O_RDWR | O_APPEND size:5494  name://root/.sh_history
#

Hinweis: Die spezielle Variable $$ wird von der Shell durch die PID der Shell ersetzt.

Für den Filedescriptor 5 wird der absolute Pfad /opt/splunkforwarder/bin/splunkd angezeigt.

Anschließend sollte man den Filedescriptor wieder schließen:

# exec 5<&-
#

Passwörter nicht-interaktiv ändern

AIX bietet mit dem Kommando chpasswd die Möglichkeit Passwörter sowohl interaktiv, als auch nicht interaktiv zu ändern. Allerdings ist die Benutzung des Kommandos dem Benutzer root vorbehalten.

Im einfachsten Fall kann der Administrator das Kommando ohne Argumente starten. Es wird dann die interaktive Eingabe von Benutzernamen und zugehörigem Passwort, getrennt durch einen Doppelpunkt „:“, erwartet. Pro Zeile wird ein Benutzername und ein Klartext-Passwort angegeben. Die Eingabe muss mit Control-D beendet werden:

# chpasswd
user01:hello19
<Control>-<D>
#

Es wird per Default das ADMCHG Flag für den Benutzer-Account gesetzt:

# pwdadm -q user01
user01:
        lastupdate = 1650438240
        flags = ADMCHG

#

Damit wird der Benutzer beim nächsten Login aufgefordert sein Passwort zu ändern.

Möchte man das Setzen des Passworts über ein Skript nicht interaktiv machen, kann z.B. ein sogeanntes „here“ Dokument verwendet werden:

# chpasswd -c <<EOF
> user02:hello20
> EOF
#

Diese Variante erfordert keine manuelle Eingabe mehr. Die einzugebenden Benutzer und Passwörter können direkt im Skript eingetragen werden. Um zu Verhindern das die Benutzer beim nächsten Login aufgefordert werden ihr Passwort zu ändern, haben wir die Option „-c“ (clear all password flags) verwendet.

Alternativ könnte man aber auch z.B. eine Pipe mit einem echo-Kommando verwenden:

# echo user03:hello21 | chpasswd -c
#

Verwendet man eine bash, dann gibt es noch die besonders elegante Möglichket eine Eingabe-Umleitung auf eine Zeichenkette einzurichten. Dazu werden 3 Kleiner-Zeichen „<<<“ gefolgt von einer Zeichenkette verwendet:

(bash)# chpasswd -c <<<user04:hello22
(bash)#

In allen obigen Beispielen wurde das Passwort jeweils im Klartext angegeben. Das ist in der Regel bei nicht-interaktivem Setzen des Passworts nicht gewünscht. Man kann das Passwort aber auch in verschlüsselter Form angeben. Dazu muss lediglich die Option „-e“ (encrypted password) verwendet werden. Es erfolgt keine Prüfung durch das chpasswd Kommando, ob das angegebene verschlüsselte Passwort die richtige Länge und Syntax hat, oder ob es überhaupt gültig ist!

Allerdings muss man nun beachten, dass das verschlüsselte Passwort eventuell Sonderzeichen wie „$“ oder „!“ enthält, die von der Shell ausgewertet und eventuell ersetzt werden. Bei Verwendung eines „here“ Dokuments werden Sonderzeichen in der Eingabe durch die Shell interpretiert. Wir demonstrieren dies durch Setzen einer Variable VAR, die dann im verschlüsselten Passwort verwendet wird:

# VAR=hello
# chpasswd -e -c <<EOF
> user02:{ssha512}06TQ.$VAR
EOF
#

Das angegebene verschlüsselte Passwort ist viel zu kurz und daher nicht gültig, es gibt aber keine Fehlermeldung. Der Teil „$VAR“ wird von der Shell durch den Wert „hello“ ersetzt, wie das Anzeigen des gesetzten Passworts zeigt:

# lsuser -a spassword user02
user02 spassword={ssha512}06TQ.hello
#

Die Ersetzung durch die Shell lässt sich verhindern, indem das Wort „EOF“ in Anführungszeichen gesetzt wird:

# VAR=hello
# chpasswd -e -c <<”EOF”
> user02:{ssha512}06TQ.$VAR
EOF
#

Dieses Mal wurde “$VAR” nicht ersetzt:

# lsuser -a spassword user02
user02 spassword={ssha512}06TQ.$VAR
#

(Das verschlüsselte Passwort ist aber nach wie vor zu kurz und damit ungültig.)

Gruppen-Mitgliedschaft unter AIX mit chgrpmem verwalten

AIX bietet ein elegantes Kommando um die Mitgliedschaft von Benutzern in Gruppen zu ändern: chgrpmem.

Als Beispiel verwenden wir die Benutzer user01, user02, …, sowie die Gruppe mygroup:

$ lsgroup mygroup
mygroup id=225 admin=false users= registry=files
$

Die Gruppe mygroup besitzt aktuell noch keine Mitglieder (users=““).

Um die beiden lokalen Benutzer user01 und user02 der Gruppe mygroup hinzuzufügen, muss die Option „-m“ (Member) verwendet werden. Dann folgt das Zeichen Plus „+“ für Hinzufügen und eine komma-separierte Liste von Benutzernamen. Als letztes Argument muss noch die Gruppe angegeben werden:

# chgrpmem -m + user01,user02 mygroup
#
# lsgroup mygroup
mygroup id=225 admin=false users=user01,user02 registry=files
#

Verwendet man anstelle des Plus-Zeichens „+“ das Gleichheits-Zeichen „=“, dann wird die aktuelle Liste der Benutzer durch die angegebene Liste von Benutzernamen überschrieben:

# chgrpmem -m = user03,user04,user05 mygroup
# 
# lsgroup mygroup
mygroup id=225 admin=false users=user03,user04,user05 registry=files
#

Das Entfernen von Benutzern erfolgt durch Verwenden eines Minus-Zeichens „“ z.B. Entfernen des Benutzers user04:

# chgrpmem -m - user04 mygroup
# 
# lsgroup mygroup
mygroup id=225 admin=false users=user03,user05 registry=files
#

Das Entfernen eines Benutzers aus der Mitgliederliste einer Gruppe muss aber nicht immer erfolgreich sein! Wir legen den Benutzer user06 mit primärer Gruppe mygroup an:

# mkuser pgrp=mygroup user06
# 
# lsgroup mygroup
mygroup id=225 admin=false users=user03,user05,user06 registry=files
#

Die Ausgabe von lsgroup zeigt das der Benutzer user06 ebenfalls Mitglied der Gruppe mygroup ist. Allerdings lässt sich in diesem Fall die Mitgliedschaft nicht aufheben:

# chgrpmem -m - user06 mygroup
Cannot drop "user06" from primary group "mygroup".
#

Ein Benutzer muss immer eine primäre Gruppe haben! Mit dem Kommando chgrpmem können nur die zusätzlichen Mitgliedschaften von Benutzern verwaltet werden. Die primäre Gruppe kann nur mit dem Kommando chuser geändert werden.

Hinweis: Mit dem Kommando chgrpmem und der Option „-a“ können auch die Administratoren einer Gruppe geändert werden. Dies wird in der Praxis aber eher selten verwendet und ist daher hier auch nicht angesprochen.

Ändern der PVID eines Physical Volumes

Jedes Physical Volume das vom AIX LVM verwendet wird, besitzt eine eindeutige Physical Volume ID, kurz PVID. Die PVID ist eine Software-generierte ID, die im Header Bereich einer Platte (Block 0) abgespeichert wird. Wenn eine neue Platte einem AIX System hinzugefügt wird, dann besitzt das neue Physical Volume noch keine PVID. Sobald ein Physical Volume einer Volume Group hinzugefügt wird, wird eine PVID generiert, wenn das Physical Volume noch keine PVID haben sollte. Eine schon existierende PVID wird übernommen.

Eine PVID kann auch manuell mit Hilfe des Kommandos chdev erzeugt werden. Dabei wird das Attribut pv auf den Wert yes gesetzt:

# chdev -l hdisk3 -a pv=yes
hdisk3 changed
#

Die gesetzte PVID kann entweder mit dem Kommando lsattr oder auch einfach mit lspv angezeigt werden:

$ lsattr -El hdisk3 -a pvid -F value
00c276b0084049750000000000000000
$
$ lspv |grep hdisk3
hdisk3          00c276b008404975                    None                       
$

Eine PVID kann auch wieder entfernt werden. Dazu darf das Physical Volume allerdings nicht in Verwendung sein (.z.B. als Teil einer Volume Group).

Um eine PVID eines Physical Volumes zu löschen, kann das Attribut pv auf den Wert clear gesetzt werden:

# chdev -l hdisk3 -a pv=clear
hdisk3 changed
#

Die PVID wurde entfernt, wie die nachfolgenden Aussagen zeigen:

$ lsattr -El hdisk3 -a pvid -F value
none
$
$ lspv |grep hdisk3
hdisk3          none                                None                       
$

Der Versuch die PVID eines Physical Volumes zu löschen, das in Verwendung ist, führt zu der folgenden Fehlermeldung:

# chdev -l hdisk0 -a pv=clear
Method error (/usr/lib/methods/chgdisk):
        0514-062 Cannot perform the requested function because the
                 specified device is busy.
     pv    

#

 

Größe eines Physical Volumes bestimmen

Um die Größe eines Physical Volumes (Disk, LUN) zu bestimmen, gibt es unter AIX eine Reihe verschiedener Möglichkeiten.

Besitzt man root-Rechte, kann das Kommando bootinfo mit der Option „-s“ (size) verwendet werden:

#  bootinfo -s hdisk0
51200
#

Die Größe des Physical Volumes wird in MB ausgegeben. Im Beispiel also 51.200 MB oder ca 50 GB.

Ohne root-Rechte, kann das Kommando getconf verwendet werden. Mit diesem Kommando können systemweite Konfigurationsparameter, aber auch gerätespezifische Variablen angezeigt werden. Um die Größe eines Physical Volumes anzuzeigen, kann die gerätespezifische Variable DISK_SIZE verwendet werden. Das in Frage kommende Physical Volume wird über den absoluten Pfad der Block- oder Character-Gerätedatei des Physical Volumes angegeben:

$ getconf DISK_SIZE /dev/hdisk0
51200
$

Auch hier wird die Größe in MB ausgegeben.

Eine weitere Möglichkeit, die aber wieder root-Rechte erfordert, ist die Verwendung des Kommandos lsmpio. Dieses bietet über die Option „-q“ (query) Daten über ein MPIO Storage Gerät anzuzeigen:

# lsmpio -ql hdisk0
Device:  hdisk0
…
           Capacity:  50.00GiB
…
#

Die Größe wird dieses Mal direkt in GB (GiB) angezeigt.

Ist das Physical Volume Teil einer Volume Group, kann auch das Kommando lspv verwendet werden, um die Größe zumindest abzuschätzen:

$ lspv hdisk0
…
TOTAL PPs:          199 (50944 megabytes)    VG DESCRIPTORS:   2
…                                      
$

Hier wird der für Daten verwendbare Bereich angegeben (50.944 MB), das Physical Volume selbst ist etwas größer, da ja auch noch Platz für Verwaltungsinformationen verwendet wird.

show_life_cycle: neuer URL für FLRT Lite Daten-File

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.)

Welche Größe hat der interne Log bei JFS2

inline log size

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:

    1. Der Log kann nicht größer als 10% der Dateisystem-Größe sein.
    2. Die maximale Größe kann 2047 MB nicht überschreiten.

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!

YUM mit NIMHTTP

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.

Oslevel –s zeigt nicht die neueste installierte Version an

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.