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.
Interesting idea!
LDAP sucks a LOT when it breaks, and it
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
Yup certname = puppet on both masters (primary/secondary). Yea if you are
setting up a fresh server I usually clear all the pem files under
/var/lib/puppet/ssl then restart puppetmasterd so it generated a fresh new
cert. I then rsync the tree over to the secondary.
I have most of this in a dumb
We only have a handful of people that need shell level access to the
servers so we push the users out with Puppet. Removes the LDAP network
dependency for us.
So sounds like you still maintain the users in LDAP, but use puppet to
pull the users out of LDAP and generate shadow, passwd, and group
Makes sense.
So that's just a certname setting inside the [puppetmasterd] config
section of /etc/puppet.conf on the master, correct? But that needs to be
set as puppet before the puppetmaster is started and any certificates are
signed.
Keeping on this same subject, perhaps you can answer th
The masters would get certname = puppet, so the cert filename would end up
being puppet.pem. You can then create a DNS entry for the VIP called
puppet... You just have to copy that cert to the secondary
nodes as well as keeping the client certs in sync so when a failover happens
you have the clie
On Wed, May 19, 2010 at 11:58:43AM -0400, Matt Juszczak wrote:
> I'd still be a little hesitant to ldapify the boxes, as a failed LDAP
> daemon would potentially could slow(er) authentication to the box I
> need to log into to fix the issue.
We only have a handful of people that need shell level a
I'd rather have most of my changes done in a consistent way that's been
tested on dozens of my nodes than have a special out of band config mechanism
just for puppetmasters. Although my view might change if we ever really
screw it up - but a mistake of that size will kill more than one node in
sta
On Wed, May 19, 2010 at 11:41:36AM -0400, Matt Juszczak wrote:
> However, don't you have concerns that a change could get introduced to
> your puppet config that would cause your puppetmaster to have issues?
There are (to me) two types of changes in this context, changes to the
puppetmaster it
* keepalived to carry the vip
* certname = puppet
* copy the cert from the primary to the secondary
* use a tool to keep /var/lib/puppet/ssl sync'd between the nodes (cron?
rsnapshot?)
Might have to get a little creative.. I think you can also do a common CA, but
that wasn't a requirement for m
"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
I do. Although rather than use environments we have a number of different
puppetmasters, one per location (which is a logical collection of
servers for us) and puppet changes get pushed from staging to live in
the same way as everything else does in our workflow. But with even more
scrutiny ;)
In
On Wed, May 19, 2010 at 11:14:41AM -0400, Matt Juszczak wrote:
> That makes sense, but do you then manage your puppetmaster via puppet as
> a normal client from then on? It would make me nervous.
I do. Although rather than use environments we have a number of different
puppetmasters, one per loc
I have a very small separate set of configs that will bootstrap my
puppet master installation and the other provisioning services I need to
rebuild my entire environment (dhcp etc.) I run (ran, it's been a while)
them via the puppet binary so the only prerequisites are access to
packages repositor
On Tue, May 18, 2010 at 06:01:56PM -0400, Matt Juszczak wrote:
> 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
15 matches
Mail list logo
