DecaTec https://decatec.de Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie Sat, 28 Mar 2020 09:27:30 +0000 de-DE hourly 1 Jitsi Meet: Videokonferenz-System unter Ubuntu Server mit nginx https://decatec.de/home-server/jitsi-meet-videokonferenz-system-unter-ubuntu-server-mit-nginx/ https://decatec.de/home-server/jitsi-meet-videokonferenz-system-unter-ubuntu-server-mit-nginx/#comments Sat, 21 Mar 2020 14:09:21 +0000 https://decatec.de/?p=6465 Jitsi Logo

Videokonferenzen werden heutzutage immer wichtiger. Im geschäftlichen Umfeld kommen hier meist proprietäre Lösungen wie z.B. Skype zum Einsatz. In Sachen Datenschutz und Privatsphäre sind diese Lösungen natürlich bedenklich.

Die bessere Alternative kann hier Jitsi Meet sein. Dies ist eine quelloffene Software, mit der Videokonferenzen mit mehreren Teilnehmern durchgeführt werden können.

Der folgende Artikel zeigt die Installation und Konfiguration von Jitsi Meet unter Ubuntu Server mit nginx als Webserver.

Update-Historie (letztes Update: 28.03.2020)
  • 28.03.2020:
    • Weitere Hinweise zur Verwendung eines eigenen STUN-Servers (coturn) hinzugefügt.

Voraussetzungen/Ziele

Zum Thema Jitsi Meet gibt es bereits unzählige Tutorials im Netz. Diese beziehen sich aber meist nur auf die Standard-Installation und es wird meist auch nicht explizit auf die Webserver-Konfiguration eingegangen. Das Augenmerk auf die (sichere) Webserver-Konfiguration ist meiner Meinung allerdings sehr wichtig, v.a. wenn auf dem Server bereits andere Anwendungen gehostet werden.

Darüber hinaus schlägt die Installation unter Ubuntu Server 18.04 u.U. manchmal fehl. Hier gilt es dann einige Besonderheiten zu beachten.

Dabei kommen folgende Programm-Versionen zum Einsatz:

  • Ubuntu Server 18.04 LTS („Bionic Beaver“).
  • nginx 1.17.9 (aktuelle Mainline-Version).

Dieses Tutorial konzentriert sich dabei v.a. auf Jitsi Meet. Eine komplette Beschreibung der Webserver-Konfiguration (nginx, Let’s Encrypt/acme.sh) würde sicherlich den Rahmen des Artikel sprengen. Daher gehe ich im folgenden davon aus, dass auf dem System nginx bereits installiert und eingerichtet ist. Ebenfalls sollte alles vorbereitet sein, dass TLS-Zertifikate über Let’s Encrypt ausgestellt werden können.

Wichtig: nginx muss vor der Installation von Jitsi Meet bereits auf dem System vorhanden sein, da das Jitsi-Setup darauf aufbaut und virtuelle Hosts anlegt.

Im Rahmen des Tutorials nutze ich die beispielhafte Domain meet.meinedomain.de für die Jitsi Meet Installation.

Vorbereitungen

Nun kann es auch schon an die Installation gehen.

Betriebssystem-Updates

Vor der eigentlichen Installation wird das System zunächst auf den neusten Stand gebracht:

apt update && apt upgrade -V && apt dist-upgrade && apt autoremove
reboot

Anpassungen nginx

Wichtig: nginx ist meistens so konfiguriert, dass die virtuellen Hosts unter /etc/nginx/conf.d geladen werden. Das Setup von Jitsi Meet geht allerdings davon aus, dass die virtuellen Hosts unter /etc/nginx/sites-available bzw. /etc/nginx/sites-enabled zu finden sind. Daher müssen diese Verzeichnisse manuell angelegt werden, falls diese noch nicht vorhanden sind:

mkdir -p /etc/nginx/sites-available
mkdir -p /etc/nginx/sites-enabled

Wird dieser Schritt nicht ausgeführt, schlägt das Setup von Jitsi Meet später fehl!

Domain/TLS-Zertifikate

Wie bereits erwähnt, nutzen wir für den Artikel die fiktive (Sub-)Domain meet.meinedomain.de.

Für diese Domain sollten vor dem Jitsi-Setup bereits Zertifikate über Let’s Encrypt beantragt werden. Folgende Artikel sollten dazu einen guten Anhaltspunkt geben:

Die folgende Konfiguration wird RSA- und ECDSA-Zertifikate (Hybrid-Betrieb) mit TLSv1.2/TLSv1.3 nutzen.

Auflösung der Domain auf localhost

Auf dem Server, auf dem Jitsi Meet installiert werden soll, muss die verwendete Domain auf localhost auflösen. Dies wird in der Hosts-Datei konfiguriert:

nano /etc/hosts

Ganz unten wird nun folgender Eintrag hinzugefügt:

127.0.0.1 meet.meinedomain.de

Installation Jitsi Meet

Als nächstes kann es an die eigentliche Installation von Jitsi Meet gehen.

Jitsi Meet – Setup

Da das Programm (noch) nicht in den offiziellen Ubuntu Paketquellen enthalten ist, müssen wir das Repository zunächst einbinden.

Dazu wird als erstes der Repository-Key im System importiert:

wget -qO -  https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -

Anschließend kann das Repository eingebunden werden:

echo 'deb https://download.jitsi.org stable/' >> /etc/apt/sources.list.d/jitsi-stable.list

Nun werden die Paketquellen noch aktualisiert:

apt update

Es folgt die eigentliche Installation:

apt install jitsi-meet

Während der Installation wird man zuerst nach der Domain gefragt, unter der Jitsi Meet gehostet werden soll. Dies ist die Domain, für das vorher schon das TLS-Zertifikat ausgestellt wurde – in diesem Beispiel also meet.meinedomain.de.

Jitsi Meet Setup: Eingabe der Domain

Jitsi Meet Setup: Eingabe der Domain

Als nächstes wird noch nach dem Zertifikat gefragt: Hier muss die zweite Option gewählt werden (I want to use my own certificate), da wir die Zertifikate selbst verwalten wollen (siehe oben).

Jitsi Meet Setup: Verwendung eigener Zertifikate

Jitsi Meet Setup: Verwendung eigener Zertifikate

Nun wird man noch nach dem Speicherort der Zertifikats-Dateien gefragt. Diese beiden Dialoge (einmal für die *.key und einmal für die *crt-Datei) kann einfach mit OK bestätigt werden. Die Zertifikate werden im Anschluss manuell im virtuellen Host von nginx hinzugefügt.

Jitsi Meet Setup: Pfad zu den Zertifikats-Dateien

Jitsi Meet Setup: Verwendung eigener Zertifikate

Das Setup sollte anschließend ohne Probleme durchlaufen.

Jitsi Meet – Anpassen des virtuellen Hosts (nginx)

Das Setup hat nun im Verzeichnis /etc/nginx/sites-available einen neuen virtuellen Host erstellt und einen symbolischen Link in /etc/nginx/sites-enabled hinzugefügt. Da wir an dieser Stelle die Verzeichnisse sites-availabe und sites-enabled nicht verwenden, wird die Datei hier entfernt und in das passende Verzeichnis verschoben:

rm /etc/nginx/sites-enabled/meet.meinedomain.de.conf
mv /etc/nginx/sites-available/meet.meinedomain.de.conf /etc/nginx/conf.d/meet.meinedomain.de.conf

Den Webserver noch nicht neu starten, erst bedarf es noch Anpassungen am vHost für Jitsi Meet.

nano /etc/nginx/conf.d/meet.meinedomain.de.conf

Diese Datei wird nun folgendermaßen bearbeitet (alle Änderungen sind hier markiert):

server_names_hash_bucket_size 64;

#server {
#    listen 80;
#    server_name meet.meinedomain.de;
#    return 301 https://$host$request_uri;
#}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name meet.meinedomain.de;

    #
    # SSL configuration
    # 

    # RSA certificates
    ssl_certificate /etc/letsencrypt/meet.meinedomain.de/rsa/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/meet.meinedomain.de/rsa/key.pem;
    # ECC certificates
    ssl_certificate /etc/letsencrypt/meet.meinedomain.de/ecc/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/meet.meinedomain.de/ecc/key.pem;

    # This should be ca.pem (certificate with the additional intermediate certifica$
    # See here: https://certbot.eff.org/docs/using.html
    # ECC
    ssl_trusted_certificate /etc/letsencrypt/meet.meinedomain.de/ecc/ca.pem;

    # SSL stapling has to be done seperately, becuase it will not work with self signed certs
    # OCSP Stapling fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;

    # Diffie-Hellman parameter for DHE ciphersuites, recommended 4096 bits
    ssl_dhparam /etc/nginx/dhparams/dhparams.pem;

    # Not using TLSv1 will break:
    # Android <= 4.4.40 IE <= 10 IE mobile <=10
    # Removing TLSv1.1 breaks nothing else!
    ssl_protocols TLSv1.2 TLSv1.3;

    # SSL ciphers: RSA + ECDSA
    # Two certificate types (ECDSA, RSA) are needed.
    ssl_ciphers 'TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384';
    
    # Use multiple curves.
    ssl_ecdh_curve secp521r1:secp384r1;

    # Server should determine the ciphers, not the client
    ssl_prefer_server_ciphers on;

    # Add your DNS resolver here
    resolver 192.168.178.1;

    # SSL session handling
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;


    #ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    #ssl_prefer_server_ciphers on;
    #ssl_ciphers ssl_ciphers "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED";
    #add_header Strict-Transport-Security "max-age=31536000";
    #ssl_certificate /etc/jitsi/meet/meet.meinedomain.de.crt;
    #ssl_certificate_key /etc/jitsi/meet/meet.meinedomain.de.key;

    # 
    # Headers
    #

    # HSTS (ngx_http_headers_module is required) In order to be recoginzed by SSL test, there must be an index.hmtl in the server's root
    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload;" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Robots-Tag none always;
    add_header X-Download-Options noopen always;
    add_header X-Permitted-Cross-Domain-Policies none always;
    add_header Referrer-Policy no-referrer always;
    #add_header X-Frame-Options "SAMEORIGIN" always;

    # Remove X-Powered-By, which is an information leak
    fastcgi_hide_header X-Powered-By;


    root /usr/share/jitsi-meet;
    ssi on;
    index index.html index.htm;
    error_page 404 /static/404.html;

    location = /config.js {
        alias /etc/jitsi/meet/meet.meinedomain.de-config.js;
    }

    location = /external_api.js {
        alias /usr/share/jitsi-meet/libs/external_api.min.js;
    }

    #ensure all static content can always be found first
    location ~ ^/(libs|css|static|images|fonts|lang|sounds|connection_optimization|.well-known)/(.*)$
    {
        add_header 'Access-Control-Allow-Origin' '*';
        alias /usr/share/jitsi-meet/$1/$2;
    }

    # BOSH
    location = /http-bind {
        proxy_pass      http://localhost:5280/http-bind;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $http_host;
    }

    # external_api.js must be accessible from the root of the
    # installation for the electron version of Jitsi Meet to work
    # https://github.com/jitsi/jitsi-meet-electron
    location /external_api.js {
        alias /srv/jitsi-meet/libs/external_api.min.js;
    }

    location ~ ^/([^/?&:'"]+)$ {
        try_files $uri @root_path;
    }

    location @root_path {
        rewrite ^/(.*)$ / break;
    }
}

Erklärungen zu den einzelnen Änderungen:

  • Zunächst wird der virtuelle Host für HTTP (Port 80) deaktiviert/auskommentiert. Dieser wird nicht benötigt, da dieser schon in einer anderen Datei vorhanden ist (sonst hätte ja die Erzeugung der TLS-Zertifikate über Let’s Encrypt vorher nicht geklappt).
  • Es folgen die Einstellungen für SSL. Die vom Jitsi Meet Setup eingefügten Zeilen wurden hier wieder auskommentiert und durch eigene optimierte Anweisungen ersetzt (RSA- und ECDSA-Zertifikate im Hybrid-Betrieb).
  • Wichtig ist hier noch die Angabe eines (DNS-)Resolvers (resolver 192.168.178.1). Hier ist die IP-Adresse eines DNS-Servers anzugeben (in diesem Beispiel die IP-Adresse des Routers, da dieser als DNS-Server fungiert).
  • Anschließend werden noch Header gesetzt, die für eine sichere Webserver-Konfiguration empfohlen sind.
  • Weiter unten wurde noch ein weiterer location-Block hinzugefügt. Dieser sorgt dafür, dass die externe API von Jitsi Meet verfügbar ist. Dies wird zur Nutzung der Desktop-Clients/mobilen Apps von Jitsi Meet benötigt.

Nun wird der Webserver neu gestartet:

service nginx restart

Zum Schluss müssen ein paar benötigte Ports in der Firewall freigeschaltet werden (in diesem Beispiel nutze ich die Firewall ufw):

ufw allow http
ufw allow https
ufw allow 4443/tcp
ufw allow in 10000/udp

Falls eine andere Firewall genutzt wird, ist diese entsprechend zu konfigurieren. Denkt auch daran, dass das Port-Forwarding ggf. auch im Router konfiguriert werden muss (Ports 80, 443, 4443, Protokoll: TCP und Port 10000, Protokoll: UDP).

Diese Ports müssen übrigens auch bei den Clients geöffnet sein (nur für ausgehenden Traffic!).

Konfiguration Jitsi Meet

Jitsi Meet läuft nun mit Standard-Einstellungen. Diese können (und sollten) aber noch weiter optimiert werden.

Konfiguration alternativer STUN-Server

Jitsi Meet benötigt für einen stabilen Betrieb sog. STUN-Server. Dies ist eine Technologie, die Verbindungen durch Router/Firewalls ermöglicht. Hier nutzt Jitsi in der Standard-Konfiguration STUN-Server von Google. Aus Sicht des Datenschutzes ist dies natürlich bedenklich und sollte geändert werden.

Dazu wird einfach die entsprechende Konfiguration geöffnet:

nano /etc/jitsi/meet/meet.meinedomain.de-config.js

Hier sucht man nun nach der Stelle, an der die STUN-Server hinterlegt sind:

stunServers: [
   { urls: 'stun:stun.l.google.com:19302' },
   { urls: 'stun:stun1.l.google.com:19302' },
   { urls: 'stun:stun2.l.google.com:19302' }
],

Die Verweise auf die Google-Server sind hier zu entfernen und durch andere STUN-Server ersetzt werden. Eine Liste mit öffentlichen STUN-Servern findet man z.B. hier.

Tipp: coturn ist ein TURN-/STUN-Server, der mit wenig Aufwand installiert werden kann. Dies habe ich bereits im Artikel Nextcloud Talk mit eigenem TURN-Server (coturn) beschrieben. Diese Anleitung bezieht sich zwar auf Nextcloud Talk (eine andere Konferenz-Lösung), kann aber auch für Jitsi Meet genutzt werden. Wenn ihr bereits eine eigene coturn-Instanz für Nextcloud Talk aufgesetzt habt, könnt ihr diese natürlich nun auch für Jitsi Meet verwenden.

Damit der STUN-Server ordnungsgemäß funktioniert, muss noch eine weitere Port-Freigabe hinzugefügt werden:

ufw allow in 3478/udp

Ein konkretes Beispiel für den entsprechenden Eintrag in der Jitsi Meet Konfiguration würde dann so aussehen (wenn der STUN-Server über die Domain stun.meinedomain.de erreichbar ist):

stunServers: [
            { urls: 'stun:stun.meinedomain.de:3478' }
        ],

Test des eigenen STUN-Servers: Um den eigenen STUN-Server zu testen, kann diese Seite gnutzt werden. Unter STUN or TURN URI wir dann folgendes eingegeben: stun:stun.meinedomain.de:3478

Nach einem Klick auf Gather candidates sollte das Ergebnis dann in etwa so aussehen:

Ergebnisse des STUN-Server Tests

Ergebnisse des STUN-Server Tests

Wichtig sind dabei, dass die Einträge vom Typ „srflx“ angezeigt werden.

Öffentlichen Zugang unterbinden („Secure Domain“)

Jitsi Meet ist nun so konfiguriert, dass jeder, der die URL des Servers kennt, beliebig viele Konferenz-Räume erstellen kann. Dies ist u.U. nicht gewünscht, da man den Server z.B. nur privat verwenden möchte. In diesem Fall kann man Jitsi Meet so konfigurieren, dass neue Konferenz-Räume nur mit einem Benutzernamen und Passwort erstellt werden können.

Wer seine Instanz öffentlich betreiben möchte, muss die folgenden Schritt nicht ausführen.

Dazu ist zunächst eine Anpassungen in folgender Datei nötig:

nano /etc/prosody/conf.avail/meet.meinedomain.de.cfg.lua

Hier werden sog. virtuelle Hosts definiert (nicht zu verwechseln mit den virtuellen Hosts von nginx). Der erste virtuelle Host wird nun so eingestellt, dass eine Authentifizierung erforderlich ist:

VirtualHost "meet.meinedomain.de"
    authentication = "internal_plain"

Am Ende der Datei wird dann ein weiterer virtueller Host hinzugefügt:

VirtualHost "guests.meet.meinedomain.de"
    authentication = "anonymous"
    c2s_require_encryption = false

Als nächstes wird der neue virtuelle Host der Jitsi Meet Installation bekannt gemacht:

nano /etc/jitsi/meet/meet.meinedomain.de-config.js

Unter der Angabe der eigentlichen Domain wird nun die Domain des zuvor angelegten virtuellen Hosts als „anonyme Domain“ hinterlegt:

hosts: {
        // XMPP domain.
        domain: 'meet.meinedomain.de',

        // When using authentication, domain for guest users.
        anonymousdomain: 'guests.meet.meinedomain.de',

Nun muss noch eine weitere Datei bearbeitet werden:

nano /etc/jitsi/jicofo/sip-communicator.properties

Hier fügen wir einfach nur eine Zeile ein:

org.jitsi.jicofo.auth.URL=XMPP:meet.meinedomain.de

Nun folgt noch ein wichtiger Punkt: Das Hinzufügen von Benutzername und Passwort zum Erstellen neuer Konferenz-Räume. Dazu einfach folgenden Befehl direkt in die Kommandozeile eingeben:

prosodyctl register JitsiAdmin meet.meinedomain.de 'mEinPAssw0rt'

JitsiAdmin ist in diesem Beispiel der Benutzername, mEinPAssw0rt das dazugehörige Passwort.

Nach den Änderungen an der Konfiguration von Jitsi Meet sind nun noch die entsprechenden Services neu zu starten:

service prosody restart
service jicofo restart
service jitsi-videobridge restart

Nutzung von Jitsi Meet

Die eigene Instanz kann nun einfach im Browser genutzt werden: https://meet.meinedomain.de.

Hinweis: Es gibt momentan wohl noch kleinere Probleme mit neueren Versionen von Firefox. Daher wird offiziell die Verwendung von Chrome/Chromium empfohlen.

Jitsi Meet im Browser

Jitsi Meet im Browser

Als erstes sollte eine Blick in die Einstellungen geworfen werden (Zahnrad oben rechts).
Unter Profil kann ein Name und eine E-Mail-Adresse hinterlegt werden. Der Name wird dann in den Konferenzen angezeigt. An Hand der E-Mail-Adresse wird versucht, per Gravatar ein Avatar für den Benutzer anzuzeigen.

Einstellungen Jitsi Meet

Einstellungen Jitsi Meet

Ebenso kann hier die Sprache der Oberfläche angepasst werden. Nach einem Klick auf OK werden die Einstellungen gespeichert.

Ein Konferenzraum kann nun durch Eingabe des Names für das Meeting und einen Klick auf Los gestartet werden. Der Browser fragt dann, ob man Zugriff auf Mikrofon/Kamera erlauben möchte. Dies sollte man bestätigen, ansonsten macht es ja für Video-Konferenzen wenig Sinn.

Der Konferenz-Raum wird dann noch nicht sofort erstellt, sondern es erscheint eine Meldung mit der Frage nach dem Organisator (dieser Schritt belibt aus, wenn ihr nicht die „Secure Domain“ konfiguriert habt, s.o.):

Jitsi Meet fragt nach dem Organisator

Jitsi Meet fragt nach dem Organisator

Erst nach einem Klick auf „Ich bin der Organisator“ und der Eingabe von Benutzername und Passwort, welches wir weiter oben konfiguriert haben, wird der Raum eröffnet.

Nun präsentiert sich Jitsi Meet mit einer aufgeräumten Oberfläche. Der folgende Screenshot zeigt dabei alle wichtigen Elemente.

Die Oberfläche von Jitsi Meet

Die Oberfläche von Jitsi Meet

Damit andere Leute nun an der Konferenz teilnehmen können, wird einfach der Link auf die Konferenz benötigt (Schaltfläche unten rechts). Ein konkreter Link könnte dann so aussehen: https://meet.meinedomain.de/MeinMeeting

Hier kann auch gleich ein Passwort für die Konferenz eingetragen werden, damit nicht jeder anonyme Benutzer der Konferenz beitreten kann.

Die Benutzung via Browser stellt vermutlich die einfachste Möglichkeit dar. Allerdings gibt es auch Clients für die unterschiedlichsten Plattformen, siehe Jitsi Download-Seite.

Hinweise für Remote Control: Für die Fernsteuerung von Rechnern (ähnlich Teamviewer), muss ein spezieller Desktop-Client („Jitsi Meet Electron“) auf dem fernzusteuernden Rechner genutzt werden. Dieser kann bei GitHub herunter geladen werden. Der Teilnehmer, der die Bedienung remote übernehmen möchte, kann allerdings auch per Browser an der Konferenz teilnehmen.

Fazit

Die eigene Videokonferenz-Lösung aufzusetzen ist mit Jitsi Meet gar nicht so schwer und innerhalb von kürzester Zeit erledigt. Lediglich die individuellen Anpassungen/Absicherungen gehen ein wenig mehr ins Detail.

Man bekommt dafür eine Lösung für Videokonferenzen, die aus Sicht von Privatsphäre und Datenschutz um einiges besser ist als proprietäre Konferenz-Software eines Unternehmens.

Wie steht es bei euch? Nutzt ihr regelmäßig Audio-/Video-Konferenzen? Habt ihr vielleicht schon eure eigene Jitsi Meet Instanz aufgesetzt? Was sind eure Erfahrungen?
Hinterlasst mir dazu doch einfach einen Kommentar.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/jitsi-meet-videokonferenz-system-unter-ubuntu-server-mit-nginx/feed/ 24
Windows Server Advanced Power Management: Version 1.6.2 https://decatec.de/software/windows-server-advanced-power-management/windows-server-advanced-power-management-version-1-6-2/ https://decatec.de/software/windows-server-advanced-power-management/windows-server-advanced-power-management-version-1-6-2/#respond Sun, 15 Mar 2020 15:12:53 +0000 https://decatec.de/?p=6462 Windows Server Advanced Power Management Logo

Windows Server Advanced Power Management v1.6.2 steht ab sofort zum Download bereit.

Dieses Update behebt einen kleinen Fehler, der beim Importieren von Einstellungen auftreten konnte.

Änderungen in Version 1.5.4

  • BUGFIX: Beim Importieren von Einstellung mit geplanten Aufwach-Zeiten konnte es u.U. zu einem Fehler kommen, so dass die Einstellungen nicht richtig geladen werden konnten.
  • Update-Check verbessert.
  • .NET Framework 4.6.2 (oder neuer) muss installiert sein.
  • Update der verwendeten Software-Pakete.
  • Die folgenden Windows-Versionen werden offiziell nicht mehr unterstützt: Windows XP, Windows 7, Windows Server 2003, Windows Server 2008, Windows Home Server 2011

Update

Am einfachsten wird das Update über die integrierte Update-Funktion im Programm heruntergeladen und installiert.
Hinweis: Es kann sein, das bei alten Versionen des Programms hier eine Fehlermeldung erscheint. In diesem Fall muss das Update einfach manuell installiert werden.

Die neue Version kann alternativ auch einfach über eine bestehende Version installiert werden. Die Einstellungen bleiben dabei erhalten.

Weitere Informationen, Download und Benutzerhandbuch:
Windows Server Advanced Power Management

Links

]]>
https://decatec.de/software/windows-server-advanced-power-management/windows-server-advanced-power-management-version-1-6-2/feed/ 0
Backup-Strategie für Linux-Server mit Borg Backup https://decatec.de/linux/backup-strategie-fuer-linux-server-mit-borg-backup/ https://decatec.de/linux/backup-strategie-fuer-linux-server-mit-borg-backup/#comments Fri, 29 Nov 2019 08:31:28 +0000 https://decatec.de/?p=6094 Logo Backup

Wer einen eigenen (Home-)Server betreibt, sollte sich auf jeden Fall Gedanken über Backups machen. Spätestens, wenn wichtige Dateien mal unbeabsichtigt gelöscht wurden, kann man froh sein, wenn man auf Backups zurück greifen kann.

Deshalb möchte ich an dieser Stelle meine Backup-Strategie für Linux-Server vorstellen. Diese basiert hauptsächlich auf dem Programm Borg Backup und wird ergänzt durch eigene Backup-Skripte.

Als Betriebssystem kommt hier Ubuntu Server 18.04 zum Einsatz, das Gezeigte kann allerdings auch auf anderen Distributionen umgesetzt werden.

Die Inspiration zu dieser Tutorial stammt aus einem Artikel von Thomas Leister: Borg Backup für Serversicherungen. Ich habe diese Strategie jedoch an meine Bedürfnisse angepasst.
Genau dies solltet ihr übrigens auch machen: Jeder hat hier individuelle Anforderungen, daher wird es nicht die eine Lösung geben. Daher könnt ihr die hier gezeigte Lösung/Skripte als Vorlage nehmen, die ihr dann an eure eigenen Bedürfnisse anpasst.

Borg Backup

Den größten Teil der Arbeit übernimmt das Programm Borg Backup. Dies ist ein Backup-Programm, welches einige Vorteile bietet:

  • Kompression: Die Backups werden komprimiert.
  • Verschlüsselung: Die Backups können verschlüsselt werden.
  • Deduplizierung: Bei mehreren aufeinander folgenden Backups werden nur die inkrementellen Änderungen gesichert. Wenn mit dem ersten Backup beispielsweise 1 GB Daten gespeichert wurden und es ändern sich darauf hin nur 100 MB, dann werden im folgenden Backup nur diese 100 MB an Daten gesichert.

Durch die Verschlüsselung ist die Sicherheit der Backups gewährleistet, so dass man diese auch z.B. auf einem FTP-Server im Internet sichern könnte.
Durch die Verschlüsselung und Deduplizierung sind die Backups recht kompakt und werden schnell angefertigt.

Um Borg Backup zu installieren, bringen wir das System erst einmal auf den aktuellen Stand:

apt update && apt upgrade -V && apt dist-upgrade && apt autoremove

Anschließend kann Borg Backup installiert werden:

apt install borgbackup

Nun kann es schon an die Einrichtung des Backups gehen.

Backup einrichten

Übersicht

Zunächst ein paar Worte zum grundsätzlichen Vorgehen.

Ziel ist ein Backup-Skript, welches alle wichtigen Teile des Systems sichert:

  • Wichtige Dateien und Verzeichnisse.
  • Komplette Anwendungen.

Unter kompletten Anwendungen verstehe ich hier ein komplettes Backup einer Anwendung, welches grundsätzlich auch erst mal für sich allein angefertigt werden kann. Als Beispiel für eine solche Anwendung dient im Rahmen dieses Artikels Nextcloud, eine selbst gehostete Cloud-Lösung. Wie ein Backup von Nextcloud angefertigt werden kann, habe ich bereits im Artikel Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript beschrieben. Das Skript, welches im Rahmen dieses Artikels erstellt wurde, kann nun für das komplette Backup des Servers wiederverwendet werden.

Jedoch kann auch jede beliebige andere Anwendung mittels des Server-Backup-Skripts gesichert werden: Weitere Beispiele wären hier z.B. FHEM, oder auch ein Firefox Sync-Server.

Das grundsätzliche Vorgehen sieht nun so aus, dass zunächst alle zu sichernden Anwendungen einzeln auf einen temporären Speicherort gesichert werden. Anschließend werden diese einzelnen Backups zusammen mit den zu sichernden Verzeichnissen des Systems an Borg Backup für die Gesamt-Sicherung übergeben. Anschließend werden die temporären Backups der Anwendungen wieder gelöscht.

In diesem Zusammenhang ist es nur wichtig, dass keine Teile des Systems doppelt gesichert werden. Wenn z.B. das Web-Verzeichnis (meist unter /var/www zu finden) gesichert werden soll, ist bei der Übergabe an Borg Backup das Nextcloud-Verzeichnis (unter /var/www/nextcloud) vom Backup auszuschließen, da dies ja schon durch die Nextcloud-Sicherung gespeichert wurde.

Individuelle Sicherung von Anwendungen

Zunächst beschäftigen wir uns mit dem Backup einzelner Anwendungen. Wie bereits erwähnt, dient hier Nextcloud als Beispiel-Anwendung, die es nun zu sichern gilt. Dieses Thema wurde hier bereits im Blog mit dem Artikel Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript behandelt. Aus diesem Grund sei hier auf das dazugehörige Bash-Skript verwiesen, welches auf Codeberg verfügbar ist: Nextcloud Backup Restore

Wenn andere Anwendungen gesichert werden sollen, empfiehlt es sich, hier ebenfalls ein gesondertes Skript anzufertigen. Als weiteres Beispiel sei an dieser Stelle WordPress erwähnt (WordPress: Backups erstellen und wiederherstellen – manuell oder per Skript). Das dazugehörige Bash-Skript ist ebenfalls auf Codeberg verfügbar: WordPress Backup Restore

Borg Repository einrichten

Vor der Erstellung des Backup-Skripts muss noch das sog. Borg-Repository angelegt werden. In diesem Beispiel erfolgt dies auf einer zweiten internen HDD (/media/hdd2). Es kann aber auch ein beliebiges anderes Verzeichnis sein (z.B. ein per fstab gemountetes NAS). Das Repository wird dabei mit folgenden Befehlen angelegt:

mkdir -p /media/hdd2/server_backup/borg
borg init -e repokey-blake2 /media/hdd2/server_backup/borg

Beim Angelgen wird nach einem Passwort gefragt. Dieses sollte ein ausreichend sicheres Passwort sein. Dieses Passwort sollte man sich auch gut merken, denn ohne das Passwort kann kein Zugriff auf die Backups erfolgen. Am besten speichert es man sich gleich in einem Passwort-Safe (wie z.B. KeePass ab).

Der Befehl zum Initialisieren eines Repositories bietet noch weitere Optionen. So ist es auch möglich, die Verschlüsselung mittels einer Schlüssel-Datei zu realisieren. Eine genaue Beschreibung zum Initialisieren von Borg-Repositories ist in der offiziellen Dokumentation zu finden.

Auch wenn es möglich ist, ein Repository ohne Verschlüsselung anzulegen, rate ich davon ab. Die Verschlüsselung sollte beim Initialisieren immer verwendet werden.

Backup-Skript erstellen

Wie sämtliche Skripte speichere ich auch die Backup-Skripte im Verzeichnis /home/<user>/scripts. Hier wird erst einmal das Skript selbst erstellt:

nano /home/user/scripts/server_backup.sh

Der Inhalt sieht dann wie folgt aus:

#!/bin/bash

#
# Backup Script for Linux servers
#
# This script needs to be customized to fit your needs. Most important are the folder and applications which should be part of the backup.
# The folders to backup are specified in the variable $borgBackupDirs (see below)
# Besides these folders, Nextcloud (https://nextcloud.com/) is taken as example for an additional web application which should be included in the backup. 
#
# Required software and scripts:
# 	- Borg Backup (https://www.borgbackup.org/)
# 	- When Nextcloud backup should be included: Nextcloud Backup/Restore scrips (https://codeberg.org/DecaTec/Nextcloud-Backup-Restore)
#
# Remarks
# 	- The borg repository has to be set up before the script is called.
#
# IMPORTANT
# You have to customize this script (directories, users, etc.) for your actual environment.
# All entries which need to be customized are tagged with "TODO".
#
#
# Calling via cron:
#  	- crontab -e: Every night at 02:05
#		m h  dom mon dow   command
#	  	5 2 * * * /home/user/scripts/server_backup.sh > /dev/null 2>&1
#

#
# Environment variables
#

# TODO: The borg repository's password
export BORG_PASSPHRASE='passw0rd'
# This has to be set when the repository has been created by user and the script is called by cron
export BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK=yes
# For "Warning: The repository at location ... was previously located at ..."
export BORG_RELOCATED_REPO_ACCESS_IS_OK=yes

#
# Variables
#

startTime=$(date +%s)
currentDate=$(date --date @"$startTime" +"%Y%m%d_%H%M%S")
currentDateReadable=$(date --date @"$startTime" +"%d.%m.%Y - %H:%M:%S")

# TODO: Customize according to your needs
logDirectory="/home/user/backup_logs/server_backup"
logFile="${logDirectory}/server-backup-${currentDate}.log"

# TODO: This is the local backup dir where the local backups (e.g. Nextcloud) are stored before being backuped by borg backup.
localBackupDir="/media/hdd1/backups_local_temp"

# TODO: Mount point of the backup destination folder
backupDiskMount="/media/hdd2"

# TODO: This is the dir where the borg respository is stored
borgRepository="${backupDiskMount}/server_backup/borg"

# TODO: List of (local) dirs borg should backup
borgBackupDirs="/var/www/ /etc/ /home/user/ /media/hdd1/NetworkShares/ $localBackupDir/"

# Nextcloud
localNextcloudBackupDir="${localBackupDir}/nextcloud"
# TODO: To be excluded by borg (the Nextcloud web directory)
nextcloudDirBorgExclude="/var/www/nextcloud"

#
# Create log dir if it does not exist already
#
if [ ! -d "${logDirectory}" ]
then
	mkdir -p "${logDirectory}"
fi

# Function for error messages
errorecho() { cat <<< "$@" 1>&2; }

#
# Write output to logfile. Comment following lines in order to see output on terminal.
#
exec > >(tee -i "${logFile}")
exec 2>&1

#
# Preparation
#

# Check for root
if [ "$(id -u)" != "0" ]
then
	errorecho "ERROR: This script has to be run as root!"
	exit 1
fi

#
# Check if directories already exist
#

# Local backup directory
if [ ! -d "${localBackupDir}" ]
then
	mkdir -p "${localBackupDir}"
fi

# Nextcloud
if [ ! -d "${localNextcloudBackupDir}" ]
then
	mkdir -p "${localNextcloudBackupDir}"
fi

echo -e "\n###### Starting server backup on ${currentDateReadable} ######\n"

#
# Create a list with installed software
#
echo -e "\n######"
echo -e "\nCreate a list with installed software"
dpkg --get-selections > "${localBackupDir}/software.list"
echo -e "\nDone\n"
echo -e "######\n"

#
# Backup Nextcloud
#
# TODO: Storage location of the script
echo -e "\n######"
echo -e "\nBackup Nextcloud"
/bin/bash /home/user/scripts/NextcloudBackup.sh ${localNextcloudBackupDir}
echo -e "\nDone\n"
echo -e "######\n"

#
# Backup with borg
#
echo -e "\n######"
echo -e "\nBackup with Borg"

# The backup is created with two main parts:
# 	- The backups created separately (in this example Nextcloud)
# 	- Backup of the important directories of the system.
#
# Remarks
# 	- Do not add "--progress" when calling the script by cron!
borg create --stats \
    $borgRepository::"${currentDate}" \
	$borgBackupDirs \
	--exclude $nextcloudDirBorgExclude 

echo -e "\nDone\n"
echo -e "######\n"

#
# Cleanup
#

echo -e "\n\n###### Cleanup backup ######"

# All local backups are deleted again, as they were saved by borg backup

# Delete list of installed software
echo -e "\n######"
echo -e "\nDelete list of installed software"
rm "${localBackupDir}"/software.list
echo -e "\nDone\n"
echo -e "######\n"

# Delete local Nextcloud backup
echo -e "\n######"
echo -e "\nDelete local Nextcloud backup"
rm -r "${localNextcloudBackupDir:?}"/*
echo -e "\nDone\n"
echo -e "######\n"

# Borg prune
echo -e "\n######"
echo -e "\nCleanup borg backups"

# TODO: Borg should keep backups from the last 7 days (one week), 4 weekly backups (one month) and 6 monthly backups (half a year)
borg prune --progress --stats $borgRepository \
--keep-within=7d \
--keep-weekly=4 \
--keep-monthly=6

echo -e "\nDone\n"
echo -e "######\n"

#
# Misc
#

# Duration of backup
endTime=$(date +%s)
endDateReadable=$(date --date @"$endTime" +"%d.%m.%Y - %H:%M:%S")
duration=$((endTime-startTime))
durationSec=$((duration % 60))
durationMin=$(((duration / 60) % 60))
durationHour=$((duration / 3600))
durationReadable=$(printf "%02d hours %02d minutes %02d seconds" $durationHour $durationMin $durationSec)
echo -e "\n\n###### Server backup finished on ${endDateReadable} (${durationReadable}) ######\n"

# Free space on backup disk
echo -e "\nDisk usage:\n"
df -h ${backupDiskMount}

#
# Send mail to admin
#
# Important: An MTA has to be installed for sending mails.
# TODO: Add your own e-mail address here.
mail -s "Server backup finished" my@email.address < "${logFile}"

Das komplette Skript ist auch als Git-Repository auf Codeberg verfügbar: Linux-Server-Backup @ Codeberg

Bevor man das Skript also mühselig kopiert und einfügt, kann einfach das Repository gecloned werden:

mkdir -p /home/user/scripts/
git clone https://codeberg.org/DecaTec/Linux-Server-Backup.git

Wichtig: In diesem Skript sind alle Stellen, die individuell angepasst werden müssen mit einem TODO im Kommentar gekennzeichnet (die betrifft v.a. Verzeichnis-Angaben). Daher das Skript bitte nicht einfach übernehmen, sondern immer auf die eigenen Bedürfnisse anpassen.

Erläuterungen zum den einzelnen Schritten des Backup-Skripts (bitte auch die Kommentare im Skript selbst beachten):

  • Als erstes werden Variablen zum Bedienen des Borg-Repositories gesetzt. Die betrifft v.a. das vergebene Passwort (Variable BORG_PASSPHRASE).
  • Mit der Variable logDirectory wird das Verzeichnis festgelegt, in das pro Backup ein Log-File geschrieben wird.
  • Mit localBackupDir wird das Verzeichnis angegeben, in das die lokalen Backups gespeichert werden – also in diesem Fall das gesondert angefertigte Nextcloud-Backup. Nach dem Aufruf von Borg werden die Inhalte dieses Verzeichnisses wieder gelöscht.
  • Anschließend wird das Verzeichnis des Borg-Repositories angegeben (borgRepository) und die Verzeichnisse definiert, die später von Borg direkt gesichert werden sollen (borgBackupDirs).
  • Es folgen die Verzeichnis-Angaben für das separate Nextcloud-Backup. Da /var/www ja schon direkt per Borg gesichert wird, ist das Web-Verzeichnis von Nextcloud später vom Backup auszuschließen (nextcloudDirBorgExclude).
  • Anschließend erfolgt bei der Ausführung des Skripts die Überprüfung, ob dieses auch mit Root-Rechten ausgeführt wird.
  • Nun beginnt die eigentliche Ausführung des Skripts: Es wird eine Liste der installierten Pakete im lokalen Backup-Verzeichnis gespeichert (sinnvoll, wenn das Backup auf einem anderen System wiederhergestellt werden sollte).
  • Das Nextcloud-Backup wird dann einfach durch das Aufrufen des Nextcloud-Backup-Skripts erstellt.
  • Es folgt der eigentliche Aufruf von Borg Backup.
  • Anschließend werden die (temporären) lokalen Backups wieder gelöscht.
  • Nun wird das Borg-Repository bereinigt. In diesem Beispiel sollen Backups der letzten 7 Tage, 4 wöchentliche Backups und 6 monatliche Backups behalten werden. Backup-Sets, die nicht mehr diesem Muster entsprechen, werden aus dem Respository gelöscht und dieses wird konsolidiert.
  • Ganz am Ende des Skripts wird noch eine E-Mail versendet. Damit dies funktionieren kann, muss auf dem System ein MTA installiert sein (siehe Linux: Einfach E-Mails versenden mit msmtp).

Ist das Skript erstellt, werden die Zugriffsrechte noch eingeschränkt (hier ist ja das Passwort des Borg-Repositories gespeichert) und das Skript wird als ausführbar gekennzeichnet:

chmod 600 /home/user/scripts/server_backup.sh
chmod +x /home/user/scripts/server_backup.sh

Das Backup-Skript kann nun für einen ersten Lauf manuell ausgeführt werden:

./home/user/scripts/server_backup.sh

Die erste Ausführung dauert in der Regel etwas länger, da alle zu sichernden Verzeichnisse und lokalen Backups gesichert werden müssen. Weitere Ausführungen des Skripts sollten dann aber deutlich schneller ablaufen.

Backups automatisieren

Das Anfertigen der Backups kann nun mittels Cron einfach automatisiert werden. Dazu muss lediglich für den Root-User ein Cronjob eingerichtet werden:

crontab -e

Hier fügen wir nun ganz unten z.B. folgende Zeile hinzu:

0 2 * * * /home/user/scripts/server_backup.sh > /dev/null 2>&1

Nun wird das Backup-Skript jede Nacht um 02:00 aufgerufen.

Hinweis: Der Pfad zum Skript muss in der Crontab immer absolut (also mit dem kompletten Verzeichnis-Pfad) angegeben werden.

Wenn das Skript zu einem anderen Zeitpunkt ausgeführt werden soll, kann ich die Seite contab guru empfehlen: Dies ist eine Seite zum einfachen Erstellen von Crontab Zeitplänen. Hiermit wird es einfacher, die Syntax für den Zeitplan eines Cronjobs zu erzeugen.

Off-Shore Backups

Das Backup kann mit diesem Skript an jeden beliebigen Ort gespeichert werden, der auf der lokalen Maschine verfügbar ist (z.B. eine zweite interne Festplatte, ein NAS, etc.). Nun kann man sich Gedanken über ein „Offshore-Backup“ machen: Dies bedeutet, dass man ein weiteres Backup anfertigt, welches jedoch örtlich getrennt vom ersten Backup ist. Im einfachsten Fall ist dies ein Backup auf einer externen Festplatte, welche bei Freunden/Verwandten gelagert wird, oder auch ein Backup in eine Cloud. Sinn und Zweck hierbei ist die Datensicherheit im Katastrophenfall (z.B. bei Hausbrand, Überschwemmung, Diebstahl, etc.).

Das Borg-Repository kann dazu in seiner Gesamtheit an einen beliebigen Ort kopiert werden und schon hat man ein zweites identisches Backup. Durch die Verschlüsselung des Backups muss man sich hierbei auch keine Gedanken um unbefugten Zugriff machen: Selbst, wenn die externe Festplatte in die falschen Hände gerät, kann ein Dritter keinen Zugriff auf die Daten des Backups erlangen.

Um das Borg-Repository (/media/hdd2/server_backup) beispielsweise auf eine externe Festplatte (hier z.B. gemountet unter /media/hdd_ext) zu kopieren, kann einfach rsync verwendet werden:

rsync -ahP --delete --stats /media/hdd2/server_backup /mnt/hdd_ext

Das zweite Backup ist dann eine identische Kopie des ersten Backups und kann genau so zur Wiederherstellung verwendet werden.

Dies kann dann auch auf einem anderen Rechner geschehen. Die einzige Voraussetzung ist eine Installation von Borg Backup und das Passwort des Original-Repositories.

Backups wiederherstellen

Ein Backup anzufertigen ist die eine Sache. Bevor man im Problemfall darauf angewiesen ist, sollte man sich auf jeden Fall damit vertraut machen, wie man die Daten aus dem Backup wiederherstellen kann.

Für die Wiederherstellung von Dateien und Verzeichnissen gibt es z.B. den Befehl borg extract (siehe Borg Dokumentation).

Ich gehe hier aber meistens einen anderen Weg, da dies für mich persönlich komfortabler ist. Zunächst kann man sich eine Liste an „Backup-Sets“ anzeigen lassen:

borg list /media/hdd2/server_backup/borg/

Nach der Eingabe des Passworts werden alle verfügbaren Backup-Sets aufgelistet (hier rot markiert):

Borg: Auflistung der Backup-Sets

Borg: Auflistung der Backup-Sets

Ein Backup-Set kann nun einfach in das Dateisystem gemountet werden:

mkdir -p /mnt/borg
borg mount /media/hdd2/server_backup/borg::20191006_020001 /mnt/borg

Wieder wird nach dem Passwort gefragt und anschließend ist das komplette Backup (mitsamt Unterverzeichnissen) unter /mnt/borg gemountet und man kann mit normalen Dateioperationen darauf zugreifen.

Um nun beispielsweise eine einzelne Datei auf dem Backup zu extrahieren, kann ganz einfach cp verwendet werden:

cp /mnt/borg/etc/nginx/conf.d/HTTP-Gateway.conf /etc/nginx/conf.d/HTTP-Gateway.conf

Nach dem Extrahieren der benötigten Dateien aus dem Backup kann das Backup-Set wieder ausgehängt werden:

borg umount /mnt/borg

Wenn nun keine einzelnen Dateien, sondern das Backup einer kompletten Applikation wiederhergestellt werden muss, wird das Backup der Anwendung aus dem Borg-Repository extrahiert. Anschließend wird dies separat wiederhergestellt. Siehe beispielsweise die Restore-Anweisungen für Nextcloud.

Troubleshooting

Das hier gezeigte Skript ist natürlich nur ein Beispiel und kann beliebig erweitert werden. Damit kann das Skript auch durchaus umfangreich werden. Wenn das Skript dann nicht richtig funktionieren sollte, ist der erste Schritt immer die Kontrolle der Logs, die durch das Skript angelegt werden. Sollte dies nicht zur Lösung des Problems führen, sollten die einzelnen Schritte, die im Skript enthalten sind, einzeln und in genau der Reihenfolge auf der Kommandozeile ausgeführt werden. Hier sollte dann zumindest der Schritt identifiziert werden können, ab dem das Skript „aus dem Ruder läuft“. Wenn das Problem gefunden wurde, sollte anschließend das Skript dementsprechend angepasst werden.

Fazit

Dieser Artikel hat eine einfache und effiziente Möglichkeit skizziert, wie ein Linux-System gesichert werden kann. Das bereit gestellt Skript kann als Ausgangspunkt für eigene Backup-Strategien verwendet werden.

Wenn das System erst einmal eingerichtet wurde (und das Wiederherstellen der angefertigten Backups getestet wurde!), können die Backups automatisiert werden, so dass man hier in Zukunft nicht mehr viel Zeit investieren muss. Im Problemfall kann man dann ganz einfach auf die erstellten Backups zurückgreifen.

Habt ihr euch für euren Server auch schon eine Backup-Strategie ausgedacht? Wie sieht diese im Detail aus? Hinterlasst mir dazu doch einfach einen Kommentar.

Weiterführende Artikel

Links

]]>
https://decatec.de/linux/backup-strategie-fuer-linux-server-mit-borg-backup/feed/ 12
Metasuchmaschine searx auf eigenem Server installieren (mit Docker und nginx) https://decatec.de/home-server/metasuchmaschine-searx-auf-eigenem-server-installieren-mit-docker-und-nginx/ https://decatec.de/home-server/metasuchmaschine-searx-auf-eigenem-server-installieren-mit-docker-und-nginx/#comments Sun, 20 Oct 2019 09:53:15 +0000 https://decatec.de/?p=6151 searx Logo

Eine Suchmaschine ist eine der wichtigsten Tools im Internet. Google ist hier der unangefochtenen Platzhirsch: Die Marktmacht von Google lässt sich allein schon an der Tatsache erahnen, dass das Wort „googeln“ schon 2004 im Duden aufgenommen wurde.
Wer nun aber Wert auf Privatsphäre und Datenschutz im Internet legt, für den ist Google sicherlich nicht die beste Wahl.

Hier gilt es also, sich nach Alternativen umzusehen. Auf dem Markt gibt es zum Glück einige Suchmaschinen, die in Bezug auf Privatsphäre und Datenschutz besser dastehen als Google. Einfach eine andere Suchmaschine zu benutzen ist jedoch auch keine optimale Lösung – mehr dazu später.

Der folgende Artikel soll daher zeigen, wie man searx als eigene Metasuchmaschine mit Docker und nginx betreiben kann. Damit bleibt man auch bei der Suche im Internet Herr seiner eigenen Daten.

Update-Historie (letztes Update: 05.02.2020)
  • 05.02.2020:
    • Update für searx v0.16.0: Der Docker-Container nutzt nun den Port 8080.
  • 15.12.2019:
    • Befehl zum Starten des Docker-Containers angepasst, so dass keine Docker-Logs geschrieben werden (–log-driver none).
  • 13.11.2019:
    • Allgemeine Hinweise zum Betrieb einer eigenen searx-Instanz hinzugefügt (kleiner Nutzerkreis).
  • 21.10.2019:
    • Hinweis auf die von mir betriebene searx-Instanz searx.decatec.de hinzugefügt.
    • Hinweis auf das Anpassen der Standard-Einstellungen (/opt/searx/searx/settings.yml) hinzugefügt.

Warum eine eigene Suchmaschine betreiben?

Sehen wir uns den Markt der Suchmaschinen mal näher an:

Hier gibt es zum einen Suchmaschinen, die von den jeweiligen Anbietern betrieben werden, z.B. Google, Bing, Yahoo, etc. Nur diese großen Anbieter haben die Kapazitäten, eigene Suchindizes aufzubauen. Und wer hier investiert, der möchte mit dem Produkt natürlich auch Geld verdienen. Dies sind jedoch nicht die Suchmaschinen selbst, sondern das Produkt sind dabei die Benutzer (bzw. deren Daten). Die Benutzer-Daten können gesammelt und ausgewertet werden, um daraufhin z.B. personalisierte Werbung zu schalten.

Daneben gibt es die sog. Metasuchmaschinen. Dies sind Suchmaschinen, die keine eigenen Suchindizes verwalten, sondern Suchanfragen an andere Suchmaschinen (wie z.B. Google) weiterleiten. Der große Vorteil dabei ist, dass dadurch Suchanfragen anonymisiert werden können, da z.B. Google einen User nicht mehr eindeutig tracken kann. Der einzige Nachteil an einer Metasuchmaschine ist, dass die Suchergebnisse nicht mehr personalisiert werden. Daher hat man immer das Gefühl, dass die Suchergebnisse von Google direkt etwas besser ausfallen, als die Ergebnisse einer Metasuchmaschine. Google schafft dies allerdings nur, weil die User getrackt werden, und das wollen wir ja gerade verhindern.

Lange Zeit habe ich Startpage als Metasuchmaschine genutzt und empfohlen. Jedoch hat Startpage ab Oktober diesen Jahres mit System1 LLC einen neuen Anteilseigner (Quellen: hier bzw. hier). Dessen Geschäftsmodell basiert allerdings genau auf dem Sammeln und Auswerten von Daten. Dies passt meiner Meinung nach nicht zu den Grundsätzen von Startpage (lt. eigener Aussage „die diskreteste Suchmaschine der Welt“). Mit dieser Meinung stehe ich sicherlich nicht allein da, siehe Startpage and System1 Abuse Your Privacy Under the Guise of ‘Privacy One Group’.

Eine Alternative wäre hier z.B. DuckDuckGo (ebenfalls eine Metasuchmaschine). Allerdings wird diese von einem amerikanischen Anbieter betrieben, der lt. Gesetzt dazu verpflichtet ist, mit den US-Behörden zusammen zu arbeiten. Also kann man im Zweifelsfall auch davon ausgehen, dass hier Daten gespeichert und ausgewertet/weitergegeben werden.

Mit searx gibt es allerdings auch eine Metasuchmaschine, die auf einem eigenen Server betrieben werden kann. Ziel dieses Open Source Projektes ist der Schutz der Privatsphäre der Benutzer, indem keine IP-Adressen an die dahinter liegenden Suchmaschinen weitergegeben werden und deren Tracking-Cookies geblockt werden.

Voraussetzungen und Installationsvarianten

searx kann auf jedem Linux-System installiert werden, welches Python-Programme ausführen kann. Dies ist auf so gut wie allen Distributionen gegeben.

Dabei gibt es mehrere Installationsvarianten:

  • Die klassische Installation.
  • Das Bauen eines Docker-Images aus dem offiziellen Repositories und der Betrieb als Docker-Container.
  • Die Nutzung eines vorgefertigten Docker-Images (z.B. wonderfall/serx bei Docker Hub).
  • Die Nutzung des Docker-Images aus dem Projekt searx-docker.

Ich empfehle hier die zweite Variante, indem das Docker-Image aus dem offiziellen Repository gebaut wird. Genau diese Variante wird daher auch in diesem Artikel gezeigt.

Daher ist der Betrieb von Docker ebenfalls eine Installations-Voraussetzung. Eine Einführung zu Docker mit Installationsanweisungen kann dem Artikel Docker auf Ubuntu Server entnommen werden.

Wichtig ist hier auch, dass die Suchmaschine per HTTPS erreichbar ist, damit die Verbindung stets verschlüsselt ist. Hier wird nginx als Webserver verwendet, der die Anfragen an die Suchmaschine an den Docker-Container weiterleitet. Der Webserver ist hierbei für die Verschlüsselung per HTTPS zuständig. Wie man die entsprechenden TLS-Zertifikate mittels acme.sh erzeugen kann, ist im Artikel RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung) zu finden.

Am einfachsten ist der Betrieb der Suchmaschine über eine eigene (Sub-)Domain. Wenn DynDNS verwendet wird, dann empfiehlt sich das Anlegen eines CNAME-Eintrags. Details dazu findet man im Artikel Nextcloud: Online-Office mit ONLYOFFICE (mit eigener Subdomain). Im folgenden gehe ich davon aus, dass die Suchmaschine unter der Domain searx.meinedomain.de betrieben wird.

Allgemeine Hinweise zum Betrieb einer eigenen searx-Instanz

Der Artikel zeigt, wie man schnell eine eigene searx-Instanz in Betrieb nehmen kann. Jedoch sollte man sich im Vorfeld Gedanken über den Nutzerkreis der Instanz machen.

Google, Bing & Co „sehen“ nur die IP-Adresse des searx-Servers. Wenn die eigene Suchmaschine nur von sehr wenigen Usern benutzt wird (im Extremfall von nur einem Benutzer), nutzt die Verschleierung der IP-Adressen der Clients durch searx hier wenig. Die Suchmaschinen können dann ebenso einfach ein Profiling vornehmen, als wenn man die diese direkt (d.h. ohne searx) verwenden würde – da die IP pro Nutzer immer die gleiche ist.

Daher sollte man eine searx-Instanz besser nicht mit sehr wenigen/einem einzelnen Benutzer betreiben. Je mehr Benutzer die Instanz verwenden, desto weniger können die Suchmaschinen ein Profiling vornehmen.

Wenn der Nutzerkreis der eigenen searx-Instanz vermutlich sehr klein ausfallen wird, ist es vielleicht eine Überlegung wert, statt einer privaten searx-Instanz auf eine der öffentlich verfügbaren searx-Instanzen auszuweichen.

searx installieren

Zunächst bringen wir das System auf den neusten Stand:

apt update && apt upgrade -V && apt dist-upgrade && apt autoremove

Anschließend wird das Git-Repository gecloned:

cd /opt
git clone https://github.com/asciimoo/searx.git
cd searx

In den meisten Anleitungen wird das Docker-Image direkt aus dem Main-Branch des Projekts gebaut (Entwicklungsversion). Ich empfehle hier jedoch das Bauen des neusten Releases. Dazu listet man zunächst einmal die Releases des Projekts auf:

git tag -l

Auflisten der searx-Releases

Auflisten der searx-Releases

Momentan ist die Version v0.16.0 aktuell, daher rufen wir im Folgenden diesen Release ab:

git checkout tags/v0.16.0

Die Warnung („Detached Head“) kann hier ruhig ignoriert werden.

Auch wenn searx recht gute Standard-Einstellungen mitbringt (z.B. die zu verwendenden Suchmaschinen, die Standard-Sprache der Suche, das Theme, etc.), können diese Einstellungen individuell angepasst werden. Dazu wird vor dem Bauen des Docker-Images folgende Datei bearbeitet:

nano /opt/searx/searx/settings.yml

Die Inhalte dieser Datei sind eigentlich selbsterklärend und würden den Rahmen des Artikels sprengen. Daher wird an dieser Stelle nur auf die Möglichkeit hingewiesen, die Einstellungen der searx-Instanz individuell anzupassen.
Auch wenn alle Einstellungen auf Standard belassen werden, können die Benutzer der Suchmaschine später ihre individuellen Einstellungen vornehmen. Diese werden dann Client-seitig mittels eines Cookies gespeichert.

Das einzige, was ihr in der Datei settings.yml ändern solltet, ist der sog. secret_key: Dies kann mit folgendem Befehl schnell durchgeführt werden:

sed -i -e "s/ultrasecretkey/`openssl rand -hex 32`/g" /opt/searx/searx/settings.yml

Das Docker-Image wird nun mit folgendem Befehl gebaut:

docker build -t searx .

Nun kann man sich erst mal einen Kaffee holen, da dieser Vorgang durchaus ein paar Minuten dauert.

Anschließend kann der Container auch schon gestartet werden:

docker run -d --name searx -p 8080:8080 --restart=always --log-driver none -e IMAGE_PROXY=True -e BASE_URL=https://searx.meindomain.de searx

Die Parameter haben dabei die folgende Bedeutung:

  • -p 8080:8080
    : Der Port 8080 (Standard-Port von searx) wird vom Host-System an den Docker-Conatiner weitergeleitet.
    Hinweis: Dies hat sich mit der Version v0.16.0 von searx geändert, bis searx v0.15.0 war dies der Port 8888. Dieser ist weiterhin auch im Settings-File (settings.yml) von searx angegeben, wird aber nicht wirklich verwendet, da der Docker-Container nur den Port 8080 nutzt.
  • --restart=always
    : Der Container soll bei jedem Systemstart automatisch gestartet werden.
  • --log-driver none
    : Sorgt dafür, dass keine Logs geschrieben werden. Ohne diesem Parameter könnten die Logs später mit dem Befehl docker logs searx abgerufen werden.
    Wichtig:
    Dieser Parameter sollte unbedingt gesetzt werden, wenn durch die searx-Instanz absolut keine Daten geloggt werden sollen.
  • -e IMAGE_PROXY=True
    : Aktiviert die Proxy-Funktion für Bilder, d.h. Bilder werden nicht direkt durch den Client-Browser abgerufen, sondern durch searx selbst.
  • -e BASE_URL=https://searx.meindomain.de
    : Hiermit wird die URL angegeben, unter der searx erreichbar sein soll. Hier muss auch das Protokoll (http/https) mit angegeben werden.

Der letzte Schritt ist nun das Hinzufügen eines virtuellen Hosts für nginx:

nano /etc/nginx/conf.d/searx.meinedomain.de.conf

Beispielhaft kann die Konfiguration hier folgendermaßen aussehen:

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name searx.meinedomain.de;

        # Include SSL configuration
        include /etc/nginx/snippets/ssl.conf;

        # Include headers
        include /etc/nginx/snippets/headers.conf;

        # Important: Disable error and access log, so that no IPs get logged
        access_log  off;
        error_log off;

        #
        # Configuration for Searx
        #

        location / {
                proxy_pass http://localhost:8080;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Remote-Port $remote_port;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_redirect off;
        }
}

Das Setzen der Settings für SSL und der Standard-Header des Webservers erfolgt hier über das Einbinden über includes. Interessant ist hier hauptsächlich der location-Block, mit dem die Anfrage an den Docker-Container von searx weitergeleitet wird (Port 8080). Diese Kommunikation erfolgt unverschlüsselt über HTTP, da diese nur Maschinen-intern stattfindet.

Wichtig: Damit absolut keine Daten gesammelt werden, sollten Access- und Error-Log für diesen virtuellen Host deaktiviert werden (access_log off bzw. error_log off). Wenn diese nicht deaktiviert werden, werden die IPs der Aufrufer automatisch über nginx geloggt!

Zu guter Letzt muss der Webserver noch neu gestartet werden:

service nginx restart

Nun kann die Suchmaschine schon über den Browser aufgerufen werden: https://searx.meinedomain.de

searx in Firefox

searx in Firefox

Damit searx als Standard-Suchmaschine genutzt werden kann, muss diese Suchmaschine noch im Browser hinzugefügt werden. Bei Firefox kann dies über das Menü mit den drei Punkten in der Adress-Leiste erledigt werden.

searx als Suchmaschine in Firefox hinzufügen

searx als Suchmaschine in Firefox hinzufügen

Anschließend kann die Standard-Suchmaschine in den Einstellungen des Browsers gesetzt werden.

Die Nutzung von searx

Nachdem searx nun fertig installiert ist, können die Optionen der Suchmaschine über einen Klick auf Einstellungen (oben rechts) gesetzt werden (z.B. welche Suchmaschinen verwendet werden). Die wichtigste Einstellung ist hier vermutlich die Suchsprache, welche auf Deutsch – de gesetzt werden sollte, da ansonsten nur englische Suchergebnisse angezeigt werden:

Die Suchsprache in searx festlegen

Die Suchsprache in searx festlegen

Diese Einstellungen werden übrigens nicht bei searx gespeichert, sondern ausschließlich per Cookie auf dem Client.

Nun lohnt sich noch ein Blick auf die Such-Syntax. Hiermit können z.B. die Ergebnisse auf eine Suchmaschine begrenzt werden. Soll z.B. nur bei Wikipedia nach dem Suchbegriff „Nürnberg“ gesucht werden, sieht die Syntax folgendermaßen aus: !wp Nürnberg
Ebenso kann explizit nach Suchergebnissen einer bestimmten Sprache gesucht werden (z.B. Englisch): :en Nürnberg

searx updaten

Wenn eine neue Version von searx verfügbar ist, wird das alte Image entfernt und das GitHub-Repository einfach neu abgerufen, wie schon bei der initialen Installation:

docker stop searx
docker rm searx
docker rmi searx
cd /opt
rm -r searx
git clone https://github.com/asciimoo/searx.git
cd searx
git tag -l
git checkout tags/v0.16.0
docker build -t searx .
docker run -d --name searx -p 8080:8080 --restart=always -e IMAGE_PROXY=True -e BASE_URL=https://searx.meindomain.de searx

searx-Instanz von decatec.de

Meine eigene Instanz ist übrigens unter searx.decatec.de zu erreichen. Diese wurde nach den Vorgaben dieses Artikels umgesetzt und es werden keine Daten gespeichert/gesammelt/ausgewertet.

Die Verbindung ist darüber hinaus dank HTTPS stets verschlüsselt, siehe Qualys SSL Labs und Mozilla Observatory.

Wenn ihr keine eigene searx-Instanz aufbauen wollt und einfach nur eine öffentliche Instanz sucht, dann lade ich euch ein, über searx.decatec.de zu suchen.

Fazit

Mittels Docker ist die eigene searx-Instanz schnell aufgesetzt. Durch das Hosten der Metasuchmaschine auf eigener Hardware und der Tatsache, dass keine IPs oder Suchanfragen geloggt werden, ist dies eine gute Lösung bzgl. Datenschutz und Privatsphäre.

Neben der Nutzung einer komplett eigenen Instanz kann auch eine öffentliche Instanz von searx genutzt werden. Eine Liste von öffentlichen Instanzen ist im Wiki des GitHub-Repositories zu finden: Searx instances

Bei der Verwendung einer öffentlichen Instanz muss man jedoch dem Administrator der Instanz vertraut werden (siehe Why use a private instance?). Von außen ist nämlich nicht ersichtlich, ob hier vielleicht doch Daten gesammelt/ausgewertet/weitergegeben werden. Absolut sicher gehen kann man hier nur durch eine eigene/persönliche Instanz von searx.

Welche Suchmaschine nutzt ihr? Ist euch hier Privatsphäre und Datenschutz wichtig, oder geht es euch mehr um den Komfort beim Suchen? Hinterlasst mir dazu doch einfach einen Kommentar.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/metasuchmaschine-searx-auf-eigenem-server-installieren-mit-docker-und-nginx/feed/ 57
TLSv1.3 unter Ubuntu Server 18.04 LTS mit nginx https://decatec.de/home-server/tlsv1-3-unter-ubuntu-server-18-04-lts-mit-nginx/ https://decatec.de/home-server/tlsv1-3-unter-ubuntu-server-18-04-lts-mit-nginx/#respond Wed, 24 Jul 2019 13:45:35 +0000 https://decatec.de/?p=5974 Let's Encrypt Logo

Moderne Webserver und Browser nutzen TLS (Transport Layer Security) für die verschlüsselte Datenübertragung (z.B. mittels HTTPS). Bereits im August 2018 wurde hier der neue Standard TLSv1.3 verabschiedet. TLSv1.3 bietet viele Vorteile bzw. Sicherheit und Performance: Es kommen moderne Krypto-Algorithmen zum Einsatz, ältere (und als unsicher geltende Algorithmen werden nicht mehr unterstützt). Ebenfalls kann der Verbindungsaufbau durch einen effizienteren Handshake schneller durchgeführt werden.

Allerdings war TLSv1.3 unter Ubuntu Server 18.04 LTS (mit nginx) lange Zeit nicht nutzbar. Dies lag zum einen daran, dass unter Ubuntu 18.04 mit OpenSSL 1.1.0 ausgeliefert wurde. Die Unterstützung für TLSv1.3 wurde allerdings erst in OpenSSL 1.1.1 hinzugefügt. Dieses Update auf Version 1.1.1 wurde allerdings zu einem späteren Zeitpunkt nachgeliefert. Zum anderen wird der Webserver nginx gegen eine bestimmte Version von OpenSSL gebaut. Erst mit dem Update vom 23.07.2019 (nginx 1.17.2 – Mainline-Version) kommt nun auch hier unter Ubuntu 18.04 OpenSSL 1.1.1 zum Einsatz.

Vor diesen Updates kursierten im Internet zahlreiche Anleitungen, wie man OpenSSL und nginx für die Unterstützung von TLSv1.3 selbst kompilieren und installieren konnte. Allerdings sollte man auf solche Aktionen gerade auf Produktiv-Systemen verzichten.

Mit den nun verfügbaren Updates kann nun auch endlich TLSv1.3 unter nginx auf Ubuntu Server 18.04 LTS genutzt werden. Dieser Artikel zeigt, was dabei zu beachten ist.

Update-Historie (letztes Update: 03.02.2020)
  • 03.02.2020:
    • Cipher Suite DHE-RSA-AES256-GCM-SHA384 entfernt.

 

Updates durchführen

Falls noch nicht geschehen, sollte das System zunächst einmal auf den aktuellen Stand gebracht werden:

apt-get update && apt-get upgrade -V && apt-get dist-upgrade && apt-get autoremove

Anschließend kann die Version von OpenSSL und nginx überprüft werden. Die Befehle dazu lauten wie folgt:

openssl version
nginx -V

Hier sollte in beiden Fällen OpenSSL 1.1.1 angezeigt werden:

Informationen zu OpenSSL/nginx

In diesem Fall ist das System bereit für TLSv1.3.

TLSv1.3 in nginx aktivieren

Die Konfiguration für TLSv1.3 muss anschließend in den virtuellen Hosts von nginx aktiviert werden.

Hinweis: Ich gehe im Folgenden davon aus, dass der Webserver bereits für HTTPS mit Zertifikaten von Let’s Encrypt konfiguriert ist. Ebenfalls kommen sowohl ECDSA-, als auch RSA-Zertifikate im Hybrid-Betrieb zum Einsatz. Details dazu sind dem Artikel RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung) zu entnehmen.

Die Konfiguration für SSL kann dabei direkt in den virtuellen Hosts erfolgen (meist zu finden unter /etc/nginx/conf.d). Für eine bessere Übersicht und die Möglichkeit, SSL-Konfigurationen für mehrere vHosts wiederzuverwenden, nutze ich hier allerdings eine eigene Konfigurations-Datei, welche anschließend in die virtuellen Hosts eingebunden wird (/etc/nginx/snippets/ssl.conf).

Für TLSv1.3 sind hier mehrere Dinge wichtig:

  • ssl_protocols TLSv1.2 TLSv1.3: Hiermit wird die Unterstützung für TLSv1.2 und TLSv1.3 aktiviert. Wichtig: TLSv1.0 und TLSv1.1 sollten an dieser Stelle nicht mit aufgelistet werden, weil diese nicht mehr als sicher gelten.
  • ssl_ciphers ‚TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384‘: Definiert die sog. Cipher Suites. Diese müssen für TLSv1.3 entsprechend angepasst werden (die ersten beiden in der Liste sind speziell für TLSv1.3). Danaben wird hier ECDSA vor RSA bevorzugt.
  • ssl_ecdh_curve secp521r1:secp384r1: Spezifiziert die „Kurve“ für ECDHE-Algorithmen. Hier sollte prime256v1 nicht mehr gelistet werden.

Alle anderen Einstellungen müssen nicht weiter angepasst werden, so dass die SSL-Konfiguration zusammenfassend so aussehen kann:

# Certificates used
# RSA
ssl_certificate /etc/letsencrypt/DOMAIN.de/rsa/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/DOMAIN.de/rsa/key.pem;

# ECC
ssl_certificate /etc/letsencrypt/DOMAIN.de/ecc/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/DOMAIN.de/ecc/key.pem;

# This should be ca.pem (certificate with the additional intermediate certificate)
# See here: https://certbot.eff.org/docs/using.html
ssl_trusted_certificate /etc/letsencrypt/DOMAIN.de/ecc/ca.pem;

# Diffie-Hellman parameter, recommended 4096 bits
ssl_dhparam /etc/nginx/ssl/dhparams.pem;

# Not using TLSv1 will break:
#	Android <= 4.4.40
#	IE <= 10
#	IE mobile <=10
# Removing TLSv1.1 breaks nothing else!
# TLSv1.3 is not supported by most clients, but it should be enabled.
ssl_protocols TLSv1.2 TLSv1.3;

# Prefer the SSL ciphers for ECDSA:
ssl_ciphers 'TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384';


# Use multiple curves.
ssl_ecdh_curve secp521r1:secp384r1;

# Server should determine the ciphers, not the client
ssl_prefer_server_ciphers on;

# OCSP Stapling
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

# This is the IP if yout DNS-Server (in most cases: your router's IP)
resolver 192.168.178.1;

# SSL session handling
ssl_session_timeout 24h;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

Am Schluss muss der Webserver noch neu gestartet werden, damit die Änderungen greifen.

service nginx restart

Falls es hier zu Fehler kommen sollte, kann die genaue Stelle des Fehlers mit folgendem Befehl ermittelt werden:

nginx -t

Kontrolle der Änderungen

Nun kann man die Website im Browser aufrufen und sich die detaillierten Informationen zu der Seite anzeigen lassen. Unter Firefox geht dies beispielsweise, indem man auf das Schloss-Symbol in der Adressleiste klickt. Unter den Details zur Verbindung (Pfeil nach rechts) findet man unten die Schaltfläche Weitere Informationen. Hier sollte dann unter Technische Details ersichtlich werden, dass TLSv1.3 genutzt wird:

Firefox nutzt nun automatisch TLSv1.3

Firefox nutzt nun automatisch TLSv1.3

Eine weitere Anlaufstelle zum Testen von Websites und deren Sicherheit ist der SSL Server Test von Qualys. Beim Test der eigenen Website sollte hier ein A+ Rating und ein Hinweis auf die Unterstützung von TLSv1.3 angezeigt werden:

Beim Qualys SSL Server Test sollte man ein A+ Rating erzielen können

Beim Qualys SSL Server Test sollte man ein A+ Rating erzielen können

Hinweis: In der Kategorie Cipher Strength kann man hier momentan nur eine Wertung von 90% erzielen, auch wenn hier vorher (TLSv1.2) eine 100% Wertung aufgelistet wurde. Dies liegt darin begründet, dass der TLSv1.3-Standard eine Cipher Suite vorgibt, die nur auf 128 Bit basiert (TLS_AES_128_GCM_SHA256). Diese ist bei OpenSSL fest verdrahtet und kann nicht deaktiviert werden. Qualys wertet hier nur mit 100%, wenn alle Cipher Suites mindestens 256 Bit haben. Dies kann momentan nur umgangen werden, indem man OpenSSL selbst kompiliert und installiert. Auf einem Produktiv-System ist dies jedoch nicht zu empfehlen. Mehr Informationen zu diesem Problem findet man auf GitHub.

Wichtig beim SSL Server Tests ist aber ausschließlich das Rating von A+. Auch wenn eine Kategorie nicht mit 100% bewertet ist, stellt dies kein Sicherheits-Risiko dar.

Fazit

Mit dem Update von nginx auf v1.17.2 ist es nun auch endlich möglich, unter Ubuntu Server 18.04 LTS TLSv1.3 zu nutzen. Dies funktioniert ab sofort auch „out-of-the-box“, ohne dass man den Webserver oder OpenSSL selbst bauen und installieren muss.

TLSv1.3 bietet Vorteile bei der Sicherheit und Performance. Daher sollte man seinen Webserver auf jeden Fall für diesem modernen Standard konfigurieren.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/tlsv1-3-unter-ubuntu-server-18-04-lts-mit-nginx/feed/ 0
Verschlüsselte Festplatte (LUKS) mit USB-Stick bei Systemstart entschlüsseln https://decatec.de/linux/verschluesselte-festplatte-luks-mit-usb-stick-bei-systemstart-entschluesseln/ https://decatec.de/linux/verschluesselte-festplatte-luks-mit-usb-stick-bei-systemstart-entschluesseln/#comments Sun, 14 Jul 2019 10:28:32 +0000 https://decatec.de/?p=5914

Oftmals werden auf dem PC oder Home-Server sensible Daten gespeichert. Hier sollte man immer überlegen, ob eine Verschlüsselung der Datenträger lohnt. Wenn der Server zu Hause steht, hat prinzipiell kein Dritter physischen Zugriff auf das System. Aber was passiert, wenn der Home-Server bei einem Einbruch gestohlen wird?. Auch wenn es der Dieb eher auf die Hardware abgesehen hat, bleibt ein ungutes Gefühl, wenn die Daten auf dem Server unverschlüsselt gespeichert wurden. In der Theorie haben dann Dritte Zugriff auf das System und alle darauf gespeicherten Daten.

Die Verschlüsselung von Datenträgern ist unter Linux schnell eingerichtet. Das Mittel der Wahl ist dabei meistens LUKS („Linux Unified Key Setup“). Hier kommt dann meist ein Passwort, oder auch ein sog. Key-File (Dateien mit beliebigem Inhalt – am besten eine zufällige Byte-Folge) zum Einsatz, mit dem eine Festplatte entschlüsselt werden kann.

Die Sicherheit erkauft man sich dann allerdings durch einen Mangel an Komfort: Nach dem Start des Systems müssen verschlüsselte Festplatten erst einmal mittels Passwort/Key-File entschlüsselt und anschließend gemountet werden. Das bedeutet nach jedem (Neu-)Start des Systems Handarbeit.

Um diese Einschränkungen zu umgehen, zeigt dieser Artikel, wie ein USB-Stick zum Entschlüsseln von Datenträgern beim Systemstart genutzt werden kann. Der Clou an der Sache: Wir speichern das Key-File nicht einfach auf dem USB-Stick selbst, sondern noch vor der ersten Partition. Auf diese Weise kann der Stick noch normal verwendet (und auch formatiert) werden. Ebenfalls ist es nicht ersichtlich, dass ein Key-File auf dem Stick enthalten ist, sollte dieser mal in falsche Hände geraten.

Update-Historie (letztes Update: 11.08.2019)
  • 11.08.2019:
    • Korrektur: Beim Erzeugen der Schlüssel-Datei wurden nur 8 statt 16 Sektoren genutzt.

Voraussetzungen

Der Artikel basiert auf Ubuntu Server 18.04 LTS, sollte allerdings auch auf andere Distributionen übertragbar sein.

Es wird nur ein beliebiger USB-Stick benötigt – die Speichergröße ist hierbei egal. Ich verwende beispielsweise einen USB-Stick von SanDisk (Affiliate-Link).

Die zu verschlüsselnde Festplatte ist in diesem Artikel beispielhaft eine zweite interne Festplatte (also nicht die System-Partition). Dadurch kann der ganze Workflow vom Verschlüsseln der Festplatte selbst, bis zum Entschlüsseln mittels USB-Stick bei Systemstart gezeigt werden.

Wichtig: Beim Verschlüsseln der Festplatte gehen dabei alle Daten verloren. Sind bereits Daten auf der Festplatte vorhanden, müssen diese vorher gesichert und nach dem Prozess wieder zurück gespielt werden.
Ebenfalls ist darauf zu achten, bei sämtlichen Befehlen die richtige Festplatte/Partition auszuwählen/anzugeben. Wird eine falsches Gerät adressiert, kann man schnell das komplette System lahm legen (weil z.B. die Daten der System-Partition überschrieben/gelöscht werden). Daher bitte die Befehle nicht einfach kopieren, sondern manuell in der Kommandozeile eingeben und am besten vor dem Ausführen nochmals kontrollieren.

Generell empfiehlt es sich, ein Backup des Systems anzufertigen, bevor die Schritte des Artikels durchgeführt werden.

Festplatte mit LUKS verschlüsseln

Ich gehe im folgenden davon aus, dass die zweite Festplatte im System unter /dev/sdb erkannt wird. Ebenfalls kommt im Setup weder LVM, noch RAID zum Einsatz. Bei LUKS in Verbindung mit LVM bzw. RAID gibt es einige zusätzliche Dinge zu beachten (siehe LUKS FAQ).

Bei der Verschlüsselung mittels LUKS hat man die Wahl, ob man die Festplatte direkt („Raw Device“), oder eine auf der Festplatte zuvor angelegte Partition verschlüsseln möchte. In diesem Beispiel wird die Festplatte (ohne Partition) verschlüsselt, da ich keine Aufteilung in unterschiedliche Partitionen benötige. Wer lieber eine Partition verschlüsseln möchte, muss dies in den entsprechenden Befehlen beachten. Hier ist dann nicht das Device an sich (/dev/sdb), sondern die Partition anzugeben (z.B. /dev/sdb1).

Zunächst wird die benötigte Software installiert:

apt-get update && apt-get install crypsteup dosfstools

Mit folgendem Befehl wird kontrolliert, ob die Festplatte richtig angeschlossen ist und ob die Gerätedatei (/dev/sdb) auch korrekt ist:

fdisk -l

Am besten achtet man hier auf die Größenangaben der Festplatte. Der Output des Programms sieht dann für /dev/sdb beispielhaft so aus:

Disk /dev/sdb: 2,7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Wenn es sich um eine Festplatte handelt, die bereits vorher in Benutzung war, sollte diese vor der Verschlüsselung nochmals mit zufälligen Daten überschrieben werden. Dies macht die Verschlüsselung dann etwas sicherer, da keine unverschlüsselten Daten mehr auf der Festplatte vorliegen.

dd if=/dev/urandom of=/dev/sdb

Achtung: Dieser Vorgang kann gerade bei größeren Festplatten sehr lange dauern!

Anschließend wird ein evtl. vorhandenes Dateisystem auf der Festplatte gelöscht:

wipefs -a /dev/sdb

Nun kann auch schon das interaktive Setup von LUKS aufgerufen werden:

cryptsetup luksFormat /dev/sdb

Hier ist ein Passwort einzugeben, mit dem das Laufwerk entschlüsselt werden kann. Das Passwort sollte dabei eine ausreichende Länge haben.

Tipp: Ein Passwort-Manager (z.B. KeePassXC) hilft nicht nur dabei, Passwörter sicher aufzubewahren, sondern kann auch bei der Generierung sicherer Passwörter helfen.

Um anschließend Zugriff auf die Festplatte zu erlangen, muss diese durch einen Device-Mapper als Geräte-Datei bereit gestellt werden:

cryptsetup luksOpen /dev/sdb crypt_hdd1

crypt_hdd1 ist anschließend der Name der entschlüsselten Festplatte. Diese kann nun wie eine normale Festplatte gemountet werden:

mkdir -p /media/hdd1
mount /dev/mapper/crypt_hdd1 /media/hdd1

Der Zugriff auf die Festplatte erfolgt in diesem Beispiel dann über den Ordner /media/hdd1.

Nun kann auf der Festplatte ein Dateisystem erzeugt werden (in diesem Fall ext4):

mkfs.ext4 /dev/mapper/crypt_hdd1

Zusammenfassend nochmals die Befehle zum Einhängen/Aushängen der verschlüsselten Festplatte.

Einhängen/Mounten:

cryptsetup luksOpen /dev/sdb crypt_hdd1
mount /dev/mapper/crypt_hdd1 /media/hdd1

Hier wird man nach dem ersten Befehl nach dem Passwort gefragt. Ohne dieses lässt sich die Platte nicht mehr entschlüsseln.

Aushängen/Unmounten:

umount /mnt/crypt_hdd1
cryptsetup luksClose crypt_hdd1

Durch luksClose wird die Verschlüsselung der Festplatte wieder aktiv, so dass ohne vorheriges Entschlüsseln/Mounten kein Zugriff mehr erfolgen kann.

USB-Stick zum Entschlüsseln einrichten

Als nächstes wird der USB-Stick vorbereitet, so dass dieser zum Entschlüsseln der Festplatte genutzt werden kann.

Achtung: Auch hier gehen wieder alle Daten verloren, die auf dem USB-Stick gespeichert sind. Wie schon zuvor ist darauf zu achten, dass man das richtige Gerät wählt. In diesem Beispiel erfolgt der Zugriff auf den USB-Stick über /dev/sdc.

Zum Einrichten des USB-Sticks benutzen wir wieder fdisk:

fdisk /dev/sdc

Mit folgenden Eingaben wird der Stick vorbereitet:

  • d: Bestehende Partition löschen.
  • o: Partitionstabelle neu erstellen.
  • n: Neue Partition erstellen. Dies sollte eine primäre Partition sein (p). Beginn der Partition sollte Sektor 2048 sein, dies ist die Standard-Einstellung.
  • w: Speichern und beenden.

Der USB-Stick wird mittels fdisk vorbereitet

Nun kann auf dem USB-Stick ein Dateisystem angelegt werden. Ich nehme hier ein FAT32-Dateisystem, damit der Stick sowohl unter Linux, als auch unter Windows verwendet werden kann. Wenn der Stick ausschließlich unter Linux verwendet werden soll, kann natürlich auch ein ext2/3/4-Dateisystem verwendet werden.

sudo mkfs.vfat -F 32 /dev/sdc1

Nun wird auf dem USB-Stick vor der ersten Partition (also in den ersten 2048 Sektoren) eine zufällige Byte-Folge erzeugt, die nachher als Schlüssel für die verschlüsselte Festplatte dienen wird:

dd if=/dev/urandom of=/dev/sdc bs=512 seek=1 count=2046

Schlüssel zur verschlüsselten Festplatte hinzufügen

Als nächstes speichern wir den soeben erzeugten Schlüssel in einer Datei ab:

dd if=/dev/sdc bs=512 skip=1 count=16 > tempKeyFile.bin

Hier nehmen wir die ersten 16 Sektoren des USB-Sticks, somit haben wir hier eine Schlüssellänge 8192 Bytes.

Diese (temporär) erzeugte Datei wird nun über LUKS als neuer Key der Festplatte hinzugefügt:

cryptsetup luksAddKey /dev/sdb tempKeyFile.bin

Anschließend kann die Festplatte auf zwei verschiedene Weisen entschlüsselt werden:

  • Mit dem Passwort, welches bei der Verschlüsselung der Festplatte angegeben wurde.
  • Mit dem soeben erzeugten Key-File, welches auch auf dem Stick vor der ersten Partition gespeichert ist.

Das Key-File (tempKeyFile.bin) wird anschließend nicht mehr benötigt. Jedoch sollte man dies ebenfalls sicher verwahren, falls man z.B. zukünftig einen anderen USB-Stick zum entschlüsseln verwenden möchte. Das Key-File kann z.B. neben dem Passwort zum Entschlüsseln ebenfalls in einem Passwort-Manager (als Anhang) gespeichert werden.

Anschließend wird das Key-File vom System entfernt:

rm tempKeyFile.bin

Festplatte automatisch bei Systemstart entschlüsseln

Nun fehlt nur noch ein entscheidender Bestandteil der Lösung: Wir wollen die Festplatte nicht per Passwort oder Key-File, sondern mit dem Schlüssel entschlüsseln, der auf dem USB-Stick hinterlegt ist. Das ganze soll auch transparent bei Systemstart ohne weiteres Zutun den Users passieren.

UUIDs der Geräte ermitteln

Damit dies umgesetzt werden kann, müssen die UUIDs der entsprechenden Geräte ermittelt werden.
Für den USB-Stick kann dies durch folgenden Befehl geschehen:

ls /dev/disk/by-id/

Hier sollte der USB-Stick mit zwei Einträgen gelistet werden.

usb-SanDisk_Ultra_4C530000100xxxxxxxxx-0:0
usb-SanDisk_Ultra_4C530000100xxxxxxxxx-0:0-part1

Hier brauchen wir die UUID des Sticks selbst und nicht jene von der ersten Partition (zu erkennen an -part1 am Ende). Die gesuchte UUID ist in diesem Beispiel also 4C530000100xxxxxxxxx-0:0.

Nun brauchen wir nur noch die UUID der LUKS-verschlüsselten Festplatte. Hier hilft folgender Befehl:

blkid

Hier sollte man nun folgende Zeile finden (die verschlüsselte Festplatte ist ja unter /dev/sdb zu erreichen):

/dev/sdb: UUID=“10fc8291-daf2-4962-xxxx-xxxxxxxxxxxx“ TYPE=“crypto_LUKS“

Die UUID ist hier dementsprechend 10fc8291-daf2-4962-xxxx-xxxxxxxxxxxx.

crypttab/fstab editieren

Damit die Festplatte bei Systemstart entschlüsselt wird, wird nun die crypttab (Anweisungen zum Einhängen verschlüsselter Geräte) bearbeitet:

nano /etc/crypttab

Hier fügen wir am Ende folgende Zeile ein:

crypt_hdd1 UUID=10fc8291-daf2-4962-xxxx-xxxxxxxxxxxx /dev/disk/by-id/usb-SanDisk_Ultra_4C530000100xxxxxxxxx-0:0 luks,tries=3,keyfile-size=8192,keyfile-offset=512

Bei der UUID handelt es sich um jene der verschlüsselten Festplatte. Daraufhin folgen Angaben zum USB-Stick, der zum entschlüsseln verwendet werden soll. Am Schluss wird angegeben, wo der entsprechende Schlüssel zu finden ist.

Damit wird die Festplatte beim Systemstart entschlüsselt. Was nun noch fehlt ist das Einhängen der entschlüsselten Festplatte, so dass diese nach dem Systemstart sofort zur Verfügung steht. Dazu wird noch die fstab editiert:

nano /etc/fstab

Am Ende fügen wir folgende Zeile hinzu:

/dev/mapper/crypt_hdd1       /media/hdd1     ext4    defaults        0       2

Beim Systemstart werden nun erst einmal die Inhalte der crypttab abgearbeitet. Damit wird die Festplatte entschlüsselt und steht per Mapper (/dev/mapper/crypt_hdd1) zur Verfügung. Erst im Anschluss werden die Laufwerke per fstab gemountet. Hier wird der Mapper dann unter /media/hdd1 eingehängt.

Nach einem Neustart des Systems (mit angeschlossenem USB-Stick) sollte die Festplatte nun direkt unter /media/hdd1 zur Verfügung stehen. Es wird kein Passwort mehr benötigt und das Key-File ist auch nicht mehr manuell anzugeben.

Fazit

Die Einrichtung von verschlüsselten Festplatten, die beim Systemstart automatisch per USB-Stick entschlüsselt werden, ist mit einigem Aufwand verbunden. Jedoch muss man sich nach der Konfiguration nicht weiter um die Ver-/Entschlüsselung der Festplatte sorgen, da dies nun vollkommen transparent geschieht

Wichtig ist ab nun nur, dass man den USB-Stick einstecken muss, wenn die Maschine (neu) gestartet werden soll. Sollte man dies vergessen, bleibt das System schon beim Booten hängen, da die Anweisungen in der crypttab nicht abgearbeitet werden können und der Mount per fstab fehlschlägt.

Ebenso benötigt es etwas Disziplin: Wenn die Maschine erst einmal läuft, sollte der USB-Stick auf jeden Fall entfernt und sicher aufbewahrt werden (z.B. am Schlüsselbund). Im Falle eines Diebstahls der Hardware ist es nun praktisch gesehen unmöglich, auf die Daten des Systems zuzugreifen, wenn man nicht den passenden USB-Stick zur Hand hat.

Links

]]>
https://decatec.de/linux/verschluesselte-festplatte-luks-mit-usb-stick-bei-systemstart-entschluesseln/feed/ 12
WordPress: Backups erstellen und wiederherstellen – manuell oder per Skript https://decatec.de/home-server/wordpress-backups-erstellen-und-wiederherstellen-manuell-oder-per-skript/ https://decatec.de/home-server/wordpress-backups-erstellen-und-wiederherstellen-manuell-oder-per-skript/#comments Sat, 08 Jun 2019 09:02:18 +0000 https://decatec.de/?p=5817 Wordpress Logo

WordPress erfreut sich bei Bloggern nach wie vor großer Beliebtheit. Wenn man einen eigenen WordPress-Blog betreibt, sollte man sich auch um das Thema Backup kümmern.

Wird der Blog bei einem Webhosting-Provider gehostet, dann werden meist von diesem automatisch Backups des kompletten Webspace durchgeführt. Damit wird dann auch ein vorhandener WordPress-Blog mit gesichert.

Anders sieht die Sache bei selbstgehosteten Blogs aus. Hier ist der Administrator selbst für Backups des Servers und der Webseiten verantwortlich.

Voraussetzungen

Dieser Artikel richtet sich an Administratoren, die WordPress auf einem eigenen (Home-)Server betreiben.

Als Grundlage dient ein WordPress-Blog, der auf einem Ubuntu Server 18.04 LTS installiert ist. Als Webserver dient hier nginx, als Datenbank kommt MariaDB zum Einsatz.
Eine beispielhafte Konfiguration wurde bereits im Artikel Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress) gezeigt.

Allerdings lassen sich die gezeigten Schritte auch auf andere Umgebungen (andere Distributionen, andere Webserver, etc.) anwenden.

Grundlagen

Ein Backup von WordPress besteht immer aus zwei Teilen:

  • Dem WordPress Dateiverzeichnis: Dies sind alle Dateien, die zum Betrieb von WordPress benötigt werden (z.B. php, oder auch css-Dateien). Dies ist normalerweise unter /var/www/wordpress zu finden.
  • Der WordPress-Datenbank: WordPress benötigt eine MySQL/MariaDB-Datenbank. Diese muss ebenfalls in die Sicherung einfließen.

Sollen Backups des eigenen Blogs eingerichtet werden, müssen immer diese beiden Teile berücksichtigt werden.

Im Vorfeld sollte man sich Gedanken darüber machen, wo die Backups gespeichert werden sollen. Im Rahmen dieses Artikels nutze ich beispielhaft das Verzeichnis /media/hdd/wordpress_backup als Backup-Ziel. Dies kann in der Praxis eine zweite (externe) Festplatte oder ein NAS sein, welches im Netzwerk zur Verfügung steht.

Backup erstellen

Um ein Backup zu erstellen, stoppen wir zunächst den Webserver:

service nginx stop

Dies verhindert, dass während des Backups aktive Zugriffe auf den Blog stattfinden.

Als nächstes wird das Dateiverzeichnis von WordPress gesichert. Hier ist dies beispielhaft das Verzeichnis /var/www/wordpress. Bitte den Punkt am Ende des Befehls beachten.

tar -cpzf "/media/hdd/wordpress_backup/wordpress-filedir_`date +"%Y%m%d"`.tar.gz" -C "/var/www/wordpress" .

Als nächstes wird die Datenbank gesichert. Nach dem Absetzen des Befehls ist noch das Passwort des WordPress-Datenbank-Users einzugeben:

mysqldump --single-transaction -h localhost -u wordpress_db_user -p wordpress_db > /media/hdd/wordpress_backup/wordpress-db_`date +"%Y%m%d"`.sql

Das Backup ist damit schon komplett und der Webserver kann neu gestartet werden:

service nginx start

Backup wiederherstellen

Das Anfertigen von Backups ist aber nur der erste Schritt. Ebenso wichtig ist es, dass diese Backups auch wiederhergestellt werden können.

Dies sollte man nach dem ersten Anfertigen eines Backups auch mindestens einmal ausprobieren.

Zunächst wird der Webserver gestoppt:

service nginx stop

Anschließend wird das Dateiverzeichnis von WordPress gelöscht und neu angelegt (allerdings leer):

rm -r /var/www/wordpress/
mkdir -p /var/www/wordpress

Als nächstes werden die Inhalte des Verzeichnisses aus dem Backup wiederhergestellt. Zu beachten ist hier der richtige Dateiname (da abhängig vom Datum):

tar -xpzf /media/hdd/wordpress_backup/wordpress-filedir_20190530.tar.gz -C /var/www/wordpress/

Nun werden noch die passenden Rechte gesetzt:

chown -R www-data:www-data /var/www/wordpress

Nun muss nur noch die Datenbank wiederhergestellt werden. Dazu wird die alte Datenbank zunächst einmal entfernt und neu angelegt:

mysql -h localhost -u wordpress_db_user -p -e "DROP DATABASE wordpress_db"
mysql -h localhost -u wordpress_db_user -p -e "CREATE DATABASE wordpress_db"

Nun wird der DB-Dump aus dem Backup wieder eingespielt:

mysql -h localhost -u wordpress_db_user -p wordpress_db < /media/hdd/wordpress_backup/wordpress-db_20190530.sql

Am Schluss wird der Webserver wieder gestartet:

service nginx start

Backup/Restore mit Bash-Skript

Ein Backup kann mit diesen einfachen Schritten erstellt werden. Allerdings sind dazu immer manuelle Schritte erforderlich. Komfortabler wird die Sache, wenn man alle Schritte mit einem Bash-Skript zusammenfasst. Dieses kann dann einfach ausgeführt werden und es wird automatisch ein Backup erstellt.

Zu diesem Zweck habe ich zwei Bash-Skripte auf Codeberg zur Verfügung gestellt:

WordPress-Backup-Restore @ Codeberg

Hinweis: Ich habe die Skript-Dateien als Open Source auf Codeberg zur Verfügung gestellt. Damit sind diese frei verfügbar und können auch von jedermann angepasst und verbessert werden. Ich übernehme allerdings keinerlei Haftung für den Einsatz dieser Skripte. Diese sollen lediglich als Basis für die Erstellung eigener Backup-/Restore-Skripte für eure WordPress-Instanzen dienen.

Das Repository kann einfach über Git gecloned werden:

cd ~
git clone https://codeberg.org/DecaTec/Wordpress-Backup-Restore.git
cd Wordpress-Backup-Restore

Wichtig: Die Skripte müssen auf jeden Fall noch an die konkrete Umgebung angepasst werden. Alle Stellen, die kontrolliert bzw. angepasst werden müssen, sind in den Skripten mit dem Kommentar „TODO“ gekennzeichnet.

Bitte passt die Skripte daher auf jeden Fall an und führt diese nicht einfach „blind“ aus!

Wenn das geschafft ist, werden die Skripte noch als ausführbar markiert:

chmod +x WordpressBackup.sh
chmod +x WordpressRestore.sh

Nun können die Skripte ganz einfach wie folgt ausgeführt werden:

./WordpressBackup.sh

Das Backup wird automatisch im Verzeichnis /media/hdd/wordpress_backup erstellt. Hier wird ein Verzeichnis mit dem aktuellen Zeitstempel erstellt, z.B.: /media/hdd/wordpress_backup/20190530_081555

Wiederhergestellt werden kann ein Backup durch das Restore-Skript. Dieses erwartet den Zeitstempel eines vorhandenen Backups als Parameter:

./WordpressRestore.sh 20190530_081555

Diese Skripte sind so konzipiert, dass diese keine Benutzer-Interaktion erfordern. Daher kann die Ausführung auch einfach per Cron automatisiert werden. Besonders für das Backup-Skript ist dies sinnvoll: So kann man z.B. jede Nacht um 03:00 ein Backup des eigenen WordPress-Blogs anfertigen. Dazu kann ein Cronjob für den Webserver-User eingerichtet werden:

crontab -u www-data -e

Hier wird am Ende einfach folgender Befehl angehängt:

0 3 * * * /home/user/Wordpress-Backup-Restore/WordpressBackup.sh > /dev/null 2>&1

Dies sorgt dafür, dass jede Nacht um 03:00 ein Backup von WordPress angelegt wird. Wichtig ist hier nur, dass der absolute Pfad zu Skript angegeben wird, da die Ausführung ansonsten fehlschlagen wird.

Alternative: Backup per WordPress-Plugin

Eine Alternative zum dem gezeigten Vorgehen ist der Einsatz eines entsprechenden Plugins für WordPress. Meiner Erfahrung nach gibt es hier zwei empfehlenswerte Plugins:

Beide Plugins dienen dazu, Backups der WordPress-Instanz manuell oder automatisiert anzulegen. Das ganze wird einfach im Dashboard von WordPress konfiguriert bzw. ausgeführt. Die Plugins sind dabei mehr oder weniger selbsterklärend, so dass ich hier nicht weiter darauf eingehen werde.

Zum einen macht dies das Anfertigen von Backups einfacher. Zum anderen macht man sich allerdings in gewisser Weise abhängig von dem verwendeten Plugin. Dies ist durch ein manuelles Backup oder ein Backup per Bash-Skript nicht gegeben.

Welche Variante (manuell/per Skript oder per Plugin) die passende ist, muss jeder WordPress-Administrator für sich selbst entscheiden.

Fazit

Ein Backup einer WordPress-Instanz ist recht schnell angefertigt. Noch komfortabler geht dies mit den bereitgestellten Bash-Skripten. Mit diesen kann das Anfertigen eines Backups auch mittels Cron automatisiert werden.

Am Ende noch ein wichtiger Tipp: Nichts ist ärgerlicher, wenn man immer Backups angefertigt hat, diese aber im Ernstfall nicht wiederhergestellt werden können. Daher sollte einmal der komplette Backup- und Restore-Prozess getestet werden. Nur auf diese Weise kann man sicher sein, dass im Falle des Falles ein bestehendes Backup wiederhergestellt werden kann.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/wordpress-backups-erstellen-und-wiederherstellen-manuell-oder-per-skript/feed/ 4
Samba auf Ubuntu Server https://decatec.de/linux/samba-auf-ubuntu-server/ https://decatec.de/linux/samba-auf-ubuntu-server/#comments Mon, 27 May 2019 13:48:39 +0000 https://decatec.de/?p=5699 Samba Logo

Wenn man einen eigenen Home-Server betreibt, dann wird man diesen oftmals auch als zentrale Stelle zur Ablage von Dateien verwenden. Damit jeder Rechner im Netzwerk Zugriff auf diese  Dateien hat, muss der Server diese Daten per Netzwerk-Freigaben bereit stellen.

In einem reinen Linux-Netzwerk würde man hier vermutlich NFS verwenden. Oftmals hat man es jedoch mit gemischten Netzwerken zu tun. Hier müssen neben Linux- auch Windows- oder Mac-Clients Zugriff auf die Netzwerk-Freigaben haben. Hier nutzt man dann am besten das SMB-Protokoll, welches auf allen Plattformen unterstützt wird. Als Server-Implementierung steht unter Linux das Softwareprojekt Samba zur Verfügung.

Dieser Artikel zeigt, wie auf Ubuntu Server 18.04 LTS eine Samba-Server installiert und konfiguriert werden kann. Allerdings können alle Schritte auch auf andere Distributionen übertragen werden.

Eine wichtige Anforderung bei Netzwerk-Shares ist immer auch die Freigabe für mehrere Benutzer: Auf eine Freigabe sollen u.U. mehrere Benutzer Schreib- und Leserechte haben. Dies wird in diesem Artikel durch das Setzen von ACLs gelöst.

Installation Samba

Zunächst wird das System auf dem neusten Stand gebracht:

apt-get update && apt-get upgrade -V && apt-get dist-upgrade && apt-get autoremove

Anschließend kann Samba installiert werden:

apt-get install samba-common samba

Das Paket samba-common sollte auf jeden Fall mit installiert werden, da dies wichtige Tools (wie z.B. smbpasswd) beinhaltet.

Benutzer hinzufügen

Damit ein Benutzer später auf die Samba-Netzwerk-Freigaben zugreifen kann, muss dieser Benutzer zunächst einmal angelegt werden. Wichtig ist ist in diesem Zusammenhang, dass der Benutzer sowohl als System-Benutzer, als auch als Samba-Benutzer angelegt werden muss.

Wenn es den Benutzer noch nicht als System-Benutzer gibt, dann wird dieser angelegt und danach ein Passwort für den Benutzer hinterlegt:

adduser bob

Alternative: Normalerweise legt man diese Benutzer nur an Home-Server an, damit diese später Zugriff auf die Samba-Freigaben haben. In diesem Fall macht es keinen Sinn, dass sich diese Benutzer direkt am System anmelden. Hier kann man den User folgendermaßen anlegen, so dass sich dieser nicht am Server selbst anmelden kann:

adduser --no-create-home --disabled-login --shell /bin/false bob

Anschließend wird noch ein Passwort für den System-Benutzer hinterlegt:

passwd bob

Anschließend muss der entsprechende User noch als Samba-User angelegt und aktiviert werden:

smbpasswd -a bob

Empfehlenswert ist hier, das gleiche Passwort wie schon für den System-Benutzer zu vergeben, dies ist jedoch nicht zwingend erforderlich.

Für jeden weiteren Benutzer ist der Vorgang zu wiederholen. Neben Bob gibt es in diesem Artikel als weiteren User auch Alice:

adduser --no-create-home --disabled-login --shell /bin/false alice
passwd alice
smbpasswd -a alice

Verzeichnisse für Netzwerk-Shares vorbereiten

Als nächstes werden beispielhaft drei Verzeichnisse vorbereitet, die später im Netzwerk verfügbar sein sollen. Auf das erste Verzeichnis sollte nur der Benutzer Bob Zugriff haben, daher werden anschließend gleich die entsprechenden Besitzrechte gesetzt:

mkdir -p /media/hdd1/networkshares/bob
chown -R bob /media/hdd1/networkshares/bob

Das gleiche wird für ein Verzeichnis für Alice wiederholt:

mkdir -p /media/hdd1/networkshares/alice
chown -R alice /media/hdd1/networkshares/alice

Ein drittes Verzeichnis soll nachher für beide Benutzer zur Verfügung stehen. Hier wird lediglich das Verzeichnis erzeugt:

mkdir -p /media/hdd1/networkshares/shared

Nun haben wir allerdings ein Problem mit den Verzeichnisrechten: Beide Benutzer sollen hier Vollzugriff haben. Per chown kann allerdings nur ein User als Owner definiert werden.

Hier gibt es nun zwei Varianten, wie die entsprechenden Rechte gesetzt werden können: Per ACL oder per Gruppen.

Rechte für mehrere Benutzer setzen – Variante 1: Per ACL

ACL (Access Control List) ergänzen das normale Rechtesystem von Linux. Man kann sich dies als zusätzliche „Schicht“ über dem normalen Rechtesystem vorstellen. Dies ist eine einfache Möglichkeit, Benutzern/Gruppen gezielt Zugriffsrechte auf Dateien und Verzeichnisse zu geben bzw. zu entziehen.

Hinweis: Beim Setzen der Rechte über ACLs gestaltet sich die Konfiguration der Netzwerk-Shares über Samba im weiteren Verlauf etwas einfacher. Daher ist dies meine bevorzugte Variante.

ACL wird während der Installation von Ubuntu Server automatisch installiert. Wenn dies nicht der Fall sein sollte, dann kann das zu einem späteren Zeitpunkt nachgeholt werden:

apt-get install acl

Nun können ACLs für das Verzeichnis gesetzt werden, auf das später beide Benutzer Zugriff haben sollen:

setfacl -R -d -m u:bob:rwx,u:alice:rwx /media/hdd1/networkshares/shared

Dieser Befehl bewirkt folgendes:

  • Die Rechte werden rekursiv gesetzt (-R).
  • Mittels -d wird ein Default gesetzt, der auch bei zukünftig angelegten Dateien und Verzeichnissen wirkt.
  • Mit dem Parameter -m werden evtl. bereits vorhandene Rechte modifiziert und nicht einfach überschrieben.
  • Die genauen Rechte für einen User werden z.B. durch u:bob:rwx gesetzt: Hier sollen die Benutzer Bob und Alice Vollzugriff auf das Verzeichnis haben.

Ein weiteres Setzen der Rechte über chown/chmod ist nicht erforderlich.

Rechte für mehrere Benutzer setzen – Variante 2: Per Gruppe

Für die zweite Variante nutzen wir Gruppen um die entsprechenden Rechte zu setzen.

Hinweis: Die Variante mit Gruppen macht die Einrichtung der Netzwerk-Shares später etwas komplizierter. Daher bevorzuge ich mittlerweile die erste Variante (ACL) zum Setzen der Rechte.

Beide Benutzer werden dazu in eine Gruppe aufgenommen. Dann wird der Gruppe die entsprechenden Besitzrechte gegeben und anschließend per chmod die passenden Zugriffsrechte gesetzt:

addgroup bobundalice
usermod -aG bobundalice bob
usermod -aG bobundalice alice
chown -R bob:bobundalice /media/hdd1/networkshares/shared
chmod -R 775 /media/hdd1/networkshares/shared

Samba Konfiguration

Bleibt eigentlich nur noch die Einrichtung des Samba-Servers. Die Konfiguration befindet sich in folgender Datei:

nano /etc/samba/smb.conf

Allgemeine Einstellungen

Zunächst werden in der Sektion [Global] ein paar Werte gesetzt. map to guest ist meist schon vorhanden, die anderen Werte werden einfach darunter eingefügt:

map to guest = never
security = user
encrypt passwords = true
invalid users root

Im einzelnen wird damit folgendes konfiguriert:

  • map to guest = never deaktiviert den Gast-Zugriff auf den Samba-Server. Ohne diese Einstellung könnte man sich am Samba-Server auch als Gast anmelden.
  • security = user gibt an, dass die Authentifizierung am Samba-Server mittels Username/Passwort erfolgt.
  • encrypt passwords = true sorgt dafür, dass Passwörter nur verschlüsselt übertragen werden.
  • invalid users root deaktiviert den Zugriff auf die Samba-Shares für den Root-User.

Weiter unten in der Konfigurations-Datei findet man Sektionen, mit den Drucker-Freigaben eingerichtet werden. Diese sind standardmäßig aktiv. Möchte man keine Drucker freigeben, dann kommentiert man die beiden Sektionen [printers] und [print$] am besten aus.

Freigabe für einen Benutzer

Bob und Alice sollen jeweils eine eigene Freigabe haben, auf die kein anderer Benutzer Zugriff hat. Dazu werden in der smb.conf ganz am Ende folgende Blöcke eingefügt:

[bob]
valid users = bob
path = /media/hdd1/networkshares/bob
guest ok = no
writeable = yes

[alice]
valid users = alice
path = /media/hdd1/networkshares/alice
guest ok = no
writeable = yes

Folgende Angaben sind hier zu machen:

  • [bob]: Der Sektions-Name legt fest, wie die Freigabe heißen soll.Über diesen Namen werden die Netzwerk-Shares dann später auf den Client-Rechnern eingerichtet.
  • valid users: Hier werden die Benutzer festgelegt, welche Zugriff auf die Freigabe haben sollen. Bei Einzel-Freigaben ist dies auch immer nur ein User.
  • path: Legt den lokalen Pfad fest, auf dem die Freigabe auf den lokalen Rechner liegen soll.
  • guest ok = no: Hiermit wird festgelegt, dass sich Gäste nicht auf diese Freigabe verbinden können.
  • writeable = yes: Dies wird nochmals explizit angegeben, dass der Benutzer unter valid users Schreibzugriff auf die Freigabe haben soll.

Freigabe für mehrere Benutzer – Variante 1: ACL

Bei den Freigaben für mehrere Benutzer gibt es wieder zwei Varianten, abhängig davon, wie zuvor die Rechte auf Dateisystem-Ebene gesetzt wurden (ACL oder Gruppen).

Ich bevorzuge das Setzen der Rechte per ACL. In diesem Fall sieht die Konfiguration der Freigabe folgendermaßen aus. Der Name der Freigabe lautet hier shared:

[shared]
valid users = bob alice
path = /media/hdd1/networkshares/shared
guest ok = no
writeable = yes

Wie man sieht, unterscheidet sich diese Variante kaum von der Einrichtung einer Freigabe für einen einzelnen User. Es werden lediglich mehrere Benutzer unter valid users angegeben.

Freigabe für mehrere Benutzer – Variante 2: Gruppen

Wenn keine ACLs gesetzt wurden, sondern beide Benutzer in eine Gruppe hinzugefügt wurden, müssen für das Konfigurieren der Freigabe ein paar zusätzliche Angaben gemacht werden:

[shared]
valid users = @bobundalice
path = /media/hdd1/networkshares/shared 
guest ok = no
write list = @bobundalice
directory mask = 0775
create mask = 0775

Folgendes gilt es hier zu beachten:

  • valid users: Hier wird die Gruppe der User angegeben, die Zugriff auf die Freigabe haben soll. Vor dem Gruppen-Namen muss dazu ein @ Symbol stehen.
  • write list: Hier wird wiederum die Gruppe angegeben, die Schreibzugriff auf die Freigabe haben soll.
  • directory mask/create mask: Hier werden die Datei- bzw. Verzeichnisrechte gesetzt, ähnlich wie beim Befehl chmod. Dies sorgt dafür, dass die Dateien mit den entsprechenden Rechten versehen werden, wenn diese (durch die Benutzer der Freigabe) erstellt werden.

Konfiguration der Freigaben abschließen

Damit wäre die Konfiguration von Samba abgeschlossen. Mit folgenden Befehlen wird die aktuelle Konfiguration getestet und Samba anschließend neu gestartet:

testparm
service smbd restart

Falls die Firewall ufw auf dem System aktiv ist, muss hier noch eine Freigabe für Samba erfolgen. Am einfachsten funktioniert dies mit einem Applikations-Filter:

ufw allow from 192.168.178.0/24 to any app Samba

In diesem Beispiel erfolgt die Freigabe nur für das lokale Netzwerk (192.168.178.0/24). Damit haben nur Clients innerhalb des gleichen Netzwerks Zugriff auf die Samba-Freigaben.

Einbinden der Netzwerk-Shares

Nach der Einrichtung von Samba können die Freigaben nun ganz einfach auf den Client-Rechnern eingebunden werden.

Linux

Unter Linux kann die Freigabe entweder temporär oder dauerhaft eingebunden werden.

Temporärer Zugriff auf die Freigaben per Datei-Manager

Auf die Freigaben kann man mit jedem Datei-Manager zugreifen, indem man in die Adressziele den SMB-Speicherort eingibt, z.B. smb://192.168.178.60.

Direkter Zugriff auf die Freigaben (Manjaro/Thunar)

Direkter Zugriff auf die Freigaben (Manjaro/Thunar)

Hier werden alle Freigaben angezeigt. Bei einem Zugriff muss dann noch die Eingabe von Username/Passwort erfolgen.

Temporäres Einbinden per Kommandozeile

Hier wird das Paket cifs-utils benötigt:

apt-get install cifs-utils

Damit nicht immer das Passwort beim Mounten der Freigabe eingegeben werden muss, sollte sich der entsprechende Nutzer in seinem Home-Verzeichnis eine Datei anlegen, in der Username und Passwort gespeichert ist:

cd ~
nano .smbcredentials

Der Inhalt der Datei ist dabei recht einfach:

username=<User>
password=<Password>

Auf diese Datei sollte nur der entsprechende User Zugriff haben:

sudo chmod 600 .smbcredentials

Als nächstes werden die Verzeichnisse angelegt, in die die Freigaben gemountet werden sollen:

mkdir -p /mnt/bob
mkdir -p /mnt/shared

Soll die Freigabe nun temporär gemountet werden, können dazu folgende Befehle genutzt werden:

mount -t cifs -o credentials=~/.smbcredentials //192.168.178.60/bob /mnt/bob
mount -t cifs -o credentials=~/.smbcredentials //192.168.178.60/shared /mnt/shared

Hier wird folgendes angegeben:

  • -o credentials=~/.smbcredentials: Hier werden Benutzername/Passwort mit der soeben angelegten Datei übergeben.
  • //192.168.178.60/bob: IP des Samba-Servers und Name der Freigabe, wie auf dem Samba-Server in der Datei smb.conf als Sektions-Name angegeben.
  • /mnt/bob: In diesen Ordner wird die Freigabe gemountet.

Ein Aushängen (unmount) der Freigabe kann folgendermaßen durchgeführt werden:

umount /mnt/bob

Auch nach einem Neustart des Systems ist die Freigabe aber wieder verschwunden.

Dauerhaftes Mounten per fstab

Die Freigaben können aber auch per fstab gemountet werden. Damit stehen die Freigaben dann direkt nach einem System-Neustart zur Verfügung:

nano /etc/fstab

Am Ende der Datei wird nun folgendes hinzugefügt (die bereits bestehenden Einträge in der Datei sollte man nicht verändern):

//192.168.178.60/bob /mnt/bob cifs credentials=/home/bob/.smbcredentials,noperm,_netdev,noauto,x-systemd.automount 0 0
//192.168.178.60/shared /mnt/shared cifs credentials=/home/bob/.smbcredentials,noperm,_netdev,noauto,x-systemd.automount 0 0

Das Einbinden erfolgt ähnlich wie schon beim temporären Einbinden, jedoch gibt es einige Unterschiede:

  • Die Pfadangabe für die Datei mit den Credentials muss absolut erfolgen.
  • Mit noperm wird angegeben, dass die Credentials nicht Client-seitig, sondern nur auf dem Server geprüft werden.
  • _netdev gibt an, dass der Mount abhängig von einer Netzwerk-Verbindung ist.
  • Die Parameter noauto,x-systemd.automount sorgen dafür, dass die Freigabe erst beim ersten Zugriff gemountet wird. Dies macht das Einbinden etwas effizienter.

Ob das Mounten erfolgreich durchgeführt werden kann, testet man anschließend mit folgendem Befehl (als Root-User):

mount -a

Nun stehen die Freigaben direkt nach dem Systemstart zur Verfügung.

Windows

Auch unter Windows kann man die Freigaben temporär oder dauerhaft einbinden.

Temporärer Zugriff auf die Freigaben per Explorer

Um im Explorer direkten Zugriff auf die Freigaben zu erhalten, gibt man einfach die entsprechende Adresse des Samba-Servers ein, z.B. \\192.168.178.60. Nach der Eingabe von Benutzername und Passwort werden die Freigaben angezeigt:

Direkter Zugriff auf die Freigaben (Windows)

Direkter Zugriff auf die Freigaben (Windows)

Dauerhaftes Einbinden unter Windows

Um die Eingaben dauerhaft einzubinden, nutzt man im Explorer einfach die Funktion Netzlaufwerk verbinden:

Windows: Netzlaufwerk verbinden

Windows: Netzlaufwerk verbinden

Im zweiten Schritt werden die Daten des Netzlaufwerks angegeben:

Windows: Verbindung mit Netzlaufwerk herstellen

Windows: Verbindung mit Netzlaufwerk herstellen

Neben dem zuzuweisenden Laufwerks-Buchstaben und dem Netzwerk-Pfad der Freigabe sollte die Option Verbindung mit anderen Anmeldeinformationen herstellen gewählt werden. Anschließend gibt man Benutzername und Passwort des Linux/Samba-Users an.

Fazit

Ein Samba-Server ist schnell auf einem Linux Server installiert. Die Konfiguration erfordert etwas Handarbeit. Gerade für Freigaben, die mehreren Benutzern zur Verfügung stehen sollen, sind zwei Varianten möglich (ACL und Bilden von Gruppen). Ich bevorzuge hier die Nutzung von ACLs, da das Konfigurieren der Freigaben bei Samba sehr viel einfacher erfolgen kann.

Wenn der Samba-Server fertig konfiguriert ist, steht dieser dauerhaft als Speicherort im Netzwerk zur Verfügung. Durch das weit verbreitete SMB-Protokoll können diese Freigaben dann auf beliebigen Systemen eingebunden werden.

Links

]]>
https://decatec.de/linux/samba-auf-ubuntu-server/feed/ 4
Nextcloud: Die eigenen Cloud auf neue Domain umziehen https://decatec.de/home-server/nextcloud-die-eigenen-cloud-auf-neue-domain-umziehen/ https://decatec.de/home-server/nextcloud-die-eigenen-cloud-auf-neue-domain-umziehen/#comments Thu, 16 May 2019 15:04:47 +0000 https://decatec.de/?p=5622 Nextcloud Logo

In diesem Artikel soll es um die Änderung der Domain einer bestehenden Nextcloud-Instanz gehen. Dies sollte zwar im Normalfall nicht notwendig sein, dennoch gibt es einige denkbare Szenarien, bei dem der Umzug auf eine andere Domain erforderlich sein kann.

Beispiel: Beim Self-Hosting kommt im privaten Bereich oftmals eine DynDNS-Adresse zum Einsatz. Einmal im Router eingerichtet, wird die DynDNS-Domain dann auf die (öffentliche) IP-Adresse des Routers gemappt. Folglich ist der eigene Server dann direkt aus dem Internet über die DynDNS-Domain erreichbar.

Allerdings ist man nun in gewissem Maße vom DynDNS-Anbieter abhängig. Ist ein solcher Dienst dann mal nicht verfügbar (z.B. durch technische Probleme beim Anbieter) oder wird komplett eingestellt (was bei kostenlosen Anbietern durchaus mal passieren kann), dann ist die eigenen Cloud nicht mehr aus dem Internet erreichbar.

Genau dann kann es erforderlich sein, den DynDNS-Provider zu wechseln, was meistens eine neue Domain für die Cloud bedeutet.

Update-Historie (letztes Update 17.08.2019)
  • 17.08.2019:
    • acme.sh sollte nicht mit Root-Rechten ausgeführt werden, daher wird für die Ausführung von acme.sh ein spezieller User angelegt.
  • 18.05.2019:
    • dynv6 als weiteren empfohlenen DynDNS-Dienst hinzugefügt.

 

Voraussetzungen

Als Basis dient folgendes System:

  • Betriebssystem: Ubuntu Server 18.04
  • Webserver: nginx
  • Let’s Encrypt Client: acme.sh
  • Nextcloud 16

Allerdings können auch andere Distributionen, Webserver und Let’s Encrypt Clients zum Einsatz kommen. Die gezeigten Schritte sind also generell auch auf andere Systeme übertragbar, auch wenn hier ggf. Anpassungen an die jeweilige Umgebung erfolgen muss.

Ich gehe im folgenden davon aus, dass das bestehende Nextcloud-Setup voll funktionsfähig ist und nur auf eine andere Domain umgezogen werden soll. Grundlage dafür ist der Artikel Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban.

Für die Generierung der HTTPS-Zertifikate nutze ich das Shell-Script acme.sh, mehr Infos dazu findet man im Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx. Ebenfalls nutze ich hier sowohl RSA- als auch ECDSA-Zertifikate („hybrid“). Was es damit auf sich hat, findet man im Artikel RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung).

Wie immer empfiehlt es sich, vor Änderungen an Nextcloud ein komplettes Backup der Cloud vorzunehmen. Mehr Informationen zu dem Thema findet man im Artikel Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript.

Die neue Domain

Die Cloud soll also umgezogen werden? Ein Backup ist erstellt? Dann kann es losgehen…

Im Rahmen des Artikels nutze ich beispielhaft die Domains alt.meinedomain.de und neu.meinedomain.de. Damit ist jederzeit klar, welche Domain (alt oder neu) gerade gemeint ist.

Zunächst braucht man jedoch überhaupt eine neue Domain, die man als DynDNS-Domain verwenden kann. Dazu gibt es sog. DynDNS-Dienste. Viele davon sind kostenlos, einige verlangen einen geringen Preis für ihre Dienste. Es gibt auch Webspace-Provider, die die Möglichkeit bieten, Domains als DynDNS-Domains zu deklarieren. Ein (aus eigener Erfahrung) empfehlenswerter Anbieter ist hier All-Inkl.com (Affiliate Link) (ab dem Paket „Privat Plus“).

Bei den kostenlosen DynDNS-Diensten gibt es mittlerweile sehr viele Anbieter. Aus Gründen des Datenschutzes sollte man bei der Auswahl darauf achten, Anbieter mit Serverstandort Deutschland zu wählen.
Meiner Meinung nach sind beispielsweise folgende Anbieter empfehlenswert:

Zum Thema kostenlos vs. kostenpflichtig: Die meisten kostenlosen DynDNS-Dienste werden privat, oder durch kleine Vereine/Unternehmen betreut. Hier kann es passieren, dass ein Dienst mal eine Zeit lang (z.B. durch eine technische Störung) nicht erreichbar ist und es ein paar Stunden oder gar Tage dauert, bis wieder alles wie gewohnt funktioniert. Auch könnten solche Dienste einfach vom einen auf den anderen Tag eingestellt werden.
Bei kostenpflichtigen Diensten gibt es meist einen (professionellen) Support, der im Fehlerfall auch schnell helfen kann. Auch ist es hier unwahrscheinlich, dass ein solcher Dienst von heute auf morgen einfach eingestellt wird.
Das soll nun aber keineswegs heißen, dass man mit kostenpflichtigen DynDNS-Diensten besser bedient ist als mit kostenlosen Diensten. Auch kostenlose DynDNS-Anbieter können eine hohe Verfügbarkeit und einen guten Support bieten.

Neue Domain im Router hinterlegen

Wenn eine neue Domain vorliegt, muss diese erst einmal als neue DynDNS-Domain im Router hinterlegt werden. Leider hängt das genaue Vorgehen sowohl von Marke/Modell des Routers, als auch vom DnyDNS-Domain-Provider ab, so dass ich hier keine detaillierte Beschreibung liefern kann.

Wichtig ist, dass nach dieser Änderung sämtliche Webdienste (v.a. Nextcloud) nicht mehr über die alte Domain erreichbar sind.

Für produktive Nextcloud-Instanzen sollte man hier im Vorfeld die Benutzer darauf aufmerksam machen, dass ein Domain-Umzug stattfindet und die Cloud für einen gewissen Zeitraum nicht mehr erreichbar ist. Recht komfortabel kann man die mit der Nextcloud-App Announcement center lösen, indem man als Administrator eine Benachrichtigung an alle Cloud-User schickt.

Hier ist es generell empfehlenswert, die Nextcloud direkt vor dem Domain-Umzug in den Maintenance-Mode zu versetzten. Das sorgt dafür, dass keine Verbindungen zur Cloud möglich sind und beugt Datenverlusten vor, wenn Cloud-Benutzer gerade aktiv mit der Cloud arbeiten:

sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --on

Neue Domain im Webserver hinterlegen und HTTPS-Zertifikate erzeugen

Also nächstes müssen die vHost(s) von nginx so konfiguriert werden, dass diese auf den neuen Domain-Namen hören. Angepasst werden muss hier nur der Gateway-Host:

nano /etc/nginx/conf.d/meinedomain.de.conf

Hier muss die Variable server_name auf den neuen Domain-Namen angepasst werden:

server_name neu.meinedomain.de 192.168.178.60;

Dies muss sowohl im server-Block für HTTP, als auch im server-Block für HTTPS angepasst werden.

Anschließend wird der Webserver neu gestartet:

service nginx restart

Hier sollten keine Fehlermeldungen angezeigt werden.

Anschließend muss das Let’s Encrypt-Zertifikat für die neue Domain erzeugt werden.

Hinweis: acme.sh sollte nicht mit Root-Rechten ausgeführt werden, daher sollte ein spezieller User eingerichtet werden, mit dem die Zertifikate generiert/verwaltet werden. Wie hierfür vorzugehen ist, kann dem Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx entnommen werden.

Diesen Befehl am besten kopieren und mittels Suchen und Ersetzen in einem beliebigen Texteditor die eigene Domain einfügen – das beugt Tippfehlern vor:

acme.sh --issue -d neu.meinedomain.de --keylength 4096 -w /var/www/letsencrypt --key-file /etc/letsencrypt/neu.meinedomain.de/key.pem --ca-file /etc/letsencrypt/neu.meinedomain.de/ca.pem --cert-file /etc/letsencrypt/neu.meinedomain.de/cert.pem --fullchain-file /etc/letsencrypt/neu.meinedomain.de/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

Wenn RSA und ECDSA-Zertifikate parallel eingesetzt werden sollen, dann ist der Befehl nochmals für ECDSA zu wiederholen:

acme.sh --issue -d neu.meinedomain.de --keylength ec-384 -w /var/www/letsencrypt --key-file /etc/letsencrypt/neu.meinedomain.de/key.pem --ca-file /etc/letsencrypt/neu.meinedomain.de/ca.pem --cert-file /etc/letsencrypt/neu.meinedomain.de/cert.pem --fullchain-file /etc/letsencrypt/neu.meinedomain.de/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

Zum Schluss müssen die neuen Zertifikate noch dem Webserver bekannt gemacht werden. Dazu wird die Datei editiert, mit der auf die Zertifikate für den vHost verwiesen wird. Ich nutze hier eine spezielle Datei, in der alle SSL-Einstellungen enthalten sind, diese können aber auch direkt im Gateway-Host enthalten sein.

nano /etc/nginx/snippets/ssl.conf

Hier werden einfach die neuen Zertifikate angegeben:

# Certificates used
# RSA
ssl_certificate /etc/letsencrypt/neu.meinedomain.de/rsa/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/neu.meinedomain.de/rsa/key.pem;
 
# ECC
ssl_certificate /etc/letsencrypt/neu.meinedomain.de/ecc/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/neu.meinedomain.de/ecc/key.pem;
 
# This should be ca.pem (certificate with the additional intermediate certificate)
# See here: https://certbot.eff.org/docs/using.html
ssl_trusted_certificate /etc/letsencrypt/neu.meinedomain.de/ecc/ca.pem;
 
# Diffie-Hellman parameter, recommended 4096 bits
ssl_dhparam /etc/nginx/dhparams/dhparams.pem;

Wie schon zuvor: Wenn sowohl RSA- als auch ECDSA-Zertifikate genutzt werden, sind beide Varianten anzugeben.

Im Listing ist auch die Einbindung der Diffie-Hellman-Parameter zu sehen. Diese müssen bei einem Domain-Umzug nicht neu erzeugt werden, sondern können wiederverwendet werden.

Nach diesen Änderungen ist der Webserver neu zu starten:

service nginx restart

Der Webserver ist nun für den Domain-Umzug vorbereitet, nun kann es mit der Nextcloud-Konfiguration weitergehen.

Nextcloud für neue Domain konfigurieren

Neben der Anpassung des Webservers sind ebenfalls Änderungen in Nextcloud durchzuführen.

Hierzu öffnet man einfach die config.php von Nextcloud:

nano /var/www/nextcloud/config/config.php

Prinzipiell sind hier alle Werte anzupassen, die auf die alte Domain verweisen. Hier wird dementsprechend der neue Domain-Name gesetzt. Meistens sind das die folgenden zwei Variablen: trusted_domains und overwrite.cli.url:

<span class="s1">'overwrite.cli.url'</span> <span class="o">=&gt;</span> <span class="s1">''</span><span class="p">,</span>

'trusted_domains' =>
  array (
    '192.168.178.60',
    'neu.meinedomain.de',
  ),
'overwrite.cli.url' => 'neu.meinedomain.de',

Nun ist es an der Zeit, den Maintenance-Mode der Nextcloud wieder zu deaktivieren, damit die Cloud wieder im Internet erreichbar ist:

sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --off

Mit einem Aufruf der Nextcloud im Browser sollten nun keine Fehlermeldungen erscheinen. Ebenso sollte man einen kurzen Blick in die Admin-Oberfläche der Cloud werfen (Einstellungen > Verwaltung > Übersicht). Unter Sicherheits- & Einrichtungswarnungen sollten keine Warnungen angezeigt werden.

In der Nextcloud Admin-Oberfläche sollten keine Warnungen angezeigt werden

In der Nextcloud Admin-Oberfläche sollten keine Warnungen angezeigt werden

Auch im Nextcloud-Log (Einstellungen > Verwaltung > Protokollierung) sollten keine Meldungen bzgl. der neuen Domain zu finden sein.

Damit der der Domain-Umzug erst einmal abgeschlossen.

Abschließende Tätigkeiten

Nach dem erfolgreichen Domain-Umzug ist es wichtig, dass alle Clients ab sofort nur noch die neue Domain nutzen können. Somit müssen sämtliche Clients aller Benutzer der Nexcloud-Instanz auf die neue Domain umgestellt werden. Hier sollte man als Admin mit erhöhtem „Support-Aufkommen“ rechnen.

Wenn dies erledigt ist und man sicher ist, dass die alten Zertifikate nicht mehr gebraucht werden, dann können die Zertifikate der alten Domain vom Server entfernt werden. Mit folgendem Befehl sollten zunächst sowohl die neuen, als auch noch die alten Zertifikate angezeigt werden:

acme.sh --list

Diese alten Zertifikate können nun entfernt werden:

acme.sh --remove -d alt.meinedomain.de

Wenn neben RSA-Zertifikaten auch ECDSA-Zertifikate zum Einsatz kommen, muss das ECDSA-Zertifikat separat entfernt werden:

acme.sh --remove -d alt.meinedomain.de --ecc

Nach der Ausführung dieser Befehle ist das Zertifikat acme.sh nicht mehr bekannt und es wird auch nicht mehr per Cronjob erneuert. Die Zertifikats-Dateien verbleiben jedoch noch auf der Festplatte des Systems. in welchem Verzeichnis die nicht mehr genutzten Zertifikate liegen, zeigt acme.sh beim Entfernen der Zertifikate an (z.B. /etc/letsencrypt/alt.meinedomain.de). Dieses Verzeichnis kann anschließend entfernt werden:

rm -r /etc/letsencrypt/alt.meinedomain.de

Eine erneute Auflistung der installierten Zertifikate über den List-Befehl von acme.sh sollte nun nur noch das neue Zertifikat anzeigen.

Fazit

Der Artikel hat gezeigt, wie man die eigene Cloud in wenigen Schritten auf eine neue Domain umziehen kann. Das sollte im Normalfall eigentlich nicht notwendig sein, aber wenn wirklich mal eine neue Domain benötigt wird, dann braucht man Nextcloud nicht nochmals komplett neu aufsetzen. Das spart dem Admin Arbeit und die Benutzer können ihre gewohnte Nextcloud-Umgebung weiterhin nutzen – lediglich unter einer neuen Domain.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-die-eigenen-cloud-auf-neue-domain-umziehen/feed/ 4
Eigener Firefox Sync Server mit nginx https://decatec.de/home-server/eigener-firefox-sync-server-mit-nginx/ https://decatec.de/home-server/eigener-firefox-sync-server-mit-nginx/#comments Thu, 02 May 2019 13:17:44 +0000 https://decatec.de/?p=5492 Firefox Logo

Ein Browser ist auf fast allen Plattformen wohl das am meisten genutzte Programm. Nach den Browserkriegen sind leider viele Browser auf der Strecke geblieben, so dass es heutzutage nur noch zwei ernstzunehmende Alternativen gibt: Firefox und Chrome.

Wer Wert auf Datenschutz und Privatsphäre legt, wird allerdings um Chrome einen großen Bogen machen und stattdessen lieber Firefox nutzen.

Firefox bietet schon sehr lange ein Feature mit dem alle Browser-Einstellungen in der Cloud synchronisiert werden: Firefox Sync. Dazu wird ein Firefox-Konto benötigt, mit dem man sich im Browser einloggt. Anschließend können alle Firefox-Einstellungen (Lesezeichen, Chronik, verwendete Addons, etc.) mit der Mozilla-Cloud synchronisiert werden und sind so auch auf mehreren Endgeräten immer auf dem aktuellsten Stand.

Damit vertraut man der Mozilla Foundation seine Daten an. Die Speicherung erfolgt dabei meistens auf US-Servern. Wer dies nicht möchte, kann zunächst einmal keine Synchronisierung bei Firefox verwenden, so dass alle Einstellungen und Addons mit jeder Browser-Installation immer manuell konfiguriert werden müssen.

Allerdings kann man auch auf dem eigenen Server einen Firefox Sync Server installieren und über diesen synchronisieren. In diesem Fall profitiert man von den Sync-Funktionen des Browsers und stellt sicher, dass alle Daten nur auf dem privaten Server gespeichert werden.

Dieser Artikel zeigt nun die Installation und Konfiguration eines eigenen Firefox Sync Servers.

Hinweis: Dieser Artikel ist eher etwas für Fortgeschrittene. Den Firefox Sync Server kann man nicht einfach installieren, sondern dieser muss erst aus dem entsprechenden Repository auf GitHub gecloned und anschließend selbst gebaut werden. Auch die Konfiguration ist alles andere als trivial. Daher sollte man schon etwas Erfahrung mit Linux mitbringen.

Übrigens: Wem es hauptsächlich nur um die Synchronisierung von Lesezeichen im Browser geht, der muss nicht unbedingt einen eigenen Firefox Sync Server betreiben. In diesem Fall können bei einer vorhandenen Nextcloud-Instanz die Lesezeichen auch einfach über die private Cloud synchronisiert werden. Wie das genau funktioniert, wurde bereits in einem anderen Artikel erklärt: Nextcloud: Lesezeichen synchronisieren mit Chrome/Firefox

Update-Historie (letztes Update 08.05.2019)
  • 08.05.2019:
    • Hinwies hinzugefügt, dass die Angabe eines eigenen Sync Servers für Firefox auf iOS nicht funktioniert (siehe hier).
  • 05.05.2019:
    • Ergänzende Informationen hinzugefügt, falls andere Datenbank-Systeme für den Sync Server zum Einsatz kommen sollen (PostgreSQL oder MySQL/MariaDB).

 

Voraussetzungen

Alle Schritte wurden mit Ubuntu Server 18.04 LTS durchgeführt, sollten aber auch mit anderen Distributionen funktionieren.

Voraussetzung ist auf jeden Fall ein bereits fertig konfigurierter Webserver (in diesem Fall nginx). Dieser muss bereits so eingerichtet sein, dass Verbindungen mittels HTTPS möglich sind.

Die gezeigte Konfiguration basiert darauf, dass der Firefox Sync Server auf einer eigenen Subdomain (firefox-sync.meinedomain.de) betrieben wird. Es ist allerdings auch möglich, den Server in einem Unterverzeichnis des Webservers zu betreiben (z.B. meinedomain.de/firefox-sync). Hier unterscheidet sich lediglich die Webserver-Konfiguration (vHost). Dies wird im Abschnitt über die Webserver-Konfiguration behandelt.

Da eine detaillierte Beschreibung der Webserver-Konfiguration den Rahmen des Artikels sprengen würde, verweise ich an dieser Stelle auf weitere Artikel, die für das Thema relevant sind:

Installation

Wie bereits erwähnt, kann der Firefox Sync Server nicht einfach über die Paketverwaltung installiert werden, sondern es sind einige manuelle Handgriffe notwendig.

Wir beginnen wie üblich damit, das System auf den neusten Stand zu bringen:

apt-get update && apt-get upgrade -V

Anschließend werden die Pakete installiert, die wir zum Bauen des Sync Servers benötigen:

apt-get install make python-dev git-core python-virtualenv g++

Nun wird das entsprechende GitHub-Repository gecloned und der Sync Server gebaut:

cd /opt
git clone https://github.com/mozilla-services/syncserver
cd syncserver
make build

Die Dateien für den Sync Server liegen dann unter /opt/syncserver.

Konfiguration

Nun geht es an die Konfiguration des Sync Servers.

Als erstes benötigen wir ein „Secret“, welches dann später in der Konfiguration angegeben wird. Auch wenn es so wirkt: Dieser Schritt ist nicht optional, ohne Angabe des Secrets wird der Sync Server später nicht funktionieren.
Um das Secret zu erzeugen, nutzen wir einfach folgenden Befehl (anschließend in die Zwischenablage kopieren):

head -c 20 /dev/urandom | sha1sum

Danach kann es auch schon an die Bearbeitung der Konfiguration gehen:

cd /opt/syncserver
nano syncserver.ini

Hier zunächst die komplette Datei zur Übersicht:

[server:main]
use = egg:gunicorn
host = 127.0.0.1
port = 5000
workers = 1
timeout = 30

[app:main]
use = egg:syncserver

[syncserver]
# This must be edited to point to the public URL of your server,
# i.e. the URL as seen by Firefox.
public_url = https://firefox-sync.meinedomain.de

# By default, syncserver will accept identity assertions issued by
# any BrowserID issuer.  The line below restricts it to accept assertions
# from just the production Firefox Account servers.  If you are hosting
# your own account server, put its public URL here instead.
identity_provider = https://accounts.firefox.com/

# This defines the database in which to store all server data.
sqluri = sqlite:////opt/syncserver/syncserver.db

# This is a secret key used for signing authentication tokens.
# It should be long and randomly-generated.
# The following command will give a suitable value on *nix systems:
#
#    head -c 20 /dev/urandom | sha1sum
#
# If not specified then the server will generate a temporary one at startup.
secret = b6ff9a32108ca32272bcf8322b5274e93031fb90

# Set this to "false" to disable new-user signups on the server.
# Only requests by existing accounts will be honoured.
# allow_new_users = true

# Set this to "true" to work around a mismatch between public_url and
# the application URL as seen by python, which can happen in certain reverse-
# proxy hosting setups.  It will overwrite the WSGI environ dict with the
# details from public_url.  This could have security implications if e.g.
# you tell the app that it's on HTTPS but it's really on HTTP, so it should
# only be used as a last resort and after careful checking of server config.
force_wsgi_environ = true

Erläuterungen zu den einzelnen Einstellungen:

  • host = 127.0.0.1: Sorgt dafür, dass der Sync Server nur lokal aufgerufen werden kann – die Kommunikation „nach außen“ übernimmt später ja nginx.
  • public_url = https://firefox-sync.meinedomain.de: Dies ist die öffentliche URL des Sync Servers. Die konkrete URL hängt dabei von der Webserver-Konfiguration ab (siehe nächster Abschnitt).
  • identity_provider = https://accounts.firefox.com/: Zur Authentifizierung wird ein vorhandener Firefox-Account eingesetzt.
  • sqluri = sqlite:////opt/syncserver/syncserver.db: Angabe der Datenbank, in der die synchonisierten Objekte gespeichert werden. Hier verwenden wir einfach eine SQLite Datenbank, es wäre aber auch möglich, eine PostgreSQL oder MySQL/MariaDB Datenbank zu verwenden (Erläuterungen siehe unten).
  • secret = b6ff9a32108ca32272bcf8322b5274e93031fb90: Hier wird einfach der Wert eingetragen, den wir gerade über die Kommandozeile generiert haben.
  • allow_new_users = true: Dies sorgt dafür, dass automatisch neue Benutzerkonten angelegt werden, wenn sich diese zum erstem Mal mit diesem Sync Server verbinden. Wenn dieser Wert auf false gesetzt wird, wird die Synchronisierung für neue Accounts nicht mehr funktionieren (dazu später mehr).
  • force_wsgi_environ = true: Diese Einstellung muss in der gezeigten Konfiguration auf true gesetzt werden und sogt dafür, dass der Sync Server auch dann noch funktioniert, wenn die Public URL (die über nginx konfiguriert wird) von der URL abweicht, die der Sync Server intern „sieht“. Durch die Verwendung von nginx als Proxy für den Sync Server werden diese beiden URLs in diesem Kontext nie gleich sein, daher muss der Wert an dieser Stelle angepasst werden.

Ergänzende Informationen bei anderen Datenbanken

Für kleinere Sync Server Instanzen reicht die SQLite-Datenbank vollkommen aus. Ebenso ist diese am einfachsten zu konfigurieren, da hier keine zusätzlichen Schritte erforderlich sind.

Allerdings können auch andere Datenbank-Systeme zum Speichern der Daten eingesetzt werden, z.B. PostgreSQL oder MySQL/MariaDB. Empfehlenswert dürfte dies nur bei Servern sein, die sehr viele Nutzer bedienen müssen, oder wenn das entsprechende Datenbank-System bereits auf dem Server installiert ist. Aus diesem Grund gehe ich bei den folgenden Schritten davon aus, dass PostgreSQL bzw. MySQL/MariaDB bereits auf dem System installiert und konfiguriert ist.

PostgreSQL

Um eine Verbindung zu PostgreSQL herstellen zu können, sind ein paar zusätzliche Programme zu installieren:

apt-get install postgresql-server-dev-10 python-pip
cd /opt/syncserver
./local/bin/pip install psycopg2

Nun muss noch eine Datenbank speziell für den Sync Server erstellt werden. Am besten geschieht das über die PostgreSQL Kommandozeile:

sudo -u postgres psql

Die Datenbank mit dem entsprechenden User wird dann folgendermaßen angelegt:

CREATE USER firefox_sync_db_user WITH PASSWORD 'MeInPaSsw0rT';
CREATE DATABASE firefox_sync_db WITH OWNER firefox_sync_db_user TEMPLATE template0 ENCODING 'UTF8'

Beendet wird die PostgreSQL Kommandozeile durch die Eingabe von /q.

In der syncserver.ini wird die Verbindung zur Datenbank dann mittels dieser Einstellung konfiguriert:

sqluri = postgresql://firefox_sync_db_user:MeInPaSsw0rT@localhost/firefox_sync_db

MySQL/MariaDB

Ähnliche Schritte sind durchzuführen, wenn MySQL/MariaDB zum Einsatz kommt:

apt-get install python-pip
cd /opt/syncserver
./local/bin/pip install PyMySQL

Anschließend öffnet man die MySQL-Kommandozeile:

mysql -u root -p

Nun folgt die Anlage der Datenbank:

CREATE USER firefox_sync_db_user@localhost IDENTIFIED BY 'MeInPaSsw0rT';
CREATE DATABASE firefox_sync_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL PRIVILEGES on firefox_sync_db.* to firefox_sync_db_user@localhost;
FLUSH privileges;
exit;

In der syncserver.ini wird die Datanbnak dann folgendermaßen angesprochen:

sqluri = pymysql://firefox_sync_db_user:MeInPaSsw0rT@localhost/firefox_sync_db

Webserver konfigurieren

Bevor das System nun einsatzfähig ist, muss zunächst noch der Webserver entsprechend konfiguriert werden. Die genauen Details zur Konfiguration des Webservers würden leider den Rahmen des Artikels sprengen, daher erwähne ich hier nur zwei mögliche Webserver-Konfigurationen.

Wichtig ist hier nur, dass der Webserver bereits so konfiguriert ist, dass dieser mittels HTTPS angesprochen werden kann und die Verbindung damit stets verschlüsselt ist.

Nach der Anpassung des Webserver muss dieser in jedem Fall noch neu gestartet werden:

service nginx restart

Wichtig: Je nach verwendeter Konfiguration unterscheidet sich die URL, unter der der Sync Server erreichbar ist. Dies muss im weiteren Verlauf des Tutorials beachtet werden, da entsprechende URLs angepasst werden müssen.

Sync Server mit eigener Subdomain

Wenn der Sync Server mit einer eigenen Subdomain betrieben werden soll (https://firefox-sync.meinedomain.de), dann benötigt man einen separaten vHost, der für diese Subdomain verantwortlich ist.

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name firefox-sync.meinedomain.de;

        root /var/www;

	location / {
		return 301 https://$host$request_uri;
	}
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name firefox-sync.meinedomain.de;

        # Include SSL configuration (and certificates)
        include /etc/nginx/snippets/ssl.conf;

	# Include headers
        include /etc/nginx/snippets/headers.conf;

        #
        # Configuration for Firefox Sync Server
        #

        location / {
		proxy_set_header Host $http_host;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_redirect off;
                proxy_read_timeout 120;
                proxy_connect_timeout 10;
                proxy_pass http://127.0.0.1:5000/;
        }
}

Sync Server in einem Unterverzeichnis des Webservers

Man kann den Sync Server allerdings auch in einem Unterverzeichnis einer bereits bestehenden (Sub-)Domain installieren. Die URL lautet dann beispielsweise https://meindomain.de/firefox-sync

Hierzu muss ein bereits bestehender vHost, der für die Domain meinedomain.de verantworlich ist, um folgenden location-Block erweitert werden. Die hinzuzufügenden Zeilen sind hier markiert:

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;
	server_name meinedomain.de;

	# Include SSL configuration
	include /etc/nginx/snippets/certs_pub.conf;
	include /etc/nginx/snippets/ssl.conf;

	# Include headers
	include /etc/nginx/snippets/headers.conf;

	location ^~ /firefox-sync/ {
		proxy_set_header Host $http_host;
		proxy_set_header X-Forwarded-Proto $scheme;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_redirect off;
		proxy_read_timeout 120;
		proxy_connect_timeout 10;
		proxy_pass http://127.0.0.1:5000/;
	}
}

Sync Server starten

Manueller Start

Nun kann der Sync Server über folgenden Befehl gestartet werden:

cd /opt/syncserver
make serve

Hier sollten keine Fehler angezeigt werden. Die Anzeige ist allerdings „live“, d.h. es scheint erst einmal so, als ob nichts weiter passieren würde:

./local/bin/gunicorn –paste ./syncserver.ini
[2019-04-27 17:23:21 +0000] [2292] [INFO] Starting gunicorn 19.6.0
[2019-04-27 17:23:21 +0000] [2292] [INFO] Listening at: http://127.0.0.1:5000 (2292)
[2019-04-27 17:23:21 +0000] [2292] [INFO] Using worker: sync
[2019-04-27 17:23:21 +0000] [2296] [INFO] Booting worker with pid: 2296

Daher stoppen wir nach diesem kurzen Test den Prozess mit STRG+C.

Nun ist es natürlich nicht optimal, wenn man den Sync Server immer manuell starten muss und dieser dann immer die Konsole blockiert. Hier könnte man sich zwar mit einem Screen weiterhelfen, aber das ist auch nicht die beste Lösung. Der Sync Server sollte im Idealfall direkt bei Systemstart automatisch mitgestartet werden.

Autostart

Um dies zu erreichen, legen wir zunächst einen eigenen User für den Sync Server an:

useradd firefox-sync -s /bin/false --no-create-home

Dieser User muss der Owner des Programmverzeichnisses sein:

chown -R firefox-sync:firefox-sync /opt/syncserver

Nun kann auch schon eine systemd Unit angelegt werden:

nano /etc/systemd/system/firefox-sync.service

Mit folgenden Zeilen wird die Unit definiert:

[Unit]
Description=Firefox Sync Server
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
User=firefox-sync
Group=firefox-sync
Umask=007
Restart=on-abort
ExecStart=/opt/syncserver/local/bin/gunicorn --paste /opt/syncserver/syncserver.ini

[Install]
WantedBy=multi-user.target

Nun sollte der Service über folgenden Befehl gestartet werden können (anschließend mit service firefox-sync status testen):

service firefox-sync start

Damit der Service nun immer automatisch bei Systemstart hochgefahren wird, ist noch ein Befehl notwendig:

systemctl enable firefox-sync

Am besten auch hier nochmal das System neu starten und dann mit service firefox-sync status prüfen, ob der Autostart auch wirklich klappt.

Browser-Konfiguration

Bevor nun Firefox den neuen Sync Server nutzen kann, sollte noch ein kurzer Test erfolgen, ob der Sync Server wie gewünscht zu erreichen ist. Dazu einfach die URL des eigenen Sync Servers in die Adress-Leiste des Browsers eingeben (https://firefox-sync.meinedomain.de). Der Browser sollte dies mit einer simplen Meldung „it works!“ quittieren. Wenn es noch nicht wie erwartet funktioniert, wird eine Meldung ausgegeben, die einen Hinweis auf das Problem liefern sollte. In diesem Fall muss zunächst dieses Problem beseitigt werden, da ansonsten kein Browser mit dem Sync Server synchronisieren kann.

Wenn der Sync Server einwandfrei läuft, kann man nun Firefox so konfigurieren, dass dieser auch den eigenen Sync Server nutzt.

Wenn der Browser schon über ein Firefox-Konto synchronisiert wurde, muss die Verknüpfung mit diesem Konto zunächst einmal getrennt werden, da sich ansonsten kein neuer Sync Server konfigurieren lässt. Dazu einfach in die Browser-Einstellungen gehen, unter Firefox-Konto findet man die Schaltfläche zum Trennen des Kontos.

Nun fragt Firefox, ob er die bereits synchronisierten Daten  auch lokal entfernen soll. Hier sollte man keine Optionen anhaken, sondern einfach nur auf Nur trennen klicken.

Die Verbindung zum Firefox-Konto wird erst einmal getrennt

Die Verbindung zum Firefox-Konto wird erst einmal getrennt

Für die Angabe des eigenen Sync Servers muss man nun in die erweiterte Browser-Konfiguration wechseln, indem man in der Adress-Leiste about:config eingibt.

Hier suchen wir nun nach folgendem Wert: identity.sync.tokenserver.uri

Mit einem Doppelklick kann der Wert geändert werden und wir geben hier die URL des eigenen Sync Servers an: https://firefox-sync.meinedomain.de/token/1.0/sync/1.5

Über about:config wird der eigene Sync-Server angegeben

Über about:config wird der eigene Sync-Server angegeben

Wichtig ist, dass neben der eigentlichen Domain, die man in der syncserver.ini angegeben hat, noch die Erweiterung token/1.0/sync/1.5 notwendig ist.

Nachdem die Einstellung gesetzt ist, muss der Browser kurz beendet und neu gestartet werden. Nun kann man wieder in die Account-Einstellungen in Firefox gehen und die Verbindung zum Firefox-Konto wieder herstellen. Der Account an sich ist dabei der gleiche, aber der verwendete Sync Server ist nun ein anderer.

Nach ein paar Augenblicken sollte die erste Synchronisierung erfolgreich durchgelaufen sein. Allerdings erhält man keine Fehlermeldung, wenn der Sync aus irgendeinem Grund nicht klappen sollte. Daher gibt man am besten nach der ersten Synchronisierung about:sync-log in die Adress-Zeile des Browsers ein. Hier sollten dann keine Einträge zu finden sein, die zeitlich zur ersten Synchronisierung passen.

Falls doch, kann man dem Eintrag öffnen und Firefox gibt technische Details zu diesem Fehler preis. Damit sollte man den Fehler dann weiter eingrenzen können.

Diese Schritte zur Verbindung vom Firefox zum eigenen Sync Server müssen dann auf allen Rechnern wiederholt werden, damit nur noch der eigene Sync Server genutzt wird.

Auf Mobilgeräten (z.B. Firefox auf Android) funktioniert das Vorgehen übrigens analog: Firefox-Konto trennen, about:config bearbeiten und erneut mit dem Firefox-Konto anmelden. Leider funktioniert die Angabe eines eigenen Sync Servers unter Firefox für iOS (noch) nicht (siehe hier).
Die mobile Version von Firefox zeigt hier übrigens in den Einstellungen Details zum verwendeten Sync Server an (bei Firefox für den Desktop ist das leider nicht der Fall).

Firefox auf Android zeigt die URL des verwendeten Sync Servers an

Firefox auf Android zeigt die URL des verwendeten Sync Servers an

Abschließende Schritte

Wenn man nun alle Firefox-Konten auf den eigenen Sync Server umgehoben hat, sollten noch ein paar Schritte durchgeführt werden.

Sync Server auf bekannte Accounts beschränken

Der Sync Server wäre nun öffentlich über das Internet erreichbar. Damit niemand sonst den Server nutzen kann, wird das Anlegen neuer User im Sync Server einfach unterbunden:

cd /opt/syncserver
nano syncserver.ini

Hier ändern wir einfach den entsprechenden Konfig-Eintrag:

allow_new_users = false

Ab jetzt können sich keine neuen Accounts mehr am Sync Server anmelden. Wenn man hier nachträglich doch noch andere Firefox-Accounts hinzufügen möchte (z.B. für Familienmitglieder), dann muss man diesen Wert natürlich temporär wieder auf true ändern.

Abschließend wird der Sync Server neu gestartet:

service firefox-sync restart

Daten auf den Mozilla-Servern entfernen

Ganz zum Schluss kann man ebenfalls sämtliche Daten von den Mozilla-Servern entfernen. Hier kann ein einfaches Script genutzt werden. Wenn die Zwei-Faktor-Authentifizierung für den Firefox-Account aktiv ist, muss diese zuvor alledings deaktiviert werden, da das Skript ansonsten auf Fehler läuft. Nach dem Ausführen des Skripts kann diese wieder aktiviert werden.

apt-get update && apt-get install python-pip
cd /opt/syncserver
pip install PyFxA
python ./bin/delete_user_data.py meine@email.de

Die E-Mail-Adresse muss natürlich die Adresse des eigenen Mozilla-Accounts sein.

Sync Server updaten

Von Zeit zu Zeit können Updates für den Sync Server erscheinen. In diesem Fall kann man das Update auch lokal „nachziehen“.

Zunächst wird dazu der Service gestoppt:

service firefox-sync stop

Da Update an sich funktioniert dann wieder über git:

cd /opt/syncserver
git stash
git pull
git stash pop
make build

Nun werden noch die Rechte entsprechend angepasst:

chown -R firefox-sync:firefox-sync /opt/syncserver

Der Service sollte sich danach problemlos mit service firefox-sync start gestartet werden können. Auch das automatische Starten nach Systemstart sollte weiterhin funktionieren.

Fazit

Zugegeben: Die Einrichtung eines eigenen Firefox Sync Servers ist nicht gerade einfach, da dieser nicht einfach aus der Paketverwaltung der verwendeten Distribution installiert werden kann. Da ist schon einiges an Handarbeit notwendig.

Wenn man die Schritte durchgearbeitet hat, kann man aber sicher sein, dass die Browser-Daten nicht mehr in „irgendeiner Cloud“ synchronisiert werden, sondern ausschließlich auf dem eigenen Server gespeichert werden.

Es wird zur Synchronisierung zwar weiterhin ein Firefox-Konto benötigt, dieses dienst von nun an allerdings nur noch zur Authentifizierung. Die Daten werden nur noch mit dem eigenen Firefox Sync Server abgeglichen.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/eigener-firefox-sync-server-mit-nginx/feed/ 44