On Wed, Jun 29, 2016 at 6:12 AM, David Sommerseth
<[log in to unmask]> wrote:
> On 29/06/16 10:00, Bill Maidment wrote:
>> My final attempt was successful, sort of.
>> I switched SElinux to enabled and rebooted, then the install worked OK.
>> Then I had to use a live CD to be able to boot, changed SElinux to disabled, and reboot again.
>> Then I had to us lpoptions to set the default parameters as the CUPS gui tool refused to change anything.
>> Phew. What a tortuous route.
>> Back to sleep now.........
>
> <rant>
>
> Let this be an example why NOT to disable SELinux.  SELinux has been (if
> my memory serves me right) available since Fedora 6 (released in 2006)
> and RHEL *4*!  I believe it was turned on by default in Fedora 8 and
> RHEL 5.  And in RHEL 6 you could no longer disable SELinux at install time.

It's a reason to set it to "permissive" and check the logs. And yes,
SELinux remains a problem with locally developed, thirdparty, and even
default upstream software. I'm afraid the amount of time wasted
debugging it frequently even usually, outweighs the security benefits.

> SELinux is not the obstacle it once was over a decade ago.  So if you
> have issues when it is enabled, learn to use the proper tools to debug
> and fix it correctly.  (audit2why, audit2allow, semanage, restorecon,
> etc, etc)

Until and unless you use something that is not from an RHEL or
Scientific Linux published RPM that has gone through real QA.

> Disabling SELinux is in 2016 *not* a solution and can barely be
> considered a workaround.
>
> Refusing to to use, accept and learn SELinux will serve you no good in
> the long run.

See above. Security is a trade-off between trouble saved by having
security, and caused by the security itself.

> Seriously, I've been running a various amount of Fedora, RHEL/SL/CentOS
> installations and versions over the last 8-9 years.  In SL7 SELinux have
> not bitten me much at all (only one issue with logrotate on servers
> running Zimbra Collaboration Suite, that's all).   I have the last 6-7
> years never needed to disable SELinux to accomplish my tasks.  Yes, I've
> put systems into permissive modes to see if SELinux was to blame, but
> mostly that was not the issue.

It's gotten better. As soon as you start hand-compiling servers for
development reasons, or start writing your own RPM's, it starts
costing serious engineering time.

> So if you are badly hit by SELinux troubles, you need to look into if
> you or the software you use are doing the right things.
>
> </rant>

Permissive is your friend. Disabled can cause its own problems.