On Tue, May 25, 2010 at 07:46:56PM -0500, Les Mikesell wrote: > I would have looked at selinux first for any "odd failure", but I thought it > related to the process itself and couldn't see any way that the process would be > different when started as "sh /etc/init.d/smb restart" than simply > /etc/init.d/smb restart. Is it? That selinux would prevent a normal init.d startup of a common daemon like smbd, but allow the same startup in several other ways ... okay, I've never studied selinux. I usually run Ubuntu on servers. I've pretty much literally inherited a bunch of RH-based servers to admin (coworker sadly died), and we're adding more to run in parallel, so CentOS was obvious (RH-the-firm being so badly run it took staff days over the phone just to buy a single new license from them). Of course AppArmour can also get in the way, but at least it logs such actions, so it's obvious if you need to reconfig or turn it off. I'm solidly impressed with this list. Nothing like it for Ubuntu, and back when Gentoo was my preferred server distro there was more noise surrounding that too. It shows that the interest in CentOS is entirely professional. So that's a strong upside. But if someone can tell me why selinux thinks it's sane to block "/etc/init.d/smb start" while leaving "sh /etc/init.d/smb start" and even /some/random/dir/smb start" wide open ... I just can't believe some happy hacker at NSA thought that would count as a security scheme. Really, I'd like to know how this is supposed to be useful. Whit