Bug 6279 - sa-update failing - failed to parse ...10_default_prefs.cf ...originating_ip_headers
Summary: sa-update failing - failed to parse ...10_default_prefs.cf ...originating_ip_...
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: 3.3.0
Hardware: All All
: P1 major
Target Milestone: 3.3.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard: ready for commit
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-07 10:29 UTC by Mark Martinec
Modified: 2010-01-08 10:33 UTC (History)
2 users (show)


Attachment Type Modified Status Actions Submitter/CLA Status
proposed patch application/octet-stream None Mark Martinec [HasCLA]
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Martinec 2010-01-07 10:29:01 UTC 
Created attachment 4626 [details]
proposed patch

(passed from a mailing list):

jidanni wrote:

> $ sa-update
> config: failed to parse line, skipping,
>  in "/tmp/.spamassassin5560GP7SGbtmp/10_default_prefs.cf":
>  clear_originating_ip_headers
> config: failed to parse line, skipping,
>  in "/tmp/.spamassassin5560GP7SGbtmp/10_default_prefs.cf":
>  originating_ip_headers X-Yahoo-Post-IP X-Originating-IP X-Apparently-From
> config: failed to parse line, skipping,
>  in "/tmp/.spamassassin5560GP7SGbtmp/10_default_prefs.cf":
>  originating_ip_headers X-SenderIP
> channel: lint check of update failed, channel failed

(Mark:)
It's an unfortunate consequence of pushing the Bug 5895 rule change
into 10_default_prefs.cf, while you are still running 3.3.0-rc1 or
older 3.3.0 code.

The quickest fix would be to install the current SA code from SVN:
  http://wiki.apache.org/spamassassin/DevelopmentStuff
  $ svn checkout https://svn.apache.org/repos/asf/spamassassin/trunk
with the usual: perl Makefile.PL; make; make install

...or just not to worry about the failing sa-update,
until we come up with a better temporary solution.


(Justin:)
Hmm.  We can use if can() to work around it...
Comment 1 Justin Mason 2010-01-07 13:53:42 UTC 
+1 exactly ;)
Comment 2 Warren Togami 2010-01-07 13:57:11 UTC 
+1
Comment 3 Kevin A. McGrail 2010-01-07 13:57:41 UTC 
(In reply to comment #2)
> +1

+1 KAM
Comment 4 Mark Martinec 2010-01-07 14:13:22 UTC 
Bug 6279: conditionalize originating_ip_headers rules in 10_default_prefs.cf
Sending        lib/Mail/SpamAssassin/Conf.pm
Sending        rules/10_default_prefs.cf
Committed revision 897031.
Comment 5 Mark Martinec 2010-01-08 03:25:48 UTC 
13 hours after the 10_default_prefs.cf has been committed into /rules/,
my sa-update is still not picking up the change. Actually, on another
host, where I deleted everything under /var/lib/spamassassin/3.00300,
it finally picked it, its sa-update shows:

Jan  8 12:18:16.892 [17200] dbg: channel: metadata version = 897136
Jan  8 12:18:16.896 [17200] dbg: dns: 0.3.3.updates.spamassassin.org => 897136, parsed as 897136

yet on the first host, it still claims:

Jan  8 12:17:34.315 [40855] dbg: channel: metadata version = 896803
Jan  8 12:17:34.322 [40855] dbg: dns: 0.3.3.updates.spamassassin.org => 896803, parsed as 896803
Jan  8 12:17:34.322 [40855] dbg: channel: current version is 896803, new version is 896803, skipping channel

Is this normal? Are DNS slaves slow to pick up the change?
Comment 6 Mark Martinec 2010-01-08 03:41:56 UTC 
> Is this normal? Are DNS slaves slow to pick up the change?

$ host -t txt 0.3.3.updates.spamassassin.org a.auth-ns.sonic.net.
0.3.3.updates.spamassassin.org descriptive text "897136"

$ host -t txt 0.3.3.updates.spamassassin.org b.auth-ns.sonic.net.
0.3.3.updates.spamassassin.org descriptive text "897136"

$ host -t txt 0.3.3.updates.spamassassin.org c.auth-ns.sonic.net.
0.3.3.updates.spamassassin.org descriptive text "897136"

$ host -t txt 0.3.3.updates.spamassassin.org ns.hyperreal.org.
0.3.3.updates.spamassassin.org descriptive text "896803"
Comment 7 Mark Martinec 2010-01-08 08:21:10 UTC 
The ns.hyperreal.org finally cought up.


Let's see how long this one will take to end up in DNS:

Change in comments in 60_whitelist_dkim.cf
Sending rules/60_whitelist_dkim.cf
Committed revision 897247.
Comment 8 Kevin A. McGrail 2010-01-08 08:25:28 UTC 
My $0.02: This sounds like something more for infra where DNS notifies / transfers aren't being properly received.

And, if needed, I originally got involved with helping the SA project because of DNS.  I run very nice, stable, disparate network name servers and would be happy to be a DNS mirror (or primary) if it helps.

KAM
Comment 9 Justin Mason 2010-01-08 08:41:25 UTC 
(In reply to comment #8)
> My $0.02: This sounds like something more for infra where DNS notifies /
> transfers aren't being properly received.
> 
> And, if needed, I originally got involved with helping the SA project because
> of DNS.  I run very nice, stable, disparate network name servers and would be
> happy to be a DNS mirror (or primary) if it helps.

We should take this off the ticket (and probably to the dev@ list).  but +1 to replacing hyperreal.org with KAM's servers if possible
Comment 10 Mark Martinec 2010-01-08 09:17:29 UTC 
> We should take this off the ticket (and probably to the dev@ list).  but +1 to
> replacing hyperreal.org with KAM's servers if possible

Closing this one.

Carrying over the general discussion onto:
  Bug 6281: Speeding up the pipeline from rules update to a final user
Comment 11 Mark Martinec 2010-01-08 10:33:14 UTC 
Closing.