Devin Carraway wrote:
On Tue, Aug 23, 2005 at 12:17:32AM -0400, Bob Dodds wrote:
A per plugin deb or rpm could install into qpsmtpd with
minimal meddling that way. Maintaining debs rpms for
qpsmtpd installs with a given set of plugins would be
easy to maintain without scripting edits of config/plugins.
It can anyway, even without having qpsmtpd check the config path where it
found the reference to the plugin. Being able to $include a directory, e.g.
/etc/qpsmtpd/plugins.d/, allows supplemental plugin packages to configure
themselves. Plugins installed from the package manager, moreover, are free to
install themselves in /usr/share/qpsmtpd/plugins/ alongside qpsmtpd's own, a
situation which doesn't even require multiple plugin dirs.
Writing code to edit a system config file after an admin has been in there is
a treacherous affair, and most package maintainers try strenuously to avoid
it. The approach I've taken with the Debian packaging is to store all the
auto-config and debconf-configured files in separate clobbered-on-install
files and $include them into the main config with an explanation of their
function and how to disable the automatic config.
I have always used debian, originally from a floppy
image download. I have cyrus22 src deb from alioth in
order to have virtual domains(cyrus21 lmtp didn't).
I replaced my last windows installation with ubuntu,
which is a debian-based free downloadable cd or
dvd image(if someone doesn't know), a couple of
weeks ago.
Is your $include different than Matt's $Include, and
where are they set?
Do you need a package manager plugin to run by
config/plugins? plugins.d would set all config vars but
I need to know if qpsmtpd would run plugins not listed
in config/plugins if they had a file in plugins.d and if
there is anything like sys5 style plugins.d/S05plugin to
determine loading order like config/plugins determines
loading order. Also extra path like [plugins/]auth etc.
could be expressed by plugins.d/auth/plugin or
plugins.d/auth/S05plugin
Believe it or not an ipc_dirqueue plugin would appreciate
a signal on shutdown plugins.d/queue/K01ipc_dirqueue
but I think it's on its own there because it's actually the
work queues on other pc's that could use a kill signal
so they could try to release nfs locks in the master
nfs ipc_dirqueue control directory. Forget that but
sys5 S0* hook load ordering is of general interest. Like
to insure SRS de-aliasing before other rcpt hooks. And
to add to the madness, communicate whether it has
to be blocking or can run in parallel with other hooks!
Then S* could say serial and order for blocking, and P0
for parallel. Or the plugins.d/hook/file could say
block=[-1-99] instead, with -1 meaning parallel.
Default DECLINED is not always a substitute there.
-Bob
