#47394 remove-ds.pl should remove /var/lock/dirsrv
Closed: Fixed None Opened 6 years ago by mreynolds.

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]:

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? 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?

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?

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.

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: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.

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?

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.

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

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.2 - 09/13 (September)

2 years ago

Login to comment on this ticket.

Metadata