Hello Sniffer Folks,

It turns out that our link to the Mail Archive has been off-line for a
bit and I'm still getting questions about the upgrade process so I'm
going to re-post the overview we published on 20080411. Here we go:

> I'm running win2003 with Imail, Mxguard v3.2 and Sniffer 2-3.2.  I set
> this up a ways back and have yet to upgrade to any of the beta client 
> versions primarily due to lack of documentation about exactly how to 
> accomplish the upgrade.

Similar questions are coming up quite a bit so I'm going to provide an
overview of the process here. Note that the SNFServer_readme.txt and
SNFClient_readme.txt files provide a great deal of information so
please do read them carefully.

The following is an overview for folks who have been using previous
command line versions of SNF (2.3x) and are now upgrading to the new
version 2-9rc (soon to be V3).

___________________________________
FIRST - SOME THINGS YOU SHOULD KNOW

There are to fundamental differences between the old version and the
new version that you need to be aware of:

1. The new version uses a Client - Server model and the old version
used a Peer - Server model. That means that with the old version you
could use one program to act as a server or client while the new
version has two programs that only do one thing each: either server or
client.

Most folks would set up the old version of SNF using a persistent
instance to improve performance. In that case the same program would
be called in two different ways with the persistent instance acting
like a server and the scanning instance (called by Declude, or
mxGuard, postfix, or some other program) acting like a client.

Persistent instance: <licenseid>.exe authenticationxx persistent

Scanning instance: <licenseid>.exe authenticationxx messagefile

The new version can be used the same way but you must use separate
programs such as:

Persistent instance: SNFServer.exe configurationfile

Scanning instance: SNFClient.exe messagefile

Note that it is also ok to do this:

Scanning instance: SNFClient.exe authenticationxx messagefile

or even this:

copy SNFClient.exe to <licenseid>.exe

Scanning instance: <licenseid>.exe authenticationxx messagefile

(( DON'T GO OFF AND DO THAT YET -- THERE IS A BETTER WAY ))

So, as long as you have the SNFServer running, you can use the
SNFClient in mxGuard, Declude, postfix, or other programs the same way
that you used the old version. If the new version gets an
authentication string on it's command line, it ignores it -- that way
it is backward compatible with the old version.

The trick is: You must have the SNFServer running with the new
version. The old version would load the rulebase itself and scan the
message if it did not find a "server instance". The new SNFClient
can't do that-- instead, it will wait while it tries to connect to
SNFServer, and if it can't it will return 0 (fail safe).

2. The new version includes an IP reputation system that learns as it
goes so you must tell it about your network if you have any gateways
or other systems that you don't want it to learn about.

____________________________________________________
SO HOW DO I UPGRADE WITH THE LEAST AMOUNT OF [EMAIL PROTECTED])#!

1. Download the latest version (StdTestPackage) from here:

http://kb.armresearch.com/index.php?title=Message_Sniffer.GettingStarted.Distributions#NEW_SNF_V2-9_Wide_Beta

2. Create a SNF folder in the appropriate place on your system. This
should be at the same level as your current sniffer installation. That
said, it really doesn't matter where you put it - so whatever works
for you is fine.

3. Copy all of the files in the distribution to your SNF folder.

4. Read through the SNFServer_readme.txt file and follow it's
instructions to set up your snf_engine.xml, identity.xml, and
GBUdbIgnoreList.txt files.

Most folks will only have to put their licenseid and authentiction
string into their identity.xml file, and update the paths at the top
of the snf_engine.xml file.

If you have gateways and other systems that you need to ignore as
infrastructure then you will need to modify the GBUdbIgnoreList.txt
file and possibly the <drilldown/> section of your snf_engine.xml
file.

5. ** We recommend that you also set up the new automated update
system which consists of the <update-script/> section of the
snf_engine.xml file and the getRulebase.cmd script.

5.1. Be sure that the full path to the getRulebase.cmd script is
correct in the <update-script/> section of your snf_engine.xml file.

5.2. Be sure that you have edited your getRulebase.cmd file with the
correct path, your license id, and your authentication string.

5.3 You can test the getRulebase.cmd script by creating an
UpdateReady.txt file in your SNF directory and then running the
getRulebase.cmd script. It should download a fresh copy of your
rulebase file and you should be able to see it do this on your screen.

6. Test your SNFServer installation by running it from your command
line. If you've installed your SNF in C:\SNF then do this:

C:\SNF\SNFServer.exe C:\SNF\snf_engine.xml

You should either see SNFServer start up and begin showing you
real-time status information or you will see an exception that tells
you what is broken. The two most common problems are:

* The paths in the snf_engine.xml are not correct.

* The rulebase file is missing. If you did step 5 then you should have
a rulebase file in the right place.

7. With your SNFServer up and running (in a dos window for now) you
can run SNFClient to scan messages.

8. In Declude, or mxGuard, or postfix, etc... you will have a line
that calls your old sniffer program. Comment that line out and make a
new one that calls the new sniffer program instead. YOU DO NOT NEED TO
SHUT DOWN YOUR OLD SNF INSTALLATION -- This way you can go back to it
immediately if you're having trouble. Here are some examples:

_______
Declude:

SNIFFER external nonzero "c:\imail\declude\sniffer\<licensid>.exe ..."

becomes

SNIFFER external nonzero "c:\imail\declude\SNF\SNFClient.exe"

_______
mxGuard:

PathToEXE=C:\IMail\Sniffer\efdsxfeff3.exe

becomes

PathToEXE=C:\IMail\SNF\SNFClient.exe

_______
postfix:

You may want to consider reworking your sniffer script, but if not...

SNIFFER_EXE=/var/spool/snfilter/snfrv2r3.exe

becomes

SNIFFER_EXE=/var/spool/snfilter/SNFClient.exe

9. Once you've updated your scanning software to use the new SNFClient
you should be able to see the statistics change on the SNFServer
(remember we left that running?). If not, check to see that your
scanning software is set up properly -- sometimes you need to restart
services for them to see new settings, for example.

10. The new version produces the same result codes that the old
version did with a few exceptions. The new version also produces
result code 20 (truncate) and result code 40 (caution). You should
account for these in your program of choice if you apply separate
weights to SNF result codes. 20 should be weighted as high as the
highest SNF value and 40 should be weighted at least as high as the
lowest SNF value on your system.

11. Once you have all of this working you will probably want to set up
the new SNFServer to run as a service. On *nix systems we've provided
a handy snfctrl script to use as a template. On win* systems you will
want to set up SNFServer the same way you set up your persistent
instance (using srvany, XYNTService, FireDaemon, etc...) The only real
differences will be the command line and the name (so that it doesn't
conflict with your existing SNF installation).

If you're used to using srvany then first reference this article:

http://kb.armresearch.com/index.php?title=Message_Sniffer.TechnicalDetails.Persistent.Setup#Setup_Instructions_for_running_Persistent_Sniffer_as_a_service_using_the_Windows_2003_Resource_Kit

In step 3) in the example...

