We're running a Policy Server and this one reports errors :
[10121/140254820423424][Tue May 26 2020
11:07:22][SmObjProvider.cpp:181][ERROR][sm-Server-03090] Policy
store failed operation 'CleanAgentCmds' for object type 'Policy
store provider' . LDAP Error Deleting AgentCommand object: 32: No
such object
[10121/140254820423424][Tue May 26 2020
11:07:22][SmPolicyServer.cpp:1899][ERROR][sm-Server-00620] Exception
in JournalThread. Text: Policy store failed operation
'CleanAgentCmds' for object type 'Policy store provider'. LDAP Error
Deleting AgentCommand object: 32: No such object
More, when we use the LDAP ODSEE UI tool to search the servercommand4
and smagentcommand4 objects, the tool reach time out and is unable to
give the result :
(&(smServerCommandOID4=*)(objectclass=smservercommand4))
and
(&(smServerCommandOID4=*)(objectclass=smagentcommand4))
Error
The time limit used to complete the search is 20 seconds. Your
search exceeds this limit. Note that if you are trying to search on
non indexed attributes the search will be slow
it logs following in policy store logs
[26/May/2020:11:11:47 +0100] - WARNING<20805> - Backend Database -
conn=1646 op=373 msgId=374 - search is not indexed
base='ou=netegrity,dc=policystore'
filter='(&(smServerCommandOID4=*)(objectClass=smservercommand4))'
scope='sub'
How can we fix this ?
Policy Server 12.8SP3 on RedHat 6;
At first glance, you get this issue because indexes are broken and you
need to reindex the Policy Store data to solve the issue. The patch of
the ODSEE Ldap server helps to avoid what you mentioned here :
To fix DSCC bug that breaks ancestorid post re-indexing
which means, after re-indexing, you won't face the ancestorid issue
and re-indexing, so you probably won't have to do this :
/usr/dsee7/bin/dsadm reindex -t ancestorid /usr/ldap/policystore/ "dc=policystore"
/usr/dsee7/bin/dsadm reindex -t ancestorid /usr/ldap/policystore/ "ou=netegrity,dc=policystore"
About the index broken, this can be caused by ldap synchronization
problem and also a machine time problem between both Policy Server
machines.
Note that
- The upgrade of the ODSEE (applying a patch) won't prevent ldap
synchronization problem nor machine time problem between both
Policy Server machines;