Wir wollen Feedback!

Wir wollen Feedback! Das neue PowerCampus „LPAR tool“ steht zum Download bereit! In weiten Teilen überarbeitet und in C++ geschrieben. Es unterstützt Output in verschiedenen Formaten: JSON + YAML!

Die ersten 100 Feedbacks erhalten beim Kauf zwei Lizenzen (2 LPARS) gratis! Für immer!

Also, downloaden installieren und Feedback geben, einfach per Mail an info@powercampus.de!

Die integrierte Test-Lizenz unterstützt ohne weitere Registrierung eine HMC und zwei komplette Managed Systems! Für eine erweiterte Trialversion für 4 HMC’s und unbegrenzte MS einfach eine Mail an info@powercampus.de senden.

Download „LPAR tool“: https://powercampus.de/en/download-2/

LPAR Console über einen Virtual I/O Server

Für gewöhnlich wird ein Console für eine LPAR über eine HMC gestartet, per GUI oder CLI (vtmenu oder mkvterm). Eine Console ist damit von der Verfügbarkeit einer HMC abhängig. Während eines HMC Updates oder bei Problemen mit der HMC ist dann eventuell keine Konsolen-Verbindung für eine LPAR möglich.

Relativ unbekannt ist die Möglichkeit eine Console zu einer LPAR über einen Virtual-I/O-Server zu konfigurieren. Ist die HMC dann nicht verfügbar, kann über den Virtual-I/O-Server eine Console gestartet werden. Auf der Client-LPAR ist hierzu keine Konfiguration notwendig! Jede Client-LPAR besitzt standardmäßig 2 virtuelle serielle Server Adapter (Slot 0 und 1). Konfiguriert man auf einem Virtual-I/O-Server einen zugehörigen Client Adapter, dann kann man diesen für eine Consolen-Verbindung nutzen.

Auf dem Virtual-I/O-Server benötigt man lediglich einen unbenutzten virtuellen Slot (hier Slot 45). Die Client-LPAR hat die LPAR-ID 39. Der virtuelle serielle Client-Adapter kann mit dem folgenden Kommando angelegt werden:

hmc01 $ chhwres -m ms02 -r virtualio --rsubtype serial -o a -p ms02-vio1 -s 45 -a adapter_type=client,remote_lpar_name=aix02,remote_slot_num=0,supports_hmc=0
hmc01 $

Jetzt kann jederzeit eine Console für die LPAR über den Virtual-I/O-Server gestartet werden:

ms02-vio1 :/home/padmin> mkvt -id 39
AIX Version 7
Copyright IBM Corporation, 1982, 2018.
Console login: root
root's Password: XXXXXX


aix02  AIX 7.2         powerpc


Last unsuccessful login: Mon Mar 18 23:14:26 2019 on ssh from N.N.N.N
Last login: Wed Mar 27 20:19:22 2019 on /dev/pts/0 from M.M.M.M
[YOU HAVE NEW MAIL]
aix02:/root> hostname
aix02
aix02:/root>

Das Kommando mkvt auf dem Virtual-I/O-Server entspricht dem Kommando mkvterm auf der HMC. Hier muss die gewünschte Partition über die LPAR-ID angegeben werden. Beenden der Console geht wie gehabt mit „~.“, oder wenn man per SSH auf dem Virtual-I/O-Server eingeloggt ist mit „~~.“.

Alternativ kann man eine Console-Session auch mit dem Kommando rmvt beenden:

ms02-vio1:/home/padmin> rmvt -id 39
ms02-vio1:/home/padmin>

In der Console erscheint dann die folgende Meldung und die Console wird beendet:

Virtual terminal has been disconnected.

$

Mit dem LPAR-Tool kann die Console über einen Virtual-I/O-Server natürlich noch leichter eingerichtet werden. Der virtuelle serielle Adapter auf dem Virtual-I/O-Server kann mit dem Kommando „lpar addserial“ angelegt werden, ein manueller Login auf die HMC ist hierfür nicht notwendig:

$ lpar addserial -c ms02-vio1 45 aix02 0
$

Die Option „-c“ steht für Client-Adapter. Das Kommando legt den Adapter auch gleich im Profil an. Den Erfolg der Aktion kann man mittels „lpar vslots“ überprüfen, dabei werden alle virtuellen Adapter einer LPAR gezeigt:

$ lpar vslots ms02-vio1
SLOT  REQ  TYPE           DATA
0     1    serial/server  remote: -(any)/any status=unavailable hmc=1
1     1    serial/server  remote: -(any)/any status=unavailable hmc=1
2     0    eth            PVID=1 VLANS=- XXXXXXXXXXXX ETHERNET0
3     1    eth            TRUNK(1) IEEE PVID=1 VLANS=201 XXXXXXXXXXXXX ETHERNET0
...
45     0   serial/client  remote: aix02(39)/0 status=unavailable hmc=0
...
$

Das Starten der Console geht dann wie gehabt durch Einloggen als padmin auf dem Virtual-I/O-Server und dem Kommando mkvt.

Vorsicht: Die Consolen-Sitzung über den Virtual-I/O-Server sollte immer beendet werden, wenn sie nicht mehr gebraucht wird. Man kann diese nicht über die HMC beenden! Hier der Versuch eine Console über die HMC zu starten, während noch eine Console über einen Virtual-I/O-Server aktiv ist:

$ lpar console aix02

Open in progress 

A terminal session is already open for this partition. 
Only one open session is allowed for a partition. 
Exiting.... 
Attempts to open the session failed. Please close the terminal and retry the open at a later time. 
If the problem persists, Please contact IBM support. 
Received end of file, Exiting.
Connection to X.X.X.X closed.
$

Auch rmvterm hilft da nicht weiter:

$ lpar rmvterm aix02
/bin/stty: standard input: Inappropriate ioctl for device
$

Umgekehrt kann auch keine Console über den Virtual-I/O-Server gestartet werden, wenn eine Console über die HMC aktiv ist:

ms02-vio1:/home/padmin> mkvt -id 39
Virtual terminal is already connected.

ms02-vio1:/home/padmin>

