You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Dan Mahoney, System Admin" <da...@prime.gushi.org> on 2007/08/04 00:49:58 UTC

Default Plugins?

Hello all,

I've got some stale v3xx.pre files around, and I notice that they load 
plugins that are NOT loaded by v320.pre

Is there some default mechanism loading these things (for example, I 
notice loadplugin Mail::SpamAssassin::Plugin::DKIM is only in v312.pre), 
and is it safe to remove the old ones?

I can't find a good piece of documentation on the wiki on this, would be 
happy to add it if I could get a definitive answer.

-Dan

--

"Little tramp sits in her room all day, sewing dolls!  Children
misbehaving in the basement, and one in the walls, doing his business God
knows where!  You children will be the death of me, *sniff*."

'Mommy', The People Under The Stairs


--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------


Re: [sa-list] Re: [sa-list] Re: Default Plugins?

Posted by Theo Van Dinter <fe...@apache.org>.
On Sat, Aug 04, 2007 at 07:55:06AM -0400, Dan Mahoney, System Admin wrote:
> No, but YOU (the SA team) can, in fact, list all of the modules that you 
> are shipping with a specific version of SA, in a commented (and possibly 
> commented out) version of $version.pre.

Sure, and that's exactly what we already do.  It's just that $version is the
version the plugin was first introduced.

