I''ve had a small working puppet setup, reduced by circumstances to 1.5
clients, for a while. It was up to 6 at one point, but things scaled
down. So I thought I knew how to make the most basic things work.
But I''ve been beating my head against the wall trying to get a new
master and new clients set up. (The new master will eventually
replace the old one and take on its client as well.)
I''ve got weird naming issues.
The old master is 192.168.1.4, dns name
wrkapp00.esteemedemployer.local (local DNS) and also a public IP under
wrkapp00.esteemedemployer.com.
The new master is 192.168.1.19, no dns name (yet; it''s going to take
over the old name when we cut over).
I''m using /etc/hosts files to make it function as
wrkapp00.esteemedemployer.local to itself and the new clients.
(Puppet, or perhaps merely the documentation, seems very weak on
dealing with systems with no DNS name, and with situations where a
system changes its DNS name. In my experience, when I''m at the stage
of configuring a system where I need to get puppet working, we haven''t
settled the DNS name for the system yet. I could probably get
something temporary put in, but then I''d have to switch it later, and
I''m scared of that given how much trouble I''m having with
this.)
In playing with this, I''ve many times wanted to wipe out all existing
certs on the master. I''ve been doing that with this command:
rm ` find /var/lib/puppet/ssl -type f `
(after stopping puppetmaster). This seems to work; when I restart
puppetmaster it seems to create its own cert (files appear, and
puppetca --all --list reports it).
I''ve installed a manifest and set of files slightly enhanced from what
worked on the old installation.
So, on the new client system (192.168.1.22, prc-mn-
lnx01.esteemedemployer.local), I do:
[root@prc-mn-lnx01 ~]# puppetd --server
wrkapp00.esteemedemployer.local --waitforcert 60 --test
notice: Ignoring --listen on onetime run
err: Could not retrieve catalog from remote server: certificate verify
failed
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
And as you see it fails spectacularly. No signing request appears on
the master, either.
Clues please!
--
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.
Patrick Mohr
2010-Jul-22 17:27 UTC
Re: [Puppet Users] Failing to connect new client to master
The hostname the client connects to, must match the name on the server''s certificate. More info at: http://groups.google.com/group/puppet-users/browse_thread/thread/8bcc83b7f52214db On Jul 22, 2010, at 10:02 AM, WEB PAGE: http://www.dyarstraights.com (08/14/04) WEB PAGE: http://www.livejournal.com/users/allyson13/ (08/14/04) David Dyer-Bennet 11/30/04 Minneapolis, Minnesota Address(es): wrote:> I''ve had a small working puppet setup, reduced by circumstances to 1.5 > clients, for a while. It was up to 6 at one point, but things scaled > down. So I thought I knew how to make the most basic things work. > > But I''ve been beating my head against the wall trying to get a new > master and new clients set up. (The new master will eventually > replace the old one and take on its client as well.) > > I''ve got weird naming issues. > > The old master is 192.168.1.4, dns name > wrkapp00.esteemedemployer.local (local DNS) and also a public IP under > wrkapp00.esteemedemployer.com. > > The new master is 192.168.1.19, no dns name (yet; it''s going to take > over the old name when we cut over). > > I''m using /etc/hosts files to make it function as > wrkapp00.esteemedemployer.local to itself and the new clients. > > (Puppet, or perhaps merely the documentation, seems very weak on > dealing with systems with no DNS name, and with situations where a > system changes its DNS name. In my experience, when I''m at the stage > of configuring a system where I need to get puppet working, we haven''t > settled the DNS name for the system yet. I could probably get > something temporary put in, but then I''d have to switch it later, and > I''m scared of that given how much trouble I''m having with this.) > > In playing with this, I''ve many times wanted to wipe out all existing > certs on the master. I''ve been doing that with this command: > rm ` find /var/lib/puppet/ssl -type f ` > (after stopping puppetmaster). This seems to work; when I restart > puppetmaster it seems to create its own cert (files appear, and > puppetca --all --list reports it). > > I''ve installed a manifest and set of files slightly enhanced from what > worked on the old installation. > > So, on the new client system (192.168.1.22, prc-mn- > lnx01.esteemedemployer.local), I do: > > [root@prc-mn-lnx01 ~]# puppetd --server > wrkapp00.esteemedemployer.local --waitforcert 60 --test > notice: Ignoring --listen on onetime run > err: Could not retrieve catalog from remote server: certificate verify > failed > warning: Not using cache on failed catalog > err: Could not retrieve catalog; skipping run > > And as you see it fails spectacularly. No signing request appears on > the master, either. > > Clues please! > > > > -- > 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.
David Dyer-Bennet
2010-Jul-22 19:20 UTC
Re: [Puppet Users] Failing to connect new client to master
On Thu, July 22, 2010 12:27, Patrick Mohr wrote:> The hostname the client connects to, must match the name on the server''s > certificate.I believe I have that right. On the server, [root@wrkapp00 ddb]# hostname wrkapp00.esteemedemployer.local [root@wrkapp00 ddb]# puppetca --all --list + wrkapp00.esteemedemployer.local The only certificate is its own, and that''s in the name I expect. On the client, [root@prc-mn-lnx01 ~]# puppetd --server wrkapp00.esteemedemployer.local --waitforcert 60 --test notice: Ignoring --listen on onetime run err: Could not retrieve catalog from remote server: certificate verify failed warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run (Ping from the client shows the name is resolving to the IP I expect it to; that it''s actually talking to the server I checked certificate names on.) -- David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info -- 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.
Patrick Mohr
2010-Jul-22 23:20 UTC
Re: [Puppet Users] Failing to connect new client to master
On Jul 22, 2010, at 12:20 PM, David Dyer-Bennet wrote:> > On Thu, July 22, 2010 12:27, Patrick Mohr wrote: >> The hostname the client connects to, must match the name on the server''s >> certificate. > > I believe I have that right. > > On the server, > > [root@wrkapp00 ddb]# hostname > wrkapp00.esteemedemployer.local > [root@wrkapp00 ddb]# puppetca --all --list > + wrkapp00.esteemedemployer.local > > The only certificate is its own, and that''s in the name I expect. > > On the client, > > [root@prc-mn-lnx01 ~]# puppetd --server wrkapp00.esteemedemployer.local > --waitforcert 60 --test > notice: Ignoring --listen on onetime run > err: Could not retrieve catalog from remote server: certificate verify failed > warning: Not using cache on failed catalog > err: Could not retrieve catalog; skipping run > > (Ping from the client shows the name is resolving to the IP I expect it > to; that it''s actually talking to the server I checked certificate names > on.)That''s strange. Are you running puppet under Passenger or Mongrel? If you don''t know, the answer is probably no. What does this command give you on the server? puppetmasterd --genconfig | grep "certname " What does this command give you on the client? puppetd --genconfig | grep "certname " What''s in /var/lib/puppet/ssl on the client and server? Does /var/lib/puppet/ssl/certs/ca.pem on the client and server match? -- 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.
David Dyer-Bennet
2010-Jul-23 16:21 UTC
Re: [Puppet Users] Failing to connect new client to master
On Thu, July 22, 2010 18:20, Patrick Mohr wrote:> > On Jul 22, 2010, at 12:20 PM, David Dyer-Bennet wrote: > >> >> On Thu, July 22, 2010 12:27, Patrick Mohr wrote: >>> The hostname the client connects to, must match the name on the >>> server''s >>> certificate. >> >> I believe I have that right. >> >> On the server, >> >> [root@wrkapp00 ddb]# hostname >> wrkapp00.esteemedemployer.local >> [root@wrkapp00 ddb]# puppetca --all --list >> + wrkapp00.esteemedemployer.local >> >> The only certificate is its own, and that''s in the name I expect. >> >> On the client, >> >> [root@prc-mn-lnx01 ~]# puppetd --server wrkapp00.esteemedemployer.local >> --waitforcert 60 --test >> notice: Ignoring --listen on onetime run >> err: Could not retrieve catalog from remote server: certificate verify >> failed >> warning: Not using cache on failed catalog >> err: Could not retrieve catalog; skipping run >> >> (Ping from the client shows the name is resolving to the IP I expect it >> to; that it''s actually talking to the server I checked certificate names >> on.) > > That''s strange. > > Are you running puppet under Passenger or Mongrel? If you don''t know, the > answer is probably no.I don''t believe I am (it''s the Centos rpm install though, I didn''t lovingly hand-craft each character of configuration).> What does this command give you on the server? > puppetmasterd --genconfig | grep "certname " > > > What does this command give you on the client? > puppetd --genconfig | grep "certname " > > What''s in /var/lib/puppet/ssl on the client and server? > > Does /var/lib/puppet/ssl/certs/ca.pem on the client and server match?At this point I''m three configurations down the road and can''t exactly answer those questions, at least not from the same source as what I previously posted. I''ve been trying to "simplify" and make things more "normal", hoping I can get that running and then build up from there. I''ll keep this on hand if I get back to that error, to provide more useful information. Which is easier, a client on the server, or a client on a different host? (I''ve got both situations that I want to set up, I''m looking for the simplest starting place.) What does the simplest setup look like in general? Also, what are namespaces? My current error references namespaces, and I haven''t so far been able to find them in the documentation (running 0.25.5). -- David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info -- 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.
Jeff McCune
2010-Jul-23 16:32 UTC
Re: [Puppet Users] Failing to connect new client to master
On Thu, Jul 22, 2010 at 4:20 PM, Patrick Mohr <kc7zzv@gmail.com> wrote:>> On the client, >> >> [root@prc-mn-lnx01 ~]# puppetd --server wrkapp00.esteemedemployer.local >> --waitforcert 60 --test >> notice: Ignoring --listen on onetime run >> err: Could not retrieve catalog from remote server: certificate verify failed >> warning: Not using cache on failed catalog >> err: Could not retrieve catalog; skipping run >> >> (Ping from the client shows the name is resolving to the IP I expect it >> to; that it''s actually talking to the server I checked certificate names >> on.)Are the clocks between the two machines in sync? The agent node may think one of the certificates is not yet valid based on time. Cheers, -- Jeff McCune http://www.puppetlabs.com/ -- 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.
David Dyer-Bennet
2010-Jul-23 17:26 UTC
Re: [Puppet Users] Failing to connect new client to master
On Fri, July 23, 2010 11:32, Jeff McCune wrote:> On Thu, Jul 22, 2010 at 4:20 PM, Patrick Mohr <kc7zzv@gmail.com> wrote: >>> On the client, >>> >>> [root@prc-mn-lnx01 ~]# puppetd --server wrkapp00.esteemedemployer.local >>> --waitforcert 60 --test >>> notice: Ignoring --listen on onetime run >>> err: Could not retrieve catalog from remote server: certificate verify >>> failed >>> warning: Not using cache on failed catalog >>> err: Could not retrieve catalog; skipping run >>> >>> (Ping from the client shows the name is resolving to the IP I expect it >>> to; that it''s actually talking to the server I checked certificate >>> names >>> on.) > > Are the clocks between the two machines in sync? The agent node may > think one of the certificates is not yet valid based on time.Yes; in one case the client and the server are the same, and in the other the client is a xen guest on the server. So the clocks are *precisely* synced, in fact :-). -- David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info -- 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.