I've setup 5 centos hosts that all work fine but after signing my
debian client request I get
Certificate validation failed; consider using the certname
configuration option
on the debian client. Never seen this error message before. Several
times i've rm -rf /etc/puppet/ssl to force it to issue a new
certificate request, which the puppetmaster sees ans signs no
problem. But that signed cert just dosen't work for the client.
/var/log/syslog on debian client.
Mar 28 00:41:46 puppetd[25663]: Reopening log files
Mar 28 00:41:46 puppetd[25663]: Creating a new certificate request
for host
Mar 28 00:41:46 puppetd[25663]: Creating a new SSL key at /etc/puppet/
ssl/private_keys/host.pem
Mar 28 00:41:46 puppetd[25663]: Did not receive certificate
Mar 28 00:43:46 puppetd[25663]: Got signed certificate
Mar 28 00:43:46 puppetd[25663]: Starting Puppet client version 0.24.7
Mar 28 00:43:49 puppetd[25663]: Caching catalog at /var/lib/puppet/
state/localconfig.yaml
Mar 28 00:43:49 puppetd[25663]: Starting catalog run
Mar 28 00:43:49 puppetd[25663]: Certificate validation failed;
consider using the certname configuration option
this puppet was installed by : apt-get install puppet/experimental
how /etc/hosts has an entry
puppet_master_ip puppet
however this is not the name that is in /etc/puppet/puppet.conf
server=FQDN_of_puppet_master
however my other centos clients have no problems with this. Could
this be a nsswith.conf issue? Both debian and centos have
host files dns
I dont want to change the
[puppetmasterd]
certname
as suggest in error message since that would break my other clients,
as I understand it.
> I've setup 5 centos hosts that all work fine but after signing my
> debian client request I get
> Certificate validation failed; consider using the certname
> configuration option
> on the debian client. Never seen this error message before. Several
> times i've rm -rf /etc/puppet/ssl to force it to issue a new
> certificate request, which the puppetmaster sees ans signs no
> problem. But that signed cert just dosen't work for the client.
> /var/log/syslog on debian client.
> Mar 28 00:41:46 puppetd[25663]: Reopening log files
> Mar 28 00:41:46 puppetd[25663]: Creating a new certificate request
> for host
> Mar 28 00:41:46 puppetd[25663]: Creating a new SSL key at /etc/ > puppet/
> ssl/private_keys/host.pem
> Mar 28 00:41:46 puppetd[25663]: Did not receive certificate
> Mar 28 00:43:46 puppetd[25663]: Got signed certificate
> Mar 28 00:43:46 puppetd[25663]: Starting Puppet client version 0.24.7
> Mar 28 00:43:49 puppetd[25663]: Caching catalog at /var/lib/puppet/
> state/localconfig.yaml
> Mar 28 00:43:49 puppetd[25663]: Starting catalog run
> Mar 28 00:43:49 puppetd[25663]: Certificate validation failed;
> consider using the certname configuration option
> this puppet was installed by : apt-get install puppet/experimental
> how /etc/hosts has an entry
> puppet_master_ip puppet
> however this is not the name that is in /etc/puppet/puppet.conf
> server=FQDN_of_puppet_master
> however my other centos clients have no problems with this. Could
> this be a nsswith.conf issue? Both debian and centos have
> host files dns
> I dont want to change the
> [puppetmasterd]
> certname
> as suggest in error message since that would break my other clients,
> as I understand it.
as it turns out the timzones were different. However , now in
/var/log/syslog I get
Mar 31 18:39:56 debain_client_host puppetd[19020]: Calling puppetca.getcert
Mar 31 18:39:57 debian_client_host puppetd[19020]: Could not request
certificate: Certificate retrieval failed: Certificate request does not
match existing certificate; run 'puppetca --clean debian_client_host'.
I have cleaned the cert on the puppetmasterd and removed the /etc/puppet/ssl
directory on the client several times but still get this error. --debug is
on but it does not tell me how the certificate is not matching.
Appreciate any assistance,
Trevor
On Fri, Mar 27, 2009 at 7:53 PM, Jason Rojas <ja...@nothingbeatsaduck.com>wrote:
> The only time I see these errors is when the date on my client is
> screwed up. Sorry if that doesn't help.
> -Jason
> On Mar 27, 2009, at 5:57 PM, Trevor <mailtrevh...@gmail.com> wrote:
> > Hello to All,
> > I've setup 5 centos hosts that all work fine but after signing my
> > debian client request I get
> > Certificate validation failed; consider using the certname
> > configuration option
> > on the debian client. Never seen this error message before. Several
> > times i've rm -rf /etc/puppet/ssl to force it to issue a new
> > certificate request, which the puppetmaster sees ans signs no
> > problem. But that signed cert just dosen't work for the client.
> > /var/log/syslog on debian client.
> > Mar 28 00:41:46 puppetd[25663]: Reopening log files
> > Mar 28 00:41:46 puppetd[25663]: Creating a new certificate request
> > for host
> > Mar 28 00:41:46 puppetd[25663]: Creating a new SSL key at /etc/
> > puppet/
> > ssl/private_keys/host.pem
> > Mar 28 00:41:46 puppetd[25663]: Did not receive certificate
> > Mar 28 00:43:46 puppetd[25663]: Got signed certificate
> > Mar 28 00:43:46 puppetd[25663]: Starting Puppet client version 0.24.7
> > Mar 28 00:43:49 puppetd[25663]: Caching catalog at /var/lib/puppet/
> > state/localconfig.yaml
> > Mar 28 00:43:49 puppetd[25663]: Starting catalog run
> > Mar 28 00:43:49 puppetd[25663]: Certificate validation failed;
> > consider using the certname configuration option
> > this puppet was installed by : apt-get install puppet/experimental
> > how /etc/hosts has an entry
> > puppet_master_ip puppet
> > however this is not the name that is in /etc/puppet/puppet.conf
> > server=FQDN_of_puppet_master
> > however my other centos clients have no problems with this. Could
> > this be a nsswith.conf issue? Both debian and centos have
> > host files dns
> > I dont want to change the
> > [puppetmasterd]
> > certname
> > as suggest in error message since that would break my other clients,
> > as I understand it.
On Mar 31, 1:43 pm, Trevor Price <mailtrevh...@gmail.com> wrote:
> as it turns out the timzones were different. However , now in
> /var/log/syslog I get
> Mar 31 18:39:56 debain_client_host puppetd[19020]: Calling puppetca.getcert
> Mar 31 18:39:57 debian_client_host puppetd[19020]: Could not request
> certificate: Certificate retrieval failed: Certificate request does not
> match existing certificate; run 'puppetca --clean debian_client_host'.
> I have cleaned the cert on the puppetmasterd and removed the /etc/puppet/ssl
> directory on the client several times but still get this error. --debug is
> on but it does not tell me how the certificate is not matching.
I saw something similar when I tried to preseed the installation of
puppet using "d-i pkgsel/include string puppet"
The preseed installation used different directory paths than the "apt-
get install puppet" installs I had done previously. When my
centralized puppet.conf file would get written to the client, the next
run through consistently produced a bunch of 500 errors as the
certificates no longer matched. So you might check that your certs
are where you think they should be. Maybe with "puppetd --genconfig" ?
Scott Frazer wrote: > On Mar 31, 1:43 pm, Trevor Price <mailtrevh...@gmail.com> wrote: >> as it turns out the timzones were different. However , now in >> /var/log/syslog I get >> Mar 31 18:39:56 debain_client_host puppetd[19020]: Calling puppetca.getcert >> Mar 31 18:39:57 debian_client_host puppetd[19020]: Could not request >> certificate: Certificate retrieval failed: Certificate request does not >> match existing certificate; run 'puppetca --clean debian_client_host'.
Scott Frazer wrote: > I saw something similar when I tried to preseed the installation of > puppet using "d-i pkgsel/include string puppet"
> The preseed installation used different directory paths than the "apt- > get install puppet" installs I had done previously. When my > centralized puppet.conf file would get written to the client, the next > run through consistently produced a bunch of 500 errors as the > certificates no longer matched. So you might check that your certs > are where you think they should be. Maybe with "puppetd --genconfig" ?
Whilst I am not preseed best friend I don't see how this is possible.
Why would preseed do installation any differently? d-i pkgsel/include should use Debian standard package tool - in this case aptitude - to install.
> Scott Frazer wrote:
> > I saw something similar when I tried to preseed the installation of
> > puppet using "d-i pkgsel/include string puppet"
> > The preseed installation used different directory paths than the "apt-
> > get install puppet" installs I had done previously. When my
> > centralized puppet.conf file would get written to the client, the next
> > run through consistently produced a bunch of 500 errors as the
> > certificates no longer matched. So you might check that your certs
> > are where you think they should be. Maybe with "puppetd --genconfig" ?
> Whilst I am not preseed best friend I don't see how this is possible.
> Why would preseed do installation any differently? d-i pkgsel/include
> should use Debian standard package tool - in this case aptitude - to
> install.
I'd love to know myself. All I know is that I spent a weekend trying
to figure out why my new installs were constantly generating 500
messages. Then I discovered that Ubuntu also broke apt-get in such a
way as to prevent it from doing an install on first boot through an
init.d script.
For now, I've got a manual process in setting up the puppet client
software, but then everything else gets set up for me, so it's still a
time saver.
> On Apr 1, 4:37 pm, James Turnbull <ja...@lovedthanlost.net> wrote: >> Why would preseed do installation any differently? d-i pkgsel/include >> should use Debian standard package tool - in this case aptitude - to >> install.
> I'd love to know myself. All I know is that I spent a weekend trying > to figure out why my new installs were constantly generating 500 > messages. Then I discovered that Ubuntu also broke apt-get in such a > way as to prevent it from doing an install on first boot through an > init.d script.
> For now, I've got a manual process in setting up the puppet client > software, but then everything else gets set up for me, so it's still a > time saver.
I don't have a recent Ubuntu preseed setup, but here's what I ended up with for preseeding a newer Puppet onto Debian etch on Feb. 23 (lines may break badly -- each d-i entry should be a single line).
as I understand it certname is a puppetmasterd change. Doing so would
break the existing dozen centos clients that are working fine. The
client side
server=FQDN_of_puppet_master
and the puppetmaster thinks its name is its FQDN
now the puppet clients all have /etc/hosts entries for
ip_of_puppetmaster puppet
so that "puppet" can be used in the manifests to specify fileserver.
Don't want to hardcode specific hostnames here in the manifests.
Unfortunately I am in a hosted situation and do not control dns.
Just /etc/hosts.
On Apr 1, 2:35 pm, James Turnbull <ja...@lovedthanlost.net> wrote:
> Scott Frazer wrote:
> > On Mar 31, 1:43 pm, Trevor Price <mailtrevh...@gmail.com> wrote:
> >> as it turns out the timzones were different. However , now in
> >> /var/log/syslog I get
> >> Mar 31 18:39:56 debain_client_host puppetd[19020]: Calling puppetca.getcert
> >> Mar 31 18:39:57 debian_client_host puppetd[19020]: Could not request
> >> certificate: Certificate retrieval failed: Certificate request does not
> >> match existing certificate; run 'puppetca --clean debian_client_host'.
On Apr 1, 5:26 pm, Scott Frazer <sfra...@gmail.com> wrote:
> I'd love to know myself. All I know is that I spent a weekend trying
> to figure out why my new installs were constantly generating 500
> messages. Then I discovered that Ubuntu also broke apt-get in such a
> way as to prevent it from doing an install on first boot through an
> init.d script.
Okay, I figured out what I did wrong. Debian's way for the SSL certs
is to put them in /var/lib/puppet/ssl. If you run puppetd with an
empty puppet.conf, your certs will go in /etc/puppet/ssl. My problem
wasn't with the preseed install, but the minimal puppet.conf file I
created to bootstrap through to the puppet server (which in my network
isn't named "puppet")
