Roxanne Sandesara wrote:
> 
> Thanks, Eric.
> Having provided what I just have, what's next? What piece of information
> should I hunt down to get us to the next step in tracking?
> 
> As I said, when I ran 'spamassassin --lint -D' from the temporary bash
> shell login as vpopmail, it does try to look in that directory, gives a
> warning that it's inaccessible, and then tries and succeeds in finding
> and processing the files in the default /etc/mail/spamassassin directory.
> 
> Should I try running 'spamassassin --lint -D' with the -x -u vopopmail
> -s options, as specified in the spamd run file, while logged in
> (otherwise) as my normal admin login, to see if its output and behaviors
> differ?
> 
> Thanks again for all of the help and advice. I'll keep trying so long as
> it takes. After all, I learn more with every step than I knew before.
> 
> Roxanne
> 

I've run a few tests, and here's what I've observed:

.) The --rebuild option of rpmbuild does not actually install the binary
rpm. The man page must be referring to the %install phase of the build, in
which the toaster's spec does an install to the %{buildroot} environment,
which is subsequently used to create the binary rpm. I had read this out of
context yesterday (although the man page might read "does a %prep, %compile
and %install" to be clearer).

.) ran both
# sudo -u vpopmail -H spamassassin --lint -D
and
# su - vpopmail -s /bin/sh
# spamassassin --line -D
There was no reference to /var/tmp in either run, and no errors in the spamd
log after starting qmail. I did notice this though:
dbg: util: running in taint mode? yes
dbg: util: taint mode: deleting unsafe environment variables, resetting PATH
This shows that spamassassin is altering its environment, and might explain
a few things.

.) I ran a diff of the essential results:
# diff sa-lint.sudo sa-lint.su
After eliminating differences in hashes, which are to be expected, this is
what's left:
7d6
< dbg: util: PATH included '/usr/kerberos/sbin', keeping
9d7
< dbg: util: PATH included '/usr/local/sbin', keeping
11d8
< dbg: util: PATH included '/sbin', keeping
13d9
< dbg: util: PATH included '/usr/sbin', keeping
16,17c12
< dbg: util: PATH included '/root/bin', which doesn't exist, dropping
< dbg: util: final PATH set to:
/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin
---
> dbg: util: final PATH set to:
/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
151c146

This shows the result of the differing PATHs, in combination with running in
taint mode (noted just previously). In a nutshell, we see that sudo keeps
the present environment (in this case, root's), while "su -" takes on a
whole new environment. This is as we expected. It may be interesting to note
the difference in the resulting paths. While it doesn't exactly explain why
the configuration files are found differently, it does show how/why the
PATHs are different, and other environment variables will almost certainly
be different too (they would only be the same coincidentally).


So we're still in the same boat, but we've seen that spamassassin can behave
differently depending on how and from which account it's invoked. We've also
missed one other fine detail. The toaster runs "spamd", not "spamassassin".
These are two entirely different programs. So now we're back to the question
of, how does *spamd* find its configuration files.

Let's remind ourself first how we're invoking spamd:
exec /usr/bin/spamd -x -u vpopmail -s stderr 2>&1

A good place to look is always the man page. From that we see that:
-x : Disable user config files
-u : run as vpmail
-s : log to stderr

There are some other interesting options as well:
-C : path for default config files
Aha! I'm guessing that if you were to add "-C /etc/mail/spamassassin" to the
exec command, that would solve your problem without having to use the
/var/tmp/ directory. It doesn't explain though why your spamd is defaulting
to /var/tmp first while other toasters are not. It does seem to be a simpler
work-around though.

Is it possible that for some reason the vpopmail user doesn't have
permissions to read /etc/mail/spamassassin and/or it's contents?
# su - vpopmail -s /bin/sh
# ls -l /etc/mail/spamassassin
All of the files in this directory should be rw-r--r--

Let us know what you find with -C and permissions.

-- 
-Eric 'shubes'

---------------------------------------------------------------------
     QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to