Versionshinweise: Unterschied zwischen den Versionen

Aus CEPHALIX/CRANIX
Zeile 19: Zeile 19:
 
# Alte Umgebung völlig löschen, cranix-vpn deinstallieren, cranix-vpn2 installieren und konfigurieren. In diesem Fall muss jeder seine VPN-Client und Konfiguration neu herunterladen.
 
# Alte Umgebung völlig löschen, cranix-vpn deinstallieren, cranix-vpn2 installieren und konfigurieren. In diesem Fall muss jeder seine VPN-Client und Konfiguration neu herunterladen.
 
# Alte Umgebung Umbenennen, cranix-vpn deinstallieren, cranix-vpn2 installieren und so konfigurieren, dass diese neben dem alten openVPN-Server arbeiten kann. D.h. anderes Port und IP-Adressenbereich wählen. In diesem Fall können die alten Clients weiter betrieben werden. Neue Clients werden mit den neuen sichereren Server/Client/Zertifikat Versionen arbeiten.
 
# Alte Umgebung Umbenennen, cranix-vpn deinstallieren, cranix-vpn2 installieren und so konfigurieren, dass diese neben dem alten openVPN-Server arbeiten kann. D.h. anderes Port und IP-Adressenbereich wählen. In diesem Fall können die alten Clients weiter betrieben werden. Neue Clients werden mit den neuen sichereren Server/Client/Zertifikat Versionen arbeiten.
Für Kunden, die cranix-vpn benutzen, führen wir die Umstellung nach Vereinbarung selber durch.
+
Für Kunden, die cranix-vpn benutzen, führen wir die Umstellung nach Rücksprache selber durch.
 
</div>
 
</div>
 
* Die Migration auf CRANIX/CEPHALIX 15.6 kann man nur von CRANIX/CEPHALIX 4.5 durchführen.
 
* Die Migration auf CRANIX/CEPHALIX 15.6 kann man nur von CRANIX/CEPHALIX 4.5 durchführen.

Version vom 14. September 2024, 15:49 Uhr

1 CRANIX 15.6

Diese Version wurde am 14. August 2024 veröffentlicht. Das aktuelle ISO kann unter CRANIX-15.6 heruntergeladen werden.

1.1 Neuigkeiten

Die wichtigsten Neuerungen gegen über 4.5 sind:

  • Basissystem: openLeap/SLES 15.6
  • Sama-ad Version 4.19.X
  • WebApp (cranix-web) Update auf IONIC 8 und Angular 18.
  • Alle openLeap/SLES Repositories werden eingebunden.
  • Es ist nur noch Online-Installation möglich. Das Installationsmedium beinhaltet nur die CRANIX/CEPHALIX spezifischen Pakete. openLeap/SLES Pakete werden direkt vom download.opensuse.org geholt.
  • Als IMAP-Server steht nur noch dovecot23 zur Verfügung.
  • Umstieg von firewalld auf cranix-firewall. Mit der Version 4.4 hatte firewalld SuSEfirewall2 ersetzt. Mit diesem Tool kann man die Firewall am Server dynamisch konfigurieren. Leider hat sich herausgestellt, dass in umfangreichen Umgebungen firewalld große Performanceprobleme verursacht. Deshalb haben wir selber eine eigene Firewall-Management-Tool entwickelt cranix-firewall, welches wir mit der Version 15.6 des CRANIX-Servers eingeführt haben. Für Sie ändert sich in erster Linie nichts. Über die Adminoberfläche können Sie die Firewall wie gehabt konfigurieren. Die Oberfläche reagiert lediglich wesentlich zügiger. Wenn Sie mehr vom cranix-firewall erfahren möchten, finden Sie die Dokumentation und die Quellkode unter https://github.com/Cranix-Solutions/cranix-firewall

1.2 Migration auf 15.6

