Act one: No.1 Duetto "Bashing the SMF scripts for sake of a sane DHCP client config"

So I've been able to pick up a DHCP address from my ISP. I've resolved the client name issue. Big deal. But now, every time I log in, be it via X or via shell, I am told the hostname is the same as whatever my external interface has. Counterintuitive I would say: Wasn't the whole purpose of /etc/nodename to overcome this? (at least, this is the way it works if you configure interfaces statically!)

So I decided to start digging in the SMF framework to work around this. (I'll regret this when I start patching or upgrading again is my guess)

It was pretty easy to dig up the files related to the SMF framework:

• the XML files are in /var/svc/manifest//....
• the methods defined in the XMLs are located in /lib/svc/method.

A "fgrep -l '/etc/nodename' /lib/svc/method/* | xargs less" revealed that the hostname is set to the contents of /etc/nodename in two locations:

at the end of /lib/svc/method/identity-node:

# If the netstrategy was unsuccessful and we haven't got a locally configured
# name, default to "unknown"
#
if [ -z "$hostname" ]; then
hostname="`shcat /etc/nodename 2>/dev/null`"
if [ -z "$hostname" ]; then
hostname="unknown"
fi
fi

And then there's a similar snippet in /lib/svc/method/net-physical:

#In order to avoid bringing up the interfaces that have
# intentionally been left down, perform RARP only if the system
# has no configured hostname in /etc/nodename
hostname="`shcat /etc/nodename 2>/dev/null`"

I went for the easy way out. I modified both scripts to read the entry from a new file /etc/machine, containing the machinename.

Rebooted, and voila. Logging in showed the hostname I wanted all along for this machine.

routing table looks a clean as well:

Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.200.0 dc-utr01-int U 1 495 hme1
XX.XXX.XXX.0 dc-utr01-ext U 1 999 hme2
BASE-ADDRESS.MCAST.NET dc-utr01-ext U 1 0 hme2