0

I am using to apache httpd to serve my python application. The application is running perfectly in standalone mode using the binary executable command inginious-webapp. MongoDB also works fine.

But the problem arises when serving it though Apache HTTPD

When I browse the website I get a 500 error. This is the error_log [Wed Jun 14 06:00:20.113043 2017] [wsgi:error] [pid 1194] [client 125.99.159.82:29947] pymongo.errors.ServerSelectionTimeoutError: localhost:27017: [Errno 13] Permission denied, referer: http://<my_domain>.eastus.cloudapp.azure.com/

Config Info

Added apache to mongodb -> usermod -aG mongodb apache
Changed owner to apache -> chown -R apache:apache /var/www/INGInious

httpd.conf

# Default config till here. Changes follows

Include conf.modules.d/*.conf

#
# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.  
#
# User/Group: The name (or #number) of the user/group to run httpd as.
# It is usually good practice to create a dedicated user and group for
# running httpd, as with most system services.
#
User apache
Group apache

LoadModule wsgi_module /usr/lib64/python3.5/site-packages/mod_wsgi/server/mod_wsgi-py35.cpython-35m-x86_64-linux-gnu.so
WSGIScriptAlias / "/usr/bin/inginious-webapp"
WSGIScriptReloading On

Alias /static/common /usr/lib/python3.5/site-packages/inginious/frontend/common/static/
Alias /static/webapp /usr/lib/python3.5/site-packages/inginious/frontend/webapp/static/
Alias /static/lti /usr/lib/python3.5/site-packages/inginious/frontend/lti/static/

# 'Main' server configuration
#
# The directives in this section set up the values used by the 'main'
# server, which responds to any requests that aren't handled by a
# <VirtualHost> definition.  These values also provide defaults for
# any <VirtualHost> containers you may define later in the file.
#
# All of these directives may appear inside <VirtualHost> containers,
# in which case these default settings will be overridden for the
# virtual host being defined.
#

#
# ServerAdmin: Your address, where problems with the server should be
# e-mailed.  This address appears on some server-generated pages, such
# as error documents.  e.g. admin@your-domain.com
#
ServerAdmin root@localhost

#
# ServerName gives the name and port that the server uses to identify itself.
# This can often be determined automatically, but we recommend you specify
# it explicitly to prevent problems during startup.
#
# If your host doesn't have a registered DNS name, enter its IP address here.
#
ServerName http://<my_domain>.eastus.cloudapp.azure.com:80

#
# Deny access to the entirety of your server's filesystem. You must
# explicitly permit access to web content directories in other 
# <Directory> blocks below.
#
<Directory />
    AllowOverride none
    Require all denied
</Directory>

#
# Note that from this point forward you must specifically allow
# particular features to be enabled - so if something's not working as
# you might expect, make sure that you have specifically enabled it
# below.
#
<Directory "/usr/bin">
    <Files "inginious-webapp">
        Require all granted
    </Files>
</Directory>

<DirectoryMatch "/usr/lib/python3.5/site-packages/inginious/frontend/(.+)/static/">
    Require all granted
</DirectoryMatch>
# Rest Unchanged
Community
  • 1
  • 1
Harvey
  • 184
  • 1
  • 3
  • 15
  • The answer here seems most plausible https://stackoverflow.com/a/41359627/2313887 which basically suggests using the [`--lazy-apps`](http://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html#preforking-vs-lazy-apps-vs-lazy) option to uwsgi – Neil Lunn Jun 14 '17 at 06:44

1 Answers1

0

I was having the same issue, and after a fair bit of hair pulling I found out that selinux was enabled on the virtual machine I was using.

If it so happens you also have selinux enabled (http://www.microhowto.info/howto/determine_whether_selinux_is_enabled.html), to get around this issue you need to allow the httpd process make network requests. You can do that by executing the following:

sudo /usr/sbin/setsebool -P httpd_can_network_connect 1

and then restart the apache service.

Unfortunately, you will most likely run into another road block afterwards when INGInious attempts to connect to the docker daemon. To get around this you will need to create a local policy module. The local policy module will then permit INGInious to connect to the docker daemon. I recommend installing sealert. This can be done by running:

sudo yum install setroubleshoot setools

if you are using CentOS (and likely RedHat). Once you have sealert installed run:

sealert -a /var/log/audit/audit.log

This will give you some info about operations being blocked by selinux. If you dig through the log you will see that the httpd is being denied access to the socket for the docker daemon. Chances are it will give you some instructions on how to generate the local policy module for httpd. Using CentOS, I had to run:

ausearch -c 'httpd' --raw | audit2allow -M my-httpd
semodule -i my-httpd.pp

If ausearch returns an error indicating that /etc/selinux/targeted/contexts/files/file_contexts.local is not present, simply run:

sudo touch /etc/selinux/targeted/contexts/files/file_contexts.local
tnibbles
  • 93
  • 5