Install WordPress on Debian 9 Using Xen Project PV DomU

The following tutorial describes how to install WordPress on a Xen Project PV DomU. This setup is useful for testing and tweaking your WordPress website before its public launch, or for WordPress plugin and theme development.

If you’re looking for LAMP or WordPress installation tips only, have a look at the table of contents and skip down to the appropriate section below.

Table of Contents:

1. Create Debian 9 PV DomU

In our first step, we’re going to create a small PV DomU with 512MB ram, 512MB swap, and 4GB of storage. Although these specs are fine for our intended use of the test server, feel free to modify your PV’s allocated resources to suit your project.

For the PV’s operating system (“OS”), we’ll be installing Debian 9 Stretch. However, the steps below were also successfully tested on Debian 10 Buster.

This tutorial assumes you already have Xen Project Hypervisor and Dom0 running on your computer. If you haven’t yet installed Xen, check out Installing Xen Project Hypervisor on Debian 9: An in-depth beginner’s guide.

1.1 Configure and Install Debian 9 PV DomU

In Dom0, execute the following command to create a new PV DomU as root user. For more information on creating PV DomU, check out the tutorial Using xen-tools to Create DomU Virtual Machines in Xen Project Hypervisor.

# xen-create-image --hostname=yoursite --lvm=vg0 --dist=stretch --dhcp --pygrub --swap=512M --memory=512M --size=4G --passwd

During the xen-create-image process, the test machine generated the following output:

General Information
Hostname       :  yoursite
Distribution   :  stretch
Mirror         :
Partitions     :  swap            512M  (swap)
                  /               4G    (ext4)
Image type     :  full
Memory size    :  512M
Bootloader     :  pygrub

Networking Information
IP Address     : DHCP [MAC: 00:16:3E:9F:94:C7]

Creating swap on /dev/vg0/yoursite-swap

Creating ext4 filesystem on /dev/vg0/yoursite-disk
Installation method: debootstrap

Running hooks

No role scripts were specified.  Skipping

Creating Xen configuration file

No role scripts were specified.  Skipping
Setting up root password
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
All done

Logfile produced at:

Installation Summary
Hostname        :  yoursite
Distribution    :  stretch
MAC Address     :  00:16:3E:9F:94:C7
IP Address(es)  :  dynamic
SSH Fingerprint :  SHA256:oJDJxULwyfIu28o/O1wPbZIvbvqlSiV4LTYOejlWsQY (DSA)
SSH Fingerprint :  SHA256:6Aq4FgDOl9RuvqF8TZQSAsYfYO3r6RC+Ez0hv5fGkdA (ECDSA)
SSH Fingerprint :  SHA256:FbyZilYXIVynyKckccOzBdkQaXTJNDhe7kkv84hxvL0 (ED25519)
SSH Fingerprint :  SHA256:6aX3axNnUm7tzugZoK1Anp6/65NFqOn3Z1GhKEnuRmU (RSA)
Root Password   :  N/A

1.2 Start Debian 9 PV Instance

Next we’ll use the xl create command to start the newly generated Debian 9 PV instance. Note that the “-c” option passes Dom0’s terminal to DomU. Use the “CTRL + ]” key combination to go back to Dom0 at any time.

# xl create -c /etc/xen/yoursite.cfg

Login as root user using the password you entered during the PV configuration and installation process, above.

1.3 PV Memory and Disk Statistics

The Debian 9 PV instance created during this tutorial provided the following memory and disk statistics:

# free -h

              total        used        free      shared  buff/cache   available
Mem:           490M         29M        421M        768K         39M        448M
Swap:          511M          0B        511M
# df -h

Filesystem      Size  Used Avail Use% Mounted on
udev            217M     0  217M   0% /dev
tmpfs            50M  768K   49M   2% /run
/dev/xvda2      3.9G  576M  3.1G  16% /
tmpfs           246M     0  246M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           246M     0  246M   0% /sys/fs/cgroup

2. Configure Debian 9

Now that the DomU is up and running with its fresh Debian 9 OS, let’s install a few packages and create a non-root user.

2.1 Install Packages and Create Non-root User with sudo Privileges

For the sake of security, we shouldn’t be using root user for every task. For this reason, we’re going to install the sudo package and create a user with sudo privileges.

Later on we’ll be using wget to download the WordPress package, so let’s install it now as well.

First we’ll refresh our package listing:

# apt-get update

Then we’ll install the sudo and wget packages:

# apt-get install sudo wget

Now that sudo is installed, we’ll create a user called “foo” (choose whatever user name you want):

# adduser foo

Then we’ll add the user foo to the sudo group:

# usermod -aG sudo foo

Now we can log out from the root user account using the “exit” command, and log back in as our new user foo.

2.2 Install Firewall and Configure for SSH

Keeping with the security theme, we’re going to install a firewall and allow login through SSH. For the purpose of this tutorial, ufw will do the trick.

$ sudo apt-get install ufw

Now we’ll allow incoming TCP connections to the server’s SSH port 22:

$ sudo ufw allow OpenSSH

Next, we’ll turn the firewall on:

$ sudo ufw enable

If you want to make sure that everything was configured properly, use the “ufw status” command:

$ sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere                  
OpenSSH (v6)               ALLOW       Anywhere (v6)

2.3 Install Everything Except WordPress Itself

Although you can easily install the wordpress package from the Debian repository, in this tutorial we’ve chosen to use the latest release as provided by Regardless, we’re going to wait until the LAMP stack is fully installed and configured before installing WordPress.

First we need to install the MariaDB and Apache2 packages and dependencies. These we’ll get from the Debian repository using the following two apt-get commands:

$ sudo apt-get install default-mysql-client default-mysql-server
$ sudo apt-get install apache2 ca-certificates libjs-cropper libapache2-mod-php php-gd php-getid3 php-mysql

3. Configure MariaDB

To get MariaDB ready for WordPress, we’ll run the mysql_secure_installation shell script, then configure a database and database user.

3.1 Secure MariaDB

Execute the mysql_secure_installation script and follow the instructions.

$ sudo mysql_secure_installation

Configuring the test machine generated the following questions and output:


In order to log into MariaDB to secure it, we'll need the current
password for the root user.  If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none): 
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.

Set root password? [Y/n] y
New password: 
Re-enter new password: 
Password updated successfully!
Reloading privilege tables..
 ... Success!

By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y
 ... Success!

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y
 ... Success!

By default, MariaDB comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] y
 ... Success!

Cleaning up...

All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.

Thanks for using MariaDB!

3.2 Create a Database and Database User

Login to mysql as root user using the password set during the mysql_secure_installation stage above. Note that, if you run the command as sudo, you may first have to enter the sudo password, then enter the MariaDB root password.

sudo mysql -u root -p

Now that we’re logged in to MariaDB as root, we’ll create a database user for the WordPress site called “bar”:

MariaDB [(none)]> CREATE USER 'bar'@'localhost' IDENTIFIED BY 'barpassword';
Query OK, 0 rows affected (0.00 sec)

Next, we’ll create a database for the WordPress site:

MariaDB [(none)]> CREATE DATABASE yoursite_db;
Query OK, 1 row affected (0.00 sec)

After that, we need to make sure that the database user is authorized on the new database. We do that with the following command:

MariaDB [(none)]> GRANT ALL ON yoursite_db.* TO 'bar'@'localhost';
Query OK, 0 rows affected (0.00 sec)

Flush the privileges…

Query OK, 0 rows affected (0.00 sec)

And exit…

MariaDB [(none)]> exit;

If you want to make sure that everything was configured properly, while logged in to MariaDB, check what databases are available with the following command:

MariaDB [(none)]> SHOW DATABASES;
| Database           |
| information_schema |
| mysql              |
| performance_schema |
| yoursite_db        |
4 rows in set (0.00 sec)

Users can be checked by executing the following:

MariaDB [(none)]> SELECT User,Host FROM mysql.user;
| User     | Host      |
| root     | localhost |
| yoursite | localhost |
2 rows in set (0.00 sec)

4. Configure Apache2

With the database and database user ready to go, the next step is to configure Apache2.

4.1 Check If Apache2 Module “mod_rewrite” is Enabled

For pretty permalinks and HTTP/HTTPS redirection, our WordPress configuration will need the Apache2 rewrite module enabled. If you’re not sure you’ll need mod_rewrite for your particular setup, feel free to skip this step now as it can be configured later if necessary.

First we’ll check if the rewrite module is already enabled by looking in the “/etc/apache2/mods-enabled/” directory:

$ ls /etc/apache2/mods-enabled/
access_compat.load  authz_user.load  filter.load       php7.0.load
alias.conf          autoindex.conf   mime.conf         reqtimeout.conf
alias.load          autoindex.load   mime.load         reqtimeout.load
auth_basic.load     deflate.conf     mpm_prefork.conf  setenvif.conf
authn_core.load     deflate.load     mpm_prefork.load  setenvif.load
authn_file.load     dir.conf         negotiation.conf  status.conf
authz_core.load     dir.load         negotiation.load  status.load
authz_host.load     env.load         php7.0.conf

It’s not in the output, so we’ll enable the rewrite module using the “a2enmod” command:

$ sudo a2enmod rewrite
Enabling module rewrite.
To activate the new configuration, you need to run:
  systemctl restart apache2

Since there are more apache2.conf configurations needed, we’ll wait until we’re all done to restart the apache2 unit.

4.2.1 Configure apache2.conf to Disable Indexes

The next step is to configure Apache2 to restrict website visitors’ access to server directories, also known as “directory browsing”. In the apache2.conf file, we’ll be removing “Indexes” from the Options line.

Here’s what the section looks like before:

<Directory /var/www/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted

And this is what the section looks like after Indexes is removed:

<Directory /var/www/>
    Options FollowSymLinks
    AllowOverride None
    Require all granted

Note that we’re keeping “AllowOverride None” because our setup doesn’t require .htaccess files. And, we’re also leaving “Require all granted” so any user can access our website’s content stored under /var/www/ (unless specifically restricted, as configured below).

4.2.2 Configure apache2.conf to Restrict Access to /usr/share Directory

The next step is optional but, since were not using the “/usr/share” directory for our website configuration, it seems more secure to remove access to it from the apache2.conf file.

This is the original /usr/share section in the apache2.conf file that we’ll comment out:

<Directory /usr/share>
    AllowOverride None
    Require all granted

And this is what it looks like with the four lines commented out:

#<Directory /usr/share>
#   AllowOverride None
#   Require all granted

4.2.3 Configure Apache2.conf to Add Global ServerName

Since there were recurring error messages in the apache log files of the test server, located at “/var/log/apache2/error.log”, it was decided to add a global “ServerName” directive to the apache2.conf file.

The recurring message in the error.log file, which occurred on server restart, was as follows:

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, 
using Set the 'ServerName' directive globally to suppress this message

To fix this message, the ServerName directive and test server IP address were added to the apache2.conf file. Make sure to use the IP address of your server.


4.3 Disable 000-default.conf, and Create and Configure 000-yoursite.conf

Now that the apache2.conf file global directives are set, it’s time to create our “virtual host” conf file. First we’ll disable the Apache2 default virtual host “000-default.conf”, which is located in the “/etc/apache2/sites-enabled/” directory.

To see what virtual hosts are enabled, use “ls” to list the directory contents of /etc/apache2/sites-enabled/:

$ ls /etc/apache2/sites-enabled/                 

Next, we’ll disable the Apache2 default virtual host using the “a2dissite” command:

$ sudo a2dissite 000-default.conf
Site 000-default disabled.
To activate the new configuration, you need to run:
  systemctl reload apache2

Now, we’ll change to the directory where the Apache2 virtual hosts are stored, “/etc/apache2/sites-available/”:

$ cd /etc/apache2/sites-available

And, make a copy of the 000-default.conf file so we can use it as the base for the new virtual host conf file called “000-yoursite.conf”:

$ sudo cp 000-default.conf 000-yoursite.conf

Now we’ll edit the new conf file to suit our website’s purposes:

$ sudo nano 000-yoursite.conf

4.3.1 Apache2 Virtual Host Configuration

We need to change the virtual host’s DocumentRoot to the directory where WordPress is going to be installed. For this tutorial, we’ll create a directory called “yoursite” inside the /var/www/ directory. Don’t worry, we haven’t created the “yoursite” directory yet, this will be done when we install WordPress.

In the virtual host configuration file we’ll anticipate the creation of “/var/www/yoursite” and add that as the DocumentRoot. Change the following line in “000-yoursite.conf”:

DocumentRoot /var/www/html


DocumentRoot /var/www/yoursite

Then we’ll add in the ServerName and ServerAlias directives, and some rewrite module code to enable pretty permalinks and redirection, after the line “<VirtualHost *:80>”:



<Directory /var/www/yoursite>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

The 000-yoursite.conf file now has the following un-commented code:

<VirtualHost *:80>

    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/yoursite

    <Directory /var/www/yoursite>
        RewriteEngine On
        RewriteBase /
        RewriteRule ^index\.php$ - [L]
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule . /index.php [L]

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined


Now that we’ve finished the preliminary virtual host configuration, we can load the virtual server and restart the apache2 unit.

To load the virtual host run the following command:

$ sudo a2ensite 000-yoursite.conf 
Enabling site 000-yoursite.
To activate the new configuration, you need to run:
  systemctl reload apache2

Then we’ll reload apache2:

$ sudo systemctl reload apache2

5. Configure WordPress

With MariaDB and Apache2 ready to go, we can download, install and configure WordPress.

5.1 Download and Install WordPress Package

For this step we’ll download the latest release of WordPress from to the user’s home directory, “/home/foo/”:

$ cd /home/foo
$ wget

Next, we’ll use the tar command to extract the contents of the downloaded archive file into the current directory. This should automatically create a directory called “wordpress” containing all the required WordPress files.

$ tar xzf latest.tar.gz

Now we’ll remove the unneeded “index.html” file stored in the “/var/www/html/” directory, then change the /var/www/html/ directory name to “/var/www/yoursite/”. Naming the directory as such makes it easier to add new WordPress instances in the future.

$ sudo rm /var/www/html/index.html
$ sudo mv /var/www/html/ /var/www/yoursite

With the directory in place, copy the contents of the wordpress folder to “/var/www/yoursite”:

$ sudo cp -r wordpress/* /var/www/yoursite

Last, we’ll use chown and chmod to provide required ownership and read/write/execute permissions to the newly installed WordPress files and directories:

$ sudo chown -R www-data:www-data /var/www/yoursite
$ sudo find /var/www/yoursite -type d -exec chmod 755 {} \;
$ sudo find /var/www/yoursite -type f -exec chmod 644 {} \;

5.2 Configure Firewall for HTTP/HTTPS

Now that WordPress is installed on the server, in order to finish its setup and connect it to the database, we’ll need to access it via a web browser. However, remember that we’ve configured the firewall to only allow SSH connections, so let’s change the firewall setting to allow for HTTP/HTTPS.

We’ll pass the “WWW Full” value to ufw allowing incoming traffic on ports 80 and 443:

$ sudo ufw allow "WWW Full"

Then we’ll do a quick check on the status of the firewall, which should result in the following output:

$ sudo ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere                  
80,443/tcp (WWW Full)      ALLOW IN    Anywhere                  
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)             
80,443/tcp (WWW Full (v6)) ALLOW IN    Anywhere (v6)

With the WordPress setup process open to the world, we should either use a web browser on a client machine to go to the server’s IP address ASAP, or turn the HTTP/HTTPS firewall allow rules off until we’re ready to finish the setup.

5.3 WordPress Installation Process

Once connected to the server via the client’s web browser, follow the steps to set up the WordPress site. Remember to use the MariaDB database name, user name, and password you created above (for the test server the values we used above were: “yoursite_db”, “bar”, and “barpassword”).

WordPress database setup

As the database is hosted on the same machine, the Database Host value of “localhost” is correct. To make it easier to add other WordPress sites to the database in the future, use a custom Table Prefix such as “your_”.

For security reasons, we’ll create a separate admin user name for the WordPress site, which will be different from the name(s) we’ll use for our public posts. Sticking with the foobar theme, the WordPress admin will be “snafu”, and we’ll use a secure password.

Note that you may not want to set the “WordPress Address” and “Site Address” values until DNS to the server is working. However, if you insist, you can modify the “/etc/hosts” file on a client machine adding the IP address of the server and domain name/address as configured in Apache2/WordPress.

Adding this line to the /etc/hosts file of the client machine will allow you to hit the site from its web browser:

At this point, your WordPress site should be up and running, and ready for further personalized configuration and/or content management.

6. Secure Apache2 / WordPress

If you’re planning on going public with your website, here are a few configurations to better secure WordPress against attackers.

6.1 Remove Unneeded Files

If you won’t be needing the “readme.html” and “license.txt” files in the website’s root directory, you might as well delete them. Same goes for “wp-config-sample.php”, which isn’t needed after WordPress is all configured.

Remove the three files with the following commands:

$ sudo rm /var/www/yoursite/readme.html
$ sudo rm /var/www/yoursite/license.txt
$ sudo rm /var/www/yoursite/wp-config-sample.php

6.2 Deny Access to .php Files in Select Directories

Blocking the ability to run .php files in the /wp-includes/ and /wp-content/uploads/ directories helps protect the core WordPress system from attackers uploading and executing malicious .php files.

If this configuration suits your security profile, consider adding the following code to the virtual host configuration file located in the “/etc/apache2/sites-available/” directory.

Open the 000-yoursite.conf file with nano, and add the following code:

$ sudo nano /etc/apache2/sites-available/000-yoursite.conf
<Directory /var/www/yoursite/wp-includes>
    <Files "*.php">
        Order Deny,Allow
        Deny from all

<Directory /var/www/yoursite/wp-content/uploads>
    <Files "*.php">
        Order Deny,Allow
        Deny from all

Note that changes will not take effect until the apache2 unit is reloaded/restarted.

$ sudo systemctl reload apache2

6.3 Deny Access to wp-config.php File in Core Directory

The “wp-config.php” file is an important file in the WordPress core. It contains database information (database name, user name, and password), and other essential configuration settings best kept private.

To deny attackers access to this file, add the following code to the virtual host’s conf:

$ sudo nano /etc/apache2/sites-available/000-yoursite.conf

Include the following code under the heading “<Directory /var/www/yoursite>”:

<Files "wp-config.php">
    Order Deny,Allow
    Deny from all

Note that changes will not take effect until the apache2 unit is reloaded/restarted.

$ sudo systemctl reload apache2

6.4 Deny Access to xmlrpc.php File in Core Directory

Some third-party apps use “xmlrpc.php” to connect to WordPress for site management. If you’re not using a third-party app to connect to WordPress, access to xmlrpc.php should be restricted: the file is a highly targeted access point for attackers.

To deny attackers access to xmlrpc.php, add the following code to the virtual host’s conf file:

$ sudo nano /etc/apache2/sites-available/000-yoursite.conf

Include the following code under the heading “<Directory /var/www/yoursite>”:

<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all

Note that changes will not take effect until the apache2 unit is reloaded/restarted.

$ sudo systemctl reload apache2

6.5 Password Protect /wp-admin/ and wp-login.php

Most WordPress attackers wanting root access to the website go about achieving this goal by brute-forcing username/password combinations. Securing login credentials by adding a second layer of authentication is one of many protections against this type of attack.

Although it’s more secure to employ authentication and authorization features combined with the Apache2 SSL module, “mod_ssl”, configuring HTTPS/SSL may be overkill for a test server on your local network.

If you’re planning on opening the website to the world, HTTPS/SSL is more easily implemented on a public website with DNS properly configured. More information on configuring HTTPS/SSL is provided below for those interested.

For now, we’ll setup authentication over HTTP, which means that credentials are passed unencrypted over the local network.

6.5.1 Check for Enabled Apache2 Modules

First we’ll make sure that the modules “mod_authn_core” and “mod_authz_core” have either been built into the httpd binary or loaded by the httpd.conf configuration file. The easiest way to do this is by listing the directory contents of “/etc/apache2/mods-enabled/”:

$ ls /etc/apache2/mods-enabled
access_compat.load  authz_user.load  filter.load       php7.0.load
alias.conf          autoindex.conf   mime.conf         reqtimeout.conf
alias.load          autoindex.load   mime.load         reqtimeout.load
auth_basic.load     deflate.conf     mpm_prefork.conf  rewrite.load
authn_core.load     deflate.load     mpm_prefork.load  setenvif.conf
authn_file.load     dir.conf         negotiation.conf  setenvif.load
authz_core.load     dir.load         negotiation.load  status.conf
authz_host.load     env.load         php7.0.conf       status.load

From this output we can see that the modules we need were enabled by default.

6.5.2 Create Password Directory and Run htpasswd Script

Next we’ll create a secure directory to store and create the htpasswd passwords file. By secure directory, we mean that the directory should not be in the website/WordPress directory path.

We’ll create the secure directory in “/etc/apache2/” and call it “passwd”:

$ sudo mkdir /etc/apache2/passwd

Now we can run the htpasswd script to create the password file. Note that the “-c” option creates a new file, otherwise the program will append an existing file. The command also contains the path to the directory/filename containing the password file, “/etc/apache2/passwd/yoursite”, and the authorized user to add. In our example the user is “foo”.

$ sudo htpasswd -c /etc/apache2/passwd/yoursite foo
New password: mypassword
Re-type new password: mypassword
Adding password for user foo

Consider using a different user/password combination for each layer of authentication; for example, one combo for the htpasswd layer and a second combo for the WordPress layer.

6.5.3 Update the Virtual Host Conf File

After the password file is created, complete the htpasswd configuration by including the following code under the heading “<Directory /var/www/yoursite>” in the virtual host’s conf file:

$ sudo nano /etc/apache2/sites-available/000-yoursite.conf
<Files "wp-login.php">
    AuthType Basic
    AuthName "Restricted Files"
    # (Following line optional)
    AuthBasicProvider file
    AuthUserFile "/etc/apache2/passwd/yoursite"
    Require user foo

Make sure to change “AuthUserFile” to the path of your password file, and “Require user” from “foo” to whatever name you chose during the htpasswd process, above.

Note that changes will not take effect until the apache2 unit is reloaded/restarted.

$ sudo systemctl reload apache2

Now is the time to test whether this works for the following website directories and files: /login, /wp-login.php, /admin, /wp-admin, or clicking the “Log In” link the menu. Don’t actually login until you’ve tested all five ways!

Note that the site directory “/wp-admin/” redirects to “/wp-login.php”, so protection is only needed on the latter.

For more configuration information, check out the official Apache2 documentation here.

6.6 Optional: Configure HTTPS/SSL

If your site is public facing and DNS is setup and working using HTTP, then it is fairly easy to configure HTTPS/SSL using the certbot command.

First you’ll need to install the certbot package:

$ sudo apt-get install certbot python-certbot-apache

Then run certbot with the “–apache” flag:

$ sudo certbot --apache

It’s as simple as following the steps in terminal; no further information is needed. To learn more about certbot check out its official site here.

7. Create Second WordPress Site on Server

For information on how to add a second WordPress website to your server, see Create Second WordPress Site on Server.