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 attachment 66563 [details, diff] Adds a USE flag to make explicit the enable-homedirs configuration.
Created attachment 66564 [details, diff] Checks to make sure enable-homedirs is not set.
Comment on attachment 66563 [details, diff] Adds a USE flag to make explicit the enable-homedirs configuration. 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.
Comment on attachment 66564 [details, diff] Checks to make sure enable-homedirs is not set. 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 attachment 66568 [details, diff] 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.
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.
