Cannot start Apache server with Bugzilla installed












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?










share|improve this question

























  • 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















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?










share|improve this question

























  • 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












0








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 a setenforce 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













  • 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



















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












1 Answer
1






active

oldest

votes


















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.






share|improve this answer























    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    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.






    share|improve this answer




























      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.






      share|improve this answer


























        0












        0








        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jun 27 '13 at 16:04









        BratchleyBratchley

        12.1k74688




        12.1k74688






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            CARDNET

            Boot-repair Failure: Unable to locate package grub-common:i386

            Aws NAT - Aws IGW- Aws router