Re: [Puppet Users] Puppet Labs Announces Puppet Forge, a Central Repository for Puppet Modules
Haha! So much for my purchase of puppetstrings.net! I guess I can scrap the crappy code I had put together, too. :-P --Paul On Thu, May 27, 2010 at 6:56 AM, Scott Olson wrote: > Details and links to the Puppet Forge can be found here: > > http://www.puppetlabs.com/blog/puppet-labs-announces-puppet-forge-a-central-repository-for-puppet-modules/ > > -- > 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. > > -- 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.
Re: [Puppet Users] More External Nodes
If you don't see a use, don't use the feature. However, when you have an issue and people suggest external nodes is the answer, you might consider listening. -Paul On Thursday, May 20, 2010, Douglas Garstang wrote: > I'm really just not getting the whole point of external nodes. The > more I look at it, the less I see the point. > > For starters, you have to pass arguments from your node back to your > classes via what appear to be global variables, and then if you have > multiple instances of a specific piece of software running, on a node > (which is not that uncommon) you have to qualify these global > variables in some manner, inst1_var1, inst2_var1 etc. > > C'mon... seriously, what am I missing here? > > Doug > > -- > 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. > > -- 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.
Re: [Puppet Users] Re: External Nodes
In this situation, the problem you need to address isn't Puppet, it's
your infrastructure. The infrastructure you describe is going to be
nuts to manage no matter what set of tools you are trying to use. It
doesn't make the tools deficient.
Basically, if you build your house on a swamp, don't complain that
there are no building materiels that you can use to keep your house
from sinking.
--Paul
On Thu, May 20, 2010 at 2:35 PM, Douglas Garstang
wrote:
> On Thu, May 20, 2010 at 2:18 PM, Steven VanDevender
> wrote:
>> Douglas Garstang writes:
>> > On Fri, May 14, 2010 at 1:38 PM, Paul Lathrop
>> wrote:
>> > > You are getting a bunch of misguided answers to this. I'm also
>> > > perplexed by your assertion that external nodes requires you to write
>> > > custom scripts to parse node manifests.
>> > >
>> > > No, you cannot put resources directly into nodes when you are using
>> > > external nodes. In practice, this hasn't mattered; you wrap your
>> > > resources in a class, done.
>> >
>> > Sorry, but I really don't follow this. It isn't until you drill down
>> > to the node level that you get to the level of detail necessary. For
>> > example, software A requires version X on server A, and software A
>> > requires version Y on server B. The only way I can see to do that it
>> > is to define it at the node level. Defining it at the class level is
>> > too far up the chain.
>>
>> You're not really talking about defining resources here. You can
>> specify node-specific variables when using an external node classifier,
>> and so you could use those to indicate node-specific requirements like
>> software versions.
>>
>> Ultimately an external node classifier has to provide these bits of YAML
>> to Puppet for each node:
>>
>> classes: [ ]
>> parameters: { }
>>
>> So if you need different Apache versions on two different nodes, your
>> node classifier could supply this for node1:
>>
>> classes: [ apache-server ]
>> parameters: { apache_version=2.0.63 }
>>
>> and this for node2:
>>
>> classes: [ apache-server ]
>> parameters: { apache_version=2.2.15 }
>>
>> And then in each node $apache_version would indicate which version to
>> install, which you could use in a "package" resource or whatever.
>
> Steven,
>
> Trying to understand this, but let's say we had multiple instances of
> Apache running on each server (we actually have multiple instances of
> JBOSS and Tomcat running, but lets stick with Apache for the analogy).
>
> How would defining variables work then? I mean, your example above has:
>
> parameters: { apache_version=2.2.15 }
>
> Extending this, we'd end up using:
>
> parameters: { apache1_version=2.2.15, apache2_version=2.2.16,
> apache3_version=2.2.16, apache4_version=2.2.17 }
>
> and so on, depending on what the syntax is:
>
> HOWEVER, we also define a number of different parameters for each
> instance of software, which makes the whole set of parameters even
> more complicated. Do external nodes work in this case?
>
> Doug
>
> --
> 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.
>
>
--
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.
Re: [Puppet Users] Six Puppet Questions
Comments inline: On Tue, May 18, 2010 at 3:01 PM, Matt Juszczak wrote: > 4) Failover: What are people doing these days for puppet failover? My gut > says to keep the configs in SVN, and always have another host on stand by. > However, there's an issue with that: the puppet nodes wouldn't be able to > just be re-pointed, because the client SSL certificates would be validated > by the failover server (and therefore, there would be certificate validation > errors). We set up a separate root CA and used it to sign certificates on our puppetmasters. The puppetmasters then act as intermediate CAs and any client can connect to any puppetmaster. We then threw the puppetmasters behind our load balancer. > 5) Puppetizing your puppet servers: I've already made the decision NOT to > LDAPify my LDAP servers (master and failover), as I wouldn't want LDAP to > fail and cause issues getting into the LDAP box. My gut has also told me > NOT to puppetize my puppet server (and just keep good backups); however, > what have others done? I've seen conflicting documentation and blog entries > on the subject. LDAP sucks a LOT when it breaks, and it seems to break a lot. The puppetmaster is much less volatile in my experience. I'm a big fan of puppetizing the puppetmaster; it makes it much easier when there's only a single process used for configuring servers. It hasn't caused any huge problems in our environment. Remember, if the puppetmasters is misconfigured badly enough that it isn't passing out configs, worst-case scenario is that you can't deploy new configs. Just log in to the puppetmaster and fix by hand. Whereas, with LDAP logins, worst case is you *can't* log in and fix (yikes!) --Paul -- 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.
Re: [Puppet Users] Negative requires
Hi Tim,
What you want is this:
package { "mysql": ensure => absent, before =>
Package["MySQL-client-community"]; }
package { "MySQL-client-community": ensure => installed;}
On Mon, May 17, 2010 at 9:35 PM, Tim Nicholas wrote:
> Hello everyone,
>
>
> I'm just getting to grips with Puppet so apologies if I've missed something.
>
> I'm wondering if there is a way to require that something isn't the case.
>
> My current situation/example is that I'm trying to uninstall one
> package ("mysql") and install another one that conflicts with it
> ("MySQL-client-community") in one puppet run.
>
> I can do something like:
>
> package { [ "mysql" ] : ensure => absent, }
> package { [ "MySQL-client-community", ] : ensure => installed, }
>
> Which is fine, unless "MySQL-client-community" is scheduled to be
> installed before mysql is removed, in which case it errors and I'm
> left with a system with no mysql.
>
> Obviously, I can just run puppet again and it'll be fine but I'd
> really like to do something like:
>
> package { [ "MySQL-client-community", ] : ensure => installed,
> require => ! Package[ "mysql" ] }
>
> with the ! negating the requirement.
>
> Is this possible or am I approaching this from the wrong angle and I
> should be doing something quite different?
>
>
> Thanks,
> Tim
>
> --
> Tim Nicholas
>
> --
> 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.
>
>
--
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.
Re: [Puppet Users] Have I found a bug with variables in nodes?
>>> Assuming the client has puppeted at least once against that server. This >>> won't work for bootstrapping a client though will it? >> >> it does, the facts yaml file is created before the external node >> classifier is called ;) > > Whoa. This should be called out in the external node docs, as I simply > assumed this happened after the node classifier is called. +1000 --Paul -- 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.
Re: [Puppet Users] Re: External Nodes
You are getting a bunch of misguided answers to this. I'm also
perplexed by your assertion that external nodes requires you to write
custom scripts to parse node manifests.
No, you cannot put resources directly into nodes when you are using
external nodes. In practice, this hasn't mattered; you wrap your
resources in a class, done.
What you gain is truly node-scoped variables (AWESOME). Contrary to
Ken's assertion about global variables, instead you have your external
node script place variables into the output YAML; these variables are
then available to all the classes and resources that apply to that
node.
You don't have to do any parsing of manifests at all. Here's Digg's
external node script:
http://github.com/digg/clusto/blob/master/src/scripts/clusto-puppet-node
It does no parsing of manifests. It also demonstrates some other
things you get using external nodes; the ability to enforce
environments on your clients, for example (useful if you want it), or
the ability to determine your own model of node inheritance (actually
not very obvious in that code, but we manage inheritance using clusto
pools, so the attributes a node end up with are usually defined at the
pool level rather than on the individual node).
External nodes is 100% awesome, I think you just haven't taken the
time to really understand it.
--Paul
On Thu, May 13, 2010 at 10:04 AM, Douglas Garstang
wrote:
> On Thu, May 13, 2010 at 9:53 AM, Ken wrote:
>> Yes your write - you can only really do the equiv of:
>>
>> node foo {
>> $bar = "bleah"
>> include some_class
>> }
>>
>> No resources. So really your left using a swarm of global vars that
>> can passed down to the resources you have show above which are stored
>> in a class. So something like:
>
> OMG. That's absolutely awful!
>
>>
>> node foo {
>> $software1_version = "t.981-1"
>> $software1_addons = "1.6-1"
>> include my_software
>> }
>>
>> Which works - but is less then ideal because your muddy you have a
>> muddy global namespace.
>>
>> However - one solution is being addressed in Rowlf with parameterized
>> classes I believe - which at least allow you to group vars as apposed
>> to using global vars. So something like:
>>
>> node foo {
>> include some_class {
>> param1 => "foo",
>> param2 => "bar",
>> }
>> }
>>
>> Will be possible using external nodes I believe. I seem to recall
>> Puppet Dashboard (the gui that provides external node support) also
>> being able to support this.
>>
>> ken.
>
> Back to parsing the node manifest until external nodes mature a bit.
>
> Thanks.
>
> --
> 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.
>
>
--
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.
Re: [Puppet Users] puppet-module-apache
On Tue, May 11, 2010 at 7:33 PM, Daniel Pittman wrote:
> Paul Lathrop writes:
>
>> I've open-sources Digg's apache module:
>> http://github.com/plathrop/puppet-module-apache
>>
>> I know this isn't much more advanced than what I've seen a lot of people
>> using.
>
> It looks very much like our internal, not-able-to-release version. The two
> features we have that you don't are:
Is it "not able to release yet" or "not ever gonna release"?
> * the module enable/disable feature also ships appropriate configuration and
> installs the appropriate packages for the platform.
Nice, I'd love to add that.
> * apache::conf, which installs a fragment in conf.d/*
Actually, apache::config in my module does exactly that.
> * apache::listen{,::port80,::port443}, which configures the system to listen
> on a custom port, and then wraps that in a class for the standard ports.
I don't do it quite the same way, but there is a tunable for the
ports: $apache_listen_ports
>> Here's my proposition, though. Let's get all the disparate "apache" modules
>> out there merged together into One Awesome Module. What do you think?
>
> Sounds like a great idea to me, but it is a heck of a lot of work.
Yeah, but I'm going to try anyway.
> The most likely "next" feature for us, incidentally, will be to try and
> extract the parts of a VirtualHost tag that are custom, and the parts that are
> standard like the header, auth, logging, etc, so that we don't duplicate those
> in dozens of different files we install...
I love this idea. Will have to see if I can add something to this module.
--Paul
--
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.
Re: [Puppet Users] puppet-module-apache
Did Isaac just volunteer to be the canary for CentOS/RHEL/Fedora? Seriously, I will integrate these various modules, including bringing in any distribution-specific stuff I can find, but I don't have any experience with the CentOS, etc. family of distributions. Related, though, is the concept that we, as a community, may want to settle on one "right way" to lay out an apache configuration. What I mean is, there ought to be a best practice established by now that we can codify into the module, and lay out the apache configs the same on Linux in general, only different where required to hook into the rest of the system. I think this is one of the few areas where the Debian way is actually really smart. That is probably a different discussion though. --Paul On Tue, May 11, 2010 at 7:13 PM, Isaac Christoffersen wrote: > +1 for this. But let's not forget the CentOS/RHEL/Fedora folks out there. > Minor but key differences in directory structure, permissions, SELinux > policies, etc. > > > On 5/11/10 9:56 PM, James Turnbull wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Paul >> >> These are the ones I know about: >> >> http://github.com/camptocamp/puppet-apache >> http://github.com/wesabe/puppet-apache2 >> http://github.com/puppet-modules/puppet-apache >> http://github.com/simpsonjulian/puppet-apache-ubuntu >> http://github.com/ohlol/puppet-apache >> >> Regards >> >> James Turnbull >> >> - -- Author of: >> * Pro Linux System Administration (http://tinyurl.com/linuxadmin) >> * Pulling Strings with Puppet (http://tinyurl.com/pupbook) >> * Pro Nagios 2.0 (http://tinyurl.com/pronagios) >> * Hardening Linux (http://tinyurl.com/hardeninglinux) >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.7 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iQEVAwUBS+oK2yFa/lDkFHAyAQKQWAf+O8Ga73MCHh357VyjJomeX3D+qXvufrf2 >> Rdn0t7gPcO30eOKzPTluF7VxvifKKaeADQktIcnX+o0+VwEYg3Yb198GQMDx >> e8Vx8MeZs8dq80anVSOko/Zc23U1+R76qQQ0zzRd9S6KzvD5bwlkTaAwtwGM2WE0 >> kS0R/xx2KA4CRQK/Vtu1u7BCrMoONbXS+5rF+6MCgYerwD+wqOPvX7PH77xdLmZz >> sFMIinJUkqcaMnZPIWXCxuwAB+abe3WxUGZ7dE1qTgrbt8BEZYuITTRRcXg+kNLO >> CfMW6sPrCtedfxxW9fyuG/Ko1BVaHlMKpG44cr5LMR0OKm3vFmWgBg== >> =vyFz >> -END PGP SIGNATURE- >> >> > > -- > 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. > > -- 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.
Re: [Puppet Users] puppet-module-apache
I'll even do the integration work, just link me to your module and I'll try to integrate its feature set into mine. On Tue, May 11, 2010 at 5:17 PM, Nigel Kersten wrote: > On Tue, May 11, 2010 at 5:15 PM, Paul Lathrop wrote: >> Hey all, >> >> I've open-sources Digg's apache module: >> http://github.com/plathrop/puppet-module-apache >> >> I know this isn't much more advanced than what I've seen a lot of >> people using. Here's my proposition, though. Let's get all the >> disparate "apache" modules out there merged together into One Awesome >> Module. What do you think? >> >> One module to rule them all >> One module to find them >> One module to bring them all >> And via Puppet bind them. >> > > +1 > > > -- > nigel > > -- > 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. > > -- 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.
[Puppet Users] puppet-module-apache
Hey all, I've open-sources Digg's apache module: http://github.com/plathrop/puppet-module-apache I know this isn't much more advanced than what I've seen a lot of people using. Here's my proposition, though. Let's get all the disparate "apache" modules out there merged together into One Awesome Module. What do you think? One module to rule them all One module to find them One module to bring them all And via Puppet bind them. --Paul -- 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.
[Puppet Users] Cassandra Module
Hey Guys, I am also happy to announce the availability of our Cassandra module: http://github.com/plathrop/libpuppet-cassandra This is a pretty simple module, and won't get you 100% of the way to building a Cassandra cluster, but it should take care of the low-level stuff so you can focus on building your fun Java XML configuration files! Questions, criticisms, and contributions welcome. Regards, Paul -- 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.
[Puppet Users] Re: Supervisor Module
My Debian packager just corrected me; we didn't package supervisor, we just back-ported it for Lenny. On Tue, Apr 20, 2010 at 3:41 PM, Paul Lathrop wrote: > Hey all, > > I am happy to announce the release of the supervisor module > (http://github.com/plathrop/libpuppet-supervisor); used to configure > the excellent daemon control tool supervisor > (http://supervisord.org/). Digg has packaged supervisor for Debian and > made the package available at http://mirrors.digg.com ; this module is > the perfect accompaniment. > > As usual, criticism and contributions are welcome! > > Regards, > Paul Lathrop > -- 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.
[Puppet Users] Supervisor Module
Hey all, I am happy to announce the release of the supervisor module (http://github.com/plathrop/libpuppet-supervisor); used to configure the excellent daemon control tool supervisor (http://supervisord.org/). Digg has packaged supervisor for Debian and made the package available at http://mirrors.digg.com ; this module is the perfect accompaniment. As usual, criticism and contributions are welcome! Regards, Paul Lathrop -- 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.
Re: [Puppet Users] Re: Can I specify the order classes are run?
On Sun, Apr 18, 2010 at 12:03 PM, Mr Gabriel wrote: > Thank you for your answer, I thought this was the case, I coudn't see > any mechanism to control the order. There specifically IS a mechanism to control ordering. 'before', 'require', 'subscribe', and 'notify' are metaparameters which specify ordering explicitly. One of the ways that people find they need to adjust their thinking when using Puppet is to adjust to the idea that you need to explicitly specify your dependencies. This is a feature, not a bug. > Is is true enough to say that eventually, everything will run? As long as there are no persistent errors, you can usually depend on multiple runs of puppet eventually bringing your system into sync with your expectations. It's generally considered a best practice to spend a little time trying to get your manifests to work in as few runs as feasible. --Paul -- 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.
[Puppet Users] Apt Module
For you debian users out there: Digg has allowed me to release our apt module as open-source. It's simple, but we find it useful. Contributions and criticisms welcome: http://github.com/plathrop/libpuppet-apt Enjoy! -- 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.
Re: [Puppet Users] File Size
On Thu, Apr 8, 2010 at 10:45 AM, Thomas Bellman wrote: > Dan Bode wrote: > >> I would prefer if puppet ran the sync. It would be nice to receive puppet >> events for any changes made via rsync (essentially reports of which files >> change, this would require that it is implemented in ruby). >> >> I can see from reading the man page that there is a --dryrun call that >> could be used to determine rather rsync should be run or not. Is this >> reasonable to run this to determine if Puppet should run? or is that too >> slow? > > Problem is, once you get file trees that have several tens of thousands > of files in them, just traversing the tree to see which files are there > and ought to be transfered can take a while. When the target tree is > already up to date, rsync --dry-run doesn't go any faster than without > --dry-run. > > The time taken doesn't matter much when Puppet is doing its automatic, > unattended runs, but when you have made a change to your manifests and > want to make a manual test run from an interactive shell, you don't want > to wait an extra ten or fifty seconds just to see that you misspelled a > package name... True, but this is one place where --tags really shines. Our manifest have reached the level of complexity where we *need* to use --tags for iterative debugging. --Paul -- 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.
Re: [Puppet Users] REST API for puppet
It does exist! Sadly, the documentation is the code, as far as I've been able to determine. You can get a fair amount of information if you are using a webserver like Apache in front of puppetmasterd by watching your access logs. --Paul On Tue, Mar 30, 2010 at 3:13 PM, Gustavo Soares wrote: > Hello everyone! > > > Is there any REST API avaiable for puppet? In the documentation page > (http://docs.puppetlabs.com/) > there is a message saying that the doc will be comming soon.. but I am in > doubt... > the REST API exists, but it is not documented or it does not exist? > If it exists, does anyone know what can kind of thing can be done with the > API? > Thanks in advance, > Gus > > -- > 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. > -- 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.
Re: [Puppet Users] Behavior of Environments -- Bug?
Scott, I know it defaults to production if a environment is not specified. However, that's not the case here. The client *is* specifying an environment, the server doesn't know about that environment. I think this is different than what you are describing - if the client does not specify an environment, it is totally sane/correct to pass out the "production" manifests. However, if the client specifies an environment the server doesn't know about, isn't it at least worth warning about? --Paul On Mon, Mar 22, 2010 at 11:50 AM, Scott Smith wrote: > On 3/22/10 10:27 AM, Paul Lathrop wrote: >> >> IMHO this is a bug, but I can see how it might be by design. Any >> comments? Should I file it? >> >> --Paul >> > > Don't know if it's a bug but... Yeah it defaults to "production" - you have > to create an empty manifest for "production" in order to prevent Very Scary > Things from occuring if you happen to also have a "production" Puppet env. > > -scott > > -- > 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. > > -- 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.
Re: [Puppet Users] Behavior of Environments -- Bug?
Tony, Sure, I understand that, but if the client is asking for a specific environment that the puppetmaster doesn't know about, I feel like that warrants a warning at minimum, probably an error and a refusal to compile. Would be interested if anyone has a counter-argument. --Paul On Mon, Mar 22, 2010 at 10:59 AM, Tony G. wrote: > Hi Paul, > > How does your config file look like in the main section? > > There is a default one if no environment is defined, e.g. > > environments = production,testing,development > manifest = /opt/puppet/production/site.pp <-- These are the > modulepath = /opt/puppet/production/modules <-- default locations > > [production] > manifest = /opt/puppet/production/site.pp > modulepath = /opt/puppet/production/modules > > [testing] > manifest = /opt/puppet/testing/site.pp > modulepath = /opt/puppet/testing/modules > > [development] > manifest = /opt/puppet/development/site.pp > modulepath = /opt/puppet/development/modules > > > On Mon, Mar 22, 2010 at 10:27 AM, Paul Lathrop > wrote: >> >> Over the weekend we noticed an interesting and unexpected behavior >> with environments. I made a change to the way our puppet.conf file is >> generated and distributed, which led to an environment which had been >> defined on a puppetmaster being no longer defined in puppet.conf. >> We'll call this the "core" environement. When clients checked in and >> asked for the "core" environment, the puppetmaster didn't know about >> it. I would have expected an error at this point. However, what >> happened instead was the puppetmaster passed out the configs for the >> "production" environment without complaint. >> >> IMHO this is a bug, but I can see how it might be by design. Any >> comments? Should I file it? >> >> --Paul >> >> -- >> 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. >> > > > > -- > Tony > > -- > 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. > -- 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.
[Puppet Users] Behavior of Environments -- Bug?
Over the weekend we noticed an interesting and unexpected behavior with environments. I made a change to the way our puppet.conf file is generated and distributed, which led to an environment which had been defined on a puppetmaster being no longer defined in puppet.conf. We'll call this the "core" environement. When clients checked in and asked for the "core" environment, the puppetmaster didn't know about it. I would have expected an error at this point. However, what happened instead was the puppetmaster passed out the configs for the "production" environment without complaint. IMHO this is a bug, but I can see how it might be by design. Any comments? Should I file it? --Paul -- 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.
Re: [Puppet Users] Re: external classifier not calling class
In case anyone is looking at this, Asif and I spent some time in #puppet talking about this and we've eliminated: * formatting of the YAML (whitespace, etc.) * missing "environment:" parameter in YAML (doesn't appear to be required) --Paul On Thu, Mar 4, 2010 at 10:08 AM, Asif Iqbal wrote: > still not worky. any help would be appreciated. > > On Thu, Mar 4, 2010 at 1:15 AM, Asif Iqbal wrote: >> Hi I am running puppet client 0.24.7 and puppet master 0.25.1 >> >> Here is my classifier >> >> (root)@sys-ubuntu:/usr/local/bin# cat external.sh >> #!/bin/sh >> # Super-simple external_node script for versions 0.23 and later >> cat <<"END" >> --- >> classes: >> - stb >> - securid::server >> parameters: >> puppet_server: puppet.example.net >> END >> exit 0 >> >> here is the dir structure for the securid module >> >> (root)@sys-ubuntu:/etc/puppet/manifests# ls -lR classes/stb.pp >> -rw-r--r-- 1 puppet puppet 195 2010-02-25 14:51 classes/stb.pp >> >> (root)@sys-ubuntu:/etc/puppet/modules# ls -lR securid/ >> securid/: >> total 12 >> drwxr-xr-x 2 puppet puppet 4096 2010-03-03 22:28 files >> drwxr-xr-x 3 puppet puppet 4096 2010-03-03 23:48 manifests >> drwxr-xr-x 2 puppet puppet 4096 2010-03-03 22:28 templates >> >> securid/files: >> total 0 >> >> securid/manifests: >> total 8 >> drwxr-xr-x 2 root root 4096 2010-03-03 23:48 RCS >> -rw--- 1 root root 376 2010-03-03 23:48 server.pp >> >> securid/templates: >> total 0 >> >> Any idea why puppet client is showing absolutely no sign of any class >> when running it? I tried many other classes with same result >> >> I tried to put a "/bin/date > /tmp/nodes" as the top line of the >> classifier and it is continuously updating that file >> >> (root)@sys-ubuntu:/usr/local/bin# cat external.sh >> #!/bin/sh >> # Super-simple external_node script for versions 0.23 and later >> /bin/date > /tmp/nodes # this generates and updates continuously >> cat <<"END" >> --- >> classes: >> - stb >> - securid::server >> parameters: >> puppet_server: puppet.example.net >> END >> exit 0 >> >> So it does read the classifier file but not making any attempt to call >> the classes >> >> Here is the puppet client report >> >> http://pastie.org/853080 >> >> It stopped working. I had been using the same classifier to manage my nodes. >> >> -- >> Asif Iqbal >> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad thing? >> > > > > -- > Asif Iqbal > PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > > -- > 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. > > -- 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.
Re: [Puppet Users] ssh_authorized_key - same key, different accounts?
On Mon, Mar 1, 2010 at 9:13 AM, Marc Fournier wrote: > Paul: why do you think ssh_authorized_key is terrible ? Do you think > the behaviour should be different ? 1) Lots of intermittent bugs that are hard to reproduce, harder to track down, and yet at scale show up often enough to cause problems. 2) Poorly designed. I've moved on to just using generate() to manage the content of my .ssh/authorized_keys files. Simple, always works. --Paul -- 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.
[Puppet Users] The Foreman & Mailing List Topics
Hey guys, I'm really glad tools like the Foreman exist and are part of the Puppet ecosystem, but I don't use it and I'd kinda like to keep the Puppet list about... Puppet. Sorry to be the jerk here, but doesn't the Foreman have it's own mailing list? Thanks, Paul -- 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.
[Puppet Users] Finding the source of errors
Hello, How are people locating the host that is having problems? Is everyone getting reports via email? I'm only using store, log and unfortunately the log messages don't identify the source host (I haven't investigated the stored reports yet). Curious how others are solving this problem. --Paul -- 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.
Re: [Puppet Users] ssh_authorized_key - same key, different accounts?
On Fri, Feb 26, 2010 at 11:58 AM, Alan Sparks wrote:
> Puppet 0.24.8... I am trying to use ssh_authorized_key to create
> passwordless logins for a couple of accounts. The important thing to
> note is I'm trying to get the source ("r...@somehost" below) as part of
> the key, and the same key needs to be added to two different accounts on
> the system.
>
> It appears that the resource name is the only place I can set the
> originating source (whatever the correct term is) for the key.
>
> ssh_authorized_key { "r...@somehost":
> ensure => present,
> type => ssh-rsa,
> target => '/home/xx/.ssh/authorized_keys',
> key => ' removed for brevity xxx',
> user => "xx",
> require => User["xx"]
> }
>
> So the above will create an authorized_keys value like:
> ssh-rsa removed for brevity xxx r...@somehost
>
> But if I need the same key installed for a different user, I'm stuck --
> I can't use the same resource name to create the "r...@somehost"
> restriction. And I can't see another way to specify that value.
>
> Is there any way to accomplish this, without abandoning
> ssh_authorized_key? Thanks in advance.
> -Alan
Abandon ssh_authorized_key - it is terrible.
My $.02
Regards, Paul
--
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.
Re: [Puppet Users] Module Execution Order
Michael, and Doug,
On reading this thread it looks like there's a lot of frustration
going on. There's a few questions that need answering. I'll list them
below:
1) "how... do we make sure that resources get applied in a predictable
order" (profanity elided)
2) Why does puppet manage dependencies the way it does?
3) How can I keep dependencies manageable?
The answer to #1 is simple, and has been repeated. Use
require/subscribe and/or before/notify. The answer to #2 is more
complicated, and has been hashed over before on the list, but I'll
comment that some people just don't like the dependency model in
puppet. There are other tools out there that use a different model -
personally I prefer Puppet's way. #3 can be answered "the same as you
would in object-oriented development" - develop good abstractions and
minimize your crossing of abstraction boundaries. It sounds like
Doug's manifests don't follow these guidelines, as he says "Within the
bootstrapped modules currently I have a horrible mess of
unmaintainable requires => statements, that are just going to get
harder to maintain as times goes on. I'm afraid to touch it now, for
fear of what will break." Refactoring is in order.
Let me know if I can clarify any of this.
--Paul Lathrop
On Mon, Nov 30, 2009 at 4:08 PM, Michael T. Halligan
wrote:
> I think what Doug is trying to ask is, how the hell do we make sure that
> resources get applied in a predictable order?
>
>
> On Nov 30, 2009, at 4:05 PM, R.I.Pienaar wrote:
>
>> hello,
>>
>>>> require CLASS
>>>>
>>>> from any class starting in 25.1.
>>>>
>>>> This will ensure that every resource in the current class requires
>>> every resource in the provided CLASS.
>>>
>>> I wasn't able to get 0.25 to work. After spending a few weeks in
>>> abject frustration, unable to get the ssl keys to work, i was forced
>>> to give up and go back to 0.24.
>>
>> modules are just convenient locations for files, templates and classes,
>> there isnt a concept of 'do everything in this module' you need to create
>> wrapper classes, for example:
>>
>> class php {
>> include php::install
>> include php::config
>> }
>>
>> class php::xml {
>> package{"php-xml":
>> ensure => present,
>> require => Class["php"]
>> }
>> }
>>
>>
>> include php
>> include php::xml
>>
>> The require function will make this easier as mentioned but on 0.24 this is
>> your best bet
>>
>> --
>> R.I.Pienaar
>>
>> --
>>
>> 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.
>>
>>
>
> --
>
> 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.
>
>
>
--
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.
Re: [Puppet Users] Weird puppet/foreman behavior
You are probably running passenger version 2.2.5 - I ran into this problem as well. See the thread "Serious issue with 0.25.1, at wits end" for the solution. On Wed, Nov 25, 2009 at 2:26 AM, Martin Englund wrote: > I've setup my puppetmaster with passenger & foreman (using external > nodes), and I'm seeing something strange: > when I run two puppet clients concurrently, the config for first one > to run will sometimes be applied to the second. > > E.g. I'm setting the GCOS field for root to include the hostname, and > I see the following after running puppetd manually: > > r...@puppet-tst-martin# head -1 /etc/passwd > root:x:0:0:root at puppet-tst-martin:/root:/bin/bash > r...@puppet-tst-martin# facter hostname > puppet-tst-martin > > r...@blogs-dev# head -1 /etc/passwd > root:x:0:0:root at puppet-tst-martin:/root:/bin/bash > r...@blogs-dev# facter hostname > blogs-dev > > As you can see it has used the $hostname from the first system to set > the string "root at $hostname" on the second system. > > Can someone help me figure out what is going on? > > cheers, > /Martin > > -- > > 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. > > > -- 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.
[Puppet Users] Re: SSL Makes My Brain Bleed
On Fri, Nov 6, 2009 at 4:49 PM, Paul Lathrop wrote: > Hi guys, > > Really could use some help with the way Puppet uses SSL. In my > environment, I need to have 2 puppetmasters. One of them is > responsible for passing out configurations to production machines, the > second one is responsible for passing out configurations to > development machines. When new systems are built, they have a default > puppet.conf which points them at the production puppetmaster. They > retrieve their config, which includes a puppet.conf that makes sure > they are pointed at the appropriate puppetmaster. I have 3 > requirements in this setup. > > 1) I cannot be generating SSL certs by hand. Autosign is a must. > 2) The development puppetmaster has to function as a client of the > production puppetmaster. > 3) Nodes which switch from the production puppetmaster to the > development puppetmaster must continue functioning without SSL > complaining. > > In 0.24.8 I did this, but it was basically opaque magic to me. I > simply copied over /var/lib/puppet/ssl from the one puppetmaster to > the other before starting any of the puppet daemons, and this worked > out happily. > > Now, as I try to set up new 0.25.1 puppetmasters, this is no longer working. > > I copied the /var/lib/puppet/ssl/ca directory from my original 0.24.8 > puppetmaster, and all my 0.24.8 clients happily switched to the new > 0.25.1 puppetmaster. That part was easy. However, nothing I can do > will convince the second 0.25.1 puppetmaster to work as outlined in > the requirements list above. > > I've consulted the IRC channel, and learned much about SSL, all to no avail. > > Happy to provide config files as needed to help me figure this out. > > --Paul > > P.S. I would love to buy support for this, but that decision isn't up > to me at the moment. I just wanted to follow up and let you guys know how I handled this (with help from Luke). First, I set up the production puppetmaster. Once the production puppetmaster was running correctly and serving clients, I used puppetca --certdnsnames "" --generate to generate the signed cert/key files for the development puppetmaster. These ended up under $ssldir for me, so I had to copy them out of there to the development puppetmaster. On the development puppetmaster I started with a clean $ssldir with nothing in it except the CA cert and the signed cert/key files I generated above (in their proper subdirectories). I put ca = false in puppet.conf, and started the development puppetmaster. Finally, on clients, I set ca_server = This works well for me. --Paul -- 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.
[Puppet Users] Checksum Behavior Change
Hiya,
Since upgrading our puppetmaster to 0.25.1, we've noticed a behavior
change which is causing us some problems, and I'm not sure if it is
expected behavior. We have the following resource definition (inside
of a define):
file {
"/var/lib/mysql/extdbfiles/$name":
owner => mysql,
group => mysql,
mode => 2660,
recurse => true,
ensure => directory,
backup => false,
require => File["/var/lib/mysql"];
}
What we're noticing is that our puppet runs are now taking a very long
time and consuming most of the I/O and CPU resources on the machine.
Running puppetd -t under strace reveals that puppet reads the contents
of all the files under this directory (even though we aren't managing
file contents). My immediate thought was that adding checksum => mtime
to the resource definition would solve the problem, but doing so does
not seem to change the behavior.
It smells like a bug to me; intuitively if we aren't managing the file
contents in any way, puppet should not bother calculating checksums of
the contents. Even if that isn't true, specifying checksum => mtime
seems to be the right approach to suppressing calculation of checksums
of the file contents.
For the time being we're working around this by using an exec resource
and chmod, but this is non-ideal. Is this a bug? If so can someone
help me understand this subsection of the puppet internals so I can
contribute a patch?
--Paul
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Multihomed puppet-server Multidomain SSL Problem
On Fri, Nov 13, 2009 at 6:40 AM, Hubert Krause wrote: > > Hello List, > > I have a problem with the CA on my Puppetmaster. This Puppetmaster is > connected to different Networks with different sub domainnames. The Puppet > clients connecting via different Interfaces. There is no routing between > subnets. Only one subnet can connect successfully. This is because the > subject in the Certificate is the name of this subnet. All other clients get: > > Could not retrieve catalog: Certificates were not trusted: hostname not match > with the server certificate > > If I use just the hostname, no client can connect successfully. It seems to > be, that there is allways the need for a single fqdn. > > The puttemaster is served via Passenger and Apache2. > > Is there a way to use the nice to use puppetca tool in this szenario or do I > have to provide as much CAs as I have subnets and do cert signing by hand? Or > is there another solution? You are looking for the puppetmasterd config option certdnsnames. You will have to re-generate your certificates to get this working: 1) Stop puppetmasterd 2) rm -rf /var/lib/puppet/ssl 3) In your puppet.conf file, under the [puppetmasterd] section, add certdnsnames = "colon:separated:list:of:dns:names" 4) Start puppetmasterd Then you'll have to clear the ssl dirs on all the clients as well. --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: SSL Makes My Brain Bleed
Hi Dan, I'm not upgrading, I'm installing a server from scratch. I want to upgrade just my puppetmaster and leave the clients alone for now, because Puppet is a huge part of our infrastructure I can't do it all in one pass. I can get a single puppetmaster up and running. I cannot then get a second puppetmaster to be a client of the first puppetmaster. I also, at this point, can't roll back because SSL is totally screwed in my infrastructure now. So, I'm in fire-fighting mode. Thanks for your help, but I'm definitely done with this. --Paul On Tue, Nov 10, 2009 at 10:43 AM, Dan Bode wrote: > Hi Paul, > > I am currently (but unfortunately slowly) staging this, so far I have done > the following: > > 1. installed .24.8 with passenger, tested > 2, Upgraded to .25.1(head from git) > 3. Reconfigured passenger > 4. Tested client/server on one machine > 5. Upgraded additional client machine to.25.1 > 6. Verified that client can get ssl keys and run puppetd against the server > > Can you get this far? Can you upgrade the CA server and connect client? > > My next step is to stage all of this with 2 puppetmasters using the methods > explained above. > > I will make a post once I get it working (its hard to find the time though, > this will take some effort). > > > regards, > > Dan > > > > > --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: SSL Makes My Brain Bleed
Dan, This looked like exactly what I needed, but I couldn't get this to work either. I'm at my wits end and have given up completely on the upgrade to 0.25.1 at this point. I will now go pester my boss to buy support. --Paul On Fri, Nov 6, 2009 at 9:38 PM, Dan Bode wrote: > Hi Paul,, > > I just want to share how I have done this before. > > 1. Production server is the only certificate authority. > 2. Development server sets ca_server = false > 3. Development server calls puppetd --server production.server > 4. Development server now gets a copy of the production servers certificate > (ca.pem) > 5. Other machines must get signed by the prod server before they can call > the dev server (there is a ca_server command line argument) > > the puppet dev server ensures that any calling machines have been signed by > the production server (its ca). > > Can you try this setup and see if it resolves your issue? > > There is another thread of people discussing passenger issues. I will go > ahead and stage the passenger config with 25.1 this weekend. I will make a > post outlining my findings. > > hope this helps, > > Dan > > > > --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Serious issue with 0.25.1, at wits end
Hi guys,
I'm attempting to move forward with our upgrade to 0.25.1, but today I
hit a show-stopper.
When running 0.25.1 behind Passenger I'm seeing the following
behavior. I'll start up apache+passenger+puppetmasterd fresh, and run
puppetd -t on a client. The *next* client I run will attempt to fetch
the *previous* client's catalog.
This doesn't happen when not running behind Passenger.
I'm sure I'm screwing up my passenger config somehow, but for the life
of me I can't figure out how. Config files below, any ideas would be
HIGHLY appreciated.
--Paul
##
apache2.conf
##
# apache2.conf -- version for puppet-controlled installations
#
# this config file merely sets some important basic configs and
# includes other files; all the truly important stuff is configured in
# one of the include directories.
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# NOTE! If you intend to place this on an NFS (or otherwise network)
# mounted filesystem then please read the LockFile documentation (available
# at http://httpd.apache.org/docs-2.1/mod/mpm_common.html#lockfile>);
# you will save yourself a lot of trouble.
#
# Do NOT add a slash at the end of the directory path.
ServerRoot "/etc/apache2"
# AccessFileName: The name of the file to look for in each directory
# for additional configuration directives. See also the AllowOverride
# directive.
AccessFileName .htaccess
# The following lines prevent .htaccess and .htpasswd files from being
# viewed by Web clients.
Order allow,deny
Deny from all
# DefaultType is the default MIME type the server will use for a
# document if it cannot otherwise determine one, such as from filename
# extensions. If your server contains mostly text or HTML documents,
# "text/plain" is a good value. If most of your content is binary,
# such as applications or images, you may want to use
# "application/octet-stream" instead to keep browsers from trying to
# display binary files as though they are text.
DefaultType text/plain
# PidFile: The file in which the server should record its process
# identification number when it starts. This needs to be set in
# /etc/apache2/envvars
PidFile ${APACHE_PID_FILE}
# These need to be set in /etc/apache2/envvars
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
# HostnameLookups: Log the names of clients or just their IP addresses
# e.g., www.apache.org (on) or 204.62.129.132 (off).
# The default is off because it'd be overall better for the net if people
# had to knowingly turn this feature on, since enabling it means that
# each client request will result in AT LEAST one lookup request to the
# nameserver.
HostnameLookups Off
# Log errors to the right place
ErrorLog /var/log/apache2/error.log
# Include module configuration:
Include /etc/apache2/mods-enabled/*.load
Include /etc/apache2/mods-enabled/*.conf
# Include generic snippets of statements
Include /etc/apache2/conf.d/*.conf
# Include the virtual host configurations:
Include /etc/apache2/sites-enabled/
##
conf.d/500-puppetmasterd.conf
##
PassengerRoot /var/lib/gems/1.8/gems/passenger-2.2.5
PassengerRuby /usr/bin/ruby1.8
PassengerHighPerformance on
PassengerMaxPoolSize 16
PassengerPoolIdleTime 300
PassengerStatThrottleRate 120
PassengerUseGlobalQueue on
RackAutoDetect Off
RailsAutoDetect Off
Listen 8140
SSLEngine on
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
SSLCertificateFile /var/lib/puppet/ssl/certs/puppet.pem
SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/puppet.pem
SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem
SSLCACertificateFile/var/lib/puppet/ssl/ca/ca_crt.pem
# If Apache complains about invalid signatures on the CRL, you
can try disabling
# CRL checking by commenting the next line, but this is not recommended.
SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +StdEnvVars
DocumentRoot /etc/puppet/rack/public/
RackBaseURI /
Options None
AllowOverride None
Order allow,deny
allow from all
##
/etc/puppet/puppet.conf
##
[main]
logdir = /var/log/puppet
report = true
rundir = /var/run/puppet
ssldir = /var/lib/puppet/ssl
vardir = /var/lib/puppet
factpath = /var/lib/puppet/lib/facter
pluginsync = true
reports = store, log
[puppetd]
server = s0005.digg.internal
runinterval = 600
splay = true
environment = production
[puppetmasterd]
autosign = true
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY
manifest = /srv/puppet/production/manifests/site.pp
modulepath = /srv/puppet/production/modules
certname = puppet
certdnsnames = puppet:puppet.digg.internal:s0005.digg.internal
[Puppet Users] Re: authentication issue with passenger (resolved)
How did you resolve this? I'm having this problem now. On Mon, Sep 28, 2009 at 9:16 AM, Allan Marcus wrote: > > I think I have it working now. > > --- > Thanks, > > Allan Marcus > 505-667-5666 > > > > On Sep 28, 2009, at 10:13 AM, Allan Marcus wrote: > >> yes, I have all those settings. Attached are the relevant files. >> >> To sum up: >> >> Everything works fine with webrick >> Nothing I do can make server 0.25.1 w/passenger work with a 0.24.8 >> client >> Only way I can get server 0.25.1 w/passenger to work with a 0.25.1 >> client is to have a a wide open auth.conf file >> >> path / >> auth any >> allow * >> >> Thanks for your help. >> >> --- >> Thanks, >> >> Allan Marcus >> 505-667-5666 >> >> > >> >> >> On Sep 26, 2009, at 8:26 AM, Christian Hofstaedtler wrote: >> >>> >>> Also: please check that you have the required settings in the masters >>> puppet.conf as mentioned in >>> http://github.com/reductivelabs/puppet/blob/master/ext/rack/README >>> >>> If it still doesn't work, please post a full log from master + server >>> for a single client run. >>> >>> Christian >>> >>> >> > > > --~--~-~--~~~---~--~~ > 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+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en > -~--~~~~--~~--~--~--- > > --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Best Practices Rewrite - First Draft
On Fri, Oct 23, 2009 at 2:22 PM, Digant C Kasundra wrote: > > >> If anyone feels up to grabbing this document and running with it, >> please feel free. > > As the original author, I suppose I should take over. Can you send me what > you had? It's available at the links I originally posted. --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Object Dependancies
On Sat, Oct 24, 2009 at 12:42 AM, Douglas Garstang wrote: > I've been putting a lot of puppet pieces together over the last few > days, and I've realised, I think, that you _REALLY_ need to be > explicit with your object dependancies. It looks like puppet just > drags all modules, all nodes, and everything else into one giant > namespace and executes them in NO PARTICULAR ORDER on the target. That is correct, and while it may seem counter-intuitive, this is really a feature. > I see examples on the puppet recipies page that probably won't work > most of the time since puppet executes things in an apparently random > order. For example, the LDAP example at > http://reductivelabs.com/trac/puppet/wiki/Recipes/LDAPClientNSSwitch > makes no mention of the fact that the ldap.conf file needs to be > updated BEFORE the service is started by putting a before=> on the > file, or a require=> on the package. What service? That manifest doesn't declare any service resources. > Or... am I just missing something here? Many Puppet newcomers are startled by this behavior. Some were so startled they went off to join another project. Over time, I've learned to love this behavior, it means my manifests a) *fully* document the setup of a particular configuration and b) Always work, even if someone refactors things and reorders the declarations in the file. This is very important in a setting where multiple sysadmins are working on the same manifests. Regards, Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: BUG? $name inside a definition 'method signature' different to within a body ?
On Sat, Oct 24, 2009 at 3:29 AM, Dick Davies
wrote:
>
> If I have something like this:
>
>
>
> define bar($thing="/tmp/$name") {
> file { $thing: ensure => present }
> }
>
>
> class foo { somedef{ "bar": } }
>
>
>
> puppet will try to create a file called '/tmp/foo' , not /tmp/bar.
> It seems like if I try to access $name inside the 'default arguments'
> bit of a definition,
> it's set to the enclosing class.
>
> I want to get at the name of the definition ('bar' in the above example).
>
> Once i'm inside the body of the definition, $name seems to be set correctly
> (inside templates called from the definition, etc.).
>
> [I'm writing an apache module, and want to infer a default docroot of
> '/docroot/www-vhostname',
> but allow an option to override it.
>
> how can I do that ? (and is this a bug?)
This isn't a bug. It is a natural consequence of scoping.
define bar() {
$thing = "/tmp/$name"
file { $thing: ensure => present }
}
should do what you want.
--Paul
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: genconf generated config aborts
On Tue, Oct 13, 2009 at 11:03 AM, Douglas Garstang wrote: > > Please don't strip it out. The documentation is terrible and this at > least gives me a known good working config. Douglas, You misunderstand. Nigel and I are saying the generated config should be known to *work*; it shouldn't have genconfig set to true in it. It is counterintuitive for the output of --genconfig to be a config file that will not start up a puppetmasterd in "normal" mode. --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: genconf generated config aborts
On Tue, Oct 13, 2009 at 9:58 AM, Nigel Kersten wrote: > I've often wondered about the utility of having that in the generated > config file, and it's bitten me several times. > > Is there a reason we don't strip it out? +1 --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: genconf generated config aborts
Doug, Remove genconfig = true from the puppet.conf file --Paul On Tue, Oct 13, 2009 at 9:51 AM, Douglas Garstang wrote: > > When I run puppetmasterd with the --genconfig option and use that as > my starting puppet.conf file, puppetmasterd dumps the full config to > the screen and then aborts. This is currently happening with 0.25 and > I was also seeing it with 0.24. > > What's up with that? I'm trying to get a baseline good working puppet > config to start. > > Doug. > > > > --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Best Practices Rewrite - First Draft
On Mon, Oct 12, 2009 at 5:09 AM, Jean Spirat wrote: > > Julian Simpson a écrit : >> I swear people who use Puppet are more fertile. Congratulations, Paul! >> >> Julian. >> > this is just that they do not let chaos do the job even in biology, all > is managed in a central repository secured by ssl certificates where the > family keeps his good practice since years now leading to a greater > chance of success. Of course i think Paul should have a look at children > virtualisation because they tend to proliferate quickly as they come > natively with 'i want a brother' service installed and running on port > 3year... :) You guys crack me up. Thanks for all the good wishes! --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Best Practices Rewrite - First Draft
Hey everyone, Well, I really was meaning to get this cleaned up and put on the wiki, but the world seems to conspire against it. First couple of times I sat down to do it, I got Nagios pages. The last time was the real winner, though. Tuesday night I sat down to get feedback integrated and post this to the wiki when my partner called to me from the back room. To make a long story short: on Wednesday morning my son, who was originally due Dec. 31st, decided to make an early appearance. He's in the NICU, and doing great, but my attention is probably going to be elsewhere for awhile. If anyone feels up to grabbing this document and running with it, please feel free. Regards, Paul Lathrop --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: puppet SYN flood
On Tue, Oct 6, 2009 at 2:10 PM, Pete Emerson wrote: > > I'm seeing this in my logs: > > kernel: possible SYN flooding on port 8140. Sending cookies. > Could not call fileserver.describe: # reset by peer> > > I'm running 0.24 with webrick, and have approximately 180 hosts under it. Respectfully... You're insane. It's dumb luck you've gotten this far :-D > I'm guessing that I'm simply hitting the limits of what webrick can do > (I'm working on moving to 0.25 and passenger). Is that true? > What's the simplest way to alleviate the problem in the meantime? Is Turn off puppet. > there a simple way to migrate to 0.24 and passenger, for example? Or > maybe something easier, like configure puppet to run less frequently > (or perhaps only on demand)? > > Any thoughts appreciated. Most people hit this wall at 30-40 hosts, I made it to about 50. I'm shocked you got up to 180. Your only choice is to move to one of the scalable options (Mongrel, Passenger, etc.) --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet support
On Mon, Oct 5, 2009 at 3:55 PM, Allan Marcus wrote: > > I'm working on a support contract with Reductive for puppet support. > My purchasing dept needs to find out if there are any other sources > for paid expert support of puppet? Anyone know of any? > > This is a check the box exercise, I know, but I have to check the > "competition market survey" box. If it helps, I'll provide Puppet support for exactly ten times whatever Reductive is charging :-P --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Best Practices Rewrite - First Draft
Hi guys, As Peter points out, this thread is old. Sorry I dropped the ball, I plan on integrating feedback and getting this updated this weekend. --Paul On Wed, Sep 16, 2009 at 6:40 AM, Peter Meier wrote: > > Hi > > so I took again a look a this rather old thread, as I tried to implement > things as I thought I have understood them. > good idea! Currently I have all site specific stuff in one big module, but like that I might be able to organize it again in modules per each site specific module adaptions. Question: Is autoloading looking in both module directories? so if it's not found in the module in one module directory it's still looking in the other one? I assume so, but as I haven't used it yet I better ask... ;) >>> >>> modulepath option must be set in your puppet.conf file. >> >> yeah, that for sure. But so I assume it looks for ssh::client in every >> ssh module it can find in the different modulepaths. > > After this discussion I thought that modules can be scattered amongst > the various module paths. But this doesn't seem to be the case. At least > my experience shows that puppet simply respects the classes of a module > it founds in the first location, all the classes in a second location > get ignored. > > So the best practices would be to have 2 module paths, one with the > public modules and one module path with the site-specific module - > extensions, prefixed with site? so something like: > > modules/public/apache <- public apache module > modules/site/site-apache <- site specific implementations of apache > > To throw up the question: > > Wouldn't it be nicer if puppet would collect a module's classes from all > module pathes? It would at least make my site specific module changes > look a bit nicer and I still wouldn't have to mix these. However I see > all the problems coming up with this solution. I'm just curious what > other people think. > > cheers pete > > > > --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Camp codefest prelude
On Sun, Sep 13, 2009 at 10:04 AM, Nigel Kersten wrote: > I live here down in the South Bay, so happy to meet up whenever really. s/South/East/g :-) --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppetmaster be client of another puppetmaster?
On Wed, Sep 9, 2009 at 11:47 AM, Keith Edmunds wrote: > > On Wed, 9 Sep 2009 11:33:21 -0700, paul.lath...@gmail.com said: > >> The development >> puppetmaster (puppet.dev.internal) has server = puppet.prod.internal >> in it's puppet.conf, while the machines that point to the development >> puppetmaster all have server = puppet.dev.internal in their >> puppet.conf. > > Thanks, but I was essentially using that configuration, and I had the > certificate errors detailed in the original posting. In that case it is almost certainly a time synchronization issue. --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppetmaster be client of another puppetmaster?
Wow, the other respondents made this somewhat complicated.
I do this right now. Our "development" puppetmaster handles a bunch of
machines, but it itself is managed by our "production" puppetmaster.
We didn't do all this certificate juggling. The development
puppetmaster (puppet.dev.internal) has server = puppet.prod.internal
in it's puppet.conf, while the machines that point to the development
puppetmaster all have server = puppet.dev.internal in their
puppet.conf.
--Paul
On Tue, Sep 8, 2009 at 9:24 AM, Keith Edmunds wrote:
>
> Is is possible to have a puppetmaster that is a client of a different
> puppetmaster? We manage our customers' server via puppet, but one customer
> has a puppetmaster server which looks after their internal systems. We've
> tried the following in /etc/puppet/puppet.conf ("customer" and "us"
> replacing the domain names) on their puppetmaster:
>
> [puppetmasterd]
> certname = puppetmaster.customer.com
> templatedir=/var/lib/puppet/templates
>
> [puppetd]
> server = puppetmaster.us.com
> certname = puppetmaster.us.com
>
> When we run "puppetd -t" on that server, we get:
>
> # puppetd -t
>
> warning: Certificate validation failed; consider using the certname
> configuration option
>
> err: Could not retrieve catalog: Certificates were not trusted:
> SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
> certificate verify failed
>
> warning: Not using cache on failed catalog
>
> Is there a way around this?
>
> Thanks,
> Keith
>
> >
>
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: restart puppetmaster when files change
Yes.
On Wed, Sep 2, 2009 at 6:51 PM, ELTigre wrote:
>
> Do you mean if any of init.pp files of any module change, puppetmaster
> gets the change and reload?
>
> regards,
> Israel.
>
> On Sep 1, 12:31 pm, Paul Lathrop wrote:
>> Why would you want to do this? puppetmaster will notice changes to
>> these files without needing to be restarted.
>>
>> --Paul
>>
>> On Sun, Aug 30, 2009 at 11:34 AM, ELTigre wrote:
>>
>> > I create this class pmaster in order to restart puppetmaster daemon
>> > after /etc/puppet/puppet.conf file change.
>>
>> > class pmaster {
>>
>> > file { "/etc/puppet/puppet.conf":
>> > ensure => "file";
>> > }
>>
>> > service { "puppetmaster":
>> > ensure => "running",
>> > enable => "true",
>> > hasrestart => "true",
>> > subscribe => File [ "/etc/puppet/puppet.conf" ]
>> > }
>>
>> > BUT I have a lot of modules and files inside /etc/puppet folder.
>>
>> > My question is:
>>
>> > What if I want to restart puppetmaster daemon if any file inside /etc/
>> > puppet change?
>> > regards,
>> > Israel.
> >
>
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: scheduling refresh when set to noop
Dan,
Note that the next line says:
"Would have triggered refresh from 1 dependencies"
--Paul
On Wed, Sep 2, 2009 at 3:55 AM, Dan Bode wrote:
> Hi all,
>
> I have encountered some that I dont quite understand.
>
> I am trying to parse log messages to create summaries, and I have seen an
> event that I do not understand.
>
> (//Node[default]/base/syslog/syslog::base/File[syslog.conf]/content) is
> {md5}549c6de7a94e882b19f98ec953c8604a, should be
> {md5}ddf8df9575b220bea7ad07d1ebce64e9 (noop)
> (//Node[default]/base/syslog/syslog::base/File[syslog.conf]) Scheduling
> refresh of Service[syslog]
> (//Node[default]/base/syslog/syslog::base/Service[syslog]) Would have
> triggered refresh from 1 dependencies
> (//Node[default]/base/autofs/Service[autofs]) Would have triggered refresh
> from 1 dependencies
>
> Should it ever be possible for a file content change on noop to Schedule a
> refresh of a service? This error just occurs once and was not reproduced in
> a subsequent run. Any ideas?
>
> (yes I will open a ticket, but first I would like to understand the expected
> behavior)
>
> -Dan
>
>
>
>
> >
>
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: restart puppetmaster when files change
Why would you want to do this? puppetmaster will notice changes to
these files without needing to be restarted.
--Paul
On Sun, Aug 30, 2009 at 11:34 AM, ELTigre wrote:
>
> I create this class pmaster in order to restart puppetmaster daemon
> after /etc/puppet/puppet.conf file change.
>
> class pmaster {
>
> file { "/etc/puppet/puppet.conf":
> ensure => "file";
> }
>
> service { "puppetmaster":
> ensure => "running",
> enable => "true",
> hasrestart => "true",
> subscribe => File [ "/etc/puppet/puppet.conf" ]
> }
>
> BUT I have a lot of modules and files inside /etc/puppet folder.
>
> My question is:
>
> What if I want to restart puppetmaster daemon if any file inside /etc/
> puppet change?
> regards,
> Israel.
>
> >
>
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: arrays, loops, etc
On Thu, Jul 30, 2009 at 1:05 PM, seph wrote:
> I am aware of the whole declarative vs. procedural thing. I do still
> have some trouble with it, though I think fewer problems than my first
> email implied.
>
> In my case, I declare a keystore. It has parameters like owner, group,
> and mode. I'd like to declare which keys are in the keystore as part of
> the keystore declaration. But I see no way to accomplish this.
>
> Instead, I need to declare the keys, and which keystores their part
> of. This is contrary to my model of declaring the keystore. I want to
> say:
>
> define keystore(keys) {
> require Keys[$keys]
> }
>
> define key() {
> # an exec to ensure the key is part of the keystore
> }
>
> keystore{/tmp/k1:
> keys => Key[x],
> }
> keystore{/tmp/k2:
> keys => Key[x, y],
> }
>
> This feels clean and declarative. But, it fails -- both things depend on
> Key[x]. All of the ways I can think to accomplish it, are very
> clunky and much more procedural.
While it may seem clean to you, it doesn't map very well into Puppet.
You can't just have a require hanging out like that in the middle of a
define, just for example. Here's what I'd do (again, not really
understanding the "key" and "keystore" here):
define key($key_arg1, $key_arg2, $keystore) {
# resources to create the key and add it to each keystore.
}
define keystore($keystore_arg1, $path) {
# an exec to create the (empty) keystore
}
key {
"key1":
key_arg1 => value,
key_arg2 => value,
keystore => ["default"],
require => Keystore["default"];
"key2":
key_arg1 => value,
key_arg2 => value,
keystore => ["default", "secure"],
require => Keystore["default", "secure"];
}
keystore {
"default":
keystore_arg1 => value,
path => "/tmp/ks/default";
"secure":
keystore_arg1 => value,
path => "/root/ks/secure";
}
Does that make sense?
--Paul
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Best Practices Rewrite - First Draft
Thanks for all the feedback everyone. I'll be working on a second draft and getting it up on the wiki soon! --Paul On Thu, Jul 23, 2009 at 1:06 AM, David Schmitt wrote: > > Paul Lathrop wrote: >> Hi Puppeteers, >> >> I spent some time tonight making a first pass at what I hope will >> eventually be a good replacement for the current "Puppet Best >> Practices" page on the wiki. I know this needs *tons of work, but I >> hit a good pausing point and decided it was time to ask for feedback >> and contributions. The idea here is to provide some overall guidelines >> to help newcomers to Puppet establish good habits as well as get the >> most out of Puppet, and especially to highlight some common mistakes >> and how to avoid them. >> >> Please take a look and flame away. I need feedback, both positive and >> negative, as well as input as to what the Best Practices actually are >> (Volcane, I'm looking at you!). I especially need to flesh out that >> final section. > > Thanks for picking up that work. It's good to see movement here! > > There are some thing I'm missing: > > * How to arrange modules, what constitutes a module? > > There's this quip "If you ever wonder whether X is running, X should be > a module." Also, some thoughts about how using external modules works? > > * Environments and the workflow surrounding them > > There is already UsingMultipleEnvironments, which has all the technical > stuff. Perhaps a few sentences about how to use the production, testing, > and development environment. > > * An overview of the recommended filesystem layout > > What goes to /etc/puppet, where to put modules and modules in different > environments. > > * Using an external node classifier to split configuration > (node+data+class list) and manifests (modules and manifests) > > * Recommend to replace complete config files instead of "editing" it > in-place. > > > > Thank you again for your time and work! > > Regards, DavidS > > > > -- "My pants growl with the hunger of a thousand bubblebees. And it feels like a Koala crapped a rainbow in my brain!" -MasterShakezula --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: arrays, loops, etc
seph,
You are making a couple of classic mistakes here. For one, thinking of
definitions as "functions" can only end in tears. Definitions are just
ways of abstracting a collection of resources into a single resource.
The second mistake you make is in thinking procedurally. Puppet's
model is declarative, not procedural. You don't loop through an array
and add each item to a keystore. You declare a keystore. You declare
keys, with parameters saying which stores they should be part of.
That's the way you should model this problem to avoid fighting the
tool.
Since I have a hard time understanding precisely what you are trying
to accomplish, I can't be more specific. But I can advise you take a
step back, remind yourself that definitions are not functions (you
don't "call" a gpg::keystore, you "declare" it, and the terminology is
very important in understanding the model), and then try to rethink
the problem in terms of resources.
--Paul
On Thu, Jul 30, 2009 at 9:51 AM, seph wrote:
>
> Inspired by the recent thread titled "Array input of dirs, ensuring
> their existence" I thought I'd write up the problem I'm running into. I
> was chatting on irc about it, I don't think puppet has a clean solution.
>
> Like the other poster, I'm defining an object that takes an array. In
> my case, I'm defining gpg keystore, which can contain a number of
> keys. (actually part of a larger svn repository object) It would be
> called something like:
>
> gpg::keystore{ "/svn/repo/conf/pubring.gpg":
> keys => ["XX", "YYY"],
> }
>
> The obvious way to deal with that array, is to use a require, or to have
> the definition directly call the key function.
>
> gpg::addkey{ $keys:
> store => $keystore, #as passed in as $name
> }
>
> But, this requires that the resources be named with the keyid. Which
> fails when I have multiple keystores -- they can't both define
> gpg::addkey["X"].
>
> It's hard to see a nice solution to this. If puppet supported
> for loops, I could do something. Or if I could pass some kind of
> multidimensional bit in the $name array expansion.
>
> I can get some of it, by inverting the logic. So instead of defining
> keystores with key attributes, I instead define keys and the locations
> they should get added to. But I find that much harder to maintain, and
> it scales differently.
>
> Depending on the details, using inline_template can get part way. But
> it's a lot of extra complexity, and I don't think it solves all
> problems.
>
> I think I'll probably just rethink my setup, so I only have 1 keystore
> per machine, but I'm not very pleased with that. Anyone have any
> better suggestion? Any chance at getting better puppet support for
> this sort of array handling?
>
> seph
>
> >
>
--
"My pants growl with the hunger of a thousand bubblebees. And it feels
like a Koala crapped a rainbow in my brain!" -MasterShakezula
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Best Practices Rewrite - First Draft
Hi Puppeteers, I spent some time tonight making a first pass at what I hope will eventually be a good replacement for the current "Puppet Best Practices" page on the wiki. I know this needs *tons of work, but I hit a good pausing point and decided it was time to ask for feedback and contributions. The idea here is to provide some overall guidelines to help newcomers to Puppet establish good habits as well as get the most out of Puppet, and especially to highlight some common mistakes and how to avoid them. Please take a look and flame away. I need feedback, both positive and negative, as well as input as to what the Best Practices actually are (Volcane, I'm looking at you!). I especially need to flesh out that final section. RST format: http://plathrop.tertiusfamily.net/puppet/best-practice-draft.rst HTML rendering: http://plathrop.tertiusfamily.net/puppet/best-practice-draft.html When this is closer to complete, and when I have permissions to do so, I'll create a new page on the wiki for this. --Paul -- "My pants growl with the hunger of a thousand bubblebees. And it feels like a Koala crapped a rainbow in my brain!" -MasterShakezula --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Vexed by puppet.conf
So here's the really weird part. A week later I come back from
vacation and it all works.
Something odd is going on here and I'm going to investigate more thoroughly.
--Paul
On Tue, Jul 14, 2009 at 10:58 PM, Teyo Tyree wrote:
>
>
> On Sat, Jul 11, 2009 at 1:18 AM, Greg wrote:
>>
>> Paul,
>>
>> I've seen similar behaviour, but it shows up for me with the list of
>> classes. I have a staging server for testing rolling out new puppet
>> configs. Upon getting the new config, puppet seems to use the same
>> server until restarting. I don't have a solution yet, but heres what I
>> know to add to the conversation.
>>
>> I tried using:
>>
>> service { "puppetd":
>> ensure => running,
>> subscribe => File["/etc/puppet/puppet.conf"]
>> }
>>
>> And that worked... For a while... This has 2 interesting side effects
>> for me (on Solaris, at least)
>>
>> 1. It would stop things mid-run. As soon as a puppet.conf was updated
>> it would restart. Mostly that is OK, but if you have schedules,
>> sometimes they get triggered without actually doing any work because
>> Puppet is shutting down. I suspect this is because it checks an item,
>> then receives the shutdown signal and doesn't get to finish the job
>> its doing.
>>
>> 2. *Sometimes* puppet would not shut down correctly. Would get the
>> signal, start to shut down then hang. If I ever figure out why or how
>> its doing this I will submit a bug report. This happens for us only
>> occasionally, and usually SMF kicks in and puts it into maintenance
>> state at which point it kills with a -9 and then waits for someone to
>> svcadm clear it.
>>
>> For us, this started happening long after we upgraded from 0.24.7 to
>> 0.24.8... We also run our staging server on a different port to the
>> production Puppet server to make sure that it doesn't accidentally get
>> used.
>>
>> The only thing I can think of is that maybe the server name gets
>> cached somewhere else other than config - and maybe it isn't being
>> cleaned out when the config is being re-read... I can understand there
>> being a server connection cached for the run, but once its finished it
>> should in theory be cleared out...
>>
>> Greg
>>
>> On Jul 11, 9:31 am, Paul Lathrop wrote:
>> > Dear Puppeteers,
>> >
>> > I'm in desperate need of help. Here's the story:
>> >
>> > When I boot up new machines, they have a default puppet.conf which
>> > causes them to talk to our production puppetmaster at
>> > puppet.digg.internal. Some of these machines are destined for our
>> > development environment, and there is a custom fact 'digg_environment'
>> > that the default config uses to pass out an updated puppet.conf file.
>> > For these development machines, this file points server= to
>> > puppet.dev.digg.internal, which has a node block for the machine that
>> > then has their full configuration.
>> >
>> > This all seemed to work great until recently, and I'm not sure what
>> > changed.
>> >
>> > Now, what happens is that the machine boots with the default
>> > puppet.conf. It talks to the production puppetmaster, and downloads
>> > the correct puppet.conf which points server= to
>> > puppet.dev.digg.internal. In the logs, I see the "Reparsing
>> > /etc/puppet/puppet.conf" message. The report ends up getting sent to
>> > the development puppetmaster (puppet.dev.digg.internal). However, on
>> > subsequent runs, puppetd continues to talk to the production
>> > puppetmaster instead of getting it's config from the development
>> > puppetmaster! After a manual restart of the daemon, it works as
>> > expected. However, manual steps are a big bummer!
>> >
>> > The only change I can think of here is that we switched to Debian
>> > Lenny. Puppet version is 0.24.8. Any help would be appreciated!
>> >
>> > Thanks,
>> > Paul
>>
> The bad news:
> We need to track down why exactly the server parameter is getting cached.
> Additionally, puppet should not restart in the middle of a transaction
> (There is a ticket for 0.25 to make this behavior optional, but currently it
> should restart post transaction. Both of these are bugs and should be
> reported as such.
> The good news:
> Paul, one work around for your issue is to do something completely different
> at provisioning time. What I do is use a ver
[Puppet Users] Re: Resource ordering
On Fri, Jul 17, 2009 at 6:08 AM, Burkholder, Peter wrote: > > I just finished listening to the Configuration Management panel from > OSBridge (on blip.tv). > > Near the end of it, Adam Jacob states that Puppet's resource dependency > ordering is non-deterministic, > and that manifests that work fine 19 times will fail the 20th time. > > Is this true? I'm puzzled that what Luke considers one of Puppet's > strong suits is derided by > others as its Achille's heel. This is true w/o being the whole story. Puppet obeys declared dependencies, but if you choose not to declare your dependencies, you are running the risk of things happening in the wrong order. To me, this is a bug in your manifests, not a bug in Puppet. Adam doesn't believe this is a good thing. However, I have found that it gives me a couple advantages: a) it forces me to really think about the order of events and determine what is actually dependent on what; b) it allows me to ignore the order of things when it doesn't matter, but often reveals situations where it *does* matter and I didn't think of it; c) there is potential for future optimization; d) I find explicitly declaring dependencies to be preferable to re-arranging lines in a file and finding things magically working. --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Vexed by puppet.conf
Dear Puppeteers, I'm in desperate need of help. Here's the story: When I boot up new machines, they have a default puppet.conf which causes them to talk to our production puppetmaster at puppet.digg.internal. Some of these machines are destined for our development environment, and there is a custom fact 'digg_environment' that the default config uses to pass out an updated puppet.conf file. For these development machines, this file points server= to puppet.dev.digg.internal, which has a node block for the machine that then has their full configuration. This all seemed to work great until recently, and I'm not sure what changed. Now, what happens is that the machine boots with the default puppet.conf. It talks to the production puppetmaster, and downloads the correct puppet.conf which points server= to puppet.dev.digg.internal. In the logs, I see the "Reparsing /etc/puppet/puppet.conf" message. The report ends up getting sent to the development puppetmaster (puppet.dev.digg.internal). However, on subsequent runs, puppetd continues to talk to the production puppetmaster instead of getting it's config from the development puppetmaster! After a manual restart of the daemon, it works as expected. However, manual steps are a big bummer! The only change I can think of here is that we switched to Debian Lenny. Puppet version is 0.24.8. Any help would be appreciated! Thanks, Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: subscribe implies require?
Dan,
You are correct: subscribe is a superset of require, and notify is a
superset of before.
--Paul
On Thu, Jun 18, 2009 at 7:42 AM, Dan Bode wrote:
> I noticed in that many of the modules in lab42 have resources that use
> require and subscribe for the same resource.
>
> Doesn't subscribe imply require? (and notify implies before)
>
>
> class syslog
> file {
> "syslog.conf":
> ..
> }
>
> service {
> "syslog":
> ..
> require => File["syslog.conf"],
> # isnt require implied by subscribe?
> subscribe => File["syslog.conf"],
> }
> }
>
>
> thanks,
>
> Dan Bode
>
> >
>
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Camp Oct 1-2 at SFSU
On Fri, Jun 12, 2009 at 12:15 AM, David Schmitt wrote: > Yes, something I forgot to mention: I'm totally open to other people > interested in this project to join, commit, and maintain their modules. > > > Regards, DavidS I'll be glad to join this effort. How do I add myself to the project? --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Moving to new puppetmaster - certificates
On Wed, Jun 10, 2009 at 9:16 AM, Jason Antman wrote: > > Unfortunately I haven't been able to find anything in the docs... > > I just built a new puppetmaster to replace my testing install on an old > box. The hostname is different, and obviously the master certificates > are different. What needs to be done to the clients to get them to play > nice with the new box? The way I've done this is: 1) Stop puppetd and puppetmasterd on the new box. 2) Delete /var/lib/puppet/ssl on the new box. 3) copy /var/lib/puppet/ssl from the old box to the new box. 4) Start puppetmasterd on the new box. 5) Start puppetd on the new box. You may have to tweak the order as I'm going from memory. The basic idea is that you need to have the CA cert from the old box in place before the daemons create the host certificate. This makes sure the new host certificate is signed by the same CA, and should allow existing clients to connect w/o problems. I think I also needed to tweak the certdnsnames parameter. Sorry this isn't more coherent. Next time I do it, I'll make a wiki page. Hopefully this puts you on the right track at least. --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Using custom facts for the first time
Paul, A custom fact is probably the wrong way to implement this, actually, unless you have servers in multiple locations where the day of the week differs from server to server. Custom facts are intended for information that can only be computed at the client end. For something like the day of the week you should use a custom function instead. See: http://reductivelabs.com/trac/puppet/wiki/WritingYourOwnFunctions for more information. --Paul On Thu, May 28, 2009 at 9:34 AM, paul matthews wrote: > Thanks to Saurabh pointing me in the right direction, the solution I found > to getting basic custom facts to work were as follows:- > > 1. On the puppetmaster in your modules directory create a facts module with > subdirectory files. In this add any of your custom .rb scripts > > # ls /etc/puppet/modules/facts/files > day_of_week.rb > hardware_platform.rb # = wiki example > > > 2. On the puppetmaster in /etc/puppet/puppet.conf I added:- > pluginsync = true > factpath = $vardir/facts #vardir = /var/lib/puppet > > 3. On the puppetmaster in /etc/puppet/fileserver.conf I added:- > [facts] > path /var/lib/puppet/facts > allow yourdomain.com # I think these 3 lines are optional > deny *.evil.example.com # " " > allow 10.0.0.0/24 # " " > > 4. On the server I added the file /etc/profile.d/facter.sh containing > export FACTERLIB=/var/lib/puppet/facts > Not entirely sure if this step is necessary but I saw it on another posting > > 5. On the client I didn't seem to need to do anything to the config files > and the only change needed to pick this up was add the --factsync param to > puppetd > All being well you should see something like the following on fhe client:- > > # puppetd -vt --factsync > info: Retrieving facts > notice: /File[/var/lib/puppet/facts/day_of_week.rb]/ensure: created > notice: /File[/var/lib/puppet/facts/hardware_platform.rb]/ensure: created > info: Loading fact day_of_week > info: Loading fact hardware_platform > info: Caching catalog at /var/lib/puppet/localconfig.yaml > notice: Starting catalog run > > To then access the variables that you have defined simply refer to them in > your manifest eg. $day_of_week or $hardware_platform > > It is probably worth noting that this may not be the best way of doing > things. The example used in the wiki using the 'custom' module I could not > get to work without file errors relating to /facts. I'm sure there is added > benefits in using the wiki example but hopefully this may get someone over > the first hurdle > > Paul > > > > > > 2009/5/28 paul matthews >> >> Superb, thanks for that. I think my confusion was missing the point that >> you need a specific module for facts pointed to by factpath rather than >> tacking on a plugins/facter directory under an existing module >> >> 2009/5/28 Saurabh Verma >>> >>> paul matthews wrote: >>> > Hi, >>> > I'm attempting to create a custom fact to tell me the day of the week >>> > ( to be used as a file suffix for vmware snapshots). I've followed the >>> > wiki which advises deploying facts via modules for releases >0.24. As >>> > I understand this means :- >>> > >>> > 1. creating a plugins/facter directory under an existing (or new >>> > module) >>> > 2. dropping in your ruby based facter (.rb) script to that directory >>> > 3. adding the following to /etc/puppet/puppet.conf on the master >>> > >>> > [main] >>> > pluginsync = true >>> > factpath = $vardir/lib/facter >>> > >>> > Aftre this things get a bit hazy for me. The Adding Facts wiki page >>> > http://reductivelabs.com/trac/puppet/wiki/AddingFacts talks about :- >>> > >>> > >> Create a directory called facter/ somewhere, and set the >>> > environment variable $RUBYLIB to its parent. You can then run facter, >>> > and it will import your code: >>> > >>> > >> host:~$ mkdir -p ~/lib/ruby/facter ; export RUBYLIB=~/lib/ruby >>> > >> host:/tmp$ cp /path/to/hardware_platform.rb $RUBYLIB/facter >>> > >> host:/tmp$ facter hardware_platform >>> > >> SUNW,Sun-Blade-1500 >>> > >>> This is to test your scripts , its nothing related to custom facts >>> distribution per se. >>> > Do I need to do this or is this deprecated with modules? Also, what >>> > does the factpath do? Does that need to exist on master and clients. >>> > The final step is to run puppetd with --factsync on (I guess) a >>> > client. On mine it returns an error >>> > >>> > # puppetd -vt --factsync >>> > info: Retrieving facts >>> > err: /File[/var/lib/puppet/facts]: Failed to generate additional >>> > resources during transaction: Fileserver module 'facts' not mounted >>> > >>> Did you configure you fileserver.conf on puppetmaster for "facts" >>> module i.e did you add following in your fileserver.conf ? >>> >>> [facts] >>> path /var/lib/puppet/facts >>> >>> here "/var/lib/puppet/facts" is your path to "facts" file server module >>> on puppetmaster where you will put your custom scripts that will sync >>> to puppet clie
[Puppet Users] Re: File contents into a variable (once it exists)
Simon,
It seems like you are trying to work with puppet as though it were a
procedural language, not a declarative one. You should try to think of
a way of expressing your user abstraction in terms of declarative
statements instead of as a series of steps. If you must do a series of
steps, you might consider writing a custom resource type for your
needs.
--Paul
On Mon, May 18, 2009 at 11:31 AM, Simon Kuhn wrote:
>
> I'm trying to approach ssh authorized_keys distribution from another
> angle. It seems like the standard method is to either put the ssh
> public key into a variable in a puppet manifest or to place the file
> within the puppet file hierarchy. I'm not happy with either of these
> options, because I would like to create a user from start to finish as
> hands-off as possible (including ssh key generation and propagation).
>
> So I want the following to happen:
>
> - Define a user in a puppet class
> - Have puppet create that user's home directory and ssh public/private
> keys on the main server
> - Export public keys into that user's authorized_keys file on every
> server
>
> I have a method that does this (or so it seems), but the main problem
> is that without some tomfoolery I can't figure out how to read a
> file's contents into a variable only AFTER that file is created by an
> exec command.
>
> I have the following (after 'user' has been called):
>
> if $hostname == puppet {
> exec { "create-ssh-key-$n...@$domain":
> command => "ssh-keygen -t rsa -C '$name@
> $domain' -N '' -q -f /home/$name/.ssh/id_rsa",
> path => "/usr/bin:/bin",
> creates => ["/home/$name/.ssh/id_rsa","/home/
> $name/.ssh/id_rsa.pub"],
> require => [ User["$name"], File["/home/
> $name/.ssh/"] ],
> before => Ssh_authorized_key["$n...@$domain"],
> user => $name,
> }
>
> @@ssh_authorized_key { "$n...@$domain":
> ensure => present,
> key => generate("/usr/bin/cut","-f2","-d ","/
> home/$name/.ssh/id_rsa.pub"),
> target => "/home/$name/.ssh/authorized_keys",
> type => ssh-rsa,
> user => $name,
> name => "$n...@$domain",
> require => User["$name"],
> }
> }
>
> Ssh_authorized_key <<| name == "$n...@$domain" |>>
>
> However, unless I completely remove the ssh_authorized_key call until
> the user exists, I wind up with this error:
>
> May 16 00:44:12 puppet puppetmasterd[22843]: Failed to execute
> generator /usr/bin/cut: Execution of '/usr/bin/cut -f2 -d /home/
> user/.ssh/id_rsa.pub' returned 1: /usr/bin/cut: /home/user/.ssh/
> id_rsa.pub: No such file or directory at /etc/puppet/modules/users/
> manifests/init.pp:34 on node puppetmaster
>
> I've tried a number of different requires, befores, and splitting
> things into multiple files/classes/defines to try to force the
> execution order that I want but to no avail. It seems like 'generate'
> is always run early, and so the user and id_rsa.pub file haven't been
> made yet.
>
> I finally used the following tactic:
>
> key => file("/home/$name/.ssh/id_rsa.pub","/etc/ssh/ssh_host_key.pub")
>
> so that the first execution puts the host's public key into
> authorized_keys (which serves no purpose, but it's the same format and
> that file will always exist) and the second execution does the right
> thing. But it's pretty gross, and it means users will take a longer
> time than necessary to fully propagate.
>
> Is there some method that I'm overlooking to force puppet to schedule
> 'ssh_authorized_key' after 'exec' in this case?
>
> --
> Simon Kuhn
>
> >
>
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: long catalog run times and random connection timeouts
On Mon, May 4, 2009 at 7:55 AM, Michael Conigliaro wrote: > > I'm actually not sure. How do I determine that? I just use the redhat > rpms from the epel repository, and I don't remember seeing an option for > that anywhere. If you aren't sure what you are using, you are using webrick. The problem you're running into is probably the scalability wall. How many clients are you running? Take a look at the http://reductivelabs.com/trac/puppet/wiki/PuppetScalability page. I have had great success with Mongrel+Nginx, but Passenger also looks promising. --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Camp
On Sun, Apr 19, 2009 at 12:23 PM, Andrew Shafer wrote: > We are organizing a Puppet mini conf. Yay! > The time frame is Septemberish, but no locations or dates are set, which is > essentially the point of this email. > > For locations, I'm proposing Salt Lake City, UT, Portland, OR, or somewhere > in or around SF/Silicon Valley with my list of pros and cons. Any of these are fine with me, though I can probably be more helpful in organizing a Bay Area thing. > The format I have in mind is 2 days of experience reports, and workshops > showing and sharing what people are doing, leaving a third of the time for > unconference style discussion. > > The cost will be minimal, something like $100, enough to cover the venue, > some food and probably a T-shirt. > > Looking for opinions on the location and dates, then volunteers interested > in presenting, leading discussions or helping to organize things. Be glad to help out and/or present. Let me know what you need. --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: CA different than hostname?
On 4/20/09, seph wrote: > The first, is a design question. Since I expect to eventually have > multiple puppetmaster servers, I'd like to name this one to be named > puppet1.example.com. But I'd like my clients to connect via a cname as > puppet.example.com. Is this pretty standard? Is there some more common > way? That's basically how we're doing it; it works great. > puppetmaster seems to want to create the CA certs as > puppet1.example.com. I assume one of the configuration parameters would > tell it otherwise. I'm not sure which. From the docs, certdnsnames > sounds right, though I don't know which section of the config file to > put it in. certdnsnames is indeed the config parameter you are looking for. You want to put it in [puppetmasterd] I think. --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet and pushing changes
On Thu, Apr 9, 2009 at 11:03 AM, Kyle Cordes wrote: > Luke Kanies wrote: >> In the meantime, it's easy enough to skip the daemon mode. > > Maybe I'll do that next time I repackage a new version. > > (Or maybe, and this is a dream rather than a request, the good folks > working on the official Debian packaging will decide that running it in > cron via a file in /etc/cron.whatever is more genuinely Debianish, and > they'll set it up that way.) I'd much prefer you cron folks keep configuring it manually :-P I *like* Puppet as a daemon, leave the Debian package alone! (only half kidding) --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Licensing and Copyright
On Mon, Apr 6, 2009 at 12:15 PM, Luke Kanies wrote: > > Hi all, > > I fear this discussion will quickly devolve into a recursive flame- > fest, but it needs to be broached, so here we go. Note that I kind of > think this is more of dev topic than users, but I want to make sure > everyone knows the conversation is happening and can easily > participate. This is also likely to be the first of a series of > conversations I'll be starting to try to paper over the lack of > organization and process we've had in the past. > > First, I want to be clear that this is me seeking your input - we > haven't decided on anything, and I'm starting this thread so we have > the necessary data to make a decision. We have to be conscious that > Reductive Labs is a commercial company, though. My development of > Puppet and the money I make around it feeds my family and keeps us > housed, allowing me to focus on it full time. > > I think our focus on building community stands on its own, but the > contributor list is an equally clear indication that being paid to > work on Puppet results in a lot more work being done on Puppet - of > the top ten Puppet contributors (http://www.ohloh.net/p/puppet/contributors > ), 5 have been paid by their companies to do the work, and 4 have been > paid specifically by Reductive Labs (me, Andrew, Rick, and Ben/ajax). > One of my goals in this discussion is to figure out the best way to > pay more people to work on Puppet, by having enough money to hire > them. (Incidentally, I should be posting a job description for a full- > time programmer at Reductive Labs this week.) > > Finally, if you have concerns about this topic that you don't feel > comfortable voicing publicly, feel free to contact me directly. > > So: > > We've never done a very good job of having much of a licensing or > copyright strategy for Puppet and the tools around it. While all of > the projects have a license, there's no documentation on how to > maintain the license (e.g., whether every file should have a license > header), and there's a bit of confusion around the license itself > since Puppet's current license file says 'GPL2 or later'. > > As to copyright, we're *pretty* good at maintaining that, especially > since we switched to Git, since everyone who commits has their email > address recorded with the commit, but we don't have an official > project policy published anywhere one way or another, and we just > haven't been tracking copyright. > > For both the project and my company, I think we need to develop > complete policies around these two topics, and then spend time > actually maintaining them. > > Given that we have a license but no policies or history around it, I > think it's worth revisiting the basics, and assessing what's best for > the project. I expect that Reductive Labs would fund any work that > needs to be done to enact these policies, but as always, I'll do what > I can to encourage community involvement. > > I think there are essentially two decisions to make, with some details > around them: > > 1) Should we use a completely open Apache-style license, or a > reciprocal/viral GPL-style license? > 2) Should we require copyright assignment of any kind? > > Going with those questions, we have two priorities: > > 1) Maximize ability to grow and sustain a community > 2) Enable Reductive Labs to increase its funding of development > > This second point is important to be obvious about - like Pixar > (http://www.nytimes.com/2009/04/06/business/media/06pixar.html > ), we make money so we can write software, and Puppet clearly needs > more development time than we're spending on it right now. There are > further tools beyond Puppet that we also want to create, but we need > enough developer manpower to be able to do so. > > I expect this point to be the biggest source of contention, so all I > can really say is, Reductive Labs isn't suddenly morphing into an anti- > community commercial vendor who uses open source for marketing but > doesn't actually believe in it. I'm asking *you*, right now, how we > can tune our licensing and copyright policy to best meet your needs. > If that doesn't satisfy you, I'll be glad to fly out and discuss it > with you for $5,000 USD per day. :) > > Really, though, one of my other goals here is to be more transparent > about how Reductive Labs hopes to make money and continue funding > development. Many people in the community are curious on this front > for many reasons, and I think it's important it be clear. > > Here is some reading on this subject, to kind of set the context: > > http://madstop.com/2009/02/28/the-most-freetm-way-to-make-money-from-open-source/ > (This article came out much more in favor than Open Core than it was > supposed to; the article was supposed to be a question, rather than an > answer.) > > http://blogs.the451group.com/opensource/2009/03/24/transparency-the-first-step-towards-open-source-participation-for-proprietary-vendors/ > > http:
[Puppet Users] Re: A simple function to load external class attributes
+1, this idea is doused in awesome sauce.
On Mon, Mar 30, 2009 at 7:38 PM, Luke Kanies wrote:
> Hi all,
>
> We at Reductive Labs keep running into clients who need something like
> an attribute class - that is, for a given module, they want a single
> class that handles all of the variable setting and overriding, and
> then they want that attribute class to be merged into all or some of
> the classes in the module. (Teyo has especially been pushing me to
> solve this problem.)
>
> This looks a lot like composition, which Puppet doesn't currently
> support - you include one class's behaviour in another, rather than
> inheriting. This lack of composition is, I think, partially why
> people keep trying to do variable inheritance and getting frustrated
> that it doesn't work well.
>
> While doing a code audit for a client this week, though, I found their
> solution to this problem to be close enough that I was able to take it
> almost the rest of the of way. They had what amounts to a 'data'
> module with a class for each class that needed external data, and then
> they defined all of the attributes in that data class. That is, if
> you have an 'apache' class, you'd also have a 'data::apache' class
> with a bunch of attributes. Then all of your usage of those
> attributes would say '$data::apache::variable'.
>
> The big benefit of this model for them is that it allows clean change
> control of all of the important configuration data (as opposed to
> manifest structure and resources), and, again, it looks a lot like
> composition. In their case, they branch this module for all of their
> environments, but none of the other modules.
>
> As soon as I saw it, though, I thought of a way that might make it
> better, so I wrote a function that enables that way (and a converter
> for their existing data).
>
> Basically, I created (and have attached) a simple function that knows
> how to find and load a yaml file from a data directory, and it loads
> that file as a hash of parameters that should be set as local
> variables in the class.
>
> For instance, say you have this class apache; you'd create this file:
>
> data/apache.yaml
>
> And put all of the attributes you care about in that file.
>
> Then, in your apache class, you'd say:
>
> class apache {
> load_data()
> ...
> }
>
> It would pick the right file based on the class name (although the
> current function allows you to specify the class, also), load it, and
> set all of the contained attributes as local variables in the class.
> So, if your apache.yaml file looks like this:
>
> ---
> host: myhost.com
> port: 80
>
> Then this 'load_data' call is equivalent to this Puppet code:
>
> class apache {
> $host = "myhost.com"
> $port = 80
> }
>
> The function is currently set up to support one big 'data' directory
> for all of your modules. One could argue that it should instead
> support a data file per module, but the benefit of this one big data
> directory is that it makes it *much* easier to write sharable modules
> - you extract all of your site-specific data into this data dir, and
> you share the module with essentially no site data. It's probably
> most reasonable to support an in-module data file and a site-wide data
> directory to make it easy to provide defaults.
>
> I'm beginning to think that this, or a function a lot like this,
> should be included directly into Puppet, and data should get loaded
> automatically, rather than requiring the call to the 'load_data'
> function.
>
> What do you think?
>
> --
> Fallacies do not cease to be fallacies because they become fashions.
> --G. K. Chesterton
> -
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
> >
>
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: error just trying to use puppetmasterd.conf
puppetmasterd.conf is deprecated, and all the *d.conf files are known to cause problems if they exist and you are using a newer version of Puppet. Remove all of these, and use puppet.conf instead. What version of Puppet are you using? I recommend getting the latest stable version, which I believe is 0.24.7 at the moment. Regards, Paul Lathrop On Wed, Mar 18, 2009 at 8:09 AM, Jonathan Mills wrote: > > Situation: I have a new puppet install that I'm learning how to use. > Puppetmasterd runs fine when there are no explicitly defined > puppetmasterd directives in any conf file. I am trying to use a > puppetmasterd.conf, however, and tweak some settings. I generated my > puppetmasterd.conf file with --genconfig, of course. In trying to use > this file, I get an error before I've even changed a single setting! > What have I done wrong? > > [r...@dcpuppet01 puppet]# /etc/init.d/puppetmaster start > Starting puppetmaster: undefined local variable or method `detail' for > # > [FAILED] > [r...@dcpuppet01 puppet]# > > > > Cheers! > > Jonathan > > > > --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: puppetmaster stops responding to some clients?
Daniel, Yep, you've hit the scaling wall. You need to check out http://reductivelabs.com/trac/puppet/wiki/UsingMongrel and switch to Mongrel sooner rather than later :-) --Paul On Thu, Mar 12, 2009 at 6:06 PM, Daniel Pittman wrote: > > Paul Lathrop writes: > >> I started seeing these symptoms when my puppetmaster was overloaded >> with more clients than Webrick could handle. Are you running Webrick >> or something else? > > Whatever the default server is, so presumably Webrick, yes. > > Regards, > Daniel > > > > --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: puppetmaster stops responding to some clients?
Daniel,
I started seeing these symptoms when my puppetmaster was overloaded
with more clients than Webrick could handle. Are you running Webrick
or something else?
--Paul
On Wed, Mar 11, 2009 at 11:17 PM, Daniel Pittman wrote:
>
> G'day.
>
> We are running into a regular problem, which I can't track down, where
> puppetmaster will simply stop responding appropriately to clients.
>
> I have exhausted my ideas for debugging this, so I turn to y'all for
> advice on where next to look in terms of tracking down and killing the
> root of these issues.
>
> The errors, on the client side, are roughly:
>
> Mar 12 16:15:27 amhocn04 puppetd[17153]: Could not call
> puppetmaster.getconfig: # nil:NilClass>
> Mar 12 16:15:27 amhocn04 puppetd[17153]: Could not retrieve catalog: private
> method `split' called for nil:NilClass
> Mar 12 16:15:27 amhocn04 puppetd[17153]:
> (//Node[default]/apt/Apt::Key[backports.org]/Exec[/usr/bin/apt-key add
> /etc/apt/backports.org.key]) Dependency file[/etc/apt/backports.org.key] has
> 1 failures
> Mar 12 16:15:27 amhocn04 puppetd[17153]:
> (//Node[default]/apt/Apt::Key[backports.org]/Exec[/usr/bin/apt-key add
> /etc/apt/backports.org.key]) Skipping because of failed dependencies
> [... and so forth for the rest of the cached config ...]
>
> On the server side, nothing. Specifically, no errors in the rails
> related logs, no errors in syslog, nothing useful shows up when running
> puppetmaster with debug enabled, etc.
>
> So, hints? It seems to be that the puppetmaster either refuses
> connections part way through the transaction, or that something gets
> significantly out of sync.
>
> Both ends are running puppet{,master} 0.24.5-3~sd-backport-1, which is
> our backport of the 0.24.5 puppet release on Debian etch.
>
> Regards,
> Daniel
>
> >
>
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Community: How to deal with attempts at sabotage
On Thu, Mar 5, 2009 at 10:27 PM, Andrew Shafer wrote: > > The voice of reason has mostly prevailed in my opinion, which is the > sentiment that the right approach is not to worry. > > Trying to be as objective as possible, AJ has contributed to the Puppet > community. He has submitted patches, triaged bugs and been helpful in both > IRC and email. He is still quite helpful in #puppet, and though sometimes a > tad snarky, he's not overtly subversive. He made a comment when chef was > only about a week old that he was surprised that more people weren't > changing or interested in chef from Puppet (I believe this was in #chef, > which I usually join and occasionally participate in). There is a psychlogy > to constantly convincing others of things in order to convince ourselves. > *shrug* > > The bottom line is chef exists for a complicated set of social, economic and > technical reasons. I won't pretend to understand them all or that some of > the circumstances are not personally emotive. That's all spilt milk under > the bridge, as it were... > > While some of the motivation for chef is clearly economic, I think 'sleazy' > is a bit harsh. Both of these frameworks are released as free and open > source. What long term business models evolve from that remain to be seen. > Is Ruby stealing people from Python or C++? The long term value of Reductive > Labs and Opscode are going to be determined by execution and intangibles, > not subtle differences in how to solve a technology problem. And to be > clear, that's really what we are talking about. > > I have read enough chef code, cookbooks and discussion, in addition to > having the context of discussions in this mailing list, to know chef > admittedly learned a lot of lessons from Puppet. In my opinion, there were > also some lessons that were ignored. > > The fact is this is 2009. Information flows at the speed of light. With just > a tiny bit of effort, people can find whatever they want, plus everything > related to that in seconds. I can't fully explain what I mean by this now, > but Puppet has and will derived benefit from chef and Opscode, directly and > indirectly. If nothing else, chef helped us to focus. There is plenty of > stuff going on behind the scenes and there is no point trying to police the > flow of information on public lists and channels. > > Puppet is awesome, except when it isn't, and the best way to move things > forward is to address those and get back to making more awesome. That's what > we need to be worried about. Just more awesome, this is not a zero sum game. > > 0.02 > Andrew *applause* --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Community: How to deal with attempts at sabotage
On Wed, Mar 4, 2009 at 1:32 PM, Luke Kanies wrote: > Hi all, > > The underlying assumption of membership in any community is that your > participation is at worst neutral, and if possible positive. > Communities, online or off, generally do what they can to protect > themselves from detrimental influences, which is where policies, > politeness, moderators, and all that come into play. > > Puppet's community has been both fortunate and awesome, in that it > requires almost no moderation or control; we've only had to kick a > couple of people out of our IRC channel and they were clearly just > insane or spammers, and we've never had to remove anyone from our > mailing list other than spammers. > > We've recently had some problems where one or two people are > maintaining their presence in the Puppet community solely as a way to > recruit people out of Puppet and into their community, at the expense > of ours, and I think we need a straightforward community policy on this. > > Overlapping communities are awesome, and I'm all for your encouraging > Puppet community members to join other communities *in addition to > ours*, but it seems a bit insane for us to support people coming into > our community just to evangelize competing products and communities. > > My take is that if your participation in our community is *solely* for > purposes of shrinking it by drawing people into your community at the > expense of ours, then you should be kicked from our community. > > What do others think? Should it be acceptable to privately contact > members of our community, encouraging them to leave? Having been waffling a bit on this question myself, I'd like to say that I agree with those who say ignore it. Community members should publicize attempts to speak to them that they feel are in poor taste, by responding on-list. The Puppet community is pretty chill and welcoming, let us strive to maintain that. I don't think a specific effort needs to be made to make non-contributing folks who evangelize for another project go away -- this is a self-limiting problem, people only have so much patience for that crap. Reductive Labs as a company should deal with attempts to snipe their clients away however they see fit; that's not as much a Puppet community issue (but feel free to tell us about it, because it's sleazy as hell and enough to make me evangelize *against* the perpetrators.) My $.02, of course. --Another Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: genmanifest question
Kevin, You misunderstand; --genmanifest generates the resources needed to run Puppet itself. You probably want to look into the 'ralsh' command. --Paul On Thu, Mar 5, 2009 at 9:01 AM, kevin wrote: > > Hi all, > > puppet --genmanifest : > > Should this not introspect all the packages on my system? I ran it > just now on ubuntu intrepid, puppet 24.7, and it just gave me puppet > related things... > > Is it not possible to configure a system using the packages I want, > and then run puppet --genmanifest to retrieve the puppet code to > reproduce it? > > > --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Could not request certificate -> big logs, full /var, failure
On Thu, Feb 26, 2009 at 9:58 AM, Kyle Cordes wrote: > I heartily agree; what I am looking at is the difference between: > > a) it is possible to type "sudo rm -rf /" > > b) making rm default to a path of "/" and default -r -f options ON, and > include it in sudoers by default. > > > Obviously B is an awful idea, whether it's done by the tool or by the > distribution. If I was the author of rm, and I saw a distribution do > such a thing, I'd recoil in horror and go find a way to make it harder > to use my tool badly, while also begging any distro doing that to please > stop. Ah, there's the key difference. What I would do is file a bug report calling them out for their horrible use of 'rm' while not trying to make it hard to use intentionally-added functionality. Cool, we can agree to disagree on that :-P --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Could not request certificate -> big logs, full /var, failure
On Thu, Feb 26, 2009 at 9:38 AM, Mike Renfro wrote: > > On 2/26/2009 11:14 AM, Paul Lathrop wrote: >> On Thu, Feb 26, 2009 at 8:49 AM, Kyle Cordes wrote: >>> I am sure there is a good use for some aspect of the -w 0 feature; the >>> part I don't think there is a good use for, is writing 70,000 entries >>> per minute to syslog, or for trying to connect in a tight loop for 12 >>> hours. I am sure there is a way for it to do what you need it to do, >>> without doing those other things. > >> Your complaint is valid; this should not be the default behavior, and >> it *isn't* -- your beef should be with the package maintainer who >> misconfigured the tool, not with the tool itself. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509566 is probably tbe > most relevant discussion, and matches my dim recollections. Back when I > first started using puppet, "-w 0" caused the first run of puppetd to > ask for a cert, and if it didn't get a response, it would exit out and > wait for you to restart it. But any other argument to -w would cause > puppetd to hang the boot process until its certificate got signed. Both > were annoying, but at least "-w 0" let you log into the system to > restart puppetd. > > Sometime later, "-w 0" was no longer a special case, and caused puppetd > to behave like you're seeing now: tight loops checking for certificates > and writing errors into the logs. If "-w 120" doesn't cause a puppetd > hang any more, then I'd guess that ought to be the default again. I can > afford to burn 2 minutes on reinstalling a new system (I've got base > preseed installations down into the 5 minute range, and can get a > cluster node tied to the Active Directory and install all my software > within an hour or so). Thanks for the link. There *is* a Puppet bug here; the documentation doesn't match the behavior. I'll take a look. --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Could not request certificate -> big logs, full /var, failure
On Thu, Feb 26, 2009 at 8:49 AM, Kyle Cordes wrote:
> I am sure there is a good use for some aspect of the -w 0 feature; the
> part I don't think there is a good use for, is writing 70,000 entries
> per minute to syslog, or for trying to connect in a tight loop for 12
> hours. I am sure there is a way for it to do what you need it to do,
> without doing those other things.
You may be right. On the other hand, powerful tools *often* provide
ways of shooting oneself in the foot. One might make a similar
argument to yours for the ability to purge resources. The following
puppet snippet will probably cause you no end of headaches:
resources { "package": purge => true; }
I have yet to meet the daemon that couldn't be mis-configured to fill
up as much log as you allow it to; I don't think that is a good
argument for removing functionality. I fight "dumbing down" tools
wherever I can, and this seems like one of those cases. The correct
way to handle this case is to remember that if you don't rotate your
logs correctly, a rogue daemon will fill up your filesystem, and act
accordingly.
Your complaint is valid; this should not be the default behavior, and
it *isn't* -- your beef should be with the package maintainer who
misconfigured the tool, not with the tool itself.
--Paul
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Could not request certificate -> big logs, full /var, failure
On Thu, Feb 26, 2009 at 6:58 AM, Kyle Cordes wrote: > Ouch. This seems like: > > a) a really awful choice for the Debian / Ub packages Yep. > b) a feature that Puppet would be much better off without. > > > I can't imagine a compelling use case for a "pound on the server > continuously" setting; and I'm not surprised, with some years of > software development experience, to find that given the existence of > such a capability, that someone would set it as the *default*. Just because you can't imagine it, doesn't mean it doesn't exist. I use -w 0 intentionally and happily, and there is a compelling use case for my environment. I can't go into it without getting into internal details I can't discuss, but, like most settings in Puppet, I believe it exists for a reason. > By the way, how do you install puppetd, on Deb systems? > > a) use the Debian-provided package, then go back and edit the settings > > b) make your own package I definitely recommend this route over all the others. We maintain our own repository of Debian packages for things the Debian packagers have screwed up, or things we really need to be newer, etc. > c) some other means, not using a package Don't do this on Debian machines, it will only end in tears ;-) --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Managing a symlink
The first route was the correct route. What you are seeing isn't an error, it is an informative message to let you know you are doing something that people often do accidentally. You can ignore it and go on your merry way. --Paul On Fri, Feb 20, 2009 at 4:43 AM, Keith Edmunds wrote: > > I have a directory that I wish to create and populate on clients, and that > works fine. However, I want to include a symlink in that directory. > Initially I wrote a "file" directive to create the symlink, but Puppet > complained with "Not managing more explicit file ...", presumably because > it was already managing the parent directory. > > I then tried putting the symlink in the files repository on the > puppetmaster, but then Puppet complained "Not checksumming symlink" and > "Not managing symlink mode". > > So: how can I ensure that a specific symlink exists inside a directory > that Puppet is managing? > > Thanks. > > > > --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Lock file /var/lib/puppet/state/puppetdlock
On Mon, Feb 16, 2009 at 7:39 PM, Luke Kanies wrote: > Otherwise I've no idea, because you're the first to run into it > that I know of. > > Note that you should be able to run 'puppetd --enable' to remove that > stale lock file. I periodically run into this issue as well; it only happens on our Xen VMs. Not sure if that helps. I just have a cron job that runs puppetd --enable on these systems. --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: basic question about template conditionals
Michael, Templates are ERB, which uses pure ruby. I think what you are doing should work in concept, thought I think your syntax is a bit off. --Paul On Wed, Feb 11, 2009 at 10:36 AM, Michael Conigliaro wrote: > > Hello, > > Sorry if this ends up getting posted twice. I originally sent this > about 3 hours ago, and I never saw it get posted, so I'm trying again. > > I want to use Puppet to manage /etc/access.conf on our managed Linux > servers. The problem is that the servers on our network will be > accessed by different groups of users, so I will need slightly different > configurations for each server. My first impression is that I probably > don't want to create completely different access.conf files for each > server, so I thought I might try using template conditionals for this. > I'm just not sure if what I'm trying to do is possible, or if there's a > better way. I've pasted my basic idea below. The part I'm not sure > about is the "if $hostname in [server1, server2, server3]" part. I > didn't see anything in the documentation about checking if a value > exists in an array, but I assume this is possible. Any thoughts? > > # > # etc/access.conf controls access to this machine # > > # User "root" can only log in locally and from trusted network subnets > - : root : ALL EXCEPT LOCAL 192.168.0.0/16 > > # Tech support users can log in from all sources. > + : @support : ALL > > <% if $hostname in [server1, server2, server3] %> # group1 can log into > this server > + : @group1 : ALL > <% end %> > > <% if $hostname in [server4, server5, server6] %> # group2 can log into > this server > + : @group2 : ALL > <% end %> > > All other users should be denied to get access from all sources. > - : ALL : ALL > > -- > Michael Conigliaro > Computer Analyst > Fuss & O'Neill Technologies > www.fandotech.com > > > > > > --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Am I the only one with lots of problems with puppet?
Arnau, Please don't be offended by my response, as you requested we not be offended by your post. I've watched a lot of your posts to the list, and the behavior I'm observing is when you run into errors, you don't seem to step back and try to take the time to understand them. Instead, it appears you do the following: 1) Immediately post a message to the list. 2) Freak out because nobody responded within 5 minutes. 3) Flail around trying things, seemingly at random, until something *seems* to work because it makes the specific error change/go away. 4) Repeat. So, if I were to offer you some ideas for how to proceed, they would be: 1) Set all the stuff you've made to this point aside. Keep it around to use as reference. 3) Pick 3 machines to use as an environment for learning puppet. 4) Ensure that Puppet is *completely* removed from these machines. It would be optimal if they were totally clean machines. * Puppet is still pre-1.0 software. The upgrade path hasn't been perfectly clean and, to complicate things, packaging has been fairly inconsistent. There are some artifacts that are in older versions which will utterly break newer versions in disorienting ways. 5) Install the latest stable version of Puppet (0.24.7 as I write). Choose one machine to act as puppetmaster, and (if it is a separate package for your environment) install puppetmaster on that machine. 6) Pick one service. Create a module for it. 7) When you encounter a problem, stop. Walk away entirely for ten minutes. Come back to it and see if you can figure out what the root cause of the problem is. Some basic troubleshooting steps for Puppet: * Re-start your puppetmaster and watch the logs. Often a syntax error in your manifests will cause the puppetmaster to ignore them and use the old cached configurations. When you restart, if you are watching the logs, you'll catch the syntax error and you can fix it. * Utilize --debug --no-daemonize on both client and server -- this is one of your biggest complaints, and it is entirely caused by having used old versions and leaving old broken config files around. You should not have a 'puppetd.conf' or a 'puppetmasterd.conf', you should be using 'puppet.conf' * Try out --parse-only * Comment out the sections of your manifest that you added since things ran perfectly. Uncomment one resource at a time. I think if you step back and start from a reasonably clean slate you will have a more positive experience. Regards, Paul Lathrop On Wed, Feb 11, 2009 at 10:25 AM, Arnau Bria wrote: > > Hi all, > > I'm facing many problems for last days with my puppet server/client. > Those who read mail list may know that. > > > I'm not sure if it's just my and my poor knowledge on puppet (I must > say in my defense that I have read many wiki docs and I have bough the > book, ok, it's not enough, if I'm a bad sysadmin I can read a complete > library and know anything...) but seems that every doc describes one > behave and puppet does an other. Please, don't feel offended > after/before reading this mail. I really appreciate the developers > effort, and all the help I got from this list, but I'm getting crazy > with puppet. > > > I started with a simple scenario, a couple of nodes with a server, and > few classes, all worked fine... But one day I faced first problem: > > err: Could not retrieve catalog: Could not parse for environment production > > after reading a lot, checking my conf one time and other, and other, > and other I realized that I removed puppetmasterd link > from /etc/puppet/ (puppetmaster complained about having two files with > same conf) and the solution was creating it again, ignoring the log > error... > > After that, I upgraded to a newer version, not latest, where I found a > installation bug about creating $vardir directory... I could solve it > by creating it by hand, but I faced some other problems like that > version was not able to run puppetmasterd in debug mode and not sending > the process to background... So, I have to upgrade again, cause I think > this feature is basic for debugging... OH! and I found that each > section of puppetd needs its own variables... $vardir was default value > for puppetmasterd if I did not specify them explicity. > > So, now I'm at version 0.24.7, from epel, and all seemed to work fine > again (complete puppetview report, many classses with deps, etc...) > > until when? until I tried to configure mongrel (ok, it's mongrel, not > puppet itself), but balancing did not work, at least in my case > (it did balance, but was not able to server catalog to hosts). I tried > to reinstall 40 host at once and I saw puppetmasterd being not able > to support that... 100 apache processes...) and it's only 40 nodes
[Puppet Users] Re: Definitions, Classes, and Nodes; Oh My!
Benoit,
This doesn't seem like a hack to me. I think this is the correct way
to approach the problem you describe.
--Paul
On Wed, Feb 11, 2009 at 5:05 AM, Benoit Decherf wrote:
> Thanks for that very good explication !
>
> I still have a doubt : How to manage property "per instance".
> In a little more complicated case, an instance of a webapp have to connect
> to a given database.
>
> node node1 {
> $countries=["fr", "uk"]
> include webserver
> }
>
> and my webserver class:
>
> class webserver {
> webapp-instance{$countries:
> database => ${db_ip_${country}}
> }
> }
>
> of course this doesn't works ;)
> How do you manage this ?
>
> hashes aren't supported by puppet, so this is not a solution.
> To make it work I make a function "eval" which lookup for the value in the
> scope and do something like:
> webapp-instance{$countries:
> database => eval(db_ip_${country})
> }
>
> But this is a hack. What is the correct way to do this ?
>
>
>
> On 02/10/2009 10:08 AM, Paul Lathrop wrote:
>
> Nicolas,
>
> I split this thread since we aren't talking about Kinial anymore.
>
> I think you misunderstood me; I certainly wouldn't advocate the
> mishmash of classes you suggest below, as you said, putting the
> definition "calls" (I use "declarations", and will in the rest of this
> email) in the node statements is easier and more maintainable. Your
> problem is a good one, and similar to one I have encountered in my use
> of Puppet. The issue at hand seems to be "I'd like to use external
> nodes, but I can't because I'd lose the ability to declare defined
> resources at the node level." This is the issue I'm addressing, so if
> I'm wrong about the problem, let me know.
>
> There are a couple of approaches to the problem you describe. The
> first step is almost always to take a step back and ask yourself if
> you have designed your solution in a way that makes the best use of
> the tools you've chosen. Puppet shines at creating repeatable
> configurations across a number of machines; creating mostly similar,
> but somewhat different configurations on each individual machine,
> while a related problem, is not the same thing. So, one thing I might
> ask myself in the situation you describe is this: does each machine
> really need to have a different set of webapp-instances? Are there
> resource constraints, or are you just following a (reasonable!) habit
> of only putting what is necessary on any given server? If you find
> that there really isn't any reason, you can address this problem by
> creating a class that defines all the webapp-instances and including
> that class on every node.
>
> To make the solution more interesting, though, let's assume that there
> is a solid reason not to deploy all the countries to every application
> server. The next question we ask is: how can we put these definitions
> within a class without losing the flexibility/maintainability we get
> from node-level declarations? Depending on the internal implementation
> of your definition, Puppet arrays might come to your rescue:
>
> node node1 {
> countries = ["es", "fr", "uk"]
> include webapp
> }
>
> node node2 {
> countries = ["es", "it", "de"]
> include webapp
> }
>
> class webapp {
> webapp-instance {
> "app":
> countries => $countries;
> }
> }
>
> We had a similar issue that I dealt with in a slightly different way.
> We have this concept of database instances that have a name (a
> numerical id of the "slot" of the instance), a port they run on, and a
> replication statement. So we have something like:
>
> define db::instance($port, $replicate_db)
>
> The instances required vary by machine, a specific instance isn't
> always on a given port, etc. So I had trouble mapping this to classes
> (especially for machines that needed multiple instances of the same
> "type" running on different ports). For a long time we did this at the
> node level:
>
> node qa-db {
> db::instance {
> "0":
> port => 3306,
> replicate_db => production;
> "1":
> port => 3307,
> replicate_db => production;
> }
> }
>
> Then we decided to switch to external nodes... and there was a bit of
> trouble. It was easy enough to write classes for each instance type
> and set a variable for the slot, but I ht a wall on machines that
> needed multiple instances that wer
[Puppet Users] Re: Definitions, Classes, and Nodes; Oh My!
Brian,
Thanks for adding this to the wiki! Glad you found it useful.
--Paul
On Tue, Feb 10, 2009 at 10:00 AM, Brian Finney wrote:
>
> As this is the best explanation of how to approach this problem I have
> ever seen, I took the liberty of adding it to the wiki at
> http://reductivelabs.com/trac/puppet/wiki/Recipes/HandlingDisparateDefinesWithClasses
> and linked it from the external nodes intro. Thanks Paul
>
> Brian
>
> On Tue, Feb 10, 2009 at 1:08 AM, Paul Lathrop wrote:
>>
>> Nicolas,
>>
>> I split this thread since we aren't talking about Kinial anymore.
>>
>> I think you misunderstood me; I certainly wouldn't advocate the
>> mishmash of classes you suggest below, as you said, putting the
>> definition "calls" (I use "declarations", and will in the rest of this
>> email) in the node statements is easier and more maintainable. Your
>> problem is a good one, and similar to one I have encountered in my use
>> of Puppet. The issue at hand seems to be "I'd like to use external
>> nodes, but I can't because I'd lose the ability to declare defined
>> resources at the node level." This is the issue I'm addressing, so if
>> I'm wrong about the problem, let me know.
>>
>> There are a couple of approaches to the problem you describe. The
>> first step is almost always to take a step back and ask yourself if
>> you have designed your solution in a way that makes the best use of
>> the tools you've chosen. Puppet shines at creating repeatable
>> configurations across a number of machines; creating mostly similar,
>> but somewhat different configurations on each individual machine,
>> while a related problem, is not the same thing. So, one thing I might
>> ask myself in the situation you describe is this: does each machine
>> really need to have a different set of webapp-instances? Are there
>> resource constraints, or are you just following a (reasonable!) habit
>> of only putting what is necessary on any given server? If you find
>> that there really isn't any reason, you can address this problem by
>> creating a class that defines all the webapp-instances and including
>> that class on every node.
>>
>> To make the solution more interesting, though, let's assume that there
>> is a solid reason not to deploy all the countries to every application
>> server. The next question we ask is: how can we put these definitions
>> within a class without losing the flexibility/maintainability we get
>> from node-level declarations? Depending on the internal implementation
>> of your definition, Puppet arrays might come to your rescue:
>>
>> node node1 {
>> countries = ["es", "fr", "uk"]
>> include webapp
>> }
>>
>> node node2 {
>> countries = ["es", "it", "de"]
>> include webapp
>> }
>>
>> class webapp {
>> webapp-instance {
>>"app":
>> countries => $countries;
>> }
>> }
>>
>> We had a similar issue that I dealt with in a slightly different way.
>> We have this concept of database instances that have a name (a
>> numerical id of the "slot" of the instance), a port they run on, and a
>> replication statement. So we have something like:
>>
>> define db::instance($port, $replicate_db)
>>
>> The instances required vary by machine, a specific instance isn't
>> always on a given port, etc. So I had trouble mapping this to classes
>> (especially for machines that needed multiple instances of the same
>> "type" running on different ports). For a long time we did this at the
>> node level:
>>
>> node qa-db {
>> db::instance {
>>"0":
>> port => 3306,
>> replicate_db => production;
>>"1":
>> port => 3307,
>> replicate_db => production;
>> }
>> }
>>
>> Then we decided to switch to external nodes... and there was a bit of
>> trouble. It was easy enough to write classes for each instance type
>> and set a variable for the slot, but I ht a wall on machines that
>> needed multiple instances that were identical except for slot#/port.
>> Then I remembered arrays:
>>
>> class zomg_read {
>> db::instance {
>>$zomg_read_slot:
>> port => $zomg_read_slot + 3306,
>> replicate_db => production;
>> }
>> }
>>
>> node qa-db {
>> $zomg_read_slot = [0, 1]
>> include zomg_read
>>
[Puppet Users] Definitions, Classes, and Nodes; Oh My!
Nicolas,
I split this thread since we aren't talking about Kinial anymore.
I think you misunderstood me; I certainly wouldn't advocate the
mishmash of classes you suggest below, as you said, putting the
definition "calls" (I use "declarations", and will in the rest of this
email) in the node statements is easier and more maintainable. Your
problem is a good one, and similar to one I have encountered in my use
of Puppet. The issue at hand seems to be "I'd like to use external
nodes, but I can't because I'd lose the ability to declare defined
resources at the node level." This is the issue I'm addressing, so if
I'm wrong about the problem, let me know.
There are a couple of approaches to the problem you describe. The
first step is almost always to take a step back and ask yourself if
you have designed your solution in a way that makes the best use of
the tools you've chosen. Puppet shines at creating repeatable
configurations across a number of machines; creating mostly similar,
but somewhat different configurations on each individual machine,
while a related problem, is not the same thing. So, one thing I might
ask myself in the situation you describe is this: does each machine
really need to have a different set of webapp-instances? Are there
resource constraints, or are you just following a (reasonable!) habit
of only putting what is necessary on any given server? If you find
that there really isn't any reason, you can address this problem by
creating a class that defines all the webapp-instances and including
that class on every node.
To make the solution more interesting, though, let's assume that there
is a solid reason not to deploy all the countries to every application
server. The next question we ask is: how can we put these definitions
within a class without losing the flexibility/maintainability we get
from node-level declarations? Depending on the internal implementation
of your definition, Puppet arrays might come to your rescue:
node node1 {
countries = ["es", "fr", "uk"]
include webapp
}
node node2 {
countries = ["es", "it", "de"]
include webapp
}
class webapp {
webapp-instance {
"app":
countries => $countries;
}
}
We had a similar issue that I dealt with in a slightly different way.
We have this concept of database instances that have a name (a
numerical id of the "slot" of the instance), a port they run on, and a
replication statement. So we have something like:
define db::instance($port, $replicate_db)
The instances required vary by machine, a specific instance isn't
always on a given port, etc. So I had trouble mapping this to classes
(especially for machines that needed multiple instances of the same
"type" running on different ports). For a long time we did this at the
node level:
node qa-db {
db::instance {
"0":
port => 3306,
replicate_db => production;
"1":
port => 3307,
replicate_db => production;
}
}
Then we decided to switch to external nodes... and there was a bit of
trouble. It was easy enough to write classes for each instance type
and set a variable for the slot, but I ht a wall on machines that
needed multiple instances that were identical except for slot#/port.
Then I remembered arrays:
class zomg_read {
db::instance {
$zomg_read_slot:
port => $zomg_read_slot + 3306,
replicate_db => production;
}
}
node qa-db {
$zomg_read_slot = [0, 1]
include zomg_read
}
Since using arrays creates multiple resources, this works really well,
and pulls the definitions into a class without losing the flexibility
required to migrate to external nodes.
Obviously, not knowing everything about your situation, I can't solve
your problem completely but I can say that, in my experience, when the
tool seems like it is getting in my way I am often not using the tool
the way it was designed to be used. Puppet is a somewhat opinionated
tool, in some ways, in that there are design decisions made to support
the Puppet model of the world, and you may have to adjust your design
to fit that model (or pick a different tool, I suppose). Not that we
can't change the tool where merited, but in this case, I think Puppet
has it right.
--Paul
On Tue, Feb 10, 2009 at 12:16 AM, nicolas wrote:
> ok paul, thanks for clarifying this.
>
> I think my misconception comes from what we're trying to do.
>
> We have webapps that have instances defined for different set of
> countries
> So we have definitions like :
> define webapp-instance($countries, ...)
>
> And then for a set of machines we want to deploy our instances, but no
> machine has the exact same requirement :
> node node1 {
>webapp-instance { "es_fr", countries = ["es", "fr"] }
>webapp-instance { "uk", countries = ["uk"] }
> }
> node node2 {
>webapp-instance { "es_it", countries = ["es", "it"] }
>webapp-instance { "de", countries = ["de"] }
> }
> and so on...
>
> So, if I follow your guidelines, I should define intermediate classes
> and then use t
[Puppet Users] Re: compiled catalog for $HOST time
Are you using stored configs? On Mon, Feb 9, 2009 at 2:54 AM, Arnau Bria wrote: > > Hi, > > anyone could explain why every time that puppet compiles a catalog for a > host, its compilation time increases? > > Hosts share same "type", so, from my understanding, compiling catalog > time should decrease... (ok, from my poor understanding). > > > Feb 9 11:33:26 gridinstall puppetmasterd[356]: Compiled catalog for > td007.pic.es in 1.80 seconds > Feb 9 11:33:27 gridinstall puppetmasterd[356]: Compiled catalog for > td008.pic.es in 2.62 seconds > Feb 9 11:33:28 gridinstall puppetmasterd[356]: Compiled catalog for > td010.pic.es in 3.21 seconds > Feb 9 11:33:36 gridinstall puppetmasterd[356]: Compiled catalog for > td009.pic.es in 7.83 seconds > Feb 9 11:33:46 gridinstall puppetmasterd[356]: Compiled catalog for > td251.pic.es in 5.10 seconds > Feb 9 11:33:48 gridinstall puppetmasterd[356]: Compiled catalog for > td250.pic.es in 6.00 seconds > Feb 9 11:33:49 gridinstall puppetmasterd[356]: Compiled catalog for > td234.pic.es in 6.81 seconds > Feb 9 11:33:50 gridinstall puppetmasterd[356]: Compiled catalog for > td247.pic.es in 7.18 seconds > Feb 9 11:33:51 gridinstall puppetmasterd[356]: Compiled catalog for > td249.pic.es in 7.67 seconds > Feb 9 11:33:53 gridinstall puppetmasterd[356]: Compiled catalog for > td070.pic.es in 8.76 seconds > Feb 9 11:33:53 gridinstall puppetmasterd[356]: Compiled catalog for > td248.pic.es in 8.43 seconds > Feb 9 11:33:56 gridinstall puppetmasterd[356]: Compiled catalog for > td065.pic.es in 10.49 seconds > Feb 9 11:33:57 gridinstall puppetmasterd[356]: Compiled catalog for > td006.pic.es in 12.16 seconds > > > TIA, > Arnau > > > > --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: what about kinial ?
On Mon, Feb 9, 2009 at 9:24 AM, nicolas wrote:
>
>
>>
>> Maybe there is something I missed about definitions. I though it was
>> a notion related to the notion of a class.
>> I'm confused too, because your answer make me think that you
>> consider definition call like resources. Is it the case ?
>>
>> My only request was to be able to put parameters, classes and
>> definitions calls in nodes. Here the request to have definition (call)
>> in the external nodes.
>>
>
> maybe the confusion comes from the fact that you must define a
> resource with the same syntax that you use to call a definition
> x { "name" : parameters }
> if calling a definition used a different syntax, would'nt it be
> better ?
> Calling a definition should be equivalent to including a class.
This is the biggest mistake I see amongst people new to Puppet. A
definition isn't "called." A definition is not a function. Puppet is a
declarative language, not an imperative language. You need to make
this conceptual jump to understand the Puppet way of doing things.
Conceptually, a definition IS a resource. Let me repeat that:
Definition == Resource
That is why the syntax is the same. Definitions provide you the
ability to create composite resources that abstract away the details
of the individual resource "atoms" (file, service, etc.) that are
required to make up your defined resource.
Calling a definition absolutely should *NOT* be equivalent to
including a class, they are very different collections. Definitions
are used to abstract away collections of resources while maintaining
the ability to have multiple "instances" of the defined resource. So,
you can have multiple subversion::working-copy instances within a
single class of machine, this is a critical capability to have!
Classes are collections used to wholly define a role that a certain
node plays. So, while it may take multiple subversion::working-copy
instances to make up a webserver, you don't want multiple "webserver"
roles on a single node, that's conceptually weird.
--Paul
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Proposal (what problems will puppet solve)
Zach, Some thoughts inline: On Mon, Feb 2, 2009 at 12:53 PM, Zach Buckholz wrote: > > This may sound like a confusing / trick question, so please bare with me. > > What problem(s) will puppet solve? Why would I use it? What problems do you want to solve? Seriously, if you don't have a solid answer to this question in your head, I bet you will have trouble making Puppet work for you. What frustrates you about doing things the old "ssh + loop over hosts" ad-hoc shell scripting way? What fires do you spend most of your time putting out? What things do you find yourself doing over and over and over again? Answer these questions and you'll be a good way towards pitching your proposal. > This is what I have come up with so far; (I wish the reductive labs site had > a wiki page for this) Add one! That's what wikis are all about! > What is the problem? > Unknown configurations > Environment is not dynamic > Messy > No central model > Hard to change > No consistency > Administration overhead > Reactive instead of proactive > Unorganized > Need scripts to work with linux and solaris > Hard to scale > > Can anyone add (non-technical explanations) to the above list? I think you've covered enough ground here to make a solid argument, as long as you remember to tie it all back to costs. Like this: Unknown configurations: Whenever a machine has a problem, I spend XX% of my time re-learning how that machine is set up before I can even consider what is causing the problem. If the configuration were consistent and self-documenting, it would free up XX hours of my time ($XX amount of money) to apply towards more important/revenue-driving tasks. That sort of thing gets managerial types fired up. Give them a dream of an Operations team that is involved in producing revenue rather than being a cost sink. My .02 --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Question about Recipe LDAPClientNSSwitch ?
Xavier, It *is* a wiki. That means you should feel free to make these kind of changes: "A wiki is a page or collection of Web pages designed to enable anyone who accesses it to contribute or modify content" (http://en.wikipedia.org/wiki/Wiki). The more community members who choose to do this, the better the wiki will be! Regards, Paul On Mon, Feb 2, 2009 at 8:43 AM, Xavier Beaudouin wrote: > PS: maybe this can be updated on the wiki ? --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Facter - the future - your input needed
I don't think that belongs in facter; it belongs in the fact itself. Just my .02 --Paul On Sat, Jan 31, 2009 at 11:18 PM, Sam Rowe wrote: > > Oh and one other thing about 'facter.d' it'd be cool if there was some > way to say that a given fact (or set of facts) is cache-able. Perhaps > your fact is resource intensive to discover and doesn't change much. > It'd be cool to have a built-in facility in facter that says "if you > just booted, find out this fact, otherwise use the old answer." > > > > --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Notifying a service when config file changes
On Fri, Jan 23, 2009 at 4:35 AM, Kenneth Holter wrote:
> service {syslog:
>ensure => running,
>subscribe => Line["rsyslogserver"]
> }
>
> line { "rsyslogserver":
> file => "/etc/syslog.conf",
> line => "*.* @server1.example.com",
> ensure => present
> notify => Service[syslog]
> }
>
> I thought that the "notify" line would make sure that the syslog service
> would restart upon changes to the config file, but apparently it isn't so.
> Anyone got any suggestions on how to implement this?
Is "line" a define you've gotten from somewhere? I think the community
is generally trying to use Augeas for this sort of thing. Myself I'd
just push out the file as a file resource.
--Paul
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Get list of all nodes
On Tue, Jan 6, 2009 at 9:50 AM, John Philips wrote:
> Thanks, that did the trick. Well, almost. The hostnames are in quotation
> marks so I piped it to yet another program for the final touch.
>
> grep ^node site.pp | sed -e 's/^node //' | awk -F, '{for(i=1;i<=NF;i++)
> {print $i}}' | cut -d "'" -f2
Awesome. Do you need me to dissect it so you know *why* it works, or
would you prefer to figure it out yourself?
--Paul
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Get list of all nodes
Use LDAP.
I couldn't resist. :-P
In all seriousness, though, grep is still your friend. He's brought a
couple new friends to the table to help you with this problem; their
names are "sed" and "awk".
With the example below, this should give you what you want:
grep ^node site.pp | sed -e 's/^node //' | awk -F,
'{for(i=1;i<=NF;i++) {print $i}}'
HTH
--Paul
On Tue, Jan 6, 2009 at 8:09 AM, John Philips wrote:
>
> Hi,
>
> Is there a way to export a list of all manually-defined nodes in a puppet
> configuration?
>
> I need to use this list in a script. Previously it was easy because I had
> each node individually defined in nodes.pp ala
>
> node 'blah1.com' {
>include stuff
> }
> node 'blah2.com' {
>include stuff
> }
>
> I could just grep the file for the word 'node' and parse the output.
> However, since many nodes have the same layout, I condensed the configuration
> and now I don't know how to extract the node names.
>
> Current layout:
>
> node 'blah1.com', 'blah2.com',
>
> 'blah48.com, 'blah172.com' {
>include stuff
> }
>
> Is there a way to parse the node list with a puppet utility or a ruby script?
> The output I'd like returned is very simple - 1 hostname per line.
>
> P.S. Please don't tell me to use LDAP :-)
>
>
>
>
> >
>
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: puppetd
What version of Puppet are you using?
--Paul
On Tue, Dec 23, 2008 at 11:59 PM, Paul Johnson wrote:
> Thanks for replies, here is the info. Actually there is not much in configs,
> I tried it with minimal manifest and the issue still persists.
>
> manifest:
> =
> node default {
>
> $server = "puppetmaster.local"
>
> #
> # distribute puppetd and auth configs to all managed nodes
> file {
> '/etc/puppet/puppet.conf': source =>
> "puppet://$server/files/puppet.conf";
> '/etc/puppet/puppetd.conf': source =>
> "puppet://$server/files/puppet.conf";
> '/etc/puppet/namespaceauth.conf': source =>
> "puppet://$server/files/namespaceauth.conf";
> }
>
> #
> # define default filebucket on puppetmaster server
> filebucket { "main": server => $server }
> File { backup => 'main' }
> }
> =
>
> puppetd.conf (the same as puppet.conf) on target server:
>
> =
> [main]
>
> # Where Puppet stores dynamic and growing data.
> # The default value is '/var/puppet'.
> vardir = /var/lib/puppet
>
> # The Puppet log directory.
> # The default value is '$vardir/log'.
> logdir = /var/log/puppet
>
> # Where Puppet PID files are kept.
> # The default value is '$vardir/run'.
> rundir = /var/run/puppet
>
> # Where SSL certificates are kept.
> # The default value is '$confdir/ssl'.
> ssldir = $vardir/ssl
>
> [puppetd]
> # The file in which puppetd stores a list of the classes
> # associated with the retrieved configuratiion. Can be loaded in
> # the separate ``puppet`` executable using the ``--loadclasses``
> # option.
> # The default value is '$confdir/classes.txt'.
> classfile = $vardir/classes.txt
>
> # Where puppetd caches the local configuration. An
> # extension indicating the cache format is added automatically.
> # The default value is '$confdir/localconfig'.
> localconfig = $vardir/localconfig
>
> # mster server
> server = puppetmaster.local
>
> # interval
> runinterval = 900
>
> # should we send reports back to puppetmaster server?
> report = true
>
> # should we listen for incoming connections? Allowd hosts are in file
> listen = true
>
> # we want all facts to be synced from master
> factsync = true
> =
>
> As to the logs, it creates only one log file during first run:
> /var/log/puppet/http.log and nothing writes to it since then, so it remains
> empty.
>
> Puppetd performs all operations I add to manifest and doesn't report any
> error or warning and the only problem is it produces those strange
> zombies...
> Target OS is Centos, tried versions 3,4 and 5 - the issue is on all of them.
> I have few instances of puppet running on Gentoo (installed from portages)
> and there is no such problem.
>
> Please let me know if I should provide any additional info.
>
> Thanks
> --
> Paul Johnson
>
> 2008/12/22 Ohad Levy
>>
>> whats the last line you see in your puppet logfiles?
>>
>> I would guess its an exec or similar
>>
>> Ohad
>>
>> On 12/22/08, Paul Johnson wrote:
>> > Hi All,
>> >
>> > I have a strange problem with running puppet as a daemon. I set it up in
>> > config to wake up every 15 min and looks like it every time spawns httpd
>> > process that becomes zombie, so after some time I see a long list of
>> > zombies, like this:
>> >
>> > root 12427 0.1 0.9 39624 37408 ? Ss Dec20 4:12
>> > /usr/bin/ruby
>> > /usr/sbin/puppetd
>> > .
>> > .
>> > .
>> > root 23654 0.0 0.0 00 ?Z15:14 0:00 \_
>> > [httpd]
>> >
>> > root 30482 0.0 0.0 00 ?Z15:29 0:00 \_
>> > [httpd]
>> >
>> > root 5389 0.0 0.0 00 ?Z15:44 0:00 \_
>> > [httpd]
>> >
>> > root 12636 0.0 0.0 00 ?Z15:59 0:00 \_
>> > [httpd]
>> >
>> > root 21618 0.0 0.0 00 ?Z16:15 0:00 \_
>> > [httpd]
>> >
>> > root 28044 0.0 0.0 00 ?Z16:30 0:00 \_
>> > [httpd]
>> >
>> > root 2363 0.0 0.0 00 ?Z16:45 0:00 \_
>> > [httpd]
>> >
>> > root 9547 0.0 0.0 00 ?Z17:00 0:00 \_
>> > [httpd]
>> >
>> > root 17770 0.0 0.0 00 ?Z17:15 0:00 \_
>> > [httpd]
>> >
>> > root 24466 0.0 0.0 00 ?Z17:30 0:00 \_
>> > [httpd]
>> >
>> > root 31275 0.0 0.0 00 ?Z17:46 0:00 \_
>> > [httpd]
>> >
>> > root 6199 0.0 0.0 00 ?Z18:01 0:00 \_
>> > [httpd]
>> >
>> > root 1
[Puppet Users] Re: local and ldap users and packages
Use classes and inheritance.
What I would do is something like this:
class base-node {
@package {
"sudo":
ensure => installed;
"sudo-ldap":
ensure => installed;
}
@user {
# Obviously fully define your user here.
"bob":
ensure => present;
}
}
class ldap-node inherits base-node {
realize Package["sudo-ldap"]
}
class non-ldap-node inherits base-node {
realize Package["sudo"]
realize User["bob"]
}
node some-app-node {
include ldap-node
}
node some-other-node {
include non-ldap-node
}
Hope that helps!
Regards,
Paul
On Wed, Dec 24, 2008 at 1:32 AM, gary wrote:
>
> Hello,
>
> We have LDAP and non-LDAP nodes and some accounts that should be
> created only on non-LDAP nodes. I'm not sure the best way to handle
> this. I can remember where to put things specifically though having
> better checks would be nice. Like
>
> debian sudo-ldap conflicts with sudo, so only one should be installed
>check define of other ldap related file like a package?
>
> users
> manage local root of every machine - seems like
> nss_initgroups_ignoreusers root in ldap.conf is necessary. Maybe my
> nsswitch and pam config could be better as well.
>
> files
> some would depend on if it's an ldap node.
>
> Maybe it's best to define $hasldap somewhere.
>
> Gary
> >
>
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Using an Exec inside a define
Hmm, I suspect that documentation is wrong. I've never successfully had multiple Exec resources with the same name. I say file a bug, at the worst someone will verify/clarify the documentation. I tend to use "module_name::define_name::$name" as my naming convention for this sort of thing. That usually guarantees uniqueness. --Paul On Mon, Dec 29, 2008 at 11:02 AM, Robin Lee Powell wrote: > > On Mon, Dec 29, 2008 at 09:45:07AM -0600, Ben Beuchler wrote: >> >> > Ah, nope. No resource title can be duplicated, exec isn't an >> > exception. Is there somewhere you read that or saw it in an >> > example? >> >> Perhaps I misunderstood what I read here: >> >> http://reductivelabs.com/trac/puppet/wiki/TypeReference#exec >> >> Not only does it seem to be saying that an exec is allowed to have >> a duplicate title/name, but the example seems to be demonstrating >> exactly that. Am I misreading it? > > I agree with you, definately. I suspect, but do not know, that the > cwds need to be different in that case. > > -Robin > > -- > They say: "The first AIs will be built by the military as weapons." > And I'm thinking: "Does it even occur to you to try for something > other than the default outcome?" -- http://shorl.com/tydruhedufogre > http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/ > > > > --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: support for upstart
On Thu, Dec 18, 2008 at 6:00 AM, John Florian wrote: > I'm not sure I'm up to developing this myself just yet as I'm very new > to puppet and haven't done any ruby thus far. I was about to create a > feature request, but then realized what you were saying about adding > upstart as a provider to the service type. I'm not sure that's > exactly what's needed. It's what I need, but perhaps would be wrong > for other uses of upstart. Upstart by design is event driven, so you > can have things like this: > > # This task is run whenever the Control-Alt-Delete key combination is > # pressed. Usually used to shut down the machine. > > start on control-alt-delete > > exec /sbin/shutdown -r now "Control-Alt-Delete pressed" > > > Here's another example from Fedora 10 that shows even more diversity: > > start on fedora.serial-console-available * > stop on runlevel [016] > > instance > pre-start script ># script portion removed for brevity > end script > exec /sbin/agetty /dev/$1 $2 vt100-nav > post-stop script ># script portion removed for brevity > end script > > I found the following page to be a quick, but informative read on some > of the capabilities: http://upstart.ubuntu.com/getting-started.html Many of those concepts don't currently map cleanly into Puppet's model. There's no reason they can't, the model could be extended to cover these concepts. However, the way that should happen is to add providers to types which are already in Puppet's model, and create new generic types to cover the other concepts. Since Puppet is to some extent an abstraction layer, we should strive to use/create generic abstractions rather than create a bunch of specific stuff (like an "upstart" type). Anyway, there's nothing wrong with building support for this sort of thing incrementally; why not make a provider for the service type that uses some of upstart's capabilities and ignores the rest? As for whether you are up to developing a provider: trust me, you probably are. The best way to stop being new to both Puppet and Ruby is to pick a task that is both useful, slightly complex without being far too difficult, and interesting to you. This sounds like it could be just the thing for you. --Paul --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Having issues getting environments working.
Simon, I'm not sure why you need to contact the server on a different port for each environment. The master serves up a different configuration (on the same port) just fine. What are you trying to accomplish? --Paul On Wed, Dec 10, 2008 at 6:53 PM, Simon Coggins <[EMAIL PROTECTED]> wrote: > > I read that as applying to the server which is fine for where it finds > it's modules and templates. I can see how only being able to change > the module and template paths on the client us useful. > > Guess I will just do it manually via command line for the options I > want in each enveonment. Shame the environment stuff showed promise. > > Thanks for your help! > > --- > Simon Coggins > Senior Systems Engineer > System Services > CQUniversity, Bruce HWY > Rockhampton, QLD, 4701, Australia > Phone: 07 49232778 > Mobile: 0408115861 > Fax: 07 49309254 > > On 11/12/2008, at 12:29, "Paul Lathrop" <[EMAIL PROTECTED]> wrote: > >> >> In the documentation >> (http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments) >> you will see the following: >> >> "Only certain parameters make sense to be configured per-environment, >> and all of those parameters revolve around specifying what files to >> use to compile a client's configuration. Those parameters are: >> >>* modulepath: Where to look for modules. It's best to have a >> standard module directory that all environments share and then a >> per-environment directory where custom modules can be stored. >>* templatedir: Where to look for templates. The modulepath should >> be preferred to this setting, but it allows you to have different >> versions of a given template in each environment. >>* manifest: Which file to use as the main entry point for the >> configuration. The Puppet parser looks for other files to compile in >> the same directory as this manifest, so this parameter also determines >> where other per-environment Puppet manifests should be stored. With a >> separate module path, it should be easy to use the same simple >> manifest in all environments." >> >> I believe that succinctly answers your question. >> >> --Paul >> >> On Wed, Dec 10, 2008 at 6:17 PM, Simon Coggins <[EMAIL PROTECTED]> >> wrote: >>> >>> Hi all, >>> >>> I've been trying to change over to using environments now that I have >>> upgraded to 0.24.6. I have a puppet.conf file that looks like this: >>> >>> --- >>> [main] >>> environment = production >>> listen = true >>> runinterval = 1800 >>> server = puppet.cqu.edu.au >>> report = true >>> factsync = true >>> >>> [puppetd] >>> environments = production, development >>> >>> [production] >>> server = puppet.cqu.edu.au >>> masterport = 8140 >>> >>> [development] >>> server = jester.cqu.edu.au >>> masterport = 18140 >>> -- >>> >>> This is what I get when I try to run it: >>> >>> [EMAIL PROTECTED]:~# /usr/local/bin/puppetd --test >>> --environment=production --configprint environment >>> production >>> [EMAIL PROTECTED]:~# /usr/local/bin/puppetd --test >>> --environment=production --configprint server >>> puppet.cqu.edu.au >>> [EMAIL PROTECTED]:~# /usr/local/bin/puppetd --test >>> --environment=production --configprint masterport >>> 8140 >>> [EMAIL PROTECTED]:~# /usr/local/bin/puppetd --test >>> --environment=development --configprint environment >>> development >>> [EMAIL PROTECTED]:~# /usr/local/bin/puppetd --test >>> --environment=development --configprint server >>> jester.cqu.edu.au >>> [EMAIL PROTECTED]:~# /usr/local/bin/puppetd --test >>> --environment=development --configprint masterport >>> 18140 >>> [EMAIL PROTECTED]:~# /usr/local/bin/puppetd --test -- >>> environment=development >>> info: Loading fact serialnumber >>> info: Loading fact zones >>> info: Loading fact hardware_platform >>> info: Loading fact sshkeys >>> info: Loading fact sun_webserver >>> notice: Ignoring --listen on onetime run >>> info: Retrieving facts >>> err: /File[/var/puppet/facts]: Failed to generate additional >>> resources >>> during transaction: Could not connect to puppet.cqu.edu.au on port >>> 8140 >>> err: /File[/var/puppet/facts]: Failed to retrieve current state
