Nextcloud: Die eigenen Cloud auf neue Domain umziehen

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.

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:

• DDNS Service
• deSEC
• dynv6

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 --server letsencrypt --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 --server letsencrypt --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:

'overwrite.cli.url' => '',

'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.

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

• Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
• Let’s Encrypt Zertifikate mit acme.sh und nginx
• RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung)
• Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript

Links

• Dynamisches DNS (Wikipedia)
• acme.sh (GitHub)
• DDNS Service
• deSEC

Ähnliche Artikel:

RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung) Nextcloud: Online-Office mit ONLYOFFICE (mit eigener Subdomain) Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban Let’s Encrypt Zertifikate mit acme.sh und nginx