Re: [Puppet Users] Puppet 3.0 and Hiera
On May 7, 2012, at 12:47 PM, Christopher Wood wrote:
Wrapper script (similar concept for anywhere with a yaml reader):
Still have to *write* the YAML files.
Out of nosiness, how do you handle the edgier cases in your manifests? For
example, how everything is a standard syslog client, except for this host
which is loghost, and these couple of clients which all do different things
with syslog?
We would have the syslog module have all the common
files/packages/services/etc. declared, and then simply do something like:
if ($fqdn =~ /^syslog/)
{
. log host specific stuff .
}
else
{
. NON-log host specific stuff .
}
doesn't seem like rocket science, and makes it clear, all in one place, what's
common, and what's special.
Puppet provides some wonderful decision-making capabilities in the manifests
themselves, I've yet to see any need to have some ugly machine-readable
formatted file to solve a problem.
But I *have* seen the parts of our organization that DO use Hiera complaining
loudly that they can't easily figure out which of a slurry of YAML files is
changing some setting/variable to a value they're not expecting.
Cheers,
D
--
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.
Re: [Puppet Users] Compile catalog time: 2.6 vs 2.7.X
FWIW, we are experiencing exactly the same thing in 2.7 that you are. We used to average 6-9 seconds for compilation time and now it's anywhere from 15 to 250 to timed out. D On May 8, 2012, at 7:07 AM, Arnau Bria wrote: Compiled catalog for td055.pic.es in environment production in 4.25 seconds Compiled catalog for td055.pic.es in environment production in 76.99 seconds err: Could not retrieve catalog from remote server: execution expired Why my code is being compiled fast in 2.6 but not in 2.7? What language programing considerations do I have to take into account when migrating? -- 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.
Re: [Puppet Users] Puppet 3.0 and Hiera
On May 3, 2012, at 1:05 PM, Pieter van de Bruggen wrote: As many of you may be aware, Hiera will be tightly integrated into Puppet in the upcoming release of Puppet 3.0. What will this mean for sites that have specifically avoided using Hiera? I would presume that this should just mean business as usual, with no significant impact? -- 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.
Re: [Puppet Users] Puppet 3.0 and Hiera
On May 7, 2012, at 11:54 AM, Nigel Kersten wrote: Yes. If you're not planning to externalize data at all, the only difference you'll see is that you'll now have Hiera installed on your system when you install Puppet 3.0. Cool. Was really panicking there for a moment. I kinda like having human readable manifests as opposed to machine readable YAML :-) Cheers, D -- 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.
Re: [Puppet Users] Certificate Annoyance: Time Differential
Well, we do it with kickstart and -- typically -- do the same thing. But for some reason it wasn't able to reach the NTP server during kickstart and it was never able to sync the clock before things really got rolling. And it just occurred to me that since, ostensibly, puppet could be in charge of making sure the NTP services were installed in the first place, that it would make a lot of sense to have this as a feature/option in puppet, to ignore the time-deltas for SSL certs. D On Feb 27, 2012, at 6:40 AM, y...@comcast.net y...@comcast.net wrote: A suggestion based on how I deal with this : I use Cobbler to load the operating system and do basic configurations. Then I hand off to Puppet. One thing I do with Cobbler is the initial setting of the system clock using ntpdate or ntpd -q Hope this helps -Original Message- From: Derek J. Balling To: puppet-users Sent: 2012-02-27 10:59:12 + Subject: [Puppet Users] Certificate Annoyance: Time Differential We recently had a situation where servers weren't able to use their auto-sign'ed certificates because their local clock was months off from real-time. Of course, it was brand-new hardware straight off the dock and hadn't yet had a chance to have ntp sync the clock to the correct time because, well, puppet is what fires up NTP. :-) Is there any way to recognize that puppet might be the thing in charge of bringing the clocks into sync, and allowing puppet to ignore certificate-verification failures that are based solely on the time-delta being too high? It certainly seems like it'd be a useful feature. D -- 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. -- 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.
Re: [Puppet Users] Step by step guide to setting user passwords
On Aug 2, 2011, at 8:35 PM, Len Rugen wrote: In puppet, passwd = $6$PVOar6qN$WUTN7HG838PnAdzLYCB4HHVSzE/SX100VVdsiIYlBo7TM5c79R38gx942Lkm710v1HMRmS5VnPbHZ2MwY96wt0, Make sure to use single-quotes, or puppet will try to evaluate variables $PVOar, $WUTN, etc., etc. D -- 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.
Re: [Puppet Users] Facter 1.6.0 and CentOS 6.0
On Aug 1, 2011, at 11:30 AM, Daniel Piddock wrote: You need to have the lsb_release command installed for the lsb* results to appear. Fedora/Redhat have it in the redhat-lsb package, so it possibly has a similar name under CentOS. Thanks to you and everyone else who pointed it out. Apparently something in our CentOS 5 kickstart brought that in, that our kickstart config for 6 didn't (almost certainly having to do with all those package group renames). Cheers, D -- 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] Facter 1.6.0 and CentOS 6.0
We just started testing CentOS 6.0 here, and I'm using Facter 1.6.0 If I run this command from my CentOS 5.x test machine: [root@puppetclient.nj1:~]# facter --version 1.6.0 [root@puppetclient.nj1:~]# facter | grep lsb lsbdistcodename = Final lsbdistdescription = CentOS release 5.3 (Final) lsbdistid = CentOS lsbdistrelease = 5.3 lsbmajdistrelease = 5 lsbrelease = :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch I get reasonable results. But if I do that from my CentOS 6.0 test machine: [root@cos6test.nj1:~]# facter --version 1.6.0 [root@cos6test.nj1:~]# facter | grep lsb [root@cos6test.nj1:~]# I get remarkably less kosher results. Is this a known issue? Is there any work-around? It's really breaking my CentOS 6 servers' ability to find their REPOs. :-) Cheers, D -- 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.
Re: [Puppet Users] Re: Force resigning of existing certificates
We've been tracking Bug 3360: https://projects.puppetlabs.com/issues/3360 which controls what the puppetmaster does when it receives a new CSR for a host that already exists. Like you and and OP, we have little to no use for the security aspects of Puppet's CA design, and build in a completely trusted environment. I *think* when 3360 goes live, most of our CA issues will be resolved. It may not be a perfect match the re-signing thing the OP is describing here, or your particular situation, but it's worth paying attention to. D On Apr 13, 2011, at 2:39 PM, Jake - USPS wrote: I also am looking to do something like this. So besides it being a bad idea, is there a way to do it? Thanks, Jake On Mar 11, 3:38 am, Patrick patr...@googlealtert.spamtrap.fht- esslingen.de wrote: On 8 Mrz., 14:54, Disconnect dc.disconn...@gmail.com wrote: Alternately, running thepuppetcacleanbefore starting the new client will result in the standard unsigned behavior. Maybe, but it would be nice to save this extra afford. In our case, we do not want the security features of puppet. (I do think its pretty broken that trying once with the wrong cert poisons the client - if it is an attack, they can just wipe the client cert again, and if it isn't - eg in your case - then it breaks..) We know, but we are using build servers in a trusted network.. The buildservers are often reinstalled and we do not want to manage the certificates. -- 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.
Re: [Puppet Users] Puppet Restarting Puppet, Puppet-Agent's resolver (was Inter-Module Dependency)
On Feb 18, 2011, at 3:01 PM, Daniel Pittman wrote: Just to be specific: puppet doesn't do anything except use those standard functions, so we are not actually capable of doing anything portable to solve these problems. It really isn't so much puppet ignores the change to... as the OS libraries ignore... I wonder how other applications deal with it, because some of the other apps on our system noticed the change to resolv.conf in short order. Maybe they're internally stat()ing /etc/resolv.conf every so often and if the time is different, they're re-init'ing their resolver object? Seems like that's something that could happen as part of a catalog run, though, with little to no overhead Dunno. D -- 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.
Re: [Puppet Users] Inter-Module Dependency
For what it is worth, for an extremely well known interface like /etc/resolv.conf I would subscribe to the file resource, but for most cases I prefer to depend on the class. So, I think both answers are right, and I didn't explain why I chose the apparently tighter binding this time around. FWIW, we've chosen to do both, if for no other reason than so that the app in question won't be processed until after the resolv.conf is updated, so we can minimize the number of restarts, etc., as necessary. The next issue which follows, for me, is that random_app is puppet-agent, because it refuses to notice changes to resolv.conf, and has to be restarted to pick them up. Likely this is because it's using its own resolver library instead of the system calls, but this is a real PITA, since the only clean way to restart the puppet agent, from within puppet, essentially amounts to issuing `/etc/init.d/puppet restart`in the middle of a catalog-run, which sucks for all the obvious reasons you would think it does. D -- 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.
Re: [Puppet Users] Trigger an event after a puppet run
size = self.logs.size if size == 0 then system /usr/lib/nagios/eventhandlers/submit_puppet_result + ip + puppet-report 0 \There has been no change\ else system /usr/lib/nagios/eventhandlers/submit_puppet_result + ip + puppet-report 2 \There have been + size.to_s + changes\ end end end This seems, at face value, to only be reporting upward change/no-change type of thing. I'm not at all ruby-ready as it were, in terms of programming skill, but it occurs to me that I can think of other conditions I'd be interested in reporting upward (syntax or other errors in the catalog received, or anything really, which causes a cached catalog to be used). Is there some easy way to add that functionality into this script? D -- 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.
Re: [Puppet Users] Re: Trigger an event after a puppet run
On Feb 16, 2011, at 2:49 PM, donavan wrote: Off hand you may be interested in the metrics portion of the report. Something like metrics[changes][:failed] would give you access to any resources that failed to apply. I don't recall how/if actual catalog failures are show in reports. A syntax error, for example, happens on the master and is presented to the client as a server error. One thing I have seen is where the client gives up waiting for the master and uses the cached catalog, but the master doesn't recognize that the client went away, and doesn't think anything went wrong, or anything like that (or at least doesn't create any sort of failure/error report). D -- 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] Inter-Module Dependency
I tried looking in the language tutorial for this, but I couldn't find a reference for how to do it, but I'm sure it must be possible. So I've got two modules, one for random_app and one for dns_config. dns_config has a file resource resolv.conf which is just what the name implies. I want service 'foo' in my random_app module to subscribe to dns_config's resolv.conf, and if the resolv.conf changes, to restart. (Because, it's a misbehaving app who doesn't just use gethostbyname() calls, but runs its own resolver and never looks at resolv.conf again after it starts up.) I would have thought it'd just be subscribing the service to File['dns_config::resolv.conf'] but clearly that didn't work. ... Could not find dependency File[dns_config::resolv.conf] Any ideas on what I need to do to make that work? Cheers, D -- 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.
Re: [Puppet Users] Possible to disable puppets internal CA, and use wildcard certs from DigiCert CA?
On Jan 28, 2011, at 2:02 PM, Daniel Pittman wrote: Yes. On the other hand, you will very quickly run into a problem: The puppet master uses the name in the SSL certificate that the client supplies as the node identifier. So, if you use that wildcard for your nodes you will not be able to uniquely identify them. You would have to have the same manifest on all of them, or reinvent all the distinctions that puppet already makes. I thought someone pointed out (when I went on one of my rants about the SSL/CA stuff in puppet) that there's a configuration-option to tell the puppetmaster to use the $fqdn fact as the nodename instead? So it shouldn't be THAT hard, if it's just a config-option. D -- 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.
Re: [Puppet Users] Puppetmaster module path specification with wildcards
On Jan 18, 2011, at 9:38 PM, Bostjan Skufca wrote: Would anyone else fancy a wildcard path expansion in module path specification? Example: modulepath = /etc/puppet/modules/* ---[ above should expand to this equivalent ]-- [ provided that repo1 and repo2 dirs exist in /etc/puppet/modules ] modulepath = /etc/puppet/modules/repo1:/etc/puppet/modules/repo2 There are a couple potential caveats to that, the most serious being sort methodology for the wildcard expansion. It would have to be deterministic in terms of always being sorted the same way (because a straight wildcard expansion will present the various directory items in essentially random order). If you care about in what order things are in the path, then it would be a bad idea to use, but if the sort-methodology is well documented so nobody is surprised, then it should be fine. (IMHO) D -- 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] Disabling Certificates
Has anyone had any luck in actually disabling certificates entirely. Just trust the hostname you get from DNS and treat that info as authoritative. I'm in the Puppet BoF @ LISA, and (essentially) was told that's never going to happen, even though I have *no* need for the security that the certificates theoretically provide and they get in my way far more often than any alleged help. Has anyone managed to just obliterate the whole certificate-nightmare from Puppet? Is there anyone else who thinks they add way more complications than they are worth? Cheers, D -- 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: Disabling Certificates
On Nov 11, 2010, at 6:26 PM, donavan wrote: From your comment in #3958 I think autosign[1] with *.domain.tld would work for you. Nope. Because autosign doesn't also auto-overwrite. - New Host foo001.domain.tld is created - Certs are exchanged for foo001 with the puppetmaster, life is good, autosigned - Host foo001.domain.tld is retired - Replacement Host foo001.domain.tld is created - foo001 tries to talk to puppetmaster, presenting brand new certs. They don't match what the master has for that host. It tells foo001 to pound-sand. At that point, I have to manually log into the CA and clean out the certificates for foo001. I also have to go out to foo001, and blow away all ITS certs, since it's been given a cert it has no idea what to do with. It's just ugly. Like I said in my ticket notes, I'll concede that for some people, it's a necessity, but there's clearly also a set of people for whom it is just unnecessary pain and suffering. -- 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] Refreshing puppetd from within puppetd
On Jun 21, 2010, at 9:03 PM, Patrick Mohr wrote:
Anyone have advice? I don't want to put puppet in cron if I can avoid it.
We did this:
service { puppet :
enable = true,
require = [ File['etc-sysconfig-puppet'],File['puppet.conf'] ],
subscribe = [ File['etc-sysconfig-puppet'],File['puppet.conf'] ],
hasrestart = true
}
the hasrestart tells it not to do a stop, start but instead to do a
restart, so it happily seems to work any time we change a config file.
D
--
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.
