You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Mark <ad...@asarian-host.net> on 2006/10/06 02:12:05 UTC

Upgrading from SpamAssassin 2.55

Hello,

I'm finally upgrading from SpamAssassin 2.55 (tweaked myself, over time)
to 3.1.6. I have a few questions regarding this upgrade.

In the "old" SA, I had a file called ConfSourceSQL.pm, which did the
per-user stuff for MySQL. I cannot seem to find a similar file in
function. I see BayesStore/MySQL.pm, but that's not what I'm looking for
(I just want the file that retrieves the per-user MySQL settings).

I also read somewhere that you can no longer parse the -u option to spamc.
I cannot say I like that. I have an LDA that runs as root (of course),
that calls spamc for the user associated with the recipient in question.
One could make a system call, like this:

system ("/usr/bin/su $user -c /path-to-spamc");

But that only works for users who have actual shell accounts (most of my
users just have mail accounts). But I rather have the -u option to spamc
back. :) So, any way to call spamc for separate users with a "fixed" UID?

Thanks,

- Mark


RE: Upgrading from SpamAssassin 2.55

Posted by Mark <ad...@asarian-host.net>.
> -----Original Message-----
> From: Matt Kettler [mailto:mkettler_sa@verizon.net]
> Sent: vrijdag 6 oktober 2006 4:33
> To: Mark
> Cc: users@spamassassin.apache.org
> Subject: Re: Upgrading from SpamAssassin 2.55

Wow; that was a very comprehensive and useful answer. :) Part of the
reason I've been postponing the upgrade is because my setup relies
on the -u functionality of spamc.

Thanks.

- Mark


