Forum: Cfengine Help
Subject: Re: Redhat / Fedora / CentOS processes, services, and chkconfig nirvana
Author: msvob...@linkedin.com
Link to topic: https://cfengine.com/forum/read.php?3,21202,21205#msg-21205
Hey David
A point of detail: In lines 45-48 your wish is (I understand) to determine
whether the service is currently enabled or disabled. I think this can be
considerably simpler. The return code of a simple "/sbin/chkconfig foo"
indicates 0 or 1 for enable/disabled. Further, you can then use "noshell" in
your "returnszero":
"$(running_service_chkconfig)_on" expression => returnszero("/sbin/chkconfig
$(running_service_chkconfig)","noshell")
So I tried going this approach. Unfortunately, the class
$(running_service_chkconfig)_on would only get set if the service was "on" in
chkconfig.
If the service is "off", then it returns 1. The class is not raised. I think
I was having a problem with using ifvarclass to tie the statement down against
a class. If I tried to state the class implicitly, I was getting errors I
would try to then use the "not defined" class in the commands portion like:
# If we discoverd that this service should be disabled on boot, but chkconfig
has it on, then flip the switch.
"/sbin/chkconfig $(stopped_service_chkconfig) off"
ifvarclass =>
canonify("!$(stopped_service_chkconfig)_turn_off");
Note the !
For whatever reason, using ifvarclass to tie a statement down with a class that
contains a variable works, while defining it as :: didn't work for me. I
hit my head on it for a bit and then just left it at this. If you can get this
to work, that would be sweet because I would like the returnszero() functions
to not be so muddled.
2. Yours is also specifically for one type of OS. But I had in mind that the
"libservice.cf" (detailed process/chkconfig) subroutine library could itself
hide details of multiple OSes. The external calling of "service_config(s,
enable)" is potentially highly portable (we'd need to do a little more work).
The bundle interface would nicely isolate the higher-level sysadmin from the
nasty detail of each OS. The bundles themselves then implement multiple,
per-OS, details, perhaps in further sub-bundles.
After seeing what the complexity was involved in doing this, I think keeping
separate policies for the different O/S would be a good idea. Possibly, have a
base promise for each O/S, and then abstract service_config(s, enable) above
those promises as method calls could work. I'm going to be working on a
Solaris 10 SMF implementation after this.
If I modify a config file like ntp.conf in a different policy, then I just do
something like this:
file:
"/etc/ntp.conf"
copy_from =>
classes => if_repaired("some_class")
commands:
some_class.linux::
"/etc/init.d/ntpd restart"
some_class.sunos_5_10::
"svcadm restart ntpd"
Is it repeating some code? Yeah, sorta.. But from my perspective, restarting
a service after modifying a config file is a different operation than making
sure that services / processes which should be online are kept online. The
stuff that should be off, kept off.
Anyways, thanks for your response. I appreciated it. =)
Mike
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
