Apache 2.4.x, mod_perl.so fetching instead of executing cig perl scripts

:warning: IMPORTANT, please fill the questions

We assume you are using Bitnami to deploy your application.

  • Which version of the application are you using?:
    rubystack 2.3.5-0

  • Please choose how you got the application: Installer (Windows, Linux, macOS), cloud image (AWS, GCE, Azure, …) or VM (VMDK, VBOX): macOS 10.11.6 rubystack installer

  • Have you installed any plugin or modified any configuration file?:
    Apache 2.4 httpd.conf modifed, added LoadModule perl_module modules/mod_perl.so lines (mod_perl.so’s listed in rubystack/apache2/modules directory) but running apache2 throws error on load (see below).

  • Describe here your question/suggestion/issue (expected and actual results):
    Trying to resolve cgi (perl) script errors in Apache 2.4, under Mac 0S X (10.11.6): Apache persistently fetches, rather than downloads, cgi scripts … in this case, perl scripts.

Downloaded MAMP stack (7.1.10-1) to see if its mod_perl.so would work … nope … MAMP 7’s apache2’s apparently not compiled with mod_perl.

Discovered support discussions indicating that although Apache Perl modules are absent in MAMP, RubyStack 2.3’s Apache implements the perl_module. but it appears not to load mod_perl.so.

  • Steps to reproduce the issue (if relevant):
    Added working cgi script (works in macOS 10.7.5 to cgi-bin … with relevant ExecCGI option … like this:

<Directory “/Applications/rubystack-2.3.5-0/apache2/cgi-bin”>
AllowOverride None
Options ExecCGI
Require all granted

No dice … still fetches scripts rather than executes then.

  • Copy the apache log (if relevant):
httpd.bin: Syntax error on line 158 of /Applications/rubystack-2.3.5-0/apache2/conf/httpd.conf: 
Cannot load modules/mod_perl.so into server: dlopen(/Applications/rubystack-2.3.5-0/apache2/modules/mod_perl.so, 10): 
Symbol not found: _modperl_handler_anon_add\n  Referenced from: /Applications/rubystack-2.3.5-0/apache2/modules/mod_perl.so\n  Expected in: dynamic lookup\n

Totally stumped,
Daniel B.

Hello @dbridgma

Thanks for reporting it! I could reproduce it on an Linux environment. The issue is in the environment of the Apache configuration.

As you mentioned, it complains about a missing library:

sudo /opt/bitnami/apache2/bin/apachectl -M | grep perl
httpd.bin: Syntax error on line 161 of /opt/bitnami/apache2/conf/httpd.conf: Cannot load modules/mod_perl.so into server: libperl.so: cannot open shared object file: No such file or directory

However, the library is included in the system:

$ sudo find /opt/bitnami/ -name "libperl.so"
/opt/bitnami/perl/lib/5.16.3/x86_64-linux-thread-multi/CORE/libperl.so```

The problem is that LD_LIBRARY_PATH is not set properly. You need to edit the file /opt/bitnami/apache2/bin/envvars adding the lines below at the end:

LD_LIBRARY_PATH="/opt/bitnami/perl/lib/5.16.3/x86_64-linux-thread-multi/CORE:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH

After that, restart apache and it should work:

sudo /opt/bitnami/ctlscript.sh restart apache
sudo /opt/bitnami/apache2/bin/apachectl -M | grep perl
 perl_module (shared)

Best Regards,

Juan Ariza


Was my answer helpful? Click on :heart:

1 Like

Juan,

Appreciate your reply and its suggestion for a fix of the LD_LIBRARY_PATH.

My Mac OSX rubystack install directory structure’s a bit different from yours on Linux, so I’m looking to make relevant changes.

Here’s what I’ve got:

/Applications/rubystack-2.3.5.0/perl/lib//site_perl/5.16.3/darwin-thread_multi-2level/ … but I find no CORE in any of the available directories.

Sorry, this is due to a lack of knowledge on my part.

Best,
Daniel B.

Hello @dbridgma

The problem seems to be the same since it doesn’t find a symbol when loading the binary. I created a task to fix the issue when I provided you the workaround for Linux environments. I just updated the information in the task in order to extend it to OS X installers. As soon as someone in the engineering team starts working on this task we will provide you a workaround.

Thanks in advance for your consideration and patience. We will notify you about our progress.

Best Regards,

Juan Ariza