On Fri, Dec 02, 2011 at 04:12:12PM -0500, no-re...@cfengine.com wrote:
>Forum: CFEngine Help
>Subject: Re: CFEngine Help: Re: controlling redhat-style startup services via
>chkconfig
>Author: matt_garman
>Link to topic: https://cfengine.com/forum/read.php?3,24170,24171#msg-24171
>
>Jesse Becker Wrote:
>-------------------------------------------------------
>> You can't do this (easily) because vars: promises
>> are processed before
>> classes: promises. Thus, but the time you have
>> defined the "needs_ntp"
>> class, it's too late--you've already processed the
>> vars: definitions.
>>
>> You have at least two possible workarounds:
>>
>> 1) use hard classes in vars:. This works because
>> hard classes are
>> defined before the processing of the promises.
>>
>> 2) do some trickery with isvariable() when
>> defining classes to create
>> what I call a "guard" class, then use that to
>> define a variable in the
>> next pass through the bundle. It's complicated
>> and ugly.
>
>Regarding (2), I don't really understand what you're saying, but I'll take
>your word that it's "complicated and ugly" and therefore not something I want
>to pursue. :)
>
>So, somewhat for posterity, what you mean by (1) is this:
>
> vars:
> # can't use soft class "need_ntp" here, because class promises
> # are determined after var promises.
> linux|cfengine_3:: "service" slist => { "ntpd", "named" };
> !(linux|cfengine_3):: "service" slist => { "named" };
>
>
>And that does exactly what I want, at least the outcome is what I want.
Yep, that it.
You can also use common bundles, since they are all processed before
agent bundles. However, within a common bundle, I think vars: are still
processed first. The so the ordering is something like this:
commmon bundle/vars, iteration1
commmon bundle/classes, iteration1
commmon bundle/vars, iteration2
commmon bundle/classes, iteration2
commmon bundle/vars, iteration3
commmon bundle/classes, iteration3
agent bundle/var, iter1
agent bundle/classes, iter1
agent bundle/var, iter2
agent bundle/classes, iter2
agent bundle/var, iter3
agent bundle/classes, iter3
<repeat for each bundle in bundlesequence>
>So, now: what is the rationale behind processing vars: promises before
>classes: promises?
Unsure. You can make arguments for both options (and there have been
several such arguments on this list--check the archives).
>And secondly, is there an overall cleaner, simpler and easily-maintainable
>approach to the problem I'm trying to solve? That is, all my servers have
>some common subset of services that I want to have run at startup. But then
>there are a handful of servers that additionally need service1, another
>handful that need service2, and another small handful that need service3.
You could try appending to a list... Maybe something like this
(*UNTESTED*):
vars:
linux::
'common_services' slist => { 'ntpd', 'cfexecd', 'sshd' };
mail_servers::
'mail_services' slist => { 'postfix' };
file_servers::
'file_services' slist => { 'smbd', 'nfs' };
any::
'all_services' slist => {
@{common_services},
@{mail_services},
@{file_services},
};
classes:
'mail_servers' or => { 'host1' };
'file_servers' or => { 'host1', 'host2' };
commands:
"/sbin/chkconfig ${all_services} on";
>I guess I could have a promise for all the common services, and then a
>per-service promise for each special case. But as a programmer, that feels a
>lot like code duplication.
Yeah, you could do that, and it may be the cleanest option. :-/
>Any hints or advice? I can't imagine this being an uncommon scenario.
--
Jesse Becker
NHGRI Linux support (Digicon Contractor)
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