WICHTIG
cyrus-imapd
wird nicht mehr unterstützt. Die Entwickler von openSUSE haben nun die Unterstützung für cyrus-imap abgekündigt. Benutzern Sie cyrus-imapd, müssen Sie zunächst auf dovecot migrieren, bevor sie die Migration auf CRANIX-15.6 durchführen. Für unsere Kunden mit mit CRANIX-Mailserver-Support erledigen wir auch diesen Migrationsschritt.
VPN-ADDON
Es ist nicht mehr möglich neue VPN-Client Konfigurationen zu erstellen. Das Problem hat mit der neuen Versionen von OpenSSL und OpenVPN zu tun. Mit diesen kann man die alte Zertifikat-Umgebung nicht mehr nutzen. Deshalb haben wir eine neue Version von cranix-vpn erstellt cranix-vpn2. Da die alte Zertifikate nicht mehr benutzt werden können, kann man leider nicht einfach updaten.

Es gibt 2 Möglichkeiten:

  1. Alte Umgebung völlig löschen, cranix-vpn deinstallieren, cranix-vpn2 installieren und konfigurieren. In diesem Fall muss jeder seine VPN-Client und Konfiguration neu herunterladen.
  2. Alte Umgebung Umbenennen, cranix-vpn deinstallieren, cranix-vpn2 installieren und so konfigurieren, dass diese neben dem alten openVPN-Server arbeiten kann. D.h. anderes Port und IP-Adressenbereich wählen. In diesem Fall können die alten Clients weiter betrieben werden. Neue Clients werden mit den neuen sichereren Server/Client/Zertifikat Versionen arbeiten.

Für Kunden, die cranix-vpn benutzen, führen wir die Umstellung nach Rücksprache selber durch.

  • Die Migration auf CRANIX/CEPHALIX 15.6 kann man nur von CRANIX/CEPHALIX 4.5 durchführen.
  • Melden Sie sich als Benutzer root auf einem nicht grafischer Konsole an: Alt+Strg+F2 drücken.
  • Installieren Sie alle Updates: crx_update.sh
  • Starten Sie die Migration mit folgendem Befehl: /usr/share/cranix/tools/migrate-to-15.6.sh
  • Nach erfolgreichem Installation wird das System automatisch neu gestartet.
  • Würde die Migration fehlschlagen, bitte den Server nicht neu starten. Eine Supportanfrage wird automatisch gestellt und wir kümmern uns um Ihr Problem.
  • Bei evtl. Problemen wenden Sie sich an CRANIX Support!

2 CRANIX 4.5

Diese Version wurde am 7. März 2023 veröffentlicht. Das aktuelle ISO kann unter CRANIX-4-5 heruntergeladen werden.

2.1 Neuigkeiten

Die wichtigsten Neuerungen gegen über 4.4 sind:

2.2 Migration auf 4.5

  • Die Migration auf CRANIX/CEPHALIX 4.5 kann man nur von CRANIX/CEPHALIX 4.4 durchführen.
  • Melden Sie sich als Benutzer root auf einem nicht grafischer Konsole an: Alt+Strg+F2 drücken.
  • Installieren Sie alle Updates: crx_update.sh
  • Alle Updaterepositories außer CRANIX müssen entfernt werden! Der Befehl zypper lr -u muss folgende Ausgabe liefern:
Die Repository-Prioritäten sind ohne Effekt. Alle aktivierten Repositorys teilen sich die gleiche Priorität.

# | Alias  | Name   | Enabled   | GPG Check       | Refresh        | URI
 --+--------+--------+-----------+-----------------+----------------+-----------------------------------
 1 | CRANIX | CRANIX | Ja        | (  ) Nein       | Ja             | http://repo.cephalix.eu/CRANIX/4.4
  • Starten Sie die Migration mit folgendem Befehl: /usr/share/cranix/tools/migrate-to-4.5.sh
  • Nach erfolgreichem Installation wird das System automatisch neu gestartet.
  • Würde die Migration fehlschlagen, bitte den Server nicht neu starten. Eine Supportanfrage wird automatisch gestellt und wir kümmern uns um Ihr Problem.
  • Bei evtl. Problemen wenden Sie sich an CRANIX Support!

3 CRANIX 4.4