Also immer darauf achten das die Console beendet wird.

 

Fehlermeldungen von der Crypto Library beim Einloggen

Auf einigen Systemen fanden sich kürzlich im syslog Fehlermeldungen beim Einloggen mit ssh (oder auch bei /bin/su) der folgenden Art:

Mar 15 10:43:47 aix01 auth|security:err|error sshd[14024884]: Crypto library (CLiC) error: Wrong object type

Mar 15 11:08:42 aix01 auth|security:err|error su: Crypto library (CLiC) error: Wrong signature

Einloggen und auch das su-Kommando funktionierten aber ohne Probleme. Allerdings waren die vielen Fehlermeldungen, eine bei jedem Login, lästig.

Der Hinweis auf die Crypto Library (CLiC), die eigentlich nur bei Verwendung von EFS benötigt wird, war schon mal ein Hinweis bei der Untersuchung. Auf den Systemen ist kein EFS im Einsatz. Eine Überprüfung mit dem Kommando „efskeymgr –V“ ergab folgendes:

$ efskeymgr -V
There is no key loaded in the current process.
$

Hier hätte eigentlich eine Fehlermeldung kommen müssen, mit dem Hinweis das EFS nicht aktiviert ist. Ein Blick ins Verzeichnis /var zeigt das das Verzeichnis /var/efs (in dem die EFS-Keys gespeichert werden) existiert:

$ ls -l /var/efs
total 24
drwx------    2 root     system          256 Apr 25 2017  efs_admin/
-rw-r--r--    1 root     system            0 Apr 25 2017  efsenabled
drwx------   51 root     system         4096 Mar 17 10:40 groups/
drwx------  123 root     system         8192 Mar 17 05:15 users/
$

Es wurde also EFS aktiviert, obwohl es nicht verwendet wird. Zum Deaktivieren von EFS ist eigentlich ein Reboot notwendig. Da es in unserem Fall aber nicht wirklich benutzt wird und vermutlich nur aufgrund eines Versehens oder Fehlers eingeschaltet wurde, behelfen wir uns mit dem folgenden Workaround, wir benennen das Verzeichnis /var/efs um:

$ mv /var/efs /var/efs.orig
$

Ein kurzer Test mit dem Kommando “efskeymgr –V“ zeigt, das für AIX EFS nun nicht aktiv ist:

$ efskeymgr -V
Problem initializing EFS framework.
Please check EFS is installed and enabled (see efsenable) on you system.
Error was: (EFS was not configured)
$

Ein Test-Login mittels ssh bestätigt das beim Login keine Fehlermeldung mehr geloggt wird.

Hinweis: Bitte sicherstellen das EFS wirklich nicht benutzt wird!

 

Welche FC-Ports gehören zu welcher SAN-Fabric?

In größeren Umgebungen mit vielen Managed Systems und mehreren SAN-Fabrics ist es trotz guter Dokumentation nicht immer klar, zu welcher SAN-Fabric ein FC-Port gehört. In vielen Fällen steht die Hardware weit entfernt vom Bildschirm, eventuell sogar in einem ganz anderen Gebäude oder auch geographisch weiter entfernt, so dass man auch nicht einfach vor Ort die Verkabelung überprüfen kann.

In diesem Blog-Beitrag soll gezeigt werden, wie man mit Hilfe von Live-Partition-Mobility (LPM) alle FC-Ports herausfinden kann, die zu einer gegebenen SAN-Fabric gehören.

Wir verwenden der Einfachheit halber das LPAR-Tool, man kann aber auch ohne LPAR-Tool mit Kommandos der HMC CLI arbeiten, also bitte weiterlesen auch wenn das LPAR-Tool nicht verfügbar sein sollte!

Im Folgenden haben wir unsere SAN-Fabrics mit „Fabric1“ und „Fabric2“ bezeichnet. Das unten beschriebene Verfahren kann aber bei beliebig vielen SAN-Fabrics verwendet werden.

Da LPM verwendet werden soll, benötigen wir erst einmal eine LPAR. Wir legen die LPAR auf einem unserer Managed Systems (ms09) mit dem LPAR-Tool an:

$ lpar –m ms09 create fabric1
Creating LPAR fabric1:
done
Register LPAR
done
$

Man kann natürlich auch die HMC GUI oder die HMC CLI verwenden, um die LPAR anzulegen. Wir haben die neue LPAR nach unserer SAN-Fabric „fabric1“ benannt. Jeder andere Name ist aber genauso gut!

Als nächstes benötigt unsere LPAR einen virtuellen FC-Adapter der auf einen FC-Port der Fabric „Fabric1“ gemappt ist:

$ lpar –p standard addfc fabric1 10 ms09-vio1
fabric1 10 ms09-vio1 20
$

Das LPAR-Tool hat auf dem VIOS ms09-vio1 den Slot 20 für den VFC Server Adapter ausgewählt und neben dem Client- auch den Server-Adapter angelegt. Über das HMC GUI oder die HMC CLI können Client und Server Adapter natürlich genauso angelegt werden. Da die LPAR nicht aktiv ist, wurde mittels der Option ‚-p standard‘ angegeben das nur das Profil angepasst werden soll.

Um den VFC Server Adapter auf einen physikalischen FC-Port zu mappen, benötigen wir die Nummer des vfchost Adapters auf dem VIOS ms09-vio1:

$ vios npiv ms09-vio1
VIOS       ADAPT NAME  SLOT  CLIENT OS      ADAPT   STATUS        PORTS
…
ms09-vio1  vfchost2    C20   (3)    unknown  -     NOT_LOGGED_IN  0
…
$

Im Slot 20 haben wir den vfchost2, dieser muss also nun auf einen FC-Port von Fabric „Fabric1“ gemappt werden. Wir mappen auf den FC-Port fcs8, von dem wir wissen das dieser an die Fabric „Fabric1“ geht. Sollten wir uns irren, werden wir dies in Kürze sehen.

Schauen wir uns kurz die WWPNs für den virtuellen FC Client Adapter an:

