- From: Andrew Brown <
>
- To: "
" <
>
- Subject: [chef] Re: Re: Rebuilding ephemeral chef servers
- Date: Thu, 28 Aug 2014 14:47:30 +0000
- Accept-language: en-US, en-CA
Thanks Ameir and Joe.
Joe - we’re running chef-client as a daemon, so checking return codes of chef-client is problematic. :)
Ameir - that’s interesting. Is there any extra load on the chef server by continually inserting new client keys? How to synchronize with the interval/splay options for chef-client?
Cheers,
Andrew
On 2014-08-28, 10:42 AM, "Joe Nuspl" <
">
> wrote:
Our approach was to wrap chef-client in a script, run-chef-client, that gets invoke from cron. If chef-client fails with “Unauthorized”, it will delete client.pem, re-register, and then re-run chef-client.
Another clever thing run-chef-client does is to force a time sync when authorization fails due to time skew.
Joe
On Aug 28, 2014, at 7:24 AM, Andrew Brown <
">
> wrote:
Ohai Chefs!
I’m investigating building an ephemeral chef server that could be rebuilt in a cloud environment. We already have a solution for re-populating all of our cookbooks, environment files, and roles; however the node data and client keys are problematic, since
chef-client always tries to use client.pem if it exists.
I’ve written a small utility to check whether the client key is valid, by fetching /nodes/<fqdn> once per minute, and deleting client.pem if authentication fails. Would this put excessive load on the Chef Server to have this many requests? Are there
alternate solutions folks have used to solve this problem?
Thanks!
Andrew
|
Archive powered by MHonArc 2.6.16.