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
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]:
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.
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.
git patch file (master) -- take 2 0001-Ticket-47555-db2bak.pl-issue-when-specifying-non-def.patch
Reviewed by Rich (Thank you!!)
Pushed to master: eb6a462..8db3a1a master -> master commit 8db3a1a
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1044202
Metadata Update from @rmeggins: - Issue assigned to nhosoi - Issue set to the milestone: 1.3.3 - 11/13 (November)
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.
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.