Inconsistent value of node['fqdn']

[fletchowns]

Created a chef repo to reproduce the issue here: https://github.com/fletchowns/hostname-playground. Just cd into the cookbooks/mycorp-chef-server directory and do a vagrant up.

Attributes & run list is defined in the Vagrantfile:

    chef.json = {
      "system" => {
        "short_hostname" => "chef",
        "domain_name" => "mycorp.com"
      }
    }

    chef.add_recipe "system"
    chef.add_recipe "mycorp-chef-server"
    chef.add_recipe "chef-server"

The default recipe for mycorp-chef-server is very simple, and leverages the certificate_manage LWRP from the certificate cookbook:

certificate_manage "wildcard" do
    nginx_cert true
end

node.override["chef-server"]["configuration"]["nginx"]["ssl_certificate"] = "/etc/pki/tls/certs/#{node['fqdn']}.pem"
node.override["chef-server"]["configuration"]["nginx"]["ssl_certificate_key"] = "/etc/pki/tls/private/#{node['fqdn']}.key"

template "/template_test" do
    source "dummy_template.erb"
    mode 0644
    action :create_if_missing
    variables({
        :fqdn => node['fqdn']
    })
end

The dummy_template.erb is meant to see if there is a difference between passing attributes in vs. referencing them in the template itself:

Is <%= @fqdn %> the same as <%= node['fqdn'] %> ?

After running vagrant up I'm seeing the following:

[root@chef ~]# hostname -f
chef.mycorp.com
[root@chef ~]# hostname -a
chef

[root@chef ~]# cat /template_test
Is chef the same as chef.mycorp.com ?

[root@chef ~]# ls -la /etc/pki/tls/certs/
total 1220
drwxr-xr-x. 2 root root   4096 Jan 23 00:14 .
drwxr-xr-x. 5 root root   4096 Mar  7  2014 ..
-rw-r--r--. 1 root root 244954 Jan 29  2014 ca-bundle.crt
-rw-r--r--. 1 root root 978662 Sep  3  2013 ca-bundle.trust.crt
-rw-r--r--. 1 root root   1710 Jan 23 00:14 chef.pem
-rwxr-xr-x. 1 root root    610 Nov 22  2013 make-dummy-cert
-rw-r--r--. 1 root root   2242 Nov 22  2013 Makefile
-rwxr-xr-x. 1 root root    829 Nov 22  2013 renew-dummy-cert

[root@chef ~]# grep ssl_certificate /var/opt/chef-server/nginx/etc/chef_https_lb.conf
  ssl_certificate /etc/pki/tls/certs/chef.pem;
  ssl_certificate_key /etc/pki/tls/private/chef.key;

It seems to think that the fqdn is just 'chef', but not always (as seen in template_test). Shouldn't the fqdn be chef.mycorp.com throughout all of this?

Now after you do a subsequent vagrant provision on this box, I see the following:

[root@chef ~]# hostname -f
chef.mycorp.com
[root@chef ~]# hostname -a
chef

[root@chef ~]# cat /template_test
Is chef the same as chef.mycorp.com ?

[root@chef ~]# ls -la /etc/pki/tls/certs/
total 1224
drwxr-xr-x. 2 root root   4096 Jan 23 00:38 .
drwxr-xr-x. 5 root root   4096 Mar  7  2014 ..
-rw-r--r--. 1 root root 244954 Jan 29  2014 ca-bundle.crt
-rw-r--r--. 1 root root 978662 Sep  3  2013 ca-bundle.trust.crt
-rw-r--r--. 1 root root   1710 Jan 23 00:38 chef.mycorp.com.pem
-rw-r--r--. 1 root root   1710 Jan 23 00:14 chef.pem
-rwxr-xr-x. 1 root root    610 Nov 22  2013 make-dummy-cert
-rw-r--r--. 1 root root   2242 Nov 22  2013 Makefile
-rwxr-xr-x. 1 root root    829 Nov 22  2013 renew-dummy-cert