$ lpar -p standard vslots fabric1
SLOT  REQ  TYPE           DATA
0     yes  serial/server  remote: (any)/any hmc=1
1     yes  serial/server  remote: (any)/any hmc=1
10    no   fc/client      remote: ms09-vio1(1)/20 c050760XXXXX0016,c050760XXXXX0017
$

Ausgestattet mit den WWPNs lassen wir uns nun von unseren Storage-Kollegen eine kleine LUN für diese WWPNs erstellen, die nur in der Fabric „Fabric1“ sichtbar sein soll. Nachdem die Storage-Kollegen die LUN angelegt und das Zoning entsprechend angepasst haben, aktivieren wir unsere neue LPAR im OpenFirmware Modus und öffnen eine Console:

$ lpar activate –p standard –b of fabric1

$ lpar console fabric1

Open in progress 

Open Completed.

IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
...

          1 = SMS Menu                          5 = Default Boot List
          8 = Open Firmware Prompt              6 = Stored Boot List

     Memory      Keyboard     Network     SCSI     Speaker  ok
0 >

Das geht natürlich auch wieder ohne Probleme mit GUI oder HMC CLI.

Im OpenFirmware Modus starten wir ioinfo und überprüfen ob die kleine LUN sichtbar ist. Wenn diese nicht sichtbar ist, dann lag der FC-Port fcs8 doch nicht in der richtigen Fabric!

0 > ioinfo

!!! IOINFO: FOR IBM INTERNAL USE ONLY !!!
This tool gives you information about SCSI,IDE,SATA,SAS,and USB devices attached to the system

Select a tool from the following

1. SCSIINFO
2. IDEINFO
3. SATAINFO
4. SASINFO
5. USBINFO
6. FCINFO
7. VSCSIINFO

q - quit/exit

==> 6

FCINFO Main Menu
Select a FC Node from the following list:
 # Location Code           Pathname
-------------------------------------------------
 1. U9117.MMC.XXXXXXX7-V10-C10-T1  /vdevice/vfc-client@3000000a

q - Quit/Exit

==> 1

FC Node Menu
FC Node String: /vdevice/vfc-client@3000000a
FC Node WorldWidePortName: c050760XXXXXX0016
------------------------------------------
1. List Attached FC Devices
2. Select a FC Device
3. Enable/Disable FC Adapter Debug flags

q - Quit/Exit

==> 1

1. 500507680YYYYYYY,0 - 10240 MB Disk drive

Hit a key to continue...

FC Node Menu
FC Node String: /vdevice/vfc-client@3000000a
FC Node WorldWidePortName: c050760XXXXXX0016
------------------------------------------
1. List Attached FC Devices
2. Select a FC Device
3. Enable/Disable FC Adapter Debug flags

q - Quit/Exit

==> q

Die LUN taucht auf, die WWPN 500507680YYYYYYY ist die WWPN des zugehörigen Storage-Ports, diese ist weltweit eindeutig und kann damit nur in der Fabric „Fabric1“ gesehen werden!

Das Aktivieren der LPAR im OpenFirmware Modus hat zwei Zwecken gedient, zum Einen um zu Überprüfen das die LUN sichtbar ist und unser Mapping auf fcs8 richtig war, zum Anderen hat das System nun die Information welche WWPNs bei einer LPM-Operation gefunden werden müssen, damit die LPAR verschoben werden kann!

Wir deaktivieren die LPAR nun wieder.

$ lpar shutdown –f fabric1
$

Führen wir nun eine LPM Validierung für die inaktive LPAR durch, so kann eine Valdierung nur auf einem Managed System erfolgreich sein, welches einen Virtual-I/O-Server mit einer Anbindung an die Fabric „Fabric1“ besitzt. Mit einer kleinen for-Schleife probieren wir das für einige Managed Systems aus:

$ for ms in ms10 ms11 ms12 ms13 ms14 ms15 ms16 ms17 ms18 ms19
do
echo $ms
lpar validate fabric1 $ms >/dev/null 2>&1
if [ $? -eq 0 ]
then
   echo connected
else
   echo not connected
fi
done

Das Kommando auf der HMC CLI zum Validieren ist ‚migrlpar‚.

Da wir nicht an den Meldungen der Validierung interessiert sind, leiten wir alle Meldungen der Validierung nach /dev/null um.

Hier die Ausgabe der for-Schleife:

ms10
connected
ms11
connected
ms12
connected
ms13
connected
ms14
connected
ms15
connected
ms16
connected
ms17
connected
ms18
connected
ms19
connected

Offensichtlich sind alle Managed Systems an die Fabric „Fabric1“ angebunden. Das ist aber nicht sehr überraschend, da diese genau so aufgebaut wurden.

Interessanter wäre es nun zu wissen welcher FC-Port auf den Managed Systems (Virtual-I/O-Servern) an die Fabric „Fabric1“ angebunden sind. Dazu benötigen wir für jedes Managed System eine Liste der Virtual-I/O-Server und für jeden Virtual-I/O-Server die Liste der NPIV-fähigen FC-ports.

Die Liste der Virtual-I/O-Server kann relativ einfach mit dem folgenden Kommando gewonnen werden:

$ vios -m ms11 list
ms11-vio1
ms11-vio2
$

Auf der HMC CLI kann man das Kommando: lssyscfg -r lpar -m ms11 -F „name lpar_env“ verwenden.

Die NPIV-fähigen Ports kann man mit dem folgenden Kommando herausfinden :

$ vios lsnports ms11-vio1
ms11-vio1       name             physloc                        fabric tports aports swwpns  awwpns
ms11-vio1       fcs0             U78AA.001.XXXXXXX-P1-C5-T1          1     64     60   2048    1926
ms11-vio1       fcs1             U78AA.001.XXXXXXX-P1-C5-T2          1     64     60   2048    2023
...
$

Zum Einsatz kommt das Kommando lsnports auf dem Virtual-I/O-Server. Dieses kann man natürlich auch ohne LPAR-Tool ausführen.

Bei der LPM-Validierung (und natürlich auch bei der Migration) kann man angeben welcher FC-Port auf dem Ziel-System verwendet werden soll, wir zeigen dies hier einmal an zwei Beispielen:

