Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Spamassassin Wiki" for change notification.
The following page has been changed by JustinMason:
http://wiki.apache.org/spamassassin/RuleUpdates
The comment on the change is:
split the RuleUpdates page into 2 publisher/user pages
------------------------------------------------------------------------------
Note: This page is under construction and shouldn't be considered "complete". If there are any questions, etc, please feel free to contact the users -at- spamassassin.apache.org list for more information.
-
- ----
== Notes / FAQ ==
@@ -130, +128 @@
The files from the update go into ''updates_spamassassin_org'', and the *.cf files are then included by ''updates_spamassassin_org.cf'', which also keeps track of what update version is installed. Therefore, if it is desired to change the update directory, the .cf and the update directory will exist there.
- ----
+ == Publishing channels for sa-update ==
+ See PublishingRuleUpdates.
- = Publishing channels for sa-update =
-
- Channels are fairly simple to setup and use. Simply put, updates are files contained in a standard tar.gz archive, distributed via HTTP. To allow for frequent update checks from clients, a lightweight method (DNS queries) is used to specify what update version is the latest for any given version of SpamAssassin. sa-update also uses a mirror file which lists all of the URLs where the update can be downloaded from, optionally including weights for different mirrors.
-
- == How does it work? ==
-
- When looking for an update, sa-update reverses the version and makes a DNS TXT query for ''<version>.<channel>''. ie: Running 3.1.1's sa-update, the default updates.spamassassin.org channel causes a DNS lookup for 1.1.3.updates.spamassassin.org. The query is for a TXT record containing the update number, which should be a monotonically increasing value. Assuming an update is necessary, sa-update will then read the MIRRORED.BY file (downloading it first if necessary from the URL found in a DNS TXT record ''mirrors.<channel>'').
-
- == Summary ==
-
- DNS Records:
- * mirrors.<channel> TXT "http://URL/TO/MIRRORS/FILE"
- {{{ mirrors.updates.spamassassin.org TXT "http://spamassassin.apache.org/updates/MIRRORED.BY" }}}
- * <version>.<channel> TXT "UPDATE_NUMBER"
- {{{ *.1.3.updates.spamassassin.org TXT "386156" }}}
-
- Mirrors file:
- * List of URLs which contain the updates
- {{{ http://buildbot.spamassassin.org.nyud.net:8090/updatestage/ }}}
-
- Update file:
- * Only files (no directories) contained in a tar.gz archive file named ''UPDATE_NUMBER.tar.gz''
- * A sha1sum file named ''UPDATE_NUMBER.tar.gz.sha1'' with the output of {{{ sha1sum UPDATE_NUMBER.tar.gz }}}.
- * Recommended, but optional, a detached GPG signature for the update named ''UPDATE_NUMBER.tar.gz.asc'' via something like {{{ gpg -bas UPDATE_NUMBER.tar.gz }}}
-
- == Examples ==
-
- Here is a short example of how an update for SpamAssassin 3.1.x would be published. By convention, we use the svn version of the directory as the update number.
-
- {{{
- $ svnversion
- 386156
- $ ls -al
- total 528
- drwxr-xr-x 3 felicity fame 4096 Mar 14 13:10 .
- drwxr-xr-x 4 felicity fame 27 Feb 19 14:55 ..
- -rw-r--r-- 1 felicity fame 5479 Feb 19 14:55 10_misc.cf
- -rw-r--r-- 1 felicity fame 8112 Mar 13 02:49 20_advance_fee.cf
- -rw-r--r-- 1 felicity fame 1602 Feb 19 14:55 20_anti_ratware.cf
- -rw-r--r-- 1 felicity fame 6690 Mar 13 02:49 20_body_tests.cf
- -rw-r--r-- 1 felicity fame 1534 Mar 13 02:49 20_compensate.cf
- [...]
- -rw-r--r-- 1 felicity fame 33266 Mar 11 18:13 50_scores.cf
- -rw-r--r-- 1 felicity fame 8564 Mar 14 13:10 80_additional.cf
- $ tar -cf 386156.tar *.cf
- $ ls -la 386156.tar
- -rw-r--r-- 1 felicity fame 471040 Mar 15 15:37 386156.tar
- $ gzip -9v 386156.tar
- 386156.tar: 74.1% -- replaced with 386156.tar.gz
- $ ls -la 386156.tar.gz
- -rw-r--r-- 1 felicity fame 122206 Mar 15 15:37 386156.tar.gz
- $ mv 386156.tar.gz /www/spamassassin/updates
- $ vi /var/named/updates.spamassassin.org
- [increase serial number, add in new update line '*.1.3 TXT "386156"']
- $ rndc reload
- }}}
-
- * What if I want to publish updates for some versions but not others?
-
- The answer is pretty simple and comes down to DNS records. As long as the reverse version DNS request does not return a TXT record, sa-update will consider there to be no updates available. ie: if we want to publish update 386156 for SpamAssassin 3.1.x, but not 3.1.0, we could use the following records:
-
- {{{
- 0.1.3 A 127.0.0.1
- *.1.3 TXT "386156"
- }}}
-
- When v3.1.0's sa-update looks for an update, it gets no TXT response (having an existing 0.1.3 record overrides the wildcard record), and therefore it sees no updates available. However, when v3.1.1 or above looks for an update, it gets "386156" returned.
== SARE Channels ==
@@ -208, +140 @@
Details of the rule-update generation backend at updates.spamassassin.org can be read at SaUpdateBackend.
- ----
-
TheoVanDinter
You have subscribed to a wiki page or wiki category on "Spamassassin Wiki" for change notification.
The following page has been changed by JustinMason:
http://wiki.apache.org/spamassassin/RuleUpdates
The comment on the change is:
split the RuleUpdates page into 2 publisher/user pages
------------------------------------------------------------------------------
Note: This page is under construction and shouldn't be considered "complete". If there are any questions, etc, please feel free to contact the users -at- spamassassin.apache.org list for more information.
-
- ----
== Notes / FAQ ==
@@ -130, +128 @@
The files from the update go into ''updates_spamassassin_org'', and the *.cf files are then included by ''updates_spamassassin_org.cf'', which also keeps track of what update version is installed. Therefore, if it is desired to change the update directory, the .cf and the update directory will exist there.
- ----
+ == Publishing channels for sa-update ==
+ See PublishingRuleUpdates.
- = Publishing channels for sa-update =
-
- Channels are fairly simple to setup and use. Simply put, updates are files contained in a standard tar.gz archive, distributed via HTTP. To allow for frequent update checks from clients, a lightweight method (DNS queries) is used to specify what update version is the latest for any given version of SpamAssassin. sa-update also uses a mirror file which lists all of the URLs where the update can be downloaded from, optionally including weights for different mirrors.
-
- == How does it work? ==
-
- When looking for an update, sa-update reverses the version and makes a DNS TXT query for ''<version>.<channel>''. ie: Running 3.1.1's sa-update, the default updates.spamassassin.org channel causes a DNS lookup for 1.1.3.updates.spamassassin.org. The query is for a TXT record containing the update number, which should be a monotonically increasing value. Assuming an update is necessary, sa-update will then read the MIRRORED.BY file (downloading it first if necessary from the URL found in a DNS TXT record ''mirrors.<channel>'').
-
- == Summary ==
-
- DNS Records:
- * mirrors.<channel> TXT "http://URL/TO/MIRRORS/FILE"
- {{{ mirrors.updates.spamassassin.org TXT "http://spamassassin.apache.org/updates/MIRRORED.BY" }}}
- * <version>.<channel> TXT "UPDATE_NUMBER"
- {{{ *.1.3.updates.spamassassin.org TXT "386156" }}}
-
- Mirrors file:
- * List of URLs which contain the updates
- {{{ http://buildbot.spamassassin.org.nyud.net:8090/updatestage/ }}}
-
- Update file:
- * Only files (no directories) contained in a tar.gz archive file named ''UPDATE_NUMBER.tar.gz''
- * A sha1sum file named ''UPDATE_NUMBER.tar.gz.sha1'' with the output of {{{ sha1sum UPDATE_NUMBER.tar.gz }}}.
- * Recommended, but optional, a detached GPG signature for the update named ''UPDATE_NUMBER.tar.gz.asc'' via something like {{{ gpg -bas UPDATE_NUMBER.tar.gz }}}
-
- == Examples ==
-
- Here is a short example of how an update for SpamAssassin 3.1.x would be published. By convention, we use the svn version of the directory as the update number.
-
- {{{
- $ svnversion
- 386156
- $ ls -al
- total 528
- drwxr-xr-x 3 felicity fame 4096 Mar 14 13:10 .
- drwxr-xr-x 4 felicity fame 27 Feb 19 14:55 ..
- -rw-r--r-- 1 felicity fame 5479 Feb 19 14:55 10_misc.cf
- -rw-r--r-- 1 felicity fame 8112 Mar 13 02:49 20_advance_fee.cf
- -rw-r--r-- 1 felicity fame 1602 Feb 19 14:55 20_anti_ratware.cf
- -rw-r--r-- 1 felicity fame 6690 Mar 13 02:49 20_body_tests.cf
- -rw-r--r-- 1 felicity fame 1534 Mar 13 02:49 20_compensate.cf
- [...]
- -rw-r--r-- 1 felicity fame 33266 Mar 11 18:13 50_scores.cf
- -rw-r--r-- 1 felicity fame 8564 Mar 14 13:10 80_additional.cf
- $ tar -cf 386156.tar *.cf
- $ ls -la 386156.tar
- -rw-r--r-- 1 felicity fame 471040 Mar 15 15:37 386156.tar
- $ gzip -9v 386156.tar
- 386156.tar: 74.1% -- replaced with 386156.tar.gz
- $ ls -la 386156.tar.gz
- -rw-r--r-- 1 felicity fame 122206 Mar 15 15:37 386156.tar.gz
- $ mv 386156.tar.gz /www/spamassassin/updates
- $ vi /var/named/updates.spamassassin.org
- [increase serial number, add in new update line '*.1.3 TXT "386156"']
- $ rndc reload
- }}}
-
- * What if I want to publish updates for some versions but not others?
-
- The answer is pretty simple and comes down to DNS records. As long as the reverse version DNS request does not return a TXT record, sa-update will consider there to be no updates available. ie: if we want to publish update 386156 for SpamAssassin 3.1.x, but not 3.1.0, we could use the following records:
-
- {{{
- 0.1.3 A 127.0.0.1
- *.1.3 TXT "386156"
- }}}
-
- When v3.1.0's sa-update looks for an update, it gets no TXT response (having an existing 0.1.3 record overrides the wildcard record), and therefore it sees no updates available. However, when v3.1.1 or above looks for an update, it gets "386156" returned.
== SARE Channels ==
@@ -208, +140 @@
Details of the rule-update generation backend at updates.spamassassin.org can be read at SaUpdateBackend.
- ----
-
TheoVanDinter