Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1447015
Description of problem: In Red Hat Enterprise Linux 7, the db2bak.pl script has been changed according to https://pagure.io/389-ds-base/c/8db3a1ad07198ba548f653aa4acebe4324c16384, to always write the backup to `/var/lib/dirsrv/<instance>/bak` and simply create a symlink for the location specified with `-a` or `-A` The current usage description of the script does not really indicate that the backup won't be written to the designated location: - https://pagure.io/389-ds-base/blob/master/f/ldap/admin/src/scripts/db2bak.pl. in#_36 From the given description, one would assume that the backup is written to the location specified with `-a` or `-A` and not just a symlink created to the default location. This can cause various issues, as customers may not expect the backup to be written to this location and it therefore can fill up the volume badly. It's therefore required to adjust the usage output and man page of the script to reflect that change and help the customer understand how this works. Version-Release number of selected component (if applicable): - 389-ds-base-1.3.5.10-15.el7_3.x86_64 How reproducible: - Always Steps to Reproduce: 1. db2bak.pl -a /mnt/backup -D 'cn=directory manager' -w - 2. Check if the Backup was written to `/mnt/backup` or just a symlink created to `/var/lib/dirsrv/<instance>/bak` Actual results: Symlink created to `/var/lib/dirsrv/<instance>/bak` Expected results: Backup created in `/mnt/backup` or else an updated usage of the script as well as man page Additional info:
Metadata Update from @mreynolds: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1447015
Metadata Update from @mreynolds: - Issue assigned to mreynolds
<img alt="0001-Ticket-49241-Update-man-page-and-usage-for-db2bak.pl.patch" src="/389-ds-base/issue/raw/files/68bab96fcfa4b7617818bf3d9b852a242173d923fc13a62457a82168a6b22c1e-0001-Ticket-49241-Update-man-page-and-usage-for-db2bak.pl.patch" />
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to review - Custom field type adjusted to defect
Part of me wonders why we even offer -a flag in this case.
I'm wondering if hardcoding /var/lib/dirsrv/<instance>/bak is a good idea or not, given we still allow people to change it. Could we point them at nsslapd-bakdir: instead? Or would people try and change that then? I don't know ....
Yeah, it's misleading in my opinion. It should really be backup name, and not backup location. I guess it's needed for backwards compatibility, but it's misleading because the backup is still stored in the same default location.
I'm wondering if hardcoding /var/lib/dirsrv/<instance>/bak is a good idea or not,
Yeah I was wondering about it as well.
given we still allow people to change it. Could we point them at nsslapd-bakdir: instead? Or would people try and change that then? I don't know ....
That's better, but now I'm starting to like the idea of changing "-a" from a location to just a backup name. That might be more of a 1.4.0 change though.
Part of me wonders why we even offer -a flag in this case. Yeah, it's misleading in my opinion. It should really be backup name, and not backup location. I guess it's needed for backwards compatibility, but it's misleading because the backup is still stored in the same default location.
Yeah, legacy is a problem here.
I'm wondering if hardcoding /var/lib/dirsrv/<instance>/bak is a good idea or not, Yeah I was wondering about it as well. given we still allow people to change it. Could we point them at nsslapd-bakdir: instead? Or would people try and change that then? I don't know .... That's better, but now I'm starting to like the idea of changing "-a" from a location to just a backup name. That might be more of a 1.4.0 change though.
well, lets put nsslapd-bakdir in the docs, because I think changing that isn't harmful if a user insisted. As for -a, perhaps we should just get rid of it instead? Maybe it's my bias but I think that db2ldif is a better backup, but I'm not sure of all the use cases. Your idea of changing it to a name is a reasonable suggestion though, but if we are changing the semantics of a flag, we better to deprecate the flag and use a new one to avoid script confusion.
I agree, and for now I will update the man page with nsslapd-bakdir
<img alt="0001-Ticket-49241-Update-man-page-and-usage-for-db2bak.pl.patch" src="/389-ds-base/issue/raw/files/a7dbcbd8612ef1e6c8abb73f8ae9dc5b9da61aeae0e14944d5a1835307dbf965-0001-Ticket-49241-Update-man-page-and-usage-for-db2bak.pl.patch" />
Metadata Update from @firstyear: - Custom field reviewstatus adjusted to ack (was: review)
97b15b9..0804c43 master -> master
2ae1521..470a30c 389-ds-base-1.3.6 -> 389-ds-base-1.3.6
071cada..6b4a0b4 389-ds-base-1.3.5 -> 389-ds-base-1.3.5
Metadata Update from @mreynolds: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
<img alt="0001-Ticket-49241-add-symblic-link-location-to-db2bak.pl-.patch" src="/389-ds-base/issue/raw/06bd9818f807ab00a37b69f75685302fe0e0a2e5cc144dcd9d3b530daff249b0-0001-Ticket-49241-add-symblic-link-location-to-db2bak.pl-.patch" />
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to review (was: ack)
ca3fef5..95a7f23 master -> master
35c0834..f076334 389-ds-base-1.3.6 -> 389-ds-base-1.3.6
34bc5ef..556674c 389-ds-base-1.3.5 -> 389-ds-base-1.3.5
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/2300
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.