Merge branch 'main' of gitpot.org:tbz/m158

docs/migration/README.md

@@ -3,9 +3,105 @@
 ## Inhaltsverzeichnis
 
 - [Inhaltsverzeichnis](#inhaltsverzeichnis)
+- [Vorbereitung](#vorbereitung)
 - [Vom alten Node migrieren](#vom-alten-node-migrieren)
 - [Altes Node auflösen](#altes-node-auflösen)
 
+## Vorbereitung
+
+Nach langem nachdenken haben wir doch entschieden eine dedizierte IP zu bestellen, da Clustering von zwei Hosts über einer SOCKS5 Proxy schlecht verlaufen wird. Deswegen probieren wir es erst recht nicht, und sparen uns die Mühe.
+
+![ip order](../../assets/migration/ip-order.png)
+
+Zum Glück kostet so eine IPv4 nicht so viel. Wir bestellen hier nur eine, da wir kein Subnetz oder eine Failover IP brauchen.
+
+![ip order confirmation](../../assets/migration/ip-order-2.png)
+
+Das geht auch sehr schnell, schon ist der Bestellauftrag raus. Sobald die IP Adresse konfiguriert ist, sollte eine Mail ankommen.
+
+![ip configured](../../assets/migration/ip-order-3.png)
+
+Jetzt müssen wir die VM und Wings selber noch umkonfigurieren:
+
+1. **Netzwerkinterface von Wings VM ändern**
+
+   ![change interface of vm](../../assets/migration/interface-change.png)
+
+   Dann muss man auch noch die richtige MAC-Adresse setzen, um MAC-Address-Spoofing zu vermeiden. Diese ist in diesem Screenshot jetzt einfach nicht sichtbar.
+
+2. **Neue IP Adresse auf VM konfigurieren**
+
+    ```bash
+    # edit netplan config
+    $ vim /etc/netplan/50-cloud-init.yaml
+    ```
+
+    ![old configuration of IPs](../../assets/migration/old-config.png)
+
+    wird zu
+
+    ![new configuration of IPs](../../assets/migration/new-config.png)
+
+    geändert
+
+    Dann fehlt noch ein Reload der Konfiguration:
+
+    ```bash
+    # apply netplan
+    $ netplan apply
+    ```
+
+    ![ip addr](../../assets/migration/ip-addr-command.png)
+
+3. **Wings Konfiguration anpassen**
+
+   Wings muss jetzt auch von der neuen IP Adresse wissen, denn momentan ist die Verbindung wieder gekappt. Dazu gehen wir zurück ins Panel → Administrationspanel → Nodes → `kubelo` Editieren → Settings:
+
+   ![changes to configuration](../../assets/migration/changes-to-configuration.png)
+
+   Hier ändern wir nur diese Optionen. Die neue Konfiguration ist mit der `nest.sangelo.space` erreichbar (die A Records wurden bereits erstellt), Wings sollte über einer SSL Verbindung erreichbar sein (konfigurieren wir jetzt gleich), und die neue Konfiguration ist nicht hinter einer Proxy.
+
+   Bevor wir hier speichern, pflanzen wir kurz SSL Zertifikate auf dem Server.
+
+4. **SSL Zertifikate**
+
+   Um auf dem Server Zertifikate zu installieren, nutzen wir `certbot`, da dieses Tool das dramatisch vereinfacht und auch automatisiert.
+
+   ```bash
+    # install certbot
+    $ sudo apt update && sudo apt install certbot
+    
+    # get DNS challenge instructions
+    $ certbot -d nest.sangelo.space --manual --preferred-challenges dns certonly
+   ```
+
+   ![certbot](../../assets/migration/certbot-initial-steps.png)
+
+   Wir erstellen jetzt dieses TXT-Record auf der Domain, und klicken nach ein paar Minuten auf Enter um weiterzumachen.
+
+   ![certbot finish](../../assets/migration/certbot-finish.png)
+
+   Das Zertifikat ist jetzt aktiv und einsatzbereit. In einer Produktionsumgebung würde man diesen Prozess von hier an automatisieren, aber das würde hier zu viel zum Dokumentieren sein.
+
+5. **Verbinden**
+
+   Nachdem Wings die neue Konfiguration und den angepassten Zertifikatspfaden lesen kann, sollte die Verbindung zu Wings klappen, nachdem wir den Service neustarten
+
+   ```bash
+   # restart wings
+   $ systemctl restart wings.service
+   ```
+
+   Jetzt können wir im Pterodactyl Panel sehen, wie die Verbindung aufgebaut wird:
+
+   ![healthy node](../../assets/migration/healthy-node.png)
+
 ## Vom alten Node migrieren
 
+- [ ] volumes rsync
+- [ ] manual server creation
+- [ ] copy files from copied volumes into new volumes
+- [ ] update migration plan
+- [ ] test servers
+
 ## Altes Node auflösen