Ich persönlich finde S3 Speicher sehr angenehm und versuche ihn für verschiedene Anwendungsbereiche zu verwenden. Heute habe ich mir wieder einen extra Server installiert und möchte den Prozess hiermit quasi dokumentieren. Mit dieser Anleitung installieren wirMinio (externer Link) auf einem Debian 12 (Bookworm) System. Dazu verwenden wir direkt nginx als Reverse Proxy und sichern das mittels Let’s encrypt Zertifikaten ab, sodass immer eine gesicherte Verbindung aufgebaut werden kann.

Was ist S3 Speicher?

S3-Speicher bezieht sich auf Amazon Simple Storage Service, kurz Amazon S3. Es handelt sich dabei um einen skalierbaren Cloud-Speicherdienst von Amazon Web Services (AWS). S3 ermöglicht es Benutzern, große Datenmengen sicher und kostengünstig in der Cloud zu speichern. Ein Objektspeicher ist eine Art von Datenspeicher, der darauf ausgelegt ist, große Mengen unstrukturierter Daten in Form von Objekten zu speichern. Jedes Objekt besteht aus Daten, Metadaten und einem eindeutigen Identifikator. Im Fall von S3 werden diese Objekte in sogenannten “Buckets” organisiert, die als virtuelle Container dienen, um die Objekte zu gruppieren.

Installation von Minio

Anlegen des Nutzers und Gruppe

Mittlerweile gibt es extra Paket fürDebian (externer Link) und Ubuntu sodass sich die Installation etwas mehr vereinfacht. Minio sollte natürlich nicht im Kontext des root-Nutzers laufen. Best practise ist hier, sich einen eigenen Nutzer anzulegen. Du kannst natürlich auch gerne schon einen vorhanden verwenden.

groupadd -r minio-useruseradd -M -r -g minio-user minio-user

Wie geschrieben kannst du die Parameter auch entsprechend anpassen. Bedenke aber, dass die Anleitung davon ausgeht, dass du die Nutzer und Gruppe genau so genannt wurden.

Datenverzeichnis vorbereiten

Als nächstes solltest du dir noch Gedanken machen wohin auf deinem System die Daten abgelegt werden sollen. In meinem Fall lege dich diese nach/opt ab. Zuerst wird das Verzeichnis angelegt und anschließend bekommt unser Minio Nutzerminio-user das Verzeichnis als Besitzer zugeordnet.

mkdir -p /opt/miniochown minio-user:minio-user /opt/minio

Minio Paket installieren

Glücklicherweise gibt es Minio mittlerweile auch als fertiges Paket, sodass wir uns um diverse Dinge keine Gedanken machen müssen. Dies beinhaltet nämlich mittlerweile auch einensystemd Skript um das Programm sauber darüber starte und stoppen zu können. Zuerst laden wir uns das Paket erst einmal runter. Sehr wahrscheinlich ist die verlinkte Version schon veraltet wenn du dieses Tutorial liest. Schaue als bitter malhier (externer Link) welche die aktuelle Version ist und ersetze die Versionnummer.

wget https://dl.min.io/server/minio/release/linux-amd64/archive/minio_20240217011557.0.0_amd64.deb -O minio.deb

Sollte dein System aus irgendwelchen Gründen den Befehlwget nicht kennen kannst du den mittels

apt install wget -y

installieren.

Nun brauchen wir nur noch Minio zu installieren und haben schon einen großen Teil erledigt.

dpkg -i minio.deb

Nach ein paar Sekunden ist das ganze auch schon fertig und wir können anfangen das Programm zu konfigurieren.

Standardkonfiguration für Minio anlegen

Wir nutzen in diesem Tutorial eine recht einfache Konfiguration. Diese kannst du natürlich immer noch nach weiterem belieben erweitern wenn du möchtest. Wir legen uns also die Default Konfiguration an

touch /etc/default/minio

und bearbeiten diese. Ich verwende immervim als Editor. Du kannst natürlich auch gernenano verwenden wenn dir das lieber ist.

vim /etc/default/minio

Darin kopieren wir jetzt folgende Zeilen

# Definition des Admin Accounts
MINIO_ROOT_USER=myminioadmin
MINIO_ROOT_PASSWORD=minio-secret-key-change-me
# MINIO_VOLUMES setzt das Verzeichnis in dem unsere Daten gespeichert werden
MINIO_VOLUMES="/opt/minio"
# Damit wir auch die Konsole bzw. Webfrontend verwenden können, müssen wir das natürlich noch setzen
MINIO_OPTS="--console-address :9001"

Bitte pass entsprechendMINIO_ROOT_USER undMINIO_ROOT_PASSWORD an und lasse die Werte nicht auf default setzen. Auch wenn du das System nicht nach außen hin veröffentlichst, sollten niemals Standardzugangsdaten verwendet werden.

Minio starten und Login

Nun starten wir Minio erst einmal um zu sehen ob alles funktioniert. Zudem sollten wir uns auch einmal anmelden um auch das gegengetestet zu haben.

systemctl enable miniosystemctl start minio

Nun öffnen wir einen Browser und navigieren zu{HOSTIP}:9001 und sollten anschließend so ein Bild sehen. Bitte anschließend einmal einloggen um zu sehen, dass auch deine Zugangsdaten korrekt funktionieren.

nginx als Rervse Proxy mit Zertifkat einrichten

Ich verwende in dem TutorialCerbot zum generieren des Let’s encrypt Zertifikates. Zudem wird mein öffentliches DNS meiner Domain von Cloudflare betrieben. Entsprechend verwende ich hier diedns-challenge mit Cloudflare und API Token.

Cloudflare API Token generieren

Auf der Cloudflare Profilseite gibt es den PunktAPI Tokens (externer Link) (Generischer Link dorthin). Dort legen wir uns rechts oben ein neuen Token an und verwenden das TemplateEdit Zone DNS. Du solltest nun ungefähr dieses Bild hier sehen. Den Bereich Permissions lassen wir so wie er ist. Im BereichZone Resources müssen wir im letzten drop down Feld in der Reihe nur noch die entsprechende Domain auswählen. Den Rest können wir mitContinue to summary ebenfalls auslassen. Auf der nächsten Seite bestätigen wir mitCreate Token und nun wird uns unser Token angezeigt. Ich empfehle diesen sicher abzuspeichern falls du den später noch mal für andere Dinge verwenden möchtest.

Pakete installieren

Nun zurück zu unserer Linux Maschine. Wir können hier nun endlich alle benötigten Pakete installieren die wir brauchen.

apt install nginx certbot python3-certbot-dns-cloudflare

Dies benötigt ein paar Sekunden und wir können weiter machen uns unser Zertifikat zu besorgen.

Let’s encrypt Zertifikat mit Certbot beantragen

Zuerst richten wir noch die Punkte für die DNS Challenge zu Cloudflare ein. Dazu erstellen wir uns ein Verzeichnis

mkdir -p /etc/certbot

und legen uns dort eine Datei an

touch /etc/certbot/credentials

in diese kommt nun unser Cloudflare Token. Also editieren wir die Datei

vim /etc/certbot/credentials

und kopieren folgendes dort rein

dns_cloudflare_api_token={DEIN_CLOUDFLARE_API_TOKEN}

Damit die Datei nicht von jedem Nutzer auf dem System gelesen werden kann, passen wir noch die Berechtigungen mittels

chmod600 /etc/certbot/credentials

an. Nun haben wir den Grundstock gelegt um das Zertifikat beantragen zu können. Beachte jetzt, dass du die Domain entsprechend an deine Domain anpassen musst.

certbot certonly --dns-cloudflare --dns-cloudflare-credentials /etc/certbot/credentials -d minio.example.com -d s3.example.com

nginx einrichten

Nun können wir uns mit dem Thema nginx als reverse proxy für minio beschäftigen. Die Software wurde bereits oben schon installiert, also können wir direkt mit der Konfiguration der Seite beginnen. Dazu wechseln wir in das Konfigurationsverzeichnis für die Webseiten

cd /etc/nginx/sites-available

Dort legen wir dann die Seitenkonfiguration an

touch minio.conf

und können dann auch diese im Anschluss bearbeiten

vim minio.conf

Dort kannst du dann folgendes rein kopieren:

## API End Point
server
{
# Listen
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
# Directory & Server Naming
server_name s3.example.com;
# HTTP to HTTPS redirection
if ($scheme != "https")
{
return 301 https://$host$request_uri;
}
# SSL
ssl_certificate /etc/letsencrypt/live/minio.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/minio.example.com/privkey.pem;
# Disable Hidden FIle Access Except Lets Encrypt Verification
location ~ /\.well-known
{
allow all;
}
# Allow special characters in headers
ignore_invalid_headers off;
# Allow any size file to be uploaded.
# Set to a value such as 1000m; to restrict file size to a specific value
client_max_body_size 0;
# Disable buffering
proxy_buffering off;
proxy_request_buffering off;
location /
{
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_connect_timeout 300;
# Default is HTTP/1, keepalive is only enabled in HTTP/1.1
proxy_http_version 1.1;
proxy_set_header Connection "";
chunked_transfer_encoding off;
proxy_pass http://127.0.0.1:9000;
}
# Nginx Logging
access_log /var/log/nginx/s3.example.com-access.log;
error_log /var/log/nginx/s3.example.com-error.log warn;
}
###################### Console ######################
server
{
# Listen
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
# Directory & Server Naming
server_name minio.example.com;
# HTTP to HTTPS redirection
if ($scheme != "https")
{
return 301 https://$host$request_uri;
}
# SSL
ssl_certificate /etc/letsencrypt/live/minio.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/minio.example.com/privkey.pem;
# Disable Hidden FIle Access Except Lets Encrypt Verification
location ~ /\.well-known
{
allow all;
}
# Allow special characters in headers
ignore_invalid_headers off;
# Allow any size file to be uploaded.
# Set to a value such as 1000m; to restrict file size to a specific value
client_max_body_size 0;
# Disable buffering
proxy_buffering off;
proxy_request_buffering off;
location /
{
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-NginX-Proxy true;
proxy_connect_timeout 300;
# To support websocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
chunked_transfer_encoding off;
proxy_pass http://127.0.0.1:9001;
}
# Nginx Logging
access_log /var/log/nginx/minio.example.com-access.log;
error_log /var/log/nginx/minio.example.com-error.log warn;
}

Bitte beachte, dass du überall dasexample.com durch deine eigene Domain austauschst. Die Konfiguration habe ich vonhier (externer Link) übernommen und ein wenig angepasst.

Jetzt legen wir noch den symlink an

ln /etc/nginx/site-available/minio.conf /etc/nginx/site-enabled/

und sollten testen ob wir auch kein Fehler gemacht haben. Das können wir am einfachsten mittels

nginx -t

Hier sollte keine Ausgabe erscheinen. Andernfalls müstest du die angezeigten Fehler noch verbessern. Zu guter letzt können wir nginx neu starten

systemctl restart nginx

Jetzt kannst du auch Minio über https über deine Domainnamen erreichen. Solltest du Minio nur im lokalen Netzwerk verwenden, denk daran, dass noch im DNS entsprechend zu hinterlegen.

Optional: Minio Admin Cli installieren

Gegebenenfalls brauchst du zu einem späteren Zeitpunkt mal die Admin CLI von Minio. Also solltest du diese direkt mit installieren. Diese ist ein einfaches binary das wir nur auf das System kopieren müssen.

curl https://dl.min.io/client/mc/release/linux-amd64/mc -o /usr/local/sbin/mc

Allerdings wird es ohne Execute Rechte nicht ausgeführt werden können, also fügen wir diese noch hinzu

chmod +x /usr/local/sbin/mc

Anschließend könntest du mittelsmc den Minio Server auch via CLI administrieren.

Fazit

In meinemKubernetes Cluster verwende ich Minio um daraufBackups abzulegen die mittelsvolsync (externer Link) erstellt wurden. Ebenso verwendet Thanos den S3 Speicher als Langzeitspeicher um die Prometheus Daten lange aufzuheben.

Solltest du Fragen zu dem Tutorial haben, kannst du mich gerne über eine der im Blog angegebenen Netzwerke erreichen.

In den letzten Jahren habe ich immer wieder aus verschiedenen Gründen die Blogsoftware gewechselt. Dieses Mal bin ich von Wordpress zu Jekyll umgezogen. Mein Vorgehen und Gründe möchte ich in diesem Beitrag erläutern.

Was ist Jekyll?

Jekyll ist eine Blogsoftware bzw. ein sogenannter Static Site Generator. Primär wird Jekyll von GitHub Pages verwendet. Die meisten Tutorials die man so im Internet finden beziehen auch genau darauf. Grundlegend baut die Software Markdown-Dateien zu statischen HTML Dateien um diese mit einem einfachen Webserver ausliefern zu können. Im bequemsten Fall sogar mit dem integriertem.

Gründe für meinen Wechsel

Gründe könnten mannigfaltig sein. Schlussendlich läuft es aber darauf hinaus, dass Wordpress immer mächtiger wird. Das hat seine Vor- und Nachteile. Sicherlich ist es sehr praktisch für jeden Anwendungsfall Wordpress verwenden zu können, denn die verschiedenen Plugins und Themes machen das möglich. Viele großen Webseiten basieren auf Wordpress und mit dem notwendigen Know-How und Ressourcen lassen sich auch sehr Performance Webseiten bauen. Der Nachteil der Erweiterbarkeit liegt entsprechend auch in der Pflege und den Bemühungen einen guten Wert für den LCP zu erreichen. Mir ist es im Laufe der Zeit nicht gelungen einen guten Wert zu erreichen. Am HosterNetcup (externer Link) liegt es nicht, da ich hier auch verschiedene ausprobiert habe. Zudem bin ich im Moment dabei mich von verschiedenen großen Softwareprodukten zu trennen und auf freiere Software zu setzen.

In der Webentwicklung steht LCP für “Largest Contentful Paint”. Es handelt sich um eine wichtige Metrik für die Ladeleistung einer Webseite. LCP misst die Zeit, die benötigt wird, um den größten sichtbaren Inhalt im Viewport eines Nutzers während des Seitenladens zu rendern. Ein guter LCP-Wert ist wichtig, um sicherzustellen, dass Webseiten schnell und reibungslos geladen werden und Benutzer eine bessere Erfahrung haben. {:.note title=“Was ist LCP?”}

Installation von Jekyll

Die Installation von Jekyll kann unter verschiedenen Betriebssystemen durchgeführt werden. Allerdings ist Windows nicht mit dabei. Wenn man allerdings den Umweg über WSL2 geht, kann man der regulären Linux Installation für die verwendete Linux-Distribution folgen. In dieser Anleitung gehe ich erst mal auf die Installation unter MacOS ein, da ich persönlich dieses Betriebssystem verwende. Alternative Installationen finden sich natürlich in der offiziellen Dokumentation. Gern kann dort diese entsprechend verwendet werden.

Installation unter MacOS

Installation des Paketmanagers brew

MacOS Nutzer haben in der Regel schon den Paketmanagerbrew installiert. Falls du das noch nicht getan hast, lässt sich das mittels

/bin/bash -c"$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

erledigen. Grundsätzlich sollte aber immer beim Ausführen von Programmen direkt aus dem Internet vorsichtig sein! Sobald das erledigt ist, brauchen wir jetzt den Ruby Installer denn Jekyll ist in der entsprechenden Programiersprache geschrieben.

Installation von ruby

brew install chruby ruby-install xz

Dies kann durchaus ein paar Minuten dauern, das ist nicht ungewöhnlich. Nun installieren wir noch ruby selbst.

ruby-install ruby 3.2.2

Beachte, dass die Version 3.2.2 die zum Zeitpunkt des Artikels die aktuellste Version ist, dass kann zum jetzigen Zeitpunkt anders sein. Der nächste Schritt ist, dass wir ruby und die ganzen Environment Variablen noch aktivieren und in die MacOS Konfiguration speichern

echo"source$(brew --prefix)/opt/chruby/share/chruby/chruby.sh" >> ~/.zshrcecho"source$(brew --prefix)/opt/chruby/share/chruby/auto.sh" >> ~/.zshrcecho"chruby ruby-3.2.2" >> ~/.zshrc# run 'chruby' to see actual version

Installation von Jekyll

Endlich kommen wir zu dem Punkt, dass wir Jekyll selbst installieren können.

gem install jekyll

Auch der Schritt kann einige Zeit lang brauchen. Anschließend haben wir Jekyll installiert.

Jekyll Webseite anlegen

Sobald wir also eine lauffähige Version von Jekyll haben, können wir nun eine Webseite anlegen. Wir suchen uns also einen entsprechenden Ordner aus in dem die Installation durchgeführt werden soll. Ich mache sowas immer in einem Unterordner in meinem Homeverzeichnis.

cd ~

Den Namen den wir im install Befehl mitgeben wird auch der Name des Ordners sein. Natürlich kann der Prozess beliebig oft ausgeführt werden, falls euch das nicht gefällt.

jekyll new blog

Es entsteht dann eine ungefähr solche Ausgabe

Running bundle install in /Users/teqqy/blog... Bundler: Fetching gem metadata from https://rubygems.org/............ Bundler: Resolving dependencies... Bundler: Fetching rouge 4.1.3 Bundler: Installing rouge 4.1.3 Bundler: Bundle complete!7 Gemfile dependencies,33 gems now installed. Bundler: Use`bundle info[gemname]` to see where a bundled gem is installed.New jekyll site installed in /Users/teqqy/blog.[21:31:33][cost 3.162s] jekyll new blog

Nun wechseln wir in das Verzeichnis und gucken mal was so für Dateien und Ordner dort hinterlegt sind.

[21:32:50][~/blog] ❱❱❱ ls -ltotal48-rw-r--r--1 teqqy staff41931 Jul 21:31 404.html-rw-r--r--1 teqqy staff130931 Jul 21:31 Gemfile-rw-r--r--1 teqqy staff205231 Jul 21:31 Gemfile.lock-rw-r--r--1 teqqy staff207931 Jul 21:31 _config.ymldrwxr-xr-x3 teqqy staff9631 Jul 21:31 _posts-rw-r--r--1 teqqy staff53931 Jul 21:31 about.markdown-rw-r--r--1 teqqy staff17531 Jul 21:31 index.markdown

Wie man sieht, sind das nicht viele Dateien. Nun sollten wir die_config.yml anpassen. Die Begriffe sollten selbsterklärend sein. Die Werte sind aber erst mal keine Pflicht. Um jetzt die HTML Dateien bauen zu lassen verwenden wir folgenden Befehl

jekyll serve

Es erscheinen diverse Fehlermeldungen und Warnungen auf Grund von veralteten Abhängigkeiten. Leider sind diese immer noch nicht sauber gefixt. Die letzte Ausgabe sollte etwas in der Art von

Run in verbose mode to see all warnings.done in 0.401 seconds. Auto-regeneration: enabledfor'/Users/teqqy/blog' Server address: http://127.0.0.1:4000/ Server running... press ctrl-c to stop.

Enthalten. Jetzt könnt ihr euren Browser öffnen und die URLhttp://127.0.0.1:4000 verwenden.

Wir brechen dann wieder den laufenden Server mitCTRL-C ab. Wenn wir jetzt nochmal die Verzeichnisse auflisten sehen wir, dass dort ein neuer Ordner_site erstellt worden ist.

[21:40:43][~/blog] ❱❱❱ ls -ltotal48-rw-r--r--1 teqqy staff41931 Jul 21:31 404.html-rw-r--r--1 teqqy staff130931 Jul 21:31 Gemfile-rw-r--r--1 teqqy staff205231 Jul 21:31 Gemfile.lock-rw-r--r--1 teqqy staff207931 Jul 21:31 _config.ymldrwxr-xr-x3 teqqy staff9631 Jul 21:31 _postsdrwxr-xr-x8 teqqy staff25631 Jul 21:35 _site-rw-r--r--1 teqqy staff53931 Jul 21:31 about.markdown-rw-r--r--1 teqqy staff17531 Jul 21:31 index.markdown

Dieser Ordner ist nun schlussendlich das wichtige. Dieser kann auf einen Webserver kopiert und ausgeliefert werden.

Webseite bereitstellen

Viele Tutorials im Internet verwenden denjekyll serve Befehl um die Webseite auszuliefern und richten einen Webserver wie NGINX oder apache2 als reverse proxy ein. Dies ist allerdings nicht der vom Hersteller empfohlene Weg. Ich für meinen Teil habe das Verzeichnis auf meinen Webserver kopiert und liefere es mit einem Nginx Docker-Container aus. Dieser hat entsprechende Traefik Labels, welches sich um die Zertifikate etc kümmert. Sicherlich kein Setup für jeden.

Nginx Docker Container

Meine verwendetedocker-compose.yaml Datei kannst du natürlich übernehmen wenn du möchtest. Du müsstest nur die Werte entsprechend anpassen.

---version:"3.8"services:nginx:image:nginxcontainer_name:nginxvolumes:-./_site:/usr/share/nginx/html-./nginx.conf:/etc/nginx/conf.d/www_nginx.conflabels:-"traefik.enable=true"-"traefik.http.middlewares.nginx-https.redirectscheme.scheme=https"-"traefik.http.middlewares.nginx-compress.compress=true"-"traefik.http.routers.nginx-http.entrypoints=web"-"traefik.http.routers.nginx-http.rule=Host(`www.example.com`) || Host(`example.com`)"-"traefik.http.routers.nginx-http.middlewares=teqqy-https@docker"-"traefik.http.routers.nginx.entrypoints=websecure"-"traefik.http.routers.teqqy.rule=Host(`www.example.com``) || Host(`example.com``)"-"traefik.http.routers.nginx.tls=true"-"traefik.http.routers.nginx.tls.certresolver=default"-"traefik.http.routers.nginx.middlewares=secHeaders@file"-"traefik.http.routers.nginx.middlewares=teqqy-compress"-"traefik.http.services.nginx.loadbalancer.server.port=80"networks:-teqqywp-traefik_proxynetworks:traefik_proxy:external:name:traefik_proxyteqqywp:driver:bridge

Nginx Konfiguration

Ich binde noch eine eigenenginx.conf Datei ein in der ich noch Anpassungen für Caching und anderes mache.

server {
listen 80;
server_name example.com www.example.com
root /usr/share/nginx/html;
index index.html index.htm;
if (!-f "${request_filename}index.html") {
rewrite ^/(.*)/$ /$1 permanent;
}
if ($request_uri ~* "/index.html") {
rewrite (?i)^(.*)index\.html$ $1 permanent;
}
if ($request_uri ~* ".html") {
rewrite (?i)^(.*)/(.*)\.html $1/$2 permanent;
}
error_page 404 /404.html;
location / {
try_files $uri $uri.html $uri/ =404;
}
location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
expires 30d;
add_header Pragma public;
add_header Cache-Control "public";
}
# reduce the data that needs to be sent over network -- for testing environment
gzip on;
# gzip_static on;
gzip_min_length 10240;
gzip_comp_level 1;
gzip_vary on;
gzip_disable msie6;
gzip_proxied expired no-cache no-store private auth;
gzip_types
# text/html is always compressed by HttpGzipModule
text/css
text/javascript
text/xml
text/plain
text/x-component
application/javascript
application/x-javascript
application/json
application/xml
application/rss+xml
application/atom+xml
font/truetype
font/opentype
application/vnd.ms-fontobject
image/svg+xml;
# allow the server to close connection on non responding client, this will free up memory
reset_timedout_connection on;
# request timed out -- default 60
client_body_timeout 10;
# if client stop responding, free up memory -- default 60
send_timeout 2;
# server will close connection after this time -- default 75
keepalive_timeout 30;
# number of requests client can make over keep-alive -- for testing environment
keepalive_requests 100000;
}

Nun kann der Container gestartet werden und nach kurzer Zeit könnt ihr die Seite über die angegebene URL aufrufen.

Wordpress Daten exportieren

Für den Export habe ich das Wordpress PluginWordpress to Jekyll Exporter (externer Link) verwendet. Es nicht das beste Plugin aber für mich hat es gereicht. In Wordpress können wir dann unterWerkzeuge den Export ausführen und bekommen eine ZIP-Datei zum Download. Die Inhalte können wir direkt in unser Jekyll Verzeichnis kopieren und die Seiten neu genierieren lassen.

jekyll serve

Nun können wir den Ordner_site wieder auf unseren Webserver kopieren. Den Container müssen wir nicht neu starten, denn nginx liefert die Dateien direkt aus. Ein einfacher reload im Browser reicht dafür aus.

Jekyll anapssen

Jetzt liegt es an euch, Jekyll entsprechend den Bedürfnissen anzu passen. Heißt ein Theme herunter zu laden oder mit Plugins zu erweitern.

Da mir dieses „ständige“ ändern der TXT-Records im DNS einfach zu mühsam ist, habe ich meine Homelab Domain zu Cloudflare als DNS-Provider umgezogen. Normalerweise betreibe ich ja alle anderen Domains unter eigenen Nameservern allerdings ist mir ein direktes Plugins für PowerDNS nicht bekannt.

Für einen Umzug der Nameserver ist dies entsprechend bei dem Unternehmen umzusetzen bei dem ihr auch eure Domain gehostet habt. In meinem Fall ist dasNetcup (externer Link) (übrigens sehr zu empfehlen). Bis die Umstellung schlussendlich vollzogen ist, kann es bis zu 48 Stunden dauern. Geduld ist also hier gefragt.

Mein reverse Proxy läuft unterDebian 9 (alias Stretch). Auf diesem installieren wir als erstesNGINX (externer Link) aus den offiziellen Paketquellen. Die Debian Pakete sind meist etwas veraltet und ich hätte gerne bei solchen Anwendungen immer die neusten Sicherheitsupdates eingespielt. Zudem arbeite ich in diesem Fall als root, solltet ihr als „normaler“ User arbeiten, ist vor die Befehle ein sudo zu setzen.

NGINX Installation

wget http://nginx.org/keys/nginx_signing.keyapt-key add nginx_signing.key

Die Paketquellen müssen noch in eine apt-Datei hinzugefügt werden. Ich lege mir, der Übersichtlichkeit halber, eine neue an und editiere nicht die vorhandenen.

nano /etc/apt/sources.list.d/nginx.list

Dort fügt ihr folgende Zeilen ein:

deb http://nginx.org/packages/debian/ stretch nginxdeb-src http://nginx.org/packages/debian/ stretch nginx

Anschließend aktuallisieren wir die Paketquellen und installierenNGINX (externer Link) .

apt update&& apt install nginx -y

Da wir es später eh noch brauchen, werden wir direkt noch dieDeffie Hellmann (externer Link) Signatur anlegen. Hierzu wechseln wir ins SSL Verzeichnis des Systems

cd /etc/ssl/certs

Anschließend erstellen wir die PEM-Datei

openssl dhparam -out dhparams.pem2048

Let’s Encrypt Zertifikate

Um die Let’s encrypt Zertifikate auch anfordern zu können, werden wir noch Certbot installieren. Hier bedienen wir uns der Backports Paketquellen von Debian. Diese müssen ebenfalls noch hinzugefügt werden. Ich nehme hierfür die backports.list

deb http://ftp.debian.org/debian stretch-backports main

Auch jetzt aktuallisieren wir wieder die Paketquellen und installieren die notwendigen Pakete

apt install python-certbot-nginx python-certbot-dns-cloudflare -y -t stretch-backports

Die Authentifizierung gegen Cloudflare erfolgt mittels Email-Adresse und API-Key. Letzteren bekommt ihr in eurer Accountverwaltung von Cloudflare. Wir legen uns einen Ordner an in dem wir dann schlussendlich eine Datei setzen werden die unsere Zugangsdaten beherbergt.

mkdir -p ~/.secrets/certbot

In diesem Ordner erstellen wir dann die Datei cloudflare.ini in die folgender Inhalt kommt:

# Cloudflare API credentials used by Certbotdns_cloudflare_email = cloudflare@example.comdns_cloudflare_api_key = 0123456789abcdef0123456789abcdef01234567

Natürlich müsst ihr die zwei Werte entsprechend euren Zugangsdaten anpassen. Anschließend schrenken wir noch die Rechte auf die Datei ein

chmod600 ~/.secrets/certbot/cloudflare.ini

Wenn eure Domain vollständig umgezogen ist, könnt ihr mit folgendem Befehl nun ein Wildcard Zertifikat von Let’s encrypt anfordern

certbot certonly --dns-cloudflare --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini -i nginx -d"*.example.com" -d example.com --server https://acme-v02.api.letsencrypt.org/directory

Natürlich müsst ihr noch die Domain auf eure gewählte umschreiben. Ist alles richtig konfiguriert und hat Cloudflare das DNS Setup schon vollständig übernommen, wird nun das Zertifikat ausgestellt.

NGINX Reverse Proxy

Als letztes kümmern wir uns darum die Weiterleitung einer Anfrage an den externen Webserver weiter zu reichen. Unter der aktuellen Debian Version speichertNGINX (externer Link) seine Konfigurationsdateien unter

/etc/nginx/conf.d

Entsprechend legen wir dort eine neue Datei an. Ich benennen diese Dateien immer nach der eigentlichen Domain, sodass für mich eine schnelle Zuordnung der Konfigurationsdateien möglich ist.

Die Konfiguration im Detail ist nicht von mir, sondern von diesem GIST aus abgeleitet. Ich habe nur ein paar Abänderungen vorgenommen, dass diese auf mein System passen.

server {
listen 80;
server_name www.example.com example.com;
return 301 https://$host$request_uri;
}
# SSL configuration
server {
listen 443 ssl;
server_name www.example.com example.com;
ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;
# Improve HTTPS performance with session resumption
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
# Enable server-side protection against BEAST attacks
ssl_prefer_server_ciphers on;
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
# Disable SSLv3
ssl_protocols TLSv1.2;
# Diffie-Hellman parameter for DHE ciphersuites
# $ sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096
ssl_dhparam /etc/ssl/certs/dhparams.pem;
# Enable HSTS (https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security)
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
# Enable OCSP stapling (http://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox)
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s; # Required for LE certificate enrollment using certbot
location '/.well-known/acme-challenge' {
default_type "text/plain";
root /var/www/html;
}
location / {
proxy_pass http://{IPDEINESWEBSERVERS};
}
}

Anschließend testen wir die Konfiguration mittels

nginx -t

Sollte alles in Ordnung sein, starten wirNGINX neu und gehen somit mit unserer neuen Konfiguration live.

systemctl restart nginx

Wenn alles korrekt gelaufen ist, könnt ihr nun eure Webseite, geschützt durch das Zertifikat, erreichen. Sollte das nicht der Fall sein, könnt ihr im error.log entsprechende Fehler finden und diese bereinigen.

Ich hatte mir für dieses Jahr fest vorgenommen ein Wildcard Zeritifkat zu kaufen. Die Erstellung von einzelnen Zertifikaten ist nämlich sehr unpraktisch. Glücklicherweise hatLet’s Encrypt (externer Link) vor einiger Zeit Wildcard Zertfiakte entwickelt und der Öffentlichkeit frei gegeben.

Mit ein paar kleinen Anpassungen am DNS konnte ich schon das erste Zertifikat mit Certbot erstellen. Natürlich sollte hier immer die neuste Version genommen werden.

Die Anpassung derNGINX (externer Link) Konfigurationsdateien war ein Kinderspiel, zumal meist nur die Subdomain im Dateinamen des Zertifikates entfernt werden musste. EinmalNGINX neu geladen und mittels SSLLabs getestet: Alles Super!

Anschließend konnte ich auch die alten Zertifikate revoken. Das ist einfach sauberer als sie auslaufen zu lassen. Man weiß ja nie…

Im Laufe der letzten Tage sind dann immer mehr Dienste hinzugekommen, welche ich nun mittels einer sauberen URL zugänglich gemacht habe. Viele Dinge müssen nicht unbedingt von extern erreichbar sein, macht sich allerdings spätestens dann bezahlt, wenn ich einmal von extern ohneVPN Anschluss daheim etwas erledigen möchte – auch wenn es nur bugfixing ist.

Ich empfehle jedem der mehrere Einzelzertifikate mit Let’s encrypt nutzt diese umzustellen. Es ist viel angenehmer wenn man einen neuen Service einrichtet und diesen von außen zugänglich machen möchte.