This is an issue if you have customised that configuration file on your system – the system doesn’t know whether it should keep your version, use the new one, or something else. So it asks you to decide what to do about it.

I’m using Debian, which uses the dpkg package management system – that name may be unfamiliar, but if you’ve used any of the Debain family (Ubuntu, Mint, MX, elementary etc.) you will have used one of the friendlier wrappers around it: apt or apt-get.

Today, it’s the Collabora Office configuration file that has been updated:

Configuration file '/etc/loolwsd/loolwsd.xml'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ? Your options are:
    Y or I : install the package maintainer's version
    N or O : keep your currently-installed version
      D    : show the differences between the versions
      Z    : start a shell to examine the situation
 The default action is to keep your current version.
*** loolwsd.xml (Y/I/N/O/D/Z) [default=N] ?

• The first option is self-explanatory – you’ll lose any customizations you’ve made, but that might be OK for you.
• Keeping your currently-installed version is usually OK – well designed software shouldn’t break because it’s missing a line in an old configuration file.

In either case the system will keep a copy of the one you don’t pick, so you can change your mind later. If you choose to use the package mantainer’s version, there will be a copy of your old one with .dpkg-old added to the filename. If you keep you own config file, the package maintainer’s version will be saved alongside it, with .dpkg-dist added to the filename.

• Choosing option D can help you decide – but ultimately doesn’t resolve the situation.
• Option Z is the point of today’s post – this is how you can fix the situation.

Lets hit Z, and this is what I get:

 The default action is to keep your current version.
*** loolwsd.xml (Y/I/N/O/D/Z) [default=N] ? Z
Useful environment variables:
 - DPKG_SHELL_REASON
 - DPKG_CONFFILE_OLD
 - DPKG_CONFFILE_NEW
Type 'exit' when you're done.
root@waldorf:/# 

The system tells you about 3 environment variables that might be useful to help fix the situation. here I’ve use the echo command (with a $ before the environment variable name) to see what’s in them:

root@waldorf:/# echo $DPKG_SHELL_REASON
conffile-prompt
root@waldorf:/# echo $DPKG_CONFFILE_OLD
/etc/loolwsd/loolwsd.xml
root@waldorf:/# echo $DPKG_CONFFILE_NEW
/etc/loolwsd/loolwsd.xml.dpkg-new

DPKG_CONFFILE_PROMPT isn’t much use to us, but the other two are. We can start a program to compare and merge the differences between the two. I’m using Neovim in diff mode – there are lots of otherways of doing this – I’d suggest you do your research and find your preferred merge tool or text editor.

root@waldorf:/# nvim -d $DPKG_CONFFILE_OLD $DPKG_CONFFILE_NEW

I wont to get into the details of how to use [Neo]vim, but if you’re already a vim user and haven’t used diff mode before, these commands will get you started. You can find more info in the documentation.

Note that the last two commands will make the files the same at that point

Modifiy one of the files (I typically modify my old file – pulling the changes from the new one that I want, and leaving the ones that I don’t), then save and exit your text editor or mergetool

Type exit at the prompt, then the system will ask you again what you want to do:

*** loolwsd.xml (Y/I/N/O/D/Z) [default=N] ?

In this case I’ll choose N or O because I’ve made the changes I want to the original config file.

The idea is to take you through all the steps needed to get up and running, some basic familiarity with computers and Linux is assumed, but not a lot.

• Server Setup 1: OS installation
  This goes through a few pre-requisites, and then launches into the installation.
• Server Setup 2: Initial tweaks
  These first few steps will make your life easier when administering this server.
• Server Setup 3: Install Webserver
  We’ll install and test the webserver software – Apache.
• Server Setup 4: Going Public
  Configure the server, DNS and your router to allow public access to a placeholder website.
• Server Setup 5: HTTPS
  Enable secure connections to your new website with Lets Encrypt and certbot.
• Server Setup 6: WordPress Pre-requisites
  Get ourselves ready to install WordPress – we need PHP and a database.
• Server Setup 7: Install WordPress
  Get WordPress installed so you have a functional website!
• Server Setup 8: WordPress tweaks
  A few tweaks to optimise WordPress.
• Server Setup 9: Nextcloud Prep
  Preparatory work before the Nextcloud installation.
• Server Setup 10: Nextcloud Installation
  Get the database and files system configured, then install Nextcloud
