CRM114 version specifics?
Glenn Steen
glenn.steen at gmail.com
Tue Jul 31 15:38:53 IST 2007
On 31/07/07, Matt Kettler <mkettler at evi-inc.com> wrote:
> Glenn Steen wrote:
> > On 31/07/07, Alex Broens <ms-list at alexb.ch> wrote:
> >> On 7/31/2007 2:41 PM, Steve Campbell wrote:
> >>> The turtle Steve, who seems to always be behind in updates, here.
> >>>
> >>> Is all of this CRM114 stuff version specific or will it run under
> >>> recent/any versions of SA?
> >>>
> >>> Now for a little soapboxing:
> >>>
> >>> I see a small problem brewing with these init.pre, v300.pre, v310.pre,
> >>> etc files where people are told to add things to this specific one, or
> >>> that specific one, when some of these don't exist and for the most part,
> >>> it doesn't matter which one you append to. I don't have v320.pre because
> >>> I haven't installed it yet. Might it not be a better idea to suggest
> >>> people add things to the latest *.pre they have? Should there be an
> >>> update_pre script somewhere that moves things from a current .pre to the
> >>> new .pre when installing upgrades? I don't think it really matters as SA
> >>> will just report duplicates or something, but there could come a time
> >>> when it does matter.
> >> To be safe, always use your own files for your custom stuff so the
> >> logical step would be to add your custom plugins load commands to
> >> something like a "myplugins.pre" file.
> >>
> >> A SA setup/update won't touch that file and you can stop worrying.
> >>
> > Actually, the "plethora" of .pre files is to facilitate safe upgrades
> > (and downgrades)... Each is meant to only hold stuff that is specific
> > the version where it is introduced (and later versions, of course)...
> > At least assuming IUC;-). Matt K will slap us silly if we get it
> > wrong:-D.
> > But having your own for that too is safe and probably even a good idea.
>
> I agree.. when adding on my own plugins, I create a separate .pre file,
>
> OR, sometimes, I include the loadplugin in the .cf file for the plugin. Many
> add-on plugins do this by default, and it is safe as long as the plugin isn't
> referenced by any rules that might be parsed before the loadplugin command. This
> is true for all add-on plugins, unless it is trying to replace one of the ones
> that comes with SA (a "standard" plugin, and I know of none that do this at present)
>
> The primary reason the standard plugins that come with SA are in .pre files is
> that /etc/mail/spamassassin/*.pre gets loaded before the default rules (ie:
> /usr/share/spamassassin/* or
> /var/lib/spamassassin/<version>/updates_spamassassin_org.cf).
>
> Rules in the default set actually check for the various standard plugins, but
> that only works if the plugin is loaded first. (otherwise the check fails and
> the rules get skipped). Thus, the .pre files are needed so the plugins get
> loaded first.
>
> However, an add-on plugin won't be referenced by the standard rules, only the
> ones that come with the plugin.
>
> In general As long as the loadplugin occurs before any of the rules that use it,
> you're fine.
>
Thanks Matt for the explanation. Always a pleasure.
Cheers
--
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se
More information about the MailScanner
mailing list