That being said, is there a way to verify the problem is actually
with VLV indices without
submitting new requests? Running ldapsearch -LLL -x -b
"ou=ca,ou=requests,o=ipaca" -D "cn=Directory Manager" -W
"(requeststate=*)" on every replica shows all the requests 19990001-19990008.
Maybe you could point me to the exact mechanism / query / source code snippet used to
select the next request id?
I've tried to reproduce CA behaviour (as much as I could understand from source code)
with the following command:
ldapsearch -LLL -x -b "ou=ca,ou=requests,o=ipaca" -D "cn=Directory
Manager" -W -E '!vlv=5/0:0820000000' -E '!sss=requestId'
"(requeststate=*)" dn
Results are the same for every replica, 19990008 is the last submitted request id, and 81
is the actual number of certificate requests in ou=ca,ou=requests,o=ipaca:
dn: cn=19990003,ou=ca,ou=requests,o=ipaca
dn: cn=19990004,ou=ca,ou=requests,o=ipaca
dn: cn=19990005,ou=ca,ou=requests,o=ipaca
dn: cn=19990006,ou=ca,ou=requests,o=ipaca
dn: cn=19990007,ou=ca,ou=requests,o=ipaca
dn: cn=19990008,ou=ca,ou=requests,o=ipaca
# sortResult: (0) Success
# vlvResultpos=81 count=81 context= (0) Success
It seems VLV indices are fine. I'll still try to repair them in case there are no
other feasible explainations for request id reuse.
Regards,
Boris