I made it because I can never find a serviceable USB stick or the right assortment of .iso files when I want to do an OS install. But I'd rather not have to completely replace my DHCP server (e.g. my home router) just to netboot one system.

It's built on netboot.xyz which provides a bootable environment with a huge assortment of Linux live CDs, installers, utilities like memtest86 and GParted and even support for the Windows installer (if you bring your own Windows ISO and mount it on your network).

Connecting the container is a little tricky: standard Docker networking creates a network for containers and then routes traffic between that and the host's network interface using iptables rules, allowing for example traffic to port 8443 on the host to be sent to port 443 on the container. That doesn't work very well with DHCP, which relies on the ability to make and receive broadcasts. All of the participants have to be on the same LAN segment, which means port forwarding isn't going to work. One easy solution is to use Docker's host network mode which makes the container behave as if it were a process on the host from a networking perspective; although that doesn't work if anything else wants to listen on the ports the container uses (which includes port 80 used by netboot.xyz). Another approach demonstrated using a docker-compose file in the repo uses the ipvlan network driver to effectively create a new network interface connected to the same network as the host, in the same IP range as if it were a separate device (akin to how VMs can be connected directly to the host network), which avoids theses issues.

I've used this to install various new systems at home, to boot into tools when I need to do partition maintenance or test some memory, and also when I want to build a new VM on my workstation (although note that if you're using Hyper-V Generation 2, Secure Boot has to be off for it to work)

The idea is to be able to have a subdomain for each of my servers (e.g. sofaserver.samn.co.uk) and to deploy various self-hosted HTTP services as Docker containers under subdomains (e.g. coolapp.sofaserver.samn.co.uk) which gets exposed with login and certificates automatically sorted out, just by applying labels to the containers when they're launched. Setting that up requires knitting together some bits of configuration, which is why I've built an Ansible role for it.

How it works

To make configuration based on Docker container labels work, Traefik has the concept of dynamic configuration. Various providers, such as the Docker Provider supply it with the details of what should be configured at runtime and Traefik listens for containers launching with traefik.* labels attached to expose them accordingly. However, granting anything direct access to Docker via the Docker socket is a security risk: anything with access to that socket is effectively root on the host. Instead, an instance of tecnativa/docker-socket-proxy is deployed which provides read-only access to details about Docker containers but rejects any other requests to reduce the attack surface.

The first part of exposing a service is automatically issuing a TLS certificate with LetsEncrypt for the relevant subdomain. LetsEncrypt has to check that you control the domain for which you've requested a certificate by using one of a series of challenges such as HTTP-01 and DNS-01. In the former LetsEncrypt provides a file to host at a specific location on your web server and verifies it can be accessed over unencrypted HTTP (proving you have control of the location the domain points to), and in the latter, it provides details of a specific DNS TXT record to create (proving you control the domain itself). Fortunately, Traefik takes care of both challenges, either intercepting and responding to requests for the challenge file over HTTP, or creating DNS records on your DNS provider using the go-acme/lego client. In my case, I tend to use DNS-01 to avoid having to expose the HTTP port and because some of my services only accept requests from inside my network, but it makes little difference.

The second major piece of automatic configuration is authentication and authorization, to restrict access to my services only to people who should be able to log in. Traefik has support for middleware to change how requests get processed, such as the ForwardAuth middleware which calls some other service and only permits requests when the other service responds that they are permitted. thomseddon/traefik-forward-auth is an example of one of those services, and it permits requests that pass an OAuth2 Authorization Code Grant. From a user perspective that looks like what happens when you push a "Sign in with Google" or "Log in with GitHub" button: you're sent to Google/GitHub/et al (the Identity Provider, or IdP), you log in, the Identity Provider sends you back with a code and Traefik uses that to get an Access Token and some details about you (your email address) which it forwards on to the service you're logging in to as the X-Forwarded-User header.

Let's think about what happens in our previous example of coolapp.sofaserver.samn.co.uk, and if Google was the IdP in use. When you browse to that site you'd be redirected to Google to log in, with a callback URL pointing to auth.sofaserver.samn.co.uk: the address of the Forward Auth middleware. After logging in successfully you are redirected to that callback URL with a code, and the middleware makes a request to Google behind the scenes for an access token and your email address. Finally, the middleware sets a cookie to keep you logged in and responds to Traefik that auth succeeded and the request should be allowed and the X-Forwarded-User header should be passed to the backing service.

Docker Compose Project

I mentioned at the beginning that the repository contained both an Ansible Role and a Docker Compose project. Ansible is ideal for automating complex infrastructure and maintaining a long-term deployment, but a lot of work for a one-off demo, which is why I built a Docker version. It starts up the same set of containers (Traefik, the auth middleware and the Docker socket proxy) as when deployed using Ansible, but also includes a container that generates all the config files. In principle, you can copy the docker-compose.yml file from the repository, set environment variables as needed (e.g. for access to your Identity Provider) and then run docker-compose run config-generator && docker-compose up reverse-proxy -d and have a working Traefik/LetsEncrypt/SSO setup.

The config-generator container runs a one-off ansible-playbook command to generate config files, using the same Ansible role, with a set of flags to disable starting the other containers.

Unit Testing & CI

The role has a set of automated tests and linting configured using Ansible Molecule to verify that it works as expected. Molecule provides a way to start a Docker container and orchestrate Ansible to connect to that container, apply the role, check that it's idempotent and run a verification process against the container afterward.

Verifying the reverse proxy role works is complicated, because the tests have to work in GitHub Actions without human interaction, but also exercise enough of the certificate issuance and auth processes to prove they work.

Testing certificates in a CI environment implies the DNS-01 challenge, because it's not practical (nor wise!) to expect your CI system to be accessible from the Internet. Instead I've delegated a subdomain to another provider (desec.io and GitHub Actions has a token to access the deSEC API. When the test runs, it generates a random string and prepends it to the delegated domain to produce the test domain (e.g. abcd1234.ci-dns.samn.co.uk), which is saved to a file and used to issue certificates (initially it just used the delegated domain directly, but that led to confusing test failures when they ran in parallel!)

For testing the ForwardAuth middleware I've used navikt/mock-oauth2-server. It behaves like an IdP that you're already logged in to, so then it's just a case of testing the various redirects to and from the IdP appear, and following them.

Further Reading

• The repository can be found at https://github.com/samdbmg/ansible-traefik-auth-proxy

• Or the role is on Ansible Galaxy at https://galaxy.ansible.com/samdbmg/traefik_auth_proxy

Why What and Where

Some things I self-host for practical reasons, like the much better transfer rates (and cheaper per GB storage cost) I get from my home WiFi to the server under my sofa compared to the cloud. Sometimes it's for principled reasons, like wanting to retain control over where my data lives and who has access to it. And sometimes it's just because I like doing it!

Amongst other things I'm running:

• Nextcloud for files and notes

• Home Assistant to monitor and control various sensors and smart devices (plus ESPHome to manage device firmware)

• TimescaleDB and Grafana for storage and more powerful analysis of those sensor data

• Convos IRC client for always-on IRC (I used to use The Lounge but Convos works better with SSO)

• Firefly III for tracking my finances

• Exim for outgoing email (incoming is handled by Cloudflare Email Routing so I don't have to worry about losing mail if my servers go down)

These are spread across a mixture of an old laptop running under my sofa with some storage attached (called sofaserver), and a Vultr VPS in London (called gate).

How it works

Most of the apps are deployed using Docker and orchestrated with docker-compose. Compose lets you write YAML files describing a set of one or more containers that make up an app, define some networks to connect those containers, and manage that app as a single unit. I've considered using a more "serious" orchestrator like Kubernetes in the past, but Compose is very easy to use, and Kubernetes is a lot of complexity for only two hosts in my spare time! Below is an example of a Compose file that will be rendered through Ansible templates.

---
version: "3"
services:
  grafana:
    image: grafana/grafana-oss:latest
    container_name: grafana
    volumes:
      - /opt/grafana/data/:/var/lib/grafana:rw
      - /opt/grafana/grafana.ini:/etc/grafana/grafana.ini:ro
    user: "{{ container_user.uid }}:{{ container_user.gid }}"
    labels:
      - traefik.enable=true
      - traefik.http.routers.grafana.rule=Host(`grafana.{{ services_domain }}`)
      - traefik.http.services.grafana.loadbalancer.server.port=3000
      - traefik.http.routers.grafana.entrypoints=websecure
      - traefik.http.routers.grafana.tls.certresolver=default
      - traefik.http.routers.grafana.middlewares=traefik-forward-auth
    restart: always
    networks:
      - traefik

networks:
  traefik:
    external: true

Notice the traefik... labels? They configure the Traefik proxy used to expose the container externally. Traefik reads the request (which is made to the standard HTTPS port 443 regardless of destination), presents the appropriate TLS certificate and routes the request to the backend. It also automatically issues and renews certificates using LetsEncrypt. I use the DNS-01 challenge via my Cloudflare DNS, which also means I can restrict some apps to only allow connections from my home network, while still using publicly trusted certificates.

A Traefik middleware, traefik-forward-auth handles authorisation to access my apps. It intercepts requests to perform a standard OIDC flow, only permitting those which log in successfully. The authentication service itself is not self-hosted; it would be possible to use something like Keycloak for this, but I've gone with a managed service instead to make securing the login process "somebody else's problem".

A previous iteration of this infrastructure used NGINX to configure the reverse proxying, and I built an Ansible role, nginx-gateway to set that up. However it didn't take care of issuing certificates, there was some Terraform that had to be rerun every few months, which is a strength of Traefik. That iteration also used client certificates (aka mTLS) for authentication, which was very secure but clunky: certs were issued with cobbled together openssl commands and several mobile apps and integrations wouldn't work because they couldn't present a client certificate, which is why I switched to OIDC.

Ansible Playbooks

The Ansible playbooks that manage all of this are stored in a private GitHub repository. The repo is laid out broadly along the lines of the layout in the Ansible documentation: there's a main playbook that imports various other playbooks to set everything up, along with host and group vars and an inventory file per environment.

site-automation/
  group_vars/
    production/
      cleartext.yml  # Non-sensitive vars for the production environmnet
      secret.yml  # Vault file containing encrypted secrets for production environment
    staging/
      cleartext.yml
      secret.yml
    vagrant_local/
      cleartext.yml
      secret.yml
  host_vars/
    gate/
      become.yml  # Password to become root on system
      gate.yml  # Vars that only apply to gate
    sofaserver/
      become.yml
      sofaserver.yml
  notes/
    setup-grafana.md  # Various Markdown notes about steps that have to be done manually
    setup-login.md
    ...
  templates/
    compose/
      esphome.yml  # Docker Compose file template for ESP Home
      firefly.yml
      grafana.yml
      ...
    gate/
      exim-cert-extract-cron.j2  # Exim certificate extraction cronjob template
      exim-cert-reload.sh  # Cert extraction script
      ...
    sofaserver/
      firefly-config.env.j2
      hdparm.conf.j2
      ...
  vagrant-testing/
    Vagrantfile  # Vagrantfile for describing local dev environment
    provision.sh  # Helper script to call `ansible-playbook` using Vagrant inventory
  .gitignore
  ansible.cfg
  inventory-production
  inventory-staging
  requirements.yml  # Roles used by the repo
  servers-00-all.yml  # Site playbook importing the others
  servers-15-networks.yml  # Configure networking and basic security hardening
  servers-20-gate.yml  # Server-specific plays for gate
  servers-20-sofaserver.yml  # Server-specific plays for sofaserver
  servers-30-containers.yml  # Set up containerised services
  servers-40-gate-post.yml  # Plays to run on gate after containers are up

The assumed starting point is a basic Ubuntu install, either using the installer (for the machines at home) or one of the cloud images on my VPS provider.

First off the servers-15-networks.yml playbook does some security hardening and network configuration by applying the firewall and security roles from Jeff Geerling. It also sets up Wireguard between the machines to have a secure internal network (using githubixx.ansible_role_wireguard) and creates records in Cloudflare DNS for the machine's IP addresses.

Next up is host-specific configuration. For sofaserver that means checking the health of the storage and RAID array and mounting it, although creating the array is done manually. It also includes setting up Samba file sharing and cloning a few HomeAssistant addons. For gate the Exim mail config is created, along with a script to extract TLS certificates from Traefik to reuse them for Exim.

Setting up and launching containers is the next step in servers-30-containers.yml, starting with installing Docker and deploying the samdbmg.traefik-auth-proxy role, then setting up each service.

services:  
  grafana:
    compose_file: templates/compose/grafana.yml
    data_backups:
      - path: /opt/grafana/data
    templates:
      - src: templates/sofaserver/grafana.ini
        dest: /opt/grafana/grafana.ini
    dns_entry:
      record: "{{ ('grafana' + services_zone) | trim('.') }}"

Each container service has a host var entry like the one above, which is used by the servers-30-containers.yml playbook to set it up. Compose files are templated to the host along with any config file templates, and data directories are created for containers to mount. Where those data directories contain useful application state, Duplicity is used for periodic backups of the data (using samdbmg.schedule-duplicity).

Finally, any extra post-container config is done, e.g. in servers-40-gate-post.yml which ensures the Traefik -> Exim certificate extraction process has run at least once.

Each deployed environment (production, staging and local testing) has its own set of group_vars, used to define the domain under which everything is hosted, versions of services, IP address ranges, etc.

Testing & Development

Since this is something I tinker with in my spare time (and that's spare time from both work and parenting) I have to pick it back up and be productive quite quickly. To help with that I try to keep detailed notes of what I'm working on: my current approach is a GitHub Issue for each bug/feature, into which I summarise progress, write up my research and add links to the commits as I work. I also maintain throwaway test environments to thoroughly test changes so I'm unlikely to break something and find I have to fix it immediately when I'm supposed to be on baby duty!

One of those test environments is a Vagrant configuration I maintain for each host, which automates building reproducible, disposable infrastructure.

Vagrant sets up a VM for each host, connects it to an internal network, and also applies any required hardware customisation like attaching extra disks. The Vagrant Ansible provisioner sorts out creating an inventory file, and a little script like the following lets me run Ansible commands using that inventory file (e.g. to apply part of the playbook for faster iterations than running vagrant provision).

#!/bin/bash

# Provision a single Vagrant VM using Ansible - mostly as a shortcut to save some typing. First arg is VM, rest are
# passed through
VM_NAME=$1
shift

ANSIBLE_CONFIG=../ansible.cfg ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook \
    -i .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory \
    ../servers-00-all.yml \
    --limit "${VM_NAME}" $@

Once a change to the playbooks has been written, I have a "staging" environment: VMs on a workstation that are very similar to the real production environment. I use this to practice complex upgrades that need to be tested in an environment that closely matches the real thing, like OS upgrades.

ansible-playbook -i inventory-production servers-00-all.yml -v --check --diff 2>&1 | tee check-prod-update.log

Finally, once a change is ready to go, I run Ansible in check and diff mode using the command above, and review all the changes it's going to make to the real thing, which has saved me a few times!

The Future

I'm going to keep evolving this setup and there are quite a few things I'd like to improve upon. I would like to have more CI/CD on some of the testing, perhaps being able to automatically power up the staging environment and apply changes to it. I've also got a couple of bugs to iron out, and a very long list of apps to test out and play with!

I have a handful of sensors around my house, monitoring things like temperature, air quality, broadband speed and latency, etc. Those are all linked back to Home Assistant, but by default it only stores 24 hours of data. I use the excellent LTSS (Long Term State Storage) module to push that data into Timescale DB, and then I can display and query it much further back in Grafana.

I use Docker Compose to deploy the Home Assistant/Grafana/Timescale DB combo, and had it set to use the timescale/timescaledb-ha:pg13 docker image - naturally the first thing I tried was just to bump the version to pg16 (something the manual hints at doing).

This broke my database, in quite a big way! Unsurprisingly, you can't just go up 3 major versions of the database and expect it to work: it fails to start complaining the database is an unsupported version. Fortunately I did this on my "staging environment" (as set of VMs I use to test stuff like this), so I rolled back to a backup and read up on pg_upgrade which got me to this process. Since initially testing this it's been better documented in the TimescaleDB docs, but I thought the step by step process was still useful.

The Process

Update current. Check how far it went (2.5 to 2.10 for me), find newest version. Upgrade to there, and repeat

The basic process is to upgrade your existing TimescaleDB extension to the latest version supported by your version of PostgreSQL, then upgrade your database to the latest version that supports that extension version, and repeat the process until you reach the version you want!

To actually upgrade PostgreSQL you start a new, empty database running the new version. Then you install the old version's binaries into it, and use pg_upgrade to move the old DB content into the new DB.

In theory this table in the docs lets you figure out how many steps you'll need to take: upgrade TimescaleDB to the newest version with a green tick for your PostgreSQL version, then upgrade PostgreSQL to a version that still has a green tick, then upgrade TimescaleDB, and so on. However I had some trouble in that my PostgreSQL 13/TimescaleDB 2.5 install wouldn't go higher than 2.10, so I had to take two steps: to PG15/Timescale2.10 and then to PG16/Timescale2.16.

For the step-by-step instructions, I'm working based on my Docker Compose environment, using a Compose file like the one below.

timescaledb:
  container_name: timescaledb
  image: timescale/timescaledb-ha:pg13-all
  environment:
    - POSTGRES_USER=usr
    - POSTGRES_PASSWORD=NOTMYPASSWORD
    - POSTGRES_DB=ha
  volumes:
    - '/opt/homeassistant/timescaledb/pgdata:/home/postgres/pgdata'
  restart: unless-stopped
  networks:
    - default

Here it is step by step.

Step 0: Make a backup!

Before you start, take a backup of your database unless you really, really don't care about the data. But if that's the case, why bother upgrading?

Step 1: Upgrade TimescaleDB

First upgrade TimescaleDB. With the server running, run the statements below on all your databases:

ALTER EXTENSION timescaledb UPDATE;
CREATE EXTENSION IF NOT EXISTS timescaledb_toolkit;
ALTER EXTENSION timescaledb_toolkit UPDATE;

In the Docker Compose environment shown above, you could run something like this to do them all in one go:

export DBNAMES=$(docker compose exec timescaledb psql \
    -U usr -d postgres --no-align --tuples-only \
    -qc 'SELECT datname from pg_database;')
for DBNAME in $DBNAMES; do
    docker compose exec timescaledb psql -U usr -d ${DBNAME} \
        -qc 'ALTER EXTENSION timescaledb UPDATE; CREATE EXTENSION IF NOT EXISTS timescaledb_toolkit; ALTER EXTENSION timescaledb_toolkit UPDATE;';
done

Step 2: Move your existing data elsewhere, start an empty database

Next, update your docker-compose.yml to move the database mount somewhere else inside the container, then bump the version. Stop the database for now and don't start it yet.

From the snippet of Compose file above the important modification is to change the volume for the data to be somewhere else inside the container, while also mounting the original location. That way, you can still access the old DB, but the container can start from clean. In the example below, I've moved it to /mnt/olddata

I use mounts on the host filesystem for my persistent data, so notice I've changed the host mount path too - I've also run mv /opt/homeassistant/timescaledb/pgdata /opt/homeassistant/oldtimescale in preparation.

timescaledb:
  container_name: timescaledb
  image: timescale/timescaledb-ha:pg15-all
  environment:
    - POSTGRES_USER=usr
    - POSTGRES_PASSWORD=NOTMYPASSWORD
    - POSTGRES_DB=ha
  volumes:
    - '/opt/homeassistant/timescaledb/pgdata:/home/postgres/pgdata'
    - '/opt/homeassistant/oldtimescale:/mnt/olddata'
  restart: unless-stopped
  networks:
    - default

Notice I've also bumped the version of the database, ready to start a new, empty one.

Note: You don't want anything to be writing to the database while you're doing this, so if you have other services that access the database, make sure they aren't running.

Next, create the directory structure for the new database and fix the permissions. Matching the example above:

sudo mkdir -p /opt/homeassistant/timescaledb/pgdata/data
sudo chown -R 1000 /opt/homeassistant/timescaledb/pgdata

Step 3: Install the old version into the container, use it to run the upgrade

Next, get a shell inside the container to install the old version of PostgreSQL. You'll want the new database to be empty for this, so make sure the container hasn't been started since the last step.

Run something like docker compose run --user root --entrypoint /bin/bash timescaledb to start a shell inside the container.

Then run the following commands to install the old PostgreSQL binaries and then run the upgrade command.

apt update

# Update the version as needed (your Docker image may include it already)
apt install postgresql-13

# Become the postgres user
su postgres

# Initialise a new empty database
/usr/lib/postgresql/15/bin/initdb --username usr

# Run the actual upgrade - you may need to tweak the user
/usr/lib/postgresql/15/bin/pg_upgrade \
    -b /usr/lib/postgresql/13/bin/ -d /mnt/olddata/data \
    -D ${PGDATA} -U usr

If that worked, you should see something like:

Your installation contains extensions that should be updated
with the ALTER EXTENSION command.  The file
    update_extensions.sql
when executed by psql by the database superuser will update
these extensions.

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade.
Once you start the new server, consider running:
    /usr/lib/postgresql/16/bin/vacuumdb -U usr --all --analyze-in-stages

If it told you to run an extension upgrade, run it as suggested (to do that you'll need to start the database as well). If it doesn't tell you, you can just exit the container.

Inside the container, run something like this (note the trailing & on the first command to make it run in the background):

/usr/lib/postgresql/15/bin/pg_ctl -D /home/postgres/pgdata/data -l logfile start &
psql -U usr -d postgres -f update_extensions.sql
psql -U usr -d postgres -c '\dx'

That last command will list the version of the extensions installed: make a note of what it is.

Finally you can type exit twice to get out of the container

Step 4: Repeat as needed

If you couldn't upgrade to your desired version in a single step, you'll now need to repeat steps 2 and 3 until you do.

Step 5: Tidy up

Finally, undo the changes you made to the Compose file, and delete the old database. You can bring the rest of your services up too, but add the --remove-orphans flag the first time to tidy away the containers used for the upgrade.

docker compose up --remove-orphans

My device has previously had an additional Vendor partition created (so technically it's a flox device rather than flo). That means some more space has been made for some things, but it also means tools like repit won't work for adjusting the size of partitions (see this XDA Developers post for more on that). YMMV - that's mainly a note to me!

See here for download links for the ROM I used (should be a zip file): https://forum.xda-developers.com/t/rom-flo-deb-unofficial-lineageos-19-1-2022-10-12.3569067/

You'll also want to download OpenGApps (the Google App suite) from that post. You want the pico variant (nothing else will fit) and arm not arm64, for the corresponding Android version to the copy of Lineage you installed (so aos12l at the time of writing).

If you want root access, you'll need a Magisk APK. The forum post where LineageOS came from should list suitable Magisk versions, but you'll need to download it from https://github.com/topjohnwu/Magisk/releases.

Finally, assuming you've already installed TWRP recovery, you might as well go ahead and update that while you're here. Head to https://twrp.me/asus/asusnexus72013wifi.html, scroll down to Download Links and choose a suitable mirror, then download the latest .img file.

Copying the Files

Once you've downloaded everything, go ahead and reboot the tablet into recovery by turning it off, then holding down the Power and Volume Down keys. Once it starts up, use the volume control to choose Recovery as an option, then push Power to boot.

Connect the tablet to your computer: it should mount automatically in the usual way. Then go ahead and copy the files to the root of the tablet.

Upgrading TWRP

1. Select the Install button

2. Go to Install Image bottom-right

3. Select the .img file for TWRP

4. Choose Recovery as the partition to flash

5. Swipe to confirm flash

6. Go back to the main screen, select Reboot and then Recovery

Installing LineageOS and OpenGApps

1. Select the Wipe button on the TWRP home screen

2. Swipe to Factory Reset

3. Go back to the Wipe screen, select Advanced Wipe

4. Select System, then swipe to wipe

5. Go back to the TWRP home screen

6. Select the Install button

7. Find the LineageOS zip file, select it

8. Swipe to install

9. Find the OpenGApps zip file, select it

10. Swipe to install

11. Reboot into the new system

12. When you're asked if you want to update Recovery with Lineage, don't tick the box: otherwise, it'll just overwrite TWRP for you, which is probably not what you want!

    

Installing Magisk

Once booted and you've done the initial setup, find the Magisk APK you downloaded earlier using the Files app, and install it.

Then you'll need to install Magisk itself, by following the instructions at https://topjohnwu.github.io/Magisk/install.html. Note that this device does not have a vbmeta partition (it'll save you a step).

1. Unzip the LineageOS zip file from earlier, to extract the boot.img file

2. Copy this to the tablet

3. Open the Magisk app, push the Install button

4. Leave the vbmeta option unchecked and push next

5. Choose Select and patch file, and find the boot.img file you copied in step 2

6. Push Let's Go

7. Shut down the tablet and reboot into recovery (power on with Power and Volume Down again)

8. Select Install, then Install Image

9. Find the .img file Magisk created in the Download folder and select it

10. Select Boot and swipe to confirm

11. Reboot system

(Re) Flashing TWRP

If you need to flash TWRP to start with or like me, you made a mistake and let LineageOS overwrite the recovery the first time, you need to run fastboot flash recovery twrp.img and then fastboot reboot (and then hold Power and Volume Down to get back to the bootloader and TWRP). If you have Docker and are on a Linux system, try these with the container at https://github.com/mparker17/docker-fastboot to save mucking about installing the ADB tools.

OK, so it wasn't a real one. British Airways ran a giveaway over Christmas and I was lucky enough to win one of three simulator sessions at the Cranebank training centre where BA train and certify their pilots. After a couple of emails and fighting my way through the rush hour traffic heading into London I dutifully showed up at a painfully early time this morning (8:15 is a dirty word among students!).

I was introduced to Andy who would be my pilot and instructor for the session, and ushered through a maze of corridors to the simulator itself. The simulators at Cranebank are full-motion, so they are basically a cockpit wrapped in screens, all supported on big hydraulic jacks that make it feel like real flight. The inevitable safety briefing followed and like everything in aviation redundancy was everywhere; in an emergency the simulator would 'land' and the access bridge would lower, and if that failed there was a ladder, and if the simulator angle stopped the ladder coming down there was a scramble net! Andy pointed out they'd never even needed the ladder before as the bridge had always worked

Some years ago I learned to fly a Grob Vigilant motor glider and even made a solo circuit, so we went through the controls and what the instruments did fairly quickly, paying particular attention to some of the automatic systems that make these aircraft (relatively) easy to fly. One such system is the Flight Director (pictured above, courtesy Wikipedia), which means altitudes, headings and climb rates can be programmed into the autopilot panel and pink lines on the PFD tell the pilot where to point the plane.

We set up for a takeoff on runway 27L at Heathrow, and I immediately got confused as the conditions were set for early evening but I'd arrived in brilliant sunshine at 8AM, which just goes to show how realistic the simulator is. You could even see headlights from the cars driving along the A30 and M25 near the runway! I made a rather wobbly takeoff that just about stayed on the runway, then flew a couple of turns, climbs and descents to try and get used to the aircraft, it feels a lot more sluggish than the little gliders did!

Up next was the big one, landing again. Andy talked me through it and handled all the aircraft setup like flaps and landing gear, and after nearly missing the runway and going quite a long way down it before touching the ground, it just about worked out. Oddly I landed quite a long way down the runway on my solo glider flight too after completely stuffing the approach angle and speed. Still, what is it they say, a good landing is any one you can walk away from and even better if you can reuse the plane!

We reset the simulator to 12 miles out to try again, which is where things went a bit wrong. The autopilot was engaged and setup to capture the ILS (autoland...ish) at Heathrow and the flight freeze was released. The throttles immediately advanced to full power and the whole cockpit shuddered a lot while Andy said "I'm not really sure I like that vibration" as he hastily went for the freeze button again. We reset the simulator, reset some of the controls and changed some configuration, shut off the autopilot and autothrottle this time, and tried again with much the same result. I noticed that the engine power gauges are still sat at idle despite the throttles being in the middle, and it looked to all appearances like we were dropping straight down towards Clapham when Andy hit the freeze button again.

It turned out that above the power gauges the "REV" indicator was still on, showing the thrust reversers were still extended after the earlier landing. This shouldn't be possible in flight and the lever won't even move unless the plane is on the ground - for good reason too as it makes the plane fall out of the sky! To get them to close again we called another Andy who had set up our simulator session and he pulled all the flight management computer circuit breakers, positioned us back on the ground and let the reversers close, then reset everything again to clear the problem.

As a minor technical note, particularly topical at the time I'm writing this; there is a huge panel of circuit breakers above the pilot's head in the 747, including two clearly labeled ACARS. For all the news media reporting on the tragic disappearance of MH370 and how detailed technical knowledge is needed to turn ACARS off in the 777, it's certainly easy to turn off in the 747!

After a slightly more successful landing (well I landed at the right end of the runway) Andy showed me what a category 3 autoland looks like in thick fog. Imagine staring at a blank white sheet, until at 50 feet above the ground a runway materialises out of nowhere and a second later you hit it, hoping that the autopilot has set everything up properly!

Finally we went for a change of scenery and took off out of Geneva in Switzerland, climbing out towards the Alps before turning back for my neatest landing yet, in that I stopped in the middle of the runway even if I touched down quite a long way to the left!

We'd run out of time by then, but the experience was absolutely fantastic, and I'd like to say a big thank you to British Airways for setting up the competition, and to Andy C and Andy S for a great morning out.

Naturally I'm talking about the Internet, and the evolution of the smartphone and the widening spread of mobile data, all of which add up to rich, connected applications pervading our daily lives. For many of us, we can't imagine life without always-on connectivity, and are completely stuck when our phones/tablets/whatever break or run out of power. Going beyond the mundane desire to tweet pictures of what I had for dinner, connectivity has even played a part in overthrowing dictatorships and corrupt regimes. If I want to know the situation in Mali, learn how to fix my car, or just watch a cat falling down the stairs repeatedly, its available near-instantly, wherever and whenever I want it.

Today I've worked with people I'll never meet, on a product they'll never see, I've pair-programmed with a friend 80 miles away as if he were sat next to me, and I've watched a music video performed by 40 people, from radically different backgrounds, scattered all over the world. The likes of YouTube have made unlikely celebrities (Numa Numa guy anyone?) and launched countless careers and forced the music and broadcasting industries to turn established ideas on their head to stay relevant in today's connected world.

Looking to the future, I'm hesitant to speculate what will come given the start to this post; and there are a great many terrifyingly plausible visions of our future, however I think its safe to say that it'll be interesting.

PCB etching works by applying an etch resist to a sheet of copper-clad laminate, then using an etching chemical to dissolve the copper not covered by resist, leaving the circuit behind. If tight manufacture tolerances aren't required this can be a DIY job with two main approaches. The first is to buy special [photo-etch boards](http://www.rapidonline.com/tools-equipment/photoetch-pcb-29445/ "...which can be bought from Rapid and similar"), print the circuit layout onto transparency, and use a lightbox to expose the board, with etch-resist remaining in the unexposed portions. This is potentially more accurate, but also more expensive for lightboxes and boards. The other method, which I used, is to transfer laser toner (from a laser printer) onto the copper-clad board, and the plastic-based toner will resist the etchant.

Naturally the first step was to design and layout a circuit. For this I used Eagle, with a set of design rules (setting trace and pad sizes and clearances) from http://www.ianstedman.co.uk/downloads/homepcb.dru. After bad experiences with autorouters before I routed mine by hand, taking care to minimise vias to the top layer. As etching a dual-layer PCB accurately using this method is almost impossible, the handful of traces that ran on the other layer would be point-to-point wire links (in blue on the layout).

The resulting PCB layout and schematic:

For toner-transfer to work it has to be heated to the point it melts and sticks to the board. With conventional laser paper this leaves bits of paper stuck to the circuit board, which will make the board look naff and soldering tricky. Glossy paper (such as magazine or photo paper) will break apart and come off in water, making it an ideal medium to use for the transfer. You can also buy special transfer paper, which is essentially the same thing. I used an old magazine I happened to have, but be careful not to choose anything too thin or it will jam in a printer.

By far the easiest way to transfer toner to the copper board is to iron it on, but be careful where you put the iron (as a nasty hole in my carpet will testify). Iron for quite a long time with plenty of heat (but no steam!), as if the paper is peeled off too early the etch won't work, and once its off it won't line back up. After peeling the paper off, run the board under warm water for a while and rub it gently (your fingers will do) to take of the rest of the glossy paper.

I attempted to clean up some of the traces which didn't transfer correctly with a fine-point Sharpie, but it didn't work out particularly well as the ink came off the board when I etched it.

Removing the remaining bits of paper after the transfer, and the layout transferred ready for ething

The next step is etching, but if you haven't already, trim the board to size. Fibreglass (the laminate holding the copper) is a tough substance to be prepared to blunt a conventional hacksaw, buy an expensive one, or just score it with a sharp knife and snap it (my approach).

There are a couple of etchant solutions available, but the most common is Ferric Chloride (FeCl), which can be bought in pellet form from most electronics suppliers (I got mine from Maplin).

Boring Health and Safety note: Ferric Chloride is extremely corrosive, and will attack any kind of metal, and more to the point, you. Wear eye protection and gloves, don't lick it, drink it, use it to wash yourself, feed it to your dog, you know the drill. Also, it stains clothes, so wear something you don't like. These were my preparations:

I made a hanger out of insulated wire to suspend my board in the solution (the insulation protects the metal wire) as in the photo below, and sacrificed a sponge as well to speed up the process.

The tricky bit with etching is to take the board out once all the copper is gone that you didn't want, but before the etchant has eaten away under the resist and destroyed the circuit you wanted. This bit didn't go so well for me, I think I left it in a little too long after I gave up wiping it with the sponge.

A drop of acetone (nail varnish remover) will remove the etch resist leaving a nice shiny PCB to begin soldering. In my case some repairs were needed as some of the traces weren't joined up anymore. Trying to repair with solder bridges is almost impossible, so I recommend sacrificing some resistors and laying segments of their legs across the gaps.

Above is the final result, with repairs done and most of the components populated. The board works, but it certainly isn't ideal given how long the repairs to fix broken traces took. From this experience, I would suggest if there is enough time (~1.5 months), take a look at [http://www.seeedstudio.com/depot/fusion-pcb-service-p-835.html Fusion PCB] who will produce 10 2-layer 5cmx5cm boards with change from £15. Eagle Files