So we’ve gotten our Pi up and running and with a minor amount of security to help us through these trying times. But like Abraham Lincoln said, “nothing beats a good password on your web server. So change is often!” Now we move on to the guts we’ll need to get WordPress working.

The Needed Installs

It needs to be said, Raspian is fickle. Well, any Linux system is actually fickle, but for some reason, Raspian seems especially fickle when it comes to order of operation with regard to how things are installed. As such, I’ve written the install of the next three applications specific to how I got them to install without error. It took me several times to do so and I’ve been able to repeat it. It may seem odd, but it works.

This is what we’re adding, in order. We’re going to first install all three then we’ll get into their configuration Trust me, it’s better this way.

  1. MariaDB;
  2. Nginx, our web server application; and
  3. PHP 7.1

MariaDB Install

Adding MariaDB is a simple install:
sudo apt install mariadb-server

Nginx Install

Next, install the Nginx server via:
sudo apt install nginx

PHP7.1 Install (this isn’t straightforward…)

The standard stretch repository doesn’t have PHP7.1 available at this time (they use the much more stable version of PHP5 (I think 5.6). But the buster repository does (note, however, though this has been proven very stable, it’s still considered beta for RPi). First, we need to open up our sources.list to allow apt to find it. This is what Raspian uses to find the package list for all the available programs you can install.

sudo nano /etc/apt/sources.list

Your list should look pretty standard. Here’s mine without edit:

At the top you’ll see deb stretch main contrib non-free rpi. We basically want to clone that, and instead of using stretch we’ll sub in buster. Copy this:

deb buster main contrib non-free rpi

and place it below the last line. It should look like this:

buster added to sources.list

Save your file (Control + X, Y, Enter) and update your sources;

sudo apt update

Now let’s install what we need from PHP7.1:

sudo apt install php7.1-fpm php7.1-common php7.1-mysqlnd php7.1-xmlrpc php7.1-curl php7.1-gd php7.1-cli php-pear php7.1-dev php7.1-imap php7.1-mcrypt -y

To make sure we’re all good, let’s check the PHP-FPM version data:

sudo php-fpm7.1 -v

You should get something like:

sudo php-fpm7.1 -v

PHP7.1 is installed!


As noted above the buster repository is a beta repository (technically called testing). With that said, it is my recommendation that you go back into your source.list file and comment out (add # ) the buster line. If you don’t, your entire system will update to “testing” environment vs. that of the stable one (mostly stable, less that of PHP7.1) you’re running now the next time you run an update. Consider yourself warned.

We (that is, you and I) now have the backbone of what we need installed to get WordPress running. However, that’s just the basic install and it doesn’t do anyone much good in such a state. It’s now time to tailor our applications to work within a WordPress ecosystem.

Maria DB Configuration

It’s already there, now we need to get it running and in working order for WordPress; run:

sudo mysql_secure_installation

Most of the questions will be easy. For some reason on Raspian, you’re not asked to set up a root password as you are with some other distros, but that’s ok, we’ll get through this. Since we didn’t set one up, go ahead and hit Enter. Then you’ll be asked if you’d like to set one. Yes. Yes, we would… then answer the rest of the questions (I usually answer yest to them all).

sudo mysql_secure_installation

We are going to set up a new user and create databases in the next part of this series.

Nginx Configuration

There are a few sites out there that’ll show, or attempt to show, you how to get the bleeding edge Nginx installed on your RPi, however, I’ve found that in the last four attempts to do just that- it failed and that’s why I had you install the current stable one. Now, to be fair, those failures could have just as easily been my fault. Meh.

In the end, the current version (v. 10.1 as of this writing) of Nginx available for use on a Raspberry Pi is perfectly adequate for a smaller site(s) (I only do about 300 visits a day on here (on a REALLY good day) and about 150 on my other site… the Pi keeps going!). Enough yapping, we already installed Nginx, so let’s start it:

sudo service nginx start

You should be able to test the web server by simply heading to your Raspberry Pi’s web address, in my case I’m heading to This is what we should get-

Welcome to nginx!

Now that we have our web server backbone installed it’s time to do some minor edits to ensure we’re actually making the best of our limited resources. For this, I’m using a mix of edits found on a site called e-tinkers and another, deliciousbrains (and one or two other tidbits from other sites). First, we want to get some info from your Pi to input into some line in a few moments. Let’s see how many cores our server has and what it’s open file limit is; in terminal enter:

grep processor /proc/cpuinfo | wc -l && ulimit -n

If you’re running a RPi 3 you should have 4 cores and an open file limit, per core, of 1024. Here’s the output from my Pi:

grep processor /proc/cpuinfo | wc -l && ulimit -n

Make note of your numbers, then let’s open the
nginx.conf file:

sudo nano /etc/nginx/nginx.conf

Here’s the top portion of mine, unchanged:

sudo nano /etc/nginx/nginx.conf

(A copy of my whole changed nginx.conf file is down below a little bit…)

  1. Here we’re going to start with changing worker_processes from auto to the number 4 (the number of cores your Pi has as noted when you ran the bit of code a moment ago). We will also change worker_connections from its standard 768 to 4096. How’d we get this number? We took the output of the second command above (unlimit -n) which told us what our open file limit was per core. Since we have four cores we do a little math (4 x 1024 = 4096). As noted on deliciousbrains, “…the number of connections doesn’t directly equate to the number of users that can be handled by the server, as the majority of web browsers open at least 2 connections per request.”
  2. Next, uncomment (remove the #) from multi_accept and make sure it’s left to on.
  3. Edit the keepalive_timeout from default 65 to 5.
  4. Remove the comment (#) from the server_tokens directive and ensure it is set to off.
  5. Just below the server_tokens directive add (type in) the client_max_body_size directive and set this to 64m;. This will be our max media library upload size. You can change it to whatever you want but make note of it as we’ll be using this number again later when we edit some PHP files.
  6. Go ahead and uncomment the gzip_vary and leave it to on.
  7. Uncomment the gzip_comp_level and make sure it’s at 5
  8. Remove the hashtag (uncomment) gzip_http_version 1.1.
  9. Right below gzip_http_version 1.1 add gzip_min_length 256;
  10. Now, delete the gzip_types line and replace it with:
  11. gzip_types

After you’ve made all of your edits go ahead and save your work (Control + X, Y, Enter). We now need to test our Nginx configuration. We do this with:

sudo nginx -t

If all is as it should be you’ll get something like this:

sudo nginx -t

However, if you got an error go back into your .conf file and be sure you placed a “;” at the end of each directive. Without it, the file can’t be read properly.

With no errors (fingers crossed) we can go ahead and restart Nginx:

sudo service nginx restart

Here’s a copy of my nginx.conf file for you to copy or check against (or just do a copy/paste):

user www-data;
worker_processes 4;
pid /run/;
include /etc/nginx/modules-enabled/*.conf;
events {
        worker_connections 4096;
        multi_accept on;
http {  
        # Basic Settings
        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 5;
        types_hash_max_size 2048;
        server_tokens off;
        client_max_body_size 64m;
        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;
        include /etc/nginx/mime.types;
        default_type application/octet-stream;
        # SSL Settings
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; 
        # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;
        # Logging Settings
        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;
        # Gzip Settings
        gzip on;
        gzip_vary on;
        gzip_proxied any;
        gzip_comp_level 5;
        # gzip_buffers 16 8k;
        gzip_http_version 1.1;
        gzip_min_length 256;
        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;

There is no doubt you can do more with Nginx but I’m operating on the assumption that we want to get to the end state of getting our sites working sooner rather than later. So, after you’re up and running, check out the Nginx documentation for more info and tricks.

PHP 7.1 Configuration

I make a big deal of installing 7.1 on the RPi because it isn’t the standard flavor of PHP for the Pi. By default, the RPi is still using PHP5. Not that it doesn’t get the job done, but speed benefits of 7 over 5 are rather nice. Here’s a great page that discusses it too.

That’s just an added bonus… now you know why I wanted to install it (and you too). Now it is time to open up our default Nginx server block and ensure PHP will work correctly with everything else:

sudo nano /etc/nginx/sites-available/default

Look for the line that reads

index index.html index.htm index.nginx-debian.html;

and change it to

index index.php index.html index.htm;

Save it (Control + X, Y, Enter). We also need to update the server block to recognize our PHP install. We’re going to edit the section under

# pass the PHP scripts to FastCGI server listening on
# location ~ .php$ {

And change it to:

# pass the PHP scripts to FastCGI server listening on
location ~ .php$ {
include snippets/fastcgi-php.conf;
# # With php7.1-fpm:
fastcgi_pass unix:/var/run/php/php7.1-fpm.sock;
fastcgi_split_path_info ^(.+.php)(/.+)$;

Since we made some edits to the Nginx system (do this every time you make an edit) we need to test and reload the file again; test it via

sudo nginx -t

And then reload;

sudo service nginx reload

We also need to do some PHP maintenance to match our Nginx config file we made a bit ago. Open with:

sudo nano /etc/php/7.1/fpm/php.ini

We’re going to make two changes to match the client_max_body_size directive we make in our default server block before. You’ll recall we placed that at 64m. With the php.ini open search for (use Control + W to search): upload_max_filesize and post_max_size and change their current value to 64. Then save (Control + X, Y, Enter) and test our PHP again;

sudo php-fpm7.1 -t

All should be good. And if that’s that case, let’s do a restart via:

sudo service php7.1-fpm restart

The last part of this is to test our PHP install by creating a PHP info page;

sudo nano /var/www/html/index.php

Within that file put the PHP info code:

// Show all information, defaults to INFO_ALL


Save your file (Control + X, Y, Enter) and refresh your browser to your Nginx install (recall mine is You should get something like this:

PHP Info

This is telling us that PHP is installed and working. This also tells us we can move on and get WordPress up and running. Let’s go to Part III.

Part 0 | Part I | Part II | Part III | Part IV: Soon

Leave a Reply

Your email address will not be published. Required fields are marked *