[[umstieg-v7-erfahrungsbericht]]
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
| umstieg-v7-erfahrungsbericht [2019/09/07 01:40] – Tobias | umstieg-v7-erfahrungsbericht [2019/09/07 18:36] (aktuell) – [Cloud umstellen] Tobias | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| + | {{tag> }} | ||
| + | |||
| + | Liebe Gemeinde, hier ein Erfahrungsbericht über meine Migration nach v7: | ||
| + | |||
| + | ====== Vorbereitungen ====== | ||
| + | |||
| + | - Ich habe mich entschieden, | ||
| + | - Ich habe mich entschlossen zu migrieren und die PW der User zu übernehmen und nicht die User komplett neu anzulegen. | ||
| + | - Ich habe MRBS vom Server umgezogen auf ein docker-basiertes system. Statt https:// | ||
| + | - Ich habe nach Anleitung kvm installiert und die aktuellen Images reingepackt, | ||
| + | - Ich habe ein Vollbackup der Server, Firewall und Docker Appliance gemacht, vor dem linuxmuster-setup | ||
| + | - Snapshot vor linuxmuster-setup, | ||
| + | |||
| + | ====== Migration ====== | ||
| + | |||
| + | Nach Anleitung mit Hilfe eines von sophomorix-vampire-example abgeleiteten Skriptes | ||
| + | |||
| + | - [x] Klassen: 8min | ||
| + | - [x] User: 62min | ||
| + | - [x] Passworthashes importieren: | ||
| + | - [x] Klassenadministratoren importieren: | ||
| + | - [x] Projekte importieren: | ||
| + | - [x] Konfigurationsdateien importieren: | ||
| + | - [x] Updates diverser Einstellungen: | ||
| + | - [x] Rechner importieren | ||
| + | - [x] Synchronisiere Benutzerdaten | ||
| + | - [x] LINBO synchronisieren | ||
| + | |||
| + | Diese Migration hat zur Folge, dass User ihre Passwörter nicht neu generiert bekommen, sondern die alten behalten. | ||
| + | |||
| + | Kommentar: Wer seine Rechner in seiner workstations mit einem Kommentar am Ende der Zeile gepflegt hat, so wie ich, der bekommt bei der Migration ein Problem, da eine Zeile: | ||
| + | < | ||
| + | rl; | ||
| + | </ | ||
| + | danach so aussieht: | ||
| + | < | ||
| + | rl; | ||
| + | </ | ||
| + | ===== Umstellung ===== | ||
| + | |||
| + | Bei der Umstellung setze ich die IP des alten Servers auf 10.16.1.2 und IPFire wird abgeschalten. | ||
| + | Dafür bekommt OpnSense die IP von IPFire und der Server läuft auf 10.16.1.1 los. | ||
| + | |||
| + | - ssh-keys wären sinnvoll: Am besten man kopiert die alten SSH-Keys vom alten Server in /root/.ssh/ auf den neuen Server in /root/.ssh/ | ||
| + | |||
| + | ===== subnetting ===== | ||
| + | |||
| + | es gibt beim subnetting fast nichts zu ändern. Ich habe in der Konfiguration: | ||
| + | <code / | ||
| + | # server subnet definition | ||
| + | 10.16.0.0/ | ||
| + | |||
| + | # Servernetz - vlan 10 (subnet rsrv) | ||
| + | # Internet - vlan 20 | ||
| + | # Lehrernetz - vlan 12 (subnet rl) | ||
| + | 10.16.12.0/ | ||
| + | # Allgemeines Schuelernetz - vlan 14 | ||
| + | 10.16.14.0/ | ||
| + | # R302 - vlan 16 | ||
| + | 10.16.16.0/ | ||
| + | # R219 - vlan 17 | ||
| + | 10.16.17.0/ | ||
| + | # R202 - vlan 18 | ||
| + | 10.16.18.0/ | ||
| + | |||
| + | </ | ||
| + | <note warning> | ||
| + | Achtung, wenn man einen Fehler macht, dann kann es sein, dass man nach dem ausgeführten Befehl nicht mehr auf die Firewall oder den Docker kommt, man kann sich also aussperren. Daher: Snapshot machen. | ||
| + | |||
| + | Achtung, wenn man linuxmuster-import-subnets zwei mal ausführt, dann ist die netplan-config ok aber die tatsächlichen routen sind zum Teil doppelt (stand: Sept. 2019). Ein Neustart des Servers räumt da auf. | ||
| + | </ | ||
| + | |||
| + | ===== Cloud umstellen ===== | ||
| + | |||
| + | Problem: uid heißt jetzt samaccountname, | ||
| + | |||
| + | Ich hatte das Glück, dass es bei mir so war, das DATA-Verzeichnis von nextcloud | ||
| + | < | ||
| + | root@jones: | ||
| + | drwxrwxr-x | ||
| + | drwxrwxr-x | ||
| + | drwxrwxr-x | ||
| + | drwxrwxr-x | ||
| + | drwxrwxr-x | ||
| + | drwxrwx--- 1055 www-data www-data | ||
| + | -rw-r----- | ||
| + | </ | ||
| + | |||
| + | * Backup der kompletten Cloudinstallation | ||
| + | * Clonen der kompletten Cloudinstallation, | ||
| + | * Cloud hochfahren, möglichst schnell den cron-dämon abschalten bzw. / | ||
| + | * in der Console der Cloud die LDAP-Konfiguration der lmn6 löschen: | ||
| + | < | ||
| + | sudo -u www-data php / | ||
| + | sudo -u www-data php / | ||
| + | </ | ||
| + | * als lokaler admin einloggen, app " | ||
| + | * Die wichtigste Einstellung ist die letzte: Ich habe auch noch zusätzlich einmal die LDAP-Gruppennamenzuordnung gelöscht, damit die Gruppen nicht " | ||
| + | * nach der umstellung auf der console noch folgende Tests benutzen, um zu sehen, ob die LDAP-User erkannt werden und existieren: | ||
| + | < | ||
| + | sudo -u www-data php $occ ldap: | ||
| + | </ | ||
| + | * Diesen Test musste ich für jeden Benutzer zweimal ausführen, dann wurde der Benutzer als " | ||
| + | <code bash> | ||
| + | occ="/ | ||
| + | data="/ | ||
| + | hardlist=`mktemp` | ||
| + | |||
| + | pv --version > /dev/null | ||
| + | if [ $? -ne 0 ] ; then | ||
| + | apt install pv | ||
| + | fi | ||
| + | |||
| + | echo -n " | ||
| + | ls $data | grep -v " | ||
| + | echo `cat / | ||
| + | |||
| + | echo " | ||
| + | for i in `cat / | ||
| + | echo -n "$i: " | ||
| + | if sudo -u www-data php $occ ldap: | ||
| + | # not a local user? | ||
| + | if ! sudo -u www-data php $occ user:info " | ||
| + | echo " | ||
| + | fi | ||
| + | fi | ||
| + | done | ||
| + | |||
| + | ## zweiter durchlauf: | ||
| + | echo " | ||
| + | for i in `cat / | ||
| + | if sudo -u www-data php $occ ldap: | ||
| + | # not a local user? | ||
| + | if ! sudo -u www-data php $occ user:info " | ||
| + | echo " | ||
| + | fi | ||
| + | echo -n " | ||
| + | else | ||
| + | echo -n " | ||
| + | fi | ||
| + | done | pv -s `cat / | ||
| + | exit | ||
| + | </ | ||
[[umstieg-v7-erfahrungsbericht]]
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Share Alike 4.0 International
