adevl and ad_response probes installation failed "inst_pkg failed: illegal SID" for an LDAP server

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)
• CA Unified Infrastructure Management On-Premise (Nimsoft / UIM)
• CA Unified Infrastructure Management SaaS (Nimsoft / UIM)

Issue/Introduction

Installation failed "inst_pkg failed: illegal SID"

Environment

• Release: DX UIM 20.3
• ad_response
• ad_evl
• Linux

Resolution

To avoid the inst_pkg failed: Invalid SID error I used Raw Configure mode to set the secondary hub to ignore_ip = yes (from no).

This allowed the packages to be deployed but this was a Linux machine so the adevl and ad_response/ad_server or template packages would deploy but not display (but this is expected as the OS turned out to be Linux).

Upon further discussion with the customer, the requirement was to monitor LDAP replication and this was for Linux machines, so OpenLDAP. (Two 2 ldap servers, monitor if they are the same.  If the replica is changed, generate an alarm.)

There is another probe ldap_response which runs on Linux but it does not monitor replication. This probe monitors a set of LDAP servers by regularly querying them with a predefined lookup call. Alarm messages can be generated on response time and number of found records. Quality of service messages can be sent on the same parameters.

Customer may be able to use logmon to run 1 or more ldap commands, e.g., ldapsearch commands to check LDAP replication.

This may help.

How can I check the OpenLDAP replication status?
https://access.redhat.com/solutions/532053 

For instance on RedHat Linux with OpenLDAP:

There is a contextCSN value that you should be able to compare to verify the status of the OpenLDAP's replication. http://www.openldap.org/doc/admin23/syncrepl.html

The contextCSN will show you when a consumer is out of sync. This can be searched for using the following command on the provider and consumers.

# ldapsearch -xLLL -h ldapconsumer -b dc=example,dc=com contextCSN
dn: dc=example,dc=com
contextCSN: 20131104063420.384948Z#000000#000#000000

You can see that this database is dc=example,dc=com and the contextCSN is the current change status of the LDAP server. You can compare the values between consumer and provider.

# ldapsearch -xLLL -h ldapprovider contextCSN
dn: dc=example,dc=com
contextCSN: 20131104064835.720953Z#000000#000#0000

You can see that the values differ between the consumer and provider because we closed the consumer's firewall and removed an entry on the provider which was then not replicated to the consumer. If the replication was in sync then the contextCSN values on the two servers would be the same.

Additional Information

"inst_pkg failed: illegal SID" when deploying probes on secondary hub (broadcom.com)