[rt-users] Trouble/Error with Web deployment httpd/apache/mod_fcgid

[Bill Cole]

On 23 Nov 2015, at 15:57, dwdixon wrote:

> This was sort of the problem....basically I installed many Perl 
> modules via
> cpanm and apparently that's a problem in certain circumstances which 
> I'm not
> totally sure about at this time.  To fix this error I installed the 
> CentOS
> @epel repo version of a few packages:
>
> perl-UNIVERSAL-require.noarch..........0.13-12.el7......... at epel
> perl-Log-Dispatch.noarch.................... 2.41-1.el7.1........ at epel
>
> These are from @epel (as shown above) but now I'm stuck with an error 
> based
> on a perl module that does not have a package published in the epel 
> repo:
>
> **************************************************************************
> Can't locate /Symbol/Global/Name.pm/ in @INC (@INC contains:
> /root/perl5/lib/perl5/ /opt/rt4/sbin/../local/lib /opt/rt4/sbin/../lib
> /usr/local/lib64/perl5 /usr/local/share/perl5 
> /usr/lib64/perl5/vendor_perl
> /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at
> /opt/rt4/sbin/../lib/RT/Config.pm line 57.
> BEGIN failed--compilation aborted at /opt/rt4/sbin/../lib/RT/Config.pm 
> line
> 57.
> Compilation failed in require at /opt/rt4/sbin/../lib/RT.pm line 159.
> **************************************************************************
>
> After getting this I searched the repo's for this package, I found and
> installed this one:
>
> perl-Symbol-Util.noarch             0.0203-4.el7               @epel
>
> But this did nothing for me and doesn't seem to be what RT/Perl/httpd
> wants.....

Right. If there was a package for the EL7 distro family that gave you 
just the Symbol::Global::Name module, its base name would be 
perl-Symbol-Global-Name, and if that module were part of a larger 
package it would probably be perl-Symbol-Global or perl-Symbol.

BUT: the way to find a specific-file dependency with yum is the 
'provides' command:

	[root at requesttracker ~]# yum provides */Symbol/Global/Name.pm
	Loaded plugins: fastestmirror, langpacks
	Loading mirror speeds from cached hostfile
	 * base: mirrors.tripadvisor.com
	 * epel: mirror.cogentco.com
	 * extras: centos.firehosted.com
	 * remi: remi.check-update.co.uk
	 * remi-safe: remi.check-update.co.uk
	 * updates: bay.uchicago.edu
	No matches found

Oh well... that is why I used CPAN on that machine (via 'make fixdeps') 
to install Symbol::Global::Name.

> So...It looks like I will have to build a package for the module
> "Symbol::Global::Name" that I can install with yum......I tried the 
> hacked
> up solution suggested in the blog post you referenced, the OP said in 
> the
> quote below that this fixed it for him but I had no luck, it's a 
> hacked in
> solution anyhow....
>
> "I fixed the issue by adding the following line in ther perl script 
> before
> any 'use' command."
>
> use lib "/root/perl5/lib/perl5/" ;

Smart choice. That's not maintainable for RT. Also: won't work unless 
you disable or reconfigure SELinux and open up /root/perl5/ to the 
apache user, which would be generally unwise things to do.

> Looks like your suggestion of installing a separate instance of perl 
> that's
> dedicated to RT is making more and more sense the deep down the rabbit 
> hole
> that I travel....I'm afraid that if I install a new separate instance 
> of
> perl it will break even more things since I suppose I probably have to
> recompile RT after doing so and I don't want to lose the configuration 
> state
> of RT/RT-IR.....
>
> I just saw Bill Cole's reply and it is EXCELLENT!!! I'm still 
> re-reading to
> comprehend but Bill if you get this reply I was drafting prior to 
> seeing
> your response so if you need to update your great info based on what 
> I've
> said here I'd be very grateful!!

Well, in looking at it again I think maybe I should have also noted that 
those PERL* variables set in either .bashrc or .bash_profile will stay 
with any shell launched with them set and its offspring, so you will 
want to log out and back in after fixing the files or:

	unset PERL_LOCAL_LIB_ROOT PERL_MB_OPT PERL_MM_OPT PERL5LIB

*BEFORE* trying to install anything with CPAN or RT's make fixdeps.

And a bit of background: if you install a Perl module using yum from the 
Base or EPEL repos, it may install pieces under any of the 6 roots shown 
by 'perl -V' depending on the mood of some junior RedHat intern on a 
random Tuesday in 1997. Mostly they SHOULD stay out of the /usr/local 
ones and only get 64-bit-specific things in the lib64 ones. There's also 
supposedly "logic" determining what does and doesn't go in vendor_perl 
but it's not obvious. If you install using CPAN in a pristine (no PERL* 
variables) environment, you should get a bit better determinism, since 
the vendor_perl roots should be avoided entirely and /usr/local/* should 
be the only place anything lands. However, if you let CPAN *upgrade* 
modules already installed as part of the canonical Perl base (i.e. not 
"local" or "vendor_perl") it *might* clobber files that the RPM/yum 
subsystem believes belong to particular packages and expect have 
particular checksums. Hilarity (or something akin to it...) shall ensue 
when you try to upgrade those with yum. On the other hand, it SHOULD 
just install under /usr/local and override the system version at 
runtime. I don't suggest relying on that.

SO: you don't actually need to build a special Perl for RT. but the 
alternative is to be careful about how you install Perl modules. Check 
yum first for dependencies, and install from the Base or EPEL repos if 
they have what you need in the correct version. If you need a module not 
in those repos, use CPAN. If you need a different version that what yum 
has already installed, remove it first before installing from CPAN. Note 
that RT's 'make fixdeps' always installs from CPAN. Note that you could 
also ONLY use CPAN to maintain a unified Perl world, but that is a 
hassle: worse than either a blended yum+CPAN world or 2 distinct worlds.