I run spamc/spamd in a virtual user setting.  I have the --create-prefs setting
set, and it works for the non-virtual users, but not for my virtual users.

I run a second spamd daemon with these options:
OPTIONS="--port=784 --create-prefs --max-children 12 --nouser-config --helper-home-dir
  --virtual-config-dir=/home/vmail/mail/%d/%l/.spamassassin --username=vmail"

I had to add this line to get the default preferences created.

~>diff /usr/sbin/spamd /usr/local/sbin/spamd-virtual
2122c2122
<     info("spamd: using default config for $username: $prefsfile");
---
2124a2125,2128

tags 454595 +unreproducible
thanks

I haven't been able to duplicate this bug.  The user prefs dir is
created as expected.  Note that the actual user dir needs to be created
by hand; this is not created by SA.  So, e.g. if the virtual-config-dir
option is set to /vhome/users/%d/%l/spamassassin, %d and %l must
reference existing directories.  Only the spamassassin subdir will be
automatically created.

noah

tags 454595 + confirmed - unreproducible
thanks

Hello,

I'm using version 3.3.1-1 and the bug still appends (some times ago, it
worked on etch for sure and maybe lenny):
I currently have the following config:
A dedicated user for spamassassin and a dedicated directory:
mkdir -p /var/lib/spamassassin/users
useradd spamassassin
usermod -d /var/lib/spamassassin spamassassin
chown -R spamassassin. /var/lib/spamassassin

In /etc/default/spamassassin:
ENABLED=1
OPTIONS="--create-prefs -x --max-children 5
--helper-home-dir=/var/lib/spamassassin 
--virtual-config-dir=/var/lib/spamassassin/users/%u -u spamassassin"

If I quote the man page of spamd:
--virtual-config-dir: [...] This path must be a writable directory.  It 
will be created if it does not already exist.

The directory should be created but unfortunately, it's not :/.
Everything works if I create by hand the directory but it's not quite
simple when using virtual users ...

As you suggest, I also tried with
virtual-config-dir=/var/lib/spamassassin/users/%u/spamassassin and
created /var/lib/spamassassin/users/test (with spamassassin as owner)
but spamd doesn't create the folder work neither.

For my test, I used (on the spamd host) the following protocol:
spamc -d 127.0.0.1 -u test <<EOF
From: test
To: test
Subject: test

test
EOF

The mail.log tells me:
# First case
spamd[24346]: spamd: using default config for test:
/var/lib/spamassassin/users/test/user_prefs
# Second case
spamd[2494]: spamd: using default config for test:
/var/lib/spamassassin/users/test/spamassassin/user_prefs

This also make per-users bayes DB unusable (the bayes plugin scream that
it can't create the lock (in the nonexistent folder))

Feel free to contact me if you need further informations.

Regards,
Damien

Dear Maintainer,

   * What led up to the situation?
Testing a new install of SpamAssassing
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
Submtted mail to a user without a config folder

   * What was the outcome of this action?
No new folder, and an error in the log:

 spamd[18039]: config: mkdir /home/vmail/mail/osric/sa failed: Insecure
 dependency in mkdir while running with -T switch at
 /usr/share/perl/5.28/File/Path.pm line 198, <GEN8> line 2

My perl-fu is not strong, but I tried basic untainting, replacing

  mkpath($fname, 0, 0700);

with

  my $clean = $fname ~= /^(*.)$/;
  mkpath($clean, 0, 0700);

(around line 1925 in /usr/share/perl5/Mail/SpamAssassin.pm)

but there was no change (no new folder)

   * What outcome did you expect instead?
The folder specified in --virtual-config-dir to be created per
the manpage for spamd.

I've confirmed that this is still present in 4.0.1.  I've pinged
upstream via https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5663 and
we'll see if they have anything to say...

noah

The code has changed since the original report, the same bug still exists.

New patch:

/usr/local/sbin#diff spamd /usr/sbin/spamd                                                                                          5:15am
2794,2798c2794,2795
<     if ( ! -f $prefsfile ) {
< 	info("spamd: using default config for $username: $prefsfile");
< 	handle_user_set_user_prefs(File::Basename::dirname($userdir), $username);
---

(line numbers are slightly off due to some removed comments and the
combined patch with #1139978)


The behavior from the original bug report remains the same, and this
patch replaces the original patch.

This was closed upstream with 4.0.2

close 454595 4.0.2-1
thanks