Hide Forgot
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/47555 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
[root@dhcp201-126 ~]# rpm -qa | grep 389 389-ds-base-libs-1.3.3.1-10.el7.x86_64 389-ds-base-1.3.3.1-10.el7.x86_64 389-ds-base-debuginfo-1.3.3.1-10.el7.x86_64 /usr/lib64/dirsrv/slapd-dhcp201-126/db2bak.pl -v -D "cn=Directory Manager" -w Secret123 -a /export/backup Back up directory: /export/backup ldap_initialize( ldap://dhcp201-126.englab.pnq.redhat.com:389 ) Successfully added task entry "cn=backup_2014_12_29_12_52_9, cn=backup, cn=tasks, cn=config" Failed to create a symlink from /var/lib/dirsrv/slapd-dhcp201-126/bak/backup to /export/backup Am I missing anything, please guide. Thanks, Ami
Hi Ami, Sorry about my not providing the details for the verification steps... If '-a backupdir' is given, the backupdir should not exist and the dir should be under selinux permission. So, most likely, you'd better run your test with the permissive mode. As you see in the following description, could you please "-A backupdir" with an existing backupdir? ====================================================================== 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. ====================================================================== I guess we should open a bug for a doc and man page to add "-A backupdir"... Please note that the usage of db2bak.pl shows these lines: -A backupdir - Backup directory (backupdir/ID-<date_time>) -a backupdir - Backup directory\n
Thanks Noriko for detailed information. Doc bug created :: https://bugzilla.redhat.com/show_bug.cgi?id=1178640 [root@dhcp201-126 ~]# rpm -qa | grep 389 389-ds-base-libs-1.3.3.1-10.el7.x86_64 389-ds-base-1.3.3.1-10.el7.x86_64 389-ds-base-debuginfo-1.3.3.1-10.el7.x86_64 [root@dhcp201-126 ~]# getenforce Enforcing [root@dhcp201-126 ~]# setenforce 0 [root@dhcp201-126 ~]# getenforce Permissive [root@dhcp201-126 ~]# ls -al /export/backup total 4 drwxrwxrwx. 2 root root 6 Dec 29 12:50 . drwxr-xr-x. 7 root root 4096 Dec 30 13:19 .. [root@dhcp201-126 ~]# /usr/lib64/dirsrv/slapd-dhcp201-126/db2bak.pl -v -D "cn=Directory Manager" -w Secret123 -A /export/backup Back up directory: /export/backup/dhcp201-126-2015_1_5_14_0_41 ldap_initialize( ldap://dhcp201-126.englab.pnq.redhat.com:389 ) Successfully added task entry "cn=backup_2015_1_5_14_0_41, cn=backup, cn=tasks, cn=config" [root@dhcp201-126 ~]# /usr/lib64/dirsrv/slapd-dhcp201-126/db2bak.pl -v -D "cn=Directory Manager" -w Secret123 -a /export/non_existing_backup Back up directory: /export/non_existing_backup ldap_initialize( ldap://dhcp201-126.englab.pnq.redhat.com:389 ) Successfully added task entry "cn=backup_2015_1_5_14_1_0, cn=backup, cn=tasks, cn=config" [root@dhcp201-126 ~]# ls -al /export lrwxrwxrwx. 1 root root 57 Jan 5 14:01 non_existing_backup -> /var/lib/dirsrv/slapd-dhcp201-126/bak/non_existing_backup [root@dhcp201-126 ~]# ls -al /export/non_existing_backup/ total 10268 drwx------. 3 nobody nobody 103 Jan 5 14:01 . drwxrwx---. 4 nobody nobody 67 Jan 5 14:01 .. -rw-------. 1 nobody nobody 51 Jan 5 14:01 DBVERSION -rw-------. 1 nobody nobody 14471 Jan 5 14:01 dse_index.ldif -rw-------. 1 nobody nobody 377 Jan 5 14:01 dse_instance.ldif -rw-------. 1 nobody nobody 10485760 Jan 5 14:01 log.0000000001 drwx------. 2 nobody nobody 4096 Jan 5 14:01 userRoot Hence VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0416.html