#48215 verify_db.pl doesn't verify DB specified by -a option.
Closed: wontfix None Opened 8 years ago by hiroko.

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:

  1. take backup by db2bak
  2. run DB verify against backup DB with -a option

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

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....

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

7 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata