#2369 closed task (invalid)
Set hostname with FQDN
Reported by: | DJ Lucas | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Bootscripts | Version: | SVN |
Severity: | normal | Keywords: | |
Cc: |
Description (last modified by )
Following on from #2364, /etc/sysconfig/network should contain a fully qualified domain name now that /bin/hostname supports it...that is assuming that it correctly sets domainname and hostname in /proc/sys/kernel. I also notice that a few old switches (-h, --host, and --domainname), as well as the DECnet support, have been removed in comparison to the really old one from net-tools. Be on the lookout for scripts that test only for -f and then use switches that might not exist.
Change History (11)
comment:1 by , 16 years ago
Description: | modified (diff) |
---|
comment:2 by , 16 years ago
Component: | Book → Bootscripts |
---|
comment:3 by , 16 years ago
follow-up: 6 comment:4 by , 16 years ago
Not quite sure what your testcase would be, DJ, but this works for me:
$ ./hostname kyoto.internal.net $ hostname kyoto.internal.net $
follow-up: 7 comment:5 by , 16 years ago
hostname -f && hostname -s && hostname -d
or
cat /proc/sys/kernel/hostname && cat /proc/sys/kernel/domainname
comment:6 by , 16 years ago
I don't think that's it Matt. What is wanted is something like:
bdubbs@lfs6:~$ hostname lfs6 bdubbs@lfs6:~$ hostname --fqdn lfs6.gdc.com
Using net-tools 1.60 / hostname 1.100 (2001-04-14).
This is set in /etc/rc.d/init.d/localnet:
hostname ${HOSTNAME} where HOSTNAME is defined in /etc/sysconfig/network as HOSTNAME=lfs6. The fqdn is picked up from /etc/hosts:
192.168.0.75 lfs6.gdc.com lfs6
From the man page:
THE FQDN
You can't change the FQDN (as returned by hostname --fqdn)
or the DNS domain name (asreturned by dnsdomainname) with this command. The FQDN of the system is the name that the resolver(3) returns for the host name.
Technically: The FQDN is the name gethostbyname(2) returns
for the host name returned by gethostname(2). The DNS domain name is the part after the first dot.
Therefore it depends on the configuration (usually in
/etc/host.conf) how you can change it. Usually (if the hosts file is parsed before DNS or NIS) you can change it in /etc/hosts.
comment:7 by , 16 years ago
Replying to dj@…:
hostname -f && hostname -s && hostname -d
# hostname kyoto.internal.net # hostname kyoto.internal.net # hostname -f kyoto.internal.net # hostname -s kyoto # hostname -d internal.net
or
cat /proc/sys/kernel/hostname && cat /proc/sys/kernel/domainname
# cat /proc/sys/kernel/hostname kyoto.internal.net # cat /proc/sys/kernel/domainname (none)
I'm testing in a limited environment though. This is not DNSed/DHCPed, so someone will have to test under those conditions I guess.
comment:8 by , 16 years ago
It's been a while, I don't have net-tools version installed, but I had thought that it correctly separated domainname and hostname if you supplied an fqdn when setting it. Maybe my memory is wrong. I've been using a script to modify proc directly for a long time. Bruce, you have it installed, does net-tools hostname set both hostname and domainname in proc correctly if passed a fqdn without arguments? If so, then we should probably bug inetutils maintainer (with a patch). I'll try and look at it a little later on this week. Matt, can you use -f when setting hostname and see if domainname is set correctly?
comment:9 by , 16 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Eww yuck. I feel as thought I've been caught with my pants around my ankles. I am very sorry for the wild goose chase. I'm seeing lots of documentation on this, and almost all neglects to mention NIS. Apparently when I learned of it years ago, I had used one of these crappy documentation sources. Official documentation states that hostname and domainname (as used in /proc/sys/kernel) are NIS/YP hosntname and domainname, not DNS hostname and domainname.
from Documentation/sysctl/kernel.txt:
domainname & hostname: These files can be used to set the NIS/YP domainname and the hostname of your box in exactly the same way as the commands domainname and hostname, i.e.: # echo "darkstar" > /proc/sys/kernel/hostname # echo "mydomain" > /proc/sys/kernel/domainname has the same effect as # hostname "darkstar" # domainname "mydomain" Note, however, that the classic darkstar.frop.org has the hostname "darkstar" and DNS (Internet Domain Name Server) domainname "frop.org", not to be confused with the NIS (Network Information Service) or YP (Yellow Pages) domainname. These two domain names are in general different. For a detailed discussion see the hostname(1) man page.
Though most configurations would probably use DNS==NIS for domain name now days, aking that assumption on the user's behalf would not be the right thing to do.
Closing ticket invalid.
comment:10 by , 16 years ago
DJ, I realise you've closed this now, and I'm not qualified enough to reopen it as my knowledge of NIS/YP is non-existent. However, note the following does what I, naive as I am to networking configuration, would expect:
# hostname -f kyoto.internal.net # hostname kyoto # hostname -f kyoto.internal.net # hostname -s kyoto # hostname -d internal.net # cat /proc/sys/kernel/hostname kyoto # cat /proc/sys/kernel/domainname (none)
comment:11 by , 16 years ago
Yes, and it should. My understanding of /proc/sys/kernel/domainname was completely off base. From Bruce's description, I'm making a partially educated (now) guess here, but ISTM that everything after the first dot should be discarded when setting with the -f flag. The domain name should be determined by consulting /etc/hosts, and should that fail, then by DNS (unless you've modified /etc/nsswitch.conf). I'm still going off of the man page for net-tools hostname, but if the new version holds true to the previous functions, setting only the short hostname (hostname kyoto
) *should* return identical results.
Not that it really matters much, but this ticket probably belongs to book, being that the /etc/sysconfig/network file is created in the book's instructions. If the new hostanme works correctly, which I haven't tested it yet, it shouldn't require a change to the localnet script.