umstieg-v7-erfahrungsbericht [CommunityWiki]

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
{{tag> }}


Liebe Gemeinde, hier ein Erfahrungsbericht über meine Migration nach v7:

====== Vorbereitungen ======

  - Ich habe mich entschieden, die Netzwerkmaske zu behalten (10.16.1.1/12), weil das keine rekonfiguration der Netzwerkswitche nach sich zieht. Wenn ich aber mal 10.0.0.0 haben will. Muss ich von ganz vorne ran (server neu aufsetzen), so wie ich das verstanden habe
  - 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://server/mrbs komme ich jetzt mit einer eigenen externen URL daher https://buchen.meinetolle-schule.de. OSP verwenden wir nicht intern, ebenso kein Pykota, ebenso kein moodle, ebenso kein user-basiertes mailing (außer die Medienbildung 5, aber die müssen halt warten)
  - Ich habe nach Anleitung kvm installiert und die aktuellen Images reingepackt, siehe http://docs.linuxmuster.net/de/v7/appendix/install-on-kvm/index.html
  - Ich habe ein Vollbackup der Server, Firewall und Docker Appliance gemacht, vor dem linuxmuster-setup
  - Snapshot vor linuxmuster-setup, dann Ausführen von linuxmuster-setup auf der Konsole (SELMA wäre auch gegangen), nachdem alles reibungslos lief: Domäne lautet nun linuxmuster.meinetolle-schule.de, meinetolle-schule.de geht ja nicht, weil "meinetolle-schule" länger als 15 Zeichen ist. restart von Selma oder reboot des servers, Freischalten der IPs 10.16.1.4-10.16.1.10  (no-proxy alias) in der Firewall, weil dort automatisch 10.16.0.1-10.16.0.10 freigeschalten wird.

====== Migration ======

