I would choose a consistent approach across the entire environment. Both solutions work fine and will remain compatible with most applications. There is a difference in manageability, though.
I go with the short name as the HOSTNAME setting, and set the FQDN as the first column in /etc/hosts for the server's IP, followed by the short name.
I have not encountered many software packages that enforce or display a preference between the two. I find the short name to be cleaner for some applications, specifically logging. Maybe I've been unlucky in seeing internal domains like server.northside.chicago.rizzomanufacturing.com. Who wants to see that in the logs or a shell prompt?
Sometimes, I'm involved in company acquisitions or restructuring where internal domains and/or subdomains change. I like using the short hostname in these cases because logging, kickstarts, printing, systems monitoring, etc. do not need full reconfiguration to account for the new domain names.
A typical RHEL/CentOS server setup for a server named "rizzo" with internal domain "ifp.com", would look like:
/etc/sysconfig/network:
HOSTNAME=rizzo
...
-
/etc/hosts:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
172.16.100.13 rizzo.ifp.com rizzo
-
[root@rizzo ~]# hostname
rizzo
-
/var/log/messages snippet:
Dec 15 10:10:13 rizzo proftpd[19675]: 172.16.100.13 (::ffff:206.15.236.182[::ffff:206.15.236.182]) - Preparing to
chroot to directory '/app/upload/GREEK'
Dec 15 10:10:51 rizzo proftpd[20660]: 172.16.100.13 (::ffff:12.28.170.2[::ffff:12.28.170.2]) - FTP session opened.
Dec 15 10:10:51 rizzo proftpd[20660]: 172.16.100.13 (::ffff:12.28.170.2[::ffff:12.28.170.2]) - Preparing to chroot
to directory '/app/upload/ftp/SRRID'
Best Answer
Changing the hostname assigned by the hosting provider to something matching your own organisation's naming convention is usually a good idea.
Predictable and memorable host names help humans remember and identify systems much more easily than the ip-address and will likely help prevent mistakes.
From a branding perspective you usually also want your servers to identify themselves as part of your domain, not the hosting providers.
Keep in mind that a hostname must uniquely identify a specific server and a server can (should) have only one hostname.
That also implies that you usually use a domain that you actually own, not something you make up.
I.e. avoid the situation where a single web server is hosting multiple websites and that has the hostname www.example.com. You can spend hours checking and finding nothing wrong with that website before realizing that the issue is with "
www other-site" running onwww.example.comYou want to avoid recycling hostnames, it gets annoying fast when you need to distinguish individual hosts by "the old www.example.com" and "the new www.example.com" and similar such non-sense.
The hostname will be used in system prompts, banners, error messages , log files etc.
When you have for instance a cluster of web servers all with the same hostname
www.example.comidentifying the specific misbehaving node is unnecessarily difficult.With forward DNS you can point an unlimited number of different and unrelated host and domainnames to a server's ip-address, but for reverse DNS you can effectively only map the ip-address to a single hostname. Align the reverse DNS record with the hostname set in the server.