ML Starkey's Weblog: Service with a smile!
Providing Technical Support to Sun's customers and other topics

1. syslogd complains that line 24: WARNING: loghost could not be resolved

2. sendmail is complaining about it's unqualified hostname and unable to qualify my own domain name.

Resolution: provide a domainname.

If you are using static IP addresses, the easiest thing to do is add a fully qualified domain name to the hosts table and you are done:

192.168.1.1 sunny.foo.com sunny loghost

But I'm currently a dhcp client and dhcp edits my /etc/hosts file and anything added to the standard entry is erased. The standard entry looks like this:

192.168.1.2 sunny # Added by DHCP

I needed another way. Google to the rescue. Since all sendmail wants is a domain name and doesn't really care where it comes from (local files, name service, etc.), I added the ".foo.com" to the /etc/nodename file after the hostname, so now that file contains: sunny.foo.com

Correcting the domain name also fixed the syslogd error. That seemed odd until I realized there is no "loghost" defined in the /etc/hosts file created by DHCP. But I ran into another snag with this config: now naming doesn't resolve correctly. After a bit of fiddling, I realized that "sunny.foo.net" is a REAL host out there. Check this out:

Sun Microsystems Inc. SunOS 5.10 Generic January 2005
# ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1004843 mtu 1500 index 2
inet 192.168.1.2 netmask ffffff00 broadcast 192.168.1.255
ether 8:0:20:b5:46:c5

but getent hosts says:

# getent hosts sunny
216.234.246.150 sunny.foo.com

When troubleshooting naming problems, it's a good idea to disable nscd (the name service cache daemon). This ensures you are getting fresh, and not cached, info when querying:

# svcs name-service-cache
STATE STIME FMRI
disabled 14:59:02 svc:/system/name-service-cache:default

dnstools.com confirms that sunny.foo.com is out there:

sunny.foo.com resolves to 216.234.246.150
Domain Whois Results:

Registrant: DigiMedia.com, L.P.
4245 Kemp Blvd., Ste 818
Wichita Falls, TX 76308
US
Domain name: FOO.COM

oops.

/etc/resolv.conf is using the netgear as the name server: nameserver 192.168.1.1

/etc/nsswitch.conf for hosts and ipnodes is using: files dns

Another method to fix this would be for the DHCP server to provide the info when the client boots. Not sure if there is a method to configure the Netgear and dhcp client to send the proper info. Now I'm not sure I want to continue as a DHCP client. It's really getting to be more of a project than I intended. Not to mention a recipe for how NOT to configure DHCP : )

Ok, just a few more things to try with the hostname.hme0 file . . . no luck. Now I'm back to sendmail complaining (syslogd is running however; perhaps adding "inet sunny" to /etc/hostname.hme0 helped there?). But now "getent hosts sunny" resolves to what it should.

A longstanding issue with the hme0 interface was resolved by Solaris 10. I was never able to get autonegotiation working between first a Linksys router/switch and later the Netgear. I had to force hme0 and then it would only work if I forced 10FDX; 100FDX refused to work either way. hme patches didn't help. Now I am finally autonegging:

NOTICE: hme0: 100Mbps full duplex link up

I've also discovered that when I have the VPN client running, I can't get to my local network anymore. This seems to be how Sun wants it to work: no access to a local network from a system currently connected to the Sun network via VPN. Any attempts at configuring a split tunnel would be sincerely frowned upon, it seems. I can understand that. It makes my need for a USB-serial adapter more urgent, if I can't talk to sunny on the local network when on the VPN.

That's enough for now. My rule is that when my neck starts to ache, it's time to wrap it up for the day!