[root@chef ~]# grep ssl_certificate /var/opt/chef-server/nginx/etc/chef_https_lb.conf
  ssl_certificate /etc/pki/tls/certs/chef.mycorp.com.pem;
  ssl_certificate_key /etc/pki/tls/private/chef.mycorp.com.key;

So initial converge created the file chef.pem but the second converge created chef.mycorp.com.pem. But strangely enough, the template_test contents did not change. Any idea what to make of all this?

[fletchowns]

Here's what happens when I do the same thing but with on EC2 with vagrant up --provider aws:

[root@chef ~]# hostname -f
chef.mycorp.com
[root@chef ~]# hostname -a
chef

[root@chef ~]# cat /template_test
Is  the same as chef.mycorp.com ?

[root@chef ~]# ls -la /etc/pki/tls/certs/
total 1720
drwxr-xr-x. 2 root root   4096 Jan 23 21:21 .
drwxr-xr-x. 5 root root   4096 Jun  9  2014 ..
-rw-r--r--. 1 root root 757191 Dec 17  2013 ca-bundle.crt
-rw-r--r--. 1 root root 978662 Dec 17  2013 ca-bundle.trust.crt
-rwxr-xr-x. 1 root root    610 Jun  2  2014 make-dummy-cert
-rw-r--r--. 1 root root   2242 Jun  2  2014 Makefile
-rw-r--r--. 1 root root   1710 Jan 23 21:21 .pem
-rwxr-xr-x. 1 root root    829 Jun  2  2014 renew-dummy-cert

[root@chef ~]# grep ssl_certificate /var/opt/chef-server/nginx/etc/chef_https_lb.conf
  ssl_certificate /etc/pki/tls/certs/.pem;
  ssl_certificate_key /etc/pki/tls/private/.key;

AWS provider branch is available here: https://github.com/fletchowns/hostname-playground/tree/system-aws
Full debug level output of that chef run is available here: https://gist.github.com/fletchowns/6386bf248c6aa2b53690

[fletchowns]

@flaccid any thoughts on this one?

[flaccid]

The reason it seems inconsistent is because your Vagrantfile is setting the vm.hostname to the same short hostname you are setting with Chef.
system cookbook will currently support using node['fqdn'] within templates, but when being used with the variables attribute in resources, you'll need to lazy load. I've added documentation on how to do that here https://github.com/xhost-cookbooks/system#recipes (all downstream cookbooks will need to ensure lazy to support a hostname change).

[fletchowns]

Running into some trouble with the latest changes. The template_test looks good now though (when using lazy attribute evaluation). I also removed setting the hostname in the Vagrantfile for this test.

$ vagrant ssh
Last login: Fri Mar  7 16:57:20 2014 from 10.0.2.2
[vagrant@chef ~]$ hostname -f
hostname: Unknown host
[vagrant@chef ~]$ hostname -a
hostname: Unknown host
[vagrant@chef ~]$ cat /template_test
Is chef.mycorp.com the same as chef.mycorp.com ?
[vagrant@chef ~]$ cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
[vagrant@chef ~]$ cat /etc/hostname
chef.mycorp.com

I created a new branch for this test run: https://github.com/fletchowns/hostname-playground/tree/system-cookbook-rework

Here's a gist of the chef run: https://gist.github.com/fletchowns/44ea27c126720f23b479

[flaccid]

In this case, version 0.4.0 of the cookbook does not place a host in /etc/hosts on non Debian systems so a lookup from nsswitch does not resolve the hostname by files nor dns and thus returns unknown host (it would be ok if it was in dns/qualified).
I'll change the behaviour in 0.5.0 so that when not using permanent_ip an entry for the hostname against 127.0.0.1/localhost is placed in /etc/hosts.

[flaccid]

0.5.0 released (https://github.com/xhost-cookbooks/system/releases/tag/v0.5.0).