Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Management Community Blog

FQDN UNIX servers

Created: 25 Mar 2009 • Updated: 07 Jul 2009
ziggy's picture
+1 1 Vote
Login to vote

To recap, we are a TMS client with the Altiris agent deployed to 11,000 servers, of which about 20% are UNIX.

We offer our clients a disaster recovery (DR) option, and with that, come the option of having a hot standby server ready to be flipped into production should the need arise.

The issue we came across involves how the server reports its' hostname and domain.

As we know, when the Altiris agent is installed, one process that takes place is the discovery of the hostname/domain on the node and then seeing if it already has a record in the NS database. If it matches, then it will pull down that guid and begin to report under that record. The hostname returns the result of the command 'hostname -s' which is the shortname. That returns all characters (up to a limit of 16) that occur before the first period .

The domain returned is the last two fields that occur before and after the last period.

For example, a server with this as the FQDN: '' would be populated in the Altiris accordingly:
Name: myserver

We configured our DR servers with this FQDN: '

Needless to say, when we would install an Altiris agent on the DR node, the domain that is found does not include the '.dr'. Since their already exists a '' this results in the agent finding a match and pulling down the GUID for the other server. Now we have two different servers with the same GUID. Now they begin the delicate dance of overwriting each others' data in the database. This is bad!

I discovered that a simple modification in the /etc/resolv.conf file on the DR servers will correct this and allow the Altiris agent to pull the true FQDN and create a unique record in the NS database.

You will need to only change the line in the /etc/ resolv.conf file that starts with 'domain' to specifically state the full domain.

For example, a server with this as the FQDN: '' would need to have this line in the /etc/resolv.conf file:

The next time the agent checks in, it will NOT match on an existing record and create a new record flawlessly. If you do have any issues, simply uninstall the agent, remove the record from the NS database (right click the record and select Delete), and reinstall the agent. I have never had any issues with it.

Hope this helps.

Thank you.