DNS on OmniOS AWS Image (Learning about dhcpinfo)
21 October 2012

I was working away creating an Amazon EC2 OmniOS AMI, but Andrzej Szeszo beat me to the punch. So, I’ve been messing about with his images.

You need to fire them up from the US East region, and the AMI ID I’m using right now is ami-e14dfe88. It runs just fine as a t1.micro image, which I believe puts it in free tier usage.

So, I’m all logged on and poking around when:

$ ping google.com
ping: unknown host google.com
$ ping is alive

Looks like DNS is broken. ( == google.com).

$ svcs -x
svc:/network/dns/client:default (DNS resolver)
 State: offline since Sun Oct 21 07:04:34 2012
Reason: Dependency file://localhost/etc/resolv.conf is absent.

Hm. Now, I’ve never really used DHCP on Solaris, but I do recall dhcpinfo being somewhere in the mix. Turns out that it’s a little impenetrable, and the man page isn’t particularly helpful. (Or at least it wasn’t to me.)

$ dhcpinfo
usage: dhcpinfo [-c] [-i interface] [-n limit] [-v {4|6}] code
       dhcpinfo [-c] [-i interface] [-n limit] [-v {4|6}] identifier

Fine, -i is obviously my interface, which on EC2, which is Xen, means xnf0; -n is the maximum number of results to return, and -v is the IPv version. What the heck are code and identifier. Turns out that all the possible identifiers are the first column of /etc/dhcp/inittab, and there are loads of them:

$ awk '/^[A-Z]/ { print $1 }' /etc/dhcp/inittab | sort

So let’s have a look at what I’ve got. Note that I don’t need to specify the IP interface, because I’ve only got one.

$ ipadm show-addr  xnf0/v4
ADDROBJ           TYPE     STATE        ADDR
xnf0/v4           dhcp     ok 
$ dhcpinfo Ciaddr
$ dhcpinfo Subnet
$ dhcpinfo DNSdmain
$ dhcpinfo DNSserv

So I opened up /etc/resolv.conf in vi and made it look like this:

domain ec2.internal

Then added dns to the hosts line in /etc/resolv.conf and cleared the DNS service

# svcadm clear dns/client
$ ping google.com
google.com is alive

Given that OmniOS had all the correct information, I’m not sure why it wasn’t updating the files itself. I think that it’s safe to hardwire these values into the AMI.