[Puppet Users] Re: Puppet Common Modules: SSH Proposal

----- "Jeroen van Meeuwen" <kanarip <at> kanarip.com> wrote:

> Digant C Kasundra wrote:
> > There is a lot to digest here but a quick correction on:
> > 
> > # Red Hat / CentOS has puppet-0.24.4 and does not do the import
> magic. It could do the imports, but it requires import statements per
> file (not exactly making the module any more portable). 
> > 
> > I'm not sure what you mean by this as import magic is most certainly
> in place (we use it all the time and we actually don't use the word
> import anywhere).
> > 
> 
> Well, it's in the commentary of the actual module... And not as 
> significant to the proposal as the actual module itself...
> 
> Besides the wiki page can just describe the module as a one file
> source, 
> I find the automagic module imports work, but the subclasses and
> defined 
> types in modules (and/or it's subbclasses) are not automatically
> imported.
> 
> Jeroen van Meeuwen
> -kanarip

That's odd b/c that seems to work for me just fine.  Perhaps it is b/c of namespacing?  I.e. when I define a
subclass of ssh called foo, I would actually declare it as ssh::foo.  If I include ssh::foo, puppet looks

[Puppet Users] Re: Module Standards

----- "Kenton Brede" <kbrede <at> gmail.com> wrote:
> > With a small operation, it is okay.  With something larger, it
> doesn't scale well and it doesn't make good use of module grouping. 
> For instance, when setting up openldap, I want to talk about what I do
> (packages I install, conf files I drop in, etc) all in one place so I
> can see what I do with openldap as a whole more easily.  If it were
> broken out into several places based on OS type, it isn't quite as
> easy to ensure that each OS type is similar.  For instance, on a
> debian box and a redhat box, I can look at classes.txt and see that
> openssh class is applied, so I know that I'm managing openssh on
> debian and redhat boxes, but with the other approach, I wouldn't be
> able to see that without digging into the debian.pp and redhat.pp
> files.
> >
> 
> Hmmm, unless I'm missing something, what you describe is what I'm
> doing.  If I'm wrong please let me know.
> 
> Currently I have two types of modules:
> 
> Modules based on type (file, cron, etc) that are not tied to a
> particular service.  For example, a custom script that goes to host
> foo, or a group such as rhel5.  And modules based on a service
> (apache, iptables, etc), which contain any resources that are needed.
> 
> The only time I have a rhel5.pp class, is if it's as sub-module.  For
> example cron::rhel5.pp, which contains cron jobs for rhel5  servers.
> Or apache::rhel5.pp, which contains rhel5 specifics for that group. 
> I

[Puppet Users] Re: Puppet Common Modules: SSH Proposal

This is an interesting approach and certainly valid and should work.  I'm not sure I would use the virtual
resources since one could just as easily define those things in the classes they are used in.  Virtual
resources are better when you wnat to declare something in one place but it could be realized in any number
of places (making it impossible to be declared in all of those places b/c if two such classes were included,
you'd have an error)

I think having the OS specific subclasses override the package name instead of a large case statement in the
initial package declaration is spiffy.  I can actually seeing both ways being useful.  Sometimes, I like to
see all the various ways a package (or  service) might look in one place, so I sometimes like to see the case
statement approach.  Other times, I like to see specific changes that are related to an OS or similar
logical grouping to be made in an appropriate subclass with the use of overrides.

To answer about use-cases, we have in our ssh module some subclasses that are relevent to a particular
configuration of ssh server.  For instance, ssh::global allows ssh connections from off campus while our
regular ssh doesn't.  I prefer these as subclasses b/c I like to look at my list of classes to glean what kinds
of things my server is setup to do (and when I build an external node tool, rather than messing with
variables and blah blah blah, I'll just be adding or dropping classes).

----- "Jeroen van Meeuwen" <kanarip <at> kanarip.com> wrote:

> Hi there,
> 
> I'd like to collect some feedback on a conceptual simple Puppet Common
> 
> Module I want to propose;
> 
> http://reductivelabs.com/trac/puppet/wiki/PuppetCommonModules/SSH
> 
> I'm thinking about things like;

[Puppet Users] Re: Puppet Common Modules: SSH Proposal

Digant C Kasundra wrote:
> That's odd b/c that seems to work for me just fine.  Perhaps it is b/c of namespacing?  I.e. when I define a
subclass of ssh called foo, I would actually declare it as ssh::foo.  If I include ssh::foo, puppet looks
for foo.pp in the ssh/manifests and if it doesn't find that, it then looks in init.pp in ssh/manifests. 
Perhaps I'm not understanding what you aren't able to get work.
> 

It's no big deal it's just something I wasn't able to get to work when I 
looked at it, I'll figure it out some time.

-Jeroen

--~--~---------~--~----~------------~-------~--~----~
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 <at> googlegroups.com
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Puppet Users] virtual resources: multiple exports and one collect

Hello everybody,
I have a question regarding virtual resources and the exporting/ 
collection thereof.

I have several hosts that should export one and the same file  
resource. This should be collected exactly once by one host.
The resources are exported within a define:

## this define is used by many hosts.
## example: sge::queue{"testqueue": ensure => present }
define sge::queue(...){
	 <at>  <at> file{"/var/lib/puppet/exported/sge/queue.template.${queue_name}":
		content => template("sge/queue.template.erb"),
		tag => "sge_queue_template",
	}
}

### one host should import the File resource above.
class queue_collect{
	File <<| tag == "sge_queue_template" |>>
	#there should be exactly one file:
	# /var/lib/puppet/exported/sge/queue.template.testqueue
}

How would I do this? If I simply do the examples above, I get the  
"cannot override local resource" error on the host which is in the  
queue_collect class.

I would like to know how I could have many hosts export the "same" (as  
in identical) resource. Is this possible?

[Puppet Users] How to aggregate node attributes?

So we've got "resources".  And "classes" and "nodes" and "defines" and
"modules" and "plugins" and "templates".  And I'm not sure I've got
them all, by any means.  Classes are singletons.

I'm working on managing a batch of identical servers.  The obvious
thing, it seems to me, is to define a *thingy* (technical term meaning
I want to not misuse any of the specifically meaningful terms above)
which encapsulates exactly what I want these identical servers to do
(presumably using lots of modules and things from elsewhere), and then
associate the *thingy* with the list of nodes I want to be like that.
Is this the propperly Puppetish best-practices approach?  (It's a
small batch, 2 at the moment, unlikely to exceed a dozen ever; they're
actually *virtual* servers).

And, if that is the right general approach -- what flavor of *thingy*
should I be writing there?  Is that a define, or a class, or a module,
or what?  Or is it best (since they're really truly supposed to be
identical) to skip the container and just import or define everything
I want directly in the node, using the multiple titles syntax to
create a batch of identical nodes?

(And I've got my test node connecting to my puppet server and doing
the trivial stuff from the "simplest recipe" correctly, and I'm moving
on to bigger and better things!  Thanks for all the help in stage
one.)

--~--~---------~--~----~------------~-------~--~----~
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 <at> googlegroups.com

[Puppet Users] Re: How to aggregate node attributes?

dd-b wrote:
> So we've got "resources".  And "classes" and "nodes" and "defines" and
> "modules" and "plugins" and "templates".  And I'm not sure I've got
> them all, by any means.  Classes are singletons.
> 
> I'm working on managing a batch of identical servers.  The obvious
> thing, it seems to me, is to define a *thingy* (technical term meaning
> I want to not misuse any of the specifically meaningful terms above)
> which encapsulates exactly what I want these identical servers to do
> (presumably using lots of modules and things from elsewhere), and then
> associate the *thingy* with the list of nodes I want to be like that.
> Is this the propperly Puppetish best-practices approach?  (It's a
> small batch, 2 at the moment, unlikely to exceed a dozen ever; they're
> actually *virtual* servers).
> 
> And, if that is the right general approach -- what flavor of *thingy*
> should I be writing there?  Is that a define, or a class, or a module,
> or what?  Or is it best (since they're really truly supposed to be
> identical) to skip the container and just import or define everything
> I want directly in the node, using the multiple titles syntax to
> create a batch of identical nodes?
> 
> (And I've got my test node connecting to my puppet server and doing
> the trivial stuff from the "simplest recipe" correctly, and I'm moving
> on to bigger and better things!  Thanks for all the help in stage
> one.)
> 

To "group" a bunch of servers to let them have the same manifests and 

[Puppet Users] Re: How to aggregate node attributes?

On Oct 1, 12:24 pm, Jeroen van Meeuwen <kana... <at> kanarip.com> wrote:

> Does that help?

Yes, thanks.

I'm inferring from  your answer that not only does that work, but you
think it's a reasonable approach.

--~--~---------~--~----~------------~-------~--~----~
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 <at> googlegroups.com
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Puppet Users] Re: How to aggregate node attributes?

On 10/1/2008 11:39 AM, dd-b wrote:

> And, if that is the right general approach -- what flavor of *thingy*
> should I be writing there?  Is that a define, or a class, or a module,
> or what?

Probably some of each, depending on what you need to do. A module is 
more or less an encapsulated set of classes, defines, files, templates, 
etc. that occupy a single directory tree. I wrote up my first module at 
http://blogs.cae.tntech.edu/mwr/2007/08/02/the-new-file-server-puppet-and-modules/ 
- and it's a combination of all of the above and may be a useful 
starting point. Its goal is to be the thingy that configures all my 
Amanda servers correctly. Honestly, I only have the one Amanda server, 
but it has three different configurations active at once, and I'd like 
to ensure that they're all done consistently. And I'd also like to 
ensure that my next Amanda server gets set up the right way as well.

--~--~---------~--~----~------------~-------~--~----~
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 <at> googlegroups.com
To unsubscribe from this group, send email to puppet-users+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Puppet Users] Ruby Openssl failure on Solaris 9