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.
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.
(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 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.
(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"?
@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.
(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
(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?
(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.
@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?
(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.
(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.
@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?
(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.
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.
(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.
(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.
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
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.