#50996 Backup to a separate directory doesn't work
Closed: wontfix 3 years ago by spichugi. Opened 4 years ago by vashirov.

Issue Description

PR#50890 introduced a regression: backup to a separate directory doesn't work anymore:

# dsconf -v -D cn=directory\ manager -w password ldap://localhost backup create /tmp/backup/
DEBUG: The 389 Directory Server Configuration Tool
DEBUG: Inspired by works of: ITS, The University of Adelaide
DEBUG: dsrc path: /root/.dsrc
DEBUG: dsrc container path: /data/config/container.inf
DEBUG: dsrc instances: []
DEBUG: dsrc no such section ldap://localhost
DEBUG: Called with: Namespace(archive='/tmp/backup/', basedn=None, binddn='cn=directory manager', bindpw='password', db_type='ldbm database', func=<function backup_create at 0x7f6b2e035170>, instance='ldap://localhost', json=False, prompt=False, pwdfile=None, starttls=False, verbose=True)
DEBUG: Instance details: {'uri': 'ldap://localhost', 'basedn': None, 'binddn': 'cn=directory manager', 'bindpw': None, 'saslmech': None, 'tls_cacertdir': None, 'tls_cert': None, 'tls_key': None, 'tls_reqcert': 1, 'starttls': False, 'prompt': False, 'pwdfile': None, 'args': {'ldapurl': 'ldap://localhost', 'root-dn': 'cn=directory manager'}}
DEBUG: SER_SERVERID_PROP not provided, assuming non-local instance
DEBUG: Allocate <class 'lib389.DirSrv'> with ldap://localhost
DEBUG: Allocate <class 'lib389.DirSrv'> with server-f31.example.com:389
DEBUG: Allocate <class 'lib389.DirSrv'> with server-f31.example.com:389
DEBUG: SER_SERVERID_PROP not provided, assuming non-local instance
DEBUG: Allocate <class 'lib389.DirSrv'> with ldap://localhost
DEBUG: Allocate <class 'lib389.DirSrv'> with server-f31.example.com:389
DEBUG: Allocate <class 'lib389.DirSrv'> with server-f31.example.com:389
DEBUG: open(): Connecting to uri ldap://localhost
DEBUG: Using dirsrv ca certificate /etc/dirsrv/slapd-{instance_name}
DEBUG: Using external ca certificate /etc/dirsrv/slapd-{instance_name}
DEBUG: Using external ca certificate /etc/dirsrv/slapd-{instance_name}
DEBUG: Using certificate policy 1
DEBUG: ldap.OPT_X_TLS_REQUIRE_CERT = 1
DEBUG: open(): bound as cn=directory manager
DEBUG: Retrieving entry with [('',)]
DEBUG: Retrieved entry [dn:
vendorVersion: 389-Directory/1.4.3.3.20200401git60ae321e7 B2020.092.1320

]
DEBUG: Checking "None" under None : {'nsArchiveDir': '/tmp/backup/', 'nsDatabaseType': 'ldbm database', 'cn': 'backup_2020-04-01T13:23:09.504791'}
DEBUG: Validated dn cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config
DEBUG: Creating cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config
DEBUG: updating dn: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config
DEBUG: updated dn: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config with {'objectclass': [b'top', b'extensibleObject']}
DEBUG: updating dn: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config
DEBUG: updated dn: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config with {'nsArchiveDir': [b'/tmp/backup/'], 'nsDatabaseType': [b'ldbm database'], 'cn': [b'backup_2020-04-01T13:23:09.504791']}
DEBUG: Created entry cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config : {'objectclass': [b'top', b'extensibleObject'], 'nsArchiveDir': [b'/tmp/backup/'], 'nsDatabaseType': [b'ldbm database'], 'cn': [b'backup_2020-04-01T13:23:09.504791']}
DEBUG: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config getVal('nsTaskExitCode')
DEBUG: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config getVal('nsTaskLog')
DEBUG: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config getVal('nsTaskExitCode')
DEBUG: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config getVal('nsTaskLog')
DEBUG: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config getVal('nsTaskStatus')
DEBUG: complete status: 0 -> Backup finished.
DEBUG: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config getVal('nsTaskExitCode')
DEBUG: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config getVal('nsTaskLog')
DEBUG: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config getVal('nsTaskStatus')
DEBUG: complete status: 0 -> Backup finished.
DEBUG: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config getVal('nsTaskExitCode')
DEBUG: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config getVal('nsTaskLog')
DEBUG: cn=backup_2020-04-01T13:23:09.504791,cn=backup,cn=tasks,cn=config getVal('nsTaskStatus')
DEBUG: complete status: 0 -> Backup finished.
INFO: The backup create task has finished successfully
INFO: Command successful.
# ls -la /tmp/backup/
total 0
drwxr-xr-x.  2 dirsrv dirsrv  40 Apr  1 13:15 .
drwxrwxrwt. 10 root   root   400 Apr  1 13:23 ..

In the errors log everything looks fine:

