On Nov 24, 1:37 pm, RijilV <[EMAIL PROTECTED]> wrote:
> 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
Thanks a lot, This really helps.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
