Liebe Gemeinde, hier ein Erfahrungsbericht über meine Migration nach v7:
Nach Anleitung mit Hilfe eines von sophomorix-vampire-example abgeleiteten Skriptes
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;rl-pr03;manage;5C:B9:01:EB:56:18;10.16.12.96;;1;1;1;1;1;0; ## drucker
danach so aussieht:
rl;rl-pr03;manage;5C:B9:01:EB:56:18;10.16.12.96;---;---;1;classroom-studentcomputer;---;1;0; ## drucker;;MIGRATION;1
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/
es gibt beim subnetting fast nichts zu ändern. Ich habe in der Konfiguration:
# 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;
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.
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:
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
sudo -u www-data php /opt/nextcloud/occ ldap:show-config sudo -u www-data php /opt/nextcloud/occ ldap:delete-config s01
sudo -u www-data php $occ ldap:check-user kuechel
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