Installation Guides

Version 3 Upgrade Help

IMPORTANT! This page is out of date. We have left it in place in order to demystify the process.

IF YOU ARE UPGRADING FROM Version 2 to Version 3 ON WIN* - Use the windows installer from our products page. In virtually all cases the installer will take care of the following process for you.

IF YOU ARE UPGRADING FROM Version 2 to Version 3 ON *NIX - The distribution will provide you with control scripts and documentation for a wide variety of configurations. Start by reading the readme and other documentation and then proceed by running the familiar configure, make, make install process.

Use the information below as a reference to explain the differences between the old and new version and how those differences affect installations.

If you run into trouble please email support@ for assistance.

----

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 3.

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: one client and one server.
   
   Most folks would set up version 2 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 $%@*)#!

NOTE: Just in case you skipped to here please go back to the top of the page and read. This information is out of date. It has been left here in order to demystify the upgrade process -- especially for folks who may have unusual version 2 installations.

1. Download the latest version from the Products page.
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.
   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.
   2. Be sure that you have edited your getRulebase.cmd file with the correct path, your license id, and your authentication string.
   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.