Thanks very much John. I had indeed been thinking of import as being
like include.
As it happens I have completely reworked this stuff and now the
monitor module just deals with specifying what packages and users are
pushed out. It also now imports a two defines which deal with all the
config stuff. What I have is a monitor machine which has one or more
sensors which intern has one or more instances. I was trying to do
the everything in the parameterised module -- not a good idea :)
one question can you have more than one instance of a parameterised
module? I am guessing the answer is no. I could not find an explicit
answer in the docs.
I'll trim most of the rest and answer a few other points inline:
>
> 2) At first I read your comments about init.pp as indicative that
> you're putting everything in the master manifest. Now I'm not so
> sure, but if that's indeed what you are doing then I strongly advise
> you to structure your manifests into modules instead.
Agreed :) and no, the 'master' manifest just has config data about
the 'master' (or template) sensor -- each master may have several
clones.
and everything is set up using modules.
>
> 3) If you *are* using modules, and you are following the naming and
> structure guidelines, then you should never need to explicitly import
> anything.
Sorry, not sure what you mean by "explicitly import". You mean
explicitly pulling in bits like that variable definition? then yes I
agree.
>
> 4) I'm curious why you need to generate your "$sensor_rule_categories"
> hash externally. There's nothing particularly wrong with doing that,
> but it seems like it would limit your ability to expand your use of
> Puppet.
I have a management system that provisions the monitoring systems
previously it did everything and I am now moving to get puppet to do
the heavy lifting. The idea is that I have all the meta data in
puppet and my management system generates the files for puppet. I
want the files that the management system produces to be sand alone.
i.e. I don't want to have the management system to have to insert
stuff in the middle of init.pp.
I now have this refined down to single file and I am rather pleased
with it:
monitor/.../init.pp
# The various mon* nodes (a non-regexp definition will take
precedence)
node 'monitor' inherits basenode {
include monitor
}
# the generic node -- installs software only
node /^mon\d+\.insec\.auckland\.ac\.nz$/ inherits monitor {}
# active nodes
import "monitors/*.pp"
monitors/mon263550.pp:
node 'mon263550.insec.auckland.ac.nz' inherits monitor {
monitor::sensor { monitor_dmzo_58:
name => 'dmzo-58', master => 'dmzo', interfaces =>
'eth1',
rule_categories => [
scan,finger,ftp,telnet,rpc,rservices,ddos,dns,tftp,web-
coldfusion,misc,web-php,
x11,attack-
responses,oracle,mysql,pop2,pop3,bad-traffic,dos,exploit,misc,smtp,
web-misc,emerging-exploit,emerging-scan,emerging-web,emerging-
web_sql_injection,
emerging-web_server,emerging-web_specific_apps,emerging-
attack_response,emerging-virus,
emerging,emerging-trojan
]
}
}
Sensor is a define and there may be more than one, and the interfaces
can be an array in which case multiple configs are generated.
This file will be generated automatically by my management script for
each monitor machine.
It has taken me about a month to get to this point but I am satisfied
with what I have now (starting completely from scratch with puppet).
There have been two complete reworks in that time.
I'd like to take this opportunity to thank the folk in this group for
their help and the folk at puppetlabs who answered questions
directly.
>
> Puppetlabs is very active fixing bugs and developing new features for
> Puppet. They crave issue reports. (And also bugfixes! Puppet is
> open source, you know.) However, I cannot speak to how any particular
> report will be prioritized or what kind of resolution it might
> receive.
>
I start using it :) and if I get time I'll investigate some of these
things myself -- yes I do Ruby ;-)
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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