Diese Version wird am 31. Januar 2022 veröffentlicht. Das aktuelle ISO kann unter CRANIX-4-4 heruntergeladen werden. Die wichtigsten Neuerungen gegen über 4.3 sind:

  • Basissystem: openLeap 15.3
  • Sama-ad Version 4.15.X
  • firewalld ersetzt nun SuSEfirewall2.
  • sssd wird für Name Services (NS) und PAM verwendet.
  • Der Printserver-Instanz von Samba kann nun auch über einen CEPHALIX-Server konfiguriert werden.
  • Die Drucker werden nicht durch den Eintrag "load printers = yes" in der Printserverkonfiguration geladen, sondern jeder Drucker bekommt eine eigene Sektion.
  • Die Zugangskontrolle wurde völlig überarbeitet:
    • Der Zugang zum Samba-AD-Server wird durch "hosts deny" Einträge in der [global]-Sektion in der SAMBA-AD-Konfiguration (/etc/samba/smb.conf) für die einzelne Räume verboten.
    • Jeder Drucker ist nun einzel in der Printserverkonfiguration aufgelistet und hat ein Parameter "hosts allow" in dem die Netzwerk- bzw. Rechneradressen aufgelistet sind, die Zugriff auf den Drucker haben. Der Servernetz muss hier immer vorhanden sein, sonst kann der Druckertreiber nicht zugewiesen werden.
      Diese Konfiugration führt dazu, dass man nur auf Drucker Zugriff hat, die dem Raum oder Rechner zugewiesen wurde.
    • Der Zugangsstatus wird durch das Programm /usr/sbin/crx_manage_room_access.py verwaltet.
  • Es kann ein Separater Fileserverinstanz für die File-Freigaben erstellet werden. In AD-Umgebung wird  es empfohlen, dass der AD-Server nur die Freigabe [sysvol] zur Verfügung stellt. Alle anderen Freigaben sollen von einem dedizierten Server/Serverinstanz zur Verfügung gestellt werden. Damit kann man diverse Problemen vor allem mit den Windows-Profilen vermeiden und man kann die Filesystemrechte mit Unix-Acls vom Fileserver direkt setzten. Eine Trennung der Dienste ist nicht notwendig ist jedoch empfehlenswert, vor allem wenn man viele Probleme mit den Windows-Profilen hat. Der neue Instanz kann mit dem Befehl /usr/share/cranix/tools/separate-file-server.py erstellt werden. Dadurch wird eine neue Datei /etc/samba/smb-fileserver.conf erstellt und die Hauptkonfigurationsdatei /etc/samba/smb.conf angepasst. Beide Dateien dürfen anschließend nach Bedarf angepasst werden.
Der Printserverkonfiguration darf nicht manuell bearbeitet werden. Diese wird bei der Zuweisung der Drucker zu den Räumen bzw. beim Setzten des Zugriffsstatus in den Räumen neu geschrieben.

3.1 Zu beachten

  • Man kann nur von CRANIX-4-3 bzw. OSS-3.4.2 eine Migration auf CRANIX-4-4 durchführen.

3.2 Migration von der Kommandozeile starten

  • Auf eine nicht grafische Konsole wechseln! <alt>+<ctl>+<F1>
  • Melden Sie sich als root an!
  • Bitte alle Updates einspielen!
  • Die Version 4.3-lp152.52.1 oder höher von cranix-base muss installiert sein. Nur dieses Paket enthält das getestete Migrationsscript. Bitte überprüfen Sie das Paket:
# rpm -q cranix-base 
cranix-base-4.3-lp152.52.1.noarch
  • Migration mit dem Befehl /usr/share/cranix/tools/migrate-to-4-4.sh starten.
  • Nach erfolgreichem Installation wird das System automatisch neu gestartet.
  • Würde die Migration fehlschlagen, bitte den Server nicht neu starten und eine Supportanfrage an CRANIX Support senden!

4 Migration von OSS-3.4.2

