On Wednesday, March 30, 2016 at 4:48:47 PM UTC-5, Dave Alden wrote:
>
> Hi,
>    I'm running into a problem with puppet agent on my Mac's.  I have ~200 
> mac's and when they reboot, a few of them (typically 5-10) have problems 
> where the "fqdn" fact is set to "localhost" (as is the "hostname" fact).  
> This causes them to try to request a new cert using the certname "localhost" 
> and therefore puppet (which is run by launchd) never works (it just sits 
> there printing "Notice: Did not receive certificate" every 2 minutes .  I 
> have a few "hacks" that I've thought of to fix this, but I'm not a fan of 
> them:
>
> 1)  Write a script that runs every <n> minutes looking at the puppet.log file 
> to see if the last few lines contains "Did not receive certificate" and 
> unload/load puppet.
>
> 2) Write a wrapper for puppet that makes sure the network is up (and the fqdn 
> is returning a true fqdn) before it starts puppet.
>
> 3) Set the "certname" in puppet.conf -- I don't like this because we rename 
> hosts kind of often and we want their certname to be their fqdn.  I don't 
> want to add another step ("don't forget to login and edit the puppet.conf 
> file before you rename the computer").
>
> I'd much prefer to figure out how to properly fix this (as I would expect 
> that no one really wants the fqdn fact to be "localhost" :) - any suggestions?
>
> ...dave
>
>

If your machines rely on the network to determine their hostnames, and 
Puppet is configured to use the hostname as certname (as it is by default), 
then it follows that you cannot successfully perform Puppet catalog runs 
until the network is up and the machine has determined (or maybe just can 
determine) its own hostname.  I'm not well versed in OS X service 
management, which in any case I understand has changed somewhat over time, 
but surely it has a conventional idiom for expressing that sort of 
dependency.

Alternatively, and perhaps a bit quicker and dirtier, you could run the 
agent via an external scheduler instead of as a daemon in its own right 
(i.e. with --onetime --no-daemonize).  This has a lot of advantages, one of 
the lesser being that if the agent does issue a certificate request, it 
will do so only once per scheduled run (and fail the run if it does not 
receive the requested cert).  Supposing that you can rely on the network 
eventually coming up, and the machines learning their correct hostnames, 
the problem will go away (on a per-machine, per-boot basis) once that 
happens.  Overall, you will see far fewer cert-request errors logged.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/e06d9dd8-b223-43ff-b21f-1d6dd35737ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to