Bug#1038158: Uses /etc/nullmailer/../mailname instead of /etc/mailname; misleading message
Andras Korn writes: > > I'm running nullmailer-send via runit. stdout is definitely a pipe (and so is > stderr); somewhere it opens /dev/console explicitly. > 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. > >> > 2. if /etc/nullmailer/me doesn't exist, default to "/etc/mailname", >> > not "/etc/nullmailer/../mailname". >> >> 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. > > Well, that at least is easy. In > debian/patches/0005-Provide-for-etc-mailname.patch, you have: 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.
Bug#1038158: Uses /etc/nullmailer/../mailname instead of /etc/mailname; misleading message
On Wed, Jun 21, 2023 at 10:18:13AM +0300, David Bremner wrote:
> > 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 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.
Thanks for the suggestion, but no, it's not practical.
> > Also, printing messages to /dev/console isn't terribly useful in the
> > case of remote headless servers.
>
> 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'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< ---
> > 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.
>
> 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.
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.
> > 2. if /etc/nullmailer/me doesn't exist, default to "/etc/mailname",
> > not "/etc/nullmailer/../mailname".
>
> 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.
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
Bug#1038158: Uses /etc/nullmailer/../mailname instead of /etc/mailname; misleading message
Andras Korn writes: > 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 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. > Also, printing messages to /dev/console isn't terribly useful in the > case of remote headless servers. 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. > 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. 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. > 2. if /etc/nullmailer/me doesn't exist, default to "/etc/mailname", > not "/etc/nullmailer/../mailname". 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.
Bug#1038158: Uses /etc/nullmailer/../mailname instead of /etc/mailname; misleading message
Package: nullmailer Version: 1:2.2-3+b1 Severity: normal 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/etc/nullmailer/me> read(3/etc/nullmailer/me>, "my-correct-hostname-here\n", 4096) = 27 close(3/etc/nullmailer/me>) = 0 write(2>, "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 -- Mishearing the voices in his head, our hero wonders how he's supposed to kill the mall.
