Kategorie: Server

Freenas 11.1: integrierten OpenVPN-Client nutzen

Veröffentlicht am von Falk Jeromin

Seit einiger Zeit benutze ich zwei FreeNAS-Boxen an zwei Standorten, um meine Daten mittels ZFS-Snapshots und Replication zu sichern. Diese Verbindung soll zusätzlich mittels OpenVPN abgesichert werden.

Die Idee: an beiden Standorten jeweils ein Raspberry Pi, die miteinander über OpenVPN verbunden sind, dazu entsprechenden statische Routen, damit sich die beiden FreeNAS-Boxen erreichen können. Grundlage dafür ist der Ansatz, ein OpenVPN-Gateway aufzubauen. 

Aber: es geht auch einfacher. FreeNAS 11.1 verfügt über OpenVPN 2.4.3 und kann damit selbst Verbindungen zu OpenVPN-Servern aufbauen. Der Vorteil:  man benötigt kein komplexes Gateway-Setup, welches mit einem zweiten Raspberry Pi eine weitere Fehlerquelle mit sich bringt.

Die Einrichtung ist einfach: sobald man einen funktionierenden VPN-Server hat, kann man mittels der gängigen Befehle eine Verbindung aufbauen:

/usr/sbin/local/openvpn --config config.ovpn --daemon

Danach erreicht man den Server „am anderen Ende“ unter seiner gewohnten IP-Adresse, z.B. 192.168.178.45. Damit kann man die Replication-Tasks in FreeNAS konfigurieren, als wäre das Ziel im eigenen Netzwerk. Weiterer Vorteil: man benötigt beim Ziel nur einen offenen Port für das VPN und keinen weiteren für SSH. 

OpenVPN auf FreeNAS 11.1

Die Einrichtung des VPN-Servers auf dem Raspberry-Pi kann einfach mittels PiVPN erfolgen. Ich verwende die Raspi im Zielnetzwerk auch dafür, um den FreeNAS-Server zeitgesteuert einzuschalten – das spart Strom in der Zeit, in der eh keine Änderungen an Dateien vorgenommen werden. 

Nginx: IP-Adresse nicht in Log-Files speichern

Veröffentlicht am von Falk Jeromin

Wer aus Datenschutzgründen – DSGVO ist das Stichwort – möglichst wenige Daten speichern will, kann ein entsprechendes Logfile-Format definieren. Damit werden sowohl IPv4- als auch IPv6-Adressen anonymisiert.

Für die Error-Logs lässt sich leider kein neues Format definieren – hier kann man jedoch auch bei ausreichend kurzer Speicherfrist ein berechtigtes Interesse zum reibungslosen Betrieb annehmen. Die Einrichtung der anonymisierten Logfiles ist einfach: folgender Code wird in die zentrale nginx.conf eingefügt, dadurch werden bei IPv4-Adressen die letzten drei Ziffern durch „0“ ersetzt, bei IPv6-Adressen werden ebenfalls die letzten beiden Blöcke gelöscht.

map $remote_addr $ip_anonym1 {
default 0.0.0;
"~(?P<ip>(\d+)\.(\d+)\.(\d+))\.\d+" $ip;
"~(?P<ip>[^:]+:[^:]+):" $ip;
}

map $remote_addr $ip_anonym2 {
default .0;
"~(?P<ip>(\d+)\.(\d+)\.(\d+))\.\d+" .0;
"~(?P<ip>[^:]+:[^:]+):" ::;
}

map $ip_anonym1$ip_anonym2 $ip_anonymized {
default 0.0.0.0;
"~(?P<ip>.*)" $ip;
}

log_format anonymized '$ip_anonymized - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';

access_log /var/log/nginx/access.log anonymized;

Für die einzelnen Virtualhosts wird nun jeweils in der Access-Log-Zeile der Eintrag „anonymized“ hinzugefügt. Danach müssen einmal alle alten Logfiles gelöscht werden. Ab dem nächsten Server-Neustart werden dann die reduzierten Logfiles gespeichert, ansonsten funktioniert alles wie gewohnt. In Sachen Datenschutz ist man damit etwas näher an einer „sauberen Lösung“, die ganz im Sinne der EU-DSGVO-Datensparsamkeit ist. Diese Lösung wird auch auf diesem Server angewendet.

Raspberry Pi 3B+: Gigabit-LAN und 200 MHz mehr Takt

Veröffentlicht am von Falk Jeromin

Die Raspberry Foundation hat eine Überarbeitung des Raspberry 3 vorgestellt: das Modell 3B+. Mehr Takt und bessere Netzwerk-Anbindung sind die wesentlichen Merkmale.

RASPBERRY PI 3 MODEL B+ (Bild: Raspberry Foundation)
RASPBERRY PI 3 MODEL B+ (Bild: Raspberry Foundation)
Das Format ist das selbe geblieben, bestehende Projekte mit einem Raspberry Pi können einfach auf das neue Modell geupgraded werden – sofern der Takt, der beim neuen Modell auch unter Dauerlast höher ausfallen soll, der limitierende Faktor ist.

Die Daten im Überblick:

  • 1.4 GHz 64-bit quad-core ARM Cortex-A53 CPU (BCM2837B0)
  • Dual-band 802.11ac wireless LAN and Bluetooth 4.2 (BCM43455)
  • Faster Ethernet (Gigabit Ethernet over USB 2.0, LAN7515)
  • Power-over-Ethernet support (with separate PoE HAT)
  • Improved PXE network and USB mass-storage booting
  • Improved thermal management

Nach wie vor ist der Ethernet-Anschluss über USB-2.0 angebunden (LAN7515), was vor allem für Media-Player-Projekte ein limitierender Faktor sein kann. Zumindest wird eine höherer Bandbreite erreicht als bisher. Verbesserungen gibt es ebenfalls beim WLAN: der Funkchip BCM43455 unterstützt 2,4- und neu 5-GHz-Netzwerke, dazu Bluetooth 4.2.

Das neue Modell ist ab sofort verfügbar zum Preis des bisherigen Raspberry Pi 3B. Ein aktualisiertes Raspbian-Image steht ebenfalls bereits zum Download bereit. Wann eine wirkliche Weiterentwicklung in Form eines Raspberry Pi 4 auf den Markt kommt ist offen – vor 2019 wird dies wohl kaum passieren.

FreeNAS 11.1 erschienen

Veröffentlicht am von Falk Jeromin

Das auf FreeBSD basierende NAS-System FreeNAS ist in der neuen Version 11.1 erschienen, die etliche Neuerungen mit sich bringt.

Die Änderungen im Changelog betreffen OpenZFS, welches vor allem beim verarbeiten von Snapshots und großen Dateien schneller geworden sein soll. Außerdem wurde der Hardware-Support verbessert sowie Funktionen zum Cloud-Sync mit Amazon S3, Microsoft Azure Blob Storage, Backblaze B2 und Google Cloud Storage hinzugefügt. Dateien können ohne weiteres mit den genannten Diensten abgeglichen werden, was für Offsite-Backups sinnvoll ist. Viele Änderungen betreffen auch die Möglichkeiten für virtuelle Maschinen, angefangen bei Support für Nicht-US-Tastatur-Layouts bis hin zu RancherOS Docker-Instanzen.

Nach dem Corral-Experiment scheint FreeNAS noch einmal die Kurve gekriegt zu haben und ist wie gewohnt leicht zu installieren gewesen. Natürlich sollte beim bei OS-Updates auf einem NAS immer ein Backup zur Verfügung haben, in meinem Fall habe ich das zweite FreeNAS, welches die Daten spiegelt, noch nicht aktualisiert. FreeNAS 11.1 gibt es auf der Projekt-Seite zum Download, es werden 8 Gigabyte RAM empfohlen und ein 64-Bit-Prozessor ist pflicht.


FreeNAS: Pi-Hole & PiVPN in Ubuntu-VM

Veröffentlicht am von Falk Jeromin

Wer FreeNAS 11 als NAS- bzw. Homeserver-Software verwendet, kann pi-hole sowie pi-vpn verwenden und sowohl auf das eigene Netzwerk zugreifen als auch Werbung zuverlässig blockieren.

PiVPN (http://www.pivpn.io/) ist ein Installations- und Verwaltungsscript für OpenVPN. Eigentlich gedacht für die Verwendung auf einem Raspberry Pi, funktioniert die Installation auch ohne Probleme auf einem Ubuntu 17.04, welches in einer bhyve-VM läuft. Der Ablauf ist der selbe wie beim „Bastelrechner“:

curl -L https://install.pivpn.io | bash

Das Installationsscript beschwert sich zwar, dass die verwendete Linux-Version gegebenenfalls nicht kompatibel ist und verweigert das automatische konfigurieren von einigen Dingen, am Ende läuft aber alles soweit problemlos durch. Wichtig: damit das deutleiten der VPN-Verbindung klappt, muss unter Ubuntu die Firewall „ufw“ (uncomplicated firewall – ein Commandozeilen-Tool für das einfache Einstellen von iptables-Regeln) installiert sein und der entsprechende Port freigegeben sein.

FreeNAS: 9p Volume/Dataset in VM mounten

Veröffentlicht am von Falk Jeromin

Wer FreeNAS mit virtuellen Maschinen nutzt (ich habe z.B. die Entwicklungsumgebung für das Blog-Theme in einer Ubuntu-VM) wird früher oder später Daten des NAS nutzen wollen. FreeNAS bietet hier VT9P als Möglichkeit an.

Das Plan9-Filesystem benötigt ein paar mount-Optionen, die nicht dem Standard entsprechen. Zwar lässt es sich in der Console ohne weiteres mounten, sobald man es in die fstab einträgt, verlangt es einen etwas ausführlicheren Eintrag. Bei meinem Setup funktioniert:

data /mnt/data 9p rw,sync,dirsync,relatime,trans=virtio,version=9p2000.L 0 0

Damit wird das Volume „data“, welches in FreeNAS konfiguriert ist, am Mount „/mnt/data“ beim booten bereitgestellt.

FreeNAS: .AppleDouble / .DS_Store löschen

Veröffentlicht am von Falk Jeromin

Wenn man eine FreeNAS-Freigabe mit macOS benutzt, legt dieses verschiedene Finder-Metadaten-Verzeichnisse für jedes reguläre Verzeichnis an. Um ein Backup auf ein externes Medium möglichst schlank zu halten, können diese Daten gelöscht werden, was am leichtesten mittels eines Kommandos auf der Linux-Eingabeaufforderung geht:

find . -name ".Apple*" -type d -prune -exec rm -r {} +

Damit werden alle Verzeichnisse gelöscht, die mit „.Apple“ beginnen. Bei „.DS_Store“ handelt es sich um Dateien, sodass wir den obigen Befehl etwas abwandeln müssen:

find . -name ".DS_Store" -type f -prune -exec rm -r {} +

Auf gar keinen Fall mit Daten vor dem Backup ausprobieren.

Mein Setup ist so aufgebaut, dass die Daten erst mittel rsync auf ein Synology-NAS kopiert werden und von dort aus auf ein Amazon Drive. Auf dem Synology wird dann auch diese Bereinigung durchgeführt, um möglichst wenig Dateien übertragen zu müssen.

FreeNAS 10: „Corral“ erschienen

Veröffentlicht am von Falk Jeromin

Nach mehrjähriger Entwicklung ist nun die Version 10 von FreeNAS erschienen, Name: „Corral“.

iXsystems hat mit FreeNAS 10 „Corral“ eine neue Version des beliebten Betriebssystem für Selbstbau-NAS-Systeme veröffentlicht. Die Oberfläche wurde komplett überarbeitet und kommt jetzt deutlich moderner daher, der Unterbau ist ebenfalls modernisiert worden.

Linux Mint als virtuelle Maschine in FreeNAS Corral
Linux Mint als virtuelle Maschine in FreeNAS Corral
Statt wie bisher auf Erweiterungen durch Plugins zu setzen, gibt es nun Support für virtuelle Maschinen (worüber auch Windows als Gast ausgeführt werden kann) und Docker-Container, womit die Auswahl an Software-Erweiterungen deutlich vergrößert wurde. Damit sind auch die Systemanforderungen etwas gestiegen, wobei gegenüber FreeNAS 9.10.x der Sprung nicht so groß ist. Wer z.B. auf einen HP Microserver Gen8 setzt, sollte zumindest mit dem Maximalausbau von 16 GB RAM und einer schnelleren CPU (der CPU-Tausch ist sehr einfach) arbeiten.

HP Microserver Gen8: CPU-Tausch

Veröffentlicht am von Falk Jeromin

Wer einen HP Microserver Gen8 kauft, setzt meist auf das Einstiegsmodell mit Celeron G1610T-Prozessor. Da die CPU gesockelt ist, kann sie einfach ausgetauscht werden.

HP Microserver Gen8: Celeron G1610T
Der Celeron G1610T ist eine Dualcore-CPU mit 2,3 GHz Takt und einer TDP von 35 Watt – daher lässt sie sich ohne Problem passiv kühlen. Wichtig ist es, eine passende CPU zum Tausch zu finden.

Nach etwas Recherche, unter anderem im sehr guten Sammelthread des Hardwareluxx-Forum fiel meine Wahl auf einen Core i5 3470T: 2 Kerne, 2,9 GHz Basistakt und Hyperthreading-Support (4 Threads). Die TDP liegt ebenfalls bei 35 Watt, sodass das selbe Kühlsystem zum Einsatz kommen kann.

Let’s encrypt: Fallstricke bei Domainwechsel

Veröffentlicht am von Falk Jeromin

Vor einiger Zeit habe ich die Domain meines Blogs gewechselt – von www.kadder.de auf www.techblogger.net. Dabei gab es einen Fallstrick durch die Verwendung von Let’s encrypt.

Der Ansatz: beim Wechsel der Domain soll natürlich von der alten Domain auf die neue weitergeleitet werden. Das Problem: läuft das Zertifikat der alten Domain ab, führen SSL-Aufrufe zu einem Zertifikatsfehler. Dadurch gehen dann auch Rankings und Besucher verloren, die bisher die alte Seite aufgerufen haben.

Nach einigen Experimenten mit den Nginx-Weiterleitungs-Regeln (um zu verhindern, dass das Verzeichnis .well-known, welches für die webroot-Zertifizierung von Let’s encrypt benötigt wird auf die neue Domain umgeleitet wird) ist die Lösung doch naheliegend.

Um die automatische Aktualisierung des Zertifikats weiterhin nutzen zu können (eine sehr gute Anleitung dafür gibt es bei Digitalocean) ist ein Ansatz die Erweiterung des bestehenden Zertifikats für die neue Domain. Dieses muss zusätzlich auch die bisherige Domain beinhalten.

Ist das erledigt, wird für die alte Domain das gleiche Zertifikat konfiguriert wie für die Neue, mit dem Ergebnis dass die Weiterleitungen auch wieder für SSL-Verbindungen funktionieren.