On Mon, Sep 09, 2013 at 01:54:32AM +0200, Jérémie Courrèges-Anglas wrote:
> 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?
I would say it was a local issue on my host, it was working fine for
some time then corrupting the file or doing an I/O error which might be
due to fs problems. It was not happenning when feeding tons of spam &
ham in a row, but was happening randomly later on when dspam was being
passed incoming mails by fdm.
[Sun Jun 2 05:45:06 2013] 22702: disk I/O error: SELECT
spam_learned,innocent_learned,spam_misclassified,innocent_misclassified,spam_corpusfed,innocent_corpusfed,spam_classified,innocent_classified
FROM dspam_stats
Tried recreating the sqlite file several times and the problem always
came back; but didnt try replicating it on another host.
> > 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).
Darn. Good catch, indeed it works much better this way.
> 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.
I will patch dspam.conf the way debian does (ie defaulting tcp port to
2424) so that it doesnt need root privileges to listen on a < 1024 port.
Landry