$ lpar validate fabric1 ms10 virtual_fc_mappings=10/ms10-vio1///fcs0 >/dev/null 2>&1
$ echo $?
0
$ lpar validate fabric1 ms10 virtual_fc_mappings=10/ms10-vio1///fcs1 >/dev/null 2>&1
$ echo $?
1
$

Die Validierung mit Ziel ms10-vio1 und fcs0 war erfolgreich, d.h. das dieser FC-Port an die Fabric „Fabric1“ angeschlossen ist. Die Validierung mit Ziel ms10-vio1 und fcs1 war nicht erfolgreich, d.h. das dieser Port nicht an die Fabric „Fabric1“ angebunden ist.

Hier kurz das Kommando das auf der HMC aufgerufen werden muss, falls das LPAR-Tool nicht verwendet werden soll:

$ lpar -v validate fabric1 ms10 virtual_fc_mappings=10/ms10-vio1///fcs0
hmc02: migrlpar -m ms09 -o v -p fabric1 -t ms10 -v -d 5 -i 'virtual_fc_mappings=10/ms10-vio1///fcs0'
$

Um alle FC-Ports die an die Fabric „Fabric1“ angeschlossen sind herauszufinden, brauchen wir eine Schleife über die zu überprüfenden Managed Systems, für jedes Managed Systeme benötigen wir dann eine Schleife über alle VIOS des Managed Systems und letztlich für jeden VIOS eine Schleife über alle FC-Ports mit einer LPM-Validierung.

Wir haben dies im folgenden Skript zusammengefasst. Damit es nicht zu lang wird, haben wir einige Checks weggelassen:

$ cat bin/fabric_ports
#! /bin/ksh
# Copyright © 2018, 2019 by PowerCampus 01 GmbH

LPAR=fabric1

STATE=$( lpar prop -F state $LPAR | tail -1 )

print "LPAR: $LPAR"
print "STATE: $STATE"

if [ "$STATE" != "Not Activated" ]
then
            print "ERROR: $LPAR must be in state 'Not Activated'"
            exit 1
fi

fcsCount=0
fcsSameFabricCount=0

for ms in $@
do
            print "MS: $ms"
            viosList=$( vios -m $ms list )

            for vios in $viosList
            do
                        rmc_state=$( lpar -m $ms prop -F rmc_state $vios | tail -1 )
                        if [ "$rmc_state" = "active" ]
                        then
                                    fcList=
                                    vios -m $ms lsnports $vios 2>/dev/null | \
                                    while read vio fcport rest
                                    do
                                               if [ "$fcport" != "name" ]
                                               then
                                                           fcList="${fcList} $fcport"
                                               fi
                                    done

                                    for fcport in $fcList
                                    do
                                               print -n "${vios}: ${fcport}: "
                                               lpar validate $LPAR $ms virtual_fc_mappings=10/${vios}///${fcport} </dev/null >/dev/null 2>&1
                                               case "$?" in
                                               0)
                                                           print "yes"
                                                           fcsSameFabricCount=$( expr $fcsSameFabricCount + 1 )
                                                           ;;
                                               *) print "no" ;;
                                               esac
                                               fcsCount=$( expr $fcsCount + 1 )
                                    done
                        else
                                    print "${vios}: RMC not active"
                        fi
            done
done

print "${fcsCount} FC-ports investigated"
print "${fcsSameFabricCount} FC-ports in same fabric"

$

Zur Illustration zeigen wir hier kurz einen Lauf des Skripts über einige Managed Systems. Wir starten das Skript mittels time, um zu sehen wie lange das ganze dauert:

$ time bin/fabric_ports ms10 ms11 ms12 ms13 ms14 ms15 ms16 ms17 ms18 ms19
LPAR: fabric1
STATE: Not Activated
MS: ms10
ms10-vio3: RMC not active
ms10-vio1: fcs0: yes
ms10-vio1: fcs2: yes
ms10-vio1: fcs4: no
ms10-vio1: fcs6: no
ms10-vio2: fcs0: yes
ms10-vio2: fcs2: yes
ms10-vio2: fcs4: no
ms10-vio2: fcs6: no
MS: ms11
ms11-vio3: RMC not active
ms11-vio1: fcs0: no
ms11-vio1: fcs1: no
ms11-vio1: fcs2: no
ms11-vio1: fcs3: yes
ms11-vio1: fcs4: no
…
ms19-vio2: fcs2: no
ms19-vio2: fcs3: no
ms19-vio2: fcs0: no
ms19-vio2: fcs1: no
ms19-vio2: fcs4: no
ms19-vio2: fcs5: no
132 FC-ports investigated
17 FC-ports in same fabric

real       2m33.978s
user      0m4.597s
sys       0m8.137s
$

In ca 150 Sekunden wurden 132 FC-Ports untersucht (LPM-Validierungen durchgeführt). Das bedeutet das eine Validierung im Durchschnitt in etwa 1 Sekunde benötigt hat.

Wir haben damit alle FC-Ports gefunden, welche an die Fabric „Fabric1“ angeschlossen sind.

Das lässt sich natürlich für weitere Fabrics analog durchführen.

Noch ein Hinweis, nicht alle Ports oben sind verkabelt!

 

 

Host-Key aus ~/.ssh/known_hosts entfernen

Gelegentlich wird auf einem Host ein Host-Key geändert, entweder manuell oder eventuell automatisch durch einen Update von OpenSSH. Beim Login per ssh auf den betreffenden Host bekommt man dann die folgende Meldung:

$ ssh aix01
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:xYglDF3cuHCCrxtbFUbpofpmhNs9MiO114vAT4qVX2M.
Please contact your system administrator.
Add correct host key in /home/as/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/as/.ssh/known_hosts:2
RSA host key for aix01 has changed and you have requested strict checking.
Host key verification failed.
$

Viele Administratoren verwenden dann vi (oder einen anderen Editor) um den Eintrag mit dem alten Host-Key aus der known_hosts zu entfernen. Eine Hilfe ist dabei die Angabe der Zeilennummer in der Ausgabe oben, /home/as/.ssh/known_hosts:2 bedeutet der Eintrag steht in der Zeile 2 der Datei.

