Change from Opensource Chef Server 11 to Chef Server 12 - Recreated clients can no longer update existing nodes

Chef Infra (archive)
1

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 -

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

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

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

2

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.

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:

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 -
Chef Server 12 does not allow client to be recrerated · Issue #54 · chef/chef-server · GitHub

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

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

  o runs wget --user=x --password=y -O -
    https://bootserver/cgi-bin/bootstrap.cgi?action=delete_chef_client&client=$HOSTNAME
  o gets back a JSON document with the clients existing
    environment and run list
  o set the old environment to the variable $ENVIRONMENT
  o create /tmp/foo.json which has the old run_list
  o 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

3

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 mselby@thenextbigsound.com
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 -
Chef Server 12 does not allow client to be recrerated · Issue #54 · chef/chef-server · GitHub

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

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

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

4

which knife plugin provides the knife acl command?

On Fri, Jan 23, 2015 at 3:14 AM, Tiago Cruz tiago.tuxkiller@gmail.com
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 mselby@thenextbigsound.com
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 -
Chef Server 12 does not allow client to be recrerated · Issue #54 · chef/chef-server · GitHub

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

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

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

5

Mark:

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

On Fri, Jan 23, 2015 at 1:48 PM, Mark Selby mselby@thenextbigsound.com
wrote:

which knife plugin provides the knife acl command?

On Fri, Jan 23, 2015 at 3:14 AM, Tiago Cruz tiago.tuxkiller@gmail.com
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 mselby@thenextbigsound.com
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 -
Chef Server 12 does not allow client to be recrerated · Issue #54 · chef/chef-server · GitHub

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

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

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