Private Chef: registering a client for an existing node


#1

Hi,

as part of the test plan for my current project I need to do something that
is quite customary, I would think:

  • create a Vagrant VM and let it register a client / node
  • run some tests
  • destroy the VM
  • delete the client
  • create a new Vagrant VM with the same node name and let it register the
    client

With Private Chef the client gets created just fine, the Chef run completes
but then saving the node back fails with 403 Forbidden.

See logs: https://gist.github.com/4555435

What gives?

Andrea


#2
  • delete the client
  • create a new Vagrant VM with the same node name and let it register the
    client

Are you deleting node as well while deleting client?

knife node delete
knife client delete

Thanks
Gourav


#3

On Thu, Jan 17, 2013 at 1:24 PM, Gourav Shah gs@initcron.org wrote:

  • delete the client
  • create a new Vagrant VM with the same node name and let it register the
    client

Are you deleting node as well while deleting client?

knife node delete
knife client delete

No, that’s the whole point :slight_smile: And it does work with a “regular” open source
Chef server, doesn’t it?

If I do delete the node it works of course.

It’s as though the new client doesn’t have rights to update the node;
except from the web UI it looks like it does.


#4

No, that’s the whole point :slight_smile: And it does work with a “regular” open
source Chef server, doesn’t it?

Could you double check that? I have been using the open source version of
chef and as long as I remember, you must delete the node before registering
with the same name.

Thanks
Gourav


#5

On Thursday, January 17, 2013 at 5:23 AM, Gourav Shah wrote:

No, that’s the whole point :slight_smile: And it does work with a “regular” open source Chef server, doesn’t it?

Could you double check that? I have been using the open source version of chef and as long as I remember, you must delete the node before registering with the same name.

Thanks
Gourav

In Hosted Chef and Private Chef, clients get permission to update a node by virtue of creating it; clients otherwise have default permissions. This happens because the RBAC system tracks clients, nodes, etc. by internal unique identifiers and not the external ones (i.e., name). In the open source server, there is a simple check for matching name.


Daniel DeLeo


#6

I am using private Chef and I just found that I can remove the client and not the node, and then recreate the client VM just fine.

Jim

From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo
Sent: Thursday, January 17, 2013 9:10 AM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: Re: Re: Private Chef: registering a client for an existing node

On Thursday, January 17, 2013 at 5:23 AM, Gourav Shah wrote:

No, that’s the whole point :slight_smile: And it does work with a “regular” open source Chef server, doesn’t it?

Could you double check that? I have been using the open source version of chef and as long as I remember, you must delete the node before registering with the same name.

Thanks
Gourav
In Hosted Chef and Private Chef, clients get permission to update a node by virtue of creating it; clients otherwise have default permissions. This happens because the RBAC system tracks clients, nodes, etc. by internal unique identifiers and not the external ones (i.e., name). In the open source server, there is a simple check for matching name.


Daniel DeLeo


#7

On Thu, Jan 17, 2013 at 5:10 PM, Daniel DeLeo dan@kallistec.com wrote:

On Thursday, January 17, 2013 at 5:23 AM, Gourav Shah wrote:

No, that’s the whole point :slight_smile: And it does work with a “regular” open
source Chef server, doesn’t it?

Could you double check that? I have been using the open source version of
chef and as long as I remember, you must delete the node before registering
with the same name.

Thanks
Gourav

In Hosted Chef and Private Chef, clients get permission to update a node
by virtue of creating it; clients otherwise have default permissions. This
happens because the RBAC system tracks clients, nodes, etc. by internal
unique identifiers and not the external ones (i.e., name). In the open
source server, there is a simple check for matching name.

That’s what I suspected.
Is there are any sanctioned way of “fixing” permissions after the fact?

The reason I’m asking this is that, if I re-create the client and then go
to edit its permissions (/clients/US14/_acl) it is displayed as having all
rights on the node that has the same name. So one way or the other, it
seems to be inconsistent.

Andrea