Re: cert issues, puppet agent applying configs, problems oh my!

[jcbollinger]

Hmm.  My first response appears to have been eaten.  My apologies if this ends up being a duplicate.

On Wednesday, July 18, 2012 4:21:50 PM UTC-5, Zippy Zeppoli wrote:

So I'm new to puppet and I'm having a bear of a time just getting a test server going.

Welcome!
 

I installed puppet and the puppet client via yum on CentOS on AWS, so that saved me some time.
I followed a few various blog posts about getting everything set up and applying a file, etc.

Now I am trying to install a module (puppetlabs/apache) and it's failing miserably for me.
I installed the module on the puppetmaster, and then tried running a test command to pull down the configs:

# puppet agent --verbose --test
dnsdomainname: Unknown host
dnsdomainname: Unknown host
notice: Ignoring --listen on onetime run
dnsdomainname: Unknown host
dnsdomainname: Unknown host
info: Caching catalog for ip-10*
info: Applying configuration version '1342645763'
info: FileBucket adding {md5}e92bea7e9d70a9ecdc61edd7c0a2f59a
info: /File[/etc/httpd/conf.d/README]: Filebucketed /etc/httpd/conf.d/README to puppet with sum e92bea7e9d70a9ecdc61edd7c0a2f59a
notice: /File[/etc/httpd/conf.d/README]/ensure: removed
info: /File[httpd_vdir]: Scheduling refresh of Service[httpd]
info: FileBucket adding {md5}2674ddafcede67ed823db6e09c8c8985
info: /File[/etc/httpd/conf.d/authz_ldap.conf]: Filebucketed /etc/httpd/conf.d/authz_ldap.conf to puppet with sum 2674ddafcede67ed823db6e09c8c8985
notice: /File[/etc/httpd/conf.d/authz_ldap.conf]/ensure: removed
info: /File[httpd_vdir]: Scheduling refresh of Service[httpd]
info: FileBucket adding {md5}98bb7dc6a56eba83a0f9713eec2d85ba
info: /File[/etc/httpd/conf.d/perl.conf]: Filebucketed /etc/httpd/conf.d/perl.conf to puppet with sum 98bb7dc6a56eba83a0f9713eec2d85ba
notice: /File[/etc/httpd/conf.d/perl.conf]/ensure: removed
info: /File[httpd_vdir]: Scheduling refresh of Service[httpd]
info: FileBucket adding {md5}8b0da169a5f7963b6bf28f9d8de7785f
info: /File[/etc/httpd/conf.d/proxy_ajp.conf]: Filebucketed /etc/httpd/conf.d/proxy_ajp.conf to puppet with sum 8b0da169a5f7963b6bf28f9d8de7785f
notice: /File[/etc/httpd/conf.d/proxy_ajp.conf]/ensure: removed
info: /File[httpd_vdir]: Scheduling refresh of Service[httpd]
info: FileBucket adding {md5}547f3a175849ad68a7a1a6d65df1afd5
info: /File[/etc/httpd/conf.d/python.conf]: Filebucketed /etc/httpd/conf.d/python.conf to puppet with sum 547f3a175849ad68a7a1a6d65df1afd5
notice: /File[/etc/httpd/conf.d/python.conf]/ensure: removed
info: /File[httpd_vdir]: Scheduling refresh of Service[httpd]
info: FileBucket adding {md5}17c85a1796be14bdac36d34f25b955b0
info: /File[/etc/httpd/conf.d/ssl.conf]: Filebucketed /etc/httpd/conf.d/ssl.conf to puppet with sum 17c85a1796be14bdac36d34f25b955b0
notice: /File[/etc/httpd/conf.d/ssl.conf]/ensure: removed
info: /File[httpd_vdir]: Scheduling refresh of Service[httpd]
info: FileBucket adding {md5}d1e9d20dbcec6fe4237204f214284e95
info: /File[/etc/httpd/conf.d/webalizer.conf]: Filebucketed /etc/httpd/conf.d/webalizer.conf to puppet with sum d1e9d20dbcec6fe4237204f214284e95
notice: /File[/etc/httpd/conf.d/webalizer.conf]/ensure: removed
info: /File[httpd_vdir]: Scheduling refresh of Service[httpd]
info: FileBucket adding {md5}98540d3009ecc6435d8770c24a71258a
info: /File[/etc/httpd/conf.d/welcome.conf]: Filebucketed /etc/httpd/conf.d/welcome.conf to puppet with sum 98540d3009ecc6435d8770c24a71258a
notice: /File[/etc/httpd/conf.d/welcome.conf]/ensure: removed
info: /File[httpd_vdir]: Scheduling refresh of Service[httpd]
notice: /Stage[main]/Apache/Service[httpd]/enable: enable changed 'false' to 'true'
notice: /Stage[main]/Apache/Service[httpd]: Triggered 'refresh' from 8 events
notice: Finished catalog run in 2.06 seconds



