RE: fqdn and Chef Server

Chef Infra (archive)
1

Probably, but it may not be trivial. I found that some parts of the chef API use redirects that include the fqdn.

Kevin Keane

The NetTech

http://www.4nettech.com http://www.4nettech.com

Our values:Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html

-----Original message-----

From:David Gil <dgilo@aemet.es mailto:dgilo@aemet.es >
Sent: Friday 23rd May 2014 1:33
To: chef@lists.opscode.com mailto:chef@lists.opscode.com
Subject: [chef] fqdn and Chef Server

Hi!

At work we want to setup a Chef server but we don't have DNS servers
that we can touch and so we work with IP addresses. Can the Chef
server work with an IP address instead of a fqdn?

Thanks,

--
David Gil Oliva

2

On Friday, May 23, 2014 at 11:49 PM, Kevin Keane Subscription wrote:

RE: [chef] fqdn and Chef Server Probably, but it may not be trivial. I found that some parts of the chef API use redirects that include the fqdn.

Kevin Keane

This should work fine if you set up the correct values in the chef server config and then run chef-server-ctl reconfigure. You should also double check that your self-signed cert is regenerated with the correct value in the CN field so that you can enable peer verification on clients.

--
Daniel DeLeo

3

I’m afraid that the latest fqdn cookbook is bombing out on my CentOS 6 test environment as follows, so I really can’t recommend it until this sort of problemis resolved.

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

Starting Chef Client, version 11.12.4
resolving cookbooks for run list: [“fqdn”]
Synchronizing Cookbooks:

  • now
  • hostsfile
  • line
  • fqdn
    Compiling Cookbooks…

================================================================================
Recipe Compile Error in /var/cache/chef/cookbooks/fqdn/recipes/default.rb

ArgumentError

node[‘machine_fqdn’] must be set

Cookbook Trace:

/var/cache/chef/cookbooks/fqdn/libraries/machine_fqdn.rb:17:in sanity_check' /var/cache/chef/cookbooks/fqdn/libraries/machine_fqdn.rb:10:ininitialize’
/var/cache/chef/cookbooks/fqdn/recipes/_rhel.rb:21:in new' /var/cache/chef/cookbooks/fqdn/recipes/_rhel.rb:21:infrom_file’
/var/cache/chef/cookbooks/now/libraries/default.rb:23:in include_recipe_now' /var/cache/chef/cookbooks/fqdn/recipes/default.rb:27:infrom_file’

Relevant File Content:

/var/cache/chef/cookbooks/fqdn/libraries/machine_fqdn.rb:

10: sanity_check node
11: set_attributes node
12: end
13:
14: private
15:
16: def sanity_check(node)
17>> fail ArgumentError, “node[‘machine_fqdn’] must be set” if node[‘machine_fqdn’].nil?
18: dots = node[‘machine_fqdn’].split(’.’).count - 1
19: fail ArgumentError, ‘There must be least one dot in an FQDN’ if dots < 1
20: end
21:
22: def set_attributes(node)
23: @fqdn = node[‘machine_fqdn’]
24: head, *tail = node[‘machine_fqdn’].split(’.’)
25:
26: if node[‘machine_fqdn_as_hostname’]

Running handlers:
Running handlers complete

4

Looks like the cookbook expects you to set the node[‘machine_fqdn] attribute.

--
Daniel DeLeo

On Thursday, May 29, 2014 at 2:02 PM, Kadel-Garcia, Nico wrote:

I'm afraid that the latest fqdn cookbook is bombing out on my CentOS 6 test environment as follows, so I really can't recommend it until this sort of problemis resolved.

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

Starting Chef Client, version 11.12.4
resolving cookbooks for run list: ["fqdn"]
Synchronizing Cookbooks:

  • now
  • hostsfile
  • line
  • fqdn
    Compiling Cookbooks...

================================================================================
Recipe Compile Error in /var/cache/chef/cookbooks/fqdn/recipes/default.rb

ArgumentError

node['machine_fqdn'] must be set

Cookbook Trace:

/var/cache/chef/cookbooks/fqdn/libraries/machine_fqdn.rb:17:in sanity_check' /var/cache/chef/cookbooks/fqdn/libraries/machine_fqdn.rb:10:in initialize'
/var/cache/chef/cookbooks/fqdn/recipes/_rhel.rb:21:in new' /var/cache/chef/cookbooks/fqdn/recipes/_rhel.rb:21:in from_file'
/var/cache/chef/cookbooks/now/libraries/default.rb:23:in include_recipe_now' /var/cache/chef/cookbooks/fqdn/recipes/default.rb:27:in from_file'

Relevant File Content:

/var/cache/chef/cookbooks/fqdn/libraries/machine_fqdn.rb:

10: sanity_check node
11: set_attributes node
12: end
13:
14: private
15:
16: def sanity_check(node)
17>> fail ArgumentError, "node['machine_fqdn'] must be set" if node['machine_fqdn'].nil?
18: dots = node['machine_fqdn'].split('.').count - 1
19: fail ArgumentError, 'There must be least one dot in an FQDN' if dots < 1
20: end
21:
22: def set_attributes(node)
23: @fqdn = node['machine_fqdn']
24: head, *tail = node['machine_fqdn'].split('.')
25:
26: if node['machine_fqdn_as_hostname']

Running handlers:
Running handlers complete

5

It shouldn't, according to the README .md, " If the attribute node['machine_fqdn'] is set, it will use the string found there to attempt to configuration the machine's hostname." It's a new option in the latest production code. It's also a violation of the coding standards where attributes should be associated with their particular cookbook. Ideally, the attribute would be "node['fqdn']['machine_fqdn']".

As it stands, specifying that attribute on a host by host basis is not very practical. It means that each host would need its own role or environment to have the FQDN applied reliably.

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

-----Original Message-----
From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo
Sent: Thursday, May 29, 2014 5:05 PM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: Re: RE: fqdn and Chef Server

Looks like the cookbook expects you to set the node[‘machine_fqdn] attribute.

--
Daniel DeLeo

On Thursday, May 29, 2014 at 2:02 PM, Kadel-Garcia, Nico wrote:

I'm afraid that the latest fqdn cookbook is bombing out on my CentOS 6 test environment as follows, so I really can't recommend it until this sort of problemis resolved.

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

Starting Chef Client, version 11.12.4
resolving cookbooks for run list: ["fqdn"] Synchronizing Cookbooks:

  • now
  • hostsfile
  • line
  • fqdn
    Compiling Cookbooks...

======================================================================
========== Recipe Compile Error in
/var/cache/chef/cookbooks/fqdn/recipes/default.rb

==========

ArgumentError

node['machine_fqdn'] must be set

Cookbook Trace:

/var/cache/chef/cookbooks/fqdn/libraries/machine_fqdn.rb:17:in sanity_check' /var/cache/chef/cookbooks/fqdn/libraries/machine_fqdn.rb:10:in initialize'
/var/cache/chef/cookbooks/fqdn/recipes/_rhel.rb:21:in new' /var/cache/chef/cookbooks/fqdn/recipes/_rhel.rb:21:in from_file'
/var/cache/chef/cookbooks/now/libraries/default.rb:23:in include_recipe_now' /var/cache/chef/cookbooks/fqdn/recipes/default.rb:27:in from_file'

Relevant File Content:

/var/cache/chef/cookbooks/fqdn/libraries/machine_fqdn.rb:

10: sanity_check node
11: set_attributes node
12: end
13:
14: private
15:
16: def sanity_check(node)
17>> fail ArgumentError, "node['machine_fqdn'] must be set" if node['machine_fqdn'].nil?
18: dots = node['machine_fqdn'].split('.').count - 1
19: fail ArgumentError, 'There must be least one dot in an FQDN' if
dots < 1
20: end
21:
22: def set_attributes(node)
23: @fqdn = node['machine_fqdn']
24: head, *tail = node['machine_fqdn'].split('.')
25:
26: if node['machine_fqdn_as_hostname']

Running handlers:
Running handlers complete

6

On Thursday, May 29, 2014 at 2:15 PM, Kadel-Garcia, Nico wrote:

It shouldn't, according to the README .md, " If the attribute node['machine_fqdn'] is set, it will use the string found there to attempt to configuration the machine's hostname." It's a new option in the latest production code. It's also a violation of the coding standards where attributes should be associated with their particular cookbook. Ideally, the attribute would be "node['fqdn']['machine_fqdn']".

node[“fqdn”] is already set to a string value by ohai, so the cookbook can’t use it’s name to namespace the attributes.

As it stands, specifying that attribute on a host by host basis is not very practical. It means that each host would need its own role or environment to have the FQDN applied reliably.

I’m not familiar with the cookbook, but I think the idea is that you write some code to determine the fqdn you want in a recipe, then set this value, e.g.:

cookbook mycorp-fqdn, recipe default.rb

random_tag = node[“host_random_tag”] || rand(1_000_000).to_s(16) # a unique component for your host’s name
node.set[“host_random_tag”] = random_tag # store the tag in node-specific storage so you get the same name next chef run
primary_role = node[“primary_role”] # set this in a role, role cookbook, etc.
subdomain = node.chef_environment # assuming your chef environments map to subdomains

node.override[“machine_fqdn”] = “#{primary_role}-#{random_tag}.#{subdomain}.example.com”

include_recipe “fqdn"

That would give you FQDNs like 'appserver-32f4f.staging.example.com'. Should be easy enough to generalize it for your own naming scheme.

--
Daniel DeLeo

7

From: Daniel DeLeo [mailto:ddeleo@kallistec.com] On Behalf Of Daniel DeLeo
Sent: Thursday, May 29, 2014 5:38 PM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: Re: RE: Re: RE: fqdn and Chef Server

On Thursday, May 29, 2014 at 2:15 PM, Kadel-Garcia, Nico wrote:

It shouldn't, according to the README .md, " If the attribute node['machine_fqdn'] is set, it will use the string found there to attempt to configuration the machine's hostname." It's a new option in the latest production code. It's also a violation of the coding standards where attributes should be associated with their particular cookbook. Ideally, the attribute would be "node['fqdn']['machine_fqdn']".

node[“fqdn”] is already set to a string value by ohai, so the cookbook can’t use it’s name to namespace the attributes.

That's a valid point. It's still not a good reason to set attributes for a specific cookbook without a leading hash element. If necessary, I think the cookbook could be renamed.

As it stands, specifying that attribute on a host by host basis is not very practical. It means that each host would need its own role or environment to have the FQDN applied reliably.

I’m not familiar with the cookbook, but I think the idea is that you write some code to determine the fqdn you want in a recipe, then set this value, e.g.:

The default value of the relevant 'node['machine_name'] attribute created, and tested, inside the library could be set to node['fqdn'] instead of being left 'nil' and the library test simply failing. It's not reasonable for a cookbook's default behavior, with no values manually added to environment or role or containing recipe caller to flat out fail. It should have a more typical default behavior.

cookbook mycorp-fqdn, recipe default.rb

random_tag = node[“host_random_tag”] || rand(1_000_000).to_s(16) # a unique component for your host’s name node.set[“host_random_tag”] = random_tag # store the tag in node-specific storage so you get the same name next chef run primary_role = node[“primary_role”] # set this in a role, role cookbook, etc.
subdomain = node.chef_environment # assuming your chef environments map to subdomains

node.override[“machine_fqdn”] = “#{primary_role}-#{random_tag}.#{subdomain}.example.com”

include_recipe “fqdn"

That would give you FQDNs like 'appserver-32f4f.staging.example.com'. Should be easy enough to generalize it for your own naming scheme.

That's a reasonable approach. Unfortunately, the breakage if node['machine_fqdn'] is not set is a new failure mode associated with the new cookbook, and I don't think it's reasonable. The README.md describes the setting of it to 'nil' as the default, but mentions nothing about that default breaking the cookbook.

The cookbook has been useful up to now for various OS installers that disagree, all of them, about whether and where the FQDN belongs in /etc/hosts. I'm already testing some patches for this: I need to enhance them with the ability not to put the FQDN on the loopback, which is known to break junit for remote access.

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