Nach Anleitung mit Hilfe eines von sophomorix-vampire-example abgeleiteten Skriptes

  - [x] Klassen: 8min
  - [x] User: 62min
  - [x] Passworthashes importieren: 13min
  - [x] Klassenadministratoren importieren: 2min
  - [x] Projekte importieren: 4min
  - [x] Konfigurationsdateien importieren:  0min
  - [x] Updates diverser Einstellungen: 2min
  - [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:
<code>
rl;rl-pr03;manage;5C:B9:01:EB:56:18;10.16.12.96;;1;1;1;1;1;0; ## drucker
</code>
danach so aussieht:
<code>
rl;rl-pr03;manage;5C:B9:01:EB:56:18;10.16.12.96;---;---;1;classroom-studentcomputer;---;1;0; ## drucker;;MIGRATION;1
</code>
===== 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 /etc/linuxmuster/subnets.csv>
# server subnet definition
10.16.0.0/12;10.16.1.253;10.16.1.100;10.16.1.200;SETUP

# Servernetz - vlan 10 (subnet rsrv)
# Internet - vlan 20
# Lehrernetz - vlan 12 (subnet rl)
10.16.12.0/24;10.16.12.254;10.16.12.100;10.16.12.110;MIGRATION;
# Allgemeines Schuelernetz - vlan 14 
10.16.14.0/24;10.16.14.254;;;MIGRATION;
# R302 - vlan 16
10.16.16.0/24;10.16.16.254;;;MIGRATION;
# R219 - vlan 17
10.16.17.0/24;10.16.17.254;10.16.17.100;10.16.17.150;MIGRATION;
# R202 - vlan 18
10.16.18.0/24;10.16.18.254;10.16.18.100;10.16.18.150;MIGRATION;

</code>
<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.
</note>

===== Cloud umstellen =====

Problem: uid heißt jetzt samaccountname, falls das nicht unter der Experteneinstellung vorgenommen wurde, haben die User intern jetzt alle UUIDs als interne Namen. Dann kann man die Nextcloud installation nicht weiter verwenden. STattdessen müssen in einer neuen installation alle Daten zugeordnet werden und die Shares müssen neu erzeugt werden.

Ich hatte das Glück, dass es bei mir so war, das DATA-Verzeichnis von nextcloud  sah unter der lmn6 schon so aus: 
<code>
root@jones:~# ls -lart /srv/nextcloud/data/ | tail
drwxrwxr-x    3 www-data www-data      4096 Sep  3 01:55 schneime
drwxrwxr-x    3 www-data www-data      4096 Sep  3 01:55 segerol
drwxrwxr-x    3 www-data www-data      4096 Sep  3 01:55 sternma
drwxrwxr-x    3 www-data www-data      4096 Sep  3 01:55 tothbe
drwxrwxr-x    3 www-data www-data      4096 Sep  3 01:55 tranbi
drwxrwx--- 1055 www-data www-data     36864 Sep  3 01:55 .
-rw-r-----    1 www-data www-data  93116098 Sep  7 17:04 nextcloud.log
</code>

  * Backup der kompletten Cloudinstallation
  * Clonen der kompletten Cloudinstallation, dann snapshot machen, zu dem man zurückkommt, wenn irgendetwas nicht richtig erscheint
  * Cloud hochfahren, möglichst schnell den cron-dämon abschalten bzw. /etc/cron.d/nextcloud auskommentieren.
  * in der Console der Cloud die LDAP-Konfiguration der lmn6 löschen:
  <code>
sudo -u www-data php /opt/nextcloud/occ ldap:show-config
sudo -u www-data php /opt/nextcloud/occ ldap:delete-config s01
</code>
  * als lokaler admin einloggen, app "circles" deaktiviert, "Home_auf_Server"-ExterneSeiten entfernt und die LDAP-Konfiguration nach Anleitung erstellt: https://ask.linuxmuster.net/t/anbindung-nextcloud-anleitung/3854  
  * Die wichtigste Einstellung ist die letzte: Ich habe auch noch zusätzlich einmal die LDAP-Gruppennamenzuordnung gelöscht, damit die Gruppen nicht "teachers_2" heißen, weil es "teachers" schon gibt. Allerdings darf man *nicht* die LDAP-Uidnamenzuordnung löschen.
  * nach der umstellung auf der console noch folgende Tests benutzen, um zu sehen, ob die LDAP-User erkannt werden und existieren:
  <code>
sudo -u www-data php $occ ldap:check-user kuechel
</code>
  * Diesen Test musste ich für jeden Benutzer zweimal ausführen, dann wurde der Benutzer als "exists" akzeptiert. Als komplettes Skript:
  <code bash>
occ="/opt/nextcloud/occ"
data="/srv/nextcloud/data"
hardlist=`mktemp`

pv --version > /dev/null
if [ $? -ne 0 ] ; then
    apt install pv
fi

echo -n "Erstelle Liste: "
ls $data | grep -v "\." | grep -vE "(appdata|files_external|rainloop|__groupfolders|updater-)" > /tmp/userlist
echo `cat /tmp/userlist | wc -l` "user"

echo "Checke, ob User noch in LDAP sind:"
for i in `cat /tmp/userlist` ; do
    echo -n "$i: "
    if  sudo -u www-data php $occ ldap:check-user "$i" ; then
        # not a local user?
        if ! sudo -u www-data php $occ user:info "$i" 2>/dev/null >/dev/null ; then
            echo "--->   has no user:info"
        fi
    fi
done 

## zweiter durchlauf:
echo "Checke, ob User noch in LDAP sind:"
for i in `cat /tmp/userlist` ; do 
    if  sudo -u www-data php $occ ldap:check-user "$i" | grep "not" 2>/dev/null >/dev/null ; then
        # not a local user?
        if ! sudo -u www-data php $occ user:info "$i" 2>/dev/null >/dev/null ; then
            echo "$i" >> $hardlist
        fi
        echo -n "x"
    else
        echo -n "."
    fi
done | pv -s `cat /tmp/userlist | wc -l` > /dev/null
exit
</code>
Benutzer-Werkzeuge

Webseiten-Werkzeuge

Seiten-Werkzeuge
