secldapclntd: LDAP failed to bind to server

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!

Das Attribut „label“ für FC-Adapter

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

Korrigieren von „falschen“ LVM Spiegelungen

Mirrored logical volume from practice

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)

AIX LVM: Mechanik von migratepv (Part II)

AIX LVM: Mechanik von migratepv (Part III)

HSCF0180E Operation failed for

Beim Versuch die System Firmware eines Managed Systems über die HMC Command Line zu aktualisieren, sind wir auf die folgende Fehlermeldung gestoßen:

hmc01:~> updlic -o a -t all -l latest -m ms26 -r sftp -h X.X.X.X -u XXXXXXXX --passwd XXXXXXXX -d /firmware/system/01VL940_071_027
HSCF0180E Operation failed for ms26 (9009-22A*XXXXXXX).
Could not unpack the firmware update package.
Check the health and available disk space of the file system.
hmc01:~>

Die angezeigte Fehlermeldung legte nahe den verfügbaren Platz in den HMC Dateisystemen zu überprüfen:

hmc01:~> lshmcfs
filesystem=/var,filesystem_size=7935,filesystem_avail=4955,temp_files_start_time=11/22/2018 12:59:00,temp_files_size=2011
filesystem=/dump,filesystem_size=60347,filesystem_avail=55935,temp_files_start_time=02/15/2021 10:21:00,temp_files_size=0
filesystem=/extra,filesystem_size=20030,filesystem_avail=15939,temp_files_start_time=none,temp_files_size=0
filesystem=/,filesystem_size=15615,filesystem_avail=4369,temp_files_start_time=02/15/2021 06:05:00,temp_files_size=4
hmc01:~>

Eigentlich sollte der verfügbare Platz ausreichend sein, aber um ganz sicher zu gehen, haben wir bei den temporären Dateien etwas aufgeräumt:

hmc01:~> chhmcfs -o f -d 5
hmc01:~>

Das Kommando updlic zeigte sich aber dadurch unbeeindruckt und lieferte die gleiche Fehlermeldung.

Auch das Entfernen einiger alter Firmware Versionen aus der lokalen Disk Repository der HMC brachte keinen Erfolg:

hmc01:~> updlic -o p --ecnumber 01AL740
hmc01:~> updlic -o p --ecnumber 01AL770
hmc01:~> updlic -o p --ecnumber 01AM740
hmc01:~>

Die Fehlermeldung war nach wie vor die gleiche. Offensichtlich hatte das Problem, entgegen dem Hinweis aus der Fehlermeldung, nichts mit dem verfügbaren Platz auf der HMC zu tun!

Daraufhin haben wir uns die heruntergeladene Firmware noch einmal genauer angeschaut. Die Firmware hatten wir als ISO-Datei H75557812_01VL940_071_027.iso von der IBM Website heruntergeladen und dann mit dem Kommando loopmount auf unserem NIM-Server gemountet:

aixnim:/root> loopmount -i /tmp/H75557812_01VL940_071_027.iso -o "-o ro -V cdrfs" -m /mnt
aixnim:/root> ls -l /mnt
total 528296
-rw-r--r--    1 102010979 213            1860 Feb 04 09:08 01VL940071_special_instructs.xml.special.note.xml
-rw-r-----    1 102010979 210            7290 Feb 04 09:08 01VL940_071_027.dd.xml
-rw-r--r--    1 102010979 213           95687 Feb 04 09:07 01VL940_071_027.html
-rw-r-----    1 102010979 210            2971 Feb 04 09:08 01VL940_071_027.pd.sdd
-rw-r-----    1 102010979 210           67338 Feb 04 09:08 01VL940_071_027.readme.txt
-rw-r-----    1 102010979 210       134969022 Feb 04 09:08 01VL940_071_027.rpm
-rw-r-----    1 102010979 210       135328848 Feb 04 09:08 01VL940_071_027.tar.gz
-rw-r-----    1 102010979 210            9442 Feb 04 09:08 01VL940_071_027.xml
aixnim:/root>

Was uns beim Kopieren der Dateien nicht aufgefallen war, waren die fehlenden Lese-Berechtigungen bei other für die meisten Dateien.

Nachdem wir für alle Dateien Leseberechtigungen vergeben hatten, war der nächste Update-Versuch erfolgreich:

hmc01:~> updlic -o a -t all -l latest -m ms26 -r sftp -h X.X.X.X -u XXXXXX --passwd XXXXXXXX -d /firmware/system/01VL940_071_027 
HSCF0179W Operation was partially successful for ms26 (9009-22A*XXXXXXX).
The following deferred fixes are present in the fix pack.  Deferred fixes will be activated after the next IPL of the system.
An immediate IPL is not required, unless you want to activate one of the fixes below now.
..
hmc01:~>

LPAR-Tool 1.6.0.0 ist verfügbar

Ab sofort ist unser LPAR-Tool in der Version 1.6.0.0 in unserem Download-Bereich verfügbar!

Neue Feature sind:

  • Online Überwachung von SEA Client Statistiken (vios help seastat)
  • Online Überwachung von virtuellen FC Client Adaptern (vios help fcstat)
  • Anzeige historischer Prozessor und Memory Daten (lpar help lsmem, lpar help lsproc)

Im Artikel Überwachung des SEA Netzwerk-Verkehrs werden die Möglichkeiten SEA Client Statistiken abzurufen gezeigt.

Fehler: Every mirror pool must contain a copy of the logical volume

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.

Fehler: Mirror pools must be defined

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.

Neuer Artikel Einführung in Mirror Pools

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.

Die Auswirkungen von FC-Ports ohne Link

FC-Ports die nicht verwendet werden und keinen Link haben, sollten deaktiviert werden, da diese die Laufzeit einer Reihe von Kommandos und Operationen (z.B. LPM) deutlich verlängern.

(Hinweis: in einigen Beispielen wird unser LPAR-Tool verwendet, es werden aber auch immer die Kommandos auf der HMC, oder dem Virtual-I/O-Server gezeigt!)

Auf einem unserer Virtual-I/O-Server (ms26-vio1) sind 2 4-Port FC Adapter in Verwendung:

$ lpar lsslot ms26-vio1
DRC_NAME                  DRC_INDEX  IOPOOL  DESCRIPTION
U78D3.001.XXXXXXX-P1-C49  21040015   none    PCIe3 x8 SAS RAID Internal Adapter 6Gb
U78D3.001.XXXXXXX-P1-C7   2103001C   none    PCIe3 4-Port 16Gb FC Adapter
U78D3.001.XXXXXXX-P1-C2   21010021   none    PCIe3 4-Port 16Gb FC Adapter
$
(HMC: lshwres -r io --rsubtype slot -m ms26 --filter lpar_names=ms26-vio1)

Es sind allerdings nur 2 Ports verkabelt:

$ vios lsnports ms26-vio1
NAME  PHYSLOC                     FABRIC  TPORTS  APORTS  SWWPNS  AWWPNS
fcs0  U78D3.001.XXXXXXX-P1-C2-T1  1       64      64      3072    3072
fcs4  U78D3.001.XXXXXXX-P1-C7-T1  1       64      64      3072    3072
$
(VIOS: lsnports)

Beim Arbeiten mit dem Virtual-I/O-Server fällt auf, das einige der Kommandos eine unerwartet lange Laufzeit haben und teilweise für längere Zeit hängen. Im Folgenden sind einige Kommandos angegeben, zusammen mit der benötigten Laufzeit:

(0)padmin@ms26-vio1:/home/padmin> time netstat –cdlistats
…
Error opening device: /dev/fscsi1
errno: 00000045

Error opening device: /dev/fscsi2
errno: 00000045

Error opening device: /dev/fscsi3
errno: 00000045

Error opening device: /dev/fscsi5
errno: 00000045

Error opening device: /dev/fscsi6
errno: 00000045

Error opening device: /dev/fscsi7
errno: 00000045

real    1m13.56s
user    0m0.03s
sys     0m0.10s
(0)padmin@ms26-vio1:/home/padmin>
(0)padmin@ms26-vio1:/home/padmin> time lsnports
name             physloc                        fabric tports aports swwpns  awwpns
fcs0             U78D3.001.XXXXXXX-P1-C2-T1          1     64     64   3072    3072
fcs4             U78D3.001.XXXXXXX-P1-C7-T1          1     64     64   3072    3072

real    0m11.61s
user    0m0.01s
sys     0m0.00s
(0)padmin@ms26-vio1:/home/padmin>
(0)padmin@ms26-vio1:/home/padmin> time fcstat fcs1

Error opening device: /dev/fscsi1
errno: 00000045

real    0m11.31s
user    0m0.01s
sys     0m0.01s
(4)padmin@ms26-vio1:/home/padmin>

Auch LPM-Operationen dauern deutlich länger, da bei der Suche nach passenden FC-Ports für die nötigen NPIV-Mappings alle FC-Ports untersucht werden. Dies kann zu Verzögerungen im Minuten-Bereich führen, bevor die Migration dann letztlich gestartet wird.

Um diese unnötig langen Laufzeiten zu vermeiden, sollten nicht verkabelte FC-Ports nicht aktiviert werden. Das fscsi-Device besitzt das Attribut autoconfig mit den möglichen Werten defined und available. Per Default wird der Wert available verwendet, was dazu führt das der Kernel das Device konfiguriert und aktiviert, auch wenn es keinen Link besitzt, was zu den oben gezeigten Wartezeiten führt. Setzt man das Attribut autoconfig auf defined, dann wird das fscsi-Device nicht aktiviert, es bleibt dann im Zustand defined.

Im folgenden Beispiel wird gezeigt, wie man das Device fscsi1 umkonfiguriert:

$ vios chdev ms26-vio1 fscsi1 autoconfig=defined
$
(VIOS: chdev -dev fscsi1 -attr autoconfig=defined)
$
$ vios rmdev ms26-vio1 fscsi1
$
(VIOS: rmdev -dev fscsi1 –ucfg)
$
$ vios lsdev ms26-vio1 fscsi1
NAME    STATUS   PHYSLOC                     PARENT  DESCRIPTION
fscsi1  Defined  U78D3.001.XXXXXXX-P1-C2-T2  fcs1    FC SCSI I/O Controller Protocol Device
$
(VIOS: lsdev -dev fscsi1)
$
$  vios lsattr ms26-vio1 fscsi1
ATTRIBUTE     VALUE      DESCRIPTION                            USER_SETTABLE
attach        none       How this adapter is CONNECTED          False
autoconfig    defined    Configuration State                    True
dyntrk        yes        Dynamic Tracking of FC Devices         True+
fc_err_recov  fast_fail  FC Fabric Event Error RECOVERY Policy  True+
scsi_id       Adapter    SCSI ID                                False
sw_fc_class   3          FC Class for Fabric                    True
$
(VIOS: lsdev -dev fscsi1 –attr)
$

Durch das Attribut autoconfig=defined bleibt das fscsi-Device auch bei einem Lauf des cfgmgr auf defined!

Wiederholt man die Laufzeit-Messung der Kommandos oben, sieht man das die Laufzeit der Kommandos sich schon meßbar verbessert hat:

(0)padmin@ms26-vio1:/home/padmin> time netstat –cdlistats
…
Error opening device: /dev/fscsi1
errno: 00000005

Error opening device: /dev/fscsi2
errno: 00000045

Error opening device: /dev/fscsi3
errno: 00000045

Error opening device: /dev/fscsi5
errno: 00000045

Error opening device: /dev/fscsi6
errno: 00000045

Error opening device: /dev/fscsi7
errno: 00000045

real    1m1.02s
user    0m0.04s
sys     0m0.10s
(0)padmin@ms26-vio1:/home/padmin>
(0)padmin@ms26-vio1:/home/padmin> time lsnports
name             physloc                        fabric tports aports swwpns  awwpns
fcs0             U78D3.001.XXXXXXX-P1-C2-T1          1     64     64   3072    3072
fcs4             U78D3.001.XXXXXXX-P1-C7-T1          1     64     64   3072    3072

real    0m9.70s
user    0m0.00s
sys     0m0.01s
(0)padmin@ms26-vio1:/home/padmin>
(0)padmin@ms26-vio1:/home/padmin> time fcstat fcs1

Error opening device: /dev/fscsi1
errno: 00000005

real    0m0.00s
user    0m0.02s
sys     0m0.00s
(4)padmin@ms26-vio1:/home/padmin>

Die Laufzeit des netstat-Kommandos hat sich um 12 Sekunden verkürzt, das Komnando lsnports war ca 2 Sekunden schneller.

Wir setzen das autoconfig Attribut jetzt auch bei allen anderen unbenutzten FC-Ports auf defined:

$ for fscsi in fscsi2 fscsi3 fscsi5 fscsi6 fscsi7
> do
> vios chdev ms26-vio1 $fscsi autoconfig=defined
> vios rmdev ms26-vio1 $fscsi
> done
$

Jetzt wiederholen wir die Laufzeit-Messung der Kommandos erneut:

(0)padmin@ms26-vio1:/home/padmin> time netstat –cdlistats
…
Error opening device: /dev/fscsi1
errno: 00000005

Error opening device: /dev/fscsi2
errno: 00000005

Error opening device: /dev/fscsi3
errno: 00000005

Error opening device: /dev/fscsi5
errno: 00000005

Error opening device: /dev/fscsi6
errno: 00000005

Error opening device: /dev/fscsi7
errno: 00000005

real    0m0.81s
user    0m0.03s
sys     0m0.10s
(0)padmin@ms26-vio1:/home/padmin>
(0)padmin@ms26-vio1:/home/padmin> time lsnports         
name             physloc                        fabric tports aports swwpns  awwpns
fcs0             U78D3.001.XXXXXXX-P1-C2-T1          1     64     64   3072    3072
fcs4             U78D3.001.XXXXXXX-P1-C7-T1          1     64     64   3072    3072

real    0m0.00s
user    0m0.01s
sys     0m0.01s
(0)padmin@ms26-vio1:/home/padmin> time fcstat fcs1       

Error opening device: /dev/fscsi1
errno: 00000005

real    0m0.04s
user    0m0.00s
sys     0m0.00s
(4)padmin@ms26-vio1:/home/padmin>

Das Kommando netstat benötigt nun weniger als 1 Sekunde, das Kommando lsnports nur noch 0.1 Sekunden.

Es lohnt sich also das autoconfig Attribut für nicht-benutzte FC-Ports auf defined zu setzen!

 

Nicht vergessen AIX-rpm zu aktualisieren

Kürzlich, bei der Installation von Python3 aus der AIX-Toolbox mittels YUM, sind wir auf folgende Fehlersituation gestoßen:

# yum install python3
...
--> Finished Dependency Resolution
Error: Package: python3-3.7.1-1.ppc (AIX_Toolbox)
           Requires: libssl.a(libssl.so.1.0.2)
Error: Package: python3-3.7.1-1.ppc (AIX_Toolbox)
           Requires: libcrypto.a(libcrypto.so.1.0.2)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
#

Python3 benötigt die Version 1.0.2 von libssl.so und libcrypto.so, die beiden Libraries können aber nicht gefunden werden. Diese beiden Bibliotheken können entweder über das RPM-Paket openssl, in der passenden Version, bereitgestellt werden oder über AIX. Wenn die AIX-Toolbox verwendet wird, wird typischerweise das Paket openssl nicht installiert, sondern es werden die OpenSSL-Bibliotheken von AIX genutzt. Daher ist in unserem Fall das OpenSSLRPM-Paket nicht installiert. Die Bibliotheken werden dann über BFF Pakete des AIX Betriebssystems zur Verfügung gestellt.

Die Information, welche Libraries von AIX zur Verfügung gestellt werden, wird über das virtuelle RPM-Paket AIX-rpm bereitgestellt:

# rpm -q --provides AIX-rpm | egrep "lib(ssl|crypto)"
libcrypto.a(libcrypto.so)
libcrypto.a(libcrypto.so.0.9.8)
libcrypto.a(libcrypto.so.1.0.0)
libcrypto.a(libcrypto64.so)
libcrypto.a(libcrypto64.so.0.9.8)
libcrypto.a(libcrypto64.so.1.0.0)
libcrypto.so.0.9.7
libcrypto_compat.a(libcrypto.so)
libcrypto_compat.a(libcrypto.so.0.9.8)
libcrypto_compat.a(libcrypto64.so)
libcrypto_compat.a(libcrypto64.so.0.9.8)
libssl.a(libssl.so)
libssl.a(libssl.so.0.9.8)
libssl.a(libssl.so.1.0.0)
libssl.a(libssl64.so)
libssl.a(libssl64.so.0.9.8)
libssl.a(libssl64.so.1.0.0)
libssl3.a(libssl3.so)
libssl3.so
libssl_compat.a(libssl.so)
libssl_compat.a(libssl.so.0.9.8)
libssl_compat.a(libssl64.so)
libssl_compat.a(libssl64.so.0.9.8)
#

Die Ausgabe zeigt, das dem Paket AIX-rpm die Versionen 0.9.8 und 1.0.0 der beiden benötigten Bibliotheken bekannt sind, die benötigte Version 1.0.2 ist aber anscheinend nicht verfügbar. Wir schauen kurz in das zugehörige Archiv /usr/lib/libssl.a (bzw. /usr/lib/libcrypto.a) herein:

# ar -X any t /usr/lib/libssl.a
libssl.so
libssl.so.0.9.8
libssl.so.1.0.0
libssl.so.1.0.2
libssl.so
libssl.so.0.9.8
libssl.so.1.0.0
libssl.so.1.0.2
libssl64.so
libssl64.so.0.9.8
libssl64.so.1.0.0
#

Das Archiv stellt offensichtlich auch die Version 1.0.2 zur Verfügung. Diese Information wird aber über das RPM-Paket AIX-rpm nicht geliefert. Das liegt daran, das offensichtlich eine neuere Version von openssl.base installiert wurde, das AIX-rpm Paket aber nicht aktualisiert wurde. Das RPM-Paket hat aktuell die folgende Version:

# rpm -q AIX-rpm
AIX-rpm-7.1.5.15-6.ppc
#

Wir aktualisieren das Paket jetzt mit dem Kommando updtvpkg (update virtual package):

# updtvpkg
Please wait...
# 
# rpm -q AIX-rpm
AIX-rpm-7.1.5.30-7.ppc
#

Die Versionsnummer hat sich jetzt von 7.1.5.15-6 auf 7.1.5.30-7 geändert! Wir lassen uns erneut anzeigen, welche Libraries von AIX über AIX-rpm bereitgestellt werden:

# rpm -q --provides AIX-rpm | egrep "lib(ssl|crypto)"
libcrypto.a(libcrypto.so)
libcrypto.a(libcrypto.so.0.9.8)
libcrypto.a(libcrypto.so.1.0.0)
libcrypto.a(libcrypto.so.1.0.2)
libcrypto.a(libcrypto64.so)
libcrypto.a(libcrypto64.so.0.9.8)
libcrypto.a(libcrypto64.so.1.0.0)
libcrypto.so
libcrypto.so.0.9.7
libcrypto.so.1.0.0
libcrypto_compat.a(libcrypto.so)
libcrypto_compat.a(libcrypto.so.0.9.8)
libcrypto_compat.a(libcrypto64.so)
libcrypto_compat.a(libcrypto64.so.0.9.8)
libssl.a(libssl.so)
libssl.a(libssl.so.0.9.8)
libssl.a(libssl.so.1.0.0)
libssl.a(libssl.so.1.0.2)
libssl.a(libssl64.so)
libssl.a(libssl64.so.0.9.8)
libssl.a(libssl64.so.1.0.0)
libssl.so
libssl.so.1.0.0
libssl3.a(libssl3.so)
libssl3.so
libssl_compat.a(libssl.so)
libssl_compat.a(libssl.so.0.9.8)
libssl_compat.a(libssl64.so)
libssl_compat.a(libssl64.so.0.9.8)
#

Nach der Aktualisierung des virtuellen Pakets AIX-rpm, steht jetzt auch in der RPM-Datenbank das libssl.so und libcrypto.so auch in der Version 1.0.2 verfügbar sind.

Die Installation von Python3 verläuft jetzt erfolgreich:

# yum install python3
...
Is this ok [y/N]: y
...
Installed:
  python3.ppc 0:3.7.1-1                                                                                       

Dependency Installed:
  bzip2.ppc 0:1.0.6-3  expat.ppc 0:2.2.4-1  info.ppc 0:6.4-1  libffi.ppc 0:3.2.1-3  libstdc++.ppc 0:6.3.0-2
  ncurses.ppc 0:6.1-2

Dependency Updated:
  readline.ppc 0:7.0-5                                                                                        

Complete!
#

Daher bei Updates von BFF Paketen die Aktualisierung von AIX-rpm nicht vergessen!