Anyone else feel free to step in and correct me, but here's how I see it...
2008/11/24 kevin <[EMAIL PROTECTED]>
>
> Ok, I've been reading and I have some questions about best practices:
>
> I understand that modules are to be self contained blocks that i can
> just drop in. Using best practices, how does this fit into the naming
> scheme?
>
> Classes are singletons. I think i understand this. I've been
> defining classes in /etc/puppet/classes, but then how does this relate
> to any modules i might want to use?
>
So, the idea behind a module really relates more to organization than
anything else. Generally speaking, modules contain classes. But back to
your question. The fact you're defining classes in /etc/puppet/classes only
relates to any modules you might want to use if you define a class that has
the same name as a class defined in a module, inwhich case you'd have a
naming conflict.
> what is the difference between
> class::whateverthismethodlikethingisinpuppetsyntax and class? ie:
>
> class apache {
> #
> }
>
> class apache::wtf {
> #
> }
>
Effectively everything. 'class' vs 'class:foo' are two different classes.
The idea is 'class::foo' is a subclass of 'class', however there isn't
anything besides sanity that enforces this. if you wanted class
'apache::wtf' to setup NIS+ and class 'apache' sets up a TFTP server, then
that's your deal. Generally speaking you'd set that relationship up to be
subclassed like the below contrived example:
class apache {
package { 'apache':
ensure => 'installed',
}
service { 'apache':
ensure => 'running',
}
file { "/etc/apache/httpd.conf":
source => 'puppet:///apache/normal.conf',
}
}
class apache::wtf inherits apache {
File["/etc/apache/httpd.conf"] {
source => 'puppet:///apache/wtf.conf',
}
}
Some syntax might be wrong, its monday and a short week in the states so I'm
a bit checked out. In any event you'd have a node that includes
'apache:wtf', which inherits 'apache' so you get all the work you did in
that class as well, with the override of httpd.conf
also, classes are not methods...
>
> What is the actual function of site.pp? I had thought it was the
> entry point for puppetmasterd. so how would I include a module in a
> site?
>
> site.pp is included whenever a client requests a configuration. Generally
speaking you'd have your node definitions in there (or in nodes.pp, or in an
external node tool). I also use it to set defaults for types, eg setting a
path for Exec, setting ensure => installed for Package, etc (but I'm also
very lazy).
As for including a module from site.pp, you'd just say 'include mymodule'.
This does require some plumbing: in your puppet.conf under the
[puppetmaster] section add something like[1]:
modulepath = /var/lib/puppet/modules
Then just copy the module to that directory. For example if you had the
module 'foo' you would end up with something like:
/var/lib/puppet/modules/foo/manifests/init.pp
/var/lib/puppet/modules/foo/manifests/subclass.pp
/var/lib/puppet/modules/foo/files/myfile.txt
/var/lib/puppet/modules/foo/files/otherfile.txt
/var/lib/puppet/modules/foo/templates/example.erb
Puppet will 'magically' take care of
.r'
[1]: http://reductivelabs.com/trac/puppet/wiki/ModuleOrganisation
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
