kbase: Mac OS X Server 10.4.6: Changes in Server Hostname Discovery and changeip

Authored by: macshome on Monday, May 08 2006 @ 10:11 pm MDT

Yeah, some people would include me. But until the behavior change in 10.4.6,
the most proper place to set the FQDN was in etc/hostconfig.

I'm just glad to see that Apple:

A) Has straightened it all out
and
B) has documented it.

---
Breaking my server to save yours.

Josh Wisenbaker
www.afp548.com

[ Reply to This | # ]

Authored by: PuLSe on Tuesday, May 09 2006 @ 01:59 pm MDT

I wrote this up for my own website, but it bears repeating here:

Just a little perspective from someone who was responsible for finding the bug in the first place and worked with some of the engineers who actually fixed it. I originally found the bug in the 10.4.3 timeframe, and there was actually a fix coded up for it by the 10.4.4 timeframe. However, Apple's engineering department considered this a significant change to functionality, and so insisted on doing heavy duty QA on the fix before it was released in 10.4.6. This was the right thing to do, in my opinion.

The issue goes back to MOSXS 10.3, when the server hostname was hard-coded in the /etc/hostconfig file, based on what the administrator entered in the Server Setup Assistant. The problem is that some relatively high minority of inexperienced administrators would either put in just the hostname instead of the fully-qualified hostname (e.g. "myserver" instead of "myserver.example.com"), or they would have a typo in the hostname. This would then be propagated through the Server Setup Assistant into various config files on the system.

To avoid this, in 10.4 Apple went to retrieving the server's fully qualified hostname from a reverse DNS lookup at boot time. The thinking was that the administrator only had to get the DNS entry right, and not re-enter the same information as a part of the server setup. However, this ran into a few problems as well. It does not work if: 1) the network didn't have full reverse DNS lookup, such as with a low-end SOHO router; 2) The DNS server is a little bit slow with its response (which can happen if the network switch is slow to autonegotiate the connection speed); or 3) the server is hosting its own DNS server, since the hostname lookup happens very early on in the boot process but the named daemon starts up much later. In any of these cases, the server fell back on the mDNS/Bonjour name of the server.

To get around this, there were two fixes -- one technical, one procedural. The technical fix was to let the named daemon signal to the operating system that it had started up, allowing the operating system to re-check the hostname -- this takes care of (3). The procedural one was to hard code the hostname in the /Library/Preferences/SystemConfiguration/preferences.plist file by using the command:

sudo scutil --set HostName servername.example.com

as documented in the kbase article:

http://docs.info.apple.com/article.html?artnum=302044.

This process is automated by the changes in Server Update 10.4.6, referred to in kbase article:

http://docs.info.apple.com/article.html?artnum=303697

In addition, the operating system now checks for a mismatched stored hostname vs. the reverse DNS result, and complains in system.log if there is a problem.

The point of all of this? Don't edit /etc/hostconfig any more, and make ABSOLUTELY SURE that your Mac OS X Server has proper forward and reverse DNS resolution on its primary IP address.

---
Paul Suh http://www.ps-enable.com/
paul.suh@ps-enable.com (301) 643-1516

[ Reply to This | # ]

Authored by: Dean_Shavit on Wednesday, May 10 2006 @ 04:16 pm MDT

Joel,

if you want to make sure it's statically set, you should use /etc/hosts instead of /etc/hostconfig.

Dean Shavit, Mac Tech Magazine
author of Mac HelpMate
http://www.macworkshops.com/machelpmate

[ Reply to This | # ]