Looks good right? Until I try to run it for real:

It seems you have a misconception there.  The --test option does not instruct puppet to run without changing the system (that option is spelled --noop).  Instead, it is a shortcut for --debug --no-daemonize, and probably one or two other options that don't spring immediately to mind.  So you already did run puppet "for real".
 

[root@ip-10-*~]# puppet agent --verbose
dnsdomainname: Unknown host
dnsdomainname: Unknown host
Could not prepare for execution: Could not create PID file: /var/run/puppet/agent.pid

Does directory /var/run/puppet exist?  Does the puppet agent have write access to it?  (Don't neglect to consider SELinux if you're running it in enforcing mode.)
 

I also tried forcing it down from the master to no avail:
# puppetrun --host pclient
Triggering pclient
Host pclient failed: hostname was not match with the server certificate
pclient finished with exit code 2
Failed: pclient

That has no nope of working unless the client is running and has --listen enabled.  That was not the case, you showed, and I don't recommend it anyway.  The bit about the certificate could mean any one of several things, but I would ignore it for now.
 

Then I tried:
# puppetd --verbose --no-daemonize --onetime
dnsdomainname: Unknown host
dnsdomainname: Unknown host
notice: Ignoring --listen on onetime run
dnsdomainname: Unknown host
dnsdomainname: Unknown host
info: Caching catalog for ip-*
info: Applying configuration version '1342645763'
notice: Finished catalog run in 0.40 seconds


Looks good no? Nope. Nothing happened and the files weren't pushed down.

Probably nothing happened because you had already applied all the needed changes in your --test run.
 

I have both the master and client named in hosts files. I understand puppet depends a lot on DNS and doesn't work that great with hosts files.

What makes you think that?  Puppet relies on the hosts' name resolution mechanisms about as much as any other network client / server system, but it's not particularly sensitive to details such as local hosts files vs. DNS.
 

Is this a certificate issue?

It doesn't look much like one.
 

Any explanation of why this is happening and how to resolve it would be appreciated.

There's more than one "this" here, but the only one that looks significant to me at this point is the agent's problem creating a PID file.  As far as I can tell, Puppet appears otherwise to be functioning correctly.


John

[Zippy Zeppoli]

>Does directory /var/run/puppet exist?  Does the puppet agent have write access to it?  (Don't neglect to consider SELinux if you're running it in enforcing mode.)

Yes it exists, and I turned selinux off just to make sure. It still has the same problem.

[root@ip ~]# puppet agent

dnsdomainname: Unknown host
dnsdomainname: Unknown host
Could not prepare for execution: Could not create PID file: /var/run/puppet/agent.pid

[root@ip~]# ls -l /var/run/puppet/
total 8
-rw-r--r-- 1 root root 5 Jul 22 04:02 agent.pid

>Probably nothing happened because you had already applied all the needed changes in your --test run.

It said changes were applied, but when I diff  actual file, in this case httpd.conf, nothing changed.

On Wednesday, July 18, 2012 2:21:50 PM UTC-7, Zippy Zeppoli wrote:

So I'm new to puppet and I'm having a bear of a time just getting a test server going.

[root@ip-10-*~]# puppet agent --verbose
dnsdomainname: Unknown host
dnsdomainname: Unknown host
Could not prepare for execution: Could not create PID file: /var/run/puppet/agent.pid

