Bug 622063 - dspam cssclean binary not found in default dspam RPM install
dspam cssclean binary not found in default dspam RPM install
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: dspam (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Nathanael Noblet
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-06 19:12 EDT by Gary Funck
Modified: 2018-04-11 10:45 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-28 10:53:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gary Funck 2010-08-06 19:12:15 EDT
Description of problem:
After installing the dspam package under Fedora Core 13 (FC13),
the dspam daily cron job failed, becuase it could not locate
the cssclean executable.

The apparent cause of this error is that the dspam-hash RPM
must also be installed, because it includes the csscleam
executable.

The dspam_hash package also installs the libhash_drv.so driver,
which is specified in the default /etc/dspam.conf configuration
file.  It seems that the dspam package by default requires the
dspam_hash package?

Version-Release number of selected component (if applicable):
dspam-3.9.0-7.fc13.x86_64

Steps to Reproduce:
Install dspam RPM, but do not install dspam-hash RPM.
  
Actual results:
Received the following error message from /etc/cron.daily/dspam:

DSPAM cssclean binary not found!
Hash storage driver detected (not running dspam_clean)

Expected results:
dspam cron job finishes without error.
Comment 1 Stevan Bajić 2010-08-09 12:25:47 EDT
You don't need the dspam-hash package to run DSPAM. You could use it but you could use any of the other storage backends that are available in Fedora:

dspam-sqlite3
SQLite v3.x storage driver for libdspam
SQLite v3 storage driver for libdspam. The driver is not thread-safe and should not be used in DSPAM server daemon mode.

dspam-mysql
MySQL storage driver for libdspam
MySQL driver for libdspam. The driver is thread-safe (required for running DSPAM in server daemon mode).

dspam-pgsql
PostgreSQL storage driver for libdspam
PostgreSQL storage driver for libdspam. The driver is thread-safe (required for running DSPAM in server daemon mode).

dspam-hash
Hash storage driver for libdspam
The self-contained Hash-Based driver (inspired by Bill Yerazunis' CRM Sparse Spectra algorithm) is the fastest solution by far and requires no dependencies, supports an auto-extend feature to grow the file size as needed, and is very fast and compact. It does, however, lack some features (such as merged groups support) and uses a lot of memory to mmap() users. The driver is thread-safe (required for running DSPAM in server daemon mode).



For DSPAM to work you should have at least one of the above mentioned storage backends installed. You can install all of them if you like or just one.
Comment 2 Gary Funck 2010-08-09 13:16:48 EDT
(In reply to comment #1)
> You don't need the dspam-hash package to run DSPAM. You could use it but you
> could use any of the other storage backends that are available in Fedora:
[...] 
> For DSPAM to work you should have at least one of the above mentioned storage
> backends installed. You can install all of them if you like or just one.

Thanks for info. I was aware of the need for a storage engine, and that
there are several of them.  This problem report documents an error condition
that occurs when only the dspam package is installed.  The cron job that is installed with the dspam package has an implicit dependency upon
the hash storage engine, because it installs cssclean, and the
cron job executes cssclean.  One possible fix is to move the cron job
into the dspam_hash package.  Another fix is that the dspam package
requires the dspam_hash package (as the default storage engine).
Comment 3 Nathanael Noblet 2010-08-09 13:32:45 EDT
The fix that will likely happen is that the cron job will get smarter, and not complain if it can't find cssclean, as without a backend, the cron job does nothing anyway.
Comment 4 Stevan Bajić 2010-08-09 13:35:46 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > You don't need the dspam-hash package to run DSPAM. You could use it but you
> > could use any of the other storage backends that are available in Fedora:
> [...] 
> > For DSPAM to work you should have at least one of the above mentioned storage
> > backends installed. You can install all of them if you like or just one.
> 
> Thanks for info. I was aware of the need for a storage engine, and that
> there are several of them.  This problem report documents an error condition
> that occurs when only the dspam package is installed.  The cron job that is
> installed with the dspam package has an implicit dependency upon
> the hash storage engine, because it installs cssclean, and the
> cron job executes cssclean.  One possible fix is to move the cron job
> into the dspam_hash package.  Another fix is that the dspam package
> requires the dspam_hash package (as the default storage engine).    

The cron job does NOT depend on the hash driver. Could you tell me what you have in dspam.conf under the entry "StorageDriver"? And could you post the output of "dspam --version"?
Comment 5 Nathanael Noblet 2010-08-09 13:44:37 EDT
@Stevan, the issue isn't the dependence. The issue is he installed *only* the dspam package, which installs a cron job, and that maintenance script expects cssclean, since the default dspam.conf file has the hash driver in it by default, however we don't install the has driver, so the script tries to run cssclean. If the maintenance script checked for the existence of cssclean before trying to execute it... that would probably be good.
Comment 6 Stevan Bajić 2010-08-09 13:56:01 EDT
(In reply to comment #5)
> @Stevan, the issue isn't the dependence. The issue is he installed *only* the
> dspam package, which installs a cron job, and that maintenance script expects
> cssclean, since the default dspam.conf file has the hash driver in it by
> default, however we don't install the has driver, so the script tries to run
> cssclean. If the maintenance script checked for the existence of cssclean
> before trying to execute it... that would probably be good.    

This is in fact what the maintenance script is doing:
if [ -e ${DSPAM_BIN_DIR}/cssclean ]
then
  if ! check_for_tool find
  then
    [ "${VERBOSE}" = "true" ] && echo "  Can not run cleanup without 'find' binary"
    myrc=1
  else
    find ${DSPAM_HOMEDIR}/data/ -maxdepth 4 -mindepth 1 -type f -name "*.css" | while read name
    do
      ${DSPAM_BIN_DIR}/cssclean "${name}" 1>/dev/null 2>&1
    done
  fi
else
  [ "${VERBOSE}" = "true" ] && echo "  DSPAM cssclean binary not found!"
fi
Comment 7 Gary Funck 2010-08-09 14:02:49 EDT
(In reply to comment #4)
> The cron job does NOT depend on the hash driver. Could you tell me what you
> have in dspam.conf under the entry "StorageDriver"? And could you post the
> output of "dspam --version"?    

# rpm -Vc dspam
# grep -B5 -n ^StorageDriver /etc/dspam.conf 
24-#
25-# IMPORTANT: Switching storage drivers requires more than merely changing
26-# this option. If you do not wish to lose all of your data, you will need to
27-# migrate it to the new backend before making this change.
28-#
29:StorageDriver /usr/lib64/dspam/libhash_drv.so

Near as I can tell, that's the default config. file, and
it references the hash storage driver.  That, and the reference
to cssclean in the cron job both are dependencies, IMHO.

BTW, doesn't it make sense to install the dspam_hash package
by default?  That way the user has something that works out
of the box, and that is probably good enough for most
installations?
Comment 8 Stevan Bajić 2010-08-09 14:13:12 EDT
(In reply to comment #7)
> (In reply to comment #4)
> > The cron job does NOT depend on the hash driver. Could you tell me what you
> > have in dspam.conf under the entry "StorageDriver"? And could you post the
> > output of "dspam --version"?    
> 
> # rpm -Vc dspam
> # grep -B5 -n ^StorageDriver /etc/dspam.conf 
> 24-#
> 25-# IMPORTANT: Switching storage drivers requires more than merely changing
> 26-# this option. If you do not wish to lose all of your data, you will need to
> 27-# migrate it to the new backend before making this change.
> 28-#
> 29:StorageDriver /usr/lib64/dspam/libhash_drv.so
> 
So the hash driver is selected by default.


> Near as I can tell, that's the default config. file, and
> it references the hash storage driver.  That, and the reference
> to cssclean in the cron job both are dependencies, IMHO.
> 
Repeat after me: THERE IS NO HARD DEPENDENCY INSIDE THE MAINTENANCE/CRON JOB FILE!

If you select the storage driver to be hash THEN the cron job file will look for cssclean. If you select another storage backend THEN the cron job file WILL NOT look for cssclean. That simple.

Switch that StorageDriver entry to /usr/lib64/dspam/libmysql_drv.so and re-run the cron job. You will see that it now requires the "mysql" binary and it will NOT bark about missing cssclean. Switch it to /usr/lib64/dspam/libpgsql_drv.so and it will bark about missing "psql" binary. etc....


> BTW, doesn't it make sense to install the dspam_hash package
> by default?  That way the user has something that works out
> of the box, and that is probably good enough for most
> installations?    

I don't know Fedora policies regarding what to include as dependency and what not.
Comment 9 Nathanael Noblet 2010-08-09 15:53:15 EDT
@stevan... I've spoken with fedora-devel people, and we agreed that the best case is to have a default dspam.conf that doesn't specify any driver at all, and modify it to provide information on how to select a driver... I'm wondering what the cron job file will do if I comment out the driver line vs removing it... 

Which would be the best way to make the cron job just be silent if there is no configured backend? I could even just add a line 'Example' before the commented driver line like they do in clamav packages so that you have to remove that before anything functions... 

What do you think?
Comment 10 Stevan Bajić 2010-08-09 16:16:29 EDT
(In reply to comment #9)
> @stevan... I've spoken with fedora-devel people, and we agreed that the best
> case is to have a default dspam.conf that doesn't specify any driver at all,
> and modify it to provide information on how to select a driver... I'm wondering
> what the cron job file will do if I comment out the driver line vs removing
> it... 
> 
Nothing will happen if you comment the driver out. At least no maintenance will be done.



> Which would be the best way to make the cron job just be silent if there is no
> configured backend? I could even just add a line 'Example' before the commented
> driver line like they do in clamav packages so that you have to remove that
> before anything functions... 
> 
> What do you think?    

Just comment out the line and that will silence the maintenance script.
Comment 11 Gary Funck 2010-08-09 16:35:54 EDT
(In reply to comment #8)
> (In reply to comment #7)
> > Near as I can tell, that's the default config. file, and
> > it references the hash storage driver.  That, and the reference
> > to cssclean in the cron job both are dependencies, IMHO.
> > 
> Repeat after me: THERE IS NO HARD DEPENDENCY INSIDE THE MAINTENANCE/CRON JOB
> FILE!
> 
> If you select the storage driver to be hash THEN the cron job file will look
> for cssclean. If you select another storage backend THEN the cron job file WILL
> NOT look for cssclean. That simple.

OK, I understand the situation now.  Sorry for adding to confusion.
Is it correct to say that the maintenance script assumes that cssclean
is present if the hash driver was selected in the /etc/dspam.conf file?

BTW, I tried commenting out the storage driver config. directive,
and the dspam_stats command (for example) just hangs.  If the default
is going to be that *no* storage driver is specified in the config.
file, then a failure mode where dspam just hangs is likely to cause
some maintenance/support issues.  My recommendation is that the
hash storage engine be selected by default (as it is now), *and*
that the dspam_hash RPM is installed as a dependency.
Comment 12 Nathanael Noblet 2010-08-09 16:45:03 EDT
@Gary

Yes the cron job parses the dspam.conf looking for the driver to determine what to run.

I will likely push an update that removes the storage backend from dspam.conf and adds a note there specifying that a driver must be installed/configured to function. As this is a complex piece of mail filtering software, I don't think I would expect an admin to install dspam, not configure it at all and run dspam_stats.

I don't want dspam-hash installed by default as a requirement to dspam, since you then if you ever don't want that installed, you can't. There is no requirement to have the hash driver installed, just a requirement to have *one* driver installed. A user installing dspam should be knowledgeable enough to decide which driver on their own, and not expect to install dspam and configure nothing and have a working filtering system. As such, having a note in the dspam.conf file as to what driver packages are available should solve this problem.. should it not?
Comment 13 Stevan Bajić 2010-08-09 16:52:23 EDT
(In reply to comment #11)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Near as I can tell, that's the default config. file, and
> > > it references the hash storage driver.  That, and the reference
> > > to cssclean in the cron job both are dependencies, IMHO.
> > > 
> > Repeat after me: THERE IS NO HARD DEPENDENCY INSIDE THE MAINTENANCE/CRON JOB
> > FILE!
> > 
> > If you select the storage driver to be hash THEN the cron job file will look
> > for cssclean. If you select another storage backend THEN the cron job file WILL
> > NOT look for cssclean. That simple.
> 
> OK, I understand the situation now.  Sorry for adding to confusion.
> Is it correct to say that the maintenance script assumes that cssclean
> is present if the hash driver was selected in the /etc/dspam.conf file?
> 
Yes! Finally you get it! Selecting in stock DSPAM the hash driver automatically installs the tools needed for maintenance of the hash storage backend (aka: cssclean, csscompress, cssconvert and cssstat).


> BTW, I tried commenting out the storage driver config. directive,
> and the dspam_stats command (for example) just hangs.  If the default
> is going to be that *no* storage driver is specified in the config.
> file, then a failure mode where dspam just hangs is likely to cause
> some maintenance/support issues.  My recommendation is that the
> hash storage engine be selected by default (as it is now), *and*
> that the dspam_hash RPM is installed as a dependency.    

Usually having NO StorageDriver in dspam.conf is telling DSPAM to use the statically into DSPAM linked driver. But as the RPM is build with dynamically loaded drivers there is nothing statically linked into DSPAM.

However... dspam_stats should not hang. At least it would be better to print out a error message or something like that if no StorageDriver is selected and there is no statically linked storage driver available.
Comment 14 Stevan Bajić 2010-08-09 17:35:27 EDT
Here you go:
http://dspam.git.sourceforge.net/git/gitweb.cgi?p=dspam/dspam;a=commit;h=8e54d084665083aedefc8156d35af1779c8f493e

I fixed that hang/segmentation fault if no StorageDriver is selected AND no driver is statically linked into DSPAM.
Comment 15 Gary Funck 2010-08-09 22:34:56 EDT
(In reply to comment #12)
> @Gary
> 
> Yes the cron job parses the dspam.conf looking for the driver to determine what
> to run.
> 
> I will likely push an update that removes the storage backend from dspam.conf
> and adds a note there specifying that a driver must be installed/configured to
> function. As this is a complex piece of mail filtering software, I don't think
> I would expect an admin to install dspam, not configure it at all and run
> dspam_stats.

My expectation/hope after installing the dspam package is that it is
functional, and that the default configuration will work out of the box.
If it does not work out of the box, my expectation/hope is that the
various dspam-related tools will issue a clear error message
along the lines: "No storage engine supplied.  Please specify a storage
engine in /etc/dspam.conf and try again".

But frankly that seems overly complicated.  Why not
statically link the hash storage engine into dspam, as built
in the dspam RPM?  This will supply a reasonable default behavior without
the user/admin doing anything.  In that scenario, there is no need for
a dspam-hash package.  Only the additional/optional storage engines will
be supplied as separate packages.
Comment 16 Stevan Bajić 2010-08-10 01:41:30 EDT
(In reply to comment #15)
> (In reply to comment #12)
> > @Gary
> > 
> > Yes the cron job parses the dspam.conf looking for the driver to determine what
> > to run.
> > 
> > I will likely push an update that removes the storage backend from dspam.conf
> > and adds a note there specifying that a driver must be installed/configured to
> > function. As this is a complex piece of mail filtering software, I don't think
> > I would expect an admin to install dspam, not configure it at all and run
> > dspam_stats.
> 
> My expectation/hope after installing the dspam package is that it is
> functional, and that the default configuration will work out of the box.
> If it does not work out of the box, my expectation/hope is that the
> various dspam-related tools will issue a clear error message
> along the lines: "No storage engine supplied.  Please specify a storage
> engine in /etc/dspam.conf and try again".
> 
Okay, okay. The current code in GIT is doing that. As soon as it is released and Fedora/Red Hat can package it then you will have that kind of error message.


> But frankly that seems overly complicated.  Why not
> statically link the hash storage engine into dspam, as built
> in the dspam RPM?  This will supply a reasonable default behavior without
> the user/admin doing anything.  In that scenario, there is no need for
> a dspam-hash package.  Only the additional/optional storage engines will
> be supplied as separate packages.    

Statically linking the hash driver into DSPAM will result in not being able to use any of the other storage engines. So one wishing to use PostgreSQL or MySQL or SQLite as storage backend will not be able to do so if the Hash driver is statically linked into DSPAM.
Comment 17 Bug Zapper 2011-06-01 07:58:24 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Bug Zapper 2011-06-28 10:53:49 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.