[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.
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, 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] CentOS 5 packages in EPEL are outdated ?
Is there rsync access to that repo? I'd like to mirror it behind our firewall so our machines can access it, and HTTP mirroring is so sub-optimal. D On Mar 13, 2012, at 12:58 PM, Michael Stahnke wrote: > Use the Puppet Labs repo, > > http://yum.puppetlabs.com it will always be updated. It does not > require EPEL or any other repository for functionality. > > > Mike > > -- > 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 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] 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] Re: [Puppet-dev] Announce: 2.6.9 Released
Todd, Do you have an ETA for 2.7.x RPMs in that repo by any chance? Cheers, D On Jun 23, 2011, at 11:21 AM, Todd Zullinger wrote: > Michael Stahnke wrote: >> This release is a maintenance release of the 2.6.x series of Puppet. >> This will likely be the last release in the 2.6.x series for Puppet, >> now that 2.7 is out. > > For those using Fedora or RHEL/CentOS, I've updated the yum repos at: > >http://tmz.fedorapeople.org/repo/puppet/ > > Packages for EL 4 - 6 and Fedora 13 - 15 are available for testing. > Add the puppet.repo file from either the epel or fedora directories to > /etc/yum.repos.d to enable. > > If you find problems with the packaging, please let me know. If you > find other bugs, please file them in redmine: > >http://projects.puppetlabs.com/projects/puppet/issues > > -- > ToddOpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp > ~~ > The policy of the American government is to leave its citizens free, > neither restraining nor aiding them in their pursuits. >-- Thomas Jefferson > -- 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] 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.
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] 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.
[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] 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.
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.
[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] 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.
Re: [Puppet Users] Puppet Restarting Puppet, Puppet-Agent's resolver (was Inter-Module Dependency)
On Feb 18, 2011, at 9:29 AM, Felix Frank wrote: > Ugly workaround: Schedule the restart using atd from within the catalog > run. (I've used "at now+2min" and it works so far). Well, that's "less ugly" I suppose than the client just vanishing in the middle of a catalog-run. :-) But also my complaint is: Why *isn't* puppet-agent noticing that resolv.conf has changed? This seems like something that would only be caused by not using the standard gethostbyname() calls and such, since *those* should reflect the change in resolv.conf almost immediately :-/ 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] 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] Re: Passenger, Puppet/ nodes.pp ignored with external nodes script?
FWIW, we use our pre-existing F5s (which we've got for production traffic) so we carved off a Puppetmaster VIP on those with no problem at all. D On Feb 15, 2011, at 9:30 PM, trey85stang wrote: > while I am at it, what is the best way to load balance between > multiple servers using passenger? a dedicated load balancer or can > the balancing be done within passenger like mongrel? > > On Feb 15, 8:11 pm, trey85stang wrote: >> Hey All, I'm still experimenting with a puppet backend for 6000 >> hosts. I have switched from mongrel to a passenger backend on a >> single puppetserver. >> >> Afterwards any node that is not defined in the external nodes script, >> is now rejected even if they have an entry in my nodes.pp manifest. >> With the mongrel server this works as expected. >> >> Anyone know what might be wrong? >> >> OS is CentOS 5.5 >> ruby 1.8.7 compiled from source >> rake from source latest >> puppet 2.6.4 >> latest facter >> everything else is 5.5 based rpms. >> >> Config files are verbatim from the passenger on enterprise linux from >> the puppet documentation. > > -- > 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] 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 esslingen.de> wrote: >> On 8 Mrz., 14:54, Disconnect 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.
