Damit bei einem Update (TL-, SP– oder PTF-Update) ein installierter Ifix automatisch entfernt werden kann, müssen die folgenden beiden Voraussetzungen gegeben sein:

1. 1. Der installierte Ifix muss die Eigenschaft besitzen automatisch entfernt werden zu können.
   2. Der zu installierende Update muss den offiziellen Fix für den APAR des installierten Ifixes enthalten.
   3. Das Fileset, welches den offiziellen Fix für den APAR enthält, muss ein Update Fileset sein! (Es können auch mehrere Filesets sein.)

Bei den drei Beispiel-Ifixes hatten wir festgestellt das der OpenSSH-Ifix (81112ma) nicht automatisch entfernbar ist, aber die beiden anderen Ifixes (IJ50424s7a und IJ52366s7a) automatisch entfernbar sind. Dazu müssen die Updates die offiziellen Fixes für die folgenden beiden APARs enthalten: IJ50424 und IJ52366.

Das Beispiel-System war auf dem Stand 7200-05-07-2346 und soll auf 7200-05-08-2420 gebracht werden. Die LPP-Source mit dieser AIX Version haben wir unter /mnt/aix720508lpp gemountet:

# ls -l /mnt/aix720508lpp
total 0
drwxr-xr-x    3 root     system          256 Jun 10 2024  RPMS
drwxr-xr-x    3 root     system          256 Jun 19 2024  emgr
drwxr-xr-x    3 root     system          256 Jun 10 2024  installp
drwxr-xr-x    3 root     system          256 Jun 18 2024  ismp
drwxr-xr-x    3 root     system          256 Jun 10 2024  usr
#

Bezüglich dem automatischen Entfernen der Beispiel-Ifixes stellt sich nun die Frage ob diese bei einem Update mit der genannten AIX-Version auch automatisch entfernt werden. Für den OpenSSH-Ifix ist schon klar, das dieser auf jeden Fall manuell entfernt werden muss, falls der Update eine neuere OpenSSH-Version enthält. Für die  beiden anderen Ifixes können wir mit Hilfe des Kommandos „installp -A“ überprüfen, ob die unter /mnt/aix720508lpp gemountete LPP-Source die notwendigen APARs (IJ50424 und IJ52366) enthält. Hierzu benötigt man die Information in welchem Fileset sich der offizielle Fix befindet. Dieses Fileset (es können auch mehrere Filesets sein) ist durch den installierten Ifix gesperrt. Die durch die installierten Ifixes gesperrten Filesets können mit „emgr -P“ (package view) angezeigt werden:

# emgr -P

PACKAGE                                                  INSTALLER   LABEL
======================================================== =========== ==========
openssh.base.client                                      installp    81112ma
openssh.base.server                                      installp    81112ma
bos.net.tcp.sendmail                                     installp    IJ50424s7a
bos.net.tcp.client_core                                  installp    IJ52366s7a
#

Überprüfen wir das zunächst für den installierten Ifix IJ50424s7a, das zugehörige Fileset im Update ist bos.net.tcp.sendmail. Das Kommando installp bietet über die Option „-A“ die Möglichkeit, die in einem Fileset enthaltenen APARs aufzulisten. Wir machen dies für das genannte Fileset und suchen gezielt nach dem APAR IJ50424:

# installp -Ad /mnt/aix720508lpp bos.net.tcp.sendmail 2>/dev/null | grep -p IJ50424
fix:
        name = IJ50424
        abstract = A potential security issue exists
        type = f
        filesets = "bos.net.tcp.sendmail:7.2.5.201\n\
"
        symptom = " This APAR addresses a potential security issue.  Any relevant\n\
information will be released via My Notifications.\n\
https://www.ibm.com/support/mynotifications\n\
"
#

Der APAR ist im Update enthalten und zwar in der Version 7.2.5.201 des Filesets bos.net.tcp.sendmail. Damit wird der installierte Ifix IJ50424s7a beim Update automatisch entfernt.

Wir wiederholen die Überprüfung für den dritten installierten Ifix (IJ52366s7a) und dem zugehörigen Fileset bos.net.tcp.client_core:

# installp -Ad /mnt/aix720508lpp bos.net.tcp.client_core 2>/dev/null | grep -p IJ52366
# 

Der offizielle Fix für den APAR IJ52366 ist in dem Update nicht enthalten. Daher wird der installierte Ifix IJ52366s7a bei einem Update auch nicht automatisch entfernt.

Ob der installierte Ifix IJ52366s7a vor dem Update manuell entfernt werden muss, hängt davon ab ob das durch diesen Ifix gesperrte Fileset bos.net.tcp.client_core durch den Update aktualisiert wird, oder nicht. Wir überprüfen kurz die aktuell installierte Version dieses Filesets:

# lslpp -l bos.net.tcp.client_core
  Fileset                      Level  State      Description        
  ----------------------------------------------------------------------------
Path: /usr/lib/objrepos
  bos.net.tcp.client_core  7.2.5.204  COMMITTED  TCP/IP Client Core Support
                                      EFIXLOCKED

Path: /etc/objrepos
  bos.net.tcp.client_core  7.2.5.204  COMMITTED  TCP/IP Client Core Support
                                      EFIXLOCKED
#

Die installierte Version ist 7.2.5.204. Wir überprüfen nun noch welche Version dieses Filesets im Update zur Verfügung steht:

# installp -Ld /mnt/aix720508lpp | grep bos.net.tcp.client_core
bos.net:bos.net.tcp.client_core:7.2.0.0::I:T:::::b:TCP/IP Client Core Support ::::0:1543:
…
bos.net.tcp.client_core:bos.net.tcp.client_core:7.2.5.205::I:T:::::b:TCP/IP Client Core Support ::::0:2419:
#

Im Update ist die höhere Version 7.2.5.205 enthalten. Damit ist klar, das vor einem Update der installierte Ifix IJ52366s7a manuell entfernt werden muss.

Wir fassen das Ergebnis der Untersuchungen noch einmal zusammen:

• • Der installierte Ifix 81112ma muss manuell entfernt werden, da es keine Referenz auf einen APAR gibt. (Damit lässt sich nicht überprüfen ob ein Update den offiziellen Fix enthält oder nicht.)
  • Der installierte Ifix IJ50424s7a wird beim Update automatisch entfernt, da der referenzierte APAR IJ50424 im Update enthalten ist.
  • Der installierte Ifix IJ52366s7a wird beim Update nicht automatisch entfernt, da der referenzierte APAR IJ52366 im Update nicht enhalten ist. Der Ifix muss vor dem Update manuell deinstalliert werden, da der Update eine neuere Version von bos.net.tcp.client_core enthält.