perl 5.8.8 install problem
Kevin W. Gagel
combonation was sending errors to my log files so often that my server
slowed down. Follow up on the cause revealed an upgrade to 5.8.8 would
correct the problem.
Unfortuantly I've spent a few days cleaning up the aftermath of the
problems that were created. I'm not stuck with a few problems I can't seem
to find the answer to. I'm hoping someone here can help me out because I'm
not to up on perl yet.
Anyway, what I did was remove the current installation of perl using the
rpm command to erase it. Since it complained about dependants and I was
about to re-install it I used the nodeps option.
Then I installed perl 5.8.8 and re-installed my modules that I use.
Specifically SpamAssassin. When I try to run spamd I get this error now:
[root@avas ~]# /etc/init.d/spamassassin start
Starting spamd: Can't locate object method "register_domain" via package
"IO::Socket::INET" at
/usr/local/lib/perl5/5.8.8/i686-linux/IO/Socket/INET.pm line 22.
Compilation failed in require at /usr/bin/spamd line 44.
BEGIN failed--compilation aborted at /usr/bin/spamd line 79.
[FAILED]
The INET installed went in with no problem and is:
cpan[12]> install IO::Socket::INET
IO::Socket::INET is up to date (1.31).
My web server could not start until I commented out the following line:
#LoadModule perl_module modules/mod_perl.so
The error I get with that active is:
May 8 10:24:04 avas httpd: Syntax error on line 26 of
/etc/httpd/conf.d/perl.conf:
May 8 10:24:04 avas httpd: Invalid command 'PerlTaintCheck', perhaps
mis-spelled or defined by a module not included in the server configuration
May 8 10:24:04 avas httpd: httpd startup failed
mod_perl.so existed in the /etc/httpd/modules directory but foolishly I
deleted it thinking that re-installing the mod_perl package would bring
back the correct one. Nope - that was wrong.
So, now I don't have a mod_perl for apache and my spamassassin won't run
because of some strange perl error.
Can someone shed some light on this for me... What should I do now?
=================================
Kevin W. Gagel
Network Administrator
Information Technology Services
(250) 562-2131 local 448
My Blog:
http://mail.cnc.bc.ca/blogs/gagel
-------------------------------------------------------------------
The College of New Caledonia, Visit us at http://www.cnc.bc.ca
Virus scanning is done on all incoming and outgoing email.
Anti-spam information for CNC can be found at http://avas.cnc.bc.ca
-------------------------------------------------------------------
Chas Owens
snip
> Then I installed perl 5.8.8 and re-installed my modules that I use.
> So, now I don't have a mod_perl for apache and my spamassassin won't run
> because of some strange perl error.
Short answer: You have RHEL, put in a support call.
Medium answer: We cannot tell you much without know how you tried to
install perl 5.8.8. RPM from a later version of RHEL? Compiled from
source?
Long answer: If you have a valid backup, restore your system. If you
don't then try reinstalling the original RPMs from RHEL and see if you
can get things up and running again. Once you are up and running
download Perl 5.8.8 and install it into a different directory than the
stock version (/opt/perl5.8.8 for instance). Change the code that is
using spamassassin to have #! lines that point to
/opt/perl5.8.8/bin/perl instead of /usr/bin/perl. Or, you can upgrade
to RHEL5 which already has perl 5.8.8.
Vincent Li
> I run SpamAssassin on a RHEL 4 box with the FuzzyOCR plugin. This
> combonation was sending errors to my log files so often that my server
> slowed down. Follow up on the cause revealed an upgrade to 5.8.8 would
> correct the problem.
Actually, you don't need to upgrade to 5.8.8 if you don't need the new
feature which latest SpamAssassin introduced to allow SA rules written in
multi-bytes languages. Add "use bytes" back to Mail::SpamAssassin::Message
will skip the broken SARE rules warnings. Too late you already decided to
upgrade to 5.8.8 :)
Why don't you get rid of all current perl and perl libraries and build
from tarball source, then run the new installed cpan command to install
modules that SA depends on
Vincent Li
http://bl0g.blogdns.com
Kevin W. Gagel
>Actually, you don't need to upgrade to 5.8.8 if you don't need the new
>feature which latest SpamAssassin introduced to allow SA rules written in
>multi-bytes languages. Add "use bytes" back to Mail::SpamAssassin::Message
>will skip the broken SARE rules warnings. Too late you already decided to
>upgrade to 5.8.8 :)
Uhg. Now someone tells me ;-)
>Why don't you get rid of all current perl and perl libraries and build
>from tarball source, then run the new installed cpan command to install
>modules that SA depends on
Actually I thought I had done that. Clearly I missed something... Doesn't
the rpm -e erase everything for me or was there something I needed to wipe
out after that?
Kevin W. Gagel
>Short answer: You have RHEL, put in a support call.
Right. And paid support...
>Medium answer: We cannot tell you much without know how you tried to
>install perl 5.8.8. RPM from a later version of RHEL? Compiled from
>source?
Used rpm -e to erase current install. Used source to install with.
>Long answer: If you have a valid backup, restore your system. If you
It didn't work. That will be the next investigation.
>don't then try reinstalling the original RPMs from RHEL and see if you
>can get things up and running again. Once you are up and running
I had just retrieved the install cd's to try that with.
>/opt/perl5.8.8/bin/perl instead of /usr/bin/perl. Or, you can upgrade
>to RHEL5 which already has perl 5.8.8.
Tried that but a couple of the disks failed the media check. So I'm running
them again in another system to determine if the cdrom or the disks are
bad. So far it looks like the disks. So I'll have to redownload a few.
Chas Owens
snip
> Why don't you get rid of all current perl and perl libraries and build
> from tarball source, then run the new installed cpan command to install
> modules that SA depends on
Because, if I remember correctly, mod_perl will still be broken.
Unless he is willing to recompile it as well then he will have a
problem with it. The docs seem to support my memory:
from the Apache docs*
Should I Rebuild mod_perl if I have Upgraded Perl?
Yes, you should. You have to rebuild the mod_perl enabled server
since it has
a hard-coded @INC variable. This points to the old Perl and it is
probably linked
to an old libperl library. If for some reason you need to keep the
old Perl version
around you can modify @INC in the startup script, but it is better
to build afresh
to save you getting into a mess.
This is not normally a problem on modern Linux boxes because upgrades
occur through a package management system that upgrades mod_perl at
the same time.
Kevin W. Gagel
>Because, if I remember correctly, mod_perl will still be broken.
>Unless he is willing to recompile it as well then he will have a
>problem with it. The docs seem to support my memory:
Yes I am, in fact it was one of the first steps I took to fix the problem.
Contrary to what I posted earlier I actually renamed the mod_perl.so not
delete it. I've renamed it back and did a ld on it.
The output of that is here:
http://avas.cnc.bc.ca/mod_perl.txt
An ldd /etc/httpd/modules/mod_perl.so gives this output:
[root@avas ~]# ldd /etc/httpd/modules/mod_perl.so
libperl.so => /lib/libperl.so (0x00903000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00b43000)
libdl.so.2 => /lib/libdl.so.2 (0x00bb2000)
libm.so.6 => /lib/tls/libm.so.6 (0x006ed000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00fd2000)
libutil.so.1 => /lib/libutil.so.1 (0x00111000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0080b000)
libc.so.6 => /lib/tls/libc.so.6 (0x004fa000)
/lib/ld-linux.so.2 (0x00650000)
An ldd /lib/libperl.so gives this output:
[root@avas ~]# ldd /lib/libperl.so
libnsl.so.1 => /lib/libnsl.so.1 (0x00550000)
libdl.so.2 => /lib/libdl.so.2 (0x00a09000)
libm.so.6 => /lib/tls/libm.so.6 (0x0077c000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x007ea000)
libutil.so.1 => /lib/libutil.so.1 (0x00646000)
libc.so.6 => /lib/tls/libc.so.6 (0x00413000)
/lib/ld-linux.so.2 (0x00650000)
It may as well be greek to me...
Chas Owens
> >Short answer: You have RHEL, put in a support call.
>
> Right. And paid support...
Ah, bad assumption on my part.
>
> >Medium answer: We cannot tell you much without know how you tried to
> >install perl 5.8.8. RPM from a later version of RHEL? Compiled from
> >source?
>
> Used rpm -e to erase current install. Used source to install with.
Source installation is tricky. You need to make sure you have all of
the dependencies perl needs (and not just the bare dependencies, but
all of the ones used to compile it like RedHat does) and that you
update everything that is tied to the old version of perl (e.g.
mod_perl). This is why package management systems are nice (I have
become very lazy).
>
> >Long answer: If you have a valid backup, restore your system. If you
>
> It didn't work. That will be the next investigation.
Ouch, life sucks.
>
> >don't then try reinstalling the original RPMs from RHEL and see if you
> >can get things up and running again. Once you are up and running
>
> I had just retrieved the install cd's to try that with.
>
> >/opt/perl5.8.8/bin/perl instead of /usr/bin/perl. Or, you can upgrade
> >to RHEL5 which already has perl 5.8.8.
>
> Tried that but a couple of the disks failed the media check. So I'm running
> them again in another system to determine if the cdrom or the disks are
> bad. So far it looks like the disks. So I'll have to redownload a few.
Life really sucks. At least it sounds like it is a personal or
development machine rather than a production system.
Kevin W. Gagel
>Life really sucks. At least it sounds like it is a personal or
>development machine rather than a production system.
I wish... It's my gateway email server. I've bypassed all anti-spam/perl
functions to keep it running while I figure out what to do.
Vincent Li
> ----- Original Message -----
>> Life really sucks. At least it sounds like it is a personal or
>> development machine rather than a production system.
>
> I wish... It's my gateway email server. I've bypassed all anti-spam/perl
> functions to keep it running while I figure out what to do.
>
I think spamd can run on seperate box, maybe it is easier/quicker to setup
fresh SA on fresh box than fixing the broken perl on the production email
server.
Vincent Li
http://bl0g.blogdns.com
Kevin W. Gagel
>I think spamd can run on seperate box, maybe it is easier/quicker to setup
>fresh SA on fresh box than fixing the broken perl on the production email
>server.
It can. But I'm a firm believer in fixing things properly. My setup has a
two stage anti-spam setup, the external gateway and another on the
internal. So I'm only letting through a lot more spam then usuall.
I'll get it...