[chef] Re: Change from Opensource Chef Server 11 to Chef Server 12 - Recreated clients can no longer update existing nodes

[Lamont Granquist < >]

I'm actively working on a PR now to make `knife bootstrap` able to use the user key to delete any old client or node data, create the new client key with the user's key, create the node with the client key and ship the new client key to the server and bootstrap it.  No validator required.  It will also precreate the node object with the run_list, the environment and optional json attributes.

https://github.com/chef/chef/pull/2030

I think the code is reasonably close to final form, it just needs specs now.

That could probably be updated with a flag so that instead of just nuking the old node, we copied the run_list + environment from the old node to create a new one, or it should be possible to manually twiddle the acls to grant the new client access to the old node, but those are outside of the scope of what I've currently got planned.

On 1/22/15 12:57 PM, Mark Selby wrote:

" type="cite">

This a new mail to round out an old issue and make people aware of a known difference between Chef Opensource Server 11 and the new Chef 12 Server.

The issue is also explained here - https://github.com/chef/chef-server/issues/54

The short of it is this:

In Opensource Chef Server 11 you could bootstrap an existing chef host by running 'knife client delete nodename' and as long as there was the correct validator during bootstrap a new chef client would be created that had full access to the old chef node. This was really nice since you did not have to worry about specifying an environment or run_list for the node as it would take it from saved state on the Chef server.

This behavior does not work with Chef Server 12 and AFAIK there are no plans to make it work. The ACL system is simply different in Chef 12 vs Chef 11 and the new client no longer has write access to the old node even though the names are the same.

This means that I have had to make some changes to way that I rebuild hosts such that I delete the client and the node and then specify the old environment and run_list during the initial chef convergence.

Here is my old workflow

• bootstrap a host via kickstart or preseed
• the %post/late_command wgets a script file from the bootserver and reboots
• the script performs the following
• install chef client
• downloads the validator from bootserver
• sets up /etc/chef/client.rb correctly
• runs wget --user=x --password=y -O - https://bootserver/cgi-bin/bootstrap.cgi?action="delete_chef_client&client=$HOSTNAME
• runs chef_client
• reboot

As you can see I have a very simple CGI script which I call with the node name and on the server a `knife client delete node` is executed.

The new work flow is different in only one way

• runs wget --user=x --password=y -O - https://bootserver/cgi-bin/bootstrap.cgi?action="delete_chef_client&client=$HOSTNAME
• gets back a JSON document with the clients existing environment and run list
• set the old environment to the variable $ENVIRONMENT
• create /tmp/foo.json which has the old run_list
• runs chef_client -E $ENVIRONMENT -j /tmp/foo.json

The bulk of the change was to the cgi script to run `knife node show $client -a chef_environment -a run_list -fj` before deleting the node and then sending that back as a JSON document

Of course there are security issues with this whole setup to around making access to the web server secure to protect against unwanted node deletion.

I also plan to migrate from using knife commands in the cgi to using the official web API when I get some time to learn that part of Chef.

If anyone has any ideas that they think simplifies this and makes it secure -- I am all ears

Thanks for listening