Hello, I have a desire to have separate primary/secondary CA servers, and separate puppet master servers running behind a load balancer (ultimately an F5 but will use an Apache mod_proxy.. setup initially to test). The Pro Puppet books suggest this with everything running with Passenger which is fine but is it really necessary for the CA''s or is there an alternative ? Anyone got any example config''s that I can crib off. If that''s the best way then I can start with that and think about the SSL issues that will inevitably arise. Any pointers would be much appreciated. 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hello, The CA server is the most difficult part to architect in a load balancer situation as it''s the one thing that doesn''t cluster that well. The idea is to keep your certificate store in sync across servers. Some people rsync, some people use shared storage, some people don''t care and have just one CA server or use multiple copies of the same CA signing cert - that causes problems if you ever want to revoke a certificate as the serials aren''t the same from server to server. What I''ve done in the past is have a single CA server that''s also an LVS load balancer. The CA (which is actually a puppet master in it''s own right) listens on 8141 and the software load balancer on 8140 directing Puppet requests to a pool of Puppet Masters. It had it''s single points of failure but that was something we were ok to live with. The absolute nicest option is to use a bundled certificate authority where all CAs are signed by some higher level Cert, then most of these problems go away. Last I heard this was broken in Puppet / Ruby. That was early this year and Puppet / Ruby has progressed a lot so maybe people have got it working now - I''d be very interested in hearing from anyone who has. As for the CA being in Passenger, this is trivial if you''ve got your Puppet Masters that compile manifests already in Passenger. The CA Puppet Master is still a standard Puppet Master, you''ve just split the (very small) CA signing workload from the manifest compiling workload. I haven''t read Pro Puppet but I can guess why you might want a primary/secondary, hot stand by or highly-available CA if you''re environment is doing a lot of machine rebuilds - if Puppet isn''t very integral to your environment then maybe you can wear the cost of losing your only CA server and either restoring it from backup or replacing every machine''s Puppet certs (not too difficult with MCollective, really). If your CA goes down it only prevents signing of new machines, existing ones should still work fine. As for the actual config, take a look at the puppet.conf ca_port and ca_server options that will allow you to direct an Agent''s certificate operations to a different server/port. Hope that helps, -Luke On 15/12/11 11:01, OlliesDad@googlemail.com wrote:> Hello, > > I have a desire to have separate primary/secondary CA servers, and > separate puppet master servers running behind a load balancer > (ultimately an F5 but will use an Apache mod_proxy.. setup initially > to test). > > The Pro Puppet books suggest this with everything running with > Passenger which is fine but is it really necessary for the CA''s or is > there an alternative ? Anyone got any example config''s that I can crib > off. If that''s the best way then I can start with that and think about > the SSL issues that will inevitably arise. > > Any pointers would be much appreciated. > > Thanks >-- Luke Bigum Information Systems +44 (0) 20 3192 2520 Luke.Bigum@lmax.com | http://www.lmax.com LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Dec 15, 2011 at 1:27 PM, Luke Bigum <Luke.Bigum@lmax.com> wrote:> Hello, > > The CA server is the most difficult part to architect in a load balancer > situation as it''s the one thing that doesn''t cluster that well. The idea is > to keep your certificate store in sync across servers. Some people rsync, > some people use shared storage, some people don''t care and have just one CA > server or use multiple copies of the same CA signing cert - that causes > problems if you ever want to revoke a certificate as the serials aren''t the > same from server to server. > > What I''ve done in the past is have a single CA server that''s also an LVS > load balancer. The CA (which is actually a puppet master in it''s own right) > listens on 8141 and the software load balancer on 8140 directing Puppet > requests to a pool of Puppet Masters. It had it''s single points of failure > but that was something we were ok to live with. > > The absolute nicest option is to use a bundled certificate authority where > all CAs are signed by some higher level Cert, then most of these problems go > away. Last I heard this was broken in Puppet / Ruby.That used to work before 0.25, sadly broken since. Ruby fully support that, and at the moment its broken in puppet afaik. Ohad>That was early this > year and Puppet / Ruby has progressed a lot so maybe people have got it > working now - I''d be very interested in hearing from anyone who has. > > As for the CA being in Passenger, this is trivial if you''ve got your Puppet > Masters that compile manifests already in Passenger. The CA Puppet Master is > still a standard Puppet Master, you''ve just split the (very small) CA > signing workload from the manifest compiling workload. > > I haven''t read Pro Puppet but I can guess why you might want a > primary/secondary, hot stand by or highly-available CA if you''re environment > is doing a lot of machine rebuilds - if Puppet isn''t very integral to your > environment then maybe you can wear the cost of losing your only CA server > and either restoring it from backup or replacing every machine''s Puppet > certs (not too difficult with MCollective, really). If your CA goes down it > only prevents signing of new machines, existing ones should still work fine. > > As for the actual config, take a look at the puppet.conf ca_port and > ca_server options that will allow you to direct an Agent''s certificate > operations to a different server/port. > > Hope that helps, > > -Luke > > > On 15/12/11 11:01, OlliesDad@googlemail.com wrote: >> >> Hello, >> >> I have a desire to have separate primary/secondary CA servers, and >> separate puppet master servers running behind a load balancer >> (ultimately an F5 but will use an Apache mod_proxy.. setup initially >> to test). >> >> The Pro Puppet books suggest this with everything running with >> Passenger which is fine but is it really necessary for the CA''s or is >> there an alternative ? Anyone got any example config''s that I can crib >> off. If that''s the best way then I can start with that and think about >> the SSL issues that will inevitably arise. >> >> Any pointers would be much appreciated. >> >> Thanks >> > > > -- > Luke Bigum > Information Systems > +44 (0) 20 3192 2520 > Luke.Bigum@lmax.com | http://www.lmax.com > LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN > > > The information in this e-mail and any attachment is confidential and is > intended only for the named recipient(s). The e-mail may not be disclosed or > used by any person other than the addressee, nor may it be copied in any > way. If you are not a named recipient please notify the sender immediately > and delete any copies of this message. Any unauthorized copying, disclosure > or distribution of the material in this e-mail is strictly forbidden. Any > view or opinions presented are solely those of the author and do not > necessarily represent those of the company. > > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> > The absolute nicest option is to use a bundled certificate authority > where > > all CAs are signed by some higher level Cert, then most of these > problems go > > away. Last I heard this was broken in Puppet / Ruby. > > That used to work before 0.25, sadly broken since. > Ruby fully support that, and at the moment its broken in puppet afaik. > > Ohad >Was this bug of yours about that? If so.. maybe others interested can vote it up. http://projects.puppetlabs.com/issues/3770 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/sTgY2Dlq2AwJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.