Most people encounter this first with transistors. eg. a typical BJT has the following pin assignments:

1. Emitter
2. Base
3. Collector

However, our simulation models have nodes, and each node will correspond to a pin on the schematic and PCB, so we need to make sure that each pin is connected to the right node.

From the datasheet you’ll be able to get the pin assignments – e.g. pin 2 is the Base. Where do you find the ngspice node assignments? It depends on the type of spice model you’re using.

• Built-in .MODEL. These are used for standard components, so the behaviour of the component can be defined with just a few parameters – e.g. for a basic simulation all you need to know about a resistor is the resistance. There are 17 types of model.
• Custom .SUBCKT (Sub-circuit). These can be used for components that don’t fit into the standard categories, or for a complete add-on board.

Which one is it? In KiCad, look at the spice model editor:

.MODEL

To get the information you need, you’ll need to look at the ngspice manual.

This includes the list of 17 standard models (reproduced here):

Go back to KiCad Spice Model Editor

So, now look at the section of the ngspice manual for BJTs:

This tells us that ngspice expects the nodes to be listed in the order collector, base, emitter.

We’ll use this later.

.SUBCKT

Sub-circuits can be easy to figure out, or they can be hard, depending on whether the creator of the model has made sensible choices about the node names.

Look at the KiCad Spice Model Editor – this example is from a manufacturer spice model of an N-channel MOSFET, that has chosen to use .SUBCKT instead of .MODEL:

Alternate Node Sequence

Now we’re ready to fill in the Alternate Node Sequence box in KiCad:

In this you write a list of the pin numbers, separated by spaces, in the correct node sequence.

e.g. for our BJT example we know that the correct node sequence is

collector, base, emmitter

Recall our pin assigments:

1. Emitter
2. Base
3. Collector

So I’ll rewrite the node sequence with the pin number in brackets:

collector (3), base(2), emmitter(1)

Now all we need are the pin numbers, so strip out everything else:

3 2 1

And put that in the Alternate Node Sequence box:

So I’m on the hunt for an offsite backup solution for this server.

This is Linux, so nothing is simple – the solution is divided into two pieces:

• Remote data storage service – to actually hold the data.
• Backup software – to figure out what needs to be uploaded, and keep track of versions and suchlike.

For the remote side I’ve got three real options:

• rsync.net – starts at $10/mo for 400 GB
• Backblaze B2 – starts at $5/mo for 1TB
• Wasabi – starts at $5.99/mo for 1TB

However, although rsync.net looks pretty simple – the price isn’t competitive. Backblaze B2 and Wasabi are similar – the benefit of Wasabi is that the’s no extra charges for downloads – B2 has a 1GB daily download threshold, and you start getting charged if you go over that.

For the backup software. These are the options I’m looking at. Please note that tools like rsync and rclone aren’t backup tools – they’re just for syncing, so don’t manage the versions or encryption

• duplicity
• borg
• restic
• duplicacy
• Duplicati

Duplicacy

I’m going to rule this one out right away it’s not free – I’m only mentioning it because it’s often included in conversations about Linux backup software.

Duplicity

Duplicity has been described as an old-school approach by this Backblaze blog post. That means it’s the model whereby you create a backup of everything – a full backup, then the next time you back up you only back up what’s changed – that’s an incremental backup. This can be space-efficient and fast and easy to understand, but the downside is to do a restore you need the last full backup, and all the incremental backups since then. This then creates headaches about deciding when to create a new full backup and how often to get rid of the old ones. Having said that it’s a respected and reliable tool which supports everything it needs to: Encryption, Compression, Backblaze B2 storage is supported, Wasabi is not.

Restic

The same article describes Restic as the new-school tool – which supports deduplication to save space. There isn’t a version 1.0.0 yet, but it seems to be fairly popular already, and supports B2 storage & Wasabi.

Borg

Borg is also a deduplicating backup software – seems to be a bit less fashionable that restic, a bit more mature. As far as I can tell the key advantage that Borg offers is compression, but can be slower with large respositories and large files because it’s single-threaded. However it doesn’t natively support remote object storage, so needs another tool to upload the data. See this forum post. It has some nice features, like the ability to mount a backup as a FUSE filesystem so you can browse it.

Duplicati

Not sure which type of tool this is. It does support B2 storage, but not Wasabi. Some people have had issues with reliability with it.

Final Thoughts

I’ve gone with restic and Backblaze B2. They can talk to each other directly, but I like the idea of having a local copy of the repo, so I’ve set restic to backup to a portable HDD, the which then is copied to Backblaze. This means I have the offsite copy in case my house burns down but can still get at the data in more mundane scenarios.

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.

Basic process:

1. Enable hardware assisted virtualization.
2. Set up WSL (Windows Subsystem for Linux)
3. Install Linux into WSL
4. Download and compile Sage
5. Configure JupyterLab
6. Make it easy to start from windows

Enable hardware assisted virtualization

WSL requires that your system supports hardware assisted virtualization (which pretty much all modern systems do), there are 3 things that you need to get it working:

• The CPU must support it
• The motherboard must support it.
• You need to enable it in the EFI (or BIOS)

This article takes you through getting everything sorted out:

https://support.bluestacks.com/hc/en-us/articles/115003174386-How-to-enable-Virtualization-VT-on-Windows-10-for-BlueStacks-4

Set up WSL 2

Follow this guide: https://docs.microsoft.com/en-us/windows/wsl/install-win10

Install and configure Linux:

1. Go to the Microsoft store and install Ubuntu.

Note: If you already have Ubuntu installed, I’d recommend you follow these instructions to set up a separate, clean install for sage: https://hfakhraei.github.io/Install-multiple-instance-of-same-Linux-Distribution-on-WSL

