Pete,
I upgraded to the latest getRulebase file and followed the instructions, but
now all I see on my windows system (DST) is the following: (I replaced my
license ID # with xxxxxxxx)
snf2check: xxxxxxxx.new ERROR_RULE_FILE!
1 file(s) copied.R:2349772 [0/12 - 0] W:0 C:0 B:0 T:0 S:0
snf2check: xxxxxxxx.new ERROR_RULE_FILE!
1 file(s) copied.R:2349772 [0/12 - 0] W:0 C:0 B:0 T:0 S:0
over and over again for pages and pages in my console window.
Everything worked great until I updated to the latest getRulebase. My
license ID and everything are all the same and I re-verified them after I
copied the info from the other getRulebase script.
What is causing this?
Thanks,
Shawn
On Mon, Mar 9, 2009 at 2:44 PM, Pete McNeil <madscient...@armresearch.com>wrote:
> Hello Sniffer Folks,
>
> DST Update Problem: A bug in the old getRulebase.cmd script caused Win*
> systems to discard the server's timestamp on rulebase files and substitute
> the local timestamp. As a result any system that change to DST (daylight
> savings time) after our rulebase delivery servers would continuously show a
> newer rulebase file on our servers. As a result these systems would
> repeatedly download the rulebase file as quickly as they could.
>
> Solutions:
>
> 1. Everyone should upgrade their getRulebase.cmd script to the latest
> version:
> http://www.armresearch.com/message-sniffer/download/CURL-getRulebase.zip
>
> ** Note that most *NIX systems do not have the same problem with wget, but
> everyone should check.
> *** Note that going forward a CURL based update script is preferred. Since
> CURL is available on most *NIX systems by default we do not expect this to
> be a problem.
>
> 2. If not upgrading to the latest version then they should modify their
> wget based scripts to ensure that the server's timestamp on the rulebase
> file is preserved.
>
> 3. Since many systems will not be upgraded in the short term, we are also
> taking action on the delivery server to prevent problems with ruelbase
> updates: From now on a new rulebase will show it's new timestamp for 5
> minutes after it is posted. Then the timestamp will be pushed back one hour
> to limit the amount of time systems with later DST transitions will see the
> files as new.
>
> The results of this change will be:
>
> * Systems that have upgraded to the new getRulebase.cmd script or are using
> an otherwise correct update script will see no difference. By default,
> SNFSync events occur about once per minute and since the new rulebase file
> will be shown with it's current timestamp for 5 minutes each correctly
> configured SNF node will see and download the fresh rulebase file as soon as
> it is available.
>
> * Some systems that have not upgraded may attempt to download a new
> rulebase file twice, or possibly three times depending upon timing. However
> after that time (based on a 180 second guard time) these systems should
> cease to see the rulebase files as new and will stop trying to download the
> files. Once these systems move to DST they will operate normally. Of course
> we hope that all systems will upgrade their update scripting before this!
>
> * Systems that are using a scheduled task to update their rulebase may
> sometimes see the newer time stamp and may sometimes see the delayed (one
> hour old) timestamp. This will cause update lag to shift in time with an
> average of 30 minutes.
>
> At this time this seems to be the best compromise for everyone.
>
> We apologize for any inconvenience.
>
> Thanks,
>
> _M
>
>
>
>
> #############################################################
> This message is sent to you because you are subscribed to
> the mailing list <sniffer@sortmonster.com>.
> To unsubscribe, E-mail to: <sniffer-...@sortmonster.com>
> To switch to the DIGEST mode, E-mail to <sniffer-dig...@sortmonster.com>
> To switch to the INDEX mode, E-mail to <sniffer-in...@sortmonster.com>
> Send administrative queries to <sniffer-requ...@sortmonster.com>
>
>
