lib389

#107 Instance removal with dsctl fails on Debian
Opened by behrmann. Modified

Open
Close Issue

Running dsctil <instance> remove --do-it or dsctl --remove-all, but fails in lib389/instance/remove.py:remove_ds_instance when asserting the existence of its marker file, which on RH systems is in /etc/sysconfig/dirsrv-<instance>, but in Debian is in /etc/default/dirsrv-<instance>. Unfortunately this path is hard-coded, although it doesn't need to be, the patch below fixes this.

--- remove.py   
+++ remove.py     
@@ -39,7 +39,7 @@
     remove_paths['tmpfiles_d'] = dirsrv.ds_paths.tmpfiles_d + "/dirsrv-" + dirsrv.serverid + ".conf"
     remove_paths['inst_dir'] = dirsrv.ds_paths.inst_dir
-    marker_path = "%s/sysconfig/dirsrv-%s" % (dirsrv.ds_paths.sysconf_dir, dirsrv.serverid)
+    marker_path = "%s/dirsrv-%s" % (dirsrv.ds_paths.initconfig_dir, dirsrv.serverid)
     etc_dirsrv_path = os.path.join(dirsrv.ds_paths.sysconf_dir, 'dirsrv/')
     ssca_path = os.path.join(etc_dirsrv_path, 'ssca/')

This has been found out on the current Debian testing, with version 1.4.0.21-1 of lib389.

Thank you for reporting the issue! I believe it was addressed in https://pagure.io/389-ds-base/issue/50208 and the fix is available in 1.4.1.x.

BTW, lib389 was merged with 389-ds-base, and new issues should be reported there. Thank you!

Metadata Update from @vashirov:
- Custom field Origin adjusted to None
- Custom field Review Status adjusted to None

Oh, sorry, I missed that it was merged.

I will try to test against the current 1.4.1.X and see whether the problem remains. Looking at the code it might be fixed, but it still has a

remove_paths['etc_sysconfig'] = "%s/sysconfig/dirsrv-%s" % (dirsrv.ds_paths.sysconf_dir, dirsrv.serverid)

which won't break anything, but still leave an artifact around on Debian (/etc/default/dirsrv-<instance>). I'll open a bug report for that.
Metadata
None
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.