I’m not all that conversant with SELinux, and for the most part, disable it on systems that I configure simply because these days 99% of the systems I configure are within a lab and already heavily firewalled. When NetWorker 7.5 came out and the release notes explicitly stated that SELinux was not supported, it seemed inevitable that my involvement with SELinux would continue to decrease.
When SELinux was recently discussed on the NetWorker mailing list, I responded citing the release notes indicating it wasn’t supported. I was therefore surprised to discover there was a workaround. Responding to the thread, Rich Graves posted the following SELinux adjustments that are necessary to get NetWorker and SELinux working together. I present them unaltered, but can attest to having confirmed they do indeed work. Here’s what Rich had to say:
This has worked for me for about a year, on both client and server. The textrel_shlib change is fairly common for proprietary binaries.
semanage fcontext -a -t textrel_shlib_t “/usr/lib/nsr(/.*)?”
semanage fcontext -a -t var_log_t “/nsr/logs(/.*)?”
restorecon -R /usr/lib/nsr
restorecon -R /nsr/logsAnother approach for the logs is to edit syslog.conf and drop them in /var/log instead of /nsr/logs.
If you’re needing to work with NetWorker and SELinux, hopefully the above tips will help.
I wonder what implications this would have for support, once you go against what the release notes recommend.
Going against the release notes recommend is never a decision that should be taken lightly. However, like it or not SELinux is becoming increasingly popular, particularly in high-security environments. There’s two factors that come into play here, I think:
(a) EMC have been made aware that the changes suggested by Rich Graves work. By EMC, I’m referring to NetWorker product management. Hopefully that will see an update to documentation or qualification.
(b) You can still get support on an unsupported configuration if you can prove the exact same problem happens on a supported configuration. For instance, SELinux can be turned off with a simple configuration file change and a reboot. So if you can temporarily disable SELinux and prove a problem is still happening, you can eliminate the non-supported configuration from the problem. Alternatively, if your support provider can reproduce the problem without SELinux, there’s grounds for an escalation.
In a lot of instances as well, it’s worthwhile remembering that ‘not supported’ can also mean ‘not qualified’. I’m not trying to recommend crazy configurations here (e.g., backing up ZFS filesystems mounted on Banyan Vines servers using v3 of the NetWorker client), but rather, just run-of-the-mill configurations that are less common and so have not yet been tested yet by EMC in their labs…