Peter J. Holzer wrote:
On 2005-04-19 12:41:02 +0200, Peter J. Holzer wrote:
On 2004-12-15 16:07:14 -0800, Robert Spier wrote:
also, do we really need seperate plugin and config dir specifiers
if we have QPSMTPD_ROOT? What's the logic?
FHS conformance:
Plugins should go to /usr/share/qpsmtpd/plugins (or maybe /usr/lib/qpsmtpd/plugins)
Config files should go into /etc/qpsmtpd.
However, we don't necessarily need command line options for that. We already have a spool_dir configuration option, so adding a
plugins_dir configuration option would be consistent.
So I'd just extend the searchpath for the config files from
$QPSMTPD_ROOT/config:$QMAIL/control
to
$QPSMTPD_CONFIG:$QPSMTPD_ROOT/config:$QMAIL/control
and then read the plugin_dir from $config_dir/plugin_dir. (similarly for pid_file, etc.)
$QPSMTPD_CONFIG, $QPSMTPD_ROOT, $QMAIL should be read from the environment and default to sane values.
hp
$QPHOME is used in some now, otherwise known as "./"
Somebody's idea of compliance is "/opt/qpsmtpd/plugins". I don't know if /opt is catching on. The problem with all those /usr/local/ and /opt schemes is that if plugins and config are not in the qp tree, a chroot jail won't work. A chroot jail for any perl program would be a lot of work, I imagine--more libs i.e. modules than for C. qmail might use its own ./control and ./alias dirs instead of /etc for that reason, chroot jails. The tcpserver model allows for executables to be called from elsewhere initially but to have environment in its run tree, which mixes the usual etc for config, var for run, model, probably a hybrid from hell to some people.
ln -s /var/log/qpsmtpd /var/qpsmtpd/log/main or ln -s /var/log/qpsmtpd /etc/qpsmtpd/log/main is one thing I do to make something conventional. Then it takes a message-id-aware script to make sense of the log file "current"--not a ucspi tool!
-Bob Dodds