• Server Setup 11: Config Improvements
  Some little tweaks to improve the security of our server
• Server Setup 12: Collabora
  Install and configure Collabora Online Development Edition
• Server Setup 13: Security Improvements
  Move the WordPress configuration out of the web root
• Server Setup 14: Backups
  This shows how to collect together all the data you need to completely back up your server.
• Server Setup 15: Optional Extras
  Further optional tweaks to make your installation better.

Now you’re up and running with what should be a stable and secure installation of WordPress and Nextcloud with Collabora.

There are plenty more tweaks you can work on yourself:

Server Administration

• Advanced HTTPS – you can check your config with https://www.ssllabs.com/ssltest/. You have choices about how you want to set up your system – more secure or more compatible with older clients. This tool from Mozilla provides recommendations for the the Apache configuration you need.
• Email configuration – This allows either system to send emails. Best way to do it us an existing email service, and let your server connect to that. s-nail and exim can both do this.
• You can keep you system automatically up to date with the unattened-upgrades package – this keeps your system up to date. If email is configure it’ll send you an summary of what it’s updated.

WordPress:

WordPress relies on htaccess for a few things, mainly nicely writing urls for permalinks. However, .htaccess files have a problem – they’re checked every time someone visits your site. You can reconfigure apache to load the data from the .htaccess file once, instead of on every request.

Be careful, there may be multiple .htaccess files, and some plugins install their own, so use these commands to find them all:

cd /var/www/wordpress
find | grep htaccess

Nextcloud

A few ideas:

• Work your way through the list in administration section – the links to the documentation will help a lot.
• Background jobs: Try setting up a systemd timer or traditional crontab. Have a look in Basic Settings in the Settings menu for an Administrator.
• Scan you installation for security issues https://scan.nextcloud.com/
• Include .htaccess instead of loading it every time, like for WordPress.

User friendliness

These are a few niceties you might try to help with general use:

• Set up passwordless login: https://linuxize.com/post/how-to-setup-passwordless-ssh-login/
• Use tmux to keep you shell sessions alive.

There’s lots of ways you could lose your website – a hard drive can fail, the server could be damaged by a lightning strike, or even stolen in a burglary. To get back up and running you’ll need to fix or replace the hardware, but this post is meant to make sure you have the data you need restore all the applications too.

Backup Options

There are a few ways to approach backups, but the key things are:

• What to back up
• Where to back up

I’ll be focussing on What, but will mention a few of your options for Where at the end.

What to back up

Whole system

The first thing I should mention is that you might have the option of backing up the whole system in one go. Many systems administrators don’t install their servers directly onto a computer, they use Virtualisation, which means first you install a special kind of operating system called a hypervisor, whose only job is to create and run virtual machines (VM) – a computer within the computer. You can then install the OS you really want for your server into one of these virtual machines.

It has many advantages, but I’ve brought it up now because many hypervisors have the option to create snapshots. This is a complete picture of the installation, so if you need to restore your system, it’s just a case of loading the most recent snapshot and you’re back up and running.

However a big disadvantage of this system is performance, especially on older computers with limited resources, which is why I haven’t done it in this tutorial. Virtualisation is a huge topic, so if it sounds interesting, then go read up on it.

There are also utilites that can clone your entire hard drive, so restoring your system should be a case of of putting that cloned hard drive into new server and starting it up. This approach has it’s disadvantages too – the backup will be as big as your hard drive, so your backup location needs a lot of storage space. It also works best if the system is off while the cloning occurs, so you’ll need to plan some regular downtime to use this backup strategy.

Specific Items

An advantage of backing up specific items is knowledge – you know what you’ve got. The tools for managing those pieces are often more common and more widely compatible than those for managing whole system backups.

Our strategy has two steps:

• Create and populate a staging directory to hold all of the data we want to back up.
• Actually do the backup to get the data off the server to somewhere else. (Backups stored on the same computer, especially on the same HDD, are a waste of time)

Create the backup staging area:

sudo mkdir /var/backup_staging
sudo chmod -R go-rwx /var/backup_staging
sudo mkdir /var/backup_staging/scripts

We’ll write a Shell script. You might not realise it, but the shell is the program you’re interracting with when you are entering commands. This means our script can use the same commands.

sudoedit /var/backup_staging/scripts/backup.sh

