Landry Breuil <lan...@rhaalovely.net> writes:
[...]
>> New version with :
>> - rc script for dspam --daemon
>> - var/run/dspam @sampled for the daemon to start fine
>> - and (courtesy of sthen@, many thanks!) a PFRAG.* + FULLPKGPATH-* +
>> @pkgpath dance that would allow all combinations of pkgpaths to
>> update seamlessly. One would need to manually install dspam-*-{my,pg}sql
>> if they were using such a backend, but that will go to upgrade.html
>> (and/or to a MESSAGE) since manual intervention to update the db schema
>> is needed anyway.
>> - no need for a pkg README, the one provided by upstream is already
>> complete enough
>> - sqlite2 flavor really dies, what's the point when we have sqlite3 in
>> base..
Great!
>> running in production here with sqlite3. This one should be good to go
>> (minus the upgrade.html/MESSAGE part)
>
> Reviving this -- at that time i had some issues with the sqlite3 backend
> which was corrupting its db, since then i've switched to use a pgsql
> backend and its been working fine.
That sucks... if that isn't/can't be fixed, shouldn't it at least be
documented?
> Only remaining interrogation - i'm unable to make it start properly if
> using daemon_user='_dspam' in the rc script. Even when disabling the tcp
> port (by default it wants to listen on 24/tcp) and using an unix socket,
> it doesnt want to start (seems stuck before any real initialization) and
> ktrace doesnt give a lot of clues. Running it as root works. *shrug*.
That's because you left "trusted user security" enabled but did not add
...
Trust _dspam
...
to the config file. Since _dspam user isn't trusted it can't choose the
operation mode and thus --daemon is ignored (thus dspam stays stuck
reading on stdin). This should either be documented in a README-main or
patched (better imho since some "Trust" entries should probably be
deactivated).
I was not aware that the default setup on OpenBSD involved dspam running
as root, that sucks. Making it run properly under the _dspam uid by
default will probably require some efforts and some documentation bits,
MESSAGE is probably not enough for this.
> Added from the previous diff a fix for a runtime issue with pg >= 9.1,
> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694942,
> http://sourceforge.net/p/dspam/bug-tracker/141/ and
> http://sourceforge.net/p/dspam/bug-tracker/112/ for the first chunk of
> pgsql_drv.c patch.
>
> Anyone testing this or having a clue at why it wouldnt start with a
> dedicated unpriviledged user ? That would be a step forward from the
> current state of things...
>
> oks welcome too.
Hmm, I'll try to set it up with and test it with hash storage backend,
even though I don't receive much spam. The sqlite3 problem saddens me,
though. (IIRC the sqlite3 backend could stand a larger load than the hash
backend, and was much faster than the PostgreSQL one).
Ciao,
--
jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