C:\> Instsrv Sniffer "C:\Program Files\Windows Resource Kits\Tools\SRVANY.exe"

becomes

C:\> Instsrv SNFServer "C:\Program Files\Windows Resource Kits\Tools\SRVANY.exe"

In step 9) in the example...

C:\IMail\Declude\Sniffer\[yourlicx].exe [authenticationxx] persistent

becomes

C:\IMail\Declude\SNF\SNFServer.exe C:\IMail\Declude\SNF\snf_engine.xml

12. You will need to shut down the SNFServer we started earlier.
Before doing that you may want to stop SMTP so that SNFClient
instances don't build up -- just in case something goes wrong ;-) Once
you're ready, the clean way to shut down SNFServer is with the
SNFClient using:

SNFClient -shutdown

You will see the shutdown progress on the SNFServer screen.

13. Once the old test SNFServer has been shut down you can start your
new SNFService.

14. HOW DO I KNOW IT'S WORKING? You can check to see that it's up and
running with SNFClient this way:

SNFClient -status.second

You should get back some XML data showing the current message rates
and some other information. If SNFServer is not running you will get
nothing back and your errorlevel will not be zero. You can see your
errorlevel on win* using:

echo %errorlevel%

on *nix something like:

echo $?

15. You can monitor the activity of your SNFServer by opening the
status.second report in your browser and refreshing it periodically.
status.minute is usually easier to understand. You can (as shown
above) get these status reports using the SNFClient also.

16. You can shut down your old version of SNF at any time once you're
satisfied that the new version is working correctly for you. Until
then you can switch back quickly if you have trouble by changing your
scanning software's setup (see step 8. above). The two versions will
not interfere with each other.

----

That's it for the overview. The above is not perfect - you may need to
"read between the lines" a bit, but it should be close enough for most
folks and should clarify any questions you have along the way. Please
let us know how this goes for you -- we are working on documentation
and our new web site right now and your input will make it into our
work.

Thanks!

_M

-- 
Pete McNeil
Chief Scientist,
Arm Research Labs, LLC.



#############################################################
This message is sent to you because you are subscribed to
  the mailing list <sniffer@sortmonster.com>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>

Reply via email to