Man kann den veralteten Host-Key aber viel einfacher mit Hilfe des Kommandos ssh-keygen und der Option „-R“ (remove) entfernen:

$ ssh-keygen -R aix01
# Host aix01 found: line 2
/home/as/.ssh/known_hosts updated.
Original contents retained as /home/as/.ssh/known_hosts.old
$ 

Das Kommando erstellt eine Kopie der Datei mit der Endung „.old“ und entfernt den gewünschten Eintrag. Das ist um einiges einfacher als mit dem Editor!

Möchte man wissen ob ein Host-Key für ein System schon in der known_hosts existiert, gibt es dafür die Option „-F“ (find):

$ ssh-keygen -F aix02
# Host aix02 found: line 49 
aix02,192.168.178.49 ssh-rsa AAAAB3NzaC1yc2E...
$

Es wird der Public Host-Key, sowie die Zeile für das System ausgegeben.

Cron-Jobs werden nicht mehr gestartet

Kürzlich wurde auf einem unserer AIX Systeme kein Cron-Job mehr gestartet. Es gab keinen Eintrag im Error Report und auch per Syslog konnte kein Hinweis auf das Problem gefunden werden. Im Log des cron-Daemon fanden sich allerdings jede Menge Meldungen:

# cat /var/adm/cron/log
...
! c queue max run limit reached Sat Feb 23 08:49:00 2019
! rescheduling a cron job Sat Feb 23 08:49:00 2019
...

Unter AIX ist die Anzahl der aktiven Cron-Jobs standardmäßig auf maximal 100 gesetzt. Offensichtlich war diese Anzahl auf unserem System erreicht worden. Neue Einträge werden dann per Default 60 Sekunden später ausgeführt. Beides kann über die Datei /var/adm/cron/queuedefs konfiguriert werden. Der Wert 100 ist allerdings schon recht hoch und ein Erreichen des Wertes deutet auf ein Problem hin.

Die PID des cron-Daemon lässt sich schnell herausfinden:

$ ps -ef|grep cron
    root  6684924        1   0   Sep 26      -  8:03 /usr/sbin/cron
$

Die aktuell aktiven Cron-Jobs laufen als Sohn-Prozesse des cron. Mit der Option „-T“ des ps-Kommandos lassen wir uns diese auflisten:

$ ps -T 6684924
      PID    TTY  TIME CMD
  6684924      -  8:03 cron
  3276876      -  0:00    |\--perl
  9961588      -  0:00    |    \--mount
 12714002      -  0:07    |        \--nfsmnthelp
  3604516      -  0:00    |\--perl
 20185130      -  0:00    |    \--mount
 10158264      -  0:35    |        \--nfsmnthelp
  4587542      -  0:00    |\--perl
...

Es fällt sofort auf, das sich die Zeilen immer wieder wiederholen, d.h. ein Perl-Programm wurde per cron immer wieder gestartet, dieses hat versucht ein Filesystem per NFS zu mounten, was aber nicht funktioniert hat (keine Antwort vom NFS-Server) und das Perl-Skript hängt. Da das Skript immer wieder neu gestartet wurde, gab es dann ab irgendeinem Zeitpunkt 100 aktive Cron-Jobs und von diesem Moment an wurden dann keine weiteren Cron-Jobs mehr gestartet. Wir zählen kurz die aktiven Perl-Prozesse:

$ ps -T 6684924 |grep perl |wc -l
     100
$

Es sind genau 100 Perl-Prozesse, die von cron gestartet wurden. Wir beenden einige der hängenden Perl-Prozesse:

# kill 3276876 3604516  4587542
#

Ein Blick ans Ende der Logdatei von cron zeigt das Jobs beendet wurden, und nach kurzer Zeit taucht dann auch schon der erste neu gestartete Cron-Job auf:

# tail –f /var/adm/cron/log
…
Cron Job with pid: 3276876 Failed
Cron Job with pid: 3604516  Failed
Cron Job with pid: 4587542Failed
mqm       : CMD ( /appdata/mqm/admin/bin/checks/checkXmitMonitoring.sh >>/appdata/mqm/tracks/logs/scheduler/checkXmitMonitoring.fatal 2>&1 ) : PID ( 28442840 ) : Mon Feb 25 10:34:00 2019
…

Wir beenden auch die übrigen hängenden Prozesse und restarten den cron-Daemon sicherheitshalber, indem wir ihn einfach beenden:

# kill 6684924
#

Der cron-Daemon wird Dank eines /etc/inittab-Eintrags automatisch neu gestartet:

# lsitab cron
cron:23456789:respawn:/usr/sbin/cron
#

Nachdem cron wieder arbeitet, sollte das Perl-Skript untersucht werden, welches letztlich zum Hängen von cron geführt hat. Bei regelmäßig per cron gestarteten Skripten empfiehlt sich eine Überprüfung, ob der Job eventuell noch oder schon läuft.

Home-Verzeichnisse automatisch anlegen

Es gib verschiedene Möglichkeiten unter AIX fehlende Home-Verzeichnisse beim Login automatisch anlegen zu lassen. Dies ist insbesondere nützlich, wenn die Benutzer-Accounts über LDAP oder einen anderen Namensdienst verwaltet werden und nicht lokal angelegt werden. Wird ein Benutzer neu im LDAP angelegt, hat er zunächst kein Home-Verzeichnis auf dem AIX LDAP-Client:

$ ssh new_user@aix01
...
Could not chdir to home directory /home/new_user: No such file or directory
$ pwd
/
$ exit
$

Die wohl einfachste Möglichkeit das Home-Verzeichnis beim Login automatisch anzulegen, ist das Attribute mkhomeatlogin in der Datei /etc/security/login.cfg. Der Default für dieses Attribut ist „false“, falls es nicht gesetzt ist:

# lssec -f /etc/security/login.cfg -s usw -a mkhomeatlogin
usw mkhomeatlogin=
# 

Das Attribut lässt sich mit dem Kommando chsec auf den Wert true setzen:

