Forum: Cfengine Help
Subject: Re: Redhat / Fedora / CentOS processes, services, and chkconfig nirvana
Author: davidlee
Link to topic: https://cfengine.com/forum/read.php?3,21202,21204#msg-21204
Many thanks for this, and for inviting comment.
Disclaimer: I'm a newcomer to version-3 of cfengine (although have a few years
cf-2 behind me). So what follows may need adjustment.
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":
... expression => returnszero("/sbin/chkconfig
$(running_service_chkconfig)","noshell")
Overall, I have been trying to do a similar thing myself in recent days, so it
is greatly re-assuring to me (as a newcomer) to see that you have come up with
something similar. Flowing from that, a few general points:
1. Yours is shaped towards one overall entity that defines and controls a the
process aspect across a set of services. I took a different approach. Many
such services will have additional things to be done, such as maintaining an
associated config file. So my overall structure separated out the service
definitions from the detailed process/chkconfig of services. I ended up with a
smaller, but general purpose "libservice.cf" with the detailed
process/chkconfig instructions for a single service, which is an argument:
bundle agent service_config(s, enable) {...}
bundle agent service_run(s, enable) {...}
This is supplemented by multiple, per-service ".cf" files. (in your example,
you might have "ntpd.cf", "mdadm.cf", "atd.cf" and "abrtd.cf") which would
encapsulate the overall state of the service, including the detailed editing of
the config file, and would control their respective processes with clauses such
as:
methods:
any::
"any" usebundle => service_config("ntpd", "1"));
"any" usebundle => service_run("ntpd", "1");
(If you don't like one-file-per-service, you could still keep them in a single
file. The important point is to separate out the details of how to control
services into a shared, common library (analogous to a general purpose
subroutine library) from the definitions and other actions about each
particular service (analogous to the callers of that subroutine library).)
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.
3. A level of abstraction such as this "service_config(s, enable)" could be
potentially very useful for a library supplied as part of cfengine itself,
maintained by the experts who provide the software itself. They could also
provide template 'callers' for common services such as "ntp.cf", again
maintained centrally. This would give us, as end-users, (a) an almost (not
quite) "drop in" usage of such common services and (b) examples of good
practice for our own local services.
So overall, I think you may started a good start to a potentially very useful
resource for us all.
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