Enter the following as the first lists of this file:

#!/bin/sh
# Backup scripts

Like a lot of files we’ve worked on, the # at the beginning of a line means a comment, so wouldn’t normally matter. However, in this case, the first line is important to tell the system how to run this file. The second line is a real comment – a title for our script.

General

You probably what to back up these areas:

• We’ve done a lot of work configuring Apache – we should definitely save those modifed configuration files: /etc/apache2
• Getting new SSL certificates isn’t too hard, but it doesn’t hurt to have them if speed things along : /etc/letsencrypt
• If you’re doing other things with this server you might have saved files your home directory: /home/[your username].

Create backup directories for these:

sudo mkdir --parents /var/backup_staging/etc/apache2
sudo mkdir /var/backup_staging/etc/letsencrypt
sudo mkdir --parents /var/backup_staging/home/[your username]

The idea is we’ll mirror the structure of the filesystem, which means you won’t get any clashes if you add to this in future. Add these lines our script /var/backup_staging/scripts/backup.sh

rsync -Aax --delete /etc/apache2/ /var/backup_staging/etc/apache2/
rsync -Aax --delete /etc/letsencrypt/ /var/backup_staging/etc/letsencrypt
rsync -Aax --delete /home/[your username]/ /var/backup_staging/home/[your username]/

Each of these lines runs the rsync program, which basically copies one folder into another. The options we’ve selected mean that the backup should be an exact mirror of the original, but it’ll only move or update the files that have changed. rsync can do a lot more than this, including transferring files to another computer, but you can research that on your own.

WordPress

There are two main pieces to the backup, files and the database.

Files

• WordPress uploads folder. Any images you upload to your site are saved in here, and that’s the only copy. Find it at /var/www/wordpress/wp-content/uploads.
• At the time of writing the entire size of my wordpress folder is only 114 megabytes, including the uploads folder mentioned above. You might as well back up the whole thing. /var/www/wordpress.
• We moved the wordpress configuration into a file outsite the web root, so make sure that’s backed up: /var/www_config.

Create directories for these:

sudo mkdir --parents /var/backup_staging/www/wordpres
sudo mkdir /var/backup_staging/www_config

Add add these lines to the script to copy them into the backup staging location.

rsync -Aax --delete /var/www/wordpress /var/backup_staging/var/www/wordpress
rsync -Aax --delete /var/www_config/ /var/backup_staging/var/www_config/

Database

The database is a critical component of both WordPress and Nextcloud, so we need to back this up, but it takes a little planning.

We’re going to use mysqldump, which logs into your database server, and saves the whole database (or even multiple databases) in a sql file. The idea is you can just execute this sql file on a database server and the database will be recreated.

The command history is considered insecure, so we don’t want to put our database password in on the command line. The database credentials go in a separate file:

sudoedit /var/backup_staging/scripts/wordpress.cnf

Add this to wordpress.cnf, filling in your database username and password, (with single quote round it in case of special characters)

[mysqldump]
user=wp_usr
password='wordpress_database_password'

And now add this line to your backup script:

mysqldump --defaults-file=/var/backup_temp/scripts/wordpress.cnf --skip-dump-date --add-drop-table sswp > /var/backup_temp/sswp-current.sql

Explanation:

• mysqldump is the utility that spits out a sql that’s a backup of a database.
  • --defaults-file tells mysqldump to read the username and password the file we specified
  • --skip-dump-date means the sql won’t include the date the dump was done, so if the database hasn’t changed between dumps, the sql file will be identical
  • –add-drop-table means the recovery can be more reliable, if riskier for the data you have on the system you’re installing the recovered data on.
  • > means the data is written the file specified.

Nextcloud

Nextcloud also has files and data that we want to back up. There’s a greater chance of inconsistencies between the files and database, and it’s down to you how much care you take over this.

Maintenance Mode

Like we did for WordPress, create a file containing the Nextcloud database login details. I’d call it /var/backup_staging/scripts/nextcloud.cnf. Use the same format, just with the Nextcloud database details instead of the WordPress ones.

First, we’ll put Nextcloud into maintenance mode, add this line to your script:

sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --on

This runs the occ script, which performs various utility tasks on a Nextcloud installation.

Database

Now we can safely dump the database contents. Add this line to the backup script:.

mysqldump --defaults-file=/var/backup_staging/scripts/nextcloud.cnf --single-transaction --skip-dump-date --add-drop-table nextcloud > /var/backup_staging/nextcloud.sql

Files

We have a choice here:

1. Minimum Downtime. Copy the enitire Nextcloud Data folder into the staging folder, then turn off maintenance mode. The downside of this you need twice as much storage space.
2. Minimum Storage: Back up the Nextcloud data folder in place, then turn off maintenance mode. Your site will be down for as long as it takes the backup to complete.

Pick an option, and add the relevant lines to the end of your backup script

Option 1:

rsync -Aax --delete /var/www/wordpress /var/backup_staging/var/www/wordpress
rsync -Aax --delete /var/nc_data/ /var/backup_staging/var/nc_data/
sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --off
# # # # # # # # # # # # # # # # # #
# Placeholder for backup commands
# Back up /var/backup_staging only
# # # # # # # # # # # # # # # # # #

Option 2:

rsync -Aax --delete /var/www/wordpress /var/backup_staging/var/www/wordpress
# # # # # #
# Placeholder for backup commands
# Back up /var/backup_staging and /var/nc_data
# # # # # #
sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --off

Where to back up

All we’ve done so far is to stage all the useful data from our websites in a single folder.

We need to get it off your server to different location, preferably serveral locations. A common rule about backups is the 3-2-1 rule:

• 3 copies of your data
• 2 of those copies on different of media
• 1 copy is offsite.

The “2 different media” rule protects against hard drive failure, and the offsite rule can protect against a whole host of ways to lose your data: physical theft, fire, lightning damage and more.

So how can you do this?

• A few portable HDDs can be a simple option – you’ll need to remember to plug them in, you may need to configure your backup script to mount it. Keep one at your mum’s house and swap it out every week or so.
• Another server. If you (or a friend) have another server with plenty of space, you could back up to that. rsync doesn’t just copy folders on one computer – it’s really meant for transfering files to a remote computer over SSH. A sample command might look like this:

rsync -az /var/backup_staging/ username@remoteserver:/var/remote_backups

• For either of these options, consider using software that encrypts the data. Duplicity works a bit like rsync, but allows for encryption and incremental backups.
• Use a backup service. These companies usually have their own software and servers. Look for encryption and trustworthiness (I would never use a free service for something like backup). It’s also essential that they offer a Linux client with a command line interface so we can add it to our script. I use SpiderOak – there are plenty other others out there, do your research!

Once you’ve picked your method, replace the placeholder in our backup script with whatever commands you need to make that run.

Run it regularly

Our backup script is great and all, but unless you run it regularly, it’s pretty pointless. We’ll use cron to run this script every night (or whenever you want).

Edit the system crontab:

sudo crontab -e

Add this line to the bottom, then save and exit the file.

  5 2   *   *   *  /bin/sh /var/backup_staging/scripts/backup.sh

The lines at the top of the crontab script tell you how to use it. The 5 and 2 means the command will run at 5 minutes past 2am (02:05 24 hour clock), and the stars means it won’t consider the other options (day of week, day or month or month) are ignored. /bin/sh is the program that will run our script.

Test!

This is critical – after you’ve done your first backup, take a good look at:

• Is everything you expected there?
• Nothing is corrupted

IT professionals regularly do “recovery drills”. i.e. practice what they’d do to get IT systems up and running after a distaster, which helps find problems with the backups. Have a go at using your backups to rebuild you site, maybe in a VM on your client computer.

Good luck!

One recommendation that many security experts make is that the WordPress configuration files should be outside the web root. Lets make this change.

WordPress

Create a new folder called /var/www_config. Put a new folder in here, wordpress

cd /var
sudo mkdir www_config
cd www_config
sudo mkdir wordpress

Copy the WordPress configuration file across, and set it’s permissions so no-one apart from www-data (and root, of course) can read it:

sudo cp -a /var/www/wordpress/wp-config.php /var/www_config/wordpress/
sudo chown -R www-data:www-data /var/www_config
sudo chmod -R u=rX,go= /var/www_config

Now we need to tell Apache that the when PHP scripts on the wordpress site run, they can only access the folders we want them to:

• /var/www/wordpress : our wordpress installation
• /var/www_config/wordpress : our wordpress config
• /tmp : WordPress needs this for handling plugin upgrades etc.

