Registration when an existing client.pem is present?

Chef Infra (archive)
1

Sometimes when building an AMI I find that I’ve forgotten to delete the
client.pem file, which can cause issues when the node tries to do a run–
it tries to auth with the key, and it doesn’t match a client with the key,
and fails.

I’m guessing that because the client keys can be shared that the answer to
this question is no, but is there a way to set things so that if the client
name does not exist that it will perform registration instead of trying to
use the old key? On some of my setups I’ve worked around this with my
chef-bootstrap.sh deleting client.pem (if it exists) in advance of running
chef-client, but in instances that might get rebooted, I don’t want to do
that (since the client won’t be able to register when it already exists).

Or is there a specific error code that I can trap for when doing this and
detect that it failed?

–
~~ StormeRider ~~

“Every world needs its heroes […] They inspire us to be better than we
are. And they protect from the darkness that’s just around the corner.”

(from Smallville Season 6x1: “Zod”)

On why I hate the phrase “that’s so lame”… http://bit.ly/Ps3uSS

2

You could use the user-data script to delete the client.pem when first booting up the machine. AFAIK it only runs once in the lifecycle of an instance so that if the node's rebooted it won't get deleted again.

  • cassiano

On Wednesday, June 5, 2013 at 05:39, Morgan Blackthorne wrote:

Sometimes when building an AMI I find that I've forgotten to delete the client.pem file, which can cause issues when the node tries to do a run-- it tries to auth with the key, and it doesn't match a client with the key, and fails.

I'm guessing that because the client keys can be shared that the answer to this question is no, but is there a way to set things so that if the client name does not exist that it will perform registration instead of trying to use the old key? On some of my setups I've worked around this with my chef-bootstrap.sh (http://chef-bootstrap.sh) deleting client.pem (if it exists) in advance of running chef-client, but in instances that might get rebooted, I don't want to do that (since the client won't be able to register when it already exists).

Or is there a specific error code that I can trap for when doing this and detect that it failed?

--
~~ StormeRider ~~

"Every world needs its heroes [...] They inspire us to be better than we are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

3

That doesn't really work for ElasticBeanstalk, though, since I'm not the
one handling the EC2 launching, Amazon is.

My current plan is to write a script to be run when building a new AMI, I
was just wondering if there was something I was missing.

On Wednesday, June 5, 2013, Cassiano Leal wrote:

You could use the user-data script to delete the client.pem when first
booting up the machine. AFAIK it only runs once in the lifecycle of an
instance so that if the node's rebooted it won't get deleted again.

  • cassiano

On Wednesday, June 5, 2013 at 05:39, Morgan Blackthorne wrote:

Sometimes when building an AMI I find that I've forgotten to delete the
client.pem file, which can cause issues when the node tries to do a run--
it tries to auth with the key, and it doesn't match a client with the key,
and fails.

I'm guessing that because the client keys can be shared that the answer to
this question is no, but is there a way to set things so that if the client
name does not exist that it will perform registration instead of trying to
use the old key? On some of my setups I've worked around this with my
chef-bootstrap.sh deleting client.pem (if it exists) in advance of
running chef-client, but in instances that might get rebooted, I don't want
to do that (since the client won't be able to register when it already
exists).

Or is there a specific error code that I can trap for when doing this and
detect that it failed?

--
~~ StormeRider ~~

"Every world needs its heroes [...] They inspire us to be better than we
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

--

~~ StormeRider ~~

"Every world needs its heroes [...] They inspire us to be better than we
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

4

On 6/5/13 1:39 AM, Morgan Blackthorne wrote:

I'm guessing that because the client keys can be shared that the answer
to this question is no, but is there a way to set things so that if the
client name does not exist that it will perform registration instead of
trying to use the old key?

It would be possible to create a patch to Chef that checked if the
client existed using the validator client before attempting to use the
client.pem. I'm not a huge fan of adding uses of the validator client
into Chef, however.

Or is there a specific error code that I can trap for when doing this
and detect that it failed?

You might be able to do something with the event dispatch system. There
is a node_load_failed event that you could potentially hook into.
Alternatively, it is likely possible to catch the HTTP 401 errors in an
error handler.

Cheers,

Steven

Steven Danna
Systems Engineer, Opscode, Inc
GPG Key: http://stevendanna.github.com/downloads/code/public.key

5

Is it that big a deal to regenerate the AMI after deleting the key? It seems to me that this would be the easiest and least hacky way out. :slight_smile:

  • cassiano

On Thursday, June 6, 2013 at 10:46, Steven Danna wrote:

On 6/5/13 1:39 AM, Morgan Blackthorne wrote:

I'm guessing that because the client keys can be shared that the answer
to this question is no, but is there a way to set things so that if the
client name does not exist that it will perform registration instead of
trying to use the old key?

It would be possible to create a patch to Chef that checked if the
client existed using the validator client before attempting to use the
client.pem. I'm not a huge fan of adding uses of the validator client
into Chef, however.

Or is there a specific error code that I can trap for when doing this
and detect that it failed?

You might be able to do something with the event dispatch system. There
is a node_load_failed event that you could potentially hook into.
Alternatively, it is likely possible to catch the HTTP 401 errors in an
error handler.

Cheers,

Steven

Steven Danna
Systems Engineer, Opscode, Inc
GPG Key: http://stevendanna.github.com/downloads/code/public.key

6

Yeah, I was just checking if there was any other ways to handle the
situation, but in the end an AMI prep script seems like the easiest and
least hacky solution :slight_smile:

--
~~ StormeRider ~~

"Every world needs its heroes [...] They inspire us to be better than we
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

On Thu, Jun 6, 2013 at 6:57 AM, Cassiano Leal cassianoleal@gmail.comwrote:

Is it that big a deal to regenerate the AMI after deleting the key? It
seems to me that this would be the easiest and least hacky way out. :slight_smile:

  • cassiano

On Thursday, June 6, 2013 at 10:46, Steven Danna wrote:

On 6/5/13 1:39 AM, Morgan Blackthorne wrote:

I'm guessing that because the client keys can be shared that the answer
to this question is no, but is there a way to set things so that if the
client name does not exist that it will perform registration instead of
trying to use the old key?

It would be possible to create a patch to Chef that checked if the
client existed using the validator client before attempting to use the
client.pem. I'm not a huge fan of adding uses of the validator client
into Chef, however.

Or is there a specific error code that I can trap for when doing this
and detect that it failed?

You might be able to do something with the event dispatch system. There
is a node_load_failed event that you could potentially hook into.
Alternatively, it is likely possible to catch the HTTP 401 errors in an
error handler.

Cheers,

Steven

Steven Danna
Systems Engineer, Opscode, Inc
GPG Key: http://stevendanna.github.com/downloads/code/public.key

7

While it doesn't clean up client.pem (yet) here is the code I use for
a quick image clean before a rebundle:

-Cary P

On Thu, Jun 6, 2013 at 2:42 PM, Morgan Blackthorne stormerider@gmail.comwrote:

Yeah, I was just checking if there was any other ways to handle the
situation, but in the end an AMI prep script seems like the easiest and
least hacky solution :slight_smile:

--
~~ StormeRider ~~

"Every world needs its heroes [...] They inspire us to be better than we
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

On Thu, Jun 6, 2013 at 6:57 AM, Cassiano Leal cassianoleal@gmail.comwrote:

Is it that big a deal to regenerate the AMI after deleting the key? It
seems to me that this would be the easiest and least hacky way out. :slight_smile:

  • cassiano

On Thursday, June 6, 2013 at 10:46, Steven Danna wrote:

On 6/5/13 1:39 AM, Morgan Blackthorne wrote:

I'm guessing that because the client keys can be shared that the answer
to this question is no, but is there a way to set things so that if the
client name does not exist that it will perform registration instead of
trying to use the old key?

It would be possible to create a patch to Chef that checked if the
client existed using the validator client before attempting to use the
client.pem. I'm not a huge fan of adding uses of the validator client
into Chef, however.

Or is there a specific error code that I can trap for when doing this
and detect that it failed?

You might be able to do something with the event dispatch system. There
is a node_load_failed event that you could potentially hook into.
Alternatively, it is likely possible to catch the HTTP 401 errors in an
error handler.

Cheers,

Steven

Steven Danna
Systems Engineer, Opscode, Inc
GPG Key: http://stevendanna.github.com/downloads/code/public.key

--
Cary Penniman
Sr. Software Developer
www.RightScale.com http://www.rightscale.com/

Phone: (805) 243-0222
Email: cary@rightscale.com
Skype: carypenniman