I also tried forcing it down from the master to no avail:
# puppetrun --host pclient
Triggering pclient
Host pclient failed: hostname was not match with the server certificate
pclient finished with exit code 2
Failed: pclient

Then I tried:
# puppetd --verbose --no-daemonize --onetime
dnsdomainname: Unknown host
dnsdomainname: Unknown host
notice: Ignoring --listen on onetime run
dnsdomainname: Unknown host
dnsdomainname: Unknown host
info: Caching catalog for ip-*
info: Applying configuration version '1342645763'
notice: Finished catalog run in 0.40 seconds


Looks good no? Nope. Nothing happened and the files weren't pushed down.

I have both the master and client named in hosts files. I understand puppet depends a lot on DNS and doesn't work that great with hosts files.

Is this a certificate issue?

[jcbollinger]

On Tuesday, July 24, 2012 1:04:38 PM UTC-5, Zippy Zeppoli wrote:

>Does directory /var/run/puppet exist?  Does the puppet agent have write access to it?  (Don't neglect to consider SELinux if you're running it in enforcing mode.)
Yes it exists, and I turned selinux off just to make sure. It still has the same problem.

[root@ip ~]# puppet agent

That would be a lot more informative if you included the --debug flag.  You might also want --no-daemonize.  Or else just use --test as you did before: it's this kind of testing for which that is intended.
 

dnsdomainname: Unknown host
dnsdomainname: Unknown host
Could not prepare for execution: Could not create PID file: /var/run/puppet/agent.pid

How about tackling those "Unknown host" messages.  Maybe that will even resolve the issue.  I think you will find that the messages are ultimately coming from the 'dnsdomainname' command (and thus that bit is not fundamentally a Puppet problem).  Its name notwithstanding, that command does not necessarily rely on DNS lookups.  It does rely on the system's resolver library, which can attempt to perform DNS lookups, but it will look first in /etc/hosts if you have it so configured (in /etc/nsswitch.conf).

It is a fundamental problem if a computer cannot resolve its own name, as seems to be the case for you, but I can't offer much specific help.  I can say that in my experience, it is best to set the system hostname to a fully-qualified domain name (even if it's not registered in DNS).  If you prefer GUI tools, then you can set the system hostname through CentOS's "Network Configuration" applet.  Also, if you change the hostname then you may need to restart the system for it to recognize that you have done so.


John

[Zippy Zeppoli]

I resolved the dnsdomain name issues by adding a FQDN (which dnsdomainname requires).
I was under the impression puppet doesn't require a FQDN when using the hosts file, but I guess I'm wrong based on the behavior.

Here is the output once this is fixed, (it still doesn't create the pidfile)

http://pastie.org/4414723

On Wednesday, July 18, 2012 2:21:50 PM UTC-7, Zippy Zeppoli wrote:

So I'm new to puppet and I'm having a bear of a time just getting a test server going.
I installed puppet and the puppet client via yum on CentOS on AWS, so that saved me some time.
I followed a few various blog posts about getting everything set up and applying a file, etc.

Now I am trying to install a module (puppetlabs/apache) and it's failing miserably for me.
I installed the module on the puppetmaster, and then tried running a test command to pull down the configs:

# puppet agent --verbose --test

dnsdomainname: Unknown host
dnsdomainname: Unknown host

notice: Ignoring --listen on onetime run

dnsdomainname: Unknown host
dnsdomainname: Unknown host

dnsdomainname: Unknown host
dnsdomainname: Unknown host
Could not prepare for execution: Could not create PID file: /var/run/puppet/agent.pid

I also tried forcing it down from the master to no avail:
# puppetrun --host pclient
Triggering pclient
Host pclient failed: hostname was not match with the server certificate
pclient finished with exit code 2
Failed: pclient


Then I tried:
# puppetd --verbose --no-daemonize --onetime

dnsdomainname: Unknown host
dnsdomainname: Unknown host

notice: Ignoring --listen on onetime run

dnsdomainname: Unknown host
dnsdomainname: Unknown host