I''ve tried to implement puppetmaster High Availability (mon+heartbeat). Herefore, the puppet client and puppet master are running on both servers. When the puppet client starts up, it generates a certificate, public and private key for the machine it runs on. When the puppet master starts up, it changes something so that the puppet client have no valid certificate anymore (the certificate isn''t trusted anymore when pulling configuration from the other server, which signed the certificate generated by the puppet client). Same thing on the other server. Is there any way to split the certificates/keys used/generated by the puppet master, and the certificates/keys used/generated by the puppet client on the same machine? grts Koen Vereeken _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
More information about this error: dummyhostA runs the puppet client dummyhostB runs the puppet master certificates on dummyhostB are all OK certificates on dummyhostA are not OK: [root@dummyhostA ssl]# openssl verify -CAfile ./certs/ca.pem ./certs/dummyhostA.domain.be.pem ./certs/dummyhostA.domain.be.pem: /CN=dummyhostB.domain.be error 9 at 1 depth lookup:certificate is not yet valid Shouldn''t this CN have value dummyhostA.domain.be? Further, some error output is provided in /var/log/puppet/masterhttp.log: [2006-11-29 14:15:12] dummyhostA.domain.be - - [29/Nov/2006:14:15:12 EST] "POST /RPC2 HTTP/1.1" 200 1880 [2006-11-29 14:15:12] - -> /RPC2 [2006-11-29 14:15:12] ERROR OpenSSL::SSL::SSLError: sslv3 alert bad certificate /usr/lib/ruby/1.8/openssl/ssl.rb:79:in `accept'' _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Wed, 2006-11-29 at 14:30 +0100, Koen Vereeken wrote:> More information about this error: > > dummyhostA runs the puppet client > dummyhostB runs the puppet master > > certificates on dummyhostB are all OK > certificates on dummyhostA are not OK: > > [root@dummyhostA ssl]# openssl verify > -CAfile ./certs/ca.pem ./certs/dummyhostA.domain.be.pem > ./certs/dummyhostA.domain.be.pem: /CN=dummyhostB.domain.be > error 9 at 1 depth lookup:certificate is not yet validAre the clocks on the two machines in sync ? David
2006/11/29, David Lutterkort <dlutter@redhat.com>:> > On Wed, 2006-11-29 at 14:30 +0100, Koen Vereeken wrote: > > More information about this error: > > > > dummyhostA runs the puppet client > > dummyhostB runs the puppet master > > > > certificates on dummyhostB are all OK > > certificates on dummyhostA are not OK: > > > > [root@dummyhostA ssl]# openssl verify > > -CAfile ./certs/ca.pem ./certs/dummyhostA.domain.be.pem > > ./certs/dummyhostA.domain.be.pem: /CN=dummyhostB.domain.be > > error 9 at 1 depth lookup:certificate is not yet valid > > Are the clocks on the two machines in sync ? > > David > > > Sorry my bad, I''ve tried this on two other machines where the clocks wereout of sync. Nevertheless, the error I have is still there: When setting a master and a client on hostA, and a master and a client on hostB, the following situations work: - clients on hostB pulls configuration from master on hostA - client on hostB pulls configuration from master on hostB - client on hostA pulls configuration from master on hostA The situation that doesn''t work: - client on hostA pulls configuration from master on hostB Even when I clear all certificates and let the client regenerate them it doesn''t work. The error output i get is the following: err: Could not retrieve configuration: Certificates were not trusted: tlsv1 alert unknown ca or err: Could not retrieve configuration: Certificates were not trusted: certificate verify failed when manual verifying the signed certificate of the client (hostA) on the master machine (hostB): -bash-3.00# openssl verify -CAfile /var/lib/puppet/ssl/certs/ca.pem /var/lib/puppet/ssl/ca/signed/hostA..pem /var/lib/puppet/ssl/ca/signed/hostA..pem: /CN=hostA. error 20 at 0 depth lookup:unable to get local issuer certificate It is certainly not a DNS issue or a permition issue (I found some issues with certificates that were not world readable). The time is synchronized on both servers too... _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
This doesn''t work, and it bugs the crap out of me too. It''s fundamental design flaw in the CA methods IMHO. I haven''t had the time to patch it since it''s a pretty huge change to the way authentication works in puppet. The CA cert is tightly coupled to the hostname of the server that generated it. Therefore, you can''t just copy the CA certificates from serverA to serverB and expect all the clients to work, even if you properly configure the server to load those files. The clients will throw a fit since they''re trying to talk to server on hostname "serverB" and it''s certificate is claiming it''s "serverA". If you generate proper CA certificates for serverB, serverB will throw a fit whenever a client connects to it with a certificate signed by serverA, since serverA is untrusted. See the problem? Cheers, -- Jeff McCune The Ohio State University Department of Mathematics Systems Manager _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Nov 29, 2006, at 5:18 AM, Koen Vereeken wrote:> I''ve tried to implement puppetmaster High Availability (mon > +heartbeat). > Herefore, the puppet client and puppet master are running on both > servers. > > When the puppet client starts up, it generates a certificate, > public and private key for the machine it runs on. > When the puppet master starts up, it changes something so that the > puppet client have no valid certificate anymore (the certificate > isn''t trusted anymore when pulling configuration from the other > server, which signed the certificate generated by the puppet > client). Same thing on the other server. > > Is there any way to split the certificates/keys used/generated by > the puppet master, and the certificates/keys used/generated by the > puppet client on the same machine?You should set things up so that you have only one CA but have multiple servers. That is, your CA should not need to be load-balanced, I would think, only the main server. Have you tried that? -- Luke Kanies http://madstop.com | http://reductivelabs.com | 615-594-8199
2006/12/1, Luke Kanies <luke@madstop.com>:> > On Nov 29, 2006, at 5:18 AM, Koen Vereeken wrote: > > > I''ve tried to implement puppetmaster High Availability (mon > > +heartbeat). > > Herefore, the puppet client and puppet master are running on both > > servers. > > > > When the puppet client starts up, it generates a certificate, > > public and private key for the machine it runs on. > > When the puppet master starts up, it changes something so that the > > puppet client have no valid certificate anymore (the certificate > > isn''t trusted anymore when pulling configuration from the other > > server, which signed the certificate generated by the puppet > > client). Same thing on the other server. > > > > Is there any way to split the certificates/keys used/generated by > > the puppet master, and the certificates/keys used/generated by the > > puppet client on the same machine? > > You should set things up so that you have only one CA but have > multiple servers. > > That is, your CA should not need to be load-balanced, I would think, > only the main server. Have you tried that? > > -- > Luke Kanies > http://madstop.com | http://reductivelabs.com | 615-594-8199 > > > I''m getting the same error. The mechanism doesn''t work properly here (Ithink) serverA runs puppetmasterd serverB runs puppetmasterd --noca when I start a client on serverB: puppetd --serve ca --server serverA --test it wants to resolve ca. When I change ''ca'' to ''serverA'', it doesn''t work and there are no signed keys present on serverA (I use autosigning because we want to use it in an automated environment). Is there in fact a good reason to use these certificates? Is the use of a private and public keypair (which is generated also, I noticed) not enough to restrict access? The fact that you are probably sending data over the network is indeed a reason to use encryption, but I think it should be the users choice to deal with this security level, and other transfer protocols should be supported too.. Did you use some high availability with puppet? If so, how did you manage it? Thanks for the support! _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Dec 1, 2006, at 1:16 PM, Koen Vereeken wrote:> > > I''m getting the same error. The mechanism doesn''t work properly > here (I think) > serverA runs puppetmasterd > serverB runs puppetmasterd --noca > > when I start a client on serverB: > puppetd --serve ca --server serverA --test > it wants to resolve ca. When I change ''ca'' to ''serverA'', it doesn''t > work and there are no signed keys present on serverA (I use > autosigning because we want to use it in an automated environment).Hmm. I just realized there should probably be a special attribute for the first connection. Do not tell the client to server the ca. First start the server on the machine with the CA, then start a client on the other server (which signs that server''s certs), then start the second server. On the first connection for other clients, tell the client to directly connect to the machine that has a CA to get the cert signed.> Is there in fact a good reason to use these certificates? Is the > use of a private and public keypair (which is generated also, I > noticed) not enough to restrict access? The fact that you are > probably sending data over the network is indeed a reason to use > encryption, but I think it should be the users choice to deal with > this security level, and other transfer protocols should be > supported too..Yes, there is a good reason. Certificates provide an easy way to handle trust, and they''re basically the standard way to handle authenticity today. They''re much, much easier to handle than simple peer-based trust systems like ssh keys. I''ve tried it the other way (cfengine uses peer keys) and this is actually much easier.> Did you use some high availability with puppet? If so, how did you > manage it?I do not personally use high availability, no, so I haven''t verified that this works. But there''s no reason it shouldn''t. -- Luke Kanies http://madstop.com | http://reductivelabs.com | 615-594-8199
2006/12/1, Luke Kanies <luke@madstop.com>:> On Dec 1, 2006, at 1:16 PM, Koen Vereeken wrote: > > > > > > I''m getting the same error. The mechanism doesn''t work properly > > here (I think) > > serverA runs puppetmasterd > > serverB runs puppetmasterd --noca > > > > when I start a client on serverB: > > puppetd --serve ca --server serverA --test > > it wants to resolve ca. When I change ''ca'' to ''serverA'', it doesn''t > > work and there are no signed keys present on serverA (I use > > autosigning because we want to use it in an automated environment). > > Hmm. I just realized there should probably be a special attribute > for the first connection. > > Do not tell the client to server the ca. First start the server on > the machine with the CA, then start a client on the other server > (which signs that server''s certs), then start the second server. On > the first connection for other clients, tell the client to directly > connect to the machine that has a CA to get the cert signed. >This works! Except for one small details: When starting the second server, it can''t find a CRL. When copying the CRL (mostly found in /var/lib/puppet/ssl/ca/ca_crl.pem) from the first server, the second server can be started. This mechanism works great. High availability can be done now by simply adding an IP to the active puppetmaster node, so that all clients can pull their configuration from that IP, no matter on what server the IP is assigned. Thanks for the support! Remark: Have you ever thought about having some connection pooling functionality? By supplying two servers in the puppetd configuration module, I don''t have to assign an IP to the active node, and high availability issues are also solved.. (and of course various advantages including load balancing for the fileservers, routing problems, failovers, ...)> > Is there in fact a good reason to use these certificates? Is the > > use of a private and public keypair (which is generated also, I > > noticed) not enough to restrict access? The fact that you are > > probably sending data over the network is indeed a reason to use > > encryption, but I think it should be the users choice to deal with > > this security level, and other transfer protocols should be > > supported too.. > > Yes, there is a good reason. Certificates provide an easy way to > handle trust, and they''re basically the standard way to handle > authenticity today. They''re much, much easier to handle than simple > peer-based trust systems like ssh keys. I''ve tried it the other way > (cfengine uses peer keys) and this is actually much easier. > > > Did you use some high availability with puppet? If so, how did you > > manage it? > > I do not personally use high availability, no, so I haven''t verified > that this works. But there''s no reason it shouldn''t. > > -- > Luke Kanies > http://madstop.com | http://reductivelabs.com | 615-594-8199 > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
On 12/5/06, Koen Vereeken <koen.vereeken@gmail.com> wrote:> Remark: Have you ever thought about having some connection pooling > functionality? By supplying two servers in the puppetd configuration > module, I don''t have to assign an IP to the active node, and high > availability issues are also solved.. (and of course various > advantages including load balancing for the fileservers, routing > problems, failovers, ...)You could do a few other things to get around that, the simple one being some sort of round robin DNS configuration, or do something with a pair of redundant load balancers to a pool of puppet masters. I really don''t like the idea of specify services via IP, I''d rather use DNS. Too many developers, too many hardcoded IPs in their code.... -r''
On Tue, Dec 05, 2006 at 05:22:56PM +0100, Koen Vereeken wrote:> > Remark: Have you ever thought about having some connection pooling > functionality? By supplying two servers in the puppetd configuration > module, I don''t have to assign an IP to the active node, and high > availability issues are also solved.. (and of course various > advantages including load balancing for the fileservers, routing > problems, failovers, ...)You could use CARP (OpenBSD) or UCARP (Linux). See http://software.newsforge.com/software/04/04/13/1842214.shtml http://www.ucarp.org/project/ucarp DGS>
Koen Vereeken wrote:> > This works! Except for one small details: > When starting the second server, it can''t find a CRL. When copying the > CRL (mostly found in /var/lib/puppet/ssl/ca/ca_crl.pem) from the first > server, the second server can be started. > This mechanism works great. High availability can be done now by > simply adding an IP to the active puppetmaster node, so that all > clients can pull their configuration from that IP, no matter on what > server the IP is assigned. > Thanks for the support!Very cool! Would you be willing to write up on the cookbook what you did?> Remark: Have you ever thought about having some connection pooling > functionality? By supplying two servers in the puppetd configuration > module, I don''t have to assign an IP to the active node, and high > availability issues are also solved.. (and of course various > advantages including load balancing for the fileservers, routing > problems, failovers, ...)I''ve thought about it, but I''ve clearly not gone far enough to actually implement it. It should be pretty easy to randomly pick one of the list of IP addresses, but as someone else mentioned, it should also be pretty easy to set up round-robin DNS for multiple Puppet servers. -- The covers of this book are too far apart. -- Ambrose Bierce --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
2006/12/7, Luke Kanies <luke@madstop.com>:> > Koen Vereeken wrote: > > > > This works! Except for one small details: > > When starting the second server, it can''t find a CRL. When copying the > > CRL (mostly found in /var/lib/puppet/ssl/ca/ca_crl.pem) from the first > > server, the second server can be started. > > This mechanism works great. High availability can be done now by > > simply adding an IP to the active puppetmaster node, so that all > > clients can pull their configuration from that IP, no matter on what > > server the IP is assigned. > > Thanks for the support! > > Very cool! Would you be willing to write up on the cookbook what you did?Well I did have some spare time this morning: http://reductivelabs.com/cookbook/PuppetHighAvailability> Remark: Have you ever thought about having some connection pooling > > functionality? By supplying two servers in the puppetd configuration > > module, I don''t have to assign an IP to the active node, and high > > availability issues are also solved.. (and of course various > > advantages including load balancing for the fileservers, routing > > problems, failovers, ...) > > I''ve thought about it, but I''ve clearly not gone far enough to actually > implement it. It should be pretty easy to randomly pick one of the list > of IP addresses, but as someone else mentioned, it should also be pretty > easy to set up round-robin DNS for multiple Puppet servers. > > -- > The covers of this book are too far apart. -- Ambrose Bierce > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > >_______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users