Thursday, April 7, 2016

[389-users] Re: Change of /etc/selinux/config's SELINUX causes port389 fail to start

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 "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.


William Brown
Software Engineer
Red Hat, Brisbane

No comments:

Post a Comment