Ich habe das mal mir der Flughöhe ausgerechnet und kam damals auf eine RTT von unter 30ms. - die Dinger fliegen nur ein paar hundert Kilometer tief.
Damit dürfte der Umweg über den/die Satelliten eigentlich nur wenige ms Unterschied ausmachen. Von dir im Garten hoch zum Satelliten, vom Satelliten dann weiter nach Frankfurt(?) und der Rest geht per normalem Kabel.
Alles anzeigenHallo allerseits,
ich hätte da mal einige Fragen zur Vorgehensweise im Detail und hoffe auf hilfreiche Hinweise - falls mir jemand helfen könnte.
Ausgangssituation:
ein vServer mit einer eigenen Domain (nennen wir sie hier beispiel.de), eigener Mailserver (Postfix/Dovecot) unter mail.beispiel.de und Webserver beispiel.de, anwendung.beispiel.de und cloud.beispiel.de
Ziel:
Es ist beabsichtigt ein Webhosting zunächst zusätzlich aufzumachen und einzelne der genannten Services möglichst ohne längeren Ausfall (< 2h) umzuziehen
Wie bewerkstellige ich das - hauptsächlich im Hinblick auf DNS? Dateien und DBs zu kopieren und die Anwendungen auf die neuen DBs und Pfade zu konfigurieren sollte ich problemlos hinkriegen und es dürfte relativ schnell gehen - es sind keine großen Datenmengen.
Meine Überlegungen/Fragen:
- brauche ich während des Umzugs für das Webhosting eine eigene Domain? (z.B. beispiel2.de)
- Oder kann ich auf dem vServer z.B. die DNS Definition von mail.beispiel.de löschen und auf dem Webhosting neu definieren?
- Dazu sollte ich vorher doch wohl alle Mail-Accounts auf dem vServer mit Mail-Clients exportiert haben, damit ich sie im Webhosting auf die dortige Mail-Infrastruktur importieren kann, oder wäre der netcup mailsync Service hier brauchbar? Könnte man dort als Serveradresse auch IP Adressen statt Namen angeben?
- Falls ich dazu erst eine Domain beispiel2.de und mail.beispiel2.de definieren müsste, wie kriege ich die später (nach dem Umzug der E-Mails) dann wieder auf mail.beispiel.de umbenannt?
- Kann man das irgendwie auch mit "redirects" lösen, so wie ich z.B. per .htaccess einen Browser von einer Domain beispiel42.de auf beispiel.de umleiten kann?
Hätten Sie / hättet Ihr zu dieser Aufgabenstellung hilfreiche (gerne auch nur high-level) Vorschläge?
Vielen lieben Dank,
Richard.
Einiges ist mir unklar bzw macht mich stutzig. Deinen Punkt 2 verstehe ich erst mal gar nicht. DNS Definition löschen und auf dem Webhosting neu definieren? Soll denn die Domain umgezogen werden? Soll sie eventuell sogar eine Inklusivdomain des Webhostings werden? Oder doch eher eine externe Domain, die nur als solche eingebunden werden soll im Webhosting. Wo liegt sie derzeit überhaupt, netcup oder anderswo? Benutzt sie die netcup Nameserver für ihr DNS?
Zu 2.1 würde ich sagen, der netcup Mailsync Service kann benutzt werden, auch IP-Adressen können da angegeben werden für die IMAP-Server.
Bei 2.2 bin ich mir nicht ganz sicher, wüsste jetzt aber erst einmal nicht, wie man da nachträglich bei Mail die Domain ändern könnte. Das Postfach ist fest mit der E-Mail-Adresse verknüpft, für die es erstellt wurde. Bestenfalls könnte man vielleicht was mit Mailaliasen machen, aber auch die funktionieren doch nur, wenn die Domain der Adressen gleich ist. Aber vielleicht hat ja jemand eine glorreiche Idee.
Allgemein ist das netcup Webhosting beim Einbinden externer Domains leider nicht sehr flexibel. Es gibt da eine Liste von DNS-Einträgen, die vorhanden sein müssen und auch auf das Webhosting zeigen müssen. Sonst wird die Domain nicht eingebunden. Ist sie mal eingebunden, dann kann man die Einträge weitgehend beliebig verändern/entfernen. Aber erst einmal müssen sie eben drin sein
Hmm, mein vermeintlicher VPS 500 von oben ist tatsächlich nur ein VPS 200 G10s. Wenn ich den jetzt mit dem VPS 500 von Valkyrie vergleiche, dann gebe ich den für einen VPS 500 G11 nicht her. Ok, hat natürlich 2 vCores mehr und 2GB mehr RAM, dreifachen SSD-Speicher, aber die vCores ...
Ich hab das Terminal Fenster längst geschlossen, aber Single Core war ~930, Multi war ~1350. Der fio Test bei 1MB blocksize hatte flotte ~1,2GB/s und bei dem iperf Test hatte ein Server 7Gbit/s.
Dagegen hatte der VPS 500 eine Single Core Performance von ~300 und Multi ~990, trotz 2 Kernen mehr. Beide Server hatten zu der Zeit kein Steal, aber irgendwie kommt mir mein Ergebnis trotzdem sehr niedrig vor.
Mein getesteter G9.5 RS hatte einen Single Core Wert von ~1200. Mich wundert aber, dass bei RS die Disk Geschwindigkeit so viel geringer ist als bei VPS. Zufall/Cache/zugesicherte Ressourcen mit weniger Schwankungen?
Ich nehme an du meinst den VPS 500 G11? VPS (x86) G11 hab ich bisher noch keinen. Was für eine Disk-Performance hat denn dein RS G9.5? Ich habe meinen damals gemessen mit ca 3,7 GB/s bei 1MB blocksize. Das war jedenfalls nicht soo langsam. Single Core Wert war ca 1250. Mein älterer VPS 500 (G10?) mit 2 Cores hat am 21.7.24 Single Core 635 gebracht. Multi Core 1062. Disk bei 1m ca 1,5 GB/s. Netzwerkanbindung war ja wohl schon immer gedrosselt, bei den G11 aber offenbar mehr als früher, ebenso die fio. Tja, was nützt mir die superschnelle NVME-SSD, wenn da noch mehr gedrosselt wird als früher? Ah nee, NVME haben wohl nur die RS G11. Würde mich aber interessieren, ob da die 3,7 GB/s meines alten G9.5 dann doch wenigstens getoppt werden.
Edit: Was ist denn nun los? Da hats mir doch glatt den Beitrag in zwei Teile zerlegt. Ich zieh das Zitat mal hier mit rein
Ich hab das Terminal Fenster längst geschlossen, aber Single Core war ~930, Multi war ~1350. Der fio Test bei 1MB blocksize hatte flotte ~1,2GB/s und bei dem iperf Test hatte ein Server 7Gbit/s.
Dagegen hatte der VPS 500 eine Single Core Performance von ~300 und Multi ~990, trotz 2 Kernen mehr. Beide Server hatten zu der Zeit kein Steal, aber irgendwie kommt mir mein Ergebnis trotzdem sehr niedrig vor.
Mein getesteter G9.5 RS hatte einen Single Core Wert von ~1200. Mich wundert aber, dass bei RS die Disk Geschwindigkeit so viel geringer ist als bei VPS. Zufall/Cache/zugesicherte Ressourcen mit weniger Schwankungen?
Und ich glaube, du durftest mit dem alten Klasse 3 Schein auch noch 7,5t fahren. So konnte ich mit meinem Schwiegervater auf eigene Faust einen Umzug mit nur einmal fahren stemmen.
Wenn wir das schon aufdröseln für die Geschichtsbücher, ich denke es waren nur 7,49 Tonnen. Ab 7,5t war es nicht mehr erlaubt. Viele LKWs sind (oder waren?) deswegen 7,49t und nicht 7,5t. Ich durfte auch mal einen fahren anlässlich einer Messe. Ging zwar ganz gut, aber ich war trotzdem froh, als ich mit dem Teil wieder heil zurück war.
Das passt sogar. T-Online hat bei mir eine ziemlich schlechte Reputation. Aber woher wissen die das? 
t online special agent
Mit der Lizenz zum Töten (von Mails)
Ich "verschiebe" das mal selbst hierher, wo ich es eigentlich schreiben wollte, und lösche dann den Beitrag im völlig falschen Forenbereich... 
E-Mail ist schon was Tolles heutzutage. Dieser Tage hatte ich mit einem meiner wenig genutzten Accounts beim Webhoster XYZ ein Problem. Gesendete Mails an meine eigene und auch fremde Adressen bei g*x kamen nicht mehr an, wurden aber ganz normal im "Sent"-Ordner abgelegt. Von anderen Accounts bei anderen Anbietern und auch von meinem Mailserver kamen alle Mails an.
Also kurz nachgeforscht bei g*x, weil ich ja wusste, dass derzeit überall die Regeln für erfolgreiche Mailzustellung verschärft werden. Schnell herausgefunden, sie wollen DKIM haben. Daran muss es liegen, denn alle anderen Anforderungen gemäß deren Policy erfüllt der Account bei XYZ. Andere begnügen sich mit SPF, aber ok, kann man machen, nichts dagegen einzuwenden. Dafür verzichten sie auf SPF . DKIM Gibts bei XYZ bestenfalls auf Anfrage, hatte ich für die betreffende Domain aber mangels Notwendigkeit nie gemacht. Also alles klar, daran wird es wohl liegen. Die bei g*x wollen eine DKIM-Signatur, die habe ich nicht, daraufhin haben sie meine Mails ins schwarze Loch versenkt.
Am nächsten Tag Supportanfrage bei XYZ gestellt zwecks Hinterlegung eines Keys für meine Domain bei deren Mailserver. Eingang der Anfrage wurde sofort bestätigt, ich habe dann mal auf die erste echte Antwort gewartet. Nach ca 1,5 Tagen ohne Antwort höre ich gestern Abend den Signalton des Smartphones für eine eingehende Mail. Reingeschaut. Ein Wunder! 
Die vor mehr als 1,5 Tagen abgeschickte Testmail ist jetzt doch noch angekommen! Laut Headerzeilen vom SMTP-Server bei XYZ empfangen zu der Zeit als ich sie auch tatsächlich gesendet habe. Empfangen vom MX von g*x vom SMTP-Server bei XYZ vor 1 Minute. Hmm, recht lange Laufzeit. Aber immerhin. Daraufhin mal genauer in den Posteingang bei g*x geschaut und siehe da, die vermissten Mails waren alle da 
.
Meine Vermutung ist, der Support von XYZ hat da irgendwas gedreht oder mit g*x gedealt. Denn, ich bin verblüfft, in der zweiten Headerzeile der eingegangenen Mail steht
Authentication-Results: g*x.net; dkim=noneJa wie nun? In der E-Mail Policy von g*x steht doch ausdrücklich
[...]
(DKIM) Um die Sicherheit und Vertraulichkeit Ihrer Nachrichten zu gewährleisten, ist die Verwendung einer DKIM-Signatur verpflichtend....
[...]
Ich fühle mich ja durchaus geehrt, dass seitens g*x für mich eine Ausnahme von den Richtlinien gemacht wird, denn anderen Kunden von g*x ist diese besondere Ehre bisher nicht zuteil geworden. Gilt also "Alle Kunden sind gleich! (aber manche Kunden sind gleicher als Andere)?" Auch eine sofort losgeschickte weitere Testmail von meinem Account bei XYZ kam anstandslos im Posteingang von g*x an, während andere g*x Kunden noch auf die Zustellung ihrer Mails von Absendern bei XYZ von vor einigen Tagen warten.
Heute Morgen kam denn auch die nächste Antwort von XYZ, der ins DNS einzutragende Key wird mir demnächst per Mail von der zuständigen Fachabteilung zugeschickt. Hoffentlich stört sich g*x dann nicht an der DKIM-Signatur. 
Und hoffentlich schafft es XYZ igendwann, DKIM für alle Kunden auch ohne Anfrage zur Verfügung zu stellen.
Kündigen und durch ein 4000 SE ersetzen, das kann ebenso Python, Ruby und NodeJS - den Speicherplatz braucht (fast) niemand.
Ja, hatte eine Zeit lang mal 3 8000er, mittlerweile sind sie alle weg. Zuletzt habe ich auf dem letzten verbliebenen einen Server gesichert . Mein 4000er habe ich aber behalten und das 2000 Plus für ursprünglich 2,-€ auch.
Ich mache Bilder von Mutter Erde im Maßstab 1:1 Nee, hätte heissen sollen 30+ MB
Ausreichend schnell und stabil ist natürlich relativ. Für meine Zwecke ist die Performance bisher sicher gut ausreichend. Während des Umzugs hatte ich schon mal eine Zeit, da hat die Cloud beim Login über zuviele Zugriffe von meiner IP gemeckert und mich nicht mehr reingelassen (Brute Force Schutz von Nextcloud) Momentan ist alles ruhig, aber da tut sich in den Daten auch nicht so viel bei mir, dass es ein ständiges Problem sein könnte. Auch über die Ursache bin ich nicht ganz sicher, ich hatte da bei den Smartphone Apps teilweise Einstellungen (Zugangsdaten) nicht geändert. Wenn es passiert, ist das natürlich unangenehm, weil man die eigene IP nicht mal eben schnell entsperren kann, wie das bei einer selbst gehosteten Cloud relativ problemlos möglich wäre durch Löschen des entsprechenden Eintrags in der Datenbank. Da sitzt du dann halt bei der Storage Share vor dem PC und drehst Däumchen oder machst dir einen Kaffee.
Momentan hängen folgende Geräte und Anwendungen an der Cloud
1. Desktop PC
2. Android Smartphone
Und wahrscheinlich noch ein paar Anwendungen, die ich jetzt vergessen habe. Naja, viel wird nicht fehlen, dürfte ziemlich komplett sein die Liste.
Das läuft problemlos. Das heißt aber nicht viel, da ich der einzige User der Cloud bin und sich an den Daten jetzt auch nicht ständig viel ändert. Überhaupt sind derzeit nur ca 30 GB Daten in der Cloud. Di von der alten Cloud per Federation Share u übernehmen ging flott. Hätte das ja auch per Desktop-Client machen können, aber bei 25 MBit/s im Upload ist das dann halt doch recht zäh. Es handelt sich im Wesentlichen um Bilder, Musik und Dokumente. Die Galerien von "Photos" und "Memories" funktionieren aber flüssig, auch bei großen Bildern (30MP JPEGs mit ca 10-15MB Dateigröße) Also da merke ich jetzt keine Verschlechterung gegenüber der eigenen Cloud. Insofern bereue ich es noch nicht wirklich. Das gute Feature, bei Bedarf problemlos auf einen größeren Tarif wechseln zu können wird mir etwas vermiest mit dem großen Spung von 1 TB auf 5 TB mit entsprechend höherem Preis. Eine Option 2 TB oder 3 TB zwischendrin wäre schön gewesen. Aber gut, vielleicht kommt es ja irgendwann noch und wahrscheinlich werde ich es eh nicht brauchen. Zudem lässt sich externer Speicher einbinden, also z.B. auch eine oder mehrere 1GB Storage Box(en) 
. Sollte ich mich also je entschliessen meine RAW-Files mit 30+GB pro Bild auch da abzulegen, wäre das eine Option. Macht aber m.E. wenig Sinn die RAW-Dateien in der Nextcloud zu haben.
Eher der Bequemlichkeit. Der Luxus einsteigen und losfahren, gegen "ich muss erstmal ne Stunde mit der Frau diskutieren ob ich jetzt darf"...
Aha, also ein Fall von
Mögen hätt ich schon wollen, aber dürfen hab ich mich nicht getraut!
Ach sorry, ich dachte 'storage box' gelesen zu haben, nicht 'storage share'.
Die storage shares unterstützen ja nur webdav.
Ebenso mit rclones modified time-fähigkeit kommst du dann auch nicht weiter.
Naja, die Wogen haben sich ja mittlerweile einigermaßen geglättet. Meine bisher nur vier mit "Memories" erstellten Alben waren letztlich innerhalb einer halben Stunde wieder hergestellt. Die Timestamps waren im Prinzip schon immer falsch, aber halt näher an der Realität als jetzt nach der Kopieraktion und somit eventuell noch eher brauchbar für die Sortierung. Und außer bei den Bilder-Alben mit Memories brauche ich sie überhaupt nicht.
Neiiiiinnnn, bloß nicht.
Außerdem kennt man schließlich seine Pappenheimer – du glaubst doch nicht, jemand der Mahnmails und Briefe ignoriert, wird sich dann für rote Banner interessieren.
Doch, genau das kann rsync (spätestens mit -a sind Rechte und Zeitstempel dabei). Ich habe zwar keine Storage Box, kann mir aber nicht vorstellen, daß die RotenHausener das abgestellt hätten.
Edit: Ach, die gelegentlich auftretende Zeitstempel-Problematik und EXIF bei Bildern hast ja mittlerweile selbst rausgefunden.
Also ich habe jetzt nochmal vergeblich gesucht nach Infos über die Möglichkeit, sich per SSH mit einer Storage Share zu verbinden. Dass rsync die Timestamps erhalten kann ist mir klar. Ich gehe davon aus, es gibt gar keine Möglichkeit Daten anders als über das Webinterface, DAV oder Ähnliches auf die Storage Share zu übertragen. Storage Box ist eine andere Geschichte, da geht das definitiv. Aber die Storage Share würde ich vereinfacht beschreiben als Nextcloud ohne Konsolenzugriff. Es gibt diverse Möglichkeiten, z.B. occ-Befehle über die Verwaltungsoberfläche ausuführen und auch einige Einstellungen in der config.php in Grenzen zu verändern. Ansonsten hat man keine Möglichkeiten. Ich denke mal, wenn es eine eingeschränkte Konsole gäbe wie bei der Storage-Box, dann würden sie nicht solche Klimmzüge bei den occ-Befehlen machen. Dann könnte man die auch einfach eingeben ohne die Verwaltungssoftware bemühen zu müssen..
Allerdings scheint da auch eine gewisse Weiterentwicklung zu geben. Letztens hatte ich nach einer App-Installation - oder war es ein Update der Cloud, daher kenne ich das von selbst gehosteten Nextclouds eher - die bekannte Meldung, man möge doch mittels occ die fehlenden Indizes in der Datenbank erzeugen. Ich habe dann in der Verwaltungsoberfläche nach dem entsprechenden occ-Befehl gesucht und ihn nicht gefunden. Heute schaue ich da mal wieder rein und jetzt ist der Befehl tatsächlich verfügbar. Dafür vermisse ich in den Verwaltungseinstellungen der Cloud die Möglichkeit, die Logeinträge zu sehen ("Protokollierung") Wollte mal schauen, ob alles fehlerfrei läuft, aber keine Chance.
Alternativ könnte ich die JPGs nochmal alle(!) neu erzeugen mit EXIF-Daten, die würden dann von Memories eventuell verwendet. Die fertigen Memories Alben der alten Cloud kann ich auch nicht übertragen ohne Datenbankzugriff, jedenfalls habe ich dazu auf die Schnelle noch nichts gefunden. So ein Export/Import ist jedenfalls gut versteckt, falls es ihn gibt. Und Federation Share geht da wohl auch nicht?!? Nur lokal.
Doch mal wieder was Positives, meine bestehenden Memories-Alben werde ich relativ leicht wieder einrichten können, weil in den Bildern zwar die Aufnahmeinformationen (absichtlich) nicht im EXIF-Header stehen, aber ich habe schon bei der Erstellung der Alben zumindest Datum und Uhrzeit in die Metadaten der Bilder eingetragen. Und die werden sinnvollerweise nicht in die Datenbank eingetragen, sondern Memories speichert das dann direkt im EXIF-Header. Sehr sinnvoll und sehr praktisch für mich. Da ich die Bilder sowieso in Ordnern geordnet habe, kann ich also einfach die Bilder im Ordner dem Album hinzufügen, die Reihenfolge und die Bildinfo passt dann automatisch.
Anyway, jetzt scheint erst mal alles zu funktionieren, das Smartphone darf sich jetzt auch anmelden ohne dass ich ausgesperrt werde. Heute Morgen werde ich dann mal checken, ob auch Aufgaben, Termine, Kontakte und Kalender sauber synchronisiert werden zwischen Cloud, PC (Thunderbird) und dem Android Phone. Denke aber schon.
Denken ist Glücksache ...
Nach einigen Nacharbeiten funktionieren jetzt endlich Kalender & Co + Kontakte. Ich synchronisiere zwei Clouds mit dem Android-Geraffel. Für Kalender und Kontakte benutze ich DAVx5. Da war einiges durcheinandergekommen, weil der Benutzer im Storage Share eine andere E-Mail-Adresse hatte und dummerweise die selbe Kombination Benutzer/E-Mail-Adresse wie bei der anderen Cloud. Da hat DAVx5 wohl noch ein Problemchen, die Clouds richtig zuzuordnen. Also wenn der Benutzername und auch die E-Mail Adresse identisch sind. Den identischen Benutzernamen hatte ich bisher umgangen, indem ich unterschiedliche Mailadressen einsetzte, habe ich jetzt halt auch wiede so gemacht.
An anderer Stelle habe ich allerdings ein mittleres Chaos. Ich benutze seit zwei Monaten die Nextcloud App Memories/Erinnerungen für Alben. Sieht schon um einiges besser aus als die Alben aus der Photos-App. Muss ich mir mal in der Datenbank anschauen wie Memories genau tickt. Jedenfalls ist meine Zeitleiste ein einziges Chaos, wohl weil ich die Bilder alle aus der Freigabe von der alten Cloud in die Storage Share kopiert habe und dabei neue Timestamps erzeugt wurden. Kann man die Daten auch per FTP oder auf eine andere Weise in die Storage Share kopieren, so dass die Timestamps erhalten bleiben? Muss ich mal Doku suchen und lesen, falls es dazu was gibt. rsync per SSH geht jedenfalls nicht nach meinem derzeitigen Kenntnisstand. Alternativ könnte ich die JPGs nochmal alle(!) neu erzeugen mit EXIF-Daten, die würden dann von Memories eventuell verwendet. Die fertigen Memories Alben der alten Cloud kann ich auch nicht übertragen ohne Datenbankzugriff, jedenfalls habe ich dazu auf die Schnelle noch nichts gefunden. So ein Export/Import ist jedenfalls gut versteckt, falls es ihn gibt. Und Federation Share geht da wohl auch nicht?!? Nur lokal.
Werde wohl die alte Cloud als Backup erst noch eine Weile auf meinem ARM VPS vorhalten, sonst wird mir das alles zeitlich zu knapp. Sind ja auch noch andere Anwendungen vom Strota Server umzuziehen . Immerhin, die neue Cloud/Storage Share hat die Kalender- und Kontakt-Synchonisierung übernommen, think positive. Also im Vergleich zum 1:1 Umzug von Server 1 auf Server 2 treten hier insgesamt schon wesentlich mehr Probleme auf, für die ich teilweise noch keine gute und effiziente Lösung habe.
Boah. Jetzt habe ich hoffentlich das Gröbste hinter mir mit dem Umzug der Cloud (oder eigentlich Cloud-Daten) zum roten H. Also vor 5 Minuten habe ich hier noch laut geflucht und der Storage-Box gedroht, sie zu entsorgen und die Kündigung meines Servers bei Strota zurückzunehmen. Das muss dann doch gewirkt haben. War gut geplant und nicht so ganz daran gehalten. Da sind so einige Dinge in den neueren Nextcloud-Versionen drin, die im Zusammenspiel mit der Storage Share so richtig Ärger machen können, wenn irgendwas falsch läuft.
Fing eigentlich relativ gut an. Ich hatte die alte Cloud in den Wartungsmodus gebracht und ne Weile gewartet, bis die Clients das gemerkt hatten. Dann CNAME auf die Storage Share gesetzt und beim roten H die Subdomain eingerichtet. Hat ne ganze Weile gedauert, bis der CNAME erkannt wurde. Dann konnte ich den Nextcloud-Client auf dem PC auf das neue Passwort umstellen und er hat dann ca 20 GB Daten synchronisiert, die zwar eigentlich schon alle da waren, aber ich vermute mal der Timestamp hat ihm nicht gepasst. Ich hatte die Daten schon gestern per Federation Share übertragen und aus dem Share in die eigenen Ordner kopiert. Hätte ich mir wahrscheinlich besser geschenkt und lieber alles über den Desktop-Client synchonisiert, war aber nicht schlimm, hat eben ca 15 Minuten gekostet und war größtenteils nur Download, was bei mir 10x schneller ist als der Upload. Insofern eventuell immer noch die schnellere Variante. Dann war alles synchron und ich dachte schon, das wars im Wesentlichen. Aber ich hätte wirklich vorher das Passwort für die Storage Share auf das Passwort für die alte Cloud setzen sollen...
So hat mir das Smartphone mit dem falschen Passwort dazwischengefunkt, hätte ich wohl besser nicht im WLAN lassen sollen, damit es wenigstens eine andere IP hat. Nextcloud honoriert sowas dann mit einem Brute Force Schutz, der meine IP dann erst mal komplett ausgesperrt hat. Das hatte ich schon mal bei einem Nextcloud-Umzug, aber da war das ein 1:1 Umzug auf einen anderen Server, beides meine Server. Man bekommt die IP Blockade problemlos weg, aber nur indem man den entsprechenden Datenbank-Eintrag löscht. Aber mach das mal bei der Storage Share...
Und wenn irgendein Client zwischendurch ein paar Versuche mit dem alten Passwort macht, ist man sehr schnell ausgesperrt und kann eigentlich nur warten und hoffen, dass irgendwann kein Client mehr mit dem falschen Passwort unterwegs ist.
Anyway, jetzt scheint erst mal alles zu funktionieren, das Smartphone darf sich jetzt auch anmelden ohne dass ich ausgesperrt werde. Heute Morgen werde ich dann mal checken, ob auch Aufgaben, Termine, Kontakte und Kalender sauber synchronisiert werden zwischen Cloud, PC (Thunderbird) und dem Android Phone. Denke aber schon.
Ja, ich habe schon eine weitere Subdomain derzeit im Gebrauch, notfalls ginge das ja auch ohne eigene Subdomain mit der Originalsubdomain vom roten H. Wird schon irgendwie gutgehen. Im Notfall existiert die alte Cloud ja immer noch unverändert, die werde ich vorher auch noch über eine zweite Subdomain zugreifbar machen. Ein Vorteil der Geschichte ist, ich finde da immer noch Dinge, die gar nicht richtig funktioniert haben bei der Synchronisierung des Smartphone Kalenders und der Kontakte. Das ist bei den vorhergehenden Umzügen nicht aufgefallen, weil die Cloud ja als Ganzes kopiert wurde und ich nicht alles im Detail überprüft habe. Jetzt kopiere ich alles vorab von Cloud zu Cloud und merke erst, dass da schon immer ein (kleiner) Teil der Kontakte fehlt. Die ältesten sind nur lokal in der Android App auf dem Smartphone gespeichert.
Ja, dann muss ich aber einen andere Subdomain für die Cloud benutzen als bisher, und cloud gefällt mir halt am Besten für eine Cloud. Ansonsten ist die alte Cloud ja sofort weg. Naja, muss ich wohl sowieso mit leben, ob so oder so. Ich ziehe jetzt alles noch in Ruhe um, schalte die Synchronisiation der Clients auf dem Desktop und Notebook um, das Smartphone wird auch noch stillgelegt werden müssen. Dann CNAME und die Subdomain beim roten H anlegen und warten, bis die Subdomain auch auf die Storage Share läuft. Dann alles wieder aktivieren. Muss ich versuchen möglichst alles vollständig zu planen vor der Aktion.
Ist eben kein "normaler" Umzug von einem Server auf einen anderen, was die Cloud schon mehrfach hinter sich hat. Das hat beim letzten Umzug einer anderen Cloud aber heftig geknirscht im Vergleich zu früher. Obwohl, wenn ich es gut vorbereite vielleicht doch. Das Passwort ist derzeit noch unterschiedlich auf den Clouds, das werde ich definitiv vorher noch anpassen. Vielleicht kann ich dann auch einfach so die alte Cloud vom Netz nehmen, den CNAME und die Subdomain setzen und warten. Hmm, lese gerade zwischendurch das Nextcloud Manual zum Thema Umzug, da bin ich ja froh, dass die Clouds bisher immer den Umzug auf meine Weise überstanden haben, auch wenn sie das Logfile mit Fehlern zugemüllt haben. Andererseits, das was da alles steht, kann ich ja in dem Fall hier gar nicht machen. Die Instanzen sind ja nicht 1:1 identisch, die Datenbank kann ich auch nicht übertragen. Da müssen sich halt die Clients warm anziehen. Aber deswegen mache ich den Umzug ja auch im Sommer.