# chsec -f /etc/security/login.cfg -s usw -a mkhomeatlogin=true
# lssec -f /etc/security/login.cfg -s usw -a mkhomeatlogin
usw mkhomeatlogin=true
#

Wir probieren den Login erneut aus:

$ ssh new_user@aix01
...
$ pwd
/home/new_user
$

Es wurde ein neues Home-Verzeichnis für den Benutzer angelegt.

HMC Fehler #25B810

Das Verwalten und Administrieren von Service-Ereignissen (Serviceable Events) wird auf HMCs gerne vergessen. In diesem Beitrag wollen wir an einem konkreten Beispiel, Fehler mit Referenz-Code #25B810, das Umgehen mit solchen Ereignissen zeigen. Zum Einsatz kommt hier natürlich unser LPAR-Tool.

Wir lassen uns zunächst einmal alle offenen Service Ereignisse anzeigen:

$ hmc lssvcevents
TIME                 PROBLEM  PMH   HMC     REFCODE   STATE     STATUS  CALLHOME  FAILING_MTMS      TEXT                                         
02/13/2019 23:02:31  7        -     hmc01   #25B810   approved  Open    false     8231-E2B/06A084P  File System alert event occurred...          
02/16/2019 16:14:28  8        -     hmc01   B3030001  approved  Open    false     8231-E2B/06A084P  ACT04284I A Management Console connect failed
02/11/2019 16:12:43  37       -     hmc02   B3030001  approved  Open    false     8231-E2B/06A084P  ACT04284I A Management Console connect failed
02/11/2019 17:43:19  38       -     hmc02   B3030001  approved  Open    false     8231-E2B/06A084P  ACT04283I A connection to a FSP,BPA...  
$

In diesem Beitrag soll es um das Problem mit der Nummer 7 gehen. Das Problem wurde am 13.02.2019 um 23:02:31 festgestellt, und von der HMC mit dem Namen hmc01 untersucht. Der Fehlercode ist #25B810. Das Problem befindet sich im Zustand „offen“ („open“), ein Call-Home wurde nicht ausgelöst. Als weitere Information entnehmen wir das das Problem auf dem Managed System mit der Seriennummer 06A084P aufgetreten ist, einer Power 710 (8231-E2B). Der Beginn der Fehlermeldung ist in der letzten Spalte zu finden.

Wir lassen uns zunächst den ganzen Datensatz zu dem Problem anzeigen, indem wir die Problem-Nummer und die HMC zusätzlich angeben

$ hmc lssvcevents -p 7 hmc01
analyzing_hmc: hmc01
analyzing_mtms: 7042-CR8/21009CD
approval_state: approved
callhome_intended: false
created_time: 02/14/2019 04:11:31
duplicate_count: 0
eed_transmitted: false
enclosure_mtms: 8231-E2B/06A084P
event_severity: 0
event_time: 02/13/2019 23:02:31
failing_mtms: 8231-E2B/06A084P
files: iqyymrge.log/Consolidated system platform log,
iqyvpd.dat/Configuration information associated with the HMC,
actzuict.dat/Tasks performed,
iqyvpdc.dat/Configuration information associated with the HMC,
problems.xml/XML version of the problems opened on the HMC for the HMC and the server,
refcode.dat/list of reference codes associated with the hmc,
iqyylog.log/HMC firmware log information,
PMap.eed/Partition map, obtained from 'lshsc -w -c machine',
hmc.eed/HMC code level obtained from 'lshmc -V' and connection information obtained from 'lssysconn -r all',
sys.eed/Output of various system configuration commands,
8231-E2B_06A084P.VPD.xml/Configuration information associated with the managed system
first_time: 02/14/2019 04:11:31
last_time: 02/14/2019 04:11:31
problem_num: 7
refcode: #25B810
reporting_mtms: 8231-E2B/06A084P
reporting_name: p710
status: Open
sys_mtms: 8231-E2B/06A084P
sys_name: p710
sys_refcode: #25B810
text: File System alert event occurred on /home/ios/CM/DB. Free space is less than 10%, or there was an error querying the filesystem.

Am Ende der Ausgabe finden wir die ungekürzte Fehlermeldung. Es geht um ein Filesystem, in dem weniger als 10% freier Platz verfügbar ist. Der Pfad „/home/ios/CM/DB“ deutet auf einen Virtual-I/O-Server hin. Die in Frage kommenden Virtual-I/O-Server befinden sich auf dem Managed System mit der Seriennummer 06A084P:

$ ms show 06A084P
NAME  SERIAL_NUM  TYPE_MODEL  HMCS        
p710  06A084P     8231-E2B    hmc01,hmc02
$

Es ist das Managed System mit dem Namen p710. Auf dem Managed System befinden sich die folgenden Virtual-I/O-Server:

$ vios -m p710 show
LPAR     ID  SERIAL    LPAR_ENV   MS    HMCs
aixvio1  1   06A084P1  vioserver  p710  hmc01,hmc02
$

Eine Überprüfung des Error-Reports auf dem Virtual-I/O-Server aixvio1 ergibt den folgenden Eintrag:

LABEL:          VIO_ALERT_EVENT
IDENTIFIER:     0FD4CF1A

Date/Time:       Wed Feb 13 22:02:31 CST 2019
Sequence Number: 98
Machine Id:      00F6A0844C00
Node Id:         aixvio1
Class:           O
Type:            INFO
WPAR:            Global
Resource Name:   /home/ios/CM/DB 

Description
Informational Message

Probable Causes
Asynchronous Event Occurred

Failure Causes
PROCESSOR

        Recommended Actions
        Check Detail Data

Detail Data
Alert Event Message
25b810
A File System alert event occurred on /home/ios/CM/DB. Free space is less than 10%, or there was an error querying the filesystem.

Diagnostic Analysis
Diagnostic Log sequence number: 19
Resource tested:        sysplanar0
Menu Number:            25B810
Description:


 File System alert event occurred on /home/ios/CM/DB. Free space is less than 10%, or there was an error querying the filesystem.

Eine kurze Überprüfung des Filesystems zeigt ,das das Problem schon bereinigt wurde, und es ausreichend Platz gibt:

