0

I've installed Bugzilla following the guide here, however, when I restart my Apache server (so I can login to the Bugzilla system), I get the following error...

Jun 27 16:10:30 localhost.localdomain systemd[1]: Starting The Apache HTTP Server...
Jun 27 16:10:30 localhost.localdomain httpd[3519]: AH00526: Syntax error on line 354 of /etc/httpd/conf/httpd.conf:
Jun 27 16:10:30 localhost.localdomain httpd[3519]: Can't locate /var/www/html/bugzilla/mod_perl.pl in @INC (@INC contains: /var/www/html/bugzilla /var/www/html/bugzilla/li...) line 1.\n
Jun 27 16:10:30 localhost.localdomain systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE
Jun 27 16:10:30 localhost.localdomain httpd[3521]: AH00526: Syntax error on line 354 of /etc/httpd/conf/httpd.conf:
Jun 27 16:10:30 localhost.localdomain httpd[3521]: Can't locate /var/www/html/bugzilla/mod_perl.pl in @INC (@INC contains: /var/www/html/bugzilla /var/www/html/bugzilla/li...) line 1.\n
Jun 27 16:10:30 localhost.localdomain systemd[1]: httpd.service: control process exited, code=exited status=1
Jun 27 16:10:30 localhost.localdomain systemd[1]: Failed to start The Apache HTTP Server.
Jun 27 16:10:30 localhost.localdomain systemd[1]: Unit httpd.service entered failed state.

This is despite the fact that the /var/www/html/bugzilla/mod_perl.pl file is present and has sufficient file permissions. Any ideas on how to fix this? (I'm working on Fedora v16)

Edit: Seemed like the SELinux tags were the problem, server starts now and I can access the bugzilla page, however the cgi file isn't executing it's just displaying at text. Thoughts?

  • What is line 354 of /etc/httpd/conf/httpd.conf? Also, the surrounding few lines or the whole block if its not too big. – derobert Jun 27 '13 at 15:42
  • You're probably running into SELinux issues. httpd runs with a different context than regular users (httpd_t) so if you didn't relabel the files after you uploaded the bugzilla source SELinux will (understandably) do a denial. You can do a setenforce 0 and try again to confirm whether this is the case. – Bratchley Jun 27 '13 at 15:53
0

Alright, it looks like my inkling was correct and SELinux was the issue. For future reference, basically all I was keying off of when I made the suggestion was that you were on a system that has SELinux enabled by default and had uploaded a third party web application. I only mention so you can follow the same shorthand in the future.

For your present problem, though, you can do one of two things for the SELinux portion:

  1. Change SELinux into permissive mode via /etc/selinux/config so that it's no longer actually doing anything. I wouldn't do a full disable since that will definitely cause filesystem labelling to get thrown out of wack and you may decide you do want SELinux at some point in the future. SELinux is good at keeping currently valid labeling valid, not so much when it comes to relabeling a filesystem. The two should be functionally identical except that Permissive will still write to a log file (which itself should be rotated out regularly).
  2. Do a restorecon -R on the DocumentRoot for the website so that the third party software gets re-labeled with whatever context the Fedora project gave httpd_t access to. This is probably preferable if the web server will be exposed to a large number of potential users (like the internet or a large intranet site).

For the "scripts are showing up as text" thing, I would verify that mod_perl is installed. Fedora/RHEL/CentOS/etc usually drop a config in /etc/httpd/conf.d that adds the handler information for mod_perl, which isn't installed by default. If it isn't installed just do a yum install -y mod_perl and then restart httpd.

If it is installed, there may be something more going on, but I'm thinking that it's probably just that mod_perl isn't installed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.