4.1 Die wichtigsten Änderungen im CRANIX-4 gegenüber OSS-3.4.2

  1. Basiert auf der aktuellen openLeap-Distribution und nicht mehr auf SLES.
  2. Der OSS-3.4.2 bot einen LDAP-Server als zentraler Authentifizierungserver an. Der CRANIX-4 ist ein Active-Directory-Server. Es gibt zwar Gemeinsamkeiten aber auch wesentliche Unterschiede: AD vs LDAP , Active-Directory
  3. Aus Umstellung zur Active-Directory Server Kompatibilität und der daraus resultierenden Notwendigkeit der Eindeutigkeit von Objekt-Namen ergibt sich die Besonderheit, dass bei Benutzer, Gruppen und Workstation-Accounts mit identischen Namen nicht existieren dürfen. Deshalb wurde der Benutzer "admin" abgeschafft. Statt dessen gibt es nur den Benutzer "Administrator", der der Windows-Domänen Administrator ist. Während der Migration werden die Daten von "admin" dem Benutzer "Administrator" zugewiesen.
  4. Bisher wurde bei der Registrierung eines Rechners ein dazugehöriger Workstation-Benutzer angelegt. Nun werden nur noch Workstation-Benutzer für Geräte angelegt, welche eine Hardwarekonfiguration vom Gerätyp FatClient haben.
  5. Die kombinierte Rolle "teachers,sysadmins" gibt es nicht mehr. Im OSS 3-4 konnte man einem Lehrerbenutzer Administrationsrechte geben. Dadurch hatte dieser Zugriff auf die meisten Funktionen, die ein Systemadministrator sonst hatte. Diese Art von Rechteverteilung hat sich als zu starr erwiesen, weshalb im CRANIX-4 ein auf ACLs basierendes Rechtesystem eingebaut wurde. Mehr dazu entnehmen Sie dem Kapitel Rechtekonzept.
  6. Raumkontrolle Im OSS-3.X war es möglich aus einem Raum mit "no_control" alle anderen kontrollierbaren Räumen zu kontrollieren. Im CRANIX-4 hat sich dieses Verhalten geändert. Räume mit "inRoom"-Kontrolle dürfen nur aus dem Raum selbst kontrolliert werden. Aus einem Raum mit "no" dürfen nur Räume mit "allTeachers" kontrolliert werden. Dadurch soll verhindert werden, dass man zum Beispiel eine Klausur stört. Klausuren sollten in Räumen mit "inRoom"-Kontrolle ausgeführt werden. Zur Kontrolle des Raumes muss ein Lehrer im "Klausurraum" angemeldet sein. Diese Änderung hat auch die Konsequenz, dass die Räume mit "inRoom" Kontrolle nicht in der Auswahl der Räume unter Pädagogik -> Unterricht erscheinen. Auch nicht für Systemadministratoren. Wollen Sie also, dass immer alle Räume zur Auswahl stehen, da es in den Räumen keinen dedizierten Lehrerrechner gibt und die Lehrer mit privaten Rechner arbeiten, müssen Sie die Kontrolle der Räumen auf "allTeachers" setzen.
    Weiterhin ist es nicht mehr möglich für Räumen mit Raumkontrolle "no" Zugriffszeitplan zu erstellen oder dynamisch den Zugriff zu kontrollieren. Für Räumen mit Raumkontrolle "no" ist der Zugang zu allen Diensten des OSS immer erlaubt. Für direkten Internetzugang muss unter Firewall -> Ausgehende Verbindungen Raumregel gesetzt werden.
    Neu ist auch die "sysadminsOnly"-Kontrolle. Das sind Räume in denen die dynamische Kontrolle nur für Systemadministratoren nicht jedoch den LehrerInnen erlaubt ist. Standardmäßig ist der ANON_DHCP-Bereich so ein Raum.
  7. CUPS ist im CRANIX-4 nur direkt am Server unter https://localhost:631 verwaltbar.
  8. Der CRANIX-4 liefert keine eigene Portalseite wie der OSS-3 und bei der Migration per Neuinstallation wird die alte Portalseite nicht übernommen. Sie können den Inhalt von /srv/www/oss/ selbst gestalten.

4.2 Migration von OSS 3.4.2 auf die aktuelle CRANIX Version

Bitte beachten Sie folgendes für die Migration: auch wenn der Prozess sorgfältig getestet wurde, können wir keine Garantie für die Übernahme aller Daten übernehmen. Der Migrations-Prozess kann nur Daten übernehmen, die von einem richtig gepflegten und aktualisierten OSS 3 stammen. Daten einer installierten Fremdsoftware oder OSS Daten, die von einer Fremdsoftware angepasst und angereichert wurden, können ggf. nicht korrekt übernommen werden. Wenn Sie in Ihrem OSS Fremdsoftware installiert haben, dann wird diese aller Voraussicht nach deinstalliert oder sie wird nicht mehr korrekt funktionieren. Aus der Umstellung zur Active-Directory Server Kompatibilität und der daraus resultierenden Notwendigkeit der Eindeutigkeit von Objekt-Namen, ergibt sich die Besonderheit, dass bei Benutzer, Gruppen und Workstation-Accounts mit identischen Namen nur das Benutzerkonto migriert wird. Die Daten der Gruppe bleiben dann zwar erhalten, die Gruppe selbst wird jedoch nicht migriert.

