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