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 18.06.2021)- 18.06.2021:
- Aufruf von acme.sh mit Parameter „server“, so dass Zertifikate über Let’s Encrypt bezogen werden.
- 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.
Inhalt
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 --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
Falls noch nicht bekannt, einen weiteren Dyn-DNS Anbieter der auch IPv6 macht:
Free dynamic DNS for IPv6
https://dynv6.com/
Hi Martin,
ja, damit konnte ich auch schon positive Erfahrungen sammeln.
Ich habe den Dienst mal in die Liste der empfehlenswerten Anbieter aufgenommen.
Danke für den Hinweis!
Gruß,
Jan
Hallo Jan,
Danke für die Anleitung, hat nach ein wenig probieren alles funktioniert.
Ich hatte Probleme bei der Einbindung der Zertifikate. Mir war nicht klar, dass ich die Verezichnisse (neu.meinedomain.de/rsa und neu.meinedomain.de/ecc) erzeugen musste und den acme Befehl ein wenig anpassen muss, damit es mit der ssl.conf übereinstimmt.
Ich habe noch ein Frage, kann ich die meinedomain.de.conf in neu.meinedomain.de.conf umbenennen bzw. erzeugen. Dann liegen meinedomain.de.conf und neu.meinedomain.de.conf in dem Verzeichnis.
Weiterhin habe ich die vHost Dateien nach dem Muster meinedomain.de_nextcloud.conf benannt. Kann ich die umbenennen – in neu.meinedomain.de_netcloud.conf?
Muss ich bei der ganzen Umbenennerei was beachten?
Hintergrund ist, dass ich gerne einheitlich und sauber halten würden.
Gruß
Hans
Hi Hans,
wie die vHosts Dateien auf der Dateisystem-Ebene benannt sind, ist vollkommen egal. Du kannst diese Dateien also beliebig umbenennen.
nginx lädt einfach alle Dateien im Verzeichnis /etc/nginx/conf.d, die mit „.conf“ enden.
Gruß,
Jan
Sehr geehrter Herr Rehe,
aktuell habe ich Schwierigkeiten mit dem Hoster, ist diese Aussage korrekt?:
„Sie haben bei uns einen Cloud Shop den Sie nicht umziehen können einfach zu einem anderen Provider. Den AUTH Code und die Daten (Artikel) können Sie natürlich haben aber nicht die Shopsoftware“
Mit freundlichen Grüßen
Thomas R.
Hallo Thomas,
ich weiß nicht, was der Anbieter unter einem „Cloud Shop“ versteht. Das klingt für mich auch eher wie eine Besonderheit des Hosters. Wenn du vollen Zugriff per SSH hast, dann kann man eine Nextcloud sicher zu einem neuen Provider/einen anderen Server portieren.
Gruß,
Jan
Hallo Jan,
gibt es eigentlich eine Möglichkeit die bestehende Zertifikate auf eine andere Hardware zu „übertragen“ ?
Aktuell versuche ich einen neuen Server aufzubauen. Es scheitert aber schon beim ersten Erzeugen der RSA-Zertifikate.
…. Connection refused
Gehe nach der Anleitung vor:
https://decatec.de/home-server/nextcloud-auf-ubuntu-server-22-04-lts-mit-nginx-postgresql-mariadb-php-lets-encrypt-redis-und-fail2ban/#Generierung_der_Zertifikate.
Auf dem „alten“ Rechner läuft NC noch und die Zertifikate wurden am 16.07 erneuert.
Hast du eventuell eine Idee was ich falsch mache?
Gruss Ernst-Peter
Hallo Ernst-Peter,
übertragen brauchst du die Zertifikate eigentlich gar nicht, sondern diese müssen auf der neuen Maschine nur neu ausgestellt werden (das sind dann die gleichen Befehle wie beim ersten Erzeugen der Zertifikate).
Das Problem könnte bei dir eher sein, dass das Port-Forwarding noch auf den alten Rechner „zeigt“. Dies musst du dann auf den neuen Rechner einstellen. Beides parallel geht leider nicht.
Gruß,
Jan