Die Windows-Benutzerprofile werden NICHT übernommen. Die Benutzer selbst müssen dafür Sorge tragen, dass sie vor der Migration alle wichtige Dateien in ihren Homeverzeichnisse speichern!

Portalseite wird NICHT übernommen. Der CRANIX-4 liefert keine eigene Portalseite wie der OSS-3 und bei der Migration per Neuinstallation wird die alte Portalseite nicht übernommen.

Drucker können nur dann übernommen werden, wenn dieser sowohl über die Adminoberfläche als auch in CUPS mit völlig identischen namen angelegt wurden. Damit solche Drucker in CRANIX-4 weiter verwaltet werden können, muss für die Geräte die Gerätekonfiguration nach der Migration über die Adminoberfläche auf 'Printer' gesetzt werden. Drucker die diese Schema nicht entsprechen, müssen vor der Migration gelöscht und neu angelegt werden.

Die Übernahme von Mailaccounts bzw. Mailservereinstellungen erfolgt nicht automatisch. Dieses bieten wir als zusätzliche Dienstleistung an. Sollten Sie hierbei Unterstützung benötigen, erstellen wir Ihnen gerne ein unverbindliches Angebot. Schreiben Sie uns einfach über: support@cephalix.eu an.

Es gibt 2 Möglichkeiten für die Migration von OSS-3.4.2 auf CRANIX-4 über ein Update per DVD oder über Neuinstallation und anschließende Import der Objekten. In beiden Fällen muss der Server bzw die Klients für die Migration vorbereitet werden. Das neueste Migrationspaket, Installationsmedium und das ClientSetup Programm befinden sich auf unserem Server: [1]

4.3 Die Migration von OSS 3.4.2 per Neuinstallation

4.3.1 Installation der Migrationstools auf dem Server

Bitte laden Sie die neueste Version von oss-migration-3-to-4 von unserem Repository-Server https://repo.cephalix.eu/Downloads herunter und installieren Sie diese auf dem Server:

 rpm -Uvh --noarch oss-migration-3-to-4-3.4-7.noarch.rpm

4.3.2 Exportieren der Objekten

Im Paket oss-migration-3-to-4 befindet sich ein Programm womit man die Objekten von OSS-3-4-2 in Dateien exportiert, die mit CRANIX-4 importiert werden können: /usr/sbin/oss_export-for-4-0.pl.
Erstellen Sie ein Verzeichnis für die Importskripten, wechseln Sie in diese Verzeichnis und führen Sie nun das Exportskrip aus:

 mkdir -p /home/migration/CRANIX-4
 cd /home/migration/CRANIX-4
 /usr/sbin/oss_export-for-4-0.pl

Überprüfen Sie den Inhalt der Importdateien. Wichtig ist auch, dass die Importdateien auf eine Partition liegen, die bei der Installation nicht formatiert wird. Am besten ist es, wenn Sie ein Backup erstellen.

4.3.3 Neuinstallation von CRANIX-4

Sie können CRANIX-4 auf eine neue Hardware oder auch auf die selbe Hardware installieren. In letzterem Fall müssen Sie die manuelle Installation wählen und die Partitioniereung selber vornehmen. Dabei ist sehr wichtig, dass die Partition mit /home nicht formatiert wird.
Möchten Sie die E-Mails auch übertragen, müssen Sie von den Verzeichnissen /var/lib/imap, /var/spool/imapund /var/lib/sieve ein Backup erstellen.
Sie können während der Installation eine andere Domäne wählen, die Netzwerkkonfiguration soll jedoch erhalten bleiben, sonst können die exportierten Räumen und Geräten nicht importiert werden.

4.3.4 Übertragung der Dateien

