If we're going to have release code names for the kernel, might as well
advertise them somewhere. :)
Signed-off-by: Kyle McMartin <[email protected]>
--- a/Makefile
+++ b/Makefile
@@ -841,6 +841,7 @@ define filechk_version.h
exit 1; \
fi; \
(echo \#define UTS_RELEASE \"$(KERNELRELEASE)\"; \
+ echo \#define LINUX_CODE_NAME \"$(NAME)\"; \
echo \#define LINUX_VERSION_CODE `expr $(VERSION) \\* 65536 + $(PATCHLEVEL) \\* 256 + $(SUBLEVEL)`; \
echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'; \
)
diff --git a/init/version.c b/init/version.c
index 3ddc3ce..97cc8ec 100644
--- a/init/version.c
+++ b/init/version.c
@@ -29,5 +29,6 @@ struct new_utsname system_utsname = {
EXPORT_SYMBOL(system_utsname);
const char linux_banner[] =
- "Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
- LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
+ "Linux version " UTS_RELEASE " \"" LINUX_CODE_NAME "\" ("
+ LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") "
+ UTS_VERSION "\n";
On Thu, 25 May 2006, Kyle McMartin wrote:
>
> If we're going to have release code names for the kernel, might as well
> advertise them somewhere. :)
Well, part of the charm of the name is that it's totally meaningless. I
can pick names out of my *ss, and they don't matter in the least, and
nobody will ever see it except in the kernel diffs.
(As to Lordi, I've only ever seen their Eurovision thing on Youtube,
because those pesky US networks thinks we're interested in some kind of
inferior "American Idol" copycat product. But unless you've lived in
Finland during the 80s and 90s, you just simply cannot appreciate the
"Whaaa?" factor of having Finland win the dang thing. Imagine a whole
_country_ going "Whaaa? What the f?" at the same time..).
Linus
On Thu, 2006-05-25 at 08:46 -0700, Linus Torvalds wrote:
>
> On Thu, 25 May 2006, Kyle McMartin wrote:
> >
> > If we're going to have release code names for the kernel, might as well
> > advertise them somewhere. :)
>
> Well, part of the charm of the name is that it's totally meaningless. I
> can pick names out of my *ss, and they don't matter in the least, and
> nobody will ever see it except in the kernel diffs.
>
> (As to Lordi, I've only ever seen their Eurovision thing on Youtube,
> because those pesky US networks thinks we're interested in some kind of
> inferior "American Idol" copycat product. But unless you've lived in
> Finland during the 80s and 90s, you just simply cannot appreciate the
> "Whaaa?" factor of having Finland win the dang thing. Imagine a whole
> _country_ going "Whaaa? What the f?" at the same time..).
>
Hmm, considering how big he is in Finland, maybe the 2.6.18 release
should be code name "Conan" ;)
-- Steve
On Thu, 25 May 2006, Linus Torvalds wrote:
>
>
> On Thu, 25 May 2006, Kyle McMartin wrote:
>>
>> If we're going to have release code names for the kernel, might as well
>> advertise them somewhere. :)
>
> Well, part of the charm of the name is that it's totally meaningless. I
> can pick names out of my *ss, and they don't matter in the least, and
> nobody will ever see it except in the kernel diffs.
Unlike the release names for "Pan" (http://pan.rebelbase.com/). They
revel in weird release names.
"I will not buy this lutefisk, it is scratched."
> (As to Lordi, I've only ever seen their Eurovision thing on Youtube,
> because those pesky US networks thinks we're interested in some kind of
> inferior "American Idol" copycat product.
Except the Eurovision Song Contest has been going on since sometime in the
middle of the Jurasic period.
> But unless you've lived in
> Finland during the 80s and 90s, you just simply cannot appreciate the
> "Whaaa?" factor of having Finland win the dang thing. Imagine a whole
> _country_ going "Whaaa? What the f?" at the same time..).
It would be like Gwar winning American Idol. (Which would be about the
only way to get me to watch it.)
--
"Waiter! This lambchop tastes like an old sock!" - Sheri Lewis
On Thu, 25 May 2006, alan wrote:
>
> > (As to Lordi, I've only ever seen their Eurovision thing on Youtube,
> > because those pesky US networks thinks we're interested in some kind of
> > inferior "American Idol" copycat product.
>
> Except the Eurovision Song Contest has been going on since sometime in the
> middle of the Jurasic period.
Sorry, I phrased it badly. I meant that Idol was the inferior copy-cat.
I'm well aware of the long (and for a Finn - until recently - very painful
indeed) history of the Eurovision.
Linus
>If we're going to have release code names for the kernel, might as well
>advertise them somewhere. :)
>
>--- a/init/version.c
>+++ b/init/version.c
>@@ -29,5 +29,6 @@ struct new_utsname system_utsname = {
> EXPORT_SYMBOL(system_utsname);
>
> const char linux_banner[] =
>- "Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
>- LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
>+ "Linux version " UTS_RELEASE " \"" LINUX_CODE_NAME "\" ("
>+ LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") "
>+ UTS_VERSION "\n";
>-
As for extending the linux_banner, here's a real patch in my line...
Signed-off-by: Jan Engelhardt <[email protected]>
diff --fast -Ndpru linux-2.6.17-rc5~/arch/i386/boot/setup.S linux-2.6.17-rc5+/arch/i386/boot/setup.S
--- linux-2.6.17-rc5~/arch/i386/boot/setup.S 2006-05-25 03:50:17.000000000 +0200
+++ linux-2.6.17-rc5+/arch/i386/boot/setup.S 2006-05-25 18:35:04.661512000 +0200
@@ -862,6 +862,8 @@ kernel_version: .ascii UTS_RELEASE
.ascii LINUX_COMPILE_BY
.ascii "@"
.ascii LINUX_COMPILE_HOST
+ .ascii "."
+ .ascii LINUX_COMPILE_DOMAIN
.ascii ") "
.ascii UTS_VERSION
.byte 0
diff --fast -Ndpru linux-2.6.17-rc5~/arch/x86_64/boot/setup.S linux-2.6.17-rc5+/arch/x86_64/boot/setup.S
--- linux-2.6.17-rc5~/arch/x86_64/boot/setup.S 2006-05-25 03:50:17.000000000 +0200
+++ linux-2.6.17-rc5+/arch/x86_64/boot/setup.S 2006-05-25 18:35:04.661512000 +0200
@@ -748,6 +748,8 @@ kernel_version: .ascii UTS_RELEASE
.ascii LINUX_COMPILE_BY
.ascii "@"
.ascii LINUX_COMPILE_HOST
+ .ascii "."
+ .ascii LINUX_COMPILE_DOMAIN
.ascii ") "
.ascii UTS_VERSION
.byte 0
diff --fast -Ndpru linux-2.6.17-rc5~/init/version.c linux-2.6.17-rc5+/init/version.c
--- linux-2.6.17-rc5~/init/version.c 2006-05-25 03:50:17.000000000 +0200
+++ linux-2.6.17-rc5+/init/version.c 2006-05-25 18:35:26.321512000 +0200
@@ -30,4 +30,5 @@ EXPORT_SYMBOL(system_utsname);
const char linux_banner[] =
"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
- LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n";
+ LINUX_COMPILE_HOST "." LINUX_COMPILE_DOMAIN ") ("
+ LINUX_COMPILER ") " UTS_VERSION "\n";
#<<eof>>
Jan Engelhardt
--
| Software Engineer and Linux/Unix Network Administrator
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/
>> Except the Eurovision Song Contest has been going on since sometime in the
>> middle of the Jurasic period.
>
>Sorry, I phrased it badly. I meant that Idol was the inferior copy-cat.
>I'm well aware of the long (and for a Finn - until recently - very painful
>indeed) history of the Eurovision.
>
Hah look at Germany the last four years :)
Maybe we "qualified", but either the song or the performer was crap. (Let's
not think of 2001 at all.)
Jan Engelhardt
--
On Thu, 25 May 2006, Jan Engelhardt wrote:
>
> As for extending the linux_banner, here's a real patch in my line...
No, this sucks.
Sane configurations already have the FQDN as the hostname. It's quite
common to have "hostname" be the full name, and domainname be "(none)"
(with dnsdomainname being the domain name).
I think your patch would make it say
[email protected]
for me.
So just fix your hostname to give the full hostname. Nothing less makes
any sense anyway.
Linus
>> As for extending the linux_banner, here's a real patch in my line...
>
>No, this sucks.
>
Read the subject (still contains Lordi) , so take this ("real") with a
grain of salt.
>Sane configurations already have the FQDN as the hostname. It's quite
>common to have "hostname" be the full name, and domainname be "(none)"
>(with dnsdomainname being the domain name).
>
>I think your patch would make it say
>
> [email protected]
>
>for me.
>
# cat /proc/version
Linux version 2.6.17-rc4 (jengelh@shanghai) (gcc version 4.1.0 (SUSE
Linux)) #1 Sat May 20 00:06:16 CEST 2006
# hostname
shanghai
# hostname --fqdn
shanghai.hopto.org
# dnsdomainname
hopto.org
If the FQDN was already in the kernel, I would not have submitted this.
Frankly, the only that that I have not done was compile test it :)
>So just fix your hostname to give the full hostname. Nothing less makes
>any sense anyway.
>
Oh in that case you just found a bug in suse linux.
> Linus
>
Jan Engelhardt
--
On Thu, 25 May 2006, Jan Engelhardt wrote:
>
> # hostname --fqdn
> shanghai.hopto.org
Ahh. I wonder how portable this is. We could certainly make the kernel
build use "hostname --fqdn" if that works across all versions.
That code hasn't changed in a looong time, and I suspect that "--fqdn"
didn't exist back when..
Linus
Linus Torvalds wrote On 25-05-2006 21:47:
>
> On Thu, 25 May 2006, Jan Engelhardt wrote:
>> # hostname --fqdn
>> shanghai.hopto.org
>
> Ahh. I wonder how portable this is. We could certainly make the kernel
> build use "hostname --fqdn" if that works across all versions.
>
> That code hasn't changed in a looong time, and I suspect that "--fqdn"
> didn't exist back when..
Doesn't work here :
cartman@southpark ~ $ hostname --fqdn
hostname: invalid option -- -
Try `hostname --help' for more information.
cartman@southpark ~ $ hostname --version
hostname (GNU coreutils) 5.96
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software. You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.
Written by Jim Meyering.
This is the latest version of coreutils available.
/ismail
On Thursday 25 May 2006 19:47, Linus Torvalds wrote:
> On Thu, 25 May 2006, Jan Engelhardt wrote:
> > # hostname --fqdn
> > shanghai.hopto.org
>
> Ahh. I wonder how portable this is. We could certainly make the kernel
> build use "hostname --fqdn" if that works across all versions.
>
> That code hasn't changed in a looong time, and I suspect that "--fqdn"
> didn't exist back when..
This is probably a broken configuration, but it would cause a regression for
me:
[alistair] 19:53 [~] hostname
damocles
[alistair] 19:52 [~] hostname --fqdn
localhost
"localhost" isn't very descriptive if I'm trying to figure out which machine a
dmesg came from.
--
Cheers,
Alistair.
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
>> > # hostname --fqdn
>> > shanghai.hopto.org
>>
>> Ahh. I wonder how portable this is. We could certainly make the kernel
>> build use "hostname --fqdn" if that works across all versions.
>>
>> That code hasn't changed in a looong time, and I suspect that "--fqdn"
>> didn't exist back when..
>
> Doesn't work here :
>
> cartman@southpark ~ $ hostname --fqdn
> hostname: invalid option -- -
> Try `hostname --help' for more information.
> cartman@southpark ~ $ hostname --version
> hostname (GNU coreutils) 5.96
20:56 shanghai:~ > hostname --version
net-tools 1.60
hostname 1.100 (2001-04-14)
Interesting.
Jan Engelhardt
--
Jan Engelhardt wrote On 25-05-2006 21:59:
>>>> # hostname --fqdn
>>>> shanghai.hopto.org
>>> Ahh. I wonder how portable this is. We could certainly make the kernel
>>> build use "hostname --fqdn" if that works across all versions.
>>>
>>> That code hasn't changed in a looong time, and I suspect that "--fqdn"
>>> didn't exist back when..
>> Doesn't work here :
>>
>> cartman@southpark ~ $ hostname --fqdn
>> hostname: invalid option -- -
>> Try `hostname --help' for more information.
>> cartman@southpark ~ $ hostname --version
>> hostname (GNU coreutils) 5.96
>
> 20:56 shanghai:~ > hostname --version
> net-tools 1.60
> hostname 1.100 (2001-04-14)
>
> Interesting.
So coreutils & net-tools conflict with each other. How nice :/
/ismail
>
>[alistair] 19:53 [~] hostname
>damocles
>
>[alistair] 19:52 [~] hostname --fqdn
>localhost
>
>"localhost" isn't very descriptive if I'm trying to figure out which machine a
>dmesg came from.
>
So, after we have coreutils and net-tools, what hostname do you run?
Here's the output of another machine (which actually does not have a domain
part set):
20:35 mason:/etc # rpm -qf `which hostname`
net-tools-1.60-37
21:00 mason:/etc # hostname -v
gethostname()=`mason'
mason
21:00 mason:/etc # hostname --fqdn
mason
21:00 mason:/etc # domainname
(none)
21:00 mason:/etc # dnsdomainname
Runs Aurora Linux 2.0.
Jan Engelhardt
--
On Thu, 25 May 2006, Alistair John Strachan wrote:
>
> This is probably a broken configuration, but it would cause a regression for
> me:
>
> [alistair] 19:53 [~] hostname
> damocles
>
> [alistair] 19:52 [~] hostname --fqdn
> localhost
Oh, wow.
So much for that idea.
Linus
On Thu, May 25, 2006 at 11:47:39AM -0700, Linus Torvalds wrote:
> On Thu, 25 May 2006, Jan Engelhardt wrote:
> >
> > # hostname --fqdn
> > shanghai.hopto.org
>
> Ahh. I wonder how portable this is. We could certainly make the kernel
> build use "hostname --fqdn" if that works across all versions.
>
> That code hasn't changed in a looong time, and I suspect that "--fqdn"
> didn't exist back when..
It still doesn't if you're using GNU coreutils' hostname...
Bauke Jan Douma
On Thu, May 25, 2006 at 08:40:59PM +0200, Jan Engelhardt wrote:
> # cat /proc/version
> Linux version 2.6.17-rc4 (jengelh@shanghai) (gcc version 4.1.0 (SUSE
> Linux)) #1 Sat May 20 00:06:16 CEST 2006
> # hostname
> shanghai
> # hostname --fqdn
> shanghai.hopto.org
> # dnsdomainname
> hopto.org
>
> If the FQDN was already in the kernel, I would not have submitted this.
> Frankly, the only that that I have not done was compile test it :)
>
> Oh in that case you just found a bug in suse linux.
And Debian too. I thought it was invalid to put the FQDN as your
hostname. Also makes updating the domain for a network harder (if one
would ever want to do so). Putting the FQDN as my hostname, makes
hostname -f act very strange. I think a number of tools think doing it
is wrong.
Len Sorensen
On Thu, May 25, 2006 at 07:54:06PM +0100, Alistair John Strachan wrote:
> This is probably a broken configuration, but it would cause a regression for
> me:
>
> [alistair] 19:53 [~] hostname
> damocles
>
> [alistair] 19:52 [~] hostname --fqdn
> localhost
>
> "localhost" isn't very descriptive if I'm trying to figure out which machine a
> dmesg came from.
rceng02:~# hostname
rceng02
rceng02:~# hostname -f
rceng02.eng.lan
rceng02:~# head -1 /etc/hosts
127.0.0.1 rceng02.eng.lan localhost.localdomain localhost
rceng02
rceng02:~#
I always thought that was how it worked. The first hostname in
/etc/hosts on the line containing the short name was used as the FQDN.
Maybe that is only a gnu hostname thing. I seem to recall solaris had a
domainname file that was used to find the domain part of the FQDN
instead.
Len Sorensen
Followup to: <[email protected]>
By author: [email protected] (Lennart Sorensen)
In newsgroup: linux.dev.kernel
>
> And Debian too. I thought it was invalid to put the FQDN as your
> hostname. Also makes updating the domain for a network harder (if one
> would ever want to do so). Putting the FQDN as my hostname, makes
> hostname -f act very strange. I think a number of tools think doing it
> is wrong.
>
BSD practice has been to do it; SysV practice has been to not do it.
This probably has to do with the fact that a larger percentage of BSD
systems were connected to the Internet earlier on, being popular at
universities.
-hpa
> 20:35 mason:/etc # rpm -qf `which hostname`
> net-tools-1.60-37
> 21:00 mason:/etc # hostname -v
> gethostname()=`mason'
> mason
> 21:00 mason:/etc # hostname --fqdn
> mason
> 21:00 mason:/etc # domainname
> (none)
> 21:00 mason:/etc # dnsdomainname
>
>
> Runs Aurora Linux 2.0.
Ubuntu does this too:
mbligh@flay:~$ hostname
flay
mbligh@flay:~$ hostname --fqdn
localhost.localdomain
On Thursday 25 May 2006 22:14, Martin J. Bligh wrote:
> > 20:35 mason:/etc # rpm -qf `which hostname`
> > net-tools-1.60-37
> > 21:00 mason:/etc # hostname -v
> > gethostname()=`mason'
> > mason
> > 21:00 mason:/etc # hostname --fqdn
> > mason
> > 21:00 mason:/etc # domainname
> > (none)
> > 21:00 mason:/etc # dnsdomainname
> >
> >
> > Runs Aurora Linux 2.0.
>
> Ubuntu does this too:
>
> mbligh@flay:~$ hostname
> flay
> mbligh@flay:~$ hostname --fqdn
> localhost.localdomain
I think it's as Lennart suggested. From the man page for /etc/hosts ("man
hosts"), it seems to suggest that the format should be:
IP_address canonical_hostname aliases
On Ubuntu and approximately on my system, it's doing:
127.0.0.1 localhost.localdomain <alias>
But the manpage suggests that "alias" might contain "localhost". On our
machines it contains the "name" we assigned the machine.
So, I think my hosts is screwed (because I don't have the .localdomain bit),
but I think Ubuntu is correct, and using the FQDN is not actually as
intuitive as you might think.
For identification purposes, an "alias" is probably more useful (in general)
than the FQDN, because the FQDN may well be something meaningless like
localhost.localdomain, which is "fully qualified" but isn't a _unique_
machine name, and thus not really a valid domain in a network context.
(The 'hostname' utility from net-tools is using the "canonical hostname"
from /etc/hosts as the value for the FQDN, but gethostname() for the regular
hostname.)
--
Cheers,
Alistair.
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Alistair John Strachan <[email protected]> writes:
> On Thursday 25 May 2006 22:14, Martin J. Bligh wrote:
>> > 20:35 mason:/etc # rpm -qf `which hostname`
>> > net-tools-1.60-37
>> > 21:00 mason:/etc # hostname -v
>> > gethostname()=`mason'
>> > mason
>> > 21:00 mason:/etc # hostname --fqdn
>> > mason
>> > 21:00 mason:/etc # domainname
>> > (none)
>> > 21:00 mason:/etc # dnsdomainname
>> >
>> >
>> > Runs Aurora Linux 2.0.
>>
>> Ubuntu does this too:
>>
>> mbligh@flay:~$ hostname
>> flay
>> mbligh@flay:~$ hostname --fqdn
>> localhost.localdomain
>
> I think it's as Lennart suggested. From the man page for /etc/hosts ("man
> hosts"), it seems to suggest that the format should be:
>
> IP_address canonical_hostname aliases
>
> On Ubuntu and approximately on my system, it's doing:
>
> 127.0.0.1 localhost.localdomain <alias>
>
> But the manpage suggests that "alias" might contain "localhost". On our
> machines it contains the "name" we assigned the machine.
The /etc/hosts file that was installed with the Slackware that ran on
my first Linux machine contained a comment strongly advising against
associating 127.0.0.1 with the hostname (or anything other than
localhost). Apparently some programs (which I don't recall) would
break if you did so. I have followed that advice ever since.
--
M?ns Rullg?rd
[email protected]
>rceng02:~# hostname
>rceng02
>rceng02:~# hostname -f
>rceng02.eng.lan
>rceng02:~# head -1 /etc/hosts
>127.0.0.1 rceng02.eng.lan localhost.localdomain localhost
>rceng02
>rceng02:~#
>
>I always thought that was how it worked. The first hostname in
>/etc/hosts on the line containing the short name was used as the FQDN.
>Maybe that is only a gnu hostname thing. I seem to recall solaris had a
>domainname file that was used to find the domain part of the FQDN
>instead.
>
What a mess. I would prefer to see Linux distributions have
127.0.0.1 localhost
in their /etc/hosts (to have the standard 127.0.0.1<->localhost mapping)
and /etc/HOSTNAME contain the hostname, which is
sethostname()d/setdomainname()d by init scripts and gethostname()d by apps.
Jan Engelhardt
--
Hi everyone,
On Fri, May 26, 2006 at 01:56:02PM +0200, Jan Engelhardt wrote:
> What a mess. I would prefer to see Linux distributions have
> 127.0.0.1 localhost
> in their /etc/hosts (to have the standard 127.0.0.1<->localhost mapping)
> and /etc/HOSTNAME contain the hostname, which is
> sethostname()d/setdomainname()d by init scripts and gethostname()d by apps.
Well I always thought that 127.0.0.1 is localhost, and _only_ localhost,
and the host's real name would rather be mapped to its IP on the real
NIC. Every interface (including local loopback) has a distinct IP;
hostnames are supposed to be resolved to one of these and need to be
somewhat unique on subnets, unless a fqdn is supplied. So here's what I
got, following that scheme:
127.0.0.1 localhost.localdomain localhost
192.168.x.y host.domain.tdl host
Major catch: it presumes you have at least one NIC actually in use. If
lo is the absolute sole interface, one might map every single hostname
to that one as well. Schizophrenia is fun, solitude is gone for good : )
Larger institutions would prefer dynamic stuff like DHCP and DNS anyway,
but for distros' installers intended for home users this might be a
viable solution - never experienced any strangeness with that one so
far.
Just my .02€, with kind regards
Chris
> >> Except the Eurovision Song Contest has been going on since sometime in the
> >> middle of the Jurasic period.
> >Sorry, I phrased it badly. I meant that Idol was the inferior copy-cat.
> >I'm well aware of the long (and for a Finn - until recently - very painful
> >indeed) history of the Eurovision.
> Hah look at Germany the last four years :)
> Maybe we "qualified", but either the song or the performer was crap. (Let's
> not think of 2001 at all.)
As we had Lordi winning this year, I cannot wait for Rammstein
representing Germany in 2007!
Folkert van Heusden
--
http://www.vanheusden.com/multitail - multitail is tail on steroids. multiple
windows, filtering, coloring, anything you can think of
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, http://www.vanheusden.com
Lennart Sorensen <[email protected]> wrote:
> I always thought that was how it worked. The first hostname in
> /etc/hosts on the line containing the short name was used as the FQDN.
> Maybe that is only a gnu hostname thing. I seem to recall solaris had a
> domainname file that was used to find the domain part of the FQDN
> instead.
yes this is how hostname works (see the man page)
# 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.
And yes, this is broken, but who used hostname -f anyway?
BTW: the above works also (better?) if you set the utsname to the FQDN like
Linus does.
Gruss
Bernd
Christian Trefzer <[email protected]> wrote:
> 127.0.0.1 localhost.localdomain localhost
> 192.168.x.y host.domain.tdl host
>
> Major catch: it presumes you have at least one NIC actually in use. If
> lo is the absolute sole interface, one might map every single hostname
> to that one as well. Schizophrenia is fun, solitude is gone for good : )
You can use "127.0.0.2 host.doma.in host" in /etc/hosts if you dont have
another interface, or if it changes regularly.
Gruss
Bernd
Lennart Sorensen <[email protected]> wrote:
> would ever want to do so). Putting the FQDN as my hostname, makes
> hostname -f act very strange. I think a number of tools think doing it
> is wrong.
no hostname -f will deal well with a FQDN gethostname() as long as your
resolver (i.e. /etc/hosts) is setup according to the man page:
> hostname -fv
gethostname()='calista.eckenfels.net'
Resolving 'calista.eckenfels.net' ...
Result: h_name='calista.eckenfels.net'
Result: h_aliases='calista'
Result: h_aliases='eckenfels.net'
Result: h_addr_list='10.0.0.3'
calista.eckenfels.net
Gruss
Bernd
Am Samstag, 27. Mai 2006 01:47 schrieb Folkert van Heusden:
> > >> Except the Eurovision Song Contest has been going on since sometime in the
> > >> middle of the Jurasic period.
> > >Sorry, I phrased it badly. I meant that Idol was the inferior copy-cat.
> > >I'm well aware of the long (and for a Finn - until recently - very painful
> > >indeed) history of the Eurovision.
> > Hah look at Germany the last four years :)
> > Maybe we "qualified", but either the song or the performer was crap. (Let's
> > not think of 2001 at all.)
>
> As we had Lordi winning this year, I cannot wait for Rammstein
> representing Germany in 2007!
Oh yes. We'll see Rammstein, Mot?rhead and Laibach.
And Bosnia will send some 16-year old singing sweetly about the
beauty of some mountain stream and win.
Regards
Oliver
On Thu, May 25, 2006 at 09:48:34AM -0700, Linus Torvalds wrote:
> So just fix your hostname to give the full hostname. Nothing less makes
> any sense anyway.
Which full hostname? I have access to a machine with 2 NICs having 5
IPv4 addresses total, and none of the associated DNS records correspond
to the hostname.
And if I move a laptop from one foreign network to an other, I most
certainly do not want the hostname to change. It is the same machine
with the same name even if it's network address/domain is completely
different compared to what it was 5 minutes ago. It would make
absolutely no sense to include the current network address in the kernel
version.
Anything that assumes that the hostname has anything to do with IP
networking and DNS records is just utterly broken IMHO.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
On Fri, May 26, 2006 at 11:11:40PM +0200, Christian Trefzer wrote:
> Well I always thought that 127.0.0.1 is localhost, and _only_ localhost,
> and the host's real name would rather be mapped to its IP on the real
> NIC. Every interface (including local loopback) has a distinct IP;
Several mistakes: there is no "the real NIC". There may be multiple NICs
(actually quite common nowadays on desktop motherboards, and on laptops
with both wired and wireless interfaces). And one NIC may have several
IP addresses, not just one.
> hostnames are supposed to be resolved to one of these and need to be
> somewhat unique on subnets, unless a fqdn is supplied.
No. Hostname does not have to resolve to _anything_. The hostname is
just a string that identifies the machine for _humans_. It is nothing
more, nothing less. It follows that a hostname should be just as unique
as it's human users are concerned, it has no relation to subnets or
FQDN or any other network term.
> Major catch: it presumes you have at least one NIC actually in use.
You can always configure a dummy interface.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
On Mon, 29 May 2006, Gabor Gombas wrote:
>
> Which full hostname? I have access to a machine with 2 NICs having 5
> IPv4 addresses total, and none of the associated DNS records correspond
> to the hostname.
That is no less true for the non-full hostname.
The fact is, a hostname is a hostname, and not "5 different hostnames".
You're right that it has nothing to do with the IP address, but where did
I claim it did?
If you have to have a hostname (and we do - it's undeniably part of what
UNIX networking does), it's much better to make the hostname be a fully
qualified one. Because it's never worse than having just a non-qualified
one, and it is often better, and avoids the whole confusion.
Linus
Yeah, hostname --fqdn is so broken:
joshua@numenor:~$ hostname
numenor
joshua@numenor:~$ hostname --fqdn
numenor
joshua@numenor:~$
My normal take is not to use the FQDN as the hostname because it
becomes too long.
If I ever need to know my outside-facing IP address, I connect a UDP
socket to 1.2.3.4
and to a getsockname(). To get outside-hostname, I do a reverse-lookup on that.
Since 1.0.0.0/8 will never be allocated, this is gauranteed to work
when there is a way out.
If there's no way out, I'll find that out too.
Gabor Gombas <[email protected]> wrote:
> No. Hostname does not have to resolve to _anything_. The hostname is
> just a string that identifies the machine for _humans_. It is nothing
> more, nothing less. It follows that a hostname should be just as unique
> as it's human users are concerned, it has no relation to subnets or
> FQDN or any other network term.
There are some (common) applications which bind more meaning to that string.
Most noteable MTAs if they are configured to detect things automatically.
The kernel does not care (well I do ignore some exotic cluster, dlm,
remote-ipc, security stacks)
Gruss
Bernd
Joshua Hudson <[email protected]> wrote:
> If I ever need to know my outside-facing IP address, I connect a UDP
> socket to 1.2.3.4
Is your MUA doing that to construct MsgIDs? Your NUA? Your MTA? a local news
spool? For a robust installation of all of them you specify the name, but
some of those services better work out of the box, so the notion of a
primary FQDN is not that bad to have.
> and to a getsockname(). To get outside-hostname, I do a reverse-lookup on that.
> Since 1.0.0.0/8 will never be allocated, this is gauranteed to work
> when there is a way out.
Why should any of your IPs have a reverse resolveable name?
Gruss
Bernd
On Tue, May 30, 2006 at 01:13:51AM +0200, Bernd Eckenfels wrote:
> There are some (common) applications which bind more meaning to that string.
> Most noteable MTAs if they are configured to detect things automatically.
MTAs and most other sensible daemons have configuration options for
overriding the host name exactly because the heuristic of "try to use
gethostname() and hope that it is resolvable" does not work in many
cases.
Using the hostname by default is fine if you keep in mind that it is
only a heuristic and that it is not guaranteed to work.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------