Time ripens all things…Miguel de Cervantes
This article is time sensitive and was last updated near the beginning of 2010.
DansGuardian follows the convention that versions 2.oddnum.x.x are “development/beta” while 2.evennum.x.x are “stable”. So when 2.9.x.x development “crystallized”, the tip was simply re-christened 2.10 (2.10 is not based on different code and is not discontinuous from 2.9 in some way). Development series are released frequently, typically every time new features are implemented. Stable series on the other hand are released only to incorporate important fixes. Typically there will only be a handful of releases in a stable series.
To find out what version you've got, first look at the comments at the top of /usr/local/etc/dansguardian/dansguardian.conf. This alone may be sufficiently indicative. But the actual code might have gotten out of sync with the configuration files. So to find out for sure exactly what version the actual code is, execute dansguardian -v.
In almost all cases deployments should use the 2.10.x.x software release. It contains several useful enhancements, has been deployed in many production environments, and is integrated into the official Smoothwall (and other) products.
The 2.10 series incorporates the ability to modify any URL. This capability, which can be used to force “safe search” for many searches, is a generalization of the old “Google patch”. The 2.10 series is particularly advantageous if you're going to implement "multiple filter groups" or in some other way make use of the “auth” mechanisms. Also, the 2.10 series implements the option of anti-virus scanning as a regular feature without requiring a “patch”. (Provided the package was built with scanning in mind, setting up A-V scanning involves nothing more than changing some options in the configuration file.) Especially relevant, the “sandwich” configuration with two copies of Squid is not necessary with the 2.10 series, not even with NTLM User Authentication.
Even though 2.10 was marked “stable”, it turned out to still hide a subtle but important bug that affected some systems where NTLM auth was enabled and users accessed https: sites. (Sites that do not have NTLM auth enabled or that do not access https: sites are not affected.) If you have NTLM enabled and access https: sites, you should use at least version 18.104.22.168, which includes a fix for this problem.
Development of the 2.9 series continued for several years (the reasons for the long 2.9 “development”, during all of which time 2.8 reigned as the “stable” verion, were non-technical). The 2.9 series used roughly the same codebase as 2.8, and it used approximately the same configuration files as 2.8. And 2.9's functionality quickly became a superset of 2.8. As a result, it made sense back then –even for production use– to get a recent “development” version rather than the “stable” version.
Fetching DansGuardian from a distribution's repository, only to find what was fetched was 22.214.171.124, was usually a WTF moment calling for special action. Sometimes a much more recent version was available from the distribution's “test” or “beta” repository. Sometimes an “unofficial” repository or collection had to be used. And sometimes it was necessary to get the source tarball and build DansGuardian yourself.
Which version isn't much of an issue right now, not like it once was. Most standard distribution repositories of stable versions now contain some version from the 2.10 series, which is current.
New development relevant to Linux systems may be done in a 2.11 series. Those who can handle “alpha” or “beta” testing and possible very significant changes to configuration files may wish to follow the 2.11 series.
Only important fixes will be integrated into the 2.10 series; it's suitable for routine production. Because handling of this series is quite conservative (especially since new development is done in the 2.11 series), there's almost no risk in deploying even the latest tip version 2.10.x.x.
In some cases a more recent release of DansGuardian is available from a distribution repository marked “testing” or “development”. However if you can't get a suitable version within the 2.10.x.x stable series from any of your distribution's repositories (or if you want to experiment with a 2.11.x.x development version and can't get it from your distribution), you may need to either fetch a more recent build outside your distribution's usual mechanisms or obtain the source code directly from the DansGuardian website and build it yourself. (Very complete and intelligent make files are provided, so building DansGuardian is usually quite simple.)
The configuration files for the 2.10.x.x series are not exactly upward compatible with those for the 2.8.x.x series (although they are quite similar). Do not attempt to simply run 2.10.x.x using your 2.8.x.x configuration files without tweaking.
(Configuration for the 2.11.x.x series will probably once again be different and not exactly compatible. But only the upgrade from the 2.8.x.x series to the 2.10.x.x series is covered in any detail here.)
A good procedure is to print out your 2.8.x.x *.conf files, install 2.10.x.x as though it were new, and edit the 2.10.x.x *.conf files from scratch using the 2.8.x.x printouts as a guide. (Of course you could also copy and paste relevant sections from one file to another.) Watch out for options that used to be “on” or “off”, but now have three or more possible numeric values - if you fail to update these, the net effect will be to set them to whatever choice corresponds to “0”.
You can use your existing *list files almost exactly as is. Note a few gotchas though:
- there are a few additional *list files in 2.10.x.x for which you won't have any previous analogue
- a couple 2.8.x.x *list files have been removed and do not have any analogue in 2.10.x.x
- in 2.10.x.x the *list files are in a slightly different location
(specifically they're now in a subfolder …/list)
Probably the easiest way to use your old *list files is to complete the installation of 2.10.x.x with all its initially empty *list files, then cp your existing *list files over top of their new location.
Use of the new …/list subfolder is largely transparent. If any of your *list files contain .Include references to other files though, those references may need to be modified to include the new subfolder in the path. Also, if you continue to use your old script for updating your blacklist subscription you may have a problem with the script placing the revised blacklist files into a different location than the new *list files look for them in. If so, one easy solution is to create a “symlink” pointing from the old location to the new location so old programs can continue to reference the old location.