Modify the wordpress Apache site configuration file and add this line inside the VirtualHost section:

php_admin_value open_basedir "/var/www/wordpress/:/var/www_config/wordpress/:/tmp/"

Now reload Apache.

Finally, WordPress still needs to be able to find this file, so replace the contents of the original wp_config.php with this:

<?php

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Location of your WordPress configuration. */
require_once('/var/www_config/wordpress/wp-config.php');

It’ll take effect the moment you save it, so now visit your site from the client, and hopefully nothing has broken!

Nextcloud

For some reason this isn’t as widely recommended by Nextcloud users. I’ll investigate and update this post with my suggestion.

For now, just make sure only www-data can read and write the config file:

sudo chown -R www-data:www-data /var/www/nextcloud/config/
sudo chmod -R u=rX,go= /var/www/nextcloud/config/

The final of the 3 big pieces – this provides document editing capability in Nextcloud.

Install Collabora

There are a couple of ways to install Collabora, and the recommended way is to use a Docker image. That isn’t ideal for us because the Docker version will use more resources which we can’t afford if you’re running this on something old. Instead, Collabora provide respositories, so these commands will:

1. Install a little tool me we need
2. Get the security keys so the repository is safe to use
3. Add the repository to our /etc/apt/sources.list.
4. Install Collabora

sudo apt install gnupg
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 0C54D189F4BA284D
sudo echo 'deb https://www.collaboraoffice.com/repos/CollaboraOnline/CODE-debian10 ./' | sudo tee -a /etc/apt/sources.list
sudo apt update && sudo apt install loolwsd code-brand

Configure Collabora

Modify /etc/loolwsd/loolwsd.xml

sudoedit /etc/loolwsd/loolwsd.xml

We’ll disable SSL in collabora itself, because Apache will handle that. Find <ssl desc="SSL settings">. Look at the line below. Change the second-to last word to false. It should now be this:

<enable type="bool" desc="Controls whether SSL encryption between browser and loolwsd is enabled (do not disable for production deployment). If default is false, must first be compiled with SSL support to enable." default="true">false</enable>

In the line below that, the second-to last word should be true.

<termination desc="Connection via proxy where loolwsd acts as working via https, but actually uses http." type="bool" default="true">true</termination>

Now find <wopi desc="Allow/de..... Add a line below it, swapping in your Nextcloud domain name, with the dots "." escaped with backslashes "\.".

<host desc="Regex pattern of hostname to allow or deny." allow="true">nextcloud\.example\.org</host>

Save and close the file, then restart Collabora

sudo systemctl restart loolwsd

Test

There isn’t a whole lot of testing we can do on Collabora as an intermediate step, but this will at least confirm the server is running. This command asks Collabora for a file saying what it’s capable of:

cd ~
wget http://localhost:9980/hosting/capabilities

If it seems to run OK, you should now have a file called capabilites in your home (~) directory. Lets look at what’s inside:

cat ~/capabilities

{"convert-to":{"available":true},"hasMobileSupport":true,"hasTemplateSaveAs":false,"hasTemplateSource":true,"productName":"Collabora Online Development Edition"}

Looking good!

Configure Apache

In this situation, all Apache has to do is act as a proxy between Collabora and the internet – we can’t connect it directly because otherwise the other sites (WordPress and Nextcloud) wouldn’t work.

Enable these 3 modules:

sudo a2enmod proxy proxy_http proxy_wstunnel

Edit the main Collabora SSL Apache configuration file:

sudoedit /etc/apache2/sites-available/collabora-le-ssl.conf

Change it to this:

<VirtualHost *:443>
    ServerName collabora.example.org
    ErrorLog ${APACHE_LOG_DIR}/collabora_error.log
    CustomLog ${APACHE_LOG_DIR}/collabora_access.log combined

    SSLCertificateFile /etc/letsencrypt/live/collabora.example.org/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/collabora.example.org/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
	# Encoded slashes need to be allowed
	AllowEncodedSlashes NoDecode

	# Container uses a unique non-signed certificate
	SSLProxyEngine On
	SSLProxyVerify None
	SSLProxyCheckPeerCN Off
	SSLProxyCheckPeerName Off

	# keep the host
	ProxyPreserveHost On

	# static html, js, images, etc. served from loolwsd
	# loleaflet is the client part of Collabora Online
	ProxyPass           /loleaflet http://127.0.0.1:9980/loleaflet retry=0
	ProxyPassReverse    /loleaflet http://127.0.0.1:9980/loleaflet

	# WOPI discovery URL
	ProxyPass           /hosting/discovery http://127.0.0.1:9980/hosting/discovery retry=0
	ProxyPassReverse    /hosting/discovery http://127.0.0.1:9980/hosting/discovery

	# Capabilities
	ProxyPass           /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities retry=0
	ProxyPassReverse    /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities

</VirtualHost>

Basically, the bits we’ve added are a two-way connector between Apache and Collabora, and it needs slightly different things for all of the different features.

Reload Apache.

Configure Nextcloud

1. Log into Nextcloud with your admin account.
2. Click on the circle with your initial in the top right corner, choose Apps.
3. Click on Office & text from the menu on the left.
4. Find Collabora Online and click Download and enable
   

5. Click on the circle with your initial in the top right corner, choose Settings.
6. Click on Collabora Online near the bottom of the menu on the left.
7. Choose Use your own server
8. Enter your Collabora domain name with the https:// and then hit save.

Now go back to the files section and give it a try!

• You should have the option to create a New Document, New Spreadsheet or New Presentation from the “+” icon.

• Or if you have any files on Open Document (.odt, .ods, .odp) or Open Office XML (.docx, .xlsx, .pptx) formats you can try opening them. They should open for editing in Collabora:

Before enabling public access to Nextcloud, lets take a moment to improve things a little.

Apache Config

First up, let’s force the use of the HTTPS and make sure we haven’t left any security holes by stripping back the HTTP config file to it’s bare bones.

sudoedit /etc/apache2/sites-available/nextcloud.conf

<VirtualHost *:80>
	ServerName nextcloud.example.org
	Redirect permanent / https://nextcloud.example.org/
</VirtualHost>

The default Apache configuration gives access to a little too much – we can lock that down, and just open up the bits we want later with the site-specific configuration files.

sudoedit /etc/apache2/apache2.conf

Look for this section and put a # at the beginning of every line so they’re ignored.

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

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

Now we have to give access back just where want it:

sudoedit /etc/apache2/sites-available/nextcloud-le-ssl.conf

Before the ErrorLog line, add this:

<Directory /var/www/nextcloud>
    Require all granted
</Directory>

Then do the same for the WordPress config:

sudoedit /etc/apache2/sites-available/wordpress-le-ssl.conf	

Before the ErrorLog line, add this:

<Directory /var/www/wordpress>
    Require all granted
</Directory>

Restart Apache (you should know how to do that by now – look back through the previous posts until you find it.)

Nextcloud Administration Warnings

Log into your nextcloud administrator account, click on the circle with your initial in the top right corner, choose setttings. On the page that pops up, pick Overview from the menu on the right.

The system will think for a moment, then show a list of warnings:

If your list is the same as mine, I’ll show you how to fix the first 2, but you can work through the others on your own if you like.

PHP Memory Limit

“The PHP memory limit is below the recommended value of 512MB.”

It isn’t essential to fix this, and if you’re running nextcloud on an old, lower powered machine I wouldn’t recommend it, because that’s the limit per script, and a script fires up every time someone access your site, so with a few users doing heavy things, you’ll have a problem.

If you do want to do it, edit the PHP configuration file:

sudoedit /etc/php/7.3/apache2/php.ini

Find this line and change the number to what you want:

memory_limit = 512M

Then restart Apache

Enable HSTS

“The “Strict-Transport-Security” HTTP header is not set to at least “15552000” seconds. For enhanced security, it is recommended to enable HSTS as described in the security tips .”

You can follow that link in the tip to find out the details of how we fix this, but these are the steps:

Enable the Apache headers module:

sudo a2enmod headers

Modify the Nextcloud apache configuration:

sudoedit /etc/apache2/sites-available/nextcloud-le-ssl.conf

Add this after the ServerName line:

Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"

And reload Apache

Re-enable public access

Now we’ve dealt with a few potential security issues, you can enable access to Nextcloud from outside you network.

sudoedit /etc/apache2/sites-available/nextcloud-le-ssl.conf

Either delete, or comment out these 3 lines. You can make a line into a comment by putting a # at the beginning of the line. That means it will be ignored.