Wurde der CRANIX-4 auf eine neue Hardware installiert, muss das /home/ vom alten Server auf den neuen Server übertragen werden. Verwenden Sie dazu das Tool rsync mit folgenden Parametern:

 rsync -aAv --exclude profile --exclude archiv /home/ <neuer-server>:/home/

4.3.5 Importieren der Objekten

Die Reihenfolge wie Sie die Importdateien einlesen ist sehr wichtig. Weichen Sie davon nicht ab!

Importieren von Gerätekonfigurationen
Von der Kommandozeile mit folgendem Befehl:

 crx_api_post_file.sh hwconfs/import hwconfs.csv

Importieren von Räumen
Von der Kommandozeile mit folgendem Befehl:

 crx_api_upload_file.sh rooms/import rooms.csv

Importieren von Benutzern
Die Benutzer müssen rollen weise von der Kommandozeile mit folgenden Befehl importiert werden:

 crx_import_user_list.py --role <role> --input /home/migration/CRANIX-4/<role>.csv

Wobei <role> mit den entsprechenden Rollen ersetzt werden soll. Alternativ können Sie das Import auch über die Adminoberfläche durchführen. Weiterhin muss beachtet werden, dass die so angelegten Benutzter neue Passwörter erhalten. Sie können jedoch mit Verwendung der Parameter --userpassword --mustchange dieses Verhalten beeinflussen. Alle Kommandozeilenparameter zum crx_import_user_list.py finden Sie hier. Die Importlisten befinden sich anschließend in /home/groups/SYSADMINS/userimports/.

Importieren von Geräten
Von der Kommandozeile mit folgendem Befehl:

 crx_api_upload_file.sh devices/import devices.csv

Anpassen von Filesystemrechten
Dazu müssen 2 Befehle ausgeführt werden aus dem Verzeichnis aus, wo sich die Importdateien befinden.

 crx_reset_home.sh -a
 bash chown-users.sh

Importieren von Gruppen
Während der Anpassung der Dateisystemrechten kann die Datei groups.csv von der Kommandozeile mit folgendem Befehl eingelesen werden:

 crx_api_upload_file.sh groups/import groups.csv

4.4 Die Migration von OSS 3.4.2 per Update

  1. Installation der Migrationstools auf dem Server
    Bitte laden Sie die neueste Version von oss-migration-3-to-4 von unserem Repository-Server http://repo.cephalix.eu/Downloads herunter und installieren Sie diese auf dem Server:
    zypper install oss-migration-3-to-4-3.4-7.noarch.rpm
  2. Installation des neuen Klientprogrammes auf den Rechnern.
    Der CRANIX-4 verwaltet die Klientrechner mit dem SaltStack-Management-Software. Um die Umstellungsarbeiten zu erleichtern, haben wir ein Wpkg-Paket erstellt, womit man das neue Klientprogramm mit dem alten Softwarevertelungstool installiert werden kann. Laden Sie dazu das Programm Oss4UpdateClients aus der Kategorie "OSS4.0 prereq" herunter. Bevor Sie dieses Software nun allen Clients zuweisen und die Installation starten müssen Sie die Datei /srv/itool/swrepository/Oss4UpdateClients/install.ps1 anpassen und den Platzhalter "<<DOMAIN>>" durch ihren DNS-Domainnamen ersetzen: $name = ($env:COMPUTERNAME).ToLower() + ".rs-angels.haeven.edu". Nach dieser Anpassung müssen Sie dieses Paket allen Rechner zuweisen und die Softwareinstallation anstoßen. Erst nachdem das neue Programm auf den Clients installiert ist, sollten Sie mit der Migration vorfahren.
  3. Vorbereitung der vorhandenen Daten auf dem alten OSS-Server
    Als erstes muss auf dem Server das Paket oss-migration-3-to-4 installiert werden. Dieses Paket liefert alle nötigen Skripte, die zur Vorbereitung der Migration nötig sind. Es ist dringend zu empfehlen ein Backup vom System durchzuführen. Die Vorbereitung zur Migration wird mit dem Skript: /usr/share/oss/oss-migration-3-to-4/migrate-to-4-0.sh gestartet. Dieses Skript muss als Benutzer root mit der vollen Pfadangabe ausgeführt werden.
  4. Update des Systems
    Dieser Schritt muss von einem CRANIX-4 Installationsmedium durchgeführt werden. Laden Sie das aktuelle CRANIX-4 DVD-Image herunter. Bei Bedarf muss dieses auf DVD gebrannt werden. Starten Sie das System von der erstellten DVD und wählen Sie aus dem Bootmenü Upgrade. Während des Upgradeprozesses werden einige Fragen gestellt, bzw. Hinweise gegeben, welche immer im positiven Sinne beantwortet werden müssen. Eine Ausnahme besteht dann, wenn eine Warnung während der Partitionierung angezeigt wird. In den meisten Fällen handelt es sich darum, dass in der Datei /etc/fstab einige Partitionen mit ihrem Kernel-Device-Namen eingetragen sind. Dies ist nicht zu empfehlen. Bitte brechen Sie in diesem Fall die Installation ab, starten Sie das alte System, und berichtigen Sie die Partitionierung mit dem "yast2 disk" Modul (Partitionierer).
  5. Einspielen von Daten
    Das Skript oss-prepare-migration.pl erstellt unter /home/archiv/migrate-to-4-0 einige Skripte, die zum Einspielen der Daten aus dem alten System nötig sind. Man startet das Einspielen der vorbereiteten Daten als Benutzer root mit dem Befehl /usr/share/oss/oss-migration-3-to-4/import-from-3-4.sh
  6. Nacharbeiten
    Während der Migration bleibt das root-Passwort ungeändert. Das Administrator-Passwort muss jedoch anschließend neu gesetzt und der Printserver in die Domäne aufgenommen werden:
 samba-tool user setpassword Administrator
 net ADS JOIN -s /etc/samba/smb-printserver.conf -U Administrator

