Over time this will accumulate quite a collection of files in /vat/cache/distfiles that are no longer needed and just collecting dust there. Not to mention the space wasted by those files.

Of course, you can remove these files manually occasionally, but wouldn’t it be nice if portage would take care of this?

And portage can!
With a little tweak that I found quite some time ago.

Save the following as /etc/portage/bashrc:

# darkelf-features-0.1::darkelf
# created for ::darkelf overlay.
# by Simon the Sorcerer - http://homepages.uni-paderborn.de/neuron/gentoo/darkelf/
#
# This enables cleaning the distfiles after every emerge,
# to enable this feature set
# DARKELF_FEATURES="postmerge_distclean"
# in /etc/portage/make.conf or per command basis e.g.:
# DARKELF_FEATURES="postmerge_distclean" emerge ...

darkelf_postmerge_distclean() {
    echo cleaning distfiles for ${CATEGORY}/${PF} ...

    if [ -z $DISTDIR ] ; then
        echo ERROR: DISTDIR is empty!
        exit 1
    fi

    for f in $DISTDIR/* ; do
        echo deleting "`readlink -f $f`" ...
        rm -r "`readlink -f $f`"
    done
}

post_pkg_postinst() {
    if grep -q "postmerge_distclean" <<< $DARKELF_FEATURES ; then
        darkelf_postmerge_distclean
    fi
}

And now add the following to your /etc/portage/make.conf file:

# Portage clean up
# Remove downloaded distfiles from ${DISTDIR}
# see /etc/portage/bashrc
DARKELF_FEATURES="postmerge_distclean"

From now on, emerge will remove the downloaded distfile for the package that just got merged successfully from /var/cache/distfiles and clean up after itself this way. All you have to do is to clean out that directory one last time.

One thing though, please don’t change the code, it’s not mine. So keep the copyright/creator header in the bash script.

One thing to keep in mind, your SWAP should never be higher than your actual RAM though. SWAP is not meant to serve as “extra Memory”, it’s there for cases where your machine might temporarily need a bit more than just what you have for memory.

In my case. it’s Nextcloud. My Nextcloud is running on a 4 GB Raspberry Pi and when I scroll through my images this 4 GB RAM will be used rather fast, depending on how many images are already cached by Redis and how many thumbnails need to be generated. So it’s starting to use SWAP space and I can assure you, the default setting was not enough here and the system ran into an OOM (Out Of Memory) rather fast. Live image manipulation seems to use quite some memory, so increasing the SWAP it was and I opted to set it to 4 GB as well.

First, you need to deactivate the current SWAP.

sudo dphys-swapfile swapoff

Now modify the SWAP size by editing the /etc/dphys-swapfile. You find the variable CONF_SWAPFILE there. Set it to the size you like to have, like so:

CONF_SWAPSIZE=4096

If you plan on using more than 2 GB of SWAP space, you might have to comment in and change the CONF_MAXSWAP variable as well. and set it to the new SWAP size. CON_MAXSWAP is set to 2 GB as default and as the name already suggests, this is the maximum of SWAP space the system will reserve.

Now, re-create the SWAP file with:

sudo dphys-swapfile setup

And start the SWAP again with:

sudo dphys-swapfile swapon

That’s all, quick and easy.

However, I assume your docker container is defined through a docker-compose.yaml file and built with docker-compose.

#!/usr/bin/env bash

CWD=$(pwd)

# Make sure we are in the current directory with this script
cd $CWD

# Check for docker-compose.yaml file
if [[ -f "docker-compose.yml" || -f "docker-compose.yaml" ]]
    then
        # Updae docker containers
        docker-compose pull

        # Restart docker containers
        docker-compose down
        docker-compose up -d
    else
        echo "'docker-compose.yaml' not found, exiting."
        exit 1
fi

Save this script and make it executable.
To update, run this script in the directory where the containers docker-compose.yaml is located.

Reasons for hosting a search engine on your own are plenty, but mostly it’s about privacy. Google and other search provider collect a metric boatload of information with every search you run through them. And there is no need to feed them. What you search for should only concern you, after all.

SearXNG is a so-called meta-search engine. Which is nothing else but fancy speak for it’s asking multiple other search engines to get you the search result. And by self-hosting it, all privacy-related data and information stay with you and the other search engines only get the IP of the server you are hosting it on. Nothing else.

So, let’s dive into this endeavour and get it set up, shall we?

Prerequisites and Preparing the System

As mentioned, you need some hardware to host this. If you already have a server hosting your website, this will do. A small 3 €/month VPS from a hoster will do as well, even the Raspberry Pi on your desk will do. For the latter, you need to do some port forwarding in your router if you want to access it from outside of your local network, but I’m sure you know how to do this, am I right?

With this out of the way, let’s get to it. SSH into your server and make sure everything is up-to-date.

Hint: System-relevant commands in this article are for Debian-based systems, so you might have to translate this to whatever distribution you use.

sudo apt update
sudo apt upgrade

Now, let’s install Docker if not already installed.

sudo apt install docker.io docker-compose

Install SearXNG

From this point on, please make sure you are not using root as the user, use your unprivileged system user. Using root for everything is just a lousy manner. So su into your user and cd into the home directory, we’ll be working in there.

The easiest way is to clone the SearXNG docker repository from GitHub and make the needed changes there.

git clone git@github.com:searxng/searxng-docker.git

Now, cd into the searxng-docker directory.

cd searxng-docker

The first file you should edit is the .env file. This file holds the hostname and your email address for Let’s Encrypt if you like to use HTTPS, and there is no reason not to do so.

nano .env

Set the variables there accordingly and save the file.

Feel free to also have a quick look at the docker-compose.yml file, but usually, you don’t need to change anything in there.

Next, you generate a secret key, which is used to do some encryption.

sed -i "s|ultrasecretkey|$(openssl rand -hex 32)|g" searxng/settings.yml

The last file that needs to be edited is searxng/settings.yml.

nano searxng/settings.yml

In this file, you can customise your search engine. You can give it its own name, tell it which search engines it should use to get the search results for you and so on. I recommend at least giving it its own name and letting it know to use GET instead of POST (Default) for search queries.

To do so, add the following to their respective sections. If a section is not already defined, you can simply add it.

server:
  method: "GET"
ui:
  static_use_hash: true
redis:
  url: redis://redis:6379/0
general:
  debug: false
  instance_name : "Not Google"
  contact_url: false

For a deeper dive into the settings, feel free to have a look at the documentation here.

Now that everything is configured, time to start it. To do so, simply run:

sudo docker-compose up -d

If everything went according to plan, you should now be able to access your very own search engine under the URL you defined earlier.

Have fun!

Wouldn’t it be nice to host such a service yourself? PrivateBin to the rescue!

This article will showcase how easy it is to host your own PrivateBin instance. Some assumptions are being made here of course, such as that you have a server to run your PrivateBin instance, your own domain to go with and are confident to get SSL certificates to work because it’s 2022 and there is no reason not to have your website not running with HTTPS.

In this article, I walk you through both, bare-metal installation and docker-compose.

Bare-Metal Installation

Requirements

To run PrivateBin you need PHP installed. According to the official documentation of PrivateBin, PHP 7.0 at least, but again, it’s 2022, so best go with a more recent version here. I recommend using PHP 8.1, you can have a quick read-up here on how to install PHP 8.1 on Debian-based systems such as your Raspberry Pi for example.

Furthermore, you need some PHP extensions, such as:

• GD extension
• zlib extension

You also need some disk space or a database supported by PDO.

Install PrivateBin

The installation process is pretty straightforward.

Download the latest release from the release archive (It’s the link labelled “Source Code (…)”) and extract it in the folder you want to install your PrivateBin instance. For example /var/www/privatebin/. Ensure the files and folders are owned by the `www-data` user so your webserver can read and write there.

Configure PrivateBin

An example configuration is provided in cfg/conf.sample.php which you can copy to cfg/conf.php. The file’s content is well documented and explained in the file itself, change it to your needs. Important to know is that basepath is mandatory to configure with the URL of your PrivateBin instance, including the full protocol (`https://`) and it needs to have a trailing slash.

Configure the Webserver

I use Nginx for this, which I will cover here. For Apache2 users, I’m pretty sure you know how to write a vhost file pointing at a directory. There is no rocket science involved in this one, just have it pointing to the right directory.

server {
    listen 80;
    listen [::]:80;

    server_name pastebin.yourdomain.net;

    # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name pastebin.yourdomain.net;

    ssl_certificate         /certificates/pastebin.yourdomain.net.crt;
    ssl_certificate_key     /certificates/pastebin.yourdomain.net.key;

    include /etc/nginx/options-ssl-nginx.conf;

    gzip on;
    access_log  /var/log/nginx/pastebin.yourdomain.net/access.log;
    error_log   /var/log/nginx/pastebin.yourdomain.net/error.log  warn;

    root /var/www/pastebin;
    index index.php index.html index.htm index.nginx-debian.html;

    location / {
        try_files $uri $uri/ =404;
    }

    # In case you are running PHP-FPM, uncomment the following lines
#    location ~ .php$ {
#        include snippets/fastcgi-php.conf;
#        fastcgi_pass unix:/var/run/php/php-fpm.sock;
#    }
}

Docker-Compose Installation

Requirements

Same as for the bare-metal installation, we need to install some software packages, this time to run docker images. Let’s dive right into it and install docker and docker-compose.

sudo apt install docker.io docker-compose

That’s all the software you need to install. The next step is to prepare the docker-compose file so Docker knows what to do.

The Docker-Compose File

This file is pretty much a description file for Docker and holds information about what to download, how to name the container and so on. I’m not going into too much detail here, when you chose a Docker install you probably know what this is all about.

So, pick a nice spot on your favourite drive, I like to have my docker stuff in ~/docker/ for example, so it’s nice and easy to find, and create a file called docker-compose.yml and paste the following in.

version: "3.7"

services:
  privatebin:
    image: privatebin/nginx-fpm-alpine:latest
    container_name: privatebin
    read_only: true
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - './privatebin-data:/srv/data' # data volume for pastes
      - './conf.php:/srv/cfg/conf.php:ro' # second volume for custom configuration file
    ports:
      - 3007:8080
    restart: always

Of course, you can set port 3007 to whatever you like, just make sure you remember what you set it to and that no other service is already listening in this port.

Before we start up the Docker volume, one additional file needs to be created, conf.php. This file holds the configuration for your PrivateBin instance. To do so, simply download the configuration example from the official PrivateBin GitHub repository.

wget -O conf.php https://raw.githubusercontent.com/PrivateBin/PrivateBin/master/cfg/conf.sample.php

This is your configuration file, you definitely should have a look through it right about now and set things up accordingly.

Nginx as Reverse Proxy

Next on the list of things to do is to set up the Nginx reverse proxy. Create a new vhost file and paste in the following.

server {
    listen 80;
    listen [::]:80;

    server_name pastebin.yourdomain.net;

    # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    
    server_name pastebin.yourdomain.net;

    ssl_certificate         /certificates/pastebin.yourdomain.net.crt;
    ssl_certificate_key     /certificates/pastebin.yourdomain.net.key;

    include /etc/nginx/options-ssl-nginx.conf;

    add_header          X-Xss-Protection            "1; mode=block" always;
    add_header          X-Content-Type-Options      "nosniff" always;
    add_header          Strict-Transport-Security   "max-age=15552000; preload" always;
    add_header          X-Frame-Options             "SAMEORIGIN" always;
    add_header          'Referrer-Policy'           'origin-when-cross-origin';
    add_header          Content-Security-Policy     "frame-ancestors yourdomain.net pastebin.yourdomain.net;";
    add_header          X-XSS-Protection            "1; mode=block" always;

    proxy_hide_header   X-Powered-By;
    proxy_buffering     off;                        ## Sends data as fast as it can not buffering large chunks.

    gzip on;
    access_log  /var/log/nginx/pastebin.yourdomain.net.access.log;
    error_log   /var/log/nginx/pastebin.yourdomain.net.error.log  warn;

    location / {
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   Host $host;
        proxy_pass         http://localhost:3007/;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection "upgrade";
    }
}

As you can see in line 41, this is where you need the port from your docker-compose.yml file.

One thing you have to keep in mind, PasteBin will only run with SSL, so make sure you have that Let’s Encrypt certificate configured.

Start the Show

When you have saved your vhost file and activated it, go back to your docker directory and run the following command.

docker-compose up -d

If everything is correct, you should now be able to access your new PrivateBin instance in your browser.

Fix Permissions

(This only applies when you have selected file storage for your pastes in your conf.php.)

Unfortunately, you cannot yet save pastes, there are still some permissions that need to be fixed. It’s a bit fiddling around, but not that much.

First, make sure the privatebin-data directory is globally writeable. Don’t worry, we change that again, we just need the Docker instance to be able to write into it, so we can see what user and group it’s using.

sudo chmod 777 privatebin-data/

Now open your PrivateBin website and create a paste. This will now write some data into the directory and you can check for the user and group.

ls -rtlh privatebin-data/

For me, this was the result:

» sudo ll privatebin-data/
total 32K
drwx------ 3 nobody 82 4.0K May 13 21:12 3c
drwx------ 3 nobody 82 4.0K May 13 21:08 4f
drwx------ 3 nobody 82 4.0K May 13 21:02 66
drwx------ 3 nobody 82 4.0K May 13 20:59 86
drwx------ 3 nobody 82 4.0K May 13 21:00 ae
-rw-r----- 1 nobody 82   45 May 13 21:12 purge_limiter.php
-rw-r----- 1 nobody 82  522 May 13 20:59 salt.php
-rw-r----- 1 nobody 82  132 May 13 21:12 traffic_limiter.php

As you can see, the user is nobody and the group is 82 in my case. So the next step will be to fix the permissions for the privatebin-data directory.

sudo chown -R nobody:82 privatebin-data/
sudo chmod 700 privatebin-data/

This should take care of the permission issue and PrivateBin should now be able to write into the data directory without issues and without it being globally writeable.

That’s it, have fun with your own Pastebin service!

With this in mind, we’re going for the latest PHP version, which – at this time – is 8.1. To install this one, some minor steps are needed, nothing too big, just a couple of commands to copy/paste.

Note: This guide is not only for Raspberry Pi and may also be used for Debian and/or Ubuntu (untested though).

Install PHP 8.1

First off, the respective sources need to be added. For this, the GPG keys need to be downloaded to verify the packages.

sudo wget -qO /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg

Now add the repository with:

echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list

And update the package list with:

sudo apt update

Now, PHP 8.1 and all its extensions can be installed using apt.

Example with the most common extensions:

sudo apt install -y php8.1-common php8.1-cli php8.1-mysql php8.1-xml php8.1-curl php8.1-zip php8.1-gd php8.1-imap 

Check which PHP version is active with:

php --version

Installed PHP modules/extensions can be checked with:

php -m

Integrate With Your Apache2 Webserver

To integrate PHP 8.1 with your Apache2 webserver, simply run:

sudo apt install libapache2-mod-php8.1

In case there is already another version of PHP used by your Apache2, the installation will return something like this:

...
Creating config file /etc/php/8.1/apache2/php.ini with new versionlibapache2-mod-php8.1: php8.0 module already enabled, not enabling PHP 8.1

In this case, the old PHP version needs to be disabled and the new one enabled. (In this example PHP 8.0 is the old version)

sudo a2dismod php8.0
sudo a2enmod php8.1

Now the Apache2 webserver needs to be restarted, which you do with this command:

sudo systemctl restart apache2.service

Test PHP

In the public directory of your webserver (/var/www/html/ by default) place a file called phpinfo.php with the following content:

<?php
phpinfo();

Now when opening this file in your web browser the PHP info page should be returned detailing everything about the PHP installation and configuration.

Make sure this page is not publically available though, it might expose some information of your installation you want to keep for yourself.

Uninstall PHP

To completely uninstall PHP again, run the following command:

sudo apt purge --autoremove -y php-common mime-support

Remove GPG keys and the repository with:

sudo rm -rf /etc/apt/trusted.gpg.d/php.gpg
sudo rm -rf /etc/apt/sources.list.d/php.list

And last but not least, remove the systemd file with:

sudo rm -rf /var/lib/systemd/timers/stamp-phpsessionclean.timer

One way could be to unplug the MicroSD card – or any other kind of storage you use – from it, plug it into your workstation and make a copy of it. While this definitely works, it will leave your Raspberry Pi offline for that time, which in return would interrupt the service it provides.

So, a better way would be to run the backup while the Raspberry Pi is up and running. And let me tell you, this is pretty simple to do with the dd command.

Some Assumptions

You have some sort of storage somewhere (like a NAS for example) that can be mounted via cifs or nfs, whatever flavour you like. I’ll be using cifs in this example.

The backup storage is mounted to /mnt/Backup/, but you can mount it anywhere you like in your file system.

Mount the Storage

Your CIFS is hopefully requiring a username and password. So you’ll need to create a credentials file first. This file is used to pass your credentials – username and password – to cifs during the mount process.

For simplicities sake, we’ll have this file as /home/pi/.mount-credentials/backup-storage with the following content:

username=your_cifs_user
password=your_cifs_password

To make sure this file cannot be changed by accident, secure it:

chmod 600 /home/pi/.mount-credentials/backup-storage

Now, that this is done, it’s time to tell the system where we want to mount the backup storage.

First, the mount point needs to be created. This is simply a directory where the backup storage is mounted to.

sudo mkdir -p /mnt/Backup

Now it’s time to mount the backup storage to its new location. Again for simplicities sake, we use the /etc/fstab file here. This way it’ll be mounted every time the Raspberry Pi is booting.

To do so, add the following line to your /etc/fstab file:

//my_server.lan/backup/raspberry-pi    /mnt/Backup    cifs    credentials=/home/pi/.mount-credentials/backup-storage,vers=3.0,uid=pi,gid=pi,iocharset=utf8,dir_mode=0770,file_mode=0655,noperm    0 0

Explanation:

//my_server.lan/backup/raspberry-pi is the directory on your backup storage where the backup files will be written to. Change this accordingly.

/mnt/Backup is where the backup storage is mounted and can be accessed.

cifs is the network filesystem we use.

And the long line of options are options that are passed down to cifs, like our credentials, which user should be used, directory and file permissions, charset and so on.

Save the file and run the following command to mount the backup storage:

sudo mount -a

The Backup Script

Now that we have taken care of the backup location, it’s time to write our little backup script. Nothing too fancy, just some lines of shell/bash script that will check if the backup storage is mounted and try to mount it if needed and create the backup file.

But before we do so, we need to figure out which device our drive is. Luckily that’s a rather simple task, just run lsblk in your console and you should see something like this:

pi@raspberry_pi ~ $
» lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 119.2G  0 disk
├─sda1   8:1    0   256M  0 part /boot
└─sda2   8:2    0   119G  0 part /

/dev/sda is the device in my case. This could vary in your setup. Make sure to change it accordingly in the backup script.

File: /home/pi/raspi-backup

#!/usr/bin/env bash


isMounted () {
    findmnt "$1" > /dev/null;
}


run_backup () {
    # Set some variables
    DATE=`/bin/date '+%Y-%m-%d'`
    TIMESTAMP="$(date +%s)"
    HOSTNAME="$(hostname)"

    DEVICE_TO_BACKUP="/dev/sda"

    BACKUP_DIR="/mnt/Backup/"
    BACKUP_FILE_NAME="raspi-${HOSTNAME}-${DATE}-${TIMESTAMP}.img"


    # Mount the backup directory if necessary
    if ! isMounted "${BACKUP_DIR}";
        then
            sudo mount ${BACKUP_DIR}
    fi

    # Check again to see if the mount was successful.
    # If not, stop right here, something went horribly wrong
    if ! isMounted "${BACKUP_DIR}";
        then
            echo "Backup directory could not be mounted. Exiting here!"

            exit 1;
    fi


    # Now go forth and run the backup
    echo "Backing up ${DEVICE_TO_BACKUP} to ${BACKUP_DIR} as ${BACKUP_FILE_NAME} ..."
    time sudo dd if=${DEVICE_TO_BACKUP} of=${BACKUP_DIR}${BACKUP_FILE_NAME} bs=1M status=progress

    # Check for PiShrink (https://github.com/Drewsif/PiShrink)
    if command -v pishrink.sh > /dev/null
        then
            # Shrinking the image
            sudo pishrink.sh -rv ${BACKUP_DIR}${BACKUP_FILE_NAME}
    fi
}


run_backup

Make sure the file is executable with:

chmod +x /home/pi/raspi-backup

Run the Backup

The backup script is ready to be tested. To run a backup simply execute the following command in your console:

/home/pi/raspi-backup

With this command, your backup file will be created under /mnt/Backup/raspi-your_hostname-date-timestamp.img. Keep in mind, we are using a network connection to the backup storage, so this might take a while, depending on the size of your MicroSD card or other storage on your Raspberry Pi.

For my AdGuardHome Pi the output looks like this:

pi@adguard ~ $
» ./raspi-backup
Backing up /dev/sda to /mnt/Backup/ as raspi-adguard-2022-10-21-1666324418.img ...
127969263616 bytes (128 GB, 119 GiB) copied, 1155 s, 111 MB/s
122104+1 records in
122104+1 records out
128035676160 bytes (128 GB, 119 GiB) copied, 1161.04 s, 110 MB/s

real    19m21.064s
user    0m1.766s
sys     7m48.681s

Restore a Backup

To restore a backup you can use any tool that can write ISO images to a device, like the Raspberry Pi Imager for example, or Balena Etcher. The only thing you have to make sure of is that the device is large enough. You can even use the same MicroSD card again, and since you have to restore a previous version, something went wrong with the live system, so the data on this particular MicroSD is probably damaged or in any other way no longer viable anyways.

Last Words

Now, you only have to make sure to always have a somewhat recent backup!

This method is of course not limited to Raspberry Pi systems, you can apply this method to any Linux system you want. I used the Raspberry Pi here as an example to showcase how easy it is to create backups of a running system.

But what about domains that are not public? Like for your own local development? Usually, these domains look like wordpress.local for example and you won’t get SSL certificates for them. That is because they only exist in your local network and certbot can’t reach them for its DNS challenge. In other words, certbot can’t verify them and cannot create an SSL certificate for them.

Sure, you can try to trick certbot a bit by using a subdomain of your live domain for example and use certbot with the --certonly option. That works somehow, but the SSL certificate generated this way can’t be renewed automatically and you have to do this dance every 3 months. Pretty annoying, trust me, been there, done that.

Now wouldn’t it be nice if there is a way to get proper SSL certificates for your local domains as well and renew them automatically? Yes, it would, and there is! Lego to the rescue!

First off, some assumptions and preparations. This still will not work with a .local domain. You need a valid live domain, in my case ppfeufer.de. And this domain needs to be with a provider that is in Logo’s list of DNS Providers. Because what Lego does is, query your DNS provider and obtain the certificate for you.

So, let’s play this step by step on an example in my case. My local WordPress development is wp-local.ppfeufer.de and I like to have an SSL certificate for it. Why? Because I’d like to test if everything works with SSL, simple as that. Also, it’s 2022, no reason not to have SSL certificates, even for local domains :-P

Another assumption we have to make is that you are working on a Linux system. I have no idea how and even if this all will work on Windows at all. Sorry.

Install Lego

First, you need to install Lego. This can be done by simply cloning their GitHub repository and installing it from there.
Make sure you have Golang (>=1.17) installed as well, it’s needed, we’re installing a piece of software written in Go after all.

Clone the GitHub repository into a directory of your choice with:

git clone git@github.com:go-acme/lego.git

Now let’s change into the repository and compile the Lego client.

cd lego
export GO111MODULE=on
make build

This will take a while. This command pulls all the needed Go modules and compiled the Lego client, which can be found in the dist directory when done.

Now that the Lego client has been compiled, you’ll find it in the dist directory inside the git repository. Go ahead and make the file executable if it isn’t already (Seems to be depending on the distribution)

chmod +x lego

Making It Available on the System

After successfully compiling the Lego client, it needs to be made available to the command prompt. This means we have to move it somewhere where it can be executed by simply typing lego in our console. I for once have it in /usr/bin/, just a personal preference.

cd /usr/bin/
ln -s /path/to/the/legorepository/dist/lego .

As you can see, I’m not moving the file, I just link it. This has the advantage that when I update the Lego client, I don’t have to copy or move the file again. It’s linked and with that, it will always be the up-to-date version.

Usage

Now that the preparations are done, time to use the Lego client.

Pick your DNS provider from this list right here, the one I use in this example is Hetzner and as you can see, there is already an example given on how to obtain the SSL certificate.

Example:

cd /home/your_username

HETZNER_API_KEY=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
lego --email your@email.com --dns hetzner --domains your.domain.com run

Of course, you need an API key from Hetzner first, which you can create in your DNS console on Hetzner’s website. Make sure to never share this key with anyone!

Now you’ve got an SSL certificate which you can configure your web server with.

All you need to do is add an entry to your /etc/hosts file, to make sure your local machine doesn’t bother your ISP’s DNS server for the domain name and resolves it locally.

My example:

127.0.0.1    your.domain.com

From now on, every time your local machine queries this domain it resolves to its local address where your web server is listening.

Renew the Certificate

Let’s Encrypt SSL certificates are valid for 3 months, so it needs to be renewed regularly. For this it’s best to make use of a cron task.

Add the following to your crontab:

##
# Certbot for renewing SSL certificates
##
0 */6 * * * /home/your_username/.lego/renew-scripts/01_renew_certificates

As you can see, we make use of a shell script here. Change the file name to whatever you think is best.

The shell script we call with the cron task looks like this:

#!/usr/bin/env bash

# Load the Hetzner API key
export HETZNER_API_KEY_FILE=/home/your_username/.lego/hetzer-api-key

LEGO_ACCOUNT_EMAIL=your@email.com
LEGO_PATH="/home/your_username/.lego"
LEGO_CERTIFICATES_PATH="${LEGO_PATH}/certificates"
LEGO_RENEW_DAYS=10
LEGO_DNS_PROVIDER=hetzner

CERTIFICATE_RENEWED=False


for LEGO_CERTIFICATE_NAME in `/usr/bin/lego --path ${LEGO_PATH} list --names`
    do
        original=$(date -r "${LEGO_CERTIFICATES_PATH}/${LEGO_CERTIFICATE_NAME}.crt")

        /usr/bin/lego \
            --path ${LEGO_PATH} \
            --email ${LEGO_ACCOUNT_EMAIL} \
            --accept-tos \
            --dns ${LEGO_DNS_PROVIDER} \
            --domains ${LEGO_CERTIFICATE_NAME} \
            renew --days ${LEGO_RENEW_DAYS}

        actual=$(date -r "${LEGO_CERTIFICATES_PATH}/${LEGO_CERTIFICATE_NAME}.crt")

        if [ "${original}" != "${actual}" ]
            then
                CERTIFICATE_RENEWED=True
        fi
    done


if [ ${CERTIFICATE_RENEWED} == True ]
    then
        systemctl restart apache2.service
fi


exit $?

The script needs to be executable, so run:

chmod +x /home/your_username/.lego/renew-scripts/01_renew_certificates

Update the Lego Client

Updating the Lego client is pretty straightforward. All you need to do is pull the latest from GitHub and compile it again.

cd /path/to/the/legorepository/
git pull
export GO111MODULE=on
make build

That’s it.

Change Boot Configuration

First, we need to edit the boot configuration file /boot/config.txt and add the following lines (edit if they are already there):

# Disable Bluetooth
dtoverlay=disable-bt

# Disable WiFi
dtoverlay=disable-wifi

This will disable the Bluetooth and WiFi interfaces on start-up.
Unfortunately, it is not that easy. Would be nice, wouldn’t it?
The services are still running, the kernel modules are still loaded. Both are completely unnecessary at this point, so let’s take care of that.

Disable the Services

To disable the services run the following commands:

sudo systemctl disable wpa_supplicant.service
sudo systemctl disable hciuart.service
sudo systemctl disable bluealsa.service
sudo systemctl disable bluetooth.service

Blacklist the Kernel Modules

Now that the services are deactivated, it’s time to blacklist the kernel modules. To do so, open /etc/modprobe.d/raspi-blacklist.conf in an editor of your choice and add:

# Disable Bluetooth
blacklist btbcm
blacklist bnep
blacklist bluetooth

# Disable WiFi
blacklist 8192cu

As you might have guessed by the file name, this will blacklist the modules and prevent them from being loaded during the system start.

Disable WiFi Check

Now, with the next login you might see a message like this:

rfkill: cannot open /dev/rfkill: Permission denied
rfkill: cannot read /dev/rfkill: Bad file descriptor

This is generally nothing to be worried about, as it is just the WiFi check telling you it can’t check the status of the WiFi interface. What a surprise!

There are 2 ways to go about it. Ignore it, which you can happily do, but if you’re like me and get annoyed by it, you might want to disable the WiFi check.

To do so, open /etc/profile.d/wifi-check.sh in an editor of your choice and add exit 0 right after the first opening bracket. The file should then look like this:

(
    exit 0
    export TEXTDOMAIN=wifi-check

    . gettext.sh

    if [ ! -x /usr/sbin/rfkill ] || [ ! -c /dev/rfkill ]; then
    exit 0
    fi

    if ! /usr/sbin/rfkill list wifi | grep -q "Soft blocked: yes" ; then
    exit 0
    fi

    echo
    /usr/bin/gettext -s "Wi-Fi is currently blocked by rfkill."
    /usr/bin/gettext -s "Use raspi-config to set the country before use."
    echo
)

If for whatever reason, you don’t feel like editing yet another file, you can just throw this command in your console, and it will do exactly that:

sudo sed -i '2i\ \ \ \ \ \ \ \ exit 0' /etc/profile.d/wifi-check.sh

Now, log out and back in and the warning message should be gone. Just don’t forget to reverse this change if you ever need to activate WiFi again.

(Optional) Remove Unused Software

Now that we have disabled Bluetooth and WiFi, we can also remove the software for it. This step is entirely optional, but if you like a clean system, go ahead.

sudo apt purge bluez bluez-firmware wpasupplicant
sudo apt-get autoremove

Reboot

To apply all these changes, the Raspberry PI needs to be rebooted.

sudo reboot

So, wouldn’t it be nice if the actual command line has this information? Yes! It can be done, at least in Bash, you just need to add a little bit of code to your bashrc file.

# GIT and SVN
parse_svn_repository_root() {
    svn info 2>/dev/null | sed -ne 's#^Repository Root: ##p'
}

parse_svn_url() {
    svn info 2>/dev/null | sed -ne 's#^URL: ##p'
}

parse_git_branch () {
    git name-rev HEAD 2> /dev/null | sed 's#HEAD\ \(.*\)# (git » \1)#'
}

parse_svn_branch() {
    parse_svn_url | sed -e 's#^'"$(parse_svn_repository_root)"'##g' | awk '{print " (svn » "$1")" }'
}


# Add to command prompt
if [[ ${EUID} == 0 ]] ; then
    # root
    export PS1='\[\033[01;31m\]\u@\h\[\033[01;34m\] \W \$\[\033[31m\]$(parse_git_branch)$(parse_svn_branch)\[\033[01;34m\]\[\033[00m\] '
else
    # normal user
    export PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[31m\]$(parse_git_branch)$(parse_svn_branch)\[\033[01;34m\]\[\033[00m\] '
fi

With the next login, you’ll see the active branch and or tag information in your command line.