Hide Forgot
Description of problem: SELinux is permissive # setup-ds.pl [ accept default for all prompts ] Password: Password (confirm): Could not import LDIF file '/tmp/ldifKnoNLA.ldif'. Error: 256. Output: importing data ... Error - Problem accessing the lockfile /var/lock/dirsrv/slapd-rawhide/lock [03/Feb/2011:23:17:13 -0500] - Shutting down due to possible conflicts with other slapd processes Error: Could not create directory server instance 'rawhide'. Exiting . . . Log file is '/tmp/setupavP0P2.log' There are no other ns-slapd instances running. The directory /var/lock/dirsrv/slapd-rawhide is empty. drwxrwx---. 2 nobody nobody 40 Feb 3 23:17 /var/lock/dirsrv/slapd-rawhide/ Version-Release number of selected component (if applicable): 389-ds-base-1.2.8-0.1.a1.fc15.x86_64
I'm still trying to get a running rawhide. Can you run setup-ds.pl -ddd -l /tmp/mysetup.log ? Then attach mysetup.log, the output from running setup, the errors log from the server (if any), ls -al /var/run/dirsrv, and see if there are AVCs.
Also: ls -laZ /var/run/dirsrv ls -laZ /var/lock/dirsrv Who is your 389 instance supposed to run as? Was this a fresh rawhide system, or have you created 389 instance on it in the past and removed them? This could be an ownership issue if you have removed instances and created new ones who run as a different user/group. I like to remove /var/run/dirsrv, /var/lock/dirsrv, /var/log/dirsrv, and /var/lib/dirsrv on my development systems to ensure that these directories that are created when the first instance is created are cleaned up.
I haven't touched anything since the last failed setup-ds.pl (so some files/directories may still exist). I took all the defaults so the user is nobody. [root@rawhide rpm]# getenforce Permissive [root@rawhide rpm]# ls -laZ /var/run/dirsrv drwxrwxrwx. root nobody system_u:object_r:var_run_t:s0 . drwxr-xr-x. root root system_u:object_r:var_run_t:s0 .. [root@rawhide rpm]# ls -laZ /var/lock/dirsrv drwx------. pkisrv root unconfined_u:object_r:var_lock_t:s0 . drwxrwxr-x. root lock system_u:object_r:var_lock_t:s0 .. drwxrwx---. nobody nobody unconfined_u:object_r:var_lock_t:s0 slapd-rawhide [root@rawhide rpm]# rm -rf /var/run/dirsrv /var/lock/dirsrv /var/log/dirsrv /var/lib/dirsrv /etc/dirsrv/slapd-rawhide/ Doing this allowed the server to be installed and start. ldapsearch -x -b 'dc=example,dc=com' is successful. The error message was very misleading about what was the cause of the startup problems.
Rob, Should IPA do something like this: rm -rf /var/run/dirsrv /var/lock/dirsrv /var/log/dirsrv /var/lib/dirsrv /etc/dirsrv/slapd-rawhide/ in the uninstall script? Just to clean things up? Ok may be change permissions so that next install does not stumble on the files owned by the removed user. Is it worth a ticket?
(In reply to comment #3) > [root@rawhide rpm]# rm -rf /var/run/dirsrv /var/lock/dirsrv /var/log/dirsrv > /var/lib/dirsrv /etc/dirsrv/slapd-rawhide/ > > Doing this allowed the server to be installed and start. Could you check what the selinux context is on /var/run/dirsrv and /var/lock/dirsrv now? They should be dirsrv_var_run_t and dirsrv_var_lock_t.
I'd be curious to know what remove-ds.pl does. We rolled our own "remove DS" routines because at the time remove-ds.pl didn't exist. Even if we use remove-ds.pl we always want the whole instance to go away and it currently just renames is (not that it's wrong for their usage, just not right for ours). We pretty much stomp over anything we please so I'm generally inclined to doing this I just don't want to use my only tool (a hammer) without understanding the implications.
(In reply to comment #6) > I'd be curious to know what remove-ds.pl does. We rolled our own "remove DS" > routines because at the time remove-ds.pl didn't exist. Even if we use > remove-ds.pl we always want the whole instance to go away and it currently just > renames is (not that it's wrong for their usage, just not right for ours). The remove-ds.pl script does actually remove the instance files. The only stuff it leaves behind and renames is in /etc/dirsrv/slapd-instance. The reason for this is that we don't want to blow away someone's certificate database. We actually remove all contents of /etc/dirsrv/slapd-instance other than the certificate database and them append ".removed" to the directory name. The problem arises with directories that are shared by multiple instances, yet they are not owned by the 389-ds-base RPM. These directories are created by setup-ds.pl for the first instance that is created, so the ownership ends up matching the first instance. When a second instance is created, these directories already exist, but a second instance needs to have the same group specified at creation time. I suppose the ideal thing to do would be to have remove-ds.pl remove these shared directories when the last instance is removed. These directories I'm referring to are: /var/lib/dirsrv /var/lock/dirsrv /var/log/dirsrv /var/run/dirsrv
Upstream ticket: https://fedorahosted.org/389/ticket/65