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".
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?
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! :)
Can you attach the directory server errors log? /var/log/dirsrv/slapd-INST-NAME/errors
Nathan, do you know which selinux directive takes care of /var/lock/dirsrv?
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
(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?
/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
(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.
It looks like we may just need to add the following to the dirsrv policy: files_read_var_symlinks(dirsrv_t)
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
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
How about restorecon -R -v /var
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'
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.
Looks like things are fixed in the Gold DVD image... thanks for all the help everyone!