#47555 db2bak.pl issue when specifying non-default directory
Closed: wontfix None Opened 9 years ago by agaviola.

Hi,

I'm doing backup on my 389 DS system using the existing db2bak.pl script and I specify a specific directory location (/mydir/dirsrv/backup) instead of the default ($mybakdir = "/var/lib/dirsrv/slapd/bak"). I invoke the command below

/usr/lib64/dirsrv/slapd/db2bak.pl -v -D cn=manager -w Manager -a /mydir/dirsrv/backup

Back up directory: /mydir/dirsrv/backup
ldap_initialize( ldap://agc.redwar.net:389 )
add objectclass:
top
extensibleObject
add cn:
backup_2013_10_10_7_42_11
add nsArchiveDir:
/mydir/dirsrv/backup
add nsDatabaseType:
ldbm database
adding new entry "cn=backup_2013_10_10_7_42_11, cn=backup, cn=tasks, cn=config"
modify complete

and nothing has been written to the specified directory.

I trace the script and found out that something needs to be added in the script to be able the -a <specified_directory> works. Here's the changes;

]# diff -Nur db2bak.pl.orig db2bak.pl
--- db2bak.pl.orig 2013-10-08 12:44:00.475987760 +0300
+++ db2bak.pl 2013-10-10 07:51:10.710773315 +0300
@@ -104,7 +104,10 @@
$taskname = "backup_${yr}${mn}${dy}${h}${m}${s}";
if ($archivedir eq "") {
$archivedir = "${mybakdir}/${yr}
${mn}${dy}${h}${m}${s}";
+} else {
+ $archivedir = "${archivedir}/${yr}${mn}${dy}${h}${m}_${s}";
}
+
$dn = "dn: cn=$taskname, cn=backup, cn=tasks, cn=config\n";
$misc = "changetype: add\nobjectclass: top\nobjectclass: extensibleObject\n";
$cn = "cn: $taskname\n";

So, kindly verify the added lines for a possible patch.

Thanks,
Archie


Bug description: db2bak.pl takes an option "-a backupdir", which is
supposed to be generated by the server and used as a backup directory.
But since the created directory inherits the parent's selinux context,
it may fail to store the backup files in the directory.

Fix description: As the reporter agaviola suggested, it should be a
good idea to add one more level to the archive directory.
$archivedir = "${archivedir}/ID-${yr}${mn}${dy}${h}${m}_${s}";
But to keep the backward compatibility, introducing a new option "-A
backupdir" and when "-A" is given, storing the backup files in the
nested backup directory. If the option is "-a backupdir", the backup
files are stored in the backupdir.

Also, this patch sets the right ownership and selinux context to the
generated directory. Note: if the parent directories of the created
backupdir do not have the correct selinux context, even if the last
directory's setting is correct, storing the backup files fails. It
is the user's responsibility to set them correctly.

systemd calls like chcon should only be done if built with support for systemd. Take a look at how we do this in perl in DSCreate.pm updateSystemD, startServer, etc.

Replying to [comment:5 rmeggins]:

systemd calls like chcon should only be done if built with support for systemd. Take a look at how we do this in perl in DSCreate.pm updateSystemD, startServer, etc.

Thank you for your comments, Rich. Revised the patch as follows:
Bug description: db2bak.pl takes an option "-a backupdir", which is
supposed to be generated by the server and used as a backup directory.
But since the created directory inherits the parent's selinux context,
it fails to store the backup files in the directory.

Fix description: As the reporter agaviola suggested, it should be a
good idea to add one more level to the archive directory.
$archivedir = "${archivedir}/ID-${yr}${mn}${dy}${h}${m}_${s}";
But to keep the backward compatibility, introducing a new option "-A
backupdir" and when "-A" is given, storing the backup files in the
nested backup directory. If the option is "-a backupdir", the backup
files are stored in the backupdir.

Respecting the selinux policy, the server and its utilities are not
supposed to create a file/directory where it is not allowed. This
patch creates a symlink from the back up location to the specified
path by a user. bak2db.pl follows the symlink and restore from the
back up directory.

Reviewed by Rich (Thank you!!)

Pushed to master:
eb6a462..8db3a1a master -> master
commit 8db3a1a

Metadata Update from @rmeggins:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.3.3 - 11/13 (November)

5 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/892

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)

2 years ago

Login to comment on this ticket.

Metadata