To start, again, I have *nothing* against RDJ. I just like things to be
as efficient as practical (it's how I live and make a living), which is
why I like sa-update. I'll explain why sa-update is more efficient...
Bowie Bailey wrote:
I don't know that there is much difference in the configuration
required. For sa-update, you create a file with a list of rulefiles.
For RDJ, you create a file with a list of rulefiles and a restart
command.
I agree. When it comes to rulesets already supported by RDJ selecting
which rulesets to use are pretty much on an equal config basis.
RDJ has the benefit of being able to update any plain .cf file available
via HTTP. The downside is, you either need to modify the script for
not-yet-supported rulesets or wait for an update.
sa-update has the benefit of not needing to be updated for new channels.
You simply add the channel to your config. The downside is the
rulesets have to be available in channel form. However, channel files
are really easy to make and can be trivially scripted and automated.
They are both good. RDJ was made to deal with third party rulesets
and it does a good job. sa-update was made to deal with official
ruleset updates and has been extended to also handle third party
rulesets.
Not really important, but sa-update has always supported channels from
anyone... no extending required. :)
RDJ has the advantage that it can update almost any ruleset that is
available on the web.
sa-update has the advantage of also updating the official rules. The
downside is that you have to create channels for new rulesets, so it
isn't quite as simple as creating the ruleset and making it available
on the web.
While true, you need to make a tarball, sign the tarball, and generate a
sha1 hash of the tarball (3 commands total, all scriptable) and update
DNS (also scriptable) the pay-offs are huge infrastructure wise.
Since sa-update uses DNS to determine if there are new updates for a
channel, users can check for updates more often without causing a
significant increase in use of the channel providers resources.
By adjusting TTLs to a value that they can comfortably support (HTTP
server resource wise) the channel provider can provide updates faster
while preventing what could effectively turn into a DDoS if their
clients were using RDJ and a check interval of only a few minutes.
In the case of the channels I provide for the SARE rulesets, if you want
to run sa-update every few minutes go for it. The current TTL on those
zones is an hour, so you're worst case wait time for new updates for
those channels is an hour (plus the maximum of 21 minutes for my server
to notice that there's been new updates). Compared to a worse case wait
time of 24 hours for SARE rules via RDJ, you'll be getting updates via
the sa-update channel a lot faster. If rules are updated at random
times throughout the day, you're looking at an approx 40 minute delay
via sa-update and a 12 hour delay via RDJ.
Not as long as people continue to use it. Quite a few of us (me
included) see no reason to switch.
I also expect that RDJ will be in use for quite some time, especially
with all those 2.x and 3.0.x users out there. Although, with engine
software that old, I'm not too sure why they're all too concerned with
automated updates. :)
Daryl
