Hi Matthias,

short answer: it is well known behavior, not a mistake on your side, and the good news is that your SUMA command is actually doing its job correctly. The catch is that what you are looking for lives in a different distribution channel by design.

SUMA's world is made of Technology Levels, Service Packs and "Latest", which means the latest SP level fileset updates for the TL you filter on. That is what the RqType parameter speaks, as the current AIX 7.3 documentation describes:
https://www.ibm.com/docs/en/aix/7.3.0?topic=suma-service-update-management-assistant
So with 7300-04-01 already in your lpp_source and no newer SP published for TL4 yet, RqType=Latest with FilterML=7300-04 has literally nothing newer to fetch in that channel. The command is fine, the channel is empty.

The python fix you mention is a different animal: security content between service packs is shipped as INTERIM fixes, the signed fixNN tarballs published with the AIX security bulletins under aix.software.ibm.com/aix/efixes/security/, installed with emgr, and only later rolled into the next SP as regular fileset updates. Here is a recent python bulletin as an example of the pattern, with the advisory, the ifix packages and the verification steps:
https://www.ibm.com/support/pages/security-bulletin-aix-affected-denial-service-cve-2024-50602-due-python
SUMA never touches that channel. No RqType reaches it. So the fileset level fix for python will show up in SUMA only when the next SP for your TL ships with it inside.

Which brings me to your actual evaluation question, because the complete AIX patching architecture is a combo, not a single tool:

1.⁠ ⁠SUMA (standalone or through NIM) for the TL/SP cadence into your lpp_source. You have this working already.

2.⁠ ⁠FLRTVC for the between-SP security gap: it compares each LPAR's installed filesets and ifixes against the FLRT vulnerability data and tells you exactly which fixNN packages are missing, with their URLs. It exists as the classic flrtvc script and as the ibm.power_aix.flrtvc Ansible module if you are automating. One current heads-up if you automate the download side: aix.software.ibm.com recently stopped answering plain http, so any tooling still following http URLs from the FLRT data breaks with connection refused. Force https.

3.⁠ ⁠emgr to apply, NIM to distribute, and the discipline that ifixes are temporary by nature: they get superseded at the next SP, which SUMA then brings you, closing the loop.

