Your message dated Sun, 12 May 2024 15:24:27 +0100 with message-id <caj3buor6mfuq5kozs_nrki-fmxemopwtzgouzew1vau2chv...@mail.gmail.com> and subject line Re: Bug#574858: logcheck: Does not ignore unresolvable hostname has caused the Debian Bug report #574858, regarding logcheck: Does not ignore unresolvable hostname to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 574858: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574858 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: logcheck Version: 1.3.7 Severity: normal After installing logcheck on a system it posted an error to the cron mail address hourly. An untrapped script error was posting stderr output to cron. It originated here: # Hostname either fully qualified or not. if [ $FQDN -eq 1 ]; then HOSTNAME="$(hostname --fqdn)" > /dev/null 2>&1 else HOSTNAME="$(hostname --short)" > /dev/null 2>&1 fi There has obviously been an attempt to silence errors in this area. Unfortunately that isn't the correct shell syntax to do this. That is silencing the output of the assignment and not of the hostname command itself. Therefore if the hostname isn't registered in DNS the error message is still emitted to stderr. $ hostname --short hostname: Unknown host $ hostname --long hostname: Unknown host I believe what was intended was the following: # Hostname either fully qualified or not. if [ $FQDN -eq 1 ]; then HOSTNAME="$(hostname --fqdn 2>/dev/null)" else HOSTNAME="$(hostname --short 2>/dev/null)" fi However this will still fail to produce a correct hostnames in the face of an unresolvable hostname in DNS. And I will guess that the short hostname is the more typical case these days since it is the default in Debian. Therefore it would be better if for the short case the hostname is received and then truncated at the first dot if one exists. This will avoid this error for the short case entirely. Because the script is already a #!/bin/bash script it is safe to use a POSIX shell parameter expansion construct. Here is an improvement. # 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 I have tested this on my system and it produced the desired result. The process of determining the FQDN using 'hostname --fqdn' is still problematic since the hostname command doesn't do the Right Thing there but that is a different topic. Determining the one single domain name of a host is fraught with subtle issues. Note: Since shell word splitting isn't done on variable assignment the extra quotes are not needed there to protect the right hand side value from word splitting. For example: $ foo=$(echo "one two three") $ echo "$foo" one two three Thanks, Bob
--- End Message ---
--- Begin Message ---On Sun, 12 Mar 2023 22:51:25 +0000 Richard Lewis <richard.lewis.deb...@googlemail.com> wrote: > control: tags -1 - patch + moreinfo > > On Fri, 21 May 2010 14:58:14 +0200 Hannes von Haugwitz > <han...@vonhaugwitz.com> wrote: > > Bob Proulx wrote: > > > 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. > > > > > Sorry, but I don't see the problem. As far as I understand a properly > > configured /etc/hosts file should be enough for a correct working > > 'hostname --fqdn' command. > > > > Please try to describe your problem in a few words. What behavior do you > > expect and what behavior do you see? > > There's been no reply to this bug for 12 years. I agree that it is > unclear what the remaining bug is. > > I am running logcheck in a systemd-nspawn container, where the > hostname is not registered in the DNS > > Although 'hostname --fqdn' does not work, logcheck correctly finds it > via 'hostname --short' which works fine. > > The user can also use the '-H' option to set whatever hostname they like. > > (i'll close this some time after bookworm if no-one objects!) A year later: closing: does not seem to be a bug
--- End Message ---
