Fix clone CA issue on upstream CI #4839
Conversation
fmarco76
force-pushed
the
Fix_CI_Clone_secure_ds
branch
2 times, most recently
from
002b43f
to
476cd9d
Compare
Ldif file for reindex task have been update to be compatible with latest DS version.
fmarco76
force-pushed
the
Fix_CI_Clone_secure_ds
branch
from
476cd9d
to
03888e9
Compare
|
There was a problem hiding this comment.
@fmarco76 @tbordaz Is the change to the index rebuild task in DS documented somewhere? I'm wondering which other platforms are affected by this change.
The changes to the test looks fine so feel free to merge. We do need to figure out why the original procedure no longer works, otherwise we would need to update the docs to include these additional steps.
I did not find specific documentation but just looking at the what the command |
|
Unfortunately you are right the only example of vlv reindex task is in GUI part You may trigger reindex with CLI like dsconf supplier2 backend vlv-index list userroot dn: cn=vlvSrch,cn=userRoot,cn=ldbm database,cn=plugins,cn=config cn: vlvSrch vlvbase: dc=example,dc=com vlvscope: 2 vlvfilter: (|(objectclass=*)(objectclass=ldapsubentry)) Sorts: - dn: cn=vlvIdx,cn=vlvSrch,cn=userRoot,cn=ldbm database,cn=plugins,cn=config - cn: vlvIdx - vlvsort: cn ou sn - vlvenabled: 1 - vlvuses: 0 dsconf supplier2 backend vlv-index reindex --index-name vlvIdx --parent-name vlvSrch userRoot |
@tbordaz The problem was not with vlv index but with normal index. The reindex task submitted by PKI was not working unless I modify the ldif as in this PR. Is this correct or there are other issuees? |
Reindex of a backend is common administration task, heavily tested by CI so you may be hitting a corner case. |
|
@tbordaz if I use the current ldif file for reindex (https://github.com/dogtagpki/pki/blob/master/base/ca/database/ds/indextasks.ldif) in the db log I get the following message and the following queries do not work because indexes are not built. If I modify the file like in this PR (leaving only the index names and removing the index types) I get the following logs: In this second case the following queries are working properly. |
|
Something not clear to me is that in both indexing the exit code is 0. Why do you think it fails in the first case ? With mdb, all databases (domain, ca, and their related indexes) are located in a single file (data.mdb) but they still exist. |
The problem starts with the query: It was not working because the description field was not indexed (there was log in my previous container but I can recreate if needed). If I update the indexes with the first ldif file then the query still does not work. If I update with the second it start to work so I think there is something not working in the first case. Reindex with the command |
|
So my understand is that if you run this task (https://github.com/dogtagpki/pki/blob/master/base/ca/database/ds/indextasks.ldif) the search fails If you reindex (the full db) using the definitions in dse.ldif then it works The seach is using the filter '(description=2;21299251...*)'. The final wildchar use substring index, if it exists. Could you retry the task https://github.com/dogtagpki/pki/blob/master/base/ca/database/ds/indextasks.ldif replacing 'nsIndexAttribute: description:eq,pres' with 'nsIndexAttribute: description:eq,pres,sub' |
Sorry, I copied the wrong line. The query has not the final "*". If I run this I get the result and in the DS log I get that index are not used. |
|
Since the DS issue generating the problem has been fixed this PR is not needed. |
Ldif file for reindex task have been update to be compatible with latest DS version.
@edewata Instead of rebuild the index with a command after the installation I tried with the parameter
pki_clone_reindex_databut it does not work as I was expecting. I tried also to modify the code using this parameter but there were side effect so I gave up for the moment and add the manual step. We could consider to add the index build in pkispawn for this specific case.Additionally, when removing the secondary CA I start to get error in the DS log from the replica manager plugin and it becomes not accessible after a while. Adding a restart to DS before re-installing the CA mitigate the problem.