robu...@gmail.com writes:
with the augmentsfile inputs variable I seem to can't include our whole
lib-dir?
Is that right?
Yes, that is correct. The inputs
key gets mapped to def.augments_inputs
, and
that list is included in the stock promises.cf
.
do I have to statically list each and any file that I want to include?
Yes. However you could include a file that includes other files.
as I have to set
"classes:" { "servicesautorun": [ "any" ] }
to make services/autorun run in the way we had it so far,
are ALL subdirs of services/autorun automatically parsed?
No, only the policy files in the top level of the services/autorun
directory
are automatically added to inputs when services_autorun
is defined.
is setting the above mentioned class in the augemntsfile sufficient to
parse all files in the service autorun dir
(and get thm executed according to services/main.cf) or do I have to
manipulate
controls/def.cf to set the classes there too? (I fear so, but that would
draw a bunch of question
marks on the whole point of the augmentsfile or not?)
No, there is no need to modify def.cf to define the services_autorun
class.
Defining it from augments is sufficient to enable the addition of
services/autorun/*.cf
to inputs and run the bundles tagged with autorun
in
lexical order.
Is it right that in the augments_file I can only set variables and classes for the class any?
No, you should be able to use any of the hard classes except for those related
to the hostname and am_policy_hub|policy_server
. So you should able to use
things like redhat_5
and 1cpu
and 64bit
.
Variables are not set conditionally from augments. They are for the any
class
all the time.
Augments is not trying to allow the level of decision making you can achieve
inside the policy language. It's intended to be pure data that applies to your
infrastructure from a high level.
… In master an augments
key has been introduced where you can merge more
specific augments on top of def.json
using the same strategy as mergedata()
variables conditionally using multiple augments. So you could have different
augments for different platforms.
(no same variable with different values for different classes?)
Up to now we have a quite extensive "bundle common def1" that is evaluated
first and defines
vars and classes, I wonder if and how much I could/should port from there
to the augmentsfile?
Augments is useful for defining classes and variables very early during agent
initialization (earlier than def.cf
). Probably your common bundle could be
included via the inputs
key in the augments file. If it's setting classes
conditionally based on other things it will likely still be useful to you. If
it's just turning on some classes and setting some variables the same for the
entire infrastructure they might do just as well in augments.
–
Nick Anderson
Doer of things, CFEngine
"mailto"
string => "root@$(def.domain)",
ifvarclass => not(isvariable("mailto"));
"mailfrom"
string => "root@$(sys.uqhost).$(def.domain)",
ifvarclass => not(isvariable("mailfrom"));
"smtpserver"
string => "localhost",
ifvarclass => not(isvariable("smtpserver"));
mail.log and our mailserver tell me that the mail is trying to be send to root@$(def.domain)
... which is wrong.
What am I missing?
TIA and regards
/var/cfengine/inputs/controls/3.7/def.cf
has the same settings as def.jsonTo unsubscribe from this group and all its topics, send an email to help-cfengine+unsubscribe@googlegroups.com.
ifvarclass => not(isvariable("mailto"));
vars:
any::
"cf_execd_pid"
string => execresult("/bin/cat /var/cfengine/cf-execd.pid", "noshell");
"cf_monitord_pid"
string => execresult("/bin/cat /var/cfengine/cf-monitord.pid", "noshell");
"cf_serverd_pid"
string => execresult("/bin/cat /var/cfengine/cf-serverd.pid", "noshell");
"m_time"
string => execresult("/bin/date", "noshell");
reports:
cfengine::
"augemts_test is ${def.augments_test}
cf_execd_pid is ${cf_execd_pid}
cf_monitord_pid is ${cf_monitord_pid}
cf_serverd_pid is ${cf_serverd_pid}
mailto is ${def.mailto}
mailfrom is ${def.mailfrom}
time is ${m_time}
sys.last_policy_update is ${sys.last_policy_update}"
comment => "test";