$ df -g
Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
...
/dev/hd1           0.25      0.16   35%      111     1% /home
...
$ 

Das Problem besteht also nicht mehr. Daher sollte das Service-Event auf der HMC auch geschlossen werden, was wir nun auch tun:

$ hmc chsvcevent -o close -p 7 hmc01
$

Zur Überprüfung listen wir die noch offenen Service-Events auf:

$ hmc lssvcevents 
TIME                 PROBLEM  PMH  HMC     REFCODE   STATE     STATUS  CALLHOME  FAILING_MTMS      TEXT                                         
02/16/2019 16:14:28  8        -    hmc01   B3030001  approved  Open    false     8231-E2B/06A084P  ACT04284I A Management Console connect failed
02/11/2019 16:12:43  37       -    machmc  B3030001  approved  Open    false     8231-E2B/06A084P  ACT04284I A Management Console connect failed
02/11/2019 17:43:19  38       -    machmc  B3030001  approved  Open    false     8231-E2B/06A084P  ACT04283I A connection to a FSP,BPA...   
$    

Das Event mit der Nummer 7 wurde erfolgreich geschlossen.

Service-Events lassen sich mit dem LPAR-Tool also relativ leicht verwalten!

Migration von SDDPCM nach AIX PCM

Auf vielen AIX Systemen wird aktuell noch SDDPCM als Multipathing Lösung eingesetzt. Allerdings wird SDDPCM auf POWER 9 Hardware von IBM nicht mehr unterstützt.

Im folgenden soll daher die Migration von SDDPCM nach AIX PCM gezeigt werden. Auf unserem Beispielsystem haben wir die folgenden Physical Volumes:

$ lspv
hdisk0          00abcdefabcde000                    datavg          active     
hdisk1          00abcdefabcde001                    datavg          active     
hdisk2          none                                None                       
hdisk3          00abcdefabcde003                    altinst_rootvg             
hdisk4          00abcdefabcde004                    rootvg          active     
$

Bei den Physical Volumes handelt es sich um Platten, die über einen SVC zur Verfügung gestellt werden:

$ lsdev -l hdisk0 -F uniquetype
disk/fcp/2145
$

Als Path Control Module (PCM) wird SDDPCM verwendet:

$ lsattr -El hdisk0 -a PCM -F value
PCM/friend/sddpcm
$

Dies sieht man auch, wenn man sich die Liste der Kernel Extensions anschaut:

$ genkex | grep pcm
f1000000c012a000    af000 /usr/lib/drivers/sddpcmke
$

Welcher PCM Treiber für welche Disk Typen verwendet wird, lässt sich leicht mit dem Kommando „manage_disk_drivers“ sehen:

$ manage_disk_drivers -l
Device              Present Driver        Driver Options    
2810XIV             AIX_AAPCM             AIX_AAPCM,AIX_non_MPIO
DS4100              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS4200              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS4300              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS4500              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS4700              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS4800              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS3950              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS5020              AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DCS3700             AIX_APPCM             AIX_APPCM
DCS3860             AIX_APPCM             AIX_APPCM
DS5100/DS5300       AIX_SDDAPPCM          AIX_APPCM,AIX_SDDAPPCM
DS3500              AIX_APPCM             AIX_APPCM
XIVCTRL             MPIO_XIVCTRL          MPIO_XIVCTRL,nonMPIO_XIVCTRL
2107DS8K            NO_OVERRIDE           AIX_AAPCM,AIX_non_MPIO,NO_OVERRIDE
IBMFlash            NO_OVERRIDE           AIX_AAPCM,AIX_non_MPIO,NO_OVERRIDE
IBMSVC              NO_OVERRIDE           AIX_AAPCM,AIX_non_MPIO,NO_OVERRIDE
$

In unserem Falle, SVC Platten, ist die letzte Zeile relevant (IBMSVC). Als aktueller PCM Treiber ist hier NO_OVERRIDE gelistet, mögliche andere Treiber sind AIX_AAPCM (AIX PCM für active/active und ALUA Systeme) und AIX_non_MPIO (Platten ohne Multi-Pathing betreiben). Der Wert NO_OVERRIDE bedeutet, das wenn kein Multipathing-Treiber explizit angegeben wird, nach Möglichkeit ein Multipathing-Treiber verwendet wird (falls vorhanden), ansonsten wird kein Multipathing-Treiber verwendet. Steht mehr als ein Multipathing-Treiber zur Verfügung (bei uns AIX PCM und SDDPCM, dann hat SDDPCM Priorität).

In einem nachfolgenden Blog-Eintrag werden wir die möglichen Werte noch einmal genauer anschauen, sowie die Stelle in AIX, an der die Auswahl festgehalten wird.

Bevor wir jetzt den Treiber für IBMSVC Platten ändern (hierzu ist ein Reboot notwendig), schauen wir uns noch die Attribute unsere Platten an, hier exemplarisch für die hdisk0:

$ lsattr -El hdisk0
PCM             PCM/friend/sddpcm                                   PCM                                     True
...
algorithm       load_balance                                        Algorithm                               True+
...
queue_depth     120                                                 Queue DEPTH                             True+
...
reserve_policy  no_reserve                                          Reserve Policy                          True+
...
$

Durch Ändern des Treibers gehen die Werte einiger gesetzter Attribute verloren, bzw. werden durch neue default Werte des neuen Treibers ersetzt. Dies gilt insbesondere für die queue_depth (hier: 120), die reserve_policy (hier: no_reserve) und die Load-Balancing-Policy (algorithm). Die aktuellen Werte sollte man notieren, um dann nach der Umstellung auf den AIX PCM Treiber diese dann entsprechend anzupassen.

Das Wechseln auf AIX PCM kann mit dem Kommando „manage_disk_drivers“ durchgeführt werden. Hierzu wird dem Kommando der Disk-Typ (hier IBMSVC) mit der Option „-d“ und der gewünschte Treiber (hier AIX_AAPCM für den AIX PCM Treiber) mit der Option „-o“ mitgegeben:

# manage_disk_drivers -d IBMSVC -o AIX_AAPCM
********************** ATTENTION *************************
  For the change to take effect the system must be rebooted
#

Die geänderte Konfiguration lässt sich unmittelbar mit „manage_disk_drivers -l“ auflisten:

$ manage_disk_drivers -l
Device              Present Driver        Driver Options    
...
IBMSVC              AIX_AAPCM             AIX_AAPCM,AIX_non_MPIO,NO_OVERRIDE
$

Für die Durchführung der Änderung muss das System nun rebootet werden:

# shutdown -r now

SHUTDOWN PROGRAM
Thu Feb  7 09:43:38 CET 2019
...

Wir führen die 3 Kommandos vom Anfang noch einmal aus (lspv, lsdev und lsattr):

$ lspv
hdisk0          00abcdefabcde000                    datavg          active     
hdisk1          00abcdefabcde001                    datavg          active     
hdisk2          none                                None                       
hdisk3          00abcdefabcde003                    altinst_rootvg             
hdisk4          00abcdefabcde004                    rootvg          active     
$

Die Physical Volumes sind unverändert.

$ lsdev -l hdisk0 -F uniquetype
disk/fcp/mpioosdisk
$

Der Typ der Platten hat sich geändert von disk/fcp/2145 auf disk/fcp/mpioosdisk. Dies deutet schon an, das sich der Multipathing-Treiber geändert hat.

$ lsattr -El hdisk0 -a PCM -F value
PCM/friend/fcpother
$

Das Path Control Module (PCM) hat sich ebenfalls geändert. Der Typ ist nicht mehr sddpcm sondern fcpother. Das schaut erst einmal nicht direkt nach AIX PCM aus. Ein Blick auf den zugehörigen Treiber zeigt aber sofort das hier AIX PCM in Verwendung ist:

$ lsdev -P -c PCM -s friend -t fcpother -F DvDr
aixdiskpcmke
$

Die zugehörige Kernel Extension aixdiskpcmke ist auch aktuell geladen und in Verwendung:

$ genkex | grep pcm
         73e2000    57000 /usr/lib/drivers/aixdiskpcmke
$

Schauen wir uns nun, wieder exemplarisch für hdisk0, die Attribute an. Wir erwarten ja hier geänderte Werte für einige Attribute:

$ lsattr -El hdisk0
PCM             PCM/friend/fcpother                                 Path Control Module              False
...
algorithm       fail_over                                           Algorithm                        True+
...
queue_depth     20                                                  Queue DEPTH                      True+
...
reserve_policy  single_path                                         Reserve Policy                   True+
...
$

Der Wert 120 für die queue_depth ist verloren gegangen und wurde durch den default Wert 20 ersetzt. Die reserve_policy hat sich auf single_path geändert und der Load-Balancing Algorithmus ist nun fail_over, d.h. es wird immer nur ein Pfad verwendet.

Wir ändern die Einstellungen auf eine Konfiguration die der Ausgangssituation entspricht:

# chdev -P -l hdisk0 -a algorithm=shortest_queue -a queue_depth=120 -a reserve_policy=no_reserve
hdisk0 changed
#

Da das Physical Volume in Benutzung ist, kann die Einstellung nur in der ODM geändert werden und es ist ein weiterer Reboot notwendig.

Nachdem alle Platten über die ODM umkonfiguriert worden sind, muss das System ein zweites Mal rebootet werden:

# shutdown -r now

SHUTDOWN PROGRAM
Thu Feb  6 20:07:12 CET 2019
...

Nach dem Reboot kann SDDPCM dann deinstalliert werden:

# installp -u devices.fcp.disk.ibm.mpio.rte devices.sddpcm.72.rte
+-----------------------------------------------------------------------------+
                    Pre-deinstall Verification...
+-----------------------------------------------------------------------------+
Verifying selections...done
Verifying requisites...done
Results...

SUCCESSES
...
0503-292 This update will not fully take effect until after a
        system reboot.

    * * *  A T T E N T I O N  * * *
    System boot image has been updated. You should reboot the
    system as soon as possible to properly integrate the changes
    and to avoid disruption of current functionality.

installp:  bosboot process completed.
+-----------------------------------------------------------------------------+
                                Summaries:
+-----------------------------------------------------------------------------+

Installation Summary
--------------------
Name                        Level           Part        Event       Result
-------------------------------------------------------------------------------
devices.sddpcm.72.rte       2.7.1.1         ROOT        DEINSTALL   SUCCESS   
devices.sddpcm.72.rte       2.7.1.1         USR         DEINSTALL   SUCCESS   
devices.fcp.disk.ibm.mpio.r 1.0.0.25        USR         DEINSTALL   SUCCESS   
#

Das SDDPCM Fileset, sowie das zugehörige Host-Attachment Fileset, konnten erfolgreich deinstalliert werden.

Da der SDDPCM-Treiber nicht geladen war, und sich damit auch keine Änderungen am Kernel ergeben haben, sollte eigentlich ein weiterer Reboot nicht notwendig sein. Da allerdings ausdrücklich auf einen schnellen Reboot hingewiesen wird, und es auch eine gute Idee ist mit der finalen Konfiguration einen Reboot-Test zu machen, rebooten wir das System ein drittes und letztes Mal:

# shutdown -r now

SHUTDOWN PROGRAM
Thu Feb  6 20:17:21 CET 2019
...

Nach dem Reboot kontrollieren wir noch einmal die Platten-Attribute:

$ lsattr -El hdisk0
PCM             PCM/friend/fcpother                                 Path Control Module              False
...
algorithm       shortest_queue                                      Algorithm                        True+
...
queue_depth     120                                                 Queue DEPTH                      True+
...
reserve_policy  no_reserve                                          Reserve Policy                   True+
...
$

Das System verwendet nun den AIX PCM Treiber für Multipathing:

$ manage_disk_drivers -l
Device              Present Driver        Driver Options    
...
IBMSVC              AIX_AAPCM             AIX_AAPCM,AIX_non_MPIO,NO_OVERRIDE
$

Die Migration von SDDPCM zu AIX PCM ist also in der Durchführung ziemlich einfach.