Bug 531061

Summary: After Fedora 11 upgrade (from 1.2.1 to 1.2.2) IPA service didn't start after reboot
Product: [Retired] 389 Reporter: Stefan Freyr Stefansson <stefan.freyr>
Component: Install/UninstallAssignee: Nathan Kinder <nkinder>
Status: CLOSED CURRENTRELEASE QA Contact: Chandrasekar Kannan <ckannan>
Severity: medium Docs Contact:
Priority: high    
Version: 1.2.1CC: benl, rmeggins
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-01-15 16:02:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 543590    

Description Stefan Freyr Stefansson 2009-10-26 18:31:13 UTC
Description of problem:
After performing an upgrade from IPA v1.2.1 to v1.2.2 on a Fedora11 box, the dirsrv stopped starting properly after rebooting the system. This led to the krb5kdc service not starting properly either.

Version-Release number of selected component (if applicable):
Version 1.2.2 displayed this problem.

Actual results:
The dirsrv service failed to start at boot time with the following error:
[16/Oct/2009:20:04:42 +0000] - Unable to access nsslapd-rundir: Permission denied
[16/Oct/2009:20:04:42 +0000] - Ensure that user "dirsrv" has read and write permissions on /var/run/dirsrv

Expected results:
The dirsrv service should have started up properly.

Additional info:
After the system had started up (which took a very long time since the dirsrv and krb5kdc services hung for a long time) the services could be started up as root:
service dirsrv restart
service krb5kdc restart

Workaround:
Changing the ownership of the /var/run/dirsrv/ directory solved this problem for me:
chown dirsrv:dirsrv /var/run/dirsrv

Comment 3 Rich Megginson 2009-12-02 17:36:23 UTC
Do you know what version of 389 or fedora-ds-base was installed prior to the upgrade?  What version of 389-ds-base did the system upgrade to?
rpm -qi 389-ds-base

Earlier versions of fedora-ds-base and 389-ds-base had problems in that upgrading the rpm would overwrite the ownership and permissions on /var/run/dirsrv - newer versions do not do this - so it's important to know what versions show this problem, to see if perhaps 
1) the original problem is still not fixed
2) there is a new problem that has the same/similar symptoms

Comment 4 Rich Megginson 2010-01-15 04:08:33 UTC
ping

Comment 5 Stefan Freyr Stefansson 2010-01-15 08:39:41 UTC
I'm afraid I don't know which version _was_ installed but the version I upgraded to is:

[root@ipa ~]# rpm -qi 389-ds-base
Name        : 389-ds-base                  Relocations: (not relocatable)
Version     : 1.2.2                             Vendor: Fedora Project
Release     : 1.fc11                        Build Date: Tue 25 Aug 2009 08:07:37 PM GMT
Install Date: Fri 16 Oct 2009 07:56:52 PM GMT      Build Host: x86-5.fedora.phx.redhat.com
Group       : System Environment/Daemons    Source RPM: 389-ds-base-1.2.2-1.fc11.src.rpm
Size        : 5287485                          License: GPLv2 with exceptions
Signature   : RSA/SHA1, Wed 26 Aug 2009 11:56:53 AM GMT, Key ID 1dc5c758d22e77f2
Packager    : Fedora Project
URL         : http://port389.org/
Summary     : 389 Directory Server (base)
Description :
389 Directory Server is an LDAPv3 compliant server.  The base package includes
the LDAP server and command line utilities for server administration.

Hope this helps.

- Stefan

Comment 6 Rich Megginson 2010-01-15 16:02:32 UTC
I'm pretty sure this was fixed in fedora-ds-base 1.2.0 as part of https://bugzilla.redhat.com/show_bug.cgi?id=430368
or
https://bugzilla.redhat.com/show_bug.cgi?id=432135

I'm not sure what happened in your case.  The rpm only touches /var/run/dirsrv if it does not exist.  The setup-ds.pl script will change the permission and ownership to match your server, but that's only run at setup time, usually only when creating a new directory server instance.

I'm going to file this as closed/currentrelease - if the problem persists or is reproducible, please reopen.