### Author:  [@Lamont\_Granquist](https://discourse.chef.io/u/Lamont_Granquist)
#### Post date: [January 22, 2015, 11:31pm UTC](https://discourse.chef.io/t/change-from-opensource-chef-server-11-to-chef-server-12-recreated-clients-can-no-longer-update-existing-nodes/6196/2 "2015-01-22T23:31:24Z")
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.
>
>
> validatorless bootstrapping and chef-vault integration
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](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
> o install chef client
> o downloads the validator from bootserver
> o sets up /etc/chef/client.rb correctly
> o runs wget --user=x --password=y -O -
> [https://bootserver/cgi-bin/bootstrap.cgi?action=delete\_chef\_client&client=$HOSTNAME](https://bootserver/cgi-bin/bootstrap.cgi?action=delete_chef_client&client=$HOSTNAME)
> o runs chef\_client
> o 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
>
> ```
> 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
---
### Author:  [@Tiago\_Cruz](https://discourse.chef.io/u/Tiago_Cruz)
#### Post date: [January 23, 2015, 11:14am UTC](https://discourse.chef.io/t/change-from-opensource-chef-server-11-to-chef-server-12-recreated-clients-can-no-longer-update-existing-nodes/6196/3 "2015-01-23T11:14:48Z")
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](http://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](mailto: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](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](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](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
---
### Author:  [@Mark\_Selby](https://discourse.chef.io/u/Mark_Selby)
#### Post date: [January 23, 2015, 3:48pm UTC](https://discourse.chef.io/t/change-from-opensource-chef-server-11-to-chef-server-12-recreated-clients-can-no-longer-update-existing-nodes/6196/4 "2015-01-23T15:48:53Z")
which knife plugin provides the knife acl command?
On Fri, Jan 23, 2015 at 3:14 AM, Tiago Cruz [tiago.tuxkiller@gmail.com](mailto: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](http://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](mailto: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](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](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](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
---
### Author:  [@Tiago\_Cruz](https://discourse.chef.io/u/Tiago_Cruz)
#### Post date: [January 23, 2015, 4:45pm UTC](https://discourse.chef.io/t/change-from-opensource-chef-server-11-to-chef-server-12-recreated-clients-can-no-longer-update-existing-nodes/6196/5 "2015-01-23T16:45:43Z")
Mark:
> **[GitHub - chef-boneyard/knife-acl: knife plugin for working with ACLs on Chef...](https://github.com/chef-boneyard/knife-acl)**
>
> knife plugin for working with ACLs on Chef Server. Contribute to chef-boneyard/knife-acl development by creating an account on GitHub.
$ sudo /opt/chef/embedded/bin/gem install knife-acl
On Fri, Jan 23, 2015 at 1:48 PM, Mark Selby [mselby@thenextbigsound.com](mailto: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](mailto: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](http://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](mailto: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](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](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](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