Hello,
Before upgrading to 0.8.16 when my nodes booted they registered
themselves regardless of whether or not a client with the same name
existed. With my fresh install of 0.8.16, this behavior has changed
and rebooted nodes fail to register because of the existing client. Is
there a way I can select/revert the old behavior? My nodes are
diskless and boot from a common base OS image so while it’s trivial to
have a validation.pem on the image, it’d be complicated and kludgy to
work out how to keep track of the client.pem for every client/node
across reboots.
Thanks,
griznog
Ohai!
On Sun, Jun 27, 2010 at 6:43 PM, John Hanks griznog@gmail.com wrote:
Hello,
Before upgrading to 0.8.16 when my nodes booted they registered
themselves regardless of whether or not a client with the same name
existed. With my fresh install of 0.8.16, this behavior has changed
and rebooted nodes fail to register because of the existing client. Is
there a way I can select/revert the old behavior? My nodes are
diskless and boot from a common base OS image so while it's trivial to
have a validation.pem on the image, it'd be complicated and kludgy to
work out how to keep track of the client.pem for every client/node
across reboots.
Thanks,
griznog
You're getting a 403 forbidden error when the client attempts to
re-register, yes? This happens because the validation client is no
longer an admin, but a much lesser privileged entity. You could
probably get the old behavior back by creating an admin client (via
knife client create) and using that instead of the stock validation
client. If you do that, though, your entire infrastructure is at risk
should the alt-validator's private key be compromised.
I'd recommend you investigate some means of giving your nodes unique
names. If you configure the node_name in client.rb before the node has
ever registered, you can set any name you want. For example, you could
name the node as the FQDN plus the boot time with something like this:
node_name(hostname -f.strip + IO.read('/proc/stat')[/^btime ([\d]+$)/,1])
HTH,
Dan DeLeo
On Sun, Jun 27, 2010 at 10:21 PM, Daniel DeLeo dan@kallistec.com wrote:
You're getting a 403 forbidden error when the client attempts to
re-register, yes? This happens because the validation client is no
longer an admin, but a much lesser privileged entity. You could
probably get the old behavior back by creating an admin client (via
knife client create) and using that instead of the stock validation
client. If you do that, though, your entire infrastructure is at risk
should the alt-validator's private key be compromised.
I believe the error is a 409 but am not connected well enough to
verify that at the moment. I'm not as concerned about security because
the entire infrastructure is in a secured area so I'll try the admin
client approach and let you know if that fixes it.
I'd recommend you investigate some means of giving your nodes unique
names. If you configure the node_name in client.rb before the node has
ever registered, you can set any name you want. For example, you could
name the node as the FQDN plus the boot time with something like this:
node_name(hostname -f.strip + IO.read('/proc/stat')[/^btime ([\d]+$)/,1])
This seems like it'd solve my client creation problem, but then I'd
have a lot of stale clients around (nodes sometimes reboot frequently
to change OS or role). I'm not sure whether that'd cause any issues
with chef, but it'd violate my cleanliness is next to godliness rule
and require yet another process to periodically clean up lingering
bits. I'm hoping to keep the entire structure as simple as possible
with no more moving parts than are necessary.
Thanks for your help,
jbh
On Mon, Jun 28, 2010 at 7:35 AM, John Hanks griznog@gmail.com wrote:
On Sun, Jun 27, 2010 at 10:21 PM, Daniel DeLeo dan@kallistec.com wrote:
You're getting a 403 forbidden error when the client attempts to
re-register, yes? This happens because the validation client is no
longer an admin, but a much lesser privileged entity. You could
probably get the old behavior back by creating an admin client (via
knife client create) and using that instead of the stock validation
client. If you do that, though, your entire infrastructure is at risk
should the alt-validator's private key be compromised.
I believe the error is a 409 but am not connected well enough to
verify that at the moment. I'm not as concerned about security because
the entire infrastructure is in a secured area so I'll try the admin
client approach and let you know if that fixes it.
Just to follow-up, I made chef-validator an admin and got the behavior
I needed with re-registrations overwriting old registrations.
jbh