# Node client deletions before recreating the same client
**URL:** https://discourse.chef.io/t/node-client-deletions-before-recreating-the-same-client/2358
**Category:** Chef Infra (archive)
**Created:** [January 18, 2012, 10:53pm UTC](https://discourse.chef.io/t/node-client-deletions-before-recreating-the-same-client/2358 "2012-01-18T22:53:15Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Kallen](https://discourse.chef.io/u/Kallen)
#### Post date: [January 18, 2012, 10:53pm UTC](https://discourse.chef.io/t/node-client-deletions-before-recreating-the-same-client/2358/1 "2012-01-18T22:53:15Z")
hiya. i'm still hoping to hear from the community how this is being
handled...
how are people handling reinstantiating a chef client using the same
node\_name (i'm using FQDN)? before i can recreate [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)
i first need to delete its previous cryptographic API identity. then the
new [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com) registers itself with the chef server using
validation.pem.
is there anything else available besides issuing "knife client delete
[hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)" prior to relaunching the new [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)?
i'm assuming at this point i'll need to create a launch wrapper that has
the right privileges to make the API call to delete the previous client,
then launch anew. i think i would wrap this in bash inside a knife ec2
template or something else homegrown.
i just now noticed "knife client reregister" and
[Chef Support for Automation & DevOps | Chef](http://help.opscode.com/discussions/problems/397-help-with-creating-an-ec2-bootstrap-replace-functionality). haven't played with it yet. perhaps soon.
thanks,
kallen
On Fri, 06 Jan 2012, [kallen@groknaut.net](mailto:kallen@groknaut.net) wrote:
> hi. hosts are expenable, right? i deploy a host, i kill it and redeploy
> it. yay automation. yay cookie cutters.
>
> how are people solving the issue where you need to first run a "knife
> client delete -y [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)" before you can redeploy that
> same host and have it successfully re-register with the chef-server?
>
> my environment is ec2. i'm slowly moving my team away from using
> ElasticFox to launch instances, and moving toward launching them
> using a smarter script that runs ec2-run-instances command (i'm not yet
> ready for knife ec2).
>
> right now i'm knife client deleting by hand, but that blows. i think
> i'd rather not add crisco and fishing line to my launch script that
> calls the knife client delete first. doing so might involve using ssh
> as an API (blech). or maybe calling knife client delete might not be
> so gross. i haven't decided yet. this launch script isn't even the
> final solution, but it's a step i've taken as an incremental improvement.
>
> what smarter ways y'all're using? even tho i'm not yet using knife ec2,
> don't hesitate telling me solutions that use it :\>
>
> tia,
> kallen
---
### Author:  [@Jesse\_Nelson](https://discourse.chef.io/u/Jesse_Nelson)
#### Post date: [January 18, 2012, 11:48pm UTC](https://discourse.chef.io/t/node-client-deletions-before-recreating-the-same-client/2358/2 "2012-01-18T23:48:07Z")
Two ways I've handled it are a knife client/node delete at the start of re-provisioning, and preserving the client.pem across rebuilds.
On Jan 18, 2012, at 2:53 PM, [kallen@groknaut.net](mailto:kallen@groknaut.net) wrote:
> hiya. i'm still hoping to hear from the community how this is being
> handled...
>
> how are people handling reinstantiating a chef client using the same
> node\_name (i'm using FQDN)? before i can recreate [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)
> i first need to delete its previous cryptographic API identity. then the
> new [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com) registers itself with the chef server using
> validation.pem.
>
> is there anything else available besides issuing "knife client delete
> [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)" prior to relaunching the new [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)?
>
> i'm assuming at this point i'll need to create a launch wrapper that has
> the right privileges to make the API call to delete the previous client,
> then launch anew. i think i would wrap this in bash inside a knife ec2
> template or something else homegrown.
>
> i just now noticed "knife client reregister" and
> [Chef Support for Automation & DevOps | Chef](http://help.opscode.com/discussions/problems/397-help-with-creating-an-ec2-bootstrap-replace-functionality). haven't played with it yet. perhaps soon.
>
> thanks,
> kallen
>
> On Fri, 06 Jan 2012, [kallen@groknaut.net](mailto:kallen@groknaut.net) wrote:
>
> > hi. hosts are expenable, right? i deploy a host, i kill it and redeploy
> > it. yay automation. yay cookie cutters.
> >
> > how are people solving the issue where you need to first run a "knife
> > client delete -y [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)" before you can redeploy that
> > same host and have it successfully re-register with the chef-server?
> >
> > my environment is ec2. i'm slowly moving my team away from using
> > ElasticFox to launch instances, and moving toward launching them
> > using a smarter script that runs ec2-run-instances command (i'm not yet
> > ready for knife ec2).
> >
> > right now i'm knife client deleting by hand, but that blows. i think
> > i'd rather not add crisco and fishing line to my launch script that
> > calls the knife client delete first. doing so might involve using ssh
> > as an API (blech). or maybe calling knife client delete might not be
> > so gross. i haven't decided yet. this launch script isn't even the
> > final solution, but it's a step i've taken as an incremental improvement.
> >
> > what smarter ways y'all're using? even tho i'm not yet using knife ec2,
> > don't hesitate telling me solutions that use it :\>
> >
> > tia,
> > kallen
---
### Author:  [@Jesse\_Campbell](https://discourse.chef.io/u/Jesse_Campbell)
#### Post date: [January 19, 2012, 7:15am UTC](https://discourse.chef.io/t/node-client-deletions-before-recreating-the-same-client/2358/3 "2012-01-19T07:15:04Z")
Another alternative is to give validation.pem admin rights, or to fix the
chef server to allow validation to update clients. I've already submitted a
patch for that, it has yet to be reviewed.
On Jan 18, 2012 6:49 PM, "Jesse Nelson" [spheromak@gmail.com](mailto:spheromak@gmail.com) wrote:
> Two ways I've handled it are a knife client/node delete at the start of
> re-provisioning, and preserving the client.pem across rebuilds.
>
> On Jan 18, 2012, at 2:53 PM, [kallen@groknaut.net](mailto:kallen@groknaut.net) wrote:
>
> > hiya. i'm still hoping to hear from the community how this is being
> > handled...
> >
> > how are people handling reinstantiating a chef client using the same
> > node\_name (i'm using FQDN)? before i can recreate [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)
> > i first need to delete its previous cryptographic API identity. then the
> > new [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com) registers itself with the chef server using
> > validation.pem.
> >
> > is there anything else available besides issuing "knife client delete
> > [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)" prior to relaunching the new
> > [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)?
> >
> > i'm assuming at this point i'll need to create a launch wrapper that has
> > the right privileges to make the API call to delete the previous client,
> > then launch anew. i think i would wrap this in bash inside a knife ec2
> > template or something else homegrown.
> >
> > i just now noticed "knife client reregister" and
>
> [Chef Support for Automation & DevOps | Chef](http://help.opscode.com/discussions/problems/397-help-with-creating-an-ec2-bootstrap-replace-functionality).
> haven't played with it yet. perhaps soon.
>
> > thanks,
> > kallen
> >
> > On Fri, 06 Jan 2012, [kallen@groknaut.net](mailto:kallen@groknaut.net) wrote:
> >
> > > hi. hosts are expenable, right? i deploy a host, i kill it and redeploy
> > > it. yay automation. yay cookie cutters.
> > >
> > > how are people solving the issue where you need to first run a "knife
> > > client delete -y [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)" before you can redeploy that
> > > same host and have it successfully re-register with the chef-server?
> > >
> > > my environment is ec2. i'm slowly moving my team away from using
> > > ElasticFox to launch instances, and moving toward launching them
> > > using a smarter script that runs ec2-run-instances command (i'm not yet
> > > ready for knife ec2).
> > >
> > > right now i'm knife client deleting by hand, but that blows. i think
> > > i'd rather not add crisco and fishing line to my launch script that
> > > calls the knife client delete first. doing so might involve using ssh
> > > as an API (blech). or maybe calling knife client delete might not be
> > > so gross. i haven't decided yet. this launch script isn't even the
> > > final solution, but it's a step i've taken as an incremental
> > > improvement.
> > >
> > > what smarter ways y'all're using? even tho i'm not yet using knife ec2,
> > > don't hesitate telling me solutions that use it :\>
> > >
> > > tia,
> > > kallen
---
### Author:  [@Jesse\_Campbell](https://discourse.chef.io/u/Jesse_Campbell)
#### Post date: [January 19, 2012, 7:18am UTC](https://discourse.chef.io/t/node-client-deletions-before-recreating-the-same-client/2358/4 "2012-01-19T07:18:28Z")
Sorry, I meant you can edit the chef-validator client and set it as an
admin.
On Jan 19, 2012 2:15 AM, "Jesse Campbell" [hikeit@gmail.com](mailto:hikeit@gmail.com) wrote:
> Another alternative is to give validation.pem admin rights, or to fix the
> chef server to allow validation to update clients. I've already submitted a
> patch for that, it has yet to be reviewed.
> On Jan 18, 2012 6:49 PM, "Jesse Nelson" [spheromak@gmail.com](mailto:spheromak@gmail.com) wrote:
>
> > Two ways I've handled it are a knife client/node delete at the start of
> > re-provisioning, and preserving the client.pem across rebuilds.
> >
> > On Jan 18, 2012, at 2:53 PM, [kallen@groknaut.net](mailto:kallen@groknaut.net) wrote:
> >
> > > hiya. i'm still hoping to hear from the community how this is being
> > > handled...
> > >
> > > how are people handling reinstantiating a chef client using the same
> > > node\_name (i'm using FQDN)? before i can recreate [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)
> > > i first need to delete its previous cryptographic API identity. then the
> > > new [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com) registers itself with the chef server using
> > > validation.pem.
> > >
> > > is there anything else available besides issuing "knife client delete
> > > [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)" prior to relaunching the new
> > > [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)?
> > >
> > > i'm assuming at this point i'll need to create a launch wrapper that has
> > > the right privileges to make the API call to delete the previous client,
> > > then launch anew. i think i would wrap this in bash inside a knife ec2
> > > template or something else homegrown.
> > >
> > > i just now noticed "knife client reregister" and
> >
> > [Chef Support for Automation & DevOps | Chef](http://help.opscode.com/discussions/problems/397-help-with-creating-an-ec2-bootstrap-replace-functionality).
> > haven't played with it yet. perhaps soon.
> >
> > > thanks,
> > > kallen
> > >
> > > On Fri, 06 Jan 2012, [kallen@groknaut.net](mailto:kallen@groknaut.net) wrote:
> > >
> > > > hi. hosts are expenable, right? i deploy a host, i kill it and redeploy
> > > > it. yay automation. yay cookie cutters.
> > > >
> > > > how are people solving the issue where you need to first run a "knife
> > > > client delete -y [hostXYZ.chefruulz.com](http://hostXYZ.chefruulz.com)" before you can redeploy that
> > > > same host and have it successfully re-register with the chef-server?
> > > >
> > > > my environment is ec2. i'm slowly moving my team away from using
> > > > ElasticFox to launch instances, and moving toward launching them
> > > > using a smarter script that runs ec2-run-instances command (i'm not yet
> > > > ready for knife ec2).
> > > >
> > > > right now i'm knife client deleting by hand, but that blows. i think
> > > > i'd rather not add crisco and fishing line to my launch script that
> > > > calls the knife client delete first. doing so might involve using ssh
> > > > as an API (blech). or maybe calling knife client delete might not be
> > > > so gross. i haven't decided yet. this launch script isn't even the
> > > > final solution, but it's a step i've taken as an incremental
> > > > improvement.
> > > >
> > > > what smarter ways y'all're using? even tho i'm not yet using knife ec2,
> > > > don't hesitate telling me solutions that use it :\>
> > > >
> > > > tia,
> > > > kallen