Cannot start Apache server with Bugzilla installed
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?
linux apache-httpd bugzilla
add a comment |
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?
linux apache-httpd bugzilla
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 asetenforce 0
and try again to confirm whether this is the case.
– Bratchley
Jun 27 '13 at 15:53
add a comment |
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?
linux apache-httpd bugzilla
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?
linux apache-httpd bugzilla
linux apache-httpd bugzilla
edited 41 mins ago
Rui F Ribeiro
41.8k1483142
41.8k1483142
asked Jun 27 '13 at 15:16
Michael HillmanMichael Hillman
1053
1053
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 asetenforce 0
and try again to confirm whether this is the case.
– Bratchley
Jun 27 '13 at 15:53
add a comment |
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 asetenforce 0
and try again to confirm whether this is the case.
– Bratchley
Jun 27 '13 at 15:53
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
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
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
add a comment |
1 Answer
1
active
oldest
votes
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:
- 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). - 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.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f80898%2fcannot-start-apache-server-with-bugzilla-installed%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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:
- 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). - 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.
add a comment |
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:
- 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). - 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.
add a comment |
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:
- 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). - 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.
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:
- 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). - 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.
answered Jun 27 '13 at 16:04
BratchleyBratchley
12.1k74688
12.1k74688
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f80898%2fcannot-start-apache-server-with-bugzilla-installed%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 asetenforce 0
and try again to confirm whether this is the case.– Bratchley
Jun 27 '13 at 15:53