Frank Cusack wrote:
> No responses? I'd have thought this would be a simple enough question.
> What is dspam_clean for and what is correct maintenance when using
> the hash driver?
The README (3.6.8) states that...
[snip]
6. NIGHTLY MAINTENANCE AND HOUSEKEEPING CRONS
Non-SQL Based Nightly Purge
If you are NOT running a SQL-based solution, then you should
configure dspam_clean to run under cron nightly. This clean
tool will read all signature databases and purge signatures
that are older than 14 days (configurable), purge abandoned
tokens, and remove unimportant tokens. Without this tool, old
signatures will continue to pile up. Be sure the user running
cleanup has full read/write permissions on the DSPAM data files.
[snip]
...so I'd say that the dspam_clean *is* for hash, or at least
that's my understanding. I'm new to dspam and I'm just testing
out basic functionality, haven't gotten to the dspam_clean yet.
R
/Lars
> -frank
>
> On January 11, 2007 12:30:24 PM -0800 Frank Cusack <[EMAIL PROTECTED]>
> wrote:
>> To bring back a thread from a little more than a year ago, it was
>> reported that for dspam compiled with only the hash driver on an
>> SMP box, dspam_clean would segv sometimes. Clearly a fault in
>> dspam_clean, and I am seeing it but on Solaris 10 x86 SMP, not
>> debian as the original reporter did.
>>
>> Thread starts here:
>> <http://dspam.nuclearelephant.com/dspam-users/0963.html>
>>
>> Jonathan says dspam_clean is not for hash, that instead cssclean
>> should be used. And that to clean up old sigs, find|rm should be
>> used. I found the FAQ entry which says to use cssclean and csscompress
>> for the hash driver. OK.
>>
>> BUT ... the actual documentation that comes with dspam says nothing
>> about cssclean/csscompress (that I can find), and furthermore the
>> README (section 6) says:
>>
>> If you are NOT running a SQL-based solution, then you should
>> configure
>> dspam_clean to run under cron nightly.
>>
>> Now, I'd accept that the README might be wrong or out of date, hey even
>> the table of contents at the start of it is wrong, but since the hash
>> driver
>> is the only non-SQL-based solution, then you can just translate that
>> sentence to "If you are using the hash driver, run dspam_clean." Since
>> this is such a direct contradiction to the cssclean advice, I want
>> to verify what is correct for the hash driver, and if it should be
>> just cssclean, then what is dspam_clean for?
>>
>> I am running dspam-3.6.8. It works fine on a Solaris 10 sparc SMP box.
>> On the x86 box with the problem, it's just one user that it fails on.
>>
>> # dspam_clean -s -p -u
>> dspam_clean startingPROCESSING USER: [EMAIL PROTECTED]
>> Processing sigs; age: 14
>> Processing probabilities; age: 90
>> Processing unused; any: 90 quota: 30 nospam: 15 onehit: 15
>> PROCESSING USER: [EMAIL PROTECTED]
>> ...
>> PROCESSING USER: [EMAIL PROTECTED]
>> Processing sigs; age: 14
>> Processing probabilities; age: 90
>> zsh: segmentation fault (core dumped) dspam_clean -s -p -u
>>
>> I can provide the dspam sigs and other info for testing/debugging.
>>
>> I have slightly modified my dspam to always include the X-DSPAM-User
>> header, due to virtual hosting. That doesn't seem to be a problem
>> area that might trigger the dspam_clean bug, AFAICT.
>>
>> -frank
>
