The November 24, 2005 version (1.61.13) of FILTSRV.NLM is included in the BM38SP4_IR2
patch. This version of FILTSRV has the ability to work by using ONLY the SYS:ETC\FILTERS.CFG file,
if you load the program with a command line parameter, or if you use the SET FILTSRV NONDS=ON
parameter. This option can have dramatic repercussions as discussed below. What it means is that
the filtering data is no longer read from NDS, but instead is read only from the filters.cfg file.
Since BorderManager 1.0, and all the way up through BorderManager 3.6, Novell packet
filters were stored in one place - the SYS:ETC\FILTERS.CFG file. There was only one utility that was
used to configure filtering - FILTCFG.NLM. This system was *extremely reliable*. I love using
FILTCFG as it is fast, reliable, simple, and for me very, very easy to use and understand. However,
some people did not like it, and requested a GUI-based system. I suspect they did not understand
filtering and really wanted a wizard to do it for them.
Responding to repeated user requests, Novell added GUI-based filtering capability with BorderManager
3.7. However, Novell's engineers had a serious issue - they were constrained by management dictates
that new management utilities be performed by iManager. This was in order to move to a single cross-
platform management utility that was (eventually) not dependent on using a Windows PC. iManager has
plenty of good things going for it, and has been getting both more useable and more reliable, but it
essentially only has the ability to manipulate NDS objects. And there we have the core issue - if
iManager was to be used to manipulate filters, the filters had to be moved into NDS.
As almost anyone who has worked extensively with BorderManager 3.7 & 3.8 knows, there are a host of
issues that can, and do, come up with filters having NDS (sorry - eDirectory) dependencies. These
issues and troubleshooting information are discussed in my BorderManager filtering book. Suffice
to say here that problems with NDS often resulted in problems with filters, including the inability
to change or delete certain filters, the inability to change, delete or add filters if time is out
of sync, and partial or complete loss of filtering due to NDS problems. Thankfully, if you have a
good backup if the filters.cfg file, you can perform a FILTSRV MIGRATE -CF procedure to get filters
back they way they were.
Stay with me - now I explain how information gets into filters.cfg, and it is important.
It used to be that if you used only iManager, your changes did not get written to the filters.cfg
file. (If you used FILTCFG, it always automatically wrote the filters to filters.cfg when it is
was loaded, or you could use a FILTSRV_BACKUP command to have the file written out as well. It is
highly recommended to get a backup of the filters.cfg file every time you update it). However, at
some patch level, FILTSRV.NLM got changed to also write to the FILTERS.CFG file. So if you make a
change in NDS, your changes will be written to the filters.cfg file if FILTSRV.NLM is loaded.
OK - so with BorderManager 3.7 and 3.8, you can use either iManager or FILTCFG to manipulate filters,
but filters are always read from NDS, unless you have an old FILTSRV.NLM on your server. (Which can
happen with in-place upgrades to NetWare 6.5). And if you have problems with filters in NDS, they
can be reflected in your filters.cfg file as well.
You now know that with the 3.7/3.8 system of having filters stored in NDS, the filters are only read from NDS, and that is done using FILTSRV.NLM. With the NEW parameter for FILTSRV, you completely revert to the old BorderManager 3.0-3.6 way of doing filtering - all information is read from SYS:ETC\FILTERS.CFG. On the face of it, this is great, unless you like to use iManager for manipulating your filters. With one change, you eliminate all dependencies on NDS being correct to have your filters working, which greatly increases their reliability. It does mean you must use FILTCFG to manipulate the filters, and it also means you can have completely different filtering information (or none at all) stored in NDS (and not being used).
We all know that things don't always work all the time, servers crash, and 'stuff
happens'. The specific issue I worry about here is a server crash that results in you losing the
NetWare registry, or any issue that results in you losing your SET parameters.
IF YOU LOSE THE SET FILTSRV NONDS=ON PARAMETER, YOUR FILTERS SUDDENLY ARE READ FROM NDS AGAIN!
This means that whatever you had in your FILTERS.CFG file is gone - replaced by whatever you had in
NDS. If you never used iManager, or never set up filters on your server without the NONDS parameter,
you will have no filters at all. In fact, in some cases it is possible you will be wide open,
(empty NBMRuleContainer), while in other cases you may be completely locked down (no NBMRuleContainer)
at all. Or you might revert to the filter exceptions you had in place when you first enabled the
NONDS option.
Certainly it is a good idea to have a current backup of the filters.cfg file, so that you can recover.
Novell has told me that in the future they are going to try to have some way of two-way synch, so
that changes to the filters.cfg file can be pushed up into NDS. That would probably make things a
lot more fault-tolerant.