| Hi all, I came across an annoyance in that, I now have set up several chef infrastructures, production/staging/test/dev etc., and opted to have each one have its own chef server as they span different physical locations. However the standard knife client reads its config from /etc/chef/*.pem , or ~/.chef/*.pem by default. I notice you can override this to locations of your choice via a knife.rb file, which can be located in $(pwd)/.chef/knife.rb or ~/.chef/knife.rb or /etc/chef/knife.rb Which is great, as now I can have multiple knife files in different locations, for each of the chef servers (which I've done). Only problem is "knife configure -i" which is the documented way to register yourself as a client of each chef server… this attempts to override whatever knife.rb file it finds.. not very helpful as I've already configured my various knife.rb files to look at different servers with different 'environment' attributes. I dont want to have all these manual steps of post-configuring knife.rb files, I want my knife.rb files committed to git so I can just run&go (™) For my solution, I created a bunch of different directories - chef-production / chef-staging / chef-dev etc., and in each of those had a .chef/knife.rb file configuring knife to the correct place. Furthermore, in each of the directories, I had a subdir "setup" with a script which copies the relevant validation/webui.pems into ~/.chef, runs knife against them with no setup/.chef/knife.rb to be found (it doesnt exist), and copies the resultant client.pem out into the correct directories, so each knife client is totally self contained with all its certs. It drives knife configure -i via expect to do this. A bit of jumping through hoops, but it works a treat. However, it strikes me as inelegant and I would be interested to hear your views on how you solved this (for those that did). -- Geoff |
Archive powered by MHonArc 2.6.16.