fusselkater.org

Umbau meiner Webseite auf Jekyll

2023-10-13T00:00:00+02:00

Da ich auf meinem Blog wirklich selten etwas schreibe, war mir Wordpress schon lange ein Dorn im Auge. Deshalb habe ich mich in den letzten Wochen bemüht, meine Website auf Jekyll umzustellen. Jekyll ist ein statischer Seitengenerator, der auch Blogs verwalten kann. Jekyll ist in Ruby entwickelt und daher auch als Ruby-Gem verfügbar.

Installation

Ich wollte von Anfang an, dass die Build-Umgebung portabel ist, auch z.B. in einer CI/CD-Pipeline. Deshalb habe ich mich entschieden, jekyll und seine Abhängigkeiten nicht aus einem Systempaket zu installieren, sondern die entsprechenden Pakete mit Bundler aus den Gems zu laden.

Dazu habe ich ein neues Verzeichnis www.fusselkater.org angelegt und dort bundle init ausgeführt. Damit der Bundler in den nächsten Schritten nicht versucht, die benötigten Gems systemweit zu installieren, habe ich danach noch .bundle als Pfad gesetzt:

bundle config set --local path '.bundle'

Die Installation von Jekyll erfolgt dann über bundle add jekyll. Dieser Befehl schreibt jekyll auch direkt in das durch bundle init erzeugte Gemfile, so dass später nur noch bundle install aufgerufen werden muss, um die Build-Umgebung aufzubauen.

Neues Jekyll-Projekt erstellen

Da Jekyll im .bundle Pfad installiert wird, ist der Befehl jekyll natürlich nicht in den Systempfaden enthalten. Um die über Bundler installierten Programme trotzdem nutzen zu können, kann man einfach ein bundle exec vor den entsprechenden Befehl setzen.

bundle exec jekyll new src --blank

Da ich nicht das Standard Minima-Theme haben wollte, habe ich das Jekyll-Projekt mit dem Parameter --blank erstellt. Dies sorgt dafür, dass nur das Gerüst für eine Jekyll-Webseite aufgebaut wird.

Themes

Für Jekyll gibt es zahlreiche Themes. Leider lassen sich die meisten Themes nicht über Gems installieren, sondern erwarten, dass man ein Jekyll-Projekt forkt und in seine Webseite einbaut. Das fand ich sehr unsauber, weshalb ich mich bei der Theme-Auswahl auf solche Themes beschränkt habe, die via Gem verfügbar sind.

Meine Wahl fiel schließlich auf das whiteglass Theme, welches ich dann mittels bundle add jekyll-whiteglass installierte.

In der Installationsanleitung des Themes wird auch beschrieben, dass noch einige Dateien aus dem Github Repository installiert werden müssen. Dies habe ich entsprechend gemacht:

pushd src
rm index.md
curl -L -O "https://github.com/yous/whiteglass/raw/master/{index.html,about.md,archives.md,feed.xml,robots.txt}"
curl -L --create-dirs -o _data/#1 "https://github.com/yous/whiteglass/raw/master/_data/{navigation.yml,i18n.yml}"
popd

Später habe ich die Datei about.md in gpg.md umbenannt, um eine Seite für meinen GPG-Schlüssel zu erstellen und die Datei _data/naviagion.yml entsprechend angepasst.

Plugins

Zum Aufbau der Seite werden noch einige Plugins benötigt. Deshalb habe ich einige Plugins mit bundle add installiert:

bundle add --group jekyll_plugins jekyll-archives jekyll-paginate jekyll-sitemap jekyll-feed

Im weiteren Verlauf ist mir aufgefallen, dass es mit Jekyll standardmäßig nicht möglich ist, Bilder, die in den einzelnen Blogartikeln verwendet werden, im Ordner des jeweiligen Blogartikels zu speichern, sondern dass diese immer im globalen Ordner assets abgelegt werden müssen. Da ich befürchtete, dass dies später im Chaos enden würde, habe ich nach einer Lösung gesucht und das Plugin jekyll-postfiles gefunden. Dieses kopiert während des Build-Prozesses die statischen Daten aus den Ordnern der Blog-Artikel in die Assets.

bundle add --group jekyll_plugins jekyll-postfiles

Erster Test

