Node name coming across wrong


#1

I am bootstrapping a linux node: “knife bootstrap
servername01.domain.org-x root -P [password]” knife node list
afterwords shows “servername01”, Not
the expected “servername01.domain.org” (FYI, this was bootstrapped before,
i did a “knife node delete” and “knife client delete”) Also, i had to give
the parameter --no-host-key-verify in the bootstrap bease of an error i was
getting. Things “seem” to work just fine until i try to re-run chef-client
a second time after bootstrapping.

Other boxed we have bootstrapped have gotten the name we expect. I am
guessing that maybe there is something that mixxing things up because the
hef server considers this as a “known host” even after the “knife node
delete” process…

Any pointers.


#2

Perhaps, using “node_name” setting in the client.rb file would fix this issue. I ran into similar issue and was able to fix it by setting this value to the FQDN name of the node.

-Kapil

From: Kenneth Barry [mailto:kbarry-x@tunein.com]
Sent: Monday, March 10, 2014 2:22 PM
To: chef@lists.opscode.com
Subject: [chef] node name coming across wrong.

I am bootstrapping a linux node: “knife bootstrap servername01.domain.orghttp://servername01.domain.org -x root -P [password]” knife node list afterwords shows “servername01”, Not the expected “servername01.domain.orghttp://servername01.domain.org” (FYI, this was bootstrapped before, i did a “knife node delete” and “knife client delete”) Also, i had to give the parameter --no-host-key-verify in the bootstrap bease of an error i was getting. Things “seem” to work just fine until i try to re-run chef-client a second time after bootstrapping.
Other boxed we have bootstrapped have gotten the name we expect. I am guessing that maybe there is something that mixxing things up because the hef server considers this as a “known host” even after the “knife node delete” process…
Any pointers.


This email and any accompanying documents may contain privileged or otherwise confidential information of, and/or is the property of Education Management Solutions, Inc. If you are not the intended recipient, please immediately advise the sender by reply email & delete the message & any attachments without using, copying or disclosing the contents. Thank you.


#3

That sounds like it would work.

Any ideas on why the node name is the short name, isntead of the FQDN?

I guess i could ass "-N [FQDN], but i thought was assumed in the use of the
FQDN in the bootstrapping

On Mon, Mar 10, 2014 at 11:30 AM, Kapil Shardha <
Kapil.Shardha@simulationiq.com> wrote:

Perhaps, using “node_name” setting in the client.rb file would fix this
issue. I ran into similar issue and was able to fix it by setting this
value to the FQDN name of the node.

-Kapil

From: Kenneth Barry [mailto:kbarry-x@tunein.com]
Sent: Monday, March 10, 2014 2:22 PM
To: chef@lists.opscode.com
Subject: [chef] node name coming across wrong.

I am bootstrapping a linux node: “knife bootstrap servername01.domain.org-x root -P [password]” knife node list afterwords shows “servername01”, Not
the expected “servername01.domain.org” (FYI, this was bootstrapped
before, i did a “knife node delete” and “knife client delete”) Also, i had
to give the parameter --no-host-key-verify in the bootstrap bease of an
error i was getting. Things “seem” to work just fine until i try to re-run
chef-client a second time after bootstrapping.

Other boxed we have bootstrapped have gotten the name we expect. I am
guessing that maybe there is something that mixxing things up because the
hef server considers this as a “known host” even after the “knife node
delete” process…

Any pointers.


This email and any accompanying documents may contain privileged or
otherwise confidential information of, and/or is the property of Education
Management Solutions, Inc. If you are not the intended recipient, please
immediately advise the sender by reply email & delete the message & any
attachments without using, copying or disclosing the contents. Thank you.


#4

When you don’t specify the node name, chef tries to determine the name from ohai data. Ohai’s fqdn attribute is pulled from hostname —fqdn, which can be blank if either your reverse DNS or /etc/hosts don’t specify it. Probably something is different about this particular machine’s configuration compared to the others which is causing this issue.


