A couple of reasons, actually, but you have to determine whether or not they apply to you.
First, until Chef 10, the client and server code were intermingled. If you used a cookbook to configure the chef-client, it could accidentally hose your chef server. In my case, one of my recipes deleted the validation.pem key - which is correct on the client, but disastrous ont he server, since it would destroy the root of the PKI infrastructure. The solution was to special-case the chef-server.
In Chef 11, that's no longer a problem. Great job, Opscode team!
Secondly - and that still applies - if you have a bug in one of your cookbooks, you could run into a chicken-and-egg problem. For instance, if you accidentally block port 443 in iptables. With most clients, it's not a big deal - you fix it, and on the next chef run, the client is back. But if you mess up your chef server that way, you can't even run chef-client and have to manually fix the problem. Granted, this type of problem can happen with other things besides chef; I once accidentally brought down our resolving DNS server. Ever since, I use a chef recipe to put the IP address of the chef server into /etc/hosts
Kevin Keane
The NetTech
760-721-8339
http://www.4nettech.com
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html
-----Original message-----
From: Eric Feldhusen < >
Sent: Tuesday 8th October 2013 11:57
To:
Subject: [chef] Chef server as a chef-client on itself ok?
Any reason I shouldn't have the Chef server be a client on itself? I have a couple of recipes that we roll out to all servers, like a NRPE configuration for monitoring by Nagios and specific user accounts.Eric Feldhusen
Archive powered by MHonArc 2.6.16.