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

[Tiago Cruz < >]

Mark:

https://github.com/chef/knife-acl

$ sudo /opt/chef/embedded/bin/gem install knife-acl

On Fri, Jan 23, 2015 at 1:48 PM, Mark Selby < " target="_blank"> > wrote:

which knife plugin provides the knife acl command?

On Fri, Jan 23, 2015 at 3:14 AM, Tiago Cruz < " target="_blank"> > wrote:

I same the same issue.

O do the 'knife node create' using one machine, create some tags in and after I create the machine, and we stay without permission.

For now, what I'm doing is:

echo -n "Enter the machine fqdn: "

read HOST

OLD="machinecreater.com"

knife acl remove nodes $HOST update client $OLD

knife acl remove nodes $HOST read client $OLD

knife acl remove nodes $HOST create client $OLD

knife acl remove nodes $HOST delete client $OLD

knife acl add nodes $HOST update client $HOST

knife acl add nodes $HOST read client $HOST

knife acl add nodes $HOST create client $HOST

knife acl add nodes $HOST delete client $HOST

knife acl show nodes $HOST | grep $HOST

On Thu, Jan 22, 2015 at 6:57 PM, Mark Selby < " target="_blank"> > wrote:

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

--

-- Tiago Cruz

--

-- Tiago Cruz