Compile and install Python’s MOD_WSGI for Apache2 in Ubuntu 18.04

Having installed mod_wsgi a couple of times on different machines, I decided to note down the steps I took and put together a guide. There are also some solutions to some issues that you may encounter, which left me clueless for a while. If you are looking for a guide to deploying a Flask/Django project, you will have to look elsewhere (for the time being).

This is for use with python3 using Ubuntu 18.04’s shipped version. You may need to tweak this guide to point to non-standard versions of python3 that you specifically want to use.

I believe some Ubuntu versions have pre-packaged mod_wsgi installations available. However, noted in a previous blog post, apache2 may flood error logs pointing to a mismatch with either differing python3 or apache2 versions and in my view, a clean compilation ensures a tailored fit to your current system without the worry of logging and runtime errors.

Things to note:

  • I prefer to compile inside the “/opt” directory. Please amend the guide to suite your preference
  • I will refer to the current latest version of mod_wsgi (4.6.4 at time of writing). This is for illustrative purposes only, and some directory paths will be different with different versions
  • The guide is built around CLi, and assumes you are comfortable with the basics


You will need to have installed some additional packages:

  • python3-dev  –  mainly for python3 header files for compilation
  • apache2
  • apache2-dev
  • gcc  –  *or an equivalent C compiler*

You may use apt install for all the above packages

Next, you will need to locate the latest mod_wsgi source files (found here)


Navigate to /opt and download the latest version of mod_wsgi:

$ cd /opt
$ wget

Unpack the tar:

$ tar -xzf 4.6.4.tar.gz mod_wsgi-4.6.4/

Configure Make file

Change into the unpacked directory:

$ cd mod_wsgi-4.6.4/

Complete a “test” run of the configure script to so you can debug any errors:

$ ./configure


  • Error: “configure: error: no acceptable C compiler found in $PATH
    Solution: install a C compiler:

    $ sudo apt install gcc


  • Error: “Checking Apache Version.. ./configure: line 2765: apsx: command not found
    Solution: install apache2-dev

    $ sudo apt install apache2-dev


  • Error: “checking for python… no
    Solution: add argument to ./configure to point to python3 (global) or full path

    $ ./configure --with-python=python3

If you run configure without any errors, you’re ready to compile!

Compiling mod_wsgi

The make file is ready. Run Make:

$ make

This will now compile mod_wsgi. It should complete without error.

We finish the process by installing mod_wsgi to our apache2 installation:

$ make install

Configure Apache2

Finally, we need to configure apache2 correctly to load the mod_wsgi module. There are 2 ways we can do this:

  1. The “lazy way”:
    Add the following to the end of the apache2.conf file:
    (located: “/etc/apache2/apache2.conf“)

    LoadModule wsgi_module /usr/lib/apache2/modules/

    Restart Apache2:

    $ sudo systemctl restart apache2

    If apache2 restarts without errors, you have successfully installed and loaded mod_wsgi!

  2. The “proper” way:
    Navigate to “/etc/apache2/mods-available“Create “mod_wsgi.conf”:

    $ sudo touch mod_wsgi.conf


    Add the following to” mod_wsgi.conf”:

    <IfModule mod_wsgi.c>

    For further information about the configuration options that can be included in “mod_wsgi.conf”, refer to docs :

    Create “mod_wsgi.load”:

    $ sudo touch mod_wsgi.load

    Add the following to “mod_wsgi.load”:

    LoadModule wsgi_module /usr/lib/apache2/modules/

    Activate module in Apache and follow onscreen instructions:

    $ sudo a2enmod mod_wsgi

    If apache2 restarts without errors, you have successfully installed and loaded mod_wsgi!

Session issue with Flask deployment – apache2/wgsi/Flask

The flask app in question was working fine within Flask’s own development server. Whilst deploying the app, I ran into a 2 problems.

The first was a mismatch with apache2_mod_wsgi and the python3 version. It was throwing apache2 error messages of terminating threads. In order to fix this, I had to compile mod_wsgi from source, which was relatively easy from automated scripts, but had to install all of the necessary python headers and C compilers to tailor this to the system. No more errors but it seems to run indifferently nonetheless.

At first I thought the threading issue caused the sessions being randomly dropped, which didn’t happen in dev. Which leads me to the second problem.

Starting a session through the app (login), I can click on as many session related pages fine within a short space of time. If I stopped for more then 10 seconds, the session would drop and would prompt to log in… again.