[01/Apr/2020:13:23:09.755477848 +0000] - INFO - task_backup_thread - Beginning backup of 'ldbm database'
[01/Apr/2020:13:23:09.766267046 +0000] - INFO - bdb_copy_directory - Backing up file 1 (/tmp/backup/userroot/entryrdn.db)
[01/Apr/2020:13:23:09.771504071 +0000] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-server-f31/db/userroot/entryrdn.db to /tmp/backup/userroot/entryrdn.db
[01/Apr/2020:13:23:09.775566225 +0000] - INFO - bdb_copy_directory - Backing up file 2 (/tmp/backup/userroot/numsubordinates.db)
[01/Apr/2020:13:23:09.779833056 +0000] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-server-f31/db/userroot/numsubordinates.db to /tmp/backup/userroot/numsubordinates.db
[01/Apr/2020:13:23:09.783760325 +0000] - INFO - bdb_copy_directory - Backing up file 3 (/tmp/backup/userroot/ancestorid.db)
[01/Apr/2020:13:23:09.788021626 +0000] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-server-f31/db/userroot/ancestorid.db to /tmp/backup/userroot/ancestorid.db
[01/Apr/2020:13:23:09.791960741 +0000] - INFO - bdb_copy_directory - Backing up file 4 (/tmp/backup/userroot/parentid.db)
[01/Apr/2020:13:23:09.796212813 +0000] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-server-f31/db/userroot/parentid.db to /tmp/backup/userroot/parentid.db
[01/Apr/2020:13:23:09.800149012 +0000] - INFO - bdb_copy_directory - Backing up file 5 (/tmp/backup/userroot/aci.db)
[01/Apr/2020:13:23:09.804362008 +0000] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-server-f31/db/userroot/aci.db to /tmp/backup/userroot/aci.db
[01/Apr/2020:13:23:09.808265757 +0000] - INFO - bdb_copy_directory - Backing up file 6 (/tmp/backup/userroot/uid.db)
[01/Apr/2020:13:23:09.812420389 +0000] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-server-f31/db/userroot/uid.db to /tmp/backup/userroot/uid.db
[01/Apr/2020:13:23:09.816279614 +0000] - INFO - bdb_copy_directory - Backing up file 7 (/tmp/backup/userroot/objectclass.db)
[01/Apr/2020:13:23:09.820382971 +0000] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-server-f31/db/userroot/objectclass.db to /tmp/backup/userroot/objectclass.db
[01/Apr/2020:13:23:09.824237277 +0000] - INFO - bdb_copy_directory - Backing up file 8 (/tmp/backup/userroot/cn.db)
[01/Apr/2020:13:23:09.828362036 +0000] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-server-f31/db/userroot/cn.db to /tmp/backup/userroot/cn.db
[01/Apr/2020:13:23:09.831936170 +0000] - INFO - bdb_copy_directory - Backing up file 9 (/tmp/backup/userroot/nsuniqueid.db)
[01/Apr/2020:13:23:09.836192928 +0000] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-server-f31/db/userroot/nsuniqueid.db to /tmp/backup/userroot/nsuniqueid.db
[01/Apr/2020:13:23:09.840102440 +0000] - INFO - bdb_copy_directory - Backing up file 10 (/tmp/backup/userroot/id2entry.db)
[01/Apr/2020:13:23:09.844386294 +0000] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-server-f31/db/userroot/id2entry.db to /tmp/backup/userroot/id2entry.db
[01/Apr/2020:13:23:09.848485674 +0000] - INFO - bdb_copy_directory - Backing up file 11 (/tmp/backup/userroot/DBVERSION)
[01/Apr/2020:13:23:09.852671572 +0000] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-server-f31/db/userroot/DBVERSION to /tmp/backup/userroot/DBVERSION
[01/Apr/2020:13:23:09.856702772 +0000] - INFO - dblayer_backup - Backing up file 12 (/tmp/backup/log.0000000001)
[01/Apr/2020:13:23:09.861101969 +0000] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-server-f31/db/log.0000000001 to /tmp/backup/log.0000000001
[01/Apr/2020:13:23:09.868296067 +0000] - INFO - dblayer_backup - Backing up file 13 (/tmp/backup/DBVERSION)
[01/Apr/2020:13:23:09.872440399 +0000] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-server-f31/db/DBVERSION to /tmp/backup/DBVERSION
[01/Apr/2020:13:23:09.878283425 +0000] - INFO - task_backup_thread - Backup finished.

Metadata Update from @vashirov:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

4 years ago

It's because that PR added privatetmp to systemd, so because your backup dest is /tmp, then it's not the system /tmp, but a private version. So I think this is not a bug? Look under /var/tmp/systemd-private-* I think for the output.

Ok, so it's a corner case. But it's confusing, because in the logs there is no mention of /var/tmp/systemd-private-*.
If the user does backup to /tmp, at least we should detect this and log a warning to inform the user that this is not the /tmp they're looking for.

I agree with you, the target directory being private to DS, we should at least log a warning that the backup is private. Because private namespace can not be used by other processes (unless by root) we may also reject commands (backup and export) with such option.

Metadata Update from @mreynolds:
- Issue priority set to: major
- Issue set to the milestone: 1.4.3

4 years ago

But directory server doesn't know it's in a private namespace, nor what that private namespace is called, because systemd chroots/bind mounts us into a namepsace where our /tmp goes to /var/tmp/systemds-private-* and we just don't know if that's real.

Also, when you do a backup, by default they go to /var/lib/dirsrv/slapd-instance/bak I think, not /tmp. You requested it to go to /tmp, so the server did what you want .....

So I think this isn't an issue or a bug ....

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/4049

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
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata