- Upgrading APIGW Software Gateway from v11.0 CR02 --> v11.1 --> v11.1.1.
- Upgraded to v11.1 successfully (Using PMS v1.0.1).
- When Attempting to upgrade to v11.1.1.
We upgraded to PMS v2.0.0 by using PMS v1.0.1 to upload and then install the PMS v2.0.0 .L7P patch.
When we try to use PMS to upload the .L7P file for v11.1.1, we get the error:
Patch operation failed : Patch API Error: Certificate is not trusted for signing patches:.
- It appears that PMS is still at v1.0.1 even though we appear to have upgraded it to v2.0.0.
Steps taken to update to PMS v2.0.0:
1)Running as root user
2) pms.sh start (running RPM v1.0.1)
cd /opt/apigw/software/gateway/ (where we have .L7P files)
3) Upload Patch:
-Provide FULL path to .L7P file even though you are in the directory where it resides
patch.sh upload /opt/apigw/software/gateway/Layer7_API_PMS_RHEL_v2.0.0-20240715115049.L7P
Patch ID Layer7_API_PMS_RHEL_v2.0.0-20240715115049 (Upgrades the Layer7 API Patch Management Service to version 2.0.0-20240715115049.
This patch requires a reboot of the Layer7 Gateway Appliance after installation.) is UPLOADED, last modified on 2025-03-11T14:22:18-0500
Patch operation completed successfully.
4) patch.list (shows patch uploaded)
5) Install Patch: (use PMS to install PMS v2.0.0)
patch.sh install Layer7_API_PMS_RHEL_v2.0.0-20240715115049
Patch ID Layer7_API_PMS_RHEL_v2.0.0-20240715115049 (Upgrades the Layer7 API Patch Management Service to version 2.0.0-20240715115049.
This patch requires a reboot of the Layer7 Gateway Appliance after installation.) is INSTALLED, last modified on 2025-03-11T14:23:01-0500
Patch operation completed successfully.
6) Rebooted API Gateway server
7) Start PMS
8) running as root user
pms.sh start
cd /opt/apigw/software/gateway/
9) patch.sh upload /opt/apigw/software/gateway/Layer7_API_Gateway_v11.1.1.18484.L7P
Patch operation failed : Patch API Error: Certificate is not trusted for signing patches
10) rpm -qa | grep patch- , shows the PMS1.0 is currently installed , but does not shows the PMS 2.0 as expected.
patch-2.7.6-11.el8.x86_64
kpatch-dnf-0.9.7_0.4-2.el8.noarch
patch-management-1.0.1-20240410001712.noarch
kpatch-0.9.7-2.el8.noarch
The PMS v2.0.0 .L7P install patch log in /opt/SecureSpan/PatchManagement/var/logs/pms_0_0.log
that this issue with the /home directory may have caused PMS v2.0.0 to not install correctly (but yet patch.sh list reports as SUCCESSFUL).
It appears that the script failed due to permissions trying to create /home/patcher but yet it still returned exit code 0 and marked the install as SUCCESSFUL.
Excerpt from PMS log:
Mar 11, 2025 3:20:30 PM com.broadcom.patchman.service.PatchServiceApiImpl installPatch
INFO: Output from patch install: Creating patcher user's home directory
Mar 11, 2025 3:20:30 PM com.broadcom.patchman.service.PatchServiceApiImpl installPatch
INFO: Output from patch install: mkdir: cannot create directory ‘/home/patcher’: Permission denied
CA API Gateway 11.x Software Form Factor
Ideally, the HOME variable from the '/etc/default/useradd' file should be honored, as we are using the Linux 'useradd' command to create the user 'patcher' and nothing from the code. This method aligns with how we create the gateway and layer7 users.
1) added another remote mount directory on our local server for /home/patcher.
Once that was mounted and available, created a symbolic link with the command:
ln -s /home/patcher /export/home/patcher
[root@MyServer patches]# ll /export/home/patcher
total 0
lrwxrwxrwx. 1 root root 13 Mar 17 10:45 patcher -> /home/patcher
2) cleared out the 'false' successful PMS v2.0.0 install in /opt/SecureSpan/PatchManagement/var/patches
by removing the Layer7_API_PMS_RHEL_v2.0.0-20240715115049.status file.
3) run the PMS v2.0.0 install again and this time it was completely successful - rpm also shows PMS v2.0.0.
# rpm -qa |grep patch-
patch-management-2.0.0-20240715115049.noarch