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
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/AxsWMws2SCIJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
