You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ben Rosengart <br...@panix.com> on 2004/09/30 00:01:05 UTC
2.6 -> 3.0 migration questions
1. Deprecated directives. If a configuration includes the
deprecated "rewrite_subject" directive, will spamd barf? Or
ignore it? Or something else? What about spamassassin?
2. Spamd/spamc protocol. Will a 2.6 spamc communicate properly with
a 3.0 spamd? What about a 3.0 spamc with a 2.6 spamd? If they're
not compatible, what are the failure modes?
3. Deprecated command-line options. Will the options deprecated
after 2.6 be ignored, or will they cause failures? What about
options previously deprecated, like '-S'?
Thank you.
--
Ben Rosengart (212) 741-4400 x215
Unix gives 0.35 t/ha extra yield.
Can you afford to ignore the Unix difference?
Re: 2.6 -> 3.0 migration questions
Posted by Ben Rosengart <br...@panix.com>.
On Fri, Oct 01, 2004 at 08:58:48AM -0500, Mike Burger wrote:
>
> While I would never presume to suggest that you work with pre-release in a
> huge production environment, like at Panix, would it not have behooved
> someone, there, to run them in a test environment...even stage the upgrade
> to the release version, in test, prior to throwing it out there for
> general consumption.
Our plan is to make 3.0.0 available "for the adventurous" for final
shake-out and use that experience to gauge what needs to be done
before we upgrade the main spamd instances.
--
Ben Rosengart (212) 741-4400 x215
Unix gives 0.35 t/ha extra yield.
Can you afford to ignore the Unix difference?
Re: 2.6 -> 3.0 migration questions
Posted by Mike Burger <mb...@bubbanfriends.org>.
On Thu, 30 Sep 2004, Ben Rosengart wrote:
> On Wed, Sep 29, 2004 at 06:40:18PM -0600, Lucas Albers wrote:
> > Some options kick you in the face.
> > Such as -a for spamd which will prevent it from starting.
>
> Ouch.
>
> Is the list of deprecated options and directives in the UPGRADE
> document definitive?
>
> Here at Panix -- where we have a bunch of spamds, a bunch of spamcs,
> a whole lot of automatically- and hand-generated customer
> configurations, and no way to upgrade everything all at once -- we
> are pretty unhappy about the skimpy upgrade documentation, and the
> number of apparently-gratuitous changes ("hits" becomes "score"?).
While I would never presume to suggest that you work with pre-release in a
huge production environment, like at Panix, would it not have behooved
someone, there, to run them in a test environment...even stage the upgrade
to the release version, in test, prior to throwing it out there for
general consumption.
--
Mike Burger
http://www.bubbanfriends.org
Visit the Dog Pound II BBS
telnet://dogpound2.citadel.org or http://dogpound2.citadel.org
To be notified of updates to the web site, visit
http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a
message to:
site-update-request@bubbanfriends.org
with a message of:
subscribe
Re: 2.6 -> 3.0 migration questions
Posted by Robert LeBlanc <rj...@renaissoft.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matt Kettler wrote:
| I liked OSS better, but then several companies decided offering
| high-dollar licenses to their code made them "open source software" and
| diluted any meaning that expression had.
Actually, I believe the "Free" in FOSS was motivated by Stallman and the
Free Software Foundation, which has a somewhat different definition of
"free software". The FSF is referring more to freedom in terms of
restrictions on redistribution and use than strictly monetary
definitions. The "free software" and "open source" camps have been at
each other's throats for years now, squabbling over ideological
distinctions, and I think "FOSS" emerged as a generic term to describe both.
- --
Robert LeBlanc <rj...@renaissoft.com>
Renaissoft, Inc.
Maia Mailguard <http://www.maiamailguard.com/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFBXIicGmqOER2NHewRAlDqAJsGJOn/4MzKXPNJUxnao+yTulSy7ACgnRY1
lxiBlWyMDDv9Z5HUHxNnn1o=
=sQB3
-----END PGP SIGNATURE-----
Re: 2.6 -> 3.0 migration questions
Posted by Kelson <ke...@speed.net>.
Kelson wrote:
> Matt Kettler wrote:
>> Perhaps we need a new one.. NBSOSS.. No BS Open Source Software... :)
>
> How about ROSS: Real Open Source Software?
Sorry to reply to my own post, but I came up with a few funnier ones:
TOSS - True Open Source Software.
FLOSS - Freely Licenced Open Source Software
U-DA-BOSS - Unrestricted Distribution Allowed By Open Source Software
We now return you to your regularly scheduled mailing list.
--
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: 2.6 -> 3.0 migration questions
Posted by jdow <jd...@earthlink.net>.
From: "snowjack" <sn...@fastmail.fm>
> Kelson wrote:
> > How about ROSS: Real Open Source Software?
>
> Bitchin' Open Source Software: BOSS
That's as bad as the acronym/name for what I developed back in the
CP/M 1.3 days when I could not afford both the disk drives and the
copy of CP/M, Disk-Based Operating Sub System, D-BOSS.
{O,o} Gawd but that was a long time ago.
Re: 2.6 -> 3.0 migration questions
Posted by snowjack <sn...@fastmail.fm>.
Kelson wrote:
> How about ROSS: Real Open Source Software?
Bitchin' Open Source Software: BOSS
:-)
Re: 2.6 -> 3.0 migration questions
Posted by Kelson <ke...@speed.net>.
Matt Kettler wrote:
> Given that it's been around for at least 6 years (I spotted it in a May
> 1998 post on usenet) I don't think FOSS is going anywhere.
>
> I liked OSS better, but then several companies decided offering
> high-dollar licenses to their code made them "open source software" and
> diluted any meaning that expression had.
>
> Perhaps we need a new one.. NBSOSS.. No BS Open Source Software... :)
How about ROSS: Real Open Source Software?
--
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: 2.6 -> 3.0 migration questions
Posted by Matt Kettler <mk...@evi-inc.com>.
At 05:11 PM 9/30/2004, Will Yardley wrote:
>Side note - who came up with this horrible acronym (I can't bring myself
>to repeat it), and can people stop using it already!
Given that it's been around for at least 6 years (I spotted it in a May
1998 post on usenet) I don't think FOSS is going anywhere.
I liked OSS better, but then several companies decided offering high-dollar
licenses to their code made them "open source software" and diluted any
meaning that expression had.
Perhaps we need a new one.. NBSOSS.. No BS Open Source Software... :)
Re: 2.6 -> 3.0 migration questions
Posted by Will Yardley <sa...@veggiechinese.net>.
On Thu, Sep 30, 2004 at 05:04:35PM -0400, Matt Kettler wrote:
> At 04:43 PM 9/30/2004, Ben Rosengart wrote:
> > we are pretty unhappy about the skimpy upgrade documentation
>
> Hmm, true, but are you volunteering to help write better documentation?
> (General principle in FOSS: If you don't like it, volunteer to help if
Side note - who came up with this horrible acronym (I can't bring myself
to repeat it), and can people stop using it already!
Re[2]: 2.6 -> 3.0 migration questions
Posted by Robert Menschel <Ro...@Menschel.net>.
Hello Loren,
Thursday, September 30, 2004, 6:23:46 PM, you wrote:
>> To the extent that user_prefs files and (most) command-line options
>> are similarly backwards- and forwards-compatible, this upgrade will
>> be painless for us. To be more explicit, I would like to make
>> necessary changes *before* the upgrade to the extent that I can, in
>> such a way that the system will behave as expected both before and
>> after the upgrade.
>>
>> What I'm trying to determine here is to what extent that's possible,
>> and conversely to what extent I will have to synchronize various
>> parts of the upgrade procedure.
LW> My impression is that *probably* you can put the 3.0 syntax into user_prefs
LW> files while running 2.6x, and things will probably still work. You will get
LW> lint errors, but I don't *think* they will abort processing. Likewise the
LW> 2.6x values will cause lint errors in 3.0. But again, I *think* they will
LW> not abort processing.
Agreed. I'm running 3.0 on my desktop, and my host's servers are running
2.63. I have 3.0 config lines in my user_prefs for my desktop use, and
they generate two warnings when my daily --lint runs on the server.
My 2.63 config lines generate 65 --lint warnings on my desktop. Neither
operation seems affected by these warnings.
Bob Menschel
Re: 2.6 -> 3.0 migration questions
Posted by Loren Wilton <lw...@earthlink.net>.
> To the extent that user_prefs files and (most) command-line options
> are similarly backwards- and forwards-compatible, this upgrade will
> be painless for us. To be more explicit, I would like to make
> necessary changes *before* the upgrade to the extent that I can, in
> such a way that the system will behave as expected both before and
> after the upgrade.
>
> What I'm trying to determine here is to what extent that's possible,
> and conversely to what extent I will have to synchronize various
> parts of the upgrade procedure.
My impression is that *probably* you can put the 3.0 syntax into user_prefs
files while running 2.6x, and things will probably still work. You will get
lint errors, but I don't *think* they will abort processing. Likewise the
2.6x values will cause lint errors in 3.0. But again, I *think* they will
not abort processing.
I would insure a blank line on each side of a line that is changing between
2.x and 3.0. I've occasionally had what appear to be scanner recovery
problems after an error, and the blank line gives the scanner a better
chance of correct recovery.
OTOH, I think you will have problems with command line arguments, unless you
clean out the depreciated things before attempting the upgrade. Since
presumably only depreciated things were actually removed in 3.0, there
should have either been a viable alternative in 2.6x that is still valid in
3.0, or the items should have been useless in 2.6x.
In either case, I think you should probably be able to get the command lines
up to 3.0 spec while still on 2.6x, IF they did it right. If not, you may
need to come up with some very clever script code to decide which line to
used based on the program version.
Loren
Re: 2.6 -> 3.0 migration questions
Posted by Ben Rosengart <br...@panix.com>.
On Thu, Sep 30, 2004 at 05:04:35PM -0400, Matt Kettler wrote:
> At 04:43 PM 9/30/2004, Ben Rosengart wrote:
> >we are pretty unhappy about the skimpy upgrade documentation
>
> Hmm, true, but are you volunteering to help write better documentation?
I would be happy to summarize whatever I learn and post it to this
list. If someone wishes to modify that summary and/or make it
available for download, they have my blessing.
> >and the number of apparently-gratuitous changes ("hits" becomes "score"?).
>
> You'd not believe the number of people who don't understand what SA
> means by "hits" when they first encounter it.
I work for an ISP. Are you sure I wouldn't believe it? :-)
I don't take much exception to that change, because it's very easy
to accommodate in a backwards- and forwards-compatible way. That
is our main concern here at Panix.
That is, all software that currently matches on "hits" can be
changed to match on "(hits|score)", and will work before and after
the upgrade without any difficulty.
To the extent that user_prefs files and (most) command-line options
are similarly backwards- and forwards-compatible, this upgrade will
be painless for us. To be more explicit, I would like to make
necessary changes *before* the upgrade to the extent that I can, in
such a way that the system will behave as expected both before and
after the upgrade.
What I'm trying to determine here is to what extent that's possible,
and conversely to what extent I will have to synchronize various
parts of the upgrade procedure.
--
Ben Rosengart (212) 741-4400 x215
Unix gives 0.35 t/ha extra yield.
Can you afford to ignore the Unix difference?
Re: 2.6 -> 3.0 migration questions
Posted by Matt Kettler <mk...@evi-inc.com>.
At 04:43 PM 9/30/2004, Ben Rosengart wrote:
>we are pretty unhappy about the skimpy upgrade documentation
Hmm, true, but are you volunteering to help write better documentation?
(General principle in FOSS: If you don't like it, volunteer to help if
you're able.)
At least this time there is an UPGRADE document. That never happened before
in any other release, which is a small step forward. Prior releases got a
few terse notes about the major issues added to README, but nothing nearly
as in-depth as the still-sparse UPGRADE document from 3.0.
>and the number of apparently-gratuitous changes ("hits" becomes "score"?).
You'd not believe the number of people who don't understand what SA
means by "hits" when they first encounter it. Particularly since SA used to
use "score" "hits" and "points" interchangeably and without much consistency.
A lot of naming convention changes come about after realizing that the
original naming isn't as clear as originally thought, or inconsistent with
other parts of the software. It's painful to go through, but makes life a
bit easier on the project in the long run by improving clarity.
This lack of consistency has been in the buglist for a long time.
http://bugzilla.spamassassin.org/show_bug.cgi?id=1332
Re: 2.6 -> 3.0 migration questions
Posted by Ben Rosengart <br...@panix.com>.
On Wed, Sep 29, 2004 at 06:40:18PM -0600, Lucas Albers wrote:
> Some options kick you in the face.
> Such as -a for spamd which will prevent it from starting.
Ouch.
Is the list of deprecated options and directives in the UPGRADE
document definitive?
Here at Panix -- where we have a bunch of spamds, a bunch of spamcs,
a whole lot of automatically- and hand-generated customer
configurations, and no way to upgrade everything all at once -- we
are pretty unhappy about the skimpy upgrade documentation, and the
number of apparently-gratuitous changes ("hits" becomes "score"?).
--
Ben Rosengart (212) 741-4400 x215
Unix gives 0.35 t/ha extra yield.
Can you afford to ignore the Unix difference?
Re: 2.6 -> 3.0 migration questions
Posted by Lucas Albers <ad...@cs.montana.edu>.
I think as many of the changes for an upgrade between 2.6 and 3.0 should
be documented somewhere.
Not the upgrade document, because their are two many changes.
(eg, My bug on this issue got rejected.)
In the wiki somewhere, then.
David Brodbeck said:
> Lucas Albers wrote:
>
>>Some options kick you in the face.
>>Such as -a for spamd which will prevent it from starting.
>>
>>
> But it gives you an error message explaining exactly what you have to
> do, so that's pretty much self-documenting.
>
--
Luke Computer Science System Administrator
Security Administrator,College of Engineering
Montana State University-Bozeman,Montana
Re: 2.6 -> 3.0 migration questions
Posted by David Brodbeck <gu...@gull.us>.
Lucas Albers wrote:
>Some options kick you in the face.
>Such as -a for spamd which will prevent it from starting.
>
>
But it gives you an error message explaining exactly what you have to
do, so that's pretty much self-documenting.
Re: 2.6 -> 3.0 migration questions
Posted by Lucas Albers <ad...@cs.montana.edu>.
Some options kick you in the face.
Such as -a for spamd which will prevent it from starting.
I guess we can add in a wiki entry for upgrades from 3.0 instead of
forcing the dev's to document every nit-picking thing.
Some options are just ignored, eg, no backward compatibility.
bayes autolearn changed syntax so you need to change the name if you set
your autolearn spam/ham level.
--
Luke Computer Science System Administrator
Security Administrator,College of Engineering
Montana State University-Bozeman,Montana
Re: 2.6 -> 3.0 migration questions
Posted by Matt Kettler <mk...@evi-inc.com>.
At 06:01 PM 9/29/2004, Ben Rosengart wrote:
>1. Deprecated directives. If a configuration includes the
> deprecated "rewrite_subject" directive, will spamd barf? Or
> ignore it? Or something else? What about spamassassin?
Based on past experience they generally don't cause problems on their own,
but if the parser gets confused, they can help make it more confused and
cause more lines of config to be dropped.
I'd use spamassassin --lint to find the deprecated options and fix them.
>2. Spamd/spamc protocol. Will a 2.6 spamc communicate properly with
> a 3.0 spamd? What about a 3.0 spamc with a 2.6 spamd? If they're
> not compatible, what are the failure modes?
I'd not recommend mixing versions, but based on the code the protocol
version for spamd/spamc hasn't changed.
Mail-SpamAssassin-2.64/spamd/libspamc.c:static const char
*PROTOCOL_VERSION="SPAMC/1.3";
Mail-SpamAssassin-3.0.0/spamc/libspamc.c:static const char
*PROTOCOL_VERSION = "SPAMC/1.3";
>3. Deprecated command-line options. Will the options deprecated
> after 2.6 be ignored, or will they cause failures? What about
> options previously deprecated, like '-S'?
I suspect they'll be ignored with a complaint to stderr, but this is a
suspicion only.
Re: 2.6 -> 3.0 migration questions
Posted by Will Yardley <sa...@veggiechinese.net>.
On Wed, Sep 29, 2004 at 06:01:05PM -0400, Ben Rosengart wrote:
> 1. Deprecated directives. If a configuration includes the
> deprecated "rewrite_subject" directive, will spamd barf? Or
> ignore it? Or something else? What about spamassassin?
Heya Ben.. long time no speak :>
I have a bunch of deprecated directives in my config, and it hasn't
caused any problems for me yet. It's not barfing - just shows up as
ignored if you run in debug mode.
debug: config: SpamAssassin failed to parse line, skipping: rewrite_subject 0
debug: config: SpamAssassin failed to parse line, skipping: report_header 1
debug: config: SpamAssassin failed to parse line, skipping: use_terse_report 1
debug: config: SpamAssassin failed to parse line, skipping: defang_mime 0
> 3. Deprecated command-line options. Will the options deprecated
> after 2.6 be ignored, or will they cause failures? What about
> options previously deprecated, like '-S'?
Looks like (from a quick test) an error is sent to stderr.
drama% spamassassin -S
The -S option has been deprecated and is no longer supported, ignoring.