Weiterhin müssen ggf. die Apache2 Kongigurationsdateien angepasst werden. Hier geht es in erster Linie um die Zugriffskontrolle. Bitte lesen Sie dazu: Apache-Update auf 2.4 von 2.2 Ob das erforderlich ist, sieht man daran ob apache2 gestartet werden konnte:

 systemctl status apache2
● apache2.service - The Apache Webserver
  Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled; vendor preset: disabled)
  Active: failed (Result: exit-code) since Do 2018-08-30 16:46:34 CEST; 3s ago
 Process: 13103 ExecStop=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND -k graceful-stop (code=exited, status=1/FAILURE)
 Process: 13093 ExecStart=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND -k start (code=exited, status=1/FAILURE)
Main PID: 13093 (code=exited, status=1/FAILURE)
Aug 30 16:46:34 admin systemd[1]: Starting The Apache Webserver...
Aug 30 16:46:34 admin start_apache2[13093]: AH00526: Syntax error on line 5 of /etc/apache2/vhosts.d/7IF2.group:
Aug 30 16:46:34 admin start_apache2[13093]: Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration

WICHTIG Bitte beachten Sie folgende Hinweise:

  • Die Uhr des Servers muss genau eingestellt werden. Liegt die Systemzeit in der Zukunft, wird der Server nach dem Update nicht 100% betriebsfähig sein.
  • Es gibt keinen Weg zurück: Hat man das Mirgrationsskript gestartet, wird das System so umkonfiguriert, dass das alte System nicht mehr funktionsfähig ist.
  • Das Einspielen eines Backups von einem OSS 3.4.2 Systems ist NICHT möglich.
  • Je nach Anzahl der Benutzerkonten und Rechner brauchen Sie ca. 100MB freien Speicherplatz unter /home/archiv/. Das Skript /usr/share/oss/oss-migration-3-to-4/oss-prepare-migration.pl überprüft, ob genug Speicherplatz zur Verfügung steht. Ansonsten wird dieses nicht gestartet.
  • Es werden nur die, vom OpenSchoolServer-Team, per Update zur Verfügung gestellten Pakete aktualisiert. Haben Sie Pakete von Drittanbieter bezogen, werden diese höchstwahrscheinlich gelöscht.
  • Eine Migration per "zypper dup" von einer Online-Repository ist nicht möglich.
  • Während der Migration wird der Benutzer "admin" samt seine Daten in den Benutzer "Administrator" konvertiert. Dieser Benutzer ist nun der Domain-Hauptadministrator. Einen Benutzer "admin" gibt es im OSS 4.0 nicht.


Frühere Versionen