After alot of debugging and hunting, I found the problem to be actually in apache2 config for the site. Within the .conf, the WSGI configuration was fine. However, the standard Apache document root folder directive was set 1 level above the app.wsgi file.

I’m not too clued up on the exact reason for this behaviour, but I think that when the Apache worker idles, there is insufficient permissions to read from the instance source (.wsgi file). This might kill the worker (& the app instance) and forget any sessions.

A relatively easy fix for a big problem.

P.s. if someone could explain this phenomenon better to me, please do so I can learn/update the post! Thanks.

Coloured SSH terminal – Ubuntu host

If you SSH into a remote Ubuntu terminal and do not see coloured text, here might be a solution. The problem is on the remote host, where bash is missing the profile and configuration for coloured commands. I will help fix this.

Connect via SSH to the remote host. You need to look for 2 hidden files in the user’s home directory.

  1. .bashrc
  2. .profile

You can check by issuing:

ls -la

If you do not see the aforementioned files, this might be an easy fix.

You should already have a default copy of .bashrc and .profile in a directory called /etc/skel/.

Simply issue these commands to copy them into your user’s home directory:

cp /etc/skel/.bashrc ~/
cp /etc/skel/.profile ~/

Now test this by logging out of your user/SSH and connecting again. Hopefully now you should have a colourful terminal!

WordPress XMLRPC.php is now working!

I really like the additional features provided by the Jetpack plugin, and after the recent migration, it stopped working. I checked over permissions, .htaccess, WP configurations and even cross referenced some major server configs to try and figure it out.

I remembered that I had this issue before and needed to install another module somewhere, but unfortunately couldn’t quite put my finger on it. Looking at apache2 error logs, after several tries at linking to, and XML error showed up. A quick Google of this informed me of a PHP XML module.

The PHP module is needed to produce and receive the XML through the RPC API.

Since I’m using PHP 7.0, all I had to do was issue this command:

sudo apt install php7.0-xml

If your running a LAMP stack, you can change the version to your current PHP version, or simply:

sudo apt install php-xml

could work too (although some people have had issues with this “generic” module)

Restart Apache2 and you should be good to blog from anywhere!

Did you see it?

You know, I bet you didn’t! I moved servers again! It has been less then a year since it happened last, which is quite dissapointing. There are a few reasons for this. I’ll be kind and fail to disclose the company as the support has been first class. The VPS industry is becoming alot more competative, however.

A current distro wasn’t available at time of setting up. Meaning I had no choice but to use an Ubuntu 14.04 image which was already ageing at the time of setting it up. Although I was pretty comfortable and familiar with using it, the LTS clock was ticking.
I can say now, even though there’s a little time left, 14.04 is really showing it’s age.

Sluggish. Yes it was hard to tell if the software, configuration, OS or I/O was the issue, but it slightly hindered me none-the-less.

Manual backups… eeeugh. I could have paid more to have automatic backups, but I felt I was paying enough taking into account the previous points. Also it was a chore… my policy was to backup every month which wasn’t enough (even though this isn’t a business site). It was more difficult whilst having an hour or so spare on a slow internet.

Price, which is an important factor when you’re hosting a site as (at the moment) a hobbiest. Again, taking in all of the above, I felt I was paying way too much compared to other places.

I found myself staring into the VPS void. Again. Unsure of which direction to throw my money. OVH did not have a UK server location, my last experience with 1and1 left me feeling like a sudo user. I wittled it to 2 new hosts, dive into DigitalOcean or try Vultr. I credited both sites and spun up a vps and had a play around…. and was really impressed.

I bit the bullet and went with Vultr. I like the way the site is layed out, how easy going it seems. Its a nippy server, its alot cheaper (including automatic backups), it’s located in the UK with many images to choose from, and has a good solid self-help database which covers alot of different topics.

It took alot less time to set up then it did with the previous host too, which might not be surprising as 14.04 was alot more configuration intesive. Newer software with 16.04 kind of solves this with hardened config  as standard (although you still need to check)

Lastly, one feature I’ve really taken to Vultr’s login page! All the previous hosting companies have allowed (some of them weak passwords) just a user/email and password to login! You spend hours hardening the VPS, but you can guess a password and delete/change anything you like. This really needs to be looked at but thats a different story.

It’s early days but I’ve really enjoyed the experience so far! You can check vultr here!