Bug 704889 - ipa-server-install hangs forever
ipa-server-install hangs forever
Status: CLOSED CURRENTRELEASE
Product: freeIPA
Classification: Community
Component: ipa-server (Show other bugs)
2.0
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Rob Crittenden
Chandrasekar Kannan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-15 15:24 EDT by Matt Mossholder
Modified: 2015-01-04 18:48 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-25 08:24:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Mossholder 2011-05-15 15:24:01 EDT
Description of problem:
On a clean install of F15, with all current updates, running ipa-server-install never moves past  phase 2/3 when configuring the directory server. Disabling selinux enforcement resolves the issue.

Version-Release number of selected component (if applicable):
freeipa-server-2.0.1-1.fc15.x86_64
selinux-policy-3.9.16-23.fc15.noarch

How reproducible:
Always

Steps to Reproduce:
1. Install F15.
2. yum upgrade
3. yum install freeipa-server
4. ipa-server-install
  
Actual results:
Installation never moves past step 2/3 while installing the directory server.

Expected results:
Installation completes

Additional info:
I believe the issue is that the dirsrv does not have SELinux permissions to create a lock file in /var/lock/dirsrv . This causes the startup of the dirsrv after the data imports to fail with "Shutting down due to possible conflicts with other slapd processes".
Comment 1 Rob Crittenden 2011-05-16 10:01:43 EDT
What version of selinux-policy do you have installed?

Can you provide a copy of the AVC for this from /var/log/audit/audit.log?
Comment 2 Matt Mossholder 2011-05-16 10:26:55 EDT
selinux-policy-3.9.16-23.fc15.noarch

The offending avc is:

type=AVC msg=audit(1305481336.431:71): avc:  denied  { read } for  pid=2927 comm="ns-slapd" name="lock" dev=dm-1 ino=1330 scontext=unconfined_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=lnk_file

(note: AVC transcribed by hand.. all typos are surely mine! :)
Comment 3 Rich Megginson 2011-05-16 10:29:10 EDT
Can you attach the directory server errors log?  /var/log/dirsrv/slapd-INST-NAME/errors
Comment 4 Rich Megginson 2011-05-16 10:29:52 EDT
Nathan, do you know which selinux directive takes care of /var/lock/dirsrv?
Comment 5 Matt Mossholder 2011-05-16 12:33:33 EDT
It never ends up getting as far as creating a /var/log/dirsrv/slapd-INST-NAME directory. It hangs on dealing with the initial /var/log/dirsrv/slapd-PKI-IPA instance.

Here is the error log in the PKI-IPA instance:

	389-Directory/1.2.8.3 B2011.122.1634
	ipatest.mossholder.com:7389 (/etc/dirsrv/slapd-PKI-IPA)

[16/May/2011:12:25:11 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database
[16/May/2011:12:25:11 -0400] - check_and_set_import_cache: pagesize: 4096, pages: 255875, procpages: 48443
[16/May/2011:12:25:11 -0400] - WARNING: After allocating import cache 409400KB, the available memory is 614100KB, which is less than the soft limit 1048576KB. You may want to decrease the import cache size and 
rerun import.
[16/May/2011:12:25:11 -0400] - Import allocates 409400KB import cache.
[16/May/2011:12:25:11 -0400] - import userRoot: Beginning import job...
[16/May/2011:12:25:11 -0400] - import userRoot: Index buffering enabled with bucket size 100
[16/May/2011:12:25:12 -0400] - import userRoot: Processing file "/tmp/ldifZdh54T.ldif"
[16/May/2011:12:25:12 -0400] - import userRoot: Finished scanning file "/tmp/ldifZdh54T.ldif" (9 entries)
[16/May/2011:12:25:12 -0400] - import userRoot: Workers finished; cleaning up...
[16/May/2011:12:25:12 -0400] - import userRoot: Workers cleaned up.
[16/May/2011:12:25:12 -0400] - import userRoot: Cleaning up producer thread...
[16/May/2011:12:25:13 -0400] - import userRoot: Indexing complete.  Post-processing...
[16/May/2011:12:25:13 -0400] - import userRoot: Flushing caches...
[16/May/2011:12:25:13 -0400] - import userRoot: Closing files...
[16/May/2011:12:25:13 -0400] - All database threads now stopped
[16/May/2011:12:25:13 -0400] - import userRoot: Import complete.  Processed 9 entries in 2 seconds. (4.50 entries/sec)
[16/May/2011:12:26:21 -0400] - Shutting down due to possible conflicts with other slapd processes
Comment 6 Nathan Kinder 2011-05-17 11:48:47 EDT
(In reply to comment #4)
> Nathan, do you know which selinux directive takes care of /var/lock/dirsrv?

The policy states that the contents of /var/lock/dirsrv should be labeled as dirsrv_var_lock_t:

[root@localhost ds]# semanage fcontext -l | grep dirsrv_var_lock_t
/var/lock/dirsrv(/.*)?                             all files          system_u:object_r:dirsrv_var_lock_t:s0

This dirctory is created by setup-ds.pl, which then runs restorecon to ensure that it is labeled properly.  The policy has the following macro to allow us to use the lock files:

files_lock_file(dirsrv_var_lock_t)

I believe that the problem may have to do with /var/lock being a symlink.  The AVC is stating that ns-slapd does not have permission to read a symlink named "lock" that is labeled as var_t.  Is /var/lock a symlink?  Does /var/lock/dirsrv exist?  What does "ls -lZ" on each of these paths show?
Comment 7 Matt Mossholder 2011-05-17 15:48:03 EDT
/var/lock is a symlink to ../run/lock. This isn't something I modified, it is that way in the standard build. /var/run/lock/dirsrv does exist, and is accessible via the /var/lock/dirsrv symlink.

Here's the ls -lZ:

lrwxrwxrwx. root root system_u:object_r:var_t:s0       /var/lock   ->  ../run/lock
Comment 8 Nathan Kinder 2011-05-17 17:55:58 EDT
(In reply to comment #7)
> /var/lock is a symlink to ../run/lock. This isn't something I modified, it is
> that way in the standard build. /var/run/lock/dirsrv does exist, and is
> accessible via the /var/lock/dirsrv symlink.
> 
> Here's the ls -lZ:
> 
> lrwxrwxrwx. root root system_u:object_r:var_t:s0       /var/lock   -> 
> ../run/lock

This symlink is a new thing in F15.  It is possible that there is a new SELinux macro that needs to be used in F15 to allow dirsrv_t read access to lnk_file targets with a var_t context.  It also might be possible that the files_lock_file() macro needs to be changed for this to work.

I'd like to see what Dan Walsh recommends.
Comment 9 Nathan Kinder 2011-05-17 17:59:21 EDT
It looks like we may just need to add the following to the dirsrv policy:

  files_read_var_symlinks(dirsrv_t)
Comment 10 Daniel Walsh 2011-05-18 02:05:55 EDT
Are you sure you have the latest policy installed

/var/lock should be labeled var_lock_t.   

# yum -y update selinux-policy-targeted
# restorecon -v /var/lock
# ls -Z /var/lock
Comment 11 Matt Mossholder 2011-05-18 08:44:17 EDT
selinux-policy-targeted-3.9.16-23.fc15.noarch is what is installed. I rebuilt the system from the ground up yesterday to ensure I had a good copy of the errors log for the PKI-IPA instance of the dirsrv, and had run 'yum upgrade' prior to installing freeipa-server. So, unless I need to run restorecon after doing the upgrade 'yum upgrade', everything should be as you would expect...

After running 'yum -y update selinux-policy-targeted' and 'restorecon -v /var/lock', the output of ls -lZ /var/lock is the same:

lrwxrwxrwx. root root system_u:object_r:var_t:s0       /var/lock   ->  ../run/lock
Comment 12 Daniel Walsh 2011-05-24 14:00:23 EDT
How about restorecon -R -v /var
Comment 13 Matt Mossholder 2011-05-24 18:38:25 EDT
That MAY have done it, after a 'yum upgrade' today,  but I am experiencing more errors further down the line. I'm going to rebuild the VM, do a 'yum upgrade', take a snapshot, and then try the install again. If that doesn't work, I'll rollback the snapshot and try after a 'restorecon -R -v /var'
Comment 14 Matt Mossholder 2011-05-24 22:11:05 EDT
My results were:

Clean install F15Beta, yum upgrade, yum install freeipa-server, ipa-server-install:
FAIL

Clean install F15Beta, yum upgrade, yum install freeipa-server, ipa-server-install, restorecon -R -v /var:
SUCCESS

I'll download and reinstall with an F15 Gold DVD image. I'm hoping that this was fixed in the final F15, and the issue was just that the correct selinux context wasn't applied.
Comment 15 Matt Mossholder 2011-05-25 08:24:25 EDT
Looks like things are fixed in the Gold DVD image... thanks for all the help everyone!

Note You need to log in before you can comment on or make changes to this bug.