<Location />
    Require ip xxx.xxx.xxx.0/24
</Location>

Reload apache and you’re done!

Database

Again, same as for WordPress, we need a database and a user. Same command to login as the root database server user:

sudo mysql -u root -p

a similar set of SQL commands to set up the nextcloud database:

CREATE USER 'nc_usr'@'localhost' IDENTIFIED BY 'password';
CREATE DATABASE IF NOT EXISTS nc_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL PRIVILEGES on nc_db.* to 'nc_usr'@'localhost';
FLUSH privileges;
EXIT;

Disable Public Access – a different way

Like before, we don’t want the Nextclound site to be public until we’ve completed the installation & configuration. On the other hand, we don’t want to do the same as before (cutting our server off from the internet by turning off port forwarding on the router) because we have an active WordPress installation that people might be using.

To do this we’ll tell Apache to only respond to requests (for the Nextcloud site) from your internal network, not from the public internet:

sudoedit /etc/apache2/sites-available/nextcloud.conf

Add this section, just before the ErrorLog line, replacing the xxx.xxx.xxx with the first 3 blocks of your IP address on your network.

<Location />
    Require ip xxx.xxx.xxx.0/24
</Location>

Reload apache:

sudo systemctl reload apache

Download the installer script

Navigate to the nextcloud folder

cd /var/www/nextcloud

Download the installer script, and pass ownership of it and the entire nextcloud folder to www-data (which is apache, remember).

sudo wget https://download.nextcloud.com/server/installer/setup-nextcloud.php
sudo chown -R www-data:www-data /var/www/nextcloud

We should also create a data folder outside the /var/www folder, which improves security:

sudo mkdir /var/nc_data
sudo chown -R www-data:www-data /var/nc_data

Run Installation Script

On the client machine, open a browser and go to nextcloud.example.org/setup-nextcloud.php

You should see the Setup Wizard, most it should be easy to understand, click your way through:

Put a “.” in the box like it says because the Nextcloud installer is already in the correct place

• Enter the details for the database and database user you created above.
• Make an admin account with a strong password.
• Change the data folder to the one we just created: /var/nc_data,
• I’d recommend unticking the Install recommended apps box. You can add them later if you like.

Once this is done you should be able to log in and start using it!

First, we need 1 extra PHP module:

sudo apt install php-gd

Like with WordPress, we’ll create a folder and apache configuration for Nextcloud:

cd /var/www
sudo mkdir nextcloud
sudoedit /etc/apache2/sites-available/nextcloud.conf

And we’ll use essentially the same apache configuration we used for wordpress, with a few tweaks.

<VirtualHost *:80>
    ServerName nextcloud.example.org
    DocumentRoot /var/www/nextcloud
    
    <Directory /var/www/nextcloud/>
        Require all granted
        AllowOverride All
        Options FollowSymLinks MultiViews

        <IfModule mod_dav.c>
            Dav off
        </IfModule>
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/nextcloud_error.log
    CustomLog ${APACHE_LOG_DIR}/nextcloud_access.log combined
</VirtualHost>

We’ll also create a temporary configuration for collabora while we’re here:

sudoedit /etc/apache2/sites-available/collabora.conf

<VirtualHost *:80>
    ServerName collabora.example.org
    ErrorLog ${APACHE_LOG_DIR}/collabora_error.log
    CustomLog ${APACHE_LOG_DIR}/collabora_access.log combined
</VirtualHost>

This is just a barebones template that’s just enough to let us set up HTTPS later.

Enable the sites and reload apache:

sudo a2ensite nextcloud collabora
sudo systemctl reload apache2

DNS

We need to create DNS Entries for Nextcloud and Collabora:

1. Log into the control panel for your domain.
2. Create a CNAME record
   • Domain: e.g. nextcloud.example.org
   • Data: e.g. example.org if you had a fixed IP, or the dynamic DNS server address you created e.g. anotherexample.ddns.net
3. Do the exact same for collabora.example.org

HTTPS

Use certbot again to enable https on both nextcloud.example.org and collabora.example.org

sudo certbot --apache

When it asks you which sites you want to activate HTTPS for, you can select multiple options by putting a comma separated list. You can also choose to allow certbot to automatically reconfigure apache to Redirect (option 2 when it asks you).