Nun war alles bereit, um den Entwicklungsserver zu starten:

pushd src
bundle exec jekyll serve
popd

Das funktionierte wunderbar. Das Grundgerüst für die neue Seite stand also.

Makefile

Da mir das ständige Wechseln zwischen den Verzeichnissen und das Merken der Befehle langsam lästig wurde, habe ich mir ein Makefile geschrieben, das mir diese Arbeit abnimmt:

.DEFAULT_GOAL:=help

BUNDLE = bundle
SRCDIR = src
DSTDIR = out

MINIFY_HTML = bin/minify-html
MINIFY_HTML_URL = https://wilsonl.in/minify-html/bin/0.11.1-linux-x86_64

.PHONY: help
help: ## Display this help message
	@echo 'Usage: make <command>'
	@cat $(MAKEFILE_LIST) | grep '^[a-zA-Z]'  | \
	    sort | \
	    awk -F ':.*?## ' 'NF==2 {printf "  %-26s%s\n", $$1, $$2}'

.PHONY: setup
setup: ## Install requirements
	${BUNDLE} config set --local path '.bundle'
	${BUNDLE} install
	mkdir -p bin
	curl ${MINIFY_HTML_URL} -o ${MINIFY_HTML}
	chmod +x ${MINIFY_HTML}

.PHONY: serve
serve: ## Start the development server
	${BUNDLE} exec jekyll serve --source ${SRCDIR} --destination ${DSTDIR}

.PHONY: build
build: ## Build the site for production (minify HTML/CSS/JS)
	${BUNDLE} exec jekyll build --source ${SRCDIR} --destination ${DSTDIR}
	${MINIFY_HTML} \
		--keep-closing-tags \
		--minify-css \
		--do-not-minify-doctype \
		--ensure-spec-compliant-unquoted-attribute-values \
		--keep-spaces-between-attributes \
		$$(find ${DSTDIR} -type f -iname '*.html' -o -name '*.css' -o -name '*.js')

.PHONY: clean
clean: ## Cleanup output and temporary files
	rm -rf ${DSTDIR}
	rm -rf ${SRCDIR}/.jekyll-cache

Zusätzlich habe ich auch direkt einen HTML-Minifier in das Build-Target geschrieben, so dass die HTML-, CSS- und JS-Dateien nach dem Bau der produktiven Seite verkleinert werden.

Google Fonts

Das whiteglass-Theme verwendet standardmäßig den Bitter-Font direkt von Google. Da mir das datenschutztechnisch nicht gefällt, habe ich mich nun darum gekümmert, den Bitter-Font auf meinem Host anzubieten. Dazu habe ich den Bitter-Font heruntergeladen und die beiden Dateien Bitter-Italic-VariableFont_wght.ttf und Bitter-VariableFont_wght.ttf in das woff2-Format konvertiert.

woff2_compress Bitter-Italic-VariableFont_wght.ttf
woff2_compress Bitter-VariableFont_wght.ttf

(Das Programm woff2_compress ist im Paket woff2-tools (Fedora) enthalten)

Die beiden woff2-Dateien habe ich nun nach src/assets/fonts/Bitter/italic.woff2 bzw. src/assets/fonts/Bitter/regular.woff2 kopiert.

Im nächsten Schritt war es notwendig, einige Dateien aus dem Theme zu überschreiben. Dazu habe ich folgende Dateien erstellt:

src/_includes/fonts.html:

<link href="/assets/fonts/Bitter/fonts.css" rel="stylesheet">

src/assets/fonts/Bitter/fonts.css:

  /* latin */
  @font-face {
    font-family: 'Bitter';
    font-style: italic;
    font-weight: 400;
    src: url(/assets/fonts/Bitter/italic.woff2) format('woff2');
    unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
  }
/* latin */
@font-face {
    font-family: 'Bitter';
    font-style: normal;
    font-weight: 400;
    src: url(/assets/fonts/Bitter/regular.woff2) format('woff2');
    unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
  }
/* latin */
@font-face {
    font-family: 'Bitter';
    font-style: normal;
    font-weight: 700;
    src: url(/assets/fonts/Bitter/regular.woff2) format('woff2');
    unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
  }

Blog-Einträge

