RT Inaccessible with httpd, fine in stand-alone

I’m working with a fresh installation of RT4.4.4, and it works fine if I run the server in standalone mode using /opt/rt4/sbin/rt-server. I can access the webpage and everything just fine. (EDIT: It may be useful to mention that this is on a RHEL 7 VM, SELinux is disabled, and firewalld is masked)

If I stop that process and try to bring it up using httpd, I can’t get it to work at all. I’m using the rt.conf files provided here, only removing the directives because they’re broken and unnecessary, and updating the server name to match my FQDN.

If I run httpd with the mod_perl config, I get to a page that tells me I’m “almost done” setting up the server, and I just need to tell http to use RT. That page directs me to the one I already linked, from where I had already copied the server configuration file.

If I run httpd with fcgi, it tells me it can’t find the require perl module.

Here’s my rt.conf file.

<VirtualHost *:80>
    ### Optional apache logs for RT
    # Ensure that your log rotation scripts know about these files
    # ErrorLog /opt/rt4/var/log/apache2.error
    # TransferLog /opt/rt4/var/log/apache2.access
    # LogLevel debug
    ServerName <FQDN>

    AddDefaultCharset UTF-8

    ScriptAlias / /opt/rt4/sbin/rt-server.fcgi/

    DocumentRoot "/opt/rt4/share/html"
    <Location />
        Require all granted
        Options +ExecCGI
        AddHandler fcgid-script fcgi


[Fri May 08 15:30:31.548805 2020] [fcgid:info] [pid 13231] mod_fcgid: server :/opt/rt4/sbin/rt-server.fcgi(13278) started
Can’t locate UNIVERSAL/require.pm in @INC (@INC contains: /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.pm line 60.

BEGIN failed–compilation aborted at /opt/rt4/sbin/…/lib/RT.pm line 60.

Compilation failed in require at /opt/rt4/sbin/rt-server.fcgi line 86.

The file is definitely there.

[root@rt_host conf.d]# find /usr -iname ‘require.pm

And it’s in @INC’s path.

[root@rt_host conf.d]# env -i perl -V | grep @INC -A 10

What am I missing?

Could this be user rights? Ie can the Apache user read the /usr/local/share/perl5 dir?

I thought that, too. I just forgot to mention that I ran chown -R 777 /usr/local/share/perl5, and I get the same error.

Are you opposed to installing a standalone version of Perl for RT? I have found that makes keeping track of the Perl deps much easier. Doing a quick search around I have seen issues with the location of Perl modules for RHEL7/Centos7

Do you use cpan or cpanm?

I used cpanm to install the modules. I ran export RT_FIX_DEPS_CMD=/usr/local/bin/cpanm, and then ran make fixdeps. There was one module that did not install through fixdeps that I then installed with cpanm -i. The only module installed differently was the XML-RSS module, which I installed through YUM because our firewall is blocking the cpanm installation.

To answer your question about the standalone perl version. I’m fine with giving that a try. But if the file is where it’s expected to be, why might that help?

Did you set cpan up with some kind of local::lib configuration?

Looking through the forum I see:

As others have noted, using CPAN on CentOS 7 can be sketchy. It’s very
easy to be drawn into installing modules locally under /root/perl5/
where normal Perl programs won’t ever see them or clobbering files owned
by yum-installed packages. Care is needed…

For the immediate issue, you can resolve the problem by enabling the
EPEL repository for yum (see [https://fedoraproject.org/wiki/EPEL ](https://fedoraproject.org/wiki/EPEL)) and
installing the needed module:

yum install perl-UNIVERSAL-require

HOWEVER, since you have had stuff installed (presumably by CPAN and a
local::lib configuration) in a private place only for use by root with
suitable variables in the environment, you probably want to fix that[1]
and install everything possible for RT via yum, filling in whatever is
missing with CPAN *NOT* using a private module tree. I recently did this
for a RT4.4rc1 install on CentOS 7 by massaging the output of “make
testdeps” into a whopping huge yum command[2]:

A standalone Perl seems the safest bet

I installed perl 5.20.1 from source, and I can make RT run with httpd if I give apache rwx permissions on all perl folders. I tried giving giving rw, and that still returned a 500 error. I also tried giving rwx on lib only, which did not help. If I don’t give apache rwx on bin, it fails. I’m setting this with setfacl -m u:apache:rwx /path/to/perl. The same approach did not work with the system’s perl, so this is at least a step in the right direction.

But still, there has to be some way to make this work without giving apache full access to run perl, right?

It would be normal for the Apache process to require mode 755 (+rx) on a directory. Directories must be executable in order to access the contents in this context. Readable also is required. Writeable, however, is not required.

Try just making the Perl library directories +rx, not -w (except by whomever needs to own them, root, whatever), and see how you go. Individual files will need to be 644, of course (readable to all).

Naturally, you can try to contain this just to the group level if you’ve got Apache in a group and don’t want other users to access your custom perl/path/libraries.

Duh! My brain stopped working right by the time I posted this… long day. Thanks!