Q & A Home
Customizing SNF
Errors
False Positives
Functionality
Integration
Log Files
Resellers
Result Codes
Rulebase Updates
Software
Spam
Subscriptions
Trials
Version 3 Architecture
Documentation Home
Software
Why are there so many places to configure paths in the setup?
This is an unfortunate, but necessary requirement. The price of flexibility is complexity.
The previous version of SNF did not offer any ability to move log and other files to alternate locations. This was one of our top feature requests. The new version allows many things to be moved to new locations if needed.
The default installation of SNF is to put all of the files in the same place -- in keeping with the way SNF has always been installed up to now (so that SNF users would be somewhat familiar with it). When SNF is divided into multiple locations there are many models to chose from.
It is likely that the update script might not be the one we've provided in the distribution and that it might perform a host of other functions that require it to be located explicitly outside of the SNF working or rulebase directories.
The script we provide is only a minimally functioning example that will do the basics for most of our customers (those that would not normally chose to move directories around for example).
You might be surprised to see some of the housekeeping, logging, analysis, reporting, and other functions that are often tied to update mechanisms used by some of our customers. It doesn't make sense for us to assume that every update mechanism must work like our getRulebase.cmd script nor can we make any hard assumptions about directory structures without reducing SNF's flexibility.
Many systems that use SNF do not or cannot follow a standard Windows tree structure. For example, on some linux systems the paths may end up being something like:
Configuration --> /etc/snf...and so on. You'll note that there are different roots to many of these paths. The SNF/Log, SNF/Workspace, SNF/Rulebase structure is nice (for Windows systems perhaps), but doesn't work for everyone. Since these configurations can vary so widely, any assumptions we might make about them would tend to be obstacles.
Workspace --> /var/spool/snfilter
Rulebase --> /home/snfilter
Logs --> /var/log/snf
The <update-script/> feature is designed to work with any update mechanism while providing some isolation between SNFServer and those programs. Our getRulebase script is just basic functional example. When installed automatically it works fine and no further tweaking is required. If it is moved then certainly it must be reconfigured.
When we considered passing configuration information to the update script through this feature we quickly realized that different scripts would have very different requirements and that passing information out of SNFServer to these scripts might represent a security vulnerability in some installations.
We opted for a simpler, more isolated approach that allows the update mechanism (whether a script or an application) to simply get the signal that an update is available. It is then free to take whatever actions its designers see fit to achieve the update - and the designers are then responsible for providing the configuration information for that mechanism. Here again we decided not make assumptions that might get in the way.
It's worth noting that our Windows installer configures all of these paths automatically. In practice, most Windows users never need to adjust any of these paths. The only time they would need to be modified is if/when the administrator wants to do something specific that is outside of the "normal" installation.