Hi,

I began using a revision tracking system for some configfiles. This involved replacing /etc/nullmailer with a symlink to a directory within the local working copy.

I noticed that locally generated mail was suddenly referencing literal "defaulthost".

I tried to create /etc/nullmailer/me with the correct hostname in it, but this didn't help. I attached strace to cron in an attempt to see what was going on and found this:

openat(AT_FDCWD, "/etc/nullmailer/me", O_RDONLY) = 3</path-to-working-copy/<...>/etc/nullmailer/me>
read(3</path-to-working-copy/<...>/etc/nullmailer/me>, "my-correct-hostname-here\n", 4096) = 27
close(3</path-to-working-copy/<...>/etc/nullmailer/me>) = 0
write(2</dev/console<char 5:1>>, "Warning: On Debian systems, nullmailer's 'me' is disregarded; please use '/etc/mailname' instead.\n", 98) = 98
getuid()                                = 0
geteuid()                               = 0
openat(AT_FDCWD, "/etc/nullmailer/../mailname", O_RDONLY) = -1 ENOENT (No such file or directory)

So, while nullmailer prints a message instructing me to fill /etc/mailname, it doesn't actually use /etc/mailname but /etc/nullmailer/../mailname, which doesn't necessarily exist and isn't necessarily the correct file if /etc/nullmailer is a symlink.

Also, printing messages to /dev/console isn't terribly useful in the case of remote headless servers.

I suggest the following changes:

1. in order to avoid violating the principle of least surprise, don't disregard /etc/nullmailer/me. If it's there, the admin put it there for a reason.

2. if /etc/nullmailer/me doesn't exist, default to "/etc/mailname", not "/etc/nullmailer/../mailname".

3. if these two changes are made, the message becomes unnecessary and can be a simple README.Debian item.

4. if you must print a message, log it to syslog instead of (or, if you insist, in addition to) writing it to /dev/console. However, can't writing to /dev/console block e.g. due to flow control on the terminal device? If so, I'd leave /dev/console alone.

Best regards,

András

Andras Korn <korn-debbugs@elan.rulez.org> writes:

I don't know if it's practical for you, but as a workaround etckeeper
works fine with the current nullmailer, since it doesn't use symlinks.

I don't (yet) see what is explicitely opening /dev/console. How are you
starting nullmailer? For example, I would expect systemd to capture
stdout. Although README.Debian mentions /dev/console, this patching to
change upstream's logging is no longer done in the current version of
nullmailer.

I would have to go back and read the (ancient) bugs for why this change
was made in the first place. I guess allowing /etc/nullmailer/me to
override /etc/mailname will break some existing configurations.

Offhand I don't understand why it doesn't use an absolute path
there. Maybe someone (tm) can change the appropriate line in hostname.cc
and test the result.

Thanks for the suggestion, but no, it's not practical.

I'm running nullmailer-send via runit. stdout is definitely a pipe (and so is stderr); somewhere it opens /dev/console explicitly.

My runit 'run' script for nullmailer is:

--- >8 ---
#!/bin/sh
exec 2>&1
if [ ! -c /var/spool/nullmailer/trigger ]; then
        rm -f /var/spool/nullmailer/trigger
        mkfifo /var/spool/nullmailer/trigger
fi
chown mail:root /var/spool/nullmailer/trigger
chmod 0622 /var/spool/nullmailer/trigger
exec chpst -u mail nullmailer-send
--- 8< ---

In other instances, I start nullmailer-send from cron to process its queue every once in a while, using this script:

--- >8 ---
#!/bin/sh
trigger=/var/spool/nullmailer/trigger
[ -r /etc/nullmailer/pausetime ] || exit 0
[ -x /usr/sbin/nullmailer-send ] || exit 0
if [ "$(cat /etc/nullmailer/pausetime)" = "0" ]; then
        rm -f /service/nullmailer-send
        if [ ! -c $trigger ]; then
                [ -e $trigger ] && rm -f $trigger
                mkfifo $trigger
        fi
        chown mail:root $trigger
        chmod 0622 $trigger
        exec chpst -L /var/lock/nullmailer-oneshot.lock nullmailer-send -s >/dev/null 2>&1
else
        exit 0
fi
--- 8< ---

I suppose that's possible; but since nullmailer has been printing warnings about this file all this time, it would be my guess that not many people have it.

Well, that at least is easy. In debian/patches/0005-Provide-for-etc-mailname.patch, you have:

diff --git a/lib/hostname.cc b/lib/hostname.cc
index 5a7bde2..ac94ffc 100644
--- a/lib/hostname.cc
+++ b/lib/hostname.cc
@@ -24,6 +24,7 @@
 #include "configio.h"
 #include "hostname.h"
 #include "canonicalize.h"
+#include "fdbuf/fdbuf.h"

 mystring me;
 mystring defaulthost;
@@ -33,7 +34,13 @@ void read_hostnames()
 {
   int nome;
   nome = 0;
-  if (!config_read("me", me)) {
+  // introduced as bugfix for #120660, #157259, #158412 in 1.00RC5-17;
+  // still there since it's more appropriate for Debian systems
+  mystring disregard;
+  if (config_read("me", disregard)) {
+    ferr << "Warning: On Debian systems, nullmailer's 'me' is disregarded; please use '/etc/mailname' instead." << endl;
+  }
+  if (!config_read("../mailname", me)) {
     nome = 1;
     me = "me";
   }
diff --git a/test/functions.in b/test/functions.in
index bc62b67..9f8c922 100644
--- a/test/functions.in
+++ b/test/functions.in
@@ -154,6 +154,6 @@ EOF

 export PATH=/bin:/usr/bin:/usr/local/bin
 rm -f $SYSCONFDIR/*
-echo f.q.d.n >$SYSCONFDIR/me
+echo f.q.d.n >$SYSCONFDIR/../mailname
 echo q.d.n >$SYSCONFDIR/defaultdomain
 set -e

I don't know what 'ferr' is, but whatever it is, it seems to be responsible for opening /dev/console.

András

Andras Korn <korn-debbugs@elan.rulez.org> writes:

If so, it does so in a somewhat non-obvious way, since the only mention
of /dev/console in the source is in README.Debian. As far as I can tell,
ferr is a buffer object opened on file descriptor 2.

I know where the code is changed, but I'm hoping for more understanding
/ analysis of why it is the way it is, since it long predates my taking
over maintenence.