> would be nice things too (as presumably, nothing is going to ever REMOVE 
> that old module from its installed location for those of us using the 
> make, make install method, and because SA will still read the 
> three-versions-ago command to LOAD that module.

Yeah, it's hard to remove the old plugins, though we could overwrite them with
a new version that has all the code ripped out.  It could even raise a flag
saying that the plugin is deprecated.

> Even now, there could be functionality I'm missing, simply because I 
> haven't installed every minor version in between.

If you were to upgrade from say 3.0.3 to 3.2.0, the install process will
install all of the v31x.pre files, and the plugins in 3.2.0 are inclusive of
all the ones from 3.1.x.   So you're not missing anything if you didn't
install all the ones in between.

-- 
Randomly Selected Tagline:
"When we traded it in my wife was upset because we didn't keep it long
 enough for her to buy a gun and shoot it."
         - Unknown about the Cadillac Cimarron

Re: [sa-list] Re: [sa-list] Re: Default Plugins?

Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Dan Mahoney, System Admin wrote:

> Even now, there could be functionality I'm missing, simply because I 
> haven't installed every minor version in between.

No, that's not correct.  Every version includes all of the pre files and 
plugins from every version before it.  If the pre files aren't present 
on your system they will be installed.  All of the plugins will be 
installed no matter what (your existing M::SA Perl lib directory is 
cleaned out during make install).

Daryl

Re: [sa-list] [sa-list] Default Plugins?

Posted by Kai Schaetzl <ma...@conactive.com>.
System Admin Dan Mahoney wrote on Sat, 4 Aug 2007 07:55:06 -0400 (EDT):

> '"Mail::SpamAssassin::Plugin::DomainKeys" is officialy outdated by 
"Mail::SpamAssassin::Plugin::DKIM"'
> 
> would be nice things too (as presumably, nothing is going to ever REMOVE 
> that old module from its installed location for those of us using the 
> make, make install method,

As Jason says this is all told in the INSTALL file, quite clear and in some detail. 
And, if you upgraded with make as you said you will also notice that the output of 
"perl makefile.PL" will remind you about it.

The usage of *.pre files is also explained, in the README.

It's all there. I'm just upgrading to 3.2.2 and I'm finding it very easy if I take the 
minimal amount of time to at least rush thru these files. Actually, the hint in the 
configure step is already enough to tipp you off.

Kai

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com




Re: [sa-list] Re: [sa-list] Re: Default Plugins?

Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Dan Mahoney, System Admin wrote:

> Even now, there could be functionality I'm missing, simply because I 
> haven't installed every minor version in between.

No, that's not correct.  Every version includes all of the pre files and 
plugins from every version before it.  If they're not present on your 
system they will be installed.

Daryl

Re: [sa-list] Re: [sa-list] Re: Default Plugins?

Posted by "Dan Mahoney, System Admin" <da...@prime.gushi.org>.
On Sat, 4 Aug 2007, Theo Van Dinter wrote:

> On Fri, Aug 03, 2007 at 10:59:31PM -0400, Dan Mahoney, System Admin wrote:
>>>> Is there some default mechanism loading these things (for example, I
>>>> notice loadplugin Mail::SpamAssassin::Plugin::DKIM is only in v312.pre),
>>>> and is it safe to remove the old ones?
>>
>> So then, what if, for example, nothing else had loaded
>> Mail::SpamAssassin::Plugin::DKIM?
>
> If nothing loads that plugin, then you don't get the functionality.  SA reads
> *.pre, so as long as a plugin is loaded in one of them, it's loaded.
>
>> It wasn't in the other files, even in a commented out format?
>>
>> Should there be a "Lint" of all the possible modules (and worst-case
>> scenario, I get an error if I try to load a module twice)
>
> You can't list all the possible modules, since they can live anywhere.  You
> could get a list of the standard/default modules, and any modules that an
> update channel gives you though.

No, but YOU (the SA team) can, in fact, list all of the modules that you 
are shipping with a specific version of SA, in a commented (and possibly 
commented out) version of $version.pre.

Notes in there such as:

'"Mail::SpamAssassin::Plugin::DomainKeys" is officialy outdated by "Mail::SpamAssassin::Plugin::DKIM"'

would be nice things too (as presumably, nothing is going to ever REMOVE 
that old module from its installed location for those of us using the 
make, make install method, and because SA will still read the 
three-versions-ago command to LOAD that module.

> However, I don't know what a lint would do for you.  Plugins are optional (*),
> so not loading them isn't a reportable problem.  In fact, that's one of the
> main benefits of having plugins: being able to not load certain functionality,
> reducing the amount of resources needed to run SA, etc.

Maybe I didn't mean the same thing by LINT you thought I meant?  Under 
BSD, there's a kernel config file called LINT that lists every possible 
kernel config option (even cross-incompatible ones) so you can at least 
see and grep for them all.  In older versions, this was fully commented. 
In more recent versions, it's programmatically generated, which means 
there's no nice human readable comments, but that it's more likely to be 
all-inclusive.

In the case of SA, the printing of such a message/description could come 
from the self-contained POD documentation.

While I feel it's my duty as an admin to know which modules I installed 
myself, and which were "stock" (pretty simple, based on which config file 
loads them from where, in most cases), it's only stated in the included 
docs that NEW modules are in $version.pre (which doesn't help AT ALL if I 
missed a version bump, or am installing clean).

Even now, there could be functionality I'm missing, simply because I 
haven't installed every minor version in between.

-Dan

--

"If you aren't going to try something, then we might as well just be
friends."

"We can't have that now, can we?"

-SK & Dan Mahoney,  December 9, 1998

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------


Re: [sa-list] Re: Default Plugins?

Posted by Theo Van Dinter <fe...@apache.org>.
On Fri, Aug 03, 2007 at 10:59:31PM -0400, Dan Mahoney, System Admin wrote:
> >>Is there some default mechanism loading these things (for example, I
> >>notice loadplugin Mail::SpamAssassin::Plugin::DKIM is only in v312.pre),
> >>and is it safe to remove the old ones?
> 
> So then, what if, for example, nothing else had loaded 
> Mail::SpamAssassin::Plugin::DKIM?

If nothing loads that plugin, then you don't get the functionality.  SA reads
*.pre, so as long as a plugin is loaded in one of them, it's loaded.

> It wasn't in the other files, even in a commented out format?
> 
> Should there be a "Lint" of all the possible modules (and worst-case 
> scenario, I get an error if I try to load a module twice)

You can't list all the possible modules, since they can live anywhere.  You
could get a list of the standard/default modules, and any modules that an
update channel gives you though.

However, I don't know what a lint would do for you.  Plugins are optional (*),
so not loading them isn't a reportable problem.  In fact, that's one of the
main benefits of having plugins: being able to not load certain functionality,
reducing the amount of resources needed to run SA, etc.

(*) - There are certain functions which are provided by modules which are
mandatory, such as check_main().  If SA detects that there is no plugin loaded
which provides that function, it throws a loud error and stops.  However,
since you could have multiple plugins which provide the function that you
could swap out, etc, the individual plugins aren't mandatory.

-- 
Randomly Selected Tagline:
"Never miss a good chance to shut up." - Zen Musings

Re: [sa-list] Re: Default Plugins?

Posted by "Dan Mahoney, System Admin" <da...@prime.gushi.org>.
On Fri, 3 Aug 2007, Theo Van Dinter wrote:

> On Fri, Aug 03, 2007 at 06:49:58PM -0400, Dan Mahoney, System Admin wrote:
>> I've got some stale v3xx.pre files around, and I notice that they load
>> plugins that are NOT loaded by v320.pre
>
> Of course.
>
>> Is there some default mechanism loading these things (for example, I
>> notice loadplugin Mail::SpamAssassin::Plugin::DKIM is only in v312.pre),
>> and is it safe to remove the old ones?
>
> All pre files are used.  Nothing is automatically loaded.  There are
> multiple files, based on the release where the plugins that are loaded by
> that file were in.  This way, we can add new plugins and the new pre file
> will get installed, and there's no issue with changing the old pre files
> (where admins may have added their own config, commented things out, etc.)
>
> So no, don't remove "old" pre files, because they're still being used and
> important.

So then, what if, for example, nothing else had loaded 
Mail::SpamAssassin::Plugin::DKIM?

It wasn't in the other files, even in a commented out format?

Should there be a "Lint" of all the possible modules (and worst-case 
scenario, I get an error if I try to load a module twice)

-Dan


>
>

--

"I wish the Real World would just stop hassling me!"

-Matchbox 20, Real World, off the album "Yourself or Someone Like You"


--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------


Re: Default Plugins?

Posted by Matt Kettler <mk...@verizon.net>.
Jason Haar wrote:
> Theo Van Dinter wrote:
>   
>> All pre files are used.  Nothing is automatically loaded.  There are
>> multiple files, based on the release where the plugins that are loaded by
>> that file were in.  This way, we can add new plugins and the new pre file
>> will get installed, and there's no issue with changing the old pre files
>> (where admins may have added their own config, commented things out, etc.)
>>
>> So no, don't remove "old" pre files, because they're still being used and
>> important.
>>   
>>     
> I'd just like to agree with Dan this this isn't intuitive.

I'll agree this isn't always clear if you're just going on the filenames
alone. I've seen a lot of folks, even package maintainers, make this
mistake. As others have suggested, this is documented in the UPGRADE file.

--------
- There are now multiple files read to enable plugins in the 
/etc/mail/spamassassin directory; previously only one, "init.pre" was 
read.  Now both "init.pre", "v310.pre", and any other files ending   in
".pre" will be read.  As future releases are made, new plugins will be
added to new files named according to the release they're added in.
--------

Perhaps that text should be added as a comment to each .pre file to
avoid future confusion.


I would also like to point out that if it was intended that you should
delete the old files when upgrading, they'd not be in
/etc/mail/spamassassin in the first place. Instead they would be in
/usr/share/spamassassin, which gets blown away and replaced during
upgrades. (And the primary reason why folks like me warn folks against
editing those files is they get obliterated during upgrades, forcing you
to re-customize after each upgrade. But if the intent was to delete and
replace, it would be in this directory...)

Again, thats a point that wouldn't be obvious to a novice, but hopefully
knowing that concept is useful to you at some point.

The whole reason it is done that way is so that when you upgrade, you
don't have to re-configure all your plugin preferences from scratch..
All your choices about the older plugins get preserved.





Re: Default Plugins?

Posted by Jason Haar <Ja...@trimble.co.nz>.
Theo Van Dinter wrote:
> All pre files are used.  Nothing is automatically loaded.  There are
> multiple files, based on the release where the plugins that are loaded by
> that file were in.  This way, we can add new plugins and the new pre file
> will get installed, and there's no issue with changing the old pre files
> (where admins may have added their own config, commented things out, etc.)
>
> So no, don't remove "old" pre files, because they're still being used and
> important.
>   
I'd just like to agree with Dan this this isn't intuitive.

Coincidentally I just noticed this week that I had a bunch of SA servers
that weren't doing DomainKey matching - ends up their v312.pre hadn't
been edited. However, they were newer installs than the working older
ones and it just didn't cross anyone's mind here that the older vXXX.pre
files needed editing. I assumed their functionality had been subsumed
into the latest release present...

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1


Re: Default Plugins?

Posted by Theo Van Dinter <fe...@apache.org>.
On Fri, Aug 03, 2007 at 06:49:58PM -0400, Dan Mahoney, System Admin wrote:
> I've got some stale v3xx.pre files around, and I notice that they load 
> plugins that are NOT loaded by v320.pre

Of course.

> Is there some default mechanism loading these things (for example, I 
> notice loadplugin Mail::SpamAssassin::Plugin::DKIM is only in v312.pre), 
> and is it safe to remove the old ones?

All pre files are used.  Nothing is automatically loaded.  There are
multiple files, based on the release where the plugins that are loaded by
that file were in.  This way, we can add new plugins and the new pre file
will get installed, and there's no issue with changing the old pre files
(where admins may have added their own config, commented things out, etc.)

So no, don't remove "old" pre files, because they're still being used and
important.

-- 
Randomly Selected Tagline:
"Q: How many surrealists does it take to screw in a lightbulb?
  A: Two.  One to hold the giraffe and the other to fill the bathtub
     with brightly colored machine tools."      - Unknown