https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6134
Summary: Assist DCC plugin in finding dcc's homedir
Product: Spamassassin
Version: 3.2.5
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P5
Component: Plugins
AssignedTo: [email protected]
ReportedBy: [email protected]
Created an attachment (id=4462)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4462)
Add a routine to DCC.pm to search for dcc's homedir
DCC may be accessed either through the dccproc command line utility, or via the
DCC interface daemon, dccifd. By default, dccifd creates a socket in DCC's
homedir.
In SpamAssassin's DCC configuration, DCC's homedir and the path to the dccifd
socket may be specified. In SA's default config, neither have default values.
When the plugin is initialized, it first tries to connect to dccifd's socket.
If that fails, it falls back to dccproc. When the plugin tries to connect to
the dccifd socket, it search two places: $dcc_dccifd_path, if the admin
specified the path to the socket, and ${dcc_home}/dccifd. As such, if neither
dcc_dccifd_path nor dcc_home are set by the admin, the dccifd socket will never
be found and dccproc will always be used.
Constantly spawning dccproc instances causes higher load on both the SA box, as
well as on the DCC public servers. Because of this, if dccproc is called
often, it will automatically start up dccifd in the hope that the caller will
use it if it's present. As it stands, however, this optimization is of no use
to a default SpamAssassin configuration.
To make the usage of DCC under SpamAssassin a little easier out-of-the-box, if
dcc_home is not set, we can have the plugin attempt to find DCC's homedir
itself.
One of the DCC utilities, cdcc, includes a command to print out the home
directory that the DCC pacakge was compiled with. If cdcc is available, then
we can simply ask it what DCC's homedir is. If cdcc is not available, or if
cdcc's reported directory doesn't exist, then we can see if DCC's default
homedir, /var/dcc, exists. If it does, we can try that.
If an admin turns on DCC and then simply trusts SpamAssassin to do the right
thing, this modification will at least give SA a fighting chance at finding and
using dccifd. If worse comes to worst, the end result will be no different
than current operation -- dccifd's socket will not be found in either case and
the plugin will simply fall back to dccproc.
My code in the attached patch is fairly simple, and I've tried to mimic the
style in the rest of the plugin. This is my first attempt at writing code for
SA, however, and I may have gotten something wrong. It's against 3.2.5, but
will apply to the 20090616151200 SVN snapshot with a bit of offset.
--
Configure bugmail:
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
