#293 remove-ds-admin.pl does not remove everything
Closed: wontfix None Opened 12 years ago by nhosoi.

This is an admin server side of ticket 34: remove-ds.pl does not remove everything

Fix description: Introduce an option "-a", with which all the
generated directory files and directories are removed.

Note: "-a" does not affect the admin-server files (yet).
Just after rpm install, /etc/dirsrv/admin-serv looks like this:
admserv.conf console.conf httpd.conf nss.conf

After setup-ds-admin.pl
adm.conf admserv.conf console.conf key3.db nss.conf
admpw cert8.db httpd.conf local.conf secmod.db

rpm --verify 389-admin

.....U.M. /etc/dirsrv/admin-serv
5S.T.U.M. c /etc/dirsrv/admin-serv/console.conf
......GM. /usr/lib64/dirsrv

After remove-ds-admin.pl -y -f -a
admserv.conf cert8.db console.conf httpd.conf key3.db nss.conf secmod.db

rpm --verify 389-admin

.....U.M. /etc/dirsrv/admin-serv
5S.T.U.M. c /etc/dirsrv/admin-serv/console.conf
......GM. /usr/lib64/dirsrv

With "-a", we can remove admin-serv/*db files, but it'd a little difficult to resume console.conf and nss.conf (if modified).


set default ticket origin to Community

Added initial screened field value.

Bug Description: While remove-ds.pl takes "-a" option to remove
all the directories and files generated by setup-ds.pl, the
corresponding remove-ds-admin.pl for the entire system including
the Admin Server does not support "-a" option.

Fix Description: This patch makes remove-ds-admin.pl support
"-a" option. Admin Server setup script setup-ds-admin.pl backs
up the original files admserv.conf, httpd.conf, nss.conf,
console.conf, cert8.db, key3.db and secmod.db in the bakup
directory. By passing "-a" to remove-ds-admin.pl, it removes
directory server instances belonging to the Admin Server and
restores the files backed up by setup-ds-admin.pl. If "-a" is
not passed, the above files remain in the config directory.

I think the /etc/dirsrv/admin-serv/bakup directory needs to be removed. Otherwise, if you do yum erase 389-* it won't remove /etc/dirsrv/admin-serv nor /etc/dirsrv. Can you verify that after running remove-ds-admin.pl -a -y , and running yum erase 389-*, the directories /etc/dirsrv, /var//dirsrv, and /usr//dirsrv are all gone?

Replying to [comment:8 rmeggins]:

I think the /etc/dirsrv/admin-serv/bakup directory needs to be removed. Otherwise, if you do yum erase 389-* it won't remove /etc/dirsrv/admin-serv nor /etc/dirsrv. Can you verify that after running remove-ds-admin.pl -a -y , and running yum erase 389-*, the directories /etc/dirsrv, /var//dirsrv, and /usr//dirsrv are all gone?

Thanks, Rich! "yum erase 389-*" does not remove the bakup dir. I modified removeAdminServer to remove the bakup dir in the remove phase.

BTW, "yum erase 389-*" is supposed to remove all the files/dirs under /usr/*/dirsrv and /etc/dirsrv? After the command line, I still see these dirs:
{{{

ls -R /usr/*/dirsrv

/usr/share/dirsrv:
manual

/usr/share/dirsrv/manual:
en

/usr/share/dirsrv/manual/en:
admin slapd

/usr/share/dirsrv/manual/en/admin:
help

/usr/share/dirsrv/manual/en/admin/help:

/usr/share/dirsrv/manual/en/slapd:
help

/usr/share/dirsrv/manual/en/slapd/help:

ls -R /etc/dirsrv

/etc/dirsrv:
admin-serv

/etc/dirsrv/admin-serv:
cert8.db console.conf.rpmsave key3.db secmod.db
}}}

Thanks to Rich for his comment. I've added the remove code to clean up the bakup directory when remove-ds-admin.pl is executed.

Reviewed by Rich (Thank you!!)

Pushed to master: commit cd9d6f19a2a2273d55f6ed18b1b8b292fa760838

Metadata Update from @nhosoi:
- Issue assigned to nhosoi
- Issue set to the milestone: 389-admin,console 1.1.31

7 years ago

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

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 (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata