|
Hi Gordon,
hi William, Your input was substantial and helped me a lot. I couldn't find the exact root cause since I've done a few things at the same time, but the problem is gone. Here's what I have done: - I noticed that a puppet agent tried to change the SELINUX config setting to "permissive" during my test with "enforcing". So, puppet agent is now disabled and its configuration will be reviewed to be sure that there is no conflict once it will be reenabled. - Actually, for some reason port389 user did belong to dirsrv group ( may be a side effect of puppet, not fully verified yet, but user/group configuration is cleaned up now ) - port389 user and port389 group are customer defined users and not part of any distro - there were old files /etc/tmpfiles.d/dirsrv* belonging to no longer existing DS instances potentially causing a conflict - nsslapd-localuser: port389 ( that's OK and what the customer wants ) - I had done a FS relabel awhile ago when I changed the SELINUX config setting from "disabled" to "permissive". To be sure, I relabeled the FS again, so this should be fine now. ( touch ./autorelabel; reboot ) - ausearch -ts recent | fgrep -i avc helped me to verify that a configuration change of SELINUX was really requested: Looked like "type=USER_AVC.....received setenforce notice" message Thanks and best regards, Lutz On 08/04/16 00:57, William Brown wrote: On Thu, 2016-04-07 at 15:33 -0700, Gordon Messmer wrote:On 04/07/2016 08:35 AM, Lutz Berger wrote:Changing the SELINUX setting from "permissive" to "enforcing" and rebooting afterwards causes port389 DS fail to start due to a permission problem of /var/run/dirsrv Interestingly, the ownership of /var/run/dirsrv changed from port389:port389 to dirsrv:dirsrv after reboot.Just to check the obvious, those users have different UIDs on the system, right? SELinux isn't related to the ownership of files in /run (the target of the /var/run symlink). Those files ownership are defined in /etc/tmpfiles.d/* If the ownership of that directory changed, then you may have conflicting definitions in /etc/tmpfiles.d, or someone may have made an unrelated change that replaced or modified those files. I'm confident that whatever broke your system was not the change from permissive to enforcing mode in SELinux.But, changing the ownership and permissions on the /var/run/dirsrv ( which is actually nsslapd-rundir ) back to its original value, doesn't help, i.e. port389 DS doesn't start anymore. A fresh install with setup-ds-admin.pl "solves" my issues.That being the case, there probably were more ownership changes than you've described.I missed this part of the email it would seem. You should check who the dirsrv process user is in dse.ldif, because that may still have the old port389 user listed rather than dirsrv. dn: cn=config nsslapd-localuser: USERNAME That would certainly cause issues if the other uid/gid permissions of the FS has changed around you. However, I would like to know what distro / versions you are running? I'm not aware of a distro that ships a port389 user. Historically DS ran as nobody:nobody, and only recently swapped to dirsrv:dirsrv. |
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
