It's by design.  IIRC you also get the rules that haven't been auto-promoted by ruleqa when running trunk, too.

(In reply to comment #1)
> It's by design.  IIRC you also get the rules that haven't been auto-promoted by
> ruleqa when running trunk, too.


This is not what I'm seeing when running sa-update.

Imo a setup from trunk/snapshot should behave exactly as a regular release except for the bleeding edge code.

I'm seeing only auto promoted rules in  72_active.cf but the scores are missing.

Same applies to installs from snapshots

Could you please do the magic so sa-update delivers the relevant scores as well?

Thanks

Axb

Hrm, things probably changed when we broke the rules out of core completely and made sa-update required.  You used to get rules generated via make from the bleeding edge sandboxes (IIRC... it's literally been years now).

I think the way I'm leaning right now (too avoid inadvertent breakage) is to create another channel for trunk that provides the same update we're providing for the stable branches now.  That way the nightly trunk updates continue to work the way they work now (even if we don't have a large enough mass-check corpus to generate scores) and the new channel will be available to those who set sa-update to use it.

So (notes to myself):

1. add DNS records like 3.4.0.stable.updates.spamassassin.org.
2. update the stable update script to build trunk and then lint the update using trunk and then update the "3.4.0.stable" update version file.
3. profit.

#2 should be doable by invoking the guts of the stable version testing loop one more time with a "3.4.0.stable" token rather than a "3.3.x" token.

#3 still eludes me.

> I think the way I'm leaning right now (too avoid inadvertent breakage) is to
> create another channel for trunk that provides the same update we're providing
> for the stable branches now.  That way the nightly trunk updates continue to
> work the way they work now (even if we don't have a large enough mass-check
> corpus to generate scores) and the new channel will be available to those who
> set sa-update to use it.

This sounds like good preparation for 3.4.0's eventual release as well.  +1.

(In reply to comment #3)
> Hrm, things probably changed when we broke the rules out of core completely and
> made sa-update required.  You used to get rules generated via make from the
> bleeding edge sandboxes (IIRC... it's literally been years now).
> 
> I think the way I'm leaning right now (too avoid inadvertent breakage) is to
> create another channel for trunk that provides the same update we're providing
> for the stable branches now.  That way the nightly trunk updates continue to
> work the way they work now (even if we don't have a large enough mass-check
> corpus to generate scores) and the new channel will be available to those who
> set sa-update to use it.
> 
> So (notes to myself):
> 
> 1. add DNS records like 3.4.0.stable.updates.spamassassin.org.
> 2. update the stable update script to build trunk and then lint the update
> using trunk and then update the "3.4.0.stable" update version file.
> 3. profit.
> 
> #2 should be doable by invoking the guts of the stable version testing loop one
> more time with a "3.4.0.stable" token rather than a "3.3.x" token.
> 
> #3 still eludes me.

Trunk is designed for masscheck without scores.  However, we need to have people testing it as a branch.  

Need to document the best way for 3.4.0 users to run with production rules.  

I believe these commands will work:

 wget http://buildbot.spamassassin.org/updatestage/1190771.tar.gz
 wget http://buildbot.spamassassin.org/updatestage/1190771.tar.gz.asc
 wget http://buildbot.spamassassin.org/updatestage/1190771.tar.gz.sha1
 sa-update -D --install 1190771.tar.gz 

Regards,
KAM

> Trunk is designed for masscheck without scores.  However, we need to have
> people testing it as a branch.  
> 
> Need to document the best way for 3.4.0 users to run with production rules.  
> 
> I believe these commands will work:
> 
>  wget http://buildbot.spamassassin.org/updatestage/1190771.tar.gz
>  wget http://buildbot.spamassassin.org/updatestage/1190771.tar.gz.asc
>  wget http://buildbot.spamassassin.org/updatestage/1190771.tar.gz.sha1
>  sa-update -D --install 1190771.tar.gz 
> 
> Regards,
> KAM

Where 1190771 was the latest 3.3.2 update:
dig +short TXT 2.3.3.updates.spamassassin.org

REV=`dig +short TXT 2.3.3.updates.spamassassin.org|tr -d '"'`; wget -P /root/sa-update/ http://buildbot.spamassassin.org/updatestage/${REV}.tar.gz http://buildbot.spamassassin.org/updatestage/${REV}.tar.gz.asc http://buildbot.spamassassin.org/updatestage/${REV}.tar.gz.sha1 ; sa-update --install /root/sa-update/${REV}.tar.gz

Seems to work.  (dont' forget to mkdir /root/sa-update )

So is this recommended for people running trunk?  I think it would be better if a normal sa-update just worked, with scores.  But I guess I don't understand the need for the way it's currently working.

(In reply to comment #7)
> REV=`dig +short TXT 2.3.3.updates.spamassassin.org|tr -d '"'`; wget -P
> /root/sa-update/ http://buildbot.spamassassin.org/updatestage/${REV}.tar.gz
> http://buildbot.spamassassin.org/updatestage/${REV}.tar.gz.asc
> http://buildbot.spamassassin.org/updatestage/${REV}.tar.gz.sha1 ; sa-update
> --install /root/sa-update/${REV}.tar.gz
> 
> Seems to work.  (dont' forget to mkdir /root/sa-update )
> 
> So is this recommended for people running trunk?  I think it would be better if
> a normal sa-update just worked, with scores.  But I guess I don't understand
> the need for the way it's currently working.

I agree - this is an ugly workaround

in sa-update "trunk" should be an alias for latest release, as they're seeing the same autopromoted rulebase

> Seems to work.  (dont' forget to mkdir /root/sa-update )
> 
> So is this recommended for people running trunk?  I think it would be better if
> a normal sa-update just worked, with scores.  But I guess I don't understand
> the need for the way it's currently working.


My understanding is:

If you want to use trunk in a production environment, you need rules.  Using the rules that come with trunk, you are using rules designed for the mass-checker to figure out the best scoring algorithmically.

Perhaps we should add a quick script called svn-trunk-get-rules-for-production.sh with commands such as this to svn for trunk?

REV=`dig +short TXT 2.3.3.updates.spamassassin.org|tr -d '"'`; mkdir /root/sa-update; wget -P /root/sa-update/ http://buildbot.spamassassin.org/updatestage/${REV}.tar.gz http://buildbot.spamassassin.org/updatestage/${REV}.tar.gz.asc  http://buildbot.spamassassin.org/updatestage/${REV}.tar.gz.sha1 && sa-update
 --install /root/sa-update/${REV}.tar.gz

It'll need some text re: the purpose of the script as well so it can be updated for example to use 0.4.3 when the next release comes out.

It could be refined for a few minutes to check for wget vs. curl, etc. as well as just document the manual steps if needed. But the number of people running trunk in production is small so if this is documented, that might be enough.

So perhaps a command in sa-update that is something like --svn-trunk-get-rules-for-production is a better idea?  Then have that load the last releases rules.

Moving this to blocker for 3.4.0.  We need to have 3.4.0 tested before release.  This issue needs a resolution for people to test.  Whether it is documented the process manually or adding capabilities to sa-update, I need others to weigh in if my understanding of why trunk has no rules is correct and that these are correct pathways to consider.

regards,
KAM

(In reply to comment #9)
> > Seems to work.  (dont' forget to mkdir /root/sa-update )
> > 
> > So is this recommended for people running trunk?  I think it would be better if
> > a normal sa-update just worked, with scores.  But I guess I don't understand
> > the need for the way it's currently working.
> 
> 
> My understanding is:
> 
> If you want to use trunk in a production environment, you need rules.  Using
> the rules that come with trunk, you are using rules designed for the
> mass-checker to figure out the best scoring algorithmically.
> 
> Perhaps we should add a quick script called
> svn-trunk-get-rules-for-production.sh with commands such as this to svn for
> trunk?
> 
> REV=`dig +short TXT 2.3.3.updates.spamassassin.org|tr -d '"'`; mkdir
> /root/sa-update; wget -P /root/sa-update/
> http://buildbot.spamassassin.org/updatestage/${REV}.tar.gz
> http://buildbot.spamassassin.org/updatestage/${REV}.tar.gz.asc 
> http://buildbot.spamassassin.org/updatestage/${REV}.tar.gz.sha1 && sa-update
>  --install /root/sa-update/${REV}.tar.gz
> 
> It'll need some text re: the purpose of the script as well so it can be updated
> for example to use 0.4.3 when the next release comes out.
> 
> It could be refined for a few minutes to check for wget vs. curl, etc. as well
> as just document the manual steps if needed. But the number of people running
> trunk in production is small so if this is documented, that might be enough.
> 
> So perhaps a command in sa-update that is something like
> --svn-trunk-get-rules-for-production is a better idea?  Then have that load the
> last releases rules.

imo, it should be transparent and not require an extra sa-update switch to run.

I've never gone thru the DNS logic behind sa-update but can't imagine it impossible to "cname" trunk to release, or is it?

> imo, it should be transparent and not require an extra sa-update switch to run.
> 
> I've never gone thru the DNS logic behind sa-update but can't imagine it
> impossible to "cname" trunk to release, or is it?

My concern would be is doing so going to break mass-check...

(In reply to comment #12)
> > imo, it should be transparent and not require an extra sa-update switch to run.
> > 
> > I've never gone thru the DNS logic behind sa-update but can't imagine it
> > impossible to "cname" trunk to release, or is it?
> 
> My concern would be is doing so going to break mass-check...

does masscheck run sa-update?

(In reply to comment #13)
> (In reply to comment #12)
> > > imo, it should be transparent and not require an extra sa-update switch to run.
> > > 
> > > I've never gone thru the DNS logic behind sa-update but can't imagine it
> > > impossible to "cname" trunk to release, or is it?
> > 
> > My concern would be is doing so going to break mass-check...
> 
> does masscheck run sa-update?

Not that I can find, No.  I checked /build and the mass check script that's up on the Fedora GIT host.

So we have a third possibility which is just DNS related possibly.

(In reply to comment #14)
> So we have a third possibility which is just DNS related possibly.

I like that one.  Any objections to it?

(In reply to comment #15)
> (In reply to comment #14)
> > So we have a third possibility which is just DNS related possibly.
> 
> I like that one.  Any objections to it?

I'm very wary of breaking things and need people who are intimately familiar with the way mass-check works and sa-update works to weigh in.  Eventually, I'll vote +1 if needed because you have to break eggs to make omelets.  But after 9 weeks of no mass check (thanks for your idea on time again, BTW), I'm more than a bit reticent to just jump in and break it again.

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > So we have a third possibility which is just DNS related possibly.
> > 
> > I like that one.  Any objections to it?
> 
> I'm very wary of breaking things and need people who are intimately familiar
> with the way mass-check works and sa-update works to weigh in.  Eventually,
> I'll vote +1 if needed because you have to break eggs to make omelets.  But
> after 9 weeks of no mass check (thanks for your idea on time again, BTW), I'm
> more than a bit reticent to just jump in and break it again.

while I understand your "fear", it may be better to risk now and have it working and if it doesn't atm, it won't do as much harm as it would shortly after a release.
Postponing just means a long wait before we know the outcome..

+1 to break eggs now :)

The change has to be well documented so a rollback doesn't become an ordeal.

(In reply to comment #16)
> I'm very wary of breaking things and need people who are intimately familiar
> with the way mass-check works and sa-update works to weigh in.  Eventually,

Is there anyone currently participating in this project that even has that knowledge?  If there is, it sure would be nice to get them to write up some documentation.

Daryl seems to be the most familiar with it, and hasn't touched it in years.  And JM's not available, right?

I'm in favour of any solution that makes trunk+rules work out of the box,
i.e. that sa-update will be able to update rules for anyone running trunk.
I'm not familiar with caveats though, so I don't know what is the best solution.

(In reply to comment #19)
> I'm in favour of any solution that makes trunk+rules work out of the box,
> i.e. that sa-update will be able to update rules for anyone running trunk.
> I'm not familiar with caveats though, so I don't know what is the best
> solution.

Well, here goes nothing.

On zones, I edited /var/named/spamassassin.org after doing svn update and a chmod 1777 spamassassin.org.d per the README

; Changes for bug 6644
;
; Updates for trunk should be a cname for the latest release
; Uncomment 3.4.0 when released so automatic updates work
; This way the file in updates.spamassassin.org/ is still updated automatically but ignored
;
;$INCLUDE /var/named/updates.spamassassin.org.d/3.4.0

; When 3.4.0 is released update this to the version used in trunk. E.g. 1.4.3 CNAME 0.4.3 

0.4.3 CNAME 2.3.3


Then I ran:

 sudo -u updatesd /home/updatesd/svn/spamassassin/build/mkupdates/tick_zone_serial


Three problems:

1 - The hyperreal server isn't appearing to update the zone though the sonic.net nameservers have.  I looked at /var/adm logs and found 209.237.226.84 was blocked from transfer.  Since this is in the same class C as all the other hyperreal servers, it might be related but that's been a month on that error.  Either way, I've emailed brian at hyperreal.org to see if I can find out more about why the master server isn't updating from the hidden master on zones.

2 - I can't getting logging to go to info level for bind with syslog.  I've emailed infra for help.


3 - I could not svn commit the changes for the zones.

svn commit -m 'DNS Changes for bug 6644'
svn: Commit failed (details follow):
svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/repos/asf/!svn/act/93e2ef37-61ef-eb0d-efe4-d04599c13f82'

I'm guessing commits are ssl only and I have to rewrite to https://svn.apache.org/repos/asf/spamassassin/dns/

I ran svn switch --relocate http://svn.apache.org/repos/asf/spamassassin/dns/ https://svn.apache.org/repos/asf/spamassassin/dns/ . but I don't know the password for svn to commit for this repository.  

I used my account to commit but got a nasty warning about encryption. Unsure if I'm going to break any of the automated rules.

I'll email Justin to see if he can help.

svn commit -m 'DNS Changes for bug 6644' --username kmcgrail
Authentication realm: <https://svn.apache.org:443> ASF Committers
Password for 'kmcgrail': 
Sending        named.conf
Sending        spamassassin.org
Transmitting file data ..
-----------------------------------------------------------------------
ATTENTION!  Your password for authentication realm:

   <https://svn.apache.org:443> ASF Committers

can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/root/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? no

Committed revision 1196445.



On the good news front, this change got my trunk version of SA to update to 1195374 via sa-update out of the box.  So as long as you aren't polling ns.hyperreal.org, sa-update should work for trunk.

Update on issues:

RESOLVED - 1 - The hyperreal server isn't appearing to update the zone.

Spoke with Brian.  They use tinydns so the TTL of 1 hour should be what triggers a reload.  Got IPs of server cleaned up in named.conf as well.

If we need to reload more quickly, likely best to move DNS.  Not sure if there is a ticket about moving DNS to ASF Infrastructure but status quo is likely fine.

I documented the 1 hour delay in named.conf


IGNORING SINCE WE RESOLVED THE DNS ISSUE - 2 - I can't getting logging to go to info level for bind with syslog.  I've emailed infra for help.


ASSUMING THAT COMMITTING AS ME IS CORRECT - 3 - I could not svn commit the changes for the zones.

Considering things fixed until we find out I broke lots of things...

Just an update that 3.4.0's current rules do not include the 72_score.cf.  Working to resolve that.