Description of problem:
verify-db.pl has option '-a 'which can specify path to DB.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Perl_Scripts.html#verify-db.pl
But if verify-db.pl run with -a option, it does not verify DB files under DB directory which is specified by option '-a', but it alreays verify instance DB instead.
Steps to Reproduce:
e.g. ./verify-db.pl -a /var/lib/dirsrv/slapd-test/bak/test-2015_07_06_16_32_07
Actual results:
DB files unser instance's DB directory always get verified.
Expected results:
DB files under DB directory specified -a option is verified.
Additional info:
Easy workaround:
N/A
operation log when the issue is confirmed by strace verify.log
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1246165
Initial investigation shows that we use -a to analyze the transaction logs, but then the db-verify.pl script calls the dbverify shell script, which then calls on the nsslapd binary: "nsslapd dbverify ..." to verify the actual db files.
The server dbverify code reads in parameters from the dse configuration in order to open the database. So the server needs to be passed information about which "database" it needs to verify (if it's not the configured database in cn=config).
Continuing investigation....
attachment 0001-Ticket-48215-verify_db.pl-doesn-t-verify-DB-specifie.patch
Looks good.
One question... Do we have to worry about SELinux or it just works fine?
Replying to [comment:8 nhosoi]:
Looks good. One question... Do we have to worry about SELinux or it just works fine?
Good question, I was only testing default backup locations, I will try other locations tomorrow. I suspect SELinux will play a part since the script calls the ns-slapd binary to do the db file verification.
Replying to [comment:9 mreynolds]:
Replying to [comment:8 nhosoi]: Looks good. One question... Do we have to worry about SELinux or it just works fine? Good question, I was only testing default backup locations, I will try other locations tomorrow. I suspect SELinux will play a part since the script calls the ns-slapd binary to do the db file verification.
Actually SELinux does not impact the verify process. Pushing commit:
eb54f03..27fadb7 master -> master commit 27fadb7 Author: Mark Reynolds mreynolds@redhat.com Date: Wed Aug 5 16:31:49 2015 -0400
b4b6adc..210071c 389-ds-base-1.3.4 -> 389-ds-base-1.3.4 commit 210071c
e2f6eeb..6878a6c 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit 6878a6c
21a1196..1e736a7 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit 1e736a7
95a7fbd..bb704aa 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit bb704aac1868ab719d0823871cf0b677e67fcf41
e4db055..cf8c8d7 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit cf8c8d7
Usage needed to be updated in dbverify script:
27fadb7..20284e6 master -> master commit 20284e6
210071c..8e08c8b 389-ds-base-1.3.4 -> 389-ds-base-1.3.4 commit 8e08c8b
6878a6c..5f395ed 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit 5f395ed
1e736a7..d2962ea 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit d2962ea
bb704aa..26f6b92 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit 26f6b92b70d50bd9e34e3a9d90334832aeb25b63
Need to usage dbverify usage in main.c
20284e6..c1912cd master -> master commit c1912cd
8e08c8b..c842dbe 389-ds-base-1.3.4 -> 389-ds-base-1.3.4 commit c842dbe
5f395ed..67e8973 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit 67e8973
d2962ea..318f897 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit 318f897
26f6b92..e861b06 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit e861b06de4faceea3774fb20963d3a6bf3fba735
cf8c8d7..aa08398 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit aa08398
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.2.11.33
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1546
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.