Nun war alles bereit, um meine Blogeinträge aus Wordpress zu kopieren. Da ich nur 2 Blogeinträge hatte, habe ich das manuell gemacht. Es gibt aber ein [Projekt] (https://github.com/benbalter/wordpress-to-jekyll-exporter), das das automatisiert.

Nextcloud hinter einer OPNSense Firewall mit Nginx Reverse-Proxy

2021-01-16T00:00:00+01:00

Heute dachte ich mir, ich möchte gerne meine Nextcloud auf meinem Heimserver betreiben. Da ich bei mir eine OpnSense als Firewall verwende und diese ein Plugin für einen Nginx Reverse-Proxy anbietet, bot sich an, dieses für diesen Zweck zu verwenden. Der Vorteil ist, ich kann SSL auf der OpnSense Terminieren, so dass ich den dort sowieso bereits eingerichteten Let’s Encrypt Client verwenden kann. Da die Konfiguration nicht ganz trivial war, zeige ich hier einmal, wie ich alles eingerichtet habe.

Einrichtung der Nextcloud auf dem Server

Um Nextcloud auf meinem Server einzurichten, habe ich das offizelle Docker-Image unter Verwendung der dort verlinkten Beispiel-Konfigurationen verwendet. Da Redhat/Fedora inzwischen auf Podman als Alternative zu Docker setzt, habe ich auch direkt Podman und Podman Compose installiert. Dies ist (mehr oder weniger) ein 1 zu 1 Ersatz für Docker, was eine Migration sehr leicht gestaltet.

Um später die Compose-Dateien aller Services an einem Ort zu haben, habe den Ordner /etc/containers/compose.d/nextcloud angelegt. Sämtliche Konfigurationsdateien in den nächsten Schritten liegen also in diesem Ordner.

Nun habe ich die Compose-Datei „container-compose.yml“ angelegt:

version: '3'
volumes:
  data:
  db:
services:
  db:
    image: mariadb
    restart: always
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    volumes:
      - db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=CHANGEME
      - MYSQL_PASSWORD=CHANGEME
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
  redis:
    image: redis:alpine
    restart: always
  app:
    build: /etc/containers/compose.d/nextcloud/app
    restart: always
    volumes:
      - data:/var/www/html
    environment:
      - MYSQL_PASSWORD=CHANGEME
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=db
      - REDIS_HOST=redis
      - NEXTCLOUD_TRUSTED_DOMAINS=cloud.example.com
      - OVERWRITEHOST=cloud.example.org
      - OVERWRITEPROTOCOL=https
    links:
      - db
      - redis
    depends_on:
      - db
      - redis
  web:
    build: /etc/containers/compose.d/nextcloud/web
    restart: always
    ports:
      - 30000:8443
    volumes:
      - data:/var/www/html:ro
    links:
      - app
    depends_on:
      - app
  cron:
    image: nextcloud:fpm-alpine
    restart: always
    volumes:
      - data:/var/www/html
    entrypoint: /cron.sh
    depends_on:
      - db
      - redis

Dies baut die Images für app und web und verwendet für mariadb, redis und cron die offiziellen Images aus dem Docker-Hub. Dementsprechend habe ich für app und web Unterordner angelegt, auf die ich nun eingehe:

app/Dockerfile:

FROM nextcloud:fpm-alpine
COPY www.conf /usr/local/etc/php-fpm.d/www.conf

app/www.conf:

[www]
user = www-data
group = www-data
listen = 127.0.0.1:9000
pm = dynamic
pm.max_children = 120
pm.start_servers = 12
pm.min_spare_servers = 6
pm.max_spare_servers = 18

Dies habe ich dafür angelegt, damit ich die Werte unter pm.max_children, pm.start_servers, usw. anpassen kann, die in der Original-Datei sehr niedrig angesetzt sind.

web/Dockerfile:

FROM nginx:alpine
COPY nginx.conf /etc/nginx/nginx.conf
COPY cert.pem /etc/nginx/cert.pem
COPY key.pem /etc/nginx/key.pem

web/nginx.conf:

worker_processes auto;
error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;
events {
    worker_connections  1024;
}
http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  /var/log/nginx/access.log  main;
    sendfile        on;
    #tcp_nopush     on;
    keepalive_timeout  65;
    #gzip  on;
    upstream php-handler {
        server app:9000;
    }
    server {
        listen 8443 ssl http2;
        ssl_certificate /etc/nginx/cert.pem;
        ssl_certificate_key /etc/nginx/key.pem;
        # Add headers to serve security related headers
        # Before enabling Strict-Transport-Security headers please read into this
        # topic first.
        #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
        #
        # WARNING: Only add the preload option once you read about
        # the consequences in https://hstspreload.org/. This option
        # will add the domain to a hardcoded list that is shipped
        # in all major browsers and getting removed from this list
        # could take several months.
        add_header Referrer-Policy "no-referrer" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header X-Download-Options "noopen" always;
        add_header X-Frame-Options "SAMEORIGIN" always;
        add_header X-Permitted-Cross-Domain-Policies "none" always;
        add_header X-Robots-Tag "none" always;
        add_header X-XSS-Protection "1; mode=block" always;
        # Remove X-Powered-By, which is an information leak
        fastcgi_hide_header X-Powered-By;
        # Path to the root of your installation
        root /var/www/html;
        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
        }
        # The following 2 rules are only needed for the user_webfinger app.
        # Uncomment it if you're planning to use this app.
        #rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
        #rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
        # The following rule is only needed for the Social app.
        # Uncomment it if you're planning to use this app.
        #rewrite ^/.well-known/webfinger /public.php?service=webfinger last;
        location = /.well-known/carddav {
            return 301 $scheme://$host:$server_port/remote.php/dav;
        }
        location = /.well-known/caldav {
            return 301 $scheme://$host:$server_port/remote.php/dav;
        }
        # set max upload size
        client_max_body_size 10G;
        fastcgi_buffers 64 4K;
        # Enable gzip but do not remove ETag headers
        gzip on;
        gzip_vary on;
        gzip_comp_level 4;
        gzip_min_length 256;
        gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
        gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
        # Uncomment if your server is build with the ngx_pagespeed module
        # This module is currently not supported.
        #pagespeed off;
        location / {
            rewrite ^ /index.php;
        }
        location ~ ^\/(?:build|tests|config|lib|3rdparty|templates|data)\/ {
            deny all;
        }
        location ~ ^\/(?:\.|autotest|occ|issue|indie|db_|console) {
            deny all;
        }
        location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+)\.php(?:$|\/) {
            fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
            set $path_info $fastcgi_path_info;
            try_files $fastcgi_script_name =404;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $path_info;
            # fastcgi_param HTTPS on;
            # Avoid sending the security headers twice
            fastcgi_param modHeadersAvailable true;
            # Enable pretty urls
            fastcgi_param front_controller_active true;
            fastcgi_pass php-handler;
            fastcgi_intercept_errors on;
            fastcgi_request_buffering off;
        }
        location ~ ^\/(?:updater|oc[ms]-provider)(?:$|\/) {
            try_files $uri/ =404;
            index index.php;
        }
        # Adding the cache control header for js, css and map files
        # Make sure it is BELOW the PHP block
        location ~ \.(?:css|js|woff2?|svg|gif|map)$ {
            try_files $uri /index.php$request_uri;
            add_header Cache-Control "public, max-age=15778463";
            # Add headers to serve security related headers (It is intended to
            # have those duplicated to the ones above)
            # Before enabling Strict-Transport-Security headers please read into
            # this topic first.
            #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
            #
            # WARNING: Only add the preload option once you read about
            # the consequences in https://hstspreload.org/. This option
            # will add the domain to a hardcoded list that is shipped
            # in all major browsers and getting removed from this list
            # could take several months.
            add_header Referrer-Policy "no-referrer" always;
            add_header X-Content-Type-Options "nosniff" always;
            add_header X-Download-Options "noopen" always;
            add_header X-Frame-Options "SAMEORIGIN" always;
            add_header X-Permitted-Cross-Domain-Policies "none" always;
            add_header X-Robots-Tag "none" always;
            add_header X-XSS-Protection "1; mode=block" always;
            # Optional: Don't log access to assets
            access_log off;
        }
        location ~ \.(?:png|html|ttf|ico|jpg|jpeg|bcmap|mp4|webm)$ {
            try_files $uri /index.php$request_uri;
            # Optional: Don't log access to other assets
            access_log off;
        }
    }
}

