McAfee, RHEL7 and systemd
 

I'm writing this up to share my experience with this.

We finally deployed a RHEL7 x86_64 in our production environment and when installing all of the 3rd party software, like McAfee, its dependent on init.d to work, not systemd.

This sort of surprised me however alot of vendors may not be ready to convert their software over to work with systemd. So looks like Linux OS that run with systemd will have to support both systemd and init.d for a period of time.

Just wondering what other folks experience is with this.

thanks

Actually while this is true there are things in Systemd that will try to convert init scripts to systemd scripts after reboots that might bite you in the posterior. On first reboot after installing something with an init script it does the conversion. On the next reboot after that it tries to run using Systemd script. This latter can fail if the former didn't work properly. That can occur because the init script is sometimes a link to the 3rd party software's install directory which Systemd can't execute on boot.

A good write up of this for a NetBackup application is:
https://www.veritas.com/support/en_US/article.000126536

Note that talks about CentOS7 rather than RHEL7 but it is the same idea as CentOS7 is compiled from RHEL7 sources.

I didn't know that systemd will try to convert init scripts. How do you check for this? I know the basics of systemd, haven't done a deep dive yet.

Thanks for sharing you experience with this.

a sysvinit compatibility layer exists for systemd, and is in use on e.g. debian jessie (this version was most affected by the switch).

in the end it depends on what exactly mcafee is doing with these init scripts.
maybe it's just a simple start script, trivial to translate (manually rewrite) to a systemd service.

so instead of (yet another) philosophical discussion about init systems, let's try to actually solve the technical problem?

I'm trying to get a better understanding of systemd, in order to solve any current and future tech problems and not wanting to fight init.d Vs systemd. I don't know why your interpreting my question as drama unless your trying to start it.

I, too, am still working to wrap my head around the systemd way of doing things.
I don't have it yet, and have to go to the 'net for help...soon, I hope.

Putting "systemd init script" into DDG yields many examples and discussions of how to accomplish starting things "the systemd way" -- In general, it appears to be very similar to init.d:
Create a script
Put it in the proper location
Use systemctl to "make it so"

As I said, I don't yet have what it takes to be specific. Try that search string...

yet you chose not to react to the technical part of my answer, the one that might help you to "get a better understanding".

i'm really not quite sure what you're asking here; is there a technical problem you need solving, or are you just asking us to look up some links for you?
fwiw, this is worth gold: https://wiki.archlinux.org/index.php/Systemd
but i'm sure RHEL have something similarly high standard.

From the main webpage.

I read ondoho's post in #4 as an attempt to avoid drama...not to create it.

Thank you, ondoho, for the excellent reference re: systemd -- it's just a new thing to learn, and I've been doing that in "data processing" and IT for nearly 50 years(!)

"The only thing constant in the universe is change."

systemd is YAIS (Yet Another Init System) that you have to deal with. Because systemd is backwards compatible with init.d, why change?

Also, I find that systemd is not as powerful as init.d. So if you want to do anything tricky, you can't. For example, the NFS init.d script checks if your /etc/exports file is empty. If it is, it doesn't bother starting nfsd... a really nice feature for those of us who need NFS once in a blue moon. systemd can't do this and just starts nfsd if enabled.

For those trying to work with systemd... the first thing you have to wrap your mind around is that disable does not mean disable. It really means something like don't auto start. It will still let other programs start the service. You almost always want mask rather than disable. It took me a while to understand why a disabled service kept running :(

That is wrong on a couple of levels.

Firstly YOU can make systemd conditional on whatever YOU want. By default it may not check for empty /etc/exports on your distro but if YOU desire that you can modify the behavior in YOUR systemd setup. systemd is meant to be modular and fast so there may be things that sysvinit did by default that systemd doesn't because of choices made to increase its speed.

Secondly there is no need for /etc/exports to be populated before you start nfs server. You can populate it after the fact then run exportfs -a to have it recognize your additions. If it didn't work like this you'd have to restart NFS every time you edited /etc/exports which might cause problems for things using previously exported filesystems.

I couldn't find a way to do that. And while I am marginally curious... in systemd's defense once I understood that it was short-circuiting the init.d file, I was able to configure systemd to let the init.d file work as normal. So this is a solved problem.

I don't think you understood what the init.d file is trying to do, and that is probably my fault. I meant this to be a simple example.

You can look at the init.d file for nfsd. I believe many (most?) systemd systems still ship with the nfsd init.d script. The idea is to NOT run nfsd unless you actually need it. There are security reasons, if nothing else, why you may not want nfsd running. Really it only saves you the extra steps of disabling and enabling the service... but it has been the default behavior for at least 18 years (probably longer) and I was surprised that systemd didn't have it by default.

I doubt it was done for speed; reading one exports file will not affect boot times. I can understand that it might be a documentation issue. i.e. It is much easier to document the systemd behavior than the init.d one.

if in some situations it (systemd? nfs? the distro?) defaults to simply start it regardless, that might be a reason for criticism.

but i'm pretty sure this is possible with systemd.

are you talking about checking /etc/exports once at startup, or continuously? tbh, the latter wouldn't make much sense to me, and the former either because i have never heard that /etc/exports changes without manual admin intervention.

anyhow, isn't sysvinit executing shell scripts?
so anything that the shell can do, the init system can also do?
that is still possible with systemd - a service file can point to a shell script.

i'm not saying systemd is better than sysvinit, just trying to clarify things. debunking.

McAfee on RHEL is horrible, if you want to know how horrible, put it on your build server and see build times doubling :-)

and I wonder what security it actually should add,
there is a RHEL system, and than you put some proprietary service on it which value is in best case doubtable.
no one knows what this software intercepts, which security is weakens, if it has backdoors, ....

and MacCafe depends on more than just a service, it adds it self to cron, the one in etc, that one from root
and it has 2 services cma and ma (ma and nails) which you can query with systemctl

systemctl status cma
systemctl status ma

you can stop/enable/disable this services via systemctl, so at least it seams there is some co-operation via/with systemd.