Hannes von Haugwitz wrote:
> Bob Proulx wrote:
> > I believe what was intended was the following:
> Fixed in 1.3.8.
Thanks!
>> # Hostname either fully qualified or not.
>> if [ $FQDN -eq 1 ]; then
>> HOSTNAME=$(hostname --fqdn 2>/dev/null)
>> test -z "$HOSTNAME" && HOSTNAME=$(hostname)
>> else
>> HOSTNAME=$(hostname)
>> HOSTNAME=${HOSTNAME%%.*}
>> fi
>
> With the above fix the error message shouldn't occur any longer. Why
> should logcheck bypass an unresolvable hostname? Wouldn't it be better
> if the administrator fixed the hostname issue instead?
A host has a hostname. A host has network device adaptors. Network
device adaptors have network addresses. There isn't a requirement
that hosts have dns names registered. There isn't a requirement that
a host have only one network address. Indeed there are many multiply
homed hosts on the net with many addresses. The method used by
'hostname --fqdn' uses to produce a fqdn isn't without debate the
correct way. Actually the process of determining the FQDN of a host
for which it isn't specified in the hostname is complex and subtle.
(The BSD way of having the hostname be the fqdn is definitely simplest
but isn't without problems.)
I was setting up a host /here/ for use /there/. Installing on one
private local network for use on a different private local network.
Both networks are using RFC1918 private addresses with local dns
servers. The new machine will in the future on its destination
environment have a hostname that is registered in dns. But in the
installation environment it does not. I did not wish to install a
local dns name for it. It is not needed nor required. The system
uses DHCP to configure its network to obtain an IP address from the
dynamic address pool. I type on the physical console. I have no need
to connect to it from the network and so do not need to know the IP
address that it received.
I set up the machine and provision it. Let it burn-in for several
days running stress testing applications. Copy files onto it and get
it ready to replace a machine on the desination network. During this
time period of days to weeks logcheck complains every hour about the
above hostname issue.
But regardless of how I ran into this problem in general it doesn't
seem good for logcheck to place a requirement that the host's hostname
be registered in dns. A thin client wouldn't have this in every
configuration. It just isn't needed and therefore shouldn't be a
dependency. And in the case that it were a dependency then it
shouldn't produce an error so much as it should detect and report the
dependency failure. But it isn't needed as a dependency. Logcheck
otherwise works fine without the hostname registered in DNS.
Thanks,
Bob
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