2. Start Ubuntu from the start menu. A command window should pop up.
3. Run these commands to update Ubuntu:

    sudo apt update
    sudo apt upgrade

4. Reboot by going (in Windows) to Services and restarting the LxssManager. You can also shut down all running WSL instances using the command wsl --shutdown in the Windows command prompt or Powershell.
5. If necessary upgrade to the latest release: https://linuxconfig.org/how-to-upgrade-ubuntu-to-20-10

Set up Sage

These instructions are a simplified version of the official documentation: https://doc.sagemath.org/html/en/installation/source.html

1. Start Ubuntu – All the commands in this section should be run on the Ubuntu installation.
2. Install the packages we need to have ready in advance:

sudo apt install bc binutils bzip2 ca-certificates cliquer cmake coinor-cbc coinor-libcbc-dev curl default-jdk dvipng eclib-tools fflas-ffpack ffmpeg flintqs g++ gcc gfan gfortran git glpk-utils gmp-ecm imagemagick latexmk lcalc libatomic-ops-dev libavdevice-dev libboost-dev libbraiding-dev libbrial-dev libbrial-groebner-dev libbz2-dev libcdd-dev libcdd-tools libcliquer-dev libcurl4-openssl-dev libec-dev libecm-dev libffi-dev libfile-slurp-perl libflint-arb-dev libflint-dev libfreetype6-dev libgc-dev libgd-dev libgf2x-dev libgiac-dev libgivaro-dev libglpk-dev libgmp-dev libgsl-dev libiml-dev libisl-dev libjson-perl liblfunction-dev liblrcalc-dev liblzma-dev libm4rie-dev libmongodb-perl libmpc-dev libmpfi-dev libmpfr-dev libnauty-dev libncurses5-dev libntl-dev libopenblas-dev libpari-dev libpcre3-dev libperl-dev libplanarity-dev libppl-dev libpython3-dev libreadline-dev librw-dev libsqlite3-dev libssl-dev libsuitesparse-dev libsvg-perl libsymmetrica2-dev libterm-readkey-perl libterm-readline-gnu-perl libxml2-dev libxml-libxslt-perl libxml-writer-perl libz-dev libzmq3-dev libzn-poly-dev m4 make nauty ninja-build openssl palp pandoc pari-doc pari-elldata pari-galdata pari-galpol pari-gp2c pari-seadata patch perl pkg-config planarity ppl-dev python3 python3-distutils r-base-dev r-cran-lattice sqlite3 sympow tachyon tar texlive texlive-xetex xcas xz-utils yasm

3. Download and extract the source tarball into a subfolder of your home directory

cd ~
wget http://www.mirrorservice.org/sites/www.sagemath.org/src/sage-9.2.tar.gz
tar xvf sage-9.2.tar.gz

4. Start building

cd sage-9.2/
./configure
make

This will take a long time (3 hours on my system)

5. Test sage

./sage

You should get a prompt that looks like this:

┌────────────────────────────────────────────────────────────────────┐
│ SageMath version 9.2, Release Date: 2020-10-24                     │
│ Using Python 3.8.6. Type "help()" for help.                        │
└────────────────────────────────────────────────────────────────────┘
sage:

6. Type exit and press enter to leave.

7. Make the command available from anywhere on this ubuntu system – edit ~/.bashrc and add this line:

alias sage=~/sage-9.2/sage

8. Close ubuntu then reopen it.
9. Try typing sage and verify that it starts.

JupyterLab

1. Install Jupyter Lab and it’s extras:

sage -i jupyterlab_widgets

This also involves compliation from source, so will take a while.

2. When it’s done, try starting the jupyterlab notebook like this:

sage --notebook jupyterlab

You might notice a problem – the list of files only includes those on your linux machine – you probably want the ones on your windows computer. You can do this by navigating to where the windows files are mounted in linux.

3. Try it (fill in your windows username instead of the square brackets):

cd /mnt/c/Documents\ and\ Settings\[your windows username]
sage --notebook jupyterlab

The list of files should now be the ones in that folder on your windows machine.

4. Lets wrap this all in a script for convenience – Create a file called ~/sage_nb.sh and put these lines into it:

#!/bin/bash
cd /mnt/c/Documents\ and\ Settings/[your windows username]
/home/[your linux username]/sage-9.2/sage --notebook jupyterlab

5. We need to make it executable – ie. so linux will run this file like it would run a program:

chmod ug+x sage_nb.sh

6. Now go back to your home directory and try it again:

cd ~
./sage_nb.sh

The JupyterLab server should start, showing your windows files in the browser.

Create windows shortcut

This is a final nicety that lets you start the JupyterLab server in one click:

1. Open Windows explorer, and type %APPDATA%\Microsoft\Windows\Start Menu\Programs
2. Make a copy of any of the program icons – we’ll customise it to do what we want
3. Right-click, and choose properties.
4. On the General tab:
   • Change the name to whatever you want.
5. On the Shortcut tab:
   • Change Target to: ubuntu.exe run ~/sage_nb.sh
   • Change Start in to: %USERPROFILE%
   • Change Run to: Minimised
   • Change the icon if you want – there are plenty of pieces of software that can create a .ico icon file one from an image file.
6. Now hit the start button or key and type the name you gave it. it should appear in the list, and should load the server and fire up your browser when you click on it.

Software versions:

This is what I used when I wrote this post – you might get different results if your versions are significantly different.

• Windows 10 Pro Version 2004 (OS Build 19041.264)
• Ubuntu 20.10 (Originally installed 20.04 as 20.10 was not available in the Windows Store)
• Sage 9.2

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!