sa-learn issues

[Chip <ch...@ninjabucket.com>]

I recently installed SA 3.0.2 on freeBSD 4.10, and it's working great, 
except for this one feature:

I have things setup so each user has a spam folder that they will put 
missed spam in.  This folder will later be trained from cron jobs using 
sa-learn.  The problem is, it seems that sa-learn is ignoring the -u / 
--user= flag.  No matter what I set it to, it trains for root instead of 
that user.  I am verifying this by checking the /root/.spamassassin/ 
directory.  Each time I run sa-learn, the bayes files in the directory 
are updated, instead of the files in /usr/home/<user>/.spamassassin/

bash-2.05b# /usr/local/bin/sa-learn -u userfoo --spam --showdots --mbox 
/usr/home/chip/SPAM
..
Learned from 2 message(s) (2 message(s) examined).
bash-2.05b# /usr/local/bin/sa-learn -u userbar --spam --showdots --mbox 
/usr/home/chip/SPAM
..
Learned from 0 message(s) (2 message(s) examined)

I have tried the following user flags:

--user=userfoo
--user="userfoo"
--user='userfoo'
-u userfoo
-u "userfoo"
-u 'userfoo'

Any idea what I am missing here?

Re: sa-learn issues

[Andre Nicholson <an...@neo-anime.org>]

>> The problem is, it seems that sa-learn is ignoring the -u / --user= flag.
>
> Of course it's ignoring it. There is no -u flag in sa-learn. ONLY spamc
> and spamd accept that flag.
>
> sa-learn uses the userid of the user that calls it. Period.

>From TFM:

-u username, --username=username Override username taken from the runtime environment

Andre

Re: sa-learn issues *RETRACTED*

[Matt Kettler <mk...@evi-inc.com>]

My bad, apparently 3.0.2 and 3.0.1 do have such a flag in sa-learn. I
was looking at the 3.0.0 version, which does not.

Matt Kettler wrote:

>Chip wrote:
>
>  
>
>>The problem is, it seems that sa-learn is ignoring the -u / --user= flag.
>>    
>>
>
>Of course it's ignoring it. There is no -u flag in sa-learn. ONLY spamc
>and spamd accept that flag.
>
>sa-learn uses the userid of the user that calls it. Period.
>
>  
>

Re: sa-learn issues

[Chip <ch...@ninjabucket.com>]

Matt Kettler wrote:

>Chip wrote:
>
>  
>
>>The problem is, it seems that sa-learn is ignoring the -u / --user= flag.
>>    
>>
>
>Of course it's ignoring it. There is no -u flag in sa-learn. ONLY spamc
>and spamd accept that flag.
>
>sa-learn uses the userid of the user that calls it. Period.
>  
>
man sa-learn says differently:

 -u username, --username=username  Override username taken from the 
runtime environment

However if this is the case, how do you use spamc to train spam on a 
users mbox?

Re: sa-learn issues

[Bart Schaefer <ba...@gmail.com>]

On Mar 31, 2005 5:46 PM, AltGrendel <al...@exit0.us> wrote:
> Matt Kettler wrote:
> 
> >>The problem is, it seems that sa-learn is ignoring the -u / --user= flag.
> >
> >sa-learn uses the userid of the user that calls it. Period.
> 
> Then why does man sa-learn show a -u flag:
> 
> Is this obsolete?

It's not obsolete, but it's incomplete.  Changing the userid does not
change the location that sa-learn uses for the bayes databases, and
although you can specify an alternat config file path, the user-level
config file is not allowed to change the bayes database location.

So for virtual users you must actually set the HOME environment
variable to point to the correct location before running sa-learn, and
*also* use the -u option to set the userid; and of course the real
user running sa-learn must have write permission for the bayes files
and for the $HOME/.spamassassin directory (to create lock files).

I ended up making a setuid (to the "spamassassin" user) copy of
sa-learn and a wrapper script for running it.

Re: sa-learn issues

[AltGrendel <al...@exit0.us>]

Matt Kettler wrote:

>Chip wrote:
>
>  
>
>>The problem is, it seems that sa-learn is ignoring the -u / --user= flag.
>>    
>>
>
>Of course it's ignoring it. There is no -u flag in sa-learn. ONLY spamc
>and spamd accept that flag.
>
>sa-learn uses the userid of the user that calls it. Period.
>  
>
No offence meant here.

Then why does man sa-learn show a -u flag:

       -u username, --username=username
           If specified this username will override the username taken from
           the runtime environment.  You can use this option to specify 
users
           in a virtual user configuration.


Is this obsolete?

Re: sa-learn issues

[Matt Kettler <mk...@evi-inc.com>]

Chip wrote:

> The problem is, it seems that sa-learn is ignoring the -u / --user= flag.

Of course it's ignoring it. There is no -u flag in sa-learn. ONLY spamc
and spamd accept that flag.

sa-learn uses the userid of the user that calls it. Period.

Re: sa-learn issues

[Michael Parker <pa...@pobox.com>]

On Thu, Mar 31, 2005 at 02:24:23PM -0500, Chip wrote:
> Ahh ok.  Make sense!  I will change to a sql backend, as my users have 
> no shell access and can't run the command as themselves.  Thanks for the 
> clarification!

Not a bad idea.  The Bayes SQL modules have proven to be stable and in
most cases worth the effort, especially in a virtual user environment.

You can find some more information on storing your SpamAssassin user
data in a SQL database here:
http://people.apache.org/~parker/presentations/

Michael

PS Anyone interested in testing a MySQL specific Bayes Storage module?
It requires MySQL 4.1, SA 3.1-dev and InnoDB tables if you want
rollback on error.  It also provides a 30-40% speed up in some cases.
If so, shoot me an email and I'll send you a copy of the module.

Re: sa-learn issues

[Chip <ch...@ninjabucket.com>]

Chip wrote:

> Michael Parker wrote:
>
>> On Thu, Mar 31, 2005 at 01:23:24PM -0500, Chip wrote:
>>  
>>
>>> I have things setup so each user has a spam folder that they will 
>>> put missed spam in.  This folder will later be trained from cron 
>>> jobs using sa-learn.  The problem is, it seems that sa-learn is 
>>> ignoring the -u / --user= flag.  No matter what I set it to, it 
>>> trains for root instead of that user.  I am verifying this by 
>>> checking the /root/.spamassassin/ directory.  Each time I run 
>>> sa-learn, the bayes files in the directory are updated, instead of 
>>> the files in /usr/home/<user>/.spamassassin/
>>>   
>>
>>
>> This is a feature/shortcoming in the -u option for sa-learn when using
>> non-SQL based bayes storage modules.  That is why the documentation
>> states:
>>  You can use this option to specify users in a virtual user
>>  configuration.
>>
>> Otherwise the bayes path, if unset via dbpath or in a .cf file is
>> expanded to be in $ENV{HOME} which in your case is /root/.
>>
>> I added the -u specifically for BayesSQL users, since it doesn't refer
>> to an actual directory on the filesystem.
>>
>> Feel free to file a bug report, but honestly it might end up being a
>> documentation patch saying that -u is not effective for DBM storage.
>>
>> BTW, you can easily accomplish the same thing as root using su -c or
>> similar mechanisms.
>>
>> Michael
>>  
>>
> Ahh ok.  Make sense!  I will change to a sql backend, as my users have 
> no shell access and can't run the command as themselves.  Thanks for 
> the clarification!


Changing the backend storage driver worked perfectly, well almost.  When 
using DBM storage, the user_prefs file was automatically created when a 
new user got its first mail.  Now using mySQL, the userpref table is 
empty.  Is this the default behavior?  Reason I ask is with no examples 
of what to put in the table, I am unsure of the syntax ;)

Re: sa-learn issues

[Chip <ch...@ninjabucket.com>]

Chip wrote:

> Michael Parker wrote:
>
>> On Thu, Mar 31, 2005 at 01:23:24PM -0500, Chip wrote:
>>  
>>
>>> I have things setup so each user has a spam folder that they will 
>>> put missed spam in.  This folder will later be trained from cron 
>>> jobs using sa-learn.  The problem is, it seems that sa-learn is 
>>> ignoring the -u / --user= flag.  No matter what I set it to, it 
>>> trains for root instead of that user.  I am verifying this by 
>>> checking the /root/.spamassassin/ directory.  Each time I run 
>>> sa-learn, the bayes files in the directory are updated, instead of 
>>> the files in /usr/home/<user>/.spamassassin/
>>>   
>>
>>
>> This is a feature/shortcoming in the -u option for sa-learn when using
>> non-SQL based bayes storage modules.  That is why the documentation
>> states:
>>  You can use this option to specify users in a virtual user
>>  configuration.
>>
>> Otherwise the bayes path, if unset via dbpath or in a .cf file is
>> expanded to be in $ENV{HOME} which in your case is /root/.
>>
>> I added the -u specifically for BayesSQL users, since it doesn't refer
>> to an actual directory on the filesystem.
>>
>> Feel free to file a bug report, but honestly it might end up being a
>> documentation patch saying that -u is not effective for DBM storage.
>>
>> BTW, you can easily accomplish the same thing as root using su -c or
>> similar mechanisms.
>>
>> Michael
>>  
>>
> Ahh ok.  Make sense!  I will change to a sql backend, as my users have 
> no shell access and can't run the command as themselves.  Thanks for 
> the clarification!

Re: sa-learn issues

[Chip <ch...@ninjabucket.com>]

Michael Parker wrote:

>On Thu, Mar 31, 2005 at 01:23:24PM -0500, Chip wrote:
>  
>
>>I have things setup so each user has a spam folder that they will put 
>>missed spam in.  This folder will later be trained from cron jobs using 
>>sa-learn.  The problem is, it seems that sa-learn is ignoring the -u / 
>>--user= flag.  No matter what I set it to, it trains for root instead of 
>>that user.  I am verifying this by checking the /root/.spamassassin/ 
>>directory.  Each time I run sa-learn, the bayes files in the directory 
>>are updated, instead of the files in /usr/home/<user>/.spamassassin/
>>    
>>
>
>This is a feature/shortcoming in the -u option for sa-learn when using
>non-SQL based bayes storage modules.  That is why the documentation
>states:
>  You can use this option to specify users in a virtual user
>  configuration.
>
>Otherwise the bayes path, if unset via dbpath or in a .cf file is
>expanded to be in $ENV{HOME} which in your case is /root/.
>
>I added the -u specifically for BayesSQL users, since it doesn't refer
>to an actual directory on the filesystem.
>
>Feel free to file a bug report, but honestly it might end up being a
>documentation patch saying that -u is not effective for DBM storage.
>
>BTW, you can easily accomplish the same thing as root using su -c or
>similar mechanisms.
>
>Michael
>  
>
Ahh ok.  Make sense!  I will change to a sql backend, as my users have 
no shell access and can't run the command as themselves.  Thanks for the 
clarification!

Re: sa-learn issues

[Michael Parker <pa...@pobox.com>]

On Thu, Mar 31, 2005 at 01:23:24PM -0500, Chip wrote:
> I have things setup so each user has a spam folder that they will put 
> missed spam in.  This folder will later be trained from cron jobs using 
> sa-learn.  The problem is, it seems that sa-learn is ignoring the -u / 
> --user= flag.  No matter what I set it to, it trains for root instead of 
> that user.  I am verifying this by checking the /root/.spamassassin/ 
> directory.  Each time I run sa-learn, the bayes files in the directory 
> are updated, instead of the files in /usr/home/<user>/.spamassassin/

This is a feature/shortcoming in the -u option for sa-learn when using
non-SQL based bayes storage modules.  That is why the documentation
states:
  You can use this option to specify users in a virtual user
  configuration.

Otherwise the bayes path, if unset via dbpath or in a .cf file is
expanded to be in $ENV{HOME} which in your case is /root/.

I added the -u specifically for BayesSQL users, since it doesn't refer
to an actual directory on the filesystem.

Feel free to file a bug report, but honestly it might end up being a
documentation patch saying that -u is not effective for DBM storage.

BTW, you can easily accomplish the same thing as root using su -c or
similar mechanisms.

Michael