Yum broke Perl on CentOS 5

During a recent Yum update that was long overdue, my perl scripts stopped working talking about missing XS versions of certain perl modules.

Specifically it broke my script that uses Mail::Box::Manager and complained about a dependency fail in Mail::Box::Reporter that needed an XS version that is missing.

I thought I would re-install Mail::Box::Manager. While trying to manually compile Mail::Box::Manager (since CPAN won't install without force, which is a bad idea if something is really broken), one of the first warnings given is

--
!!!! WARNING !!!! On your system, the module Scalar::Util is installed
!!!! WARNING !!!! without use of XS. This means that critical functionality
!!!! WARNING !!!! is missing. Reinstall the module and be sure to get the
!!!! WARNING !!!! correct installation.
!!!! WARNING !!!! perl -MCPAN -e 'shell'
!!!! WARNING !!!! > force install Scalar::Util
--

This led to the bug below that recommends force installing Scalar::Util via CPAN, since CentOS RPMs don't have this and is missing the XS version.
http://bugs.centos.org/view.php?id=2434

Force installing Scalar::Util as indicated worked. Phew! Took me 2 days to research this, but finding a simple solution to fix everything is great. :)

perl xml parser and dependency hell

Was trying to install a perl module from CPAN (Frontier::Daemon) which needed XML::Parser which just wouldn't install. Perl's package manager kept complaining about a missing expat.h file, followed by many lines of errors. yum said expat is up to date. Removing expat (in an effort to reinstall it) removed yum as well. Installing yum wasn't easy. Finally got the rpm for yum to work and installed CentOS's precompiled perl xml parser. perl was satisfied with this and installed Frontier::Daemon without further complaints.

SELinux

I was struggling to install MT4 on a fresh CentOS installation. Building a LAMP Server was a decent guide, but I got stuck at setting up MT4. The 'mt-wizard.cgi' could not find it's own 'mt-static' directory. But the directory would navigate just fine from a browser client. Was MT4-RC1 broken?

I went to the MT::App:Wizard Perl module and edited the function which was testing for {mt-dir}/mt-static/styles.css file, which is how MT determines the location of 'mt-static' folder within its own installation. Adding simple print statements gave the state of the LWP::UserAgent variable.

print STDERR $response->status_line

This output (to the Apache error log of this VirtualHost) an error message similar to "500 Connection refused to {servername}:80. Permission denied". I tried writing my own test perl scripts using LWP::UserAgent and LWP::Simple to verify if either MT4 or Perl themselves weren't broken within the environment.

Finally found /var/log/messages log file that recorded each attempt and access denied. The log file was very helpful. Learnt about SELinux's role over Apache as a security measure. So I tried modifying the local policy as described, but it didn't work. So finally had to change SELinux mode from enforcing to permissive in it's config file at /etc/selinux/config.

SELINUX=permissive

Have to learn more about SELinux and it's role in Linux, Apache, etc.