Firstly thank you Daniel for your response on the scope stuff in
templates -- I had read that doc and missed it.
I am still struggling with this and I suspect that there may well be a
better way of doing what I need so as the subject says I am going back
to basics. In this post I will try and abstract out what I am trying
to do and what my assumptions are.
I have monitor machines:
These have one or more sensors:
sensors run have one or more interfaces.
all sensors are clones of a master template
For instance I have two monitors on our outer dmz monitoring the two
links to the internet, each of these runs a clone of the dmzo master
sensor. Since the load is high on these machines and snort is single
threaded we split the traffic onto virtual interfaces so there are two
instances if each sensor running on each machine.
Logically there are two bits of configuration to specify a monitor
machine, first is a list of sensors and secondly a list of masters.
my current set up is like this:
module monitor
manifests init (defines monitor class which includes sensor
definition )
masters (either all in one pp file or preferably
as a directory with file for each master:
master1
master2
..........
manifest
nodes/
monitor.pp
monitors/
host1
host2
....
The master and host files are generated by my management system:
e.g.
modules/monitor/manifest.masters/dmzo.pp
class dmzo {
$rule_categories = [
scan,finger,ftp,telnet,rpc,rservices,ddos,dns,tftp,web-
coldfusion,misc,web-php,
.....
]
}
manifest/nodes/monitors/mon1:
node ''mon263550.insec.auckland.ac.nz'' inherits monitor {
monitor::sensor { dmzo_58:
name => ''dmzo-58'', master =>
''dmzo'', interfaces =>
''eth1'',
}
}
####################
sensor is a define in the monitor class....
Where I am having problems is within the sensor define where I am
trying to get the value of $rule_categories associated with the
parameter $master. i.e. I want to qualify the variable
$rule_categories dependent on the value of the parameter $master
$rule_categories = ${$master}::rule_categories to use a perlism. I
suspect that this is not possible ?? I don''t see any way of doing
that indirection in erb either.
An alternative (less than ideal but workable *) approach I have tried
is to have
module/monitors/manifest/masters.pp (no directory)
class masters {
$rules = { ''dmzo'' => [
scan,finger,ftp,telnet,rpc,rservices,ddos,dns,tftp,web-
coldfusion,misc,web-php,
]
}
}
and then have in the sensor define:
$rule_categories = $masters::rules[$master]
SERVER: undefined local variable or method `accesskey'' for
#<Puppet::Parser::AST::HashOrArrayAccess:0x2afda268e0f0> at /etc/
puppet/modules/monitor/manifests/init.pp:63 on node
mon263550.insec.auckland.ac.nz
If I place the definition or $rules in side the define and drop the
$masters:: qualification this works fine.
so why isn''t the value getting passed through the qualified variable
when the unqualified works?
Russell
* less than ideal because I would really like to have the definition
of each master in a separate file -- this makes manipulating on entry
independent of the other much easier in the management script but this
is not a big deal.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
"russell.fulton" <russell.fulton@gmail.com> writes:> Firstly thank you Daniel for your response on the scope stuff in templates > -- I had read that doc and missed it.No worries - happy to help. As an incidental aside, if you actually continue the same thread by replying to a previous message my mail client highlights it for me attention, and I am less likely to skip over it.[1]> I am still struggling with this and I suspect that there may well be a > better way of doing what I need so as the subject says I am going back > to basics. In this post I will try and abstract out what I am trying > to do and what my assumptions are. > > I have monitor machines: > These have one or more sensors: > sensors run have one or more interfaces. > all sensors are clones of a master template[...]> Where I am having problems is within the sensor define where I am trying to > get the value of $rule_categories associated with the parameter $master. > i.e. I want to qualify the variable $rule_categories dependent on the value > of the parameter $master $rule_categories = ${$master}::rule_categories to > use a perlism. I suspect that this is not possible ?? I don''t see any way > of doing that indirection in erb either.You can, using something ugly like this: <%= scope.lookupvar("#{master}::rule_categories") %> OTOH, if you can avoid that I would strongly advise it. That sort of thing is pretty ugly, and might get broken by side-effect later on because it isn''t really how things are supposed to work. :( You mentioned that some of your data is automatically generated:> The master and host files are generated by my management system:To my eye that sounds like your external database contains the knowledge of which rules should apply to which sensor, right? I would probably just skip the entire puppet side for that and use this: node foo.example.com { sensor { "sensor001": } } define sensor () { $rules = generate("/usr/local/sbin/get-rules-for ${fqdn} ${name}") # ...and that emits a single string with the right data. } You can use the split function to turn that into a puppet array if you need it to be, incidentally. (Generate runs on the puppetmaster, not the client, BTW.) When your master data is stored outside of puppet there is nothing even remotely wrong with querying that service to get at that data. We do that for a few bits and pieces, like "what IP *should* this host have". That also saves you having to model the "master" stuff in puppet at all, which it sounds to me like you only want so that your actual sensor definitions make sense. Using the external, authoritative data source means you don''t duplicate that information, even if it ends up "copied" multiple times in the final instructions sent down to the client. Regards, Daniel Footnotes: [1] ...of course, the few days after our central firewall goes "pop" and we can''t source suitable hardware to replace it I don''t pay much attention to anything outside my own offices. ;) -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> } > > define sensor () { > $rules = generate("/usr/local/sbin/get-rules-for ${fqdn} ${name}") > # ...and that emits a single string with the right data. >It looks as if one can not pass variables into generators to protect us from ourselves.... "Generators can only contain alphanumerics, file separators, and dashes at /etc/puppet/modules/monitor/manifests/init.pp:61 " I may end up using #{var} in the erb.... Russell -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
"russell.fulton" <russell.fulton@gmail.com> writes:>> } >> >> define sensor () { >> $rules = generate("/usr/local/sbin/get-rules-for ${fqdn} ${name}") >> # ...and that emits a single string with the right data. >> > > It looks as if one can not pass variables into generators to protect > us from ourselves.... > > "Generators can only contain alphanumerics, file separators, and > dashes at /etc/puppet/modules/monitor/manifests/init.pp:61 " > > I may end up using #{var} in the erb....Ah! Sorry, I forgot the syntax is incoherent with the other ways that shell commands are invoked. We actually use this to get the IP: $dns_ip = generate(''/usr/bin/ruby'', ''-e'', "require ''socket''; print IPSocket.getaddress(''${fqdn}'')") ...so, you should be good with: $rules = generate(''/.../get-rules-for'', $fqdn, $name) Sorry for the wasted time. I wish those interfaces all worked the same, predictable, way in puppet. One day, one day... Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.