Bugzilla Bug 81596

I've found that my dspam trying to create and use ~/.dspam(but cant while ran
from dspam uid from mailer) when virtual user name have corresponding passwd
entry.
I propose to not enable homedir with --enable-virtual-users (with USE=mysql or
pgsql).

Reproducible: Always
Steps to Reproduce:
1. less /var/log/dspam.debug
2.
3.

Regardless of the backend, dspam-web is useless (as it can't find the
quarantine) if --enable-homedir is used.

Just wanted to confirm on this one.
I couldn't get dspam to work, until I read this bug report.
Dspam didn't create /var/spool/dspam/local/<user>/<user>.* files.
I commented out the line 'myconf="${myconf} --enable-homedir"' in dspam-3.4_rc2.ebuild and remerged dspam.
Now it DOES create the files. Wow!

I am using MySQL as backend database.

Hi,
  I'll look into this.  Thanx for the info, :)

Regards
Lim Swee Tat

Part of a patch at bug #86099.

The ebuild makes an incorrect assumption that if virtual-users is not set, then
homedirs must be.  It is possible to have both configure items as false.  You
have real users in /etc/passwd, and there is a central location for all your per
user dspam statistics.

I think what the original author if the ebuild was trying to capture was that
you can't have homedirs if you have virtual users.

This is why the original configure script has these two items as separate flags.

The biggest reason not to use homedirs is that it makes the CGI useless.  In
fact, the dspam-web ebuild ought to fail to emerge if homedirs is set.  I
propose a new use flag to reflect that, although I'm ignorant of the whole
ebuild process (everybody's a user sometimes, heh).

Created an attachment (id=66563) [edit]
Adds a USE flag to make explicit the enable-homedirs configuration.

Created an attachment (id=66564) [edit]
Checks to make sure enable-homedirs is not set.

(From update of attachment 66563 [edit])
This fixes the problem by adding a USE flag user-homedirs.  Virtual users and
user homedirs are not exclusively OR - it is the norm on a lot of installations
that they are both false.  Indeed, that is the default configure script
behavior.  Check the DSPAM README for details about both flags.

(From update of attachment 66564 [edit])
This is for dspam-web.	If user_homedirs is set, then dspam-web will not
install and the user is told why.  It also checks the dspam binary to ensure
that it is NOT configured with --enable-homedirs.

Created an attachment (id=66568) [edit]
Oops, forgot to redirect grep output to /dev/null.

Confirming the --enable-homedir thing in dspam-3.4.9 

Removed the config parameter and everything began magically working after hours
and hours of poking at permissions, scripts, and all sorts of voodoo.

Confirming the --enable-homedir thing in dspam-3.4.9 

Removed the config parameter and everything began magically working after hours
and hours of poking at permissions, scripts, and all sorts of voodoo.

Bump.  This is still a problem in 3.6.  Was there something wrong with the
patches I uploaded?  This bug is still open.  The 3.6.0 ebuild makes an
incorrect assumption at line 90:

use virtual-users || myconf="${myconf} --enable-homedir"

Those two dspam config options do not have an exclusive OR relationship.  Like I
mentioned before, the default configure for dspam has both off (which is
probably the most likely case).

Further dspam-web DOES NOT WORK with --enable-homedir, from the README:

"     --enable-homedir
     When enabled, instead of checking for $HOME/$USER/opt-in/
     $USER[.dspam|.nodspam], DSPAM will check for a .dspam|.nodspam file in the
     user's home directory. DSPAM will also store each user's data in ~/.dspam
     when this option is enabled. Because of this, DSPAM will automatically 
     install and run setuid root so that it can read each user's home directory.

     Note:

       This function is incompatible with most implementations of the Web UI, 
       since it requires access to read each user's home directory. Therefore, 
       only use this option if you will not be using the Web UI or plan on 
       doing something asinine like running it as root."

Could I please get the patches put in to the official ebuild or an explanation
why the patch doesn't work, etc?

BTW, thanks for making an ebuild of dspam, I really appreciate it.

Fixing in CVS. :) Sorry for the tardiness.