RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1044202 - db2bak.pl issue when specifying non-default directory
Summary: db2bak.pl issue when specifying non-default directory
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-17 21:54 UTC by Nathan Kinder
Modified: 2020-09-13 20:48 UTC (History)
2 users (show)

Fixed In Version: 389-ds-base-1.3.3.1-1.el7
Doc Type: Bug Fix
Doc Text:
Cause: If "-a backup_directory" is given to the db2bak.pl utility, the backup_directory is not supposed to exist. If it exists, it fails to create a symbolic link to the specified backup_directory. Consequence: The utility fails to create a back up in the specified backup_directory. Fix: Introduced a new option "-A backup_directory". Result: Even if the backup_directory exists, another level of directory with the format "ID-<date_time>" is created under the backup_directory as a symbolic link. The backup is successfully created in backup_directory/ID-<date_time>.
Clone Of:
Environment:
Last Closed: 2015-03-05 09:33:04 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 892 0 None None None 2020-09-13 20:48:43 UTC
Red Hat Product Errata RHSA-2015:0416 0 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description Nathan Kinder 2013-12-17 21:54:28 UTC 
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
Comment 2 Amita Sharma 2014-12-29 07:23:20 UTC 
 [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
Comment 3 Noriko Hosoi 2015-01-01 02:25:02 UTC 
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
Comment 4 Amita Sharma 2015-01-05 08:36:20 UTC 
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.
Comment 6 errata-xmlrpc 2015-03-05 09:33:04 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.