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.