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?
On 2014-08-28, 10:42 AM, “Joe Nuspl” <email@example.com:firstname.lastname@example.org> 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.
On Aug 28, 2014, at 7:24 AM, Andrew Brown <email@example.com:firstname.lastname@example.org> wrote:
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/ 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?