DNS Search Domain in instance /etc/resolv.conf should be set by DHCP

I think this is the same as an issue I've been trying to fix.

On a freshly started up instance (with DISABLE_DNS=n), running hostname -f or dnsdomainname fails (causing issues with running Puppet, as, I would expect it would with other applications).

As a temporary workaround, I used a user-data script for cloud-init to put the following lines into /etc/dhcp3/dhclient.conf on the instance:

supersede domain-name "eucalyptus.internal"
supersede domain-search "eucalyptus.internal";
prepend domain-name-servers 172.19.1.1;

(I'm using the CLC private IP, because when using the public IP, the returning packets are from the local address, and dns doesn't like it.)

I've been looking at a way to do this from the DHCP server on the CLC, and from what I can gather, I'd need to modify "tools/eucanetd" and possibly add some new options to eucalyptus.conf?

Can anyone comment on if this is correct?

Also, would it be worth adding the ability to set/override dhcp server options from eucalyptus.conf?

Its actually simpler than that :)

L1032 of net/vnetwork.c is

fprintf(fp, "subnet %s netmask %s {\n option subnet-mask %s;\n option broadc .....

change it to ..

fprintf(fp, "subnet %s netmask %s {\n option domain-name \"eucalyptus.internal\";\n option subnet-mask %s;\n option broadc ...

and recompile ..

Also - that user-data script you have wont work thanks to "default-lease-time 1200;" .. 20 mins later your changes are reverted...

Also re "(I'm using the CLC private IP, because when using the public IP, the returning packets are from the local address, and dns doesn't like it.)" ..

Thats a mix of two issues i think ..

Lets say your instance FQDN is euca-172-19-1-2.eucalyptus.internal / euca-10-2-2-110.eucalyptus.uec.domain.com (i.e in the admin GUI, you set the domain to be "uec.domain.com")

You have to delegate uec.domain.com to the CLC's public IP in domain.com's DNS records, and on you're local resolver, delagate "internal" to the CLC's public IP ... This is the only way I've managed to hack euca's DNS setup to work..

The second possible part of that issue is traffic returning from the wrong interface - thats hairpin NAT not being applied correctly. I have another 1 line patch here for this https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/676167

and

The user-data script sets the options in /etc/dhcp3/dhclient.conf.
The supersede and prepend tags make sure that when the lease is renewed, those options supersede and prepend the ones retrieved via dhcp. So those options should always override, at least, that's how I understand it, and also, as part of the script, I do a

/etc/init.d/networking restart

for good measure which runs dhclient. So if the options were going to be overwritten, they would be immediately.

As for changing net/vnetwork.c in the way you suggested, do you mean that as a fix I should do, then submit, or just for me specifically? I was looking at doing it in a way that's configurable that could be used by others.

Aha - I didn't noticed it was /etc/dhcp3/dhclient.conf you were editing, rather than /etc/resolv.conf

Re the change to net/vnetwork.c .. The only config option that would require that line to change (when DNS is delegated correctly) is when DISABLE_DNS=Y it should use the original version .. No need for new config options etc etc..

if (DISABLE_DNS == 'Y') {
     fprintf(fp, "subnet %s netmask %s {\n option subnet-mask %s;\n option broadc .....
}
else
{
     fprintf(fp, "subnet %s netmask %s {\n option domain-name \"eucalyptus.internal\";\n option subnet-mask %s;\n option broadc ...
}

Also .. really .. the CLC should not be listed in the nodes /etc/resolv.conf at all - its an authoritative name server rather than a recursive name server ..

The CLC is only there temporarily, the cloud is currently in test phase, once we get it put into place properly, the DNS will be sorted.

Thanks for the help, I'll let you know how it goes!

Digging through the latest code in the bazaar repo, it seems VNET_DOMAINNAME is now a configuration option, (handled in cluster/handlers.c and project/cluster/handlers.c according to grep), which does the above.

This issue is now being tracked upstream at http://eucalyptus.atlassian.net/browse/EUCA-2744

Please watch that issue for further updates.