Re: sa-learn issues
On Mar 31, 2005 5:46 PM, AltGrendel <[EMAIL PROTECTED]> 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
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
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//.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 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//.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
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. pgppL9kGtH8D9.pgp Description: PGP signature
Re: sa-learn issues
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//.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
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//.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 pgpbeEbvUpSUj.pgp Description: PGP signature
Re: sa-learn issues
>> 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*
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
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
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.