Dies steht so nahezu identisch in den offiziellen Beispielen des Nextcloud-Images, außer dass ich auch intern SSL verwenden möchte. Dementsprechend habe ich unter web/cert.pem und web/key.pem noch SSL-Zertifikate abgelegt, die ich über die OPNSense erstellt habe.

Erstellung einer internen CA und eines internen Server-Zertifikats

In der OPNSense Weboberfläche habe ich unter System > Trust > Authorities eine neue interne CA angelegt. Dies ist relativ selbsterklärend daher werde ich nicht näher darauf eingehen. Anschließend habe ich für meinen Server unter System > Trust > Certificates ein Zertifikat erstellt, welches mit der zuvor erstellten Authority signiert wurde. Zertifikat und Schlüssel können anschließend einfach über die Weboberfläche exportiert werden und entsprechend in die o.g. stellen auf dem Server eingefügt werden.

Erstellen eines podman Benutzers

Da ich die Container rootless betreiben wollte, benötigte ich noch einen Benutzer, unter dem die Container laufen sollen. Ich habe mich dazu entschieden, diesen einfach podman zu nennen:

groupadd podman
useradd -m -g podman -s /bin/bash -d `/mnt/pool/services/podman` podman

Wobei mein Festplattenraid unter /mnt/pool eingehangen ist und ich deshalb auch die Container dort hinlegen wollte.

Außerdem musste die Anzahl der User-Namespaces noch erhöht werden:

echo "user.max_user_namespaces=28633" > /etc/sysctl.d/userns.conf
sysctl -p /etc/sysctl.d/userns.conf

Systemd zum Starten von Nextcloud verwenden

Nun war Nextcloud bereit, gestartet zu werden. Es fehlte nur noch eine Systemd-Unit, damit dies auch beim Reboot des Servers automatisch funktioniert. Dazu habe ich folgende Unitfile unter /etc/systemd/system/compose@.service angelegt:

[Unit]
Description=%i service with podman-compose
[Service]
Restart=always
TimeoutStartSec=1200
User=podman
WorkingDirectory=/etc/containers/compose.d/%i
ExecStartPre=/usr/bin/podman-compose down
ExecStartPre=/usr/bin/podman-compose pull
ExecStart=/usr/bin/podman-compose up
ExecStop=/usr/bin/podman-compose down
[Install]
WantedBy=multi-user.target

Die Unitfile bedient sich der Interface-Funktion von Systemd, bei der %i gegen die Zeichenkette ersetzt wird, die hinter dem @ des Services angegeben wird. Die Nextcloud kann nun also folgendermaßen gestartet und aktiviert werden:

systemctl enable compose@nextcloud.service
systemctl start compose@nextcloud.service

Damit war die Einrichtung des Servers soweit abgeschlossen und nun konnte der Nginx Reverse-Proxy auf der OPNSense eingerichtet werden.

Einrichtung der OPNSense

Damit Nginx die Ports 80 und 443 nutzen kann, musste ich als erstes den Webkonfigurator auf einen anderen Port einstellen. Diese Einstellung ist in der Weboberfläche unter System > Settings > Administration zu finden:

Hier habe ich den TCP-Port auf 8443 geändert und den HTTP Redirect deaktiviert. Es zeigte sich, dass daraufhin ein Reboot der Firewall nötig ist, da die Ports ansonsten nicht freigegeben wurden.

Nun habe ich das Nginx Plugin unter System > Firmware > Plugins installiert.

Nginx Einrichtung

Unter Services erschien nun der neue Service Nginx, auf dessen Konfiguration ich nun eingehe.

Upstream Server und Upstream Konfiguration

Im Dropdown-Menü Upstream ließen sich nun Upstream-Server und Upstreams konfigurieren. Als erstes habe ich den Upstream-Server folgendermaßen konfiguriert:

Anschließend habe ich folgenden Upstream eingerichtet:

Hier musste ich unter Trusted Certificate die CA wählen, die ich zum Signieren des Server-Zertifikats verwendet habe.

Security Header konfigurieren

Nun bin ich unter HTTP(S) > Security Headers gegangen und habe dort für die Nextcloud Security Headers erstellt, die dem entsprechen, was in der Nextcloud-Dokumentation angegeben ist:

Erstellung einer Rewrite-Regel

Nextcloud braucht standardmäßig Rewrite-Regeln für Cal- und Carddav. Deshalb habe ich dafür unter HTTP(S) > URL Rewriting eine Regel angelegt:

Erstellung der Location

Nun habe ich eine Location für / erstellt:

Erstellung des HTTP-Servers

Zuletzt war nun alles vorbereitet um den eigentlichen HTTP-Server unter HTTP(S) > HTTP-Server anzulegen:

Ein entsprechendes Let’s Encrypt Zertifikat hatte ich zuvor bereits über das Let’s Encrypt Plugin erzeugt, welches ich sowieso bereits installiert und konfiguriert hatte. Dazu gibt es im Internet bereits brauchbare Anleitungen, weshalb ich darauf nicht weiter eingehe.

Wichtig: Mir ist später aufgefallen, dass mein Handy, das ich via DAVx mit Card- und Caldav verbinden wollte, ständig auf der Banlist aufgetaucht ist. Scheinbar wird DAVx durch die Bot Protection als Bot erkannt. Diese ließ sich in der Server Konfiguration in den Advanced Options deaktivieren:

Firewall Regeln erstellen

Damit der Nginx nun auch aus dem Internet erreichbar ist, müssen natürlich noch Firewall-Regeln für HTTP und HTTPS unter Firewall > Rules > WAN angelegt werden:

Schlusswort

Nun war alles soweit fertig konfiguriert. Unter General musste ich nun noch einmal auf Apply klicken und dann den Nginx-Service restarten und dann konnte ich auf meine Nextcloud auch von außen zugreifen.

Was in diesem Artikel nicht erwähnt wurde:

Ich habe zuvor für die Nextcloud einen DNS-Eintrag als CNAME auf die Adresse meiner Firewall angelegt.
Möchte man das OPNSense Webinterface weiterhin unter Port 443 erreichen, ist dies möglich, indem man im Nginx eine Proxy-Konfiguration für das Webinterface anlegt, die entsprechend auf ::1 zeigt. Hier ist nur zu beachten, dass dann auf jeden Fall darauf geachtet werden muss, ACLs zu erstellen, die den Zugriff auf das Webinterface auf den lokalen Adressraum einschränken.

Ich hoffe euch hilft der Artikel. Mir wird er auf jeden Fall helfen, falls ich dies irgendwann mal erneut aufsetzen muss.

Automatisches Löschen von Prosody-Usern

2019-07-30T00:00:00+02:00

Wer einen XMPP-Dienst hostet, bei dem die öffentliche Registrierung aktiviert ist, wird auf kurz oder lang vor dem Problem stehen, dass viele registrierte Benutzer existieren, die gar nicht mehr aktiv sind, oder nie aktiv waren. Möchte man nun Benutzer nach einem gewissen Zeitfenster der Inaktivität löschen, ist dies gar nicht so leicht umzusetzen, wenn man nicht vorgesorgt hat.

Speicherung von Aktivitätsdaten

Um eine solche Löschung zu ermöglichen ist es nötig, die Aktivitätsdaten der Benutzer erst einmal zu speichern und dann nach inaktiven Nutzern zu suchen. Dazu bietet Prosody zum Glück zwei passende Plugins an:

Löschung inaktiver Benutzer

Über mod_lastlog wird der timestamp des letzten Log-Ins der Benutzer gespeichert und über mod_list_inactive kann über diese gespeicherten Daten gesucht werden. Dazu habe ich mir folgendes Script geschrieben, das täglich via cron ausgeführt wird:

#!/bin/bash
WHITELIST=( foo@fusselkater.org )
for i in $(prosodyctl mod_list_inactive fusselkater.org 1month)
do
    if [[ ! " ${WHITELIST[@]} " =~ " ${i} " ]]
    then
        prosodyctl deluser $i
    fi
done

Dieses Script sucht also alle Benutzer von der Domain fusselkater.org, die länger als 1 Monat nicht online waren. Zusätzlich prüft es, ob der Benutzer sich nicht in der Whitelist befindet, damit z.B. der ein oder andere Service-Account nicht gelöscht wird.