OS-5985 vmadm man page incorrectly states dns_domain property is associated with /etc/hosts

[joyent-automation]

OS-5985 vmadm man page incorrectly states dns_domain property is associated with /etc/hosts

This PR was migrated-from-gerrit, https://cr.joyent.us/#/c/1576/.
The raw archive of this CR is here.
See MANTA-4594 for info on Joyent Eng's migration from Gerrit.

CR discussion

@bahamat commented at 2017-02-25T20:06:36

Patch Set 1:

New commits:
commit 98a8cff271df8831101b81db9db61413736b008a
OS-5985 vmadm man page incorrectly states dns_domain property is associated with /etc/hosts

@arekinath commented at 2017-02-25T20:13:01

Patch Set 1:

(1 comment)

@bahamat commented at 2017-02-25T23:43:21

Patch Set 1:

(1 comment)

@arekinath commented at 2017-02-27T04:01:58

Patch Set 1:

(1 comment)

vmadm sets this up in the zone config that's passed to zoneinit, which then writes these files on the very first boot (and then deletes itself). Newer zoneinits don't actually use this file, though, instead they get the hostname + dns_domain out of metadata (in 02-config.sh)

As far as I know zoneinit is not checked into source control anywhere, and is handed down from image to image, so it's possible some versions don't do this all the same way.

In the latest and last few base-64 releases this logic is all there and works the way I have explained (hostname + "." + dns_domain becomes the FQDN of the new zone and is written out into /etc/nodename. There's an attempt to use "sed" to update /etc/hosts as well, unclear if that all works the way it's supposed to still)

How did you set this property on the JPC? None of these properties (hostname, dns_domain etc) can be set through cloudapi (they are not passed through at all).

@trentm commented at 2018-06-19T18:15:34

Patch Set 1:

zoneinit is on GitHub at least now.

It looks like at one time zoneinit did set hostname including dns_domain, but no longer:
TritonDataCenter/zoneinit@33c8d8d

There is still the attempt to sed "@domainname@" into files in /etc and /opt/local/etc here: https://github.com/joyent/zoneinit/blob/master/includes/11-files.sh#L13-L24

However on a base-64 image at the time (70e3ae72-96b6-11e6-9056-9737fd4d0764 base-64 16.3.1), there are no hits for that:

[root@headnode (coal) /zones/70e3ae72-96b6-11e6-9056-9737fd4d0764/root/etc]# grep -r DOMAINNAME .
./security/audit_event:59:AUE_SETDOMAINNAME:setdomainname(2):no
[root@headnode (coal) /zones/70e3ae72-96b6-11e6-9056-9737fd4d0764/root/etc]# cd ../opt/local/etc
[root@headnode (coal) /zones/70e3ae72-96b6-11e6-9056-9737fd4d0764/root/opt/local/etc]# grep -r DOMAINNAME .
[root@headnode (coal) /zones/70e3ae72-96b6-11e6-9056-9737fd4d0764/root/opt/local/etc]#

So AFAICT the only usage of <vm>.dns_domain is for setting the search ... line in /etc/resolv.conf, and of course for mdata-get sdc:dns_domain.

@trentm commented at 2018-06-19T18:16:58

Patch Set 1:

(1 comment)

Patch Set 1 code comments

src/vm/man/vmadm.1m.md#953 @arekinath

It also specifies the suffix that will be appended to "hostname" to set the FQDN for the zone at create time. If it's not specified, we append ".local" instead. This should be noted here.

src/vm/man/vmadm.1m.md#953 @bahamat

I based my description on the behavior of /lib/svc/method/mdata-fetch, since that's the only SMF method I see that references dns_domain from mdata. The other SMF methods all reference CONFIG_dns_domain. I didn't see what you describe in the code for mdata-fetch.

I have an instance deployed in JPC 1 week ago on PI 20170105T023718Z, and here's the entirety of /etc/hosts:

::1             localhost
127.0.0.1       localhost localhost.local loghost deploy-cache

As far as I can tell, what you're describing only happens in the global zone as part of identity:node. But, I may be missing something?

src/vm/man/vmadm.1m.md#954 @trentm

Perhaps this part could be clarified. From my testing in COAL, updating dns_domain on a VM will only propagate to /etc/resolv.conf if both (a) maintain_resolvers=true and (b) there is a change to VM.resolvers.

src/vm/man/vmadm.1m.md#954 @bahamat

Should we just fix that in the PI then? If your resolvers are correct but you need to fix dns_domain, you would have to set resolvers to some wrong value, then set resolvers back to the correct value while also setting dns_domain. That behavior itself feels broken to me.

src/vm/man/vmadm.1m.md#954 @trentm

You are welcome to open a separate ticket and CR to change that if you like. For here I was suggesting just clarifying in the docs. I don't have a strong opinion as we don't expose changing dns_domain via cloudapi currently.

@bahamat commented at 2018-06-20T15:25:58

Patch Set 2:

New commits:
commit ee3627b4704d1fa2180334f6751f7ac29471554d
WIP

commit 90514600486f6529a9caf55c9cbef164c8a92def  
OS-5985 vmadm man page incorrectly states dns_domain property is associated with /etc/hosts

@bahamat commented at 2018-06-20T15:34:10

Patch Set 1:

(1 comment)

@trentm commented at 2018-06-20T17:34:46

Patch Set 1:

(1 comment)