When removing the last instance of 389, we should clean up /var/lock/dirsrv, and maybe other directories like this(/var/run/dirsrv, etc), because if you create a DS instance running as a different user than the previous instance, these "old" directories remain, and prevent a new server instance from being created.
To reproduce:
[1] run setup-ds.pl and specify "nobody" as the user and group for the server instance. [2] run remove-ds.pl [3] Create a user and group called "dirsrv" [4] run setup.pl and specify "dirsrv" as the user and group [5] setup fails.
Hitting that issue, I used 'chmod o+rwx /var/lock/dirsrv' as a temporary workaround
Record failure logs to retrieve this ticket
{{{ Could not import LDIF file '/tmp/ldif1Fo7FQ.ldif'. Error: 256. Output: importing data ... Error - Problem accessing the lockfile /var/lock/dirsrv/slapd-master/lock [19/Jul/2013:19:14:03 +0200] - Shutting down due to possible conflicts with other slapd processes
Error: Could not create directory server instance 'master'. Exiting . . . }}}
nack - you can't remove /var/lib/dirsrv, /var/log/dirsrv, or /var/lock/dirsrv because they are owned by the package/rpm: 389-ds-base.spec %files ... %dir %{_localstatedir}/lib/%{pkgname} %dir %{_localstatedir}/log/%{pkgname} %dir %{_localstatedir}/lock/%{pkgname}
Replying to [comment:6 rmeggins]:
They are recreated when I create a new instance.
So you are saying that once you install an instance as "testuser" you must always use testuser for the entire lifetime of the package? Meaning the only option is to completely remove 389-ds-base package, and readd the package if you want a fresh instance to run as a different user.
Replying to [comment:7 mreynolds]:
Replying to [comment:6 rmeggins]: nack - you can't remove /var/lib/dirsrv, /var/log/dirsrv, or /var/lock/dirsrv because they are owned by the package/rpm: 389-ds-base.spec %files ... %dir %{_localstatedir}/lib/%{pkgname} %dir %{_localstatedir}/log/%{pkgname} %dir %{_localstatedir}/lock/%{pkgname} They are recreated when I create a new instance. So you are saying that once you install an instance as "testuser" you must always use testuser for the entire lifetime of the package?
So you are saying that once you install an instance as "testuser" you must always use testuser for the entire lifetime of the package?
Are you saying that if a directory is owned by user "testuser" the only way to avoid having to use testuser forever is to remove the directory and recreate it?
Meaning the only option is to completely remove 389-ds-base package, and readd the package if you want a fresh instance to run as a different user.
Those are my only choices?
Replying to [comment:8 rmeggins]:
Replying to [comment:7 mreynolds]: Replying to [comment:6 rmeggins]: nack - you can't remove /var/lib/dirsrv, /var/log/dirsrv, or /var/lock/dirsrv because they are owned by the package/rpm: 389-ds-base.spec %files ... %dir %{_localstatedir}/lib/%{pkgname} %dir %{_localstatedir}/log/%{pkgname} %dir %{_localstatedir}/lock/%{pkgname} They are recreated when I create a new instance. So you are saying that once you install an instance as "testuser" you must always use testuser for the entire lifetime of the package? Are you saying that if a directory is owned by user "testuser" the only way to avoid having to use testuser forever is to remove the directory and recreate it?
It can not keep the testuser ownership. But I'm not sure there is a way to know what ownership it should be set to.
At package install only /var/log/dirsrv is created. /var/lock/dirsrv/, /var/lib/dirsrv/, and /var/run/dirsrv are only created when the first instance is created. So I saw no harm in removing them(except for /var/log/dirsrv)
Meaning the only option is to completely remove 389-ds-base package, and readd the package if you want a fresh instance to run as a different user. Those are my only choices?
Replying to [comment:9 mreynolds]:
Replying to [comment:8 rmeggins]: Replying to [comment:7 mreynolds]: Replying to [comment:6 rmeggins]: nack - you can't remove /var/lib/dirsrv, /var/log/dirsrv, or /var/lock/dirsrv because they are owned by the package/rpm: 389-ds-base.spec %files ... %dir %{_localstatedir}/lib/%{pkgname} %dir %{_localstatedir}/log/%{pkgname} %dir %{_localstatedir}/lock/%{pkgname} They are recreated when I create a new instance. So you are saying that once you install an instance as "testuser" you must always use testuser for the entire lifetime of the package? Are you saying that if a directory is owned by user "testuser" the only way to avoid having to use testuser forever is to remove the directory and recreate it? It can not keep the testuser ownership. But I'm not sure there is a way to know what ownership it should be set to.
Can't setup-ds set/change the ownership when a new instance is created?
Ok. If you remove them, you'll need to test what happens when these directories don't exist, and you do a rpm removal, or an rpm upgrade.
Replying to [comment:10 rmeggins]:
Replying to [comment:9 mreynolds]: Replying to [comment:8 rmeggins]: Replying to [comment:7 mreynolds]: Replying to [comment:6 rmeggins]: nack - you can't remove /var/lib/dirsrv, /var/log/dirsrv, or /var/lock/dirsrv because they are owned by the package/rpm: 389-ds-base.spec %files ... %dir %{_localstatedir}/lib/%{pkgname} %dir %{_localstatedir}/log/%{pkgname} %dir %{_localstatedir}/lock/%{pkgname} They are recreated when I create a new instance. So you are saying that once you install an instance as "testuser" you must always use testuser for the entire lifetime of the package? Are you saying that if a directory is owned by user "testuser" the only way to avoid having to use testuser forever is to remove the directory and recreate it? It can not keep the testuser ownership. But I'm not sure there is a way to know what ownership it should be set to. Can't setup-ds set/change the ownership when a new instance is created?
Depends what user is doing the setup. It's possible, but unlikely, it might not have permission to do so. If you do it during the removal, we know that user can make such changes.
At package install only /var/log/dirsrv is created. /var/lock/dirsrv/, /var/lib/dirsrv/, and /var/run/dirsrv are only created when the first instance is created. So I saw no harm in removing them(except for /var/log/dirsrv) Ok. If you remove them, you'll need to test what happens when these directories don't exist, and you do a rpm removal, or an rpm upgrade.
Ok, I'll test this.
Only /var/lock/dirsrv, and /var/run/dirsrv needed to be removed. Tested removing rpm on rhel and fedora 19 after removing the last instance.
New patch is attached.
Revision #2 0001-Ticket-47394-remove-ds.pl-should-remove-var-lock-dir.patch
Turns out /var/lib/dirsrv also needs to be removed.
git merge ticket47394 Updating 52f7906..56441c3 Fast-forward ldap/admin/src/scripts/DSCreate.pm.in | 14 ++++++++++++-- 1 files changed, 12 insertions(+), 2 deletions(-)
git push origin master Counting objects: 13, done. Delta compression using up to 4 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (7/7), 1007 bytes, done. Total 7 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 52f7906..56441c3 master -> master
commit 56441c3 Author: Mark Reynolds mreynolds@redhat.com Date: Fri Aug 23 12:17:57 2013 -0400
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1044160
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.2 - 09/13 (September)
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/731
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.