Daniel DeLeo

On Monday, March 10, 2014 at 11:35 AM, Kenneth Barry wrote:

That sounds like it would work.

Any ideas on why the node name is the short name, isntead of the FQDN?

I guess i could ass "-N [FQDN], but i thought was assumed in the use of the FQDN in the bootstrapping

On Mon, Mar 10, 2014 at 11:30 AM, Kapil Shardha <Kapil.Shardha@simulationiq.com (mailto:Kapil.Shardha@simulationiq.com)> wrote:

Perhaps, using “node_name” setting in the client.rb file would fix this issue. I ran into similar issue and was able to fix it by setting this value to the FQDN name of the node.

-Kapil

From: Kenneth Barry [mailto:kbarry-x@tunein.com]
Sent: Monday, March 10, 2014 2:22 PM
To: chef@lists.opscode.com (mailto:chef@lists.opscode.com)
Subject: [chef] node name coming across wrong.

I am bootstrapping a linux node: “knife bootstrap servername01.domain.org (http://servername01.domain.org) -x root -P [password]” knife node list afterwords shows “servername01”, Not the expected “servername01.domain.org (http://servername01.domain.org)” (FYI, this was bootstrapped before, i did a “knife node delete” and “knife client delete”) Also, i had to give the parameter --no-host-key-verify in the bootstrap bease of an error i was getting. Things “seem” to work just fine until i try to re-run chef-client a second time after bootstrapping.

Other boxed we have bootstrapped have gotten the name we expect. I am guessing that maybe there is something that mixxing things up because the hef server considers this as a “known host” even after the “knife node delete” process…

Any pointers.

This email and any accompanying documents may contain privileged or otherwise confidential information of, and/or is the property of Education Management Solutions, Inc. If you are not the intended recipient, please immediately advise the sender by reply email & delete the message & any attachments without using, copying or disclosing the contents. Thank you.


#5

Also note that a lot of system deployment tools have horrible ideas about how to do /etc/hosts, /etc/sysconfig/network or /etc/hostname, and DNS hostnaming. I’d strongly encourage you to use the “fqdn” cookbook to standardize what winds up in /etc/hosts.


Nico Kadel-Garcia
Senior Systems Consultant
Email: nkadelgarcia-consultant@scholastic.com
Cell Phone: +1.339.368.2428


From: Daniel DeLeo ddeleo@kallistec.com on behalf of Daniel DeLeo dan@kallistec.com
Sent: Tuesday, March 11, 2014 12:53 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: RE: node name coming across wrong.

When you don’t specify the node name, chef tries to determine the name from ohai data. Ohai’s fqdn attribute is pulled from hostname —fqdn, which can be blank if either your reverse DNS or /etc/hosts don’t specify it. Probably something is different about this particular machine’s configuration compared to the others which is causing this issue.


Daniel DeLeo

On Monday, March 10, 2014 at 11:35 AM, Kenneth Barry wrote:

That sounds like it would work.

Any ideas on why the node name is the short name, isntead of the FQDN?

I guess i could ass "-N [FQDN], but i thought was assumed in the use of the FQDN in the bootstrapping

On Mon, Mar 10, 2014 at 11:30 AM, Kapil Shardha <Kapil.Shardha@simulationiq.com (mailto:Kapil.Shardha@simulationiq.com)> wrote:

Perhaps, using “node_name” setting in the client.rb file would fix this issue. I ran into similar issue and was able to fix it by setting this value to the FQDN name of the node.

-Kapil

From: Kenneth Barry [mailto:kbarry-x@tunein.com]
Sent: Monday, March 10, 2014 2:22 PM
To: chef@lists.opscode.com (mailto:chef@lists.opscode.com)
Subject: [chef] node name coming across wrong.

I am bootstrapping a linux node: “knife bootstrap servername01.domain.org (http://servername01.domain.org) -x root -P [password]” knife node list afterwords shows “servername01”, Not the expected “servername01.domain.org (http://servername01.domain.org)” (FYI, this was bootstrapped before, i did a “knife node delete” and “knife client delete”) Also, i had to give the parameter --no-host-key-verify in the bootstrap bease of an error i was getting. Things “seem” to work just fine until i try to re-run chef-client a second time after bootstrapping.

Other boxed we have bootstrapped have gotten the name we expect. I am guessing that maybe there is something that mixxing things up because the hef server considers this as a “known host” even after the “knife node delete” process…

Any pointers.

This email and any accompanying documents may contain privileged or otherwise confidential information of, and/or is the property of Education Management Solutions, Inc. If you are not the intended recipient, please immediately advise the sender by reply email & delete the message & any attachments without using, copying or disclosing the contents. Thank you.


#6

oooooh, an FQDN cookbook. Interesing. Will take a look.

On Thu, Mar 13, 2014 at 4:26 AM, Kadel-Garcia, Nico <
NKadelGarcia-consultant@scholastic.com> wrote:

Also note that a lot of system deployment tools have horrible ideas
about how to do /etc/hosts, /etc/sysconfig/network or /etc/hostname, and
DNS hostnaming. I’d strongly encourage you to use the “fqdn” cookbook to
standardize what winds up in /etc/hosts.


Nico Kadel-Garcia
Senior Systems Consultant
Email: nkadelgarcia-consultant@scholastic.com
Cell Phone: +1.339.368.2428


From: Daniel DeLeo ddeleo@kallistec.com on behalf of Daniel DeLeo <
dan@kallistec.com>
Sent: Tuesday, March 11, 2014 12:53 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: RE: node name coming across wrong.

When you don’t specify the node name, chef tries to determine the name
from ohai data. Ohai’s fqdn attribute is pulled from hostname --fqdn,
which can be blank if either your reverse DNS or /etc/hosts don’t specify
it. Probably something is different about this particular machine’s
configuration compared to the others which is causing this issue.


Daniel DeLeo

On Monday, March 10, 2014 at 11:35 AM, Kenneth Barry wrote:

That sounds like it would work.

Any ideas on why the node name is the short name, isntead of the FQDN?

I guess i could ass "-N [FQDN], but i thought was assumed in the use of
the FQDN in the bootstrapping

On Mon, Mar 10, 2014 at 11:30 AM, Kapil Shardha <
Kapil.Shardha@simulationiq.com (mailto:Kapil.Shardha@simulationiq.com)>
wrote:

Perhaps, using “node_name” setting in the client.rb file would fix
this issue. I ran into similar issue and was able to fix it by setting this
value to the FQDN name of the node.

-Kapil

From: Kenneth Barry [mailto:kbarry-x@tunein.com]
Sent: Monday, March 10, 2014 2:22 PM
To: chef@lists.opscode.com (mailto:chef@lists.opscode.com)
Subject: [chef] node name coming across wrong.

I am bootstrapping a linux node: “knife bootstrap
servername01.domain.org (http://servername01.domain.org) -x root -P
[password]” knife node list afterwords shows “servername01”, Not the
expected “servername01.domain.org (http://servername01.domain.org)” (FYI,
this was bootstrapped before, i did a “knife node delete” and “knife client
delete”) Also, i had to give the parameter --no-host-key-verify in the
bootstrap bease of an error i was getting. Things “seem” to work just fine
until i try to re-run chef-client a second time after bootstrapping.

Other boxed we have bootstrapped have gotten the name we expect. I am
guessing that maybe there is something that mixxing things up because the
hef server considers this as a “known host” even after the “knife node
delete” process…

Any pointers.

This email and any accompanying documents may contain privileged or
otherwise confidential information of, and/or is the property of Education
Management Solutions, Inc. If you are not the intended recipient, please
immediately advise the sender by reply email & delete the message & any
attachments without using, copying or disclosing the contents. Thank you.


#7

Good. The fqdn cookbook is limited. I’ve published some patches for it at https://github.com/nkadelgarcia-consultant/fqdn-cookbook, but haven’t heard back from the author about the pull request I submitted.


Nico Kadel-Garcia
Senior Systems Consultant
Email: nkadelgarcia-consultant@scholastic.com
Cell Phone: +1.339.368.2428


From: Kenneth Barry kbarry-x@tunein.com
Sent: Thursday, March 13, 2014 11:00 AM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: Re: Re: RE: node name coming across wrong.

oooooh, an FQDN cookbook. Interesing. Will take a look.

On Thu, Mar 13, 2014 at 4:26 AM, Kadel-Garcia, Nico <NKadelGarcia-consultant@scholastic.commailto:NKadelGarcia-consultant@scholastic.com> wrote:
Also note that a lot of system deployment tools have horrible ideas about how to do /etc/hosts, /etc/sysconfig/network or /etc/hostname, and DNS hostnaming. I’d strongly encourage you to use the “fqdn” cookbook to standardize what winds up in /etc/hosts.


Nico Kadel-Garcia
Senior Systems Consultant
Email: nkadelgarcia-consultant@scholastic.commailto:nkadelgarcia-consultant@scholastic.com
Cell Phone: +1.339.368.2428


From: Daniel DeLeo <ddeleo@kallistec.commailto:ddeleo@kallistec.com> on behalf of Daniel DeLeo <dan@kallistec.commailto:dan@kallistec.com>
Sent: Tuesday, March 11, 2014 12:53 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] Re: Re: RE: node name coming across wrong.

When you don’t specify the node name, chef tries to determine the name from ohai data. Ohai’s fqdn attribute is pulled from hostname -fqdn, which can be blank if either your reverse DNS or /etc/hosts don’t specify it. Probably something is different about this particular machine’s configuration compared to the others which is causing this issue.


Daniel DeLeo

On Monday, March 10, 2014 at 11:35 AM, Kenneth Barry wrote:

That sounds like it would work.

Any ideas on why the node name is the short name, isntead of the FQDN?

I guess i could ass "-N [FQDN], but i thought was assumed in the use of the FQDN in the bootstrapping

On Mon, Mar 10, 2014 at 11:30 AM, Kapil Shardha <Kapil.Shardha@simulationiq.commailto:Kapil.Shardha@simulationiq.com (mailto:Kapil.Shardha@simulationiq.commailto:Kapil.Shardha@simulationiq.com)> wrote:

Perhaps, using “node_name” setting in the client.rb file would fix this issue. I ran into similar issue and was able to fix it by setting this value to the FQDN name of the node.

-Kapil

From: Kenneth Barry [mailto:kbarry-x@tunein.commailto:kbarry-x@tunein.com]
Sent: Monday, March 10, 2014 2:22 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com (mailto:chef@lists.opscode.commailto:chef@lists.opscode.com)
Subject: [chef] node name coming across wrong.

I am bootstrapping a linux node: “knife bootstrap servername01.domain.orghttp://servername01.domain.org/ (http://servername01.domain.orghttp://servername01.domain.org/) -x root -P [password]” knife node list afterwords shows “servername01”, Not the expected “servername01.domain.orghttp://servername01.domain.org/ (http://servername01.domain.orghttp://servername01.domain.org/)” (FYI, this was bootstrapped before, i did a “knife node delete” and “knife client delete”) Also, i had to give the parameter --no-host-key-verify in the bootstrap bease of an error i was getting. Things “seem” to work just fine until i try to re-run chef-client a second time after bootstrapping.

Other boxed we have bootstrapped have gotten the name we expect. I am guessing that maybe there is something that mixxing things up because the hef server considers this as a “known host” even after the “knife node delete” process…

Any pointers.

This email and any accompanying documents may contain privileged or otherwise confidential information of, and/or is the property of Education Management Solutions, Inc. If you are not the intended recipient, please immediately advise the sender by reply email & delete the message & any attachments without using, copying or disclosing the contents. Thank you.