On May 11, 2008, at 11:53 AM, Eric Shubert wrote:
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.
OK. Made a copy of the run file for spamd as run.bak. Modified run to
add -C /etc/mail/spamassassin. Saved that. Made a copy of it as
run.new so that I could potentially switch back and forth, and have
referents before and after the change.
Stopped qmail. Deleted the /var/tmp/spamassassin-toaster-root
directory and contents. (Since we want to see how this will work with
the change in place, we don't want there to be any chance it is
reading the 'stopgap' copy of config files I placed there to make
things run yesterday.)
Started qmail. Checked our spamd log. The errors I was getting before
are no longer present. It is scanning successfully. The directory /
var/tmp/spamassassin-toaster-root is not being re-created.
Obviously, this doesn't yet answer the question of how or why the
system was behaving as it was - and why uninstalling and re-
installing the packages didn't correct that issue - but adding the -C
option to the run file has at least corrected the problem so that the
system is running 'as it should' from its default configuration files
without errors.
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--
# su - vpopmail -s /bin/sh
-sh-3.00$ ls -l /etc/mail/spamassassin
total 52
-rw-r--r-- 1 root root 1299 May 10 16:34 init.pre
-rw-r--r-- 1 root root 1299 May 8 19:02 init.pre.rpmnew
-rw-r--r-- 1 root root 399 May 10 16:34 local.cf
-rw-r--r-- 1 root root 399 May 8 19:02 local.cf.rpmnew
-rw-r--r-- 1 root root 1703 Jan 8 16:41 local.cf.rpmsave
-rw-r--r-- 1 root root 2397 May 10 16:34 v310.pre
-rw-r--r-- 1 root root 2397 May 8 19:02 v310.pre.rpmnew
-rw-r--r-- 1 root root 2443 May 7 15:27 v310.pre.rpmsave
-rw-r--r-- 1 root root 1195 May 10 16:34 v312.pre
-rw-r--r-- 1 root root 1195 May 8 19:02 v312.pre.rpmnew
-rw-r--r-- 1 root root 2416 May 10 16:34 v320.pre
-rw-r--r-- 1 root root 2416 May 8 19:02 v320.pre.rpmnew
Let us know what you find with -C and permissions.
--
-Eric 'shubes'
So. That being the case of our results, it seems clear to me that
there is something 'hanging around' that is influencing both
Spamassassin and spamd to go looking for that directory. Initiating
spamd with the -C option is correcting for this. Which I am fine
with, frankly, as I can read man pages well enough to continue
replicating that correction in the future as needed. But it doesn't
quite satiate my curiosity. Any thoughts as to where I should look to
run down where this might be coming from? Or should I feed my
curiosity some chocolate and tell it to be happy as-is? :)
Roxanne
(And I hope everyone remembered to tell their mothers Happy Mothers
Day. I know I did.)
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
