FQDN originates from the hostname in some way. If the hostname is being set
on the first chef run through a recipe, it appears you have to run chef-client
twice to get the FQDN into the chef server. sound right?
The first run of chef-client will pick up the original (and wrong) fqdn, and
input that into chef server.
The second chef-client run will get the new, and correct, fqdn.
check out the fqdn cookbook to set this on linux
On Tue, Jun 11, 2013 at 8:39 AM, Sam Darwin samuel.d.darwin@gmail.comwrote:
FQDN originates from the hostname in some way. If the hostname is being
set
on the first chef run through a recipe, it appears you have to run
chef-client
twice to get the FQDN into the chef server. sound right?The first run of chef-client will pick up the original (and wrong) fqdn,
and
input that into chef server.The second chef-client run will get the new, and correct, fqdn.
Hi Sean,
I just tried out the fqdn cookbook. It appears to not solve the
problem I was mentioning which is that two runs of chef-client are
required. that is still the case. I would like the fqdn to be
correct in the chef server so that nagios can use it. the first run
of the fqdn recipe will fix the name on the client itself, but not on
the chef server, and so a second run of chef-client is required.
this is relevant because we are commonly bootstrapping new clients
with "knife ec2 server create" and "knife bootstrap" , and these
usually run chef-client a single time, not twice, and then nagios
picks up the new server name. But nagios is not getting the right
fqdn , even with the fqdn recipe being part of the bootstrap.
On Tue, Jun 11, 2013 at 4:01 PM, Sean OMeara someara@gmail.com wrote:
check out the fqdn cookbook to set this on linux
On Tue, Jun 11, 2013 at 8:39 AM, Sam Darwin samuel.d.darwin@gmail.com
wrote:FQDN originates from the hostname in some way. If the hostname is being
set
on the first chef run through a recipe, it appears you have to run
chef-client
twice to get the FQDN into the chef server. sound right?The first run of chef-client will pick up the original (and wrong) fqdn,
and
input that into chef server.The second chef-client run will get the new, and correct, fqdn.
Are you using the "-N" option with your knife bootstrap command? That sets the node name in the Chef server. I image something like this would work:
knife bootstrap mynode -N mynode.mydomain.com
-----Original Message-----
From: Sam Darwin [mailto:samuel.d.darwin@gmail.com]
Sent: Wednesday, June 12, 2013 08:55
To: Sean OMeara
Cc: chef@lists.opscode.com
Subject: [chef] Re: Re: setting the fqdn
Hi Sean,
I just tried out the fqdn cookbook. It appears to not solve the
problem I was mentioning which is that two runs of chef-client are
required. that is still the case. I would like the fqdn to be
correct in the chef server so that nagios can use it. the first run
of the fqdn recipe will fix the name on the client itself, but not on the chef server, and so a second run of chef-client is required.
this is relevant because we are commonly bootstrapping new clients with "knife ec2 server create" and "knife bootstrap" , and these usually run chef-client a single time, not twice, and then nagios
picks up the new server name. But nagios is not getting the right
fqdn , even with the fqdn recipe being part of the bootstrap.
On Tue, Jun 11, 2013 at 4:01 PM, Sean OMeara someara@gmail.com wrote:
check out the fqdn cookbook to set this on linux
On Tue, Jun 11, 2013 at 8:39 AM, Sam Darwin
samuel.d.darwin@gmail.com
wrote:FQDN originates from the hostname in some way. If the hostname is being
set
on the first chef run through a recipe, it appears you have to run
chef-client
twice to get the FQDN into the chef server. sound right?The first run of chef-client will pick up the original (and wrong)
fqdn, and input that into chef server.The second chef-client run will get the new, and correct, fqdn.
Are you bootstapping with -N
knife bootstrap 1.2.3.4 -r 'recipe[superserver]' -N node123.example.com
-s
On Wed, Jun 12, 2013 at 11:54 AM, Sam Darwin samuel.d.darwin@gmail.comwrote:
Hi Sean,
I just tried out the fqdn cookbook. It appears to not solve the
problem I was mentioning which is that two runs of chef-client are
required. that is still the case. I would like the fqdn to be
correct in the chef server so that nagios can use it. the first run
of the fqdn recipe will fix the name on the client itself, but not on
the chef server, and so a second run of chef-client is required.
this is relevant because we are commonly bootstrapping new clients
with "knife ec2 server create" and "knife bootstrap" , and these
usually run chef-client a single time, not twice, and then nagios
picks up the new server name. But nagios is not getting the right
fqdn , even with the fqdn recipe being part of the bootstrap.On Tue, Jun 11, 2013 at 4:01 PM, Sean OMeara someara@gmail.com wrote:
check out the fqdn cookbook to set this on linux
On Tue, Jun 11, 2013 at 8:39 AM, Sam Darwin samuel.d.darwin@gmail.com
wrote:FQDN originates from the hostname in some way. If the hostname is
being
set
on the first chef run through a recipe, it appears you have to run
chef-client
twice to get the FQDN into the chef server. sound right?The first run of chef-client will pick up the original (and wrong) fqdn,
and
input that into chef server.The second chef-client run will get the new, and correct, fqdn.
create a new EC2 instance manually: ip-10-60-6-141.ec2.internal
then run this command:
knife bootstrap 10-60-6-141 -r 'recipe[fqdn]' -N node123.example.com
looking on the node itself, everything is correct. the name is now
node123.example.com
looking on chef-server, the fqdn of the new instance is
ip-10-60-6-141.ec2.internal , which is what it saw when it first
connected to this new machine.
On Wed, Jun 12, 2013 at 7:00 PM, Sean OMeara someara@gmail.com wrote:
Are you bootstapping with -N
knife bootstrap 1.2.3.4 -r 'recipe[superserver]' -N node123.example.com
-s
On Wed, Jun 12, 2013 at 11:54 AM, Sam Darwin samuel.d.darwin@gmail.com
wrote:Hi Sean,
I just tried out the fqdn cookbook. It appears to not solve the
problem I was mentioning which is that two runs of chef-client are
required. that is still the case. I would like the fqdn to be
correct in the chef server so that nagios can use it. the first run
of the fqdn recipe will fix the name on the client itself, but not on
the chef server, and so a second run of chef-client is required.
this is relevant because we are commonly bootstrapping new clients
with "knife ec2 server create" and "knife bootstrap" , and these
usually run chef-client a single time, not twice, and then nagios
picks up the new server name. But nagios is not getting the right
fqdn , even with the fqdn recipe being part of the bootstrap.On Tue, Jun 11, 2013 at 4:01 PM, Sean OMeara someara@gmail.com wrote:
check out the fqdn cookbook to set this on linux
On Tue, Jun 11, 2013 at 8:39 AM, Sam Darwin samuel.d.darwin@gmail.com
wrote:FQDN originates from the hostname in some way. If the hostname is
being
set
on the first chef run through a recipe, it appears you have to run
chef-client
twice to get the FQDN into the chef server. sound right?The first run of chef-client will pick up the original (and wrong)
fqdn,
and
input that into chef server.The second chef-client run will get the new, and correct, fqdn.
Sam, I have the same issue, pending to investigate.
2013/6/13 Sam Darwin samuel.d.darwin@gmail.com
create a new EC2 instance manually: ip-10-60-6-141.ec2.internal
then run this command:
knife bootstrap 10-60-6-141 -r 'recipe[fqdn]' -N node123.example.com
looking on the node itself, everything is correct. the name is now
node123.example.comlooking on chef-server, the fqdn of the new instance is
ip-10-60-6-141.ec2.internal , which is what it saw when it first
connected to this new machine.On Wed, Jun 12, 2013 at 7:00 PM, Sean OMeara someara@gmail.com wrote:
Are you bootstapping with -N
knife bootstrap 1.2.3.4 -r 'recipe[superserver]' -N node123.example.com
-s
On Wed, Jun 12, 2013 at 11:54 AM, Sam Darwin samuel.d.darwin@gmail.com
wrote:Hi Sean,
I just tried out the fqdn cookbook. It appears to not solve the
problem I was mentioning which is that two runs of chef-client are
required. that is still the case. I would like the fqdn to be
correct in the chef server so that nagios can use it. the first run
of the fqdn recipe will fix the name on the client itself, but not on
the chef server, and so a second run of chef-client is required.
this is relevant because we are commonly bootstrapping new clients
with "knife ec2 server create" and "knife bootstrap" , and these
usually run chef-client a single time, not twice, and then nagios
picks up the new server name. But nagios is not getting the right
fqdn , even with the fqdn recipe being part of the bootstrap.On Tue, Jun 11, 2013 at 4:01 PM, Sean OMeara someara@gmail.com wrote:
check out the fqdn cookbook to set this on linux
On Tue, Jun 11, 2013 at 8:39 AM, Sam Darwin <
samuel.d.darwin@gmail.com>
wrote:FQDN originates from the hostname in some way. If the hostname is
being
set
on the first chef run through a recipe, it appears you have to run
chef-client
twice to get the FQDN into the chef server. sound right?The first run of chef-client will pick up the original (and wrong)
fqdn,
and
input that into chef server.The second chef-client run will get the new, and correct, fqdn.
++1
Earlier i tried but had few issues then moved with the defaults.
Anybody any solns?
On Wednesday, June 12, 2013, Jordi Llonch wrote:
Sam, I have the same issue, pending to investigate.
2013/6/13 Sam Darwin <samuel.d.darwin@gmail.com <javascript:_e({},
'cvml', 'samuel.d.darwin@gmail.com');>>create a new EC2 instance manually: ip-10-60-6-141.ec2.internal
then run this command:
knife bootstrap 10-60-6-141 -r 'recipe[fqdn]' -N node123.example.com
looking on the node itself, everything is correct. the name is now
node123.example.comlooking on chef-server, the fqdn of the new instance is
ip-10-60-6-141.ec2.internal , which is what it saw when it first
connected to this new machine.On Wed, Jun 12, 2013 at 7:00 PM, Sean OMeara <someara@gmail.com<javascript:_e({}, 'cvml', 'someara@gmail.com');>>
wrote:Are you bootstapping with -N
knife bootstrap 1.2.3.4 -r 'recipe[superserver]' -N node123.example.com
-s
On Wed, Jun 12, 2013 at 11:54 AM, Sam Darwin <samuel.d.darwin@gmail.com<javascript:_e({}, 'cvml', 'samuel.d.darwin@gmail.com');>
wrote:
Hi Sean,
I just tried out the fqdn cookbook. It appears to not solve the
problem I was mentioning which is that two runs of chef-client are
required. that is still the case. I would like the fqdn to be
correct in the chef server so that nagios can use it. the first run
of the fqdn recipe will fix the name on the client itself, but not on
the chef server, and so a second run of chef-client is required.
this is relevant because we are commonly bootstrapping new clients
with "knife ec2 server create" and "knife bootstrap" , and these
usually run chef-client a single time, not twice, and then nagios
picks up the new server name. But nagios is not getting the right
fqdn , even with the fqdn recipe being part of the bootstrap.On Tue, Jun 11, 2013 at 4:01 PM, Sean OMeara <someara@gmail.com<javascript:_e({}, 'cvml', 'someara@gmail.com');>>
wrote:check out the fqdn cookbook to set this on linux
On Tue, Jun 11, 2013 at 8:39 AM, Sam Darwin <
samuel.d.darwin@gmail.com <javascript:_e({}, 'cvml',
'samuel.d.darwin@gmail.com');>>
wrote:FQDN originates from the hostname in some way. If the hostname is
being
set
on the first chef run through a recipe, it appears you have to run
chef-client
twice to get the FQDN into the chef server. sound right?The first run of chef-client will pick up the original (and wrong)
fqdn,
and
input that into chef server.The second chef-client run will get the new, and correct, fqdn.
--
@millisami
~Sachin Sagar Rai
Ruby on Rails Developer
http://tfm.com.np
http://nepalonrails.com
the fqdn that gets sent to chef comes from an ohai call that happens before
the chef run, so despite the fqdn getting changed by the fqdn recipe,
node['fqdn'] doesn't get changed until the next run.
sean, can that value be overridden in a recipe, or does it stay with the
ohai value? ohai iirc has the highest precedence...
-jesse
On Wed, Jun 12, 2013 at 2:57 PM, millisami r millisami@gmail.com wrote:
++1
Earlier i tried but had few issues then moved with the defaults.
Anybody any solns?On Wednesday, June 12, 2013, Jordi Llonch wrote:
Sam, I have the same issue, pending to investigate.
2013/6/13 Sam Darwin samuel.d.darwin@gmail.com
create a new EC2 instance manually: ip-10-60-6-141.ec2.internal
then run this command:
knife bootstrap 10-60-6-141 -r 'recipe[fqdn]' -N node123.example.com
looking on the node itself, everything is correct. the name is now
node123.example.comlooking on chef-server, the fqdn of the new instance is
ip-10-60-6-141.ec2.internal , which is what it saw when it first
connected to this new machine.On Wed, Jun 12, 2013 at 7:00 PM, Sean OMeara someara@gmail.com wrote:
Are you bootstapping with -N
knife bootstrap 1.2.3.4 -r 'recipe[superserver]' -N
node123.example.com-s
On Wed, Jun 12, 2013 at 11:54 AM, Sam Darwin <
samuel.d.darwin@gmail.com>
wrote:Hi Sean,
I just tried out the fqdn cookbook. It appears to not solve the
problem I was mentioning which is that two runs of chef-client are
required. that is still the case. I would like the fqdn to be
correct in the chef server so that nagios can use it. the first run
of the fqdn recipe will fix the name on the client itself, but not on
the chef server, and so a second run of chef-client is required.
this is relevant because we are commonly bootstrapping new clients
with "knife ec2 server create" and "knife bootstrap" , and these
usually run chef-client a single time, not twice, and then nagios
picks up the new server name. But nagios is not getting the right
fqdn , even with the fqdn recipe being part of the bootstrap.On Tue, Jun 11, 2013 at 4:01 PM, Sean OMeara someara@gmail.com
wrote:check out the fqdn cookbook to set this on linux
On Tue, Jun 11, 2013 at 8:39 AM, Sam Darwin <
samuel.d.darwin@gmail.com>
wrote:FQDN originates from the hostname in some way. If the hostname is
being
set
on the first chef run through a recipe, it appears you have to run
chef-client
twice to get the FQDN into the chef server. sound right?The first run of chef-client will pick up the original (and wrong)
fqdn,
and
input that into chef server.The second chef-client run will get the new, and correct, fqdn.
--
@millisami
~Sachin Sagar Rai
Ruby on Rails Developer
http://tfm.com.np
http://nepalonrails.com
Yea, that's what this line is supposed to take care of:
https://github.com/someara/fqdn-cookbook/blob/master/recipes/rhel.rb#L79
I guess I'll have to figure out why it's busted
-s
On Wed, Jun 12, 2013 at 5:58 PM, Jesse Campbell hikeit@gmail.com wrote:
the fqdn that gets sent to chef comes from an ohai call that happens
before the chef run, so despite the fqdn getting changed by the fqdn
recipe, node['fqdn'] doesn't get changed until the next run.sean, can that value be overridden in a recipe, or does it stay with the
ohai value? ohai iirc has the highest precedence...-jesse
On Wed, Jun 12, 2013 at 2:57 PM, millisami r millisami@gmail.com wrote:
++1
Earlier i tried but had few issues then moved with the defaults.
Anybody any solns?On Wednesday, June 12, 2013, Jordi Llonch wrote:
Sam, I have the same issue, pending to investigate.
2013/6/13 Sam Darwin samuel.d.darwin@gmail.com
create a new EC2 instance manually: ip-10-60-6-141.ec2.internal
then run this command:
knife bootstrap 10-60-6-141 -r 'recipe[fqdn]' -N node123.example.com
looking on the node itself, everything is correct. the name is now
node123.example.comlooking on chef-server, the fqdn of the new instance is
ip-10-60-6-141.ec2.internal , which is what it saw when it first
connected to this new machine.On Wed, Jun 12, 2013 at 7:00 PM, Sean OMeara someara@gmail.com wrote:
Are you bootstapping with -N
knife bootstrap 1.2.3.4 -r 'recipe[superserver]' -N
node123.example.com-s
On Wed, Jun 12, 2013 at 11:54 AM, Sam Darwin <
samuel.d.darwin@gmail.com>
wrote:Hi Sean,
I just tried out the fqdn cookbook. It appears to not solve the
problem I was mentioning which is that two runs of chef-client are
required. that is still the case. I would like the fqdn to be
correct in the chef server so that nagios can use it. the first
run
of the fqdn recipe will fix the name on the client itself, but not on
the chef server, and so a second run of chef-client is required.
this is relevant because we are commonly bootstrapping new clients
with "knife ec2 server create" and "knife bootstrap" , and these
usually run chef-client a single time, not twice, and then nagios
picks up the new server name. But nagios is not getting the right
fqdn , even with the fqdn recipe being part of the bootstrap.On Tue, Jun 11, 2013 at 4:01 PM, Sean OMeara someara@gmail.com
wrote:check out the fqdn cookbook to set this on linux
On Tue, Jun 11, 2013 at 8:39 AM, Sam Darwin <
samuel.d.darwin@gmail.com>
wrote:FQDN originates from the hostname in some way. If the hostname
is
being
set
on the first chef run through a recipe, it appears you have to run
chef-client
twice to get the FQDN into the chef server. sound right?The first run of chef-client will pick up the original (and wrong)
fqdn,
and
input that into chef server.The second chef-client run will get the new, and correct, fqdn.
--
@millisami
~Sachin Sagar Rai
Ruby on Rails Developer
http://tfm.com.np
http://nepalonrails.com
Shameless Plug: there's also `hostname' cookbook, which is a bit less
sophisticated (and is tested only with Debian derivatives), but fits into a
bit different setup: node name is not FQDN, and FQDN to set is taken from
an attribute. The attribute itself I usually set in a "base" cookbook,
based on node's name and a predefined domain - I'll probably update the
cookbook soon to do it automatically.
-- M
On 13 June 2013 00:03, Sean OMeara someara@gmail.com wrote:
Yea, that's what this line is supposed to take care of:
https://github.com/someara/fqdn-cookbook/blob/master/recipes/rhel.rb#L79
I guess I'll have to figure out why it's busted
-s
On Wed, Jun 12, 2013 at 5:58 PM, Jesse Campbell hikeit@gmail.com wrote:
the fqdn that gets sent to chef comes from an ohai call that happens
before the chef run, so despite the fqdn getting changed by the fqdn
recipe, node['fqdn'] doesn't get changed until the next run.sean, can that value be overridden in a recipe, or does it stay with the
ohai value? ohai iirc has the highest precedence...-jesse
On Wed, Jun 12, 2013 at 2:57 PM, millisami r millisami@gmail.com wrote:
++1
Earlier i tried but had few issues then moved with the defaults.
Anybody any solns?On Wednesday, June 12, 2013, Jordi Llonch wrote:
Sam, I have the same issue, pending to investigate.
2013/6/13 Sam Darwin samuel.d.darwin@gmail.com
create a new EC2 instance manually: ip-10-60-6-141.ec2.internal
then run this command:
knife bootstrap 10-60-6-141 -r 'recipe[fqdn]' -N node123.example.com
looking on the node itself, everything is correct. the name is now
node123.example.comlooking on chef-server, the fqdn of the new instance is
ip-10-60-6-141.ec2.internal , which is what it saw when it first
connected to this new machine.On Wed, Jun 12, 2013 at 7:00 PM, Sean OMeara someara@gmail.com
wrote:Are you bootstapping with -N
knife bootstrap 1.2.3.4 -r 'recipe[superserver]' -N
node123.example.com-s
On Wed, Jun 12, 2013 at 11:54 AM, Sam Darwin <
samuel.d.darwin@gmail.com>
wrote:Hi Sean,
I just tried out the fqdn cookbook. It appears to not solve the
problem I was mentioning which is that two runs of chef-client are
required. that is still the case. I would like the fqdn to be
correct in the chef server so that nagios can use it. the first
run
of the fqdn recipe will fix the name on the client itself, but not
on
the chef server, and so a second run of chef-client is required.
this is relevant because we are commonly bootstrapping new clients
with "knife ec2 server create" and "knife bootstrap" , and these
usually run chef-client a single time, not twice, and then nagios
picks up the new server name. But nagios is not getting the right
fqdn , even with the fqdn recipe being part of the bootstrap.On Tue, Jun 11, 2013 at 4:01 PM, Sean OMeara someara@gmail.com
wrote:check out the fqdn cookbook to set this on linux
On Tue, Jun 11, 2013 at 8:39 AM, Sam Darwin <
samuel.d.darwin@gmail.com>
wrote:FQDN originates from the hostname in some way. If the hostname
is
being
set
on the first chef run through a recipe, it appears you have to
run
chef-client
twice to get the FQDN into the chef server. sound right?The first run of chef-client will pick up the original (and
wrong)
fqdn,
and
input that into chef server.The second chef-client run will get the new, and correct, fqdn.
--
@millisami
~Sachin Sagar Rai
Ruby on Rails Developer
http://tfm.com.np
http://nepalonrails.com