On Fri Apr 25, 2008 at 11:13:09 +0200, Peter J. Holzer wrote:
> > I use a singleton module to gain access to the DBI instance,
>
> That's a good idea.
I tend to use singletons pretty exclusively for DBI, project-wide
config file handling, and the use of Danga's memcached (which really
rocks if you're using DBI).
> Well, qpsmtpd doesn't create the connection, your plugin does.
Indeed.
> DBI connections generally cannot be shared between processes (not even for
> selects, if it worked for you, you were just lucky), so you need to make
> sure you don't create the connection before the connect hook.
I don't, thankfully.
> Or you could check for a changed pid in Singleton::DBI->instance()
> and open a new connection (*carefully* closing the old one).
That is an option. In the end I decided to just the avoid updates from
within the qpsmtpd process.
Generally my DBI queries are of the form "Does this domain want
to run antivirus?", or "does this user exist?". The updates are handled
via a web application. The only part that caused me pain was having
a database-backed IP blacklist.
Testing worked OK ( "SELECT ip,reason FROM blacklists WHERE ip=?" ),
but when I started adding updates in the mix it all broke. Instead
my blacklist system was reduced to:
Blacklisted?: if [ -e /tmp/reject/$ip ];
Reason? cat /tmp/reject/$ip
Remove: rm /tmp/reject/$ip
Add: echo "Missing reverse DNS" > /tmp/reject/$ip
Using rsync/unison I can share this state across a number of MXs
so it all worked out just fine in the end.
Steve
--
Debian GNU/Linux System Administration
http://www.debian-administration.org/
