Yup, this fixed it. There is something wrong with Mandrake dists where
/usr/lib/perl5/site_perl gets chmod' to 700 and that is not the proper
behavior. This is a v10 -> 10.1 upgraded machine with 5.8.3 upgraded
to 5.8.5 in recent days as part of urpmi.update. It looks like the
vendor package maintainer decided to chmod all of the 5.8.3 site_perl
locations 700 to avoid clashes with 5.8.5 in lieu of deleting the
directories outright. Good in theory but he/she just went one dir to
high when they did it. That's what I get for patching...
Tom
Thomas Bolioli wrote:
Thanks for the heads up but the problem is starting to look like perl.
When I run perl as root I have the same @INC path as when I run
non-privileged. However, only as root am I able to find most of the
modules in site_perl. When I run as other than root, I can not get
access to the modules I need. It appears some permission problems have
crept up after doing an update a few days ago. I am in the process of
fixing them right now and hopefully that will hold and not get
automatically "fixed" by some bots Mandrake has to fixperms on an
hourly basis.
Thanks,
Tom
Bob McClure Jr wrote:
On Thu, Feb 17, 2005 at 11:58:04AM -0500, Thomas Bolioli wrote:
Ok. I created copies of the /etc/resolv.conf file in the user's home
dirs and made sure the copies were owned by those users and no go. It is
still not executing network tests for any user other than root. Can
anybody confirm they are getting network tests performed on a 3.0.0
setup with procmail executing /usr/bin/spamassassin (not a spamc/spamd
setup)? I know I have all the correct settings as other emails in this
thread can show.
Tom
Don't know if this relates to your problem. About two weeks ago I
started having a lot of spam slipping through, even the obvious C-drug
ones. Following a recent posting (may have been yours), I ran the
spam through "spamassassin -D" and it scored much higher, even enough
to qualify for summary punting, mostly thanks to SURBL scores that
weren't in the original scan by spamc/spamd. After some thought, I
remembered recently fixing a problem in my /etc/resolv.conf in which a
now-dead IP address had been at the top of the list. So I restarted
spamd, and now things are once again wonderful.
Apparently, spamd reads /etc/resolv.conf at startup and uses only the
first entry. If that's busted, forget about all the SURBL stuff.
Thomas Bolioli wrote:
I had not upgraded from a 2.6x install with Spam Cop. It was a totally
stock install and it is still 3.0.0. I have since discovered that when
I run spamassassin as any user except root, the network tests do not
work. When I run it as root, all the network tests work just fine. I
have tried to run network based things as other users before and there
does not appear to be any restrictions on network access for those
users. I checked /etc/resolve.conf and it is read only to the world
and is configured properly. Something may be wrong with
Net::DNS::Resolver and it is not seeing the /etc/resolve.conf file
when run as other users. This morning's chore is to create links to
~/.resolve.conf for a few users and get it owned by them and see what
happens.
Will advise.
Tom
Jeff Chan wrote:
On Wednesday, February 16, 2005, 2:25:52 PM, Thomas Bolioli wrote:
Hence my problem.
>From my local.cf which is not overridden anywhere
skip_rbl_checks 0
dns_available yes
>From etc/procmailrc
SPAMC="/usr/bin/spamassassin"
:0f
|$SPAMC
but the surbl checks only occur when I do spamassassin -t < file_w_msg
and not when procmail does the forwarding.
I am at a loss. This has never worked since I install 10.1 (SA 3.0.0).
SA 2.63/2.64 used a separate patch called SpamCopURI, and SA
3.x uses the built in program urirhssub for SURBL lookups.
If you had SpamCopURI before, did you get rid of the it and the
rules for it, as you should for 3.X? (3.X versions have SURBL
rules set up by default).
Did you perhaps upgrade from 3.0.0 to later versions? If so, did
you remember to change the rule type from "header" to "body" as
mentioned at:
http://www.surbl.org/faq.html#body
Jeff C.
Cheers,
|
smime.p7s
Description: S/MIME Cryptographic Signature