4.⁠ ⁠PowerSC TNC Patch Management is the managed umbrella over all of this: it is built around FLRT verification of the endpoints and maintains its own fix repository on the server side (pmconf init builds it, setup here: https://www.ibm.com/docs/en/powersc-standard/2.2.0?topic=tnc-setting-up-components). If you are evaluating PowerSC anyway, that component is the one designed to close exactly the gap you found, so I would test precisely this scenario against it: whether your PowerSC level pulls the security ifixes for your TL into its repository. Fair warning from the community trenches: some corners of the TNCPM documentation are thinner than they should be, so budget some hands-on time.

If you share which exact fix or CVE you are chasing, whether NIM is in the picture, and which PowerSC edition and level you are evaluating, happy to get more concrete on the setup.

Cheers
Roberto

Hi Roberto,

I'm thank thankful for your detailed explanation, espicially looking at the role of suma and PowerSC. Indeed we have PowerSC, NIM and Suma in place and actual evaluate which setup might help us in automated AIX patching. 

Best regards

Matthias

Hi Matthias,

short answer: it is well known behavior, not a mistake on your side, and the good news is that your SUMA command is actually doing its job correctly. The catch is that what you are looking for lives in a different distribution channel by design.

SUMA's world is made of Technology Levels, Service Packs and "Latest", which means the latest SP level fileset updates for the TL you filter on. That is what the RqType parameter speaks, as the current AIX 7.3 documentation describes:
https://www.ibm.com/docs/en/aix/7.3.0?topic=suma-service-update-management-assistant
So with 7300-04-01 already in your lpp_source and no newer SP published for TL4 yet, RqType=Latest with FilterML=7300-04 has literally nothing newer to fetch in that channel. The command is fine, the channel is empty.

The python fix you mention is a different animal: security content between service packs is shipped as INTERIM fixes, the signed fixNN tarballs published with the AIX security bulletins under aix.software.ibm.com/aix/efixes/security/, installed with emgr, and only later rolled into the next SP as regular fileset updates. Here is a recent python bulletin as an example of the pattern, with the advisory, the ifix packages and the verification steps:
https://www.ibm.com/support/pages/security-bulletin-aix-affected-denial-service-cve-2024-50602-due-python
SUMA never touches that channel. No RqType reaches it. So the fileset level fix for python will show up in SUMA only when the next SP for your TL ships with it inside.

Which brings me to your actual evaluation question, because the complete AIX patching architecture is a combo, not a single tool:

1.⁠ ⁠SUMA (standalone or through NIM) for the TL/SP cadence into your lpp_source. You have this working already.

2.⁠ ⁠FLRTVC for the between-SP security gap: it compares each LPAR's installed filesets and ifixes against the FLRT vulnerability data and tells you exactly which fixNN packages are missing, with their URLs. It exists as the classic flrtvc script and as the ibm.power_aix.flrtvc Ansible module if you are automating. One current heads-up if you automate the download side: aix.software.ibm.com recently stopped answering plain http, so any tooling still following http URLs from the FLRT data breaks with connection refused. Force https.

3.⁠ ⁠emgr to apply, NIM to distribute, and the discipline that ifixes are temporary by nature: they get superseded at the next SP, which SUMA then brings you, closing the loop.

4.⁠ ⁠PowerSC TNC Patch Management is the managed umbrella over all of this: it is built around FLRT verification of the endpoints and maintains its own fix repository on the server side (pmconf init builds it, setup here: https://www.ibm.com/docs/en/powersc-standard/2.2.0?topic=tnc-setting-up-components). If you are evaluating PowerSC anyway, that component is the one designed to close exactly the gap you found, so I would test precisely this scenario against it: whether your PowerSC level pulls the security ifixes for your TL into its repository. Fair warning from the community trenches: some corners of the TNCPM documentation are thinner than they should be, so budget some hands-on time.

If you share which exact fix or CVE you are chasing, whether NIM is in the picture, and which PowerSC edition and level you are evaluating, happy to get more concrete on the setup.

Cheers
Roberto

Hi Roberto,

I'm thank thankful for your detailed explanation, espicially looking at the role of suma and PowerSC. Indeed we have PowerSC, NIM and Suma in place and actual evaluate which setup might help us in automated AIX patching. 

Best regards

Matthias

Hi Matthias,

short answer: it is well known behavior, not a mistake on your side, and the good news is that your SUMA command is actually doing its job correctly. The catch is that what you are looking for lives in a different distribution channel by design.

SUMA's world is made of Technology Levels, Service Packs and "Latest", which means the latest SP level fileset updates for the TL you filter on. That is what the RqType parameter speaks, as the current AIX 7.3 documentation describes:
https://www.ibm.com/docs/en/aix/7.3.0?topic=suma-service-update-management-assistant
So with 7300-04-01 already in your lpp_source and no newer SP published for TL4 yet, RqType=Latest with FilterML=7300-04 has literally nothing newer to fetch in that channel. The command is fine, the channel is empty.

The python fix you mention is a different animal: security content between service packs is shipped as INTERIM fixes, the signed fixNN tarballs published with the AIX security bulletins under aix.software.ibm.com/aix/efixes/security/, installed with emgr, and only later rolled into the next SP as regular fileset updates. Here is a recent python bulletin as an example of the pattern, with the advisory, the ifix packages and the verification steps:
https://www.ibm.com/support/pages/security-bulletin-aix-affected-denial-service-cve-2024-50602-due-python
SUMA never touches that channel. No RqType reaches it. So the fileset level fix for python will show up in SUMA only when the next SP for your TL ships with it inside.

Which brings me to your actual evaluation question, because the complete AIX patching architecture is a combo, not a single tool:

1.⁠ ⁠SUMA (standalone or through NIM) for the TL/SP cadence into your lpp_source. You have this working already.

2.⁠ ⁠FLRTVC for the between-SP security gap: it compares each LPAR's installed filesets and ifixes against the FLRT vulnerability data and tells you exactly which fixNN packages are missing, with their URLs. It exists as the classic flrtvc script and as the ibm.power_aix.flrtvc Ansible module if you are automating. One current heads-up if you automate the download side: aix.software.ibm.com recently stopped answering plain http, so any tooling still following http URLs from the FLRT data breaks with connection refused. Force https.

3.⁠ ⁠emgr to apply, NIM to distribute, and the discipline that ifixes are temporary by nature: they get superseded at the next SP, which SUMA then brings you, closing the loop.

4.⁠ ⁠PowerSC TNC Patch Management is the managed umbrella over all of this: it is built around FLRT verification of the endpoints and maintains its own fix repository on the server side (pmconf init builds it, setup here: https://www.ibm.com/docs/en/powersc-standard/2.2.0?topic=tnc-setting-up-components). If you are evaluating PowerSC anyway, that component is the one designed to close exactly the gap you found, so I would test precisely this scenario against it: whether your PowerSC level pulls the security ifixes for your TL into its repository. Fair warning from the community trenches: some corners of the TNCPM documentation are thinner than they should be, so budget some hands-on time.

If you share which exact fix or CVE you are chasing, whether NIM is in the picture, and which PowerSC edition and level you are evaluating, happy to get more concrete on the setup.

Cheers
Roberto