The config-test script verifies that the log file exists and is writable,
but does not check whether the directory containing it can be written, for
locking. (To a novice like me, it's tempting to just put the Majordomo
log file in /var/log with suitable file permissions, but that naturally
doesn't work -- Majordomo doesn't have write permissions on /var/log.)
In itself, this is a relatively minor problem, and it's not like the docs
don't prominently warn about permission problems! The bad part of this
one is that when you get it wrong, *and* you botch something else -- in
this case it was the old BSDI "mail" command not putting a full user@host
in the From header -- what you get in mail when you do INSTALL step 10 is:
MAJORDOMO ABORT (mj_majordomo)!!
and that's *all*. No indication of what the problem was, none whatsoever.
It tried to log the user@host problem, found it couldn't, and just keeled
over. Majordomo 1.94.5, BSDI 2.1 (yeah, it's old...), sendmail 8.9.3.
Either problem by itself is trivial and produces reasonably informative
error messages, but the combination is ugly.
Config-test should do everything it can to ensure that Majordomo will at
least get far enough to diagnose and report its problems. In particular,
config-test ought to check *everything* needed for successful logging,
not just the log file's permissions. Ideally, it should try to actually
make a log entry, and carefully report any problems encountered.
Majordomo's logging/reporting code is capable of giving an intelligible
message to the user about inability to lock the log file, but doesn't
manage to do so if the problem is discovered while trying to report
another problem. This is bad.
Henry Spencer
henry@spsystems.net
|
|