WordPress is a very flexible platform, but there are a few key pieces that are essential for it to run:

• A websever
  • We installed Apache in an earlier post so that’s covered, though we will need some extra modules.
• PHP
  • This is the programming language WordPress is built in and runs on, so our server needs to have it installed.
• A Database
  • We’ll install MariaDB, which is powerful & popular solution.

The full details are on the WordPress website, and we’ll refer back to this for the specifics in a bit: https://make.wordpress.org/hosting/handbook/handbook/server-environment/

First, lets install PHP

sudo apt install php

It’s worth paying some attention to what apt is actually doing at his point:

sandy@waldorf:/var/www/test$ sudo apt install php
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libapache2-mod-php7.3 libsodium23 php-common php7.3 php7.3-cli php7.3-common php7.3-json
  php7.3-opcache php7.3-readline psmisc
Suggested packages:
  php-pear
The following NEW packages will be installed:
  libapache2-mod-php7.3 libsodium23 php php-common php7.3 php7.3-cli php7.3-common php7.3-json
  php7.3-opcache php7.3-readline psmisc
0 upgraded, 11 newly installed, 0 to remove and 0 not upgraded.
Need to get 4,377 kB of archives.
After this operation, 17.7 MB of additional disk space will be used.
Do you want to continue? [Y/n]

In the list of packages that will be installed, php7.3 has been selected. This is the current stable version of PHP, and is the default in Debian 10. Also, libapache2-mod-php7.3 will be installed – this is the Apache module that lets it run php code when to create the web pages you see.

We can test this with the phpinfo(); function, which does a similar thing to the http://test.example.org/server-info page we created in the previous post.

Create a file called phpinfo.php in the folder for the test website:

sudoedit /var/www/test/phpinfo.php

Type in this line:

<?php phpinfo(); ?>

Now visit http://test.example.org/phpinfo.php. You should get a long page full of information that looks like this:

All of the headings on this page after HTTP Headers Information and before Additional Modules are the modules that PHP has loaded and can be used by php webpages on your server.

If we compare that list of modules, to the list of extensions required by WordPress, we might find some gaps. This is the list from my server:

So the missing ones are:

• curl
• dom
• imagick
• mbstring
• mysqli
• xml
• zip

So we’ll install them. The package names take the form of php- or php7.3- and then the module name. The dom module is provided within the php-xml package. mysqli is in php-mysql.

sudo apt install php-curl php-imagick php7.3-mbstring php-mysql php-xml php-zip

For some reason, some of these need to be enabled manually, the others just work.

sudo phpenmod -s apache2 curl mbstring mysqli

Restart the webserver:

sudo systemctl restart apache2

Database

The Database holds all of the live content in your wordpress blog, like the posts and comments. It also has all of the user information.

We’ll install mariadb

sudo apt install mariadb-server

Now we’ll use a ready-made script to set basic security options. You’ll need to create a strong password for root user for the database server (not the same as the root user of the system).

sudo mysql_secure_installation

Say yes to all of the options, entering the database server root password when prompted.

Now create the actual worpress database in the database server. Start by logging into the database with the mysql command line client, and enter the password when prompted.

sudo mysql -u root -p

sandy@waldorf:/etc/php/7.3/apache2$ sudo mysql -u root -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 57
Server version: 10.3.22-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

You’re now logged into a special command line that’s just for working on the database server. This command creates the database – the name could be anything – just remember it for later. I’ve called mine wp_db.

CREATE DATABASE wp_db;

Then next command creates the user that WordPress will use to access this database. It also sets their password and gives them access to the database. Fill in your own values for wp_db, wp_usr and password.

GRANT ALL PRIVILEGES ON wp_db.* TO "wp_usr"@"localhost" IDENTIFIED BY "password";

Now force the database to reload that user information and exit:

FLUSH PRIVILEGES;
EXIT

This is what the whole interraction looks like on my system:

sandy@waldorf:/etc/php/7.3/apache2$ sudo mysql -u root -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 57
Server version: 10.3.22-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

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

MariaDB [(none)]> GRANT ALL PRIVILEGES ON wp_db.* TO "wp_usr"@"localhost" IDENTIFIED BY "password";
Query OK, 0 rows affected (0.001 sec)

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.001 sec)

MariaDB [(none)]> EXIT
Bye