> Mark wrote:
>
> > Hello,
> >
> > I'm finally upgrading from SpamAssassin 2.55 (tweaked
> > myself, over time)
> > to 3.1.6. I have a few questions regarding this upgrade.
> >
> > In the "old" SA, I had a file called ConfSourceSQL.pm, which did the
> > per-user stuff for MySQL. I cannot seem to find a similar file in
> > function. I see BayesStore/MySQL.pm, but that's not what
> > I'm looking for
> > (I just want the file that retrieves the per-user MySQL settings).
> >
> > I also read somewhere that you can no longer parse the -u
> > option to spamc.
> 
> Parse? or pass? You can still pass -u to spamc. That's not changed in
> any way I'm aware of from 2.55 to 3.1.6.
>
> According to the docs you shouldn't use -u to cause spamc's
> environment
> (ie: where ~/ is), but I say that's nothing but shenanigans. Your
> version of spamassassin says the same thing. Check the spamc
> manpage on
> your system..
>
> The spamc docs have claimed -u is "semi obsoleted"  and you should su
> first for a very long time. In fact, the docs for this
> argument haven't
> changed since at least 2.40. I say it's a crock.
>
> Someone implemented reading the current userid a long time
> ago and then
> updated the docs in order to proclaim this as the only proper way. As
> time has gone on, spamc -u has gotten more useful, not less. SA now
> supports virtual users who only have SQL stored configurations. How's
> that work if you shouldn't use -u?
>
> I'd ignore this aspect of the docs as outdated rubbish made by someone
> who envisioned the "new" feature as causing -u to eventually go away.
> That's never come to pass, and probably never will.
>
> That said, if your user is su'able, there's no reason to not
> su first..
> but you could use -u if you wanted.
>
> Some evidence:
>
> SA 2.40's spamc manpage (lifted from a freshly downloaded
> tarball from cpan)
> ---------------
> item -u username
>
> This argument has been semi-obsoleted. To have spamd use
> per-user-config
> files, run spamc as the user whose config files spamd should load. If
> you're
> running spamc as some other user, though, (eg. root, mail, nobody,
> cyrus, etc.)
> then you can still use this flag.
> ---------------
>
> SA 2.50's spamc man page (lifted from a local tarball)
> ---------------
> item -u username
>
> This argument has been semi-obsoleted. To have spamd use
> per-user-config
> files, run spamc as the user whose config files spamd should load. If
> you're
> running spamc as some other user, though, (eg. root, mail, nobody,
> cyrus, etc.)
> then you can still use this flag.
> ---------------
>
> SA 3.1.0's man page, lifted from
> http://spamassassin.apache.org/full/3.1.x/dist/doc/spamc.html
>
> ---------------
>
> **-u* /username/*
>
>     This argument has been semi-obsoleted. To have spamd use
>     per-user-config files, run spamc as the user whose config files
>     spamd should load. If you're running spamc as some other user,
>     though, (eg. root, mail, nobody, cyrus, etc.) then you
>     can still use this flag.
>
> ---------------


Re: Upgrading from SpamAssassin 2.55

Posted by Matt Kettler <mk...@verizon.net>.
Mark wrote:
> Hello,
>
> I'm finally upgrading from SpamAssassin 2.55 (tweaked myself, over time)
> to 3.1.6. I have a few questions regarding this upgrade.
>
> In the "old" SA, I had a file called ConfSourceSQL.pm, which did the
> per-user stuff for MySQL. I cannot seem to find a similar file in
> function. I see BayesStore/MySQL.pm, but that's not what I'm looking for
> (I just want the file that retrieves the per-user MySQL settings).
>
> I also read somewhere that you can no longer parse the -u option to spamc.
>   
Parse? or pass? You can still pass -u to spamc. That's not changed in
any way I'm aware of from 2.55 to 3.1.6.

According to the docs you shouldn't use -u to cause spamc's environment
(ie: where ~/ is), but I say that's nothing but shenanigans. Your
version of spamassassin says the same thing. Check the spamc manpage on
your system..

The spamc docs have claimed -u is "semi obsoleted"  and you should su
first for a very long time. In fact, the docs for this argument haven't
changed since at least 2.40. I say it's a crock.

Someone implemented reading the current userid a long time ago and then
updated the docs in order to proclaim this as the only proper way. As
time has gone on, spamc -u has gotten more useful, not less.  SA now
supports virtual users who only have SQL stored configurations. How's
that work if you shouldn't use -u?

I'd ignore this aspect of the docs as outdated rubbish made by someone
who envisioned the "new" feature as causing -u to eventually go away.
That's never come to pass, and probably never will.

That said, if your user is su'able, there's no reason to not su first..
but you could use -u if you wanted.


Some evidence:

SA 2.40's spamc manpage (lifted from a freshly downloaded tarball from cpan)
---------------
item -u username

This argument has been semi-obsoleted.  To have spamd use per-user-config
files, run spamc as the user whose config files spamd should load.  If
you're
running spamc as some other user, though, (eg. root, mail, nobody,
cyrus, etc.)
then you can still use this flag.
---------------

SA 2.50's spamc man page (lifted from a local tarball)
---------------
item -u username

This argument has been semi-obsoleted.  To have spamd use per-user-config
files, run spamc as the user whose config files spamd should load.  If
you're
running spamc as some other user, though, (eg. root, mail, nobody,
cyrus, etc.)
then you can still use this flag.
---------------

SA 3.1.0's man page, lifted from
http://spamassassin.apache.org/full/3.1.x/dist/doc/spamc.html

---------------

**-u* /username/*

    This argument has been semi-obsoleted. To have spamd use
    per-user-config files, run spamc as the user whose config files
    spamd should load. If you're running spamc as some other user,
    though, (eg. root, mail, nobody, cyrus, etc.) then you can still use
    this flag.

---------------




> I cannot say I like that. I have an LDA that runs as root (of course),
> that calls spamc for the user associated with the recipient in question.
> One could make a system call, like this:
>
> system ("/usr/bin/su $user -c /path-to-spamc");
>
> But that only works for users who have actual shell accounts (most of my
> users just have mail accounts). But I rather have the -u option to spamc
> back. :) So, any way to call spamc for separate users with a "fixed" UID?
>
> Thanks,
>
> - Mark
>
>
>