Versionshinweise

1 CRANIX 4.3

Am 20. Oktober 2020 wurde die finale Version von CRANIX-4-3 ist freigegeben. Das aktuelle ISO können sie unter CRANIX-4-3 Die wichtigsten Neuerungen gegen über 4.1 sind:

• Basissystem: openLeap 15.2
• Python3 ist Standard. Viele unsere Helperscripten wurden auch in python umgeschreiben.
• SysVinit ist komplett entfernt.
• Die alten Befehle ipconfig und route sind ebenfalls entfernt.
• Da xfce4 auf openLeap 15.2 für "root" so gut wie unbrauchbar ist, wird KDE als Window/Displaymanager eingeführt.
• Die Administrationsoberfläche wurde mit der Verwendung von Ionic Framework und ag-Grid völlig neu geschrieben.
• samba 4.11
  • Die Nutzung der GPOs wurde verbessert.
  • Für die Rollen werden nun OU-s erstellt und die Benutzer werden nicht in CN=Users,<LDAPBASE> sondern OU=<rolle>,<LDAPBASE> hinterlegt. Dadurch kann man verschiedene GPOs für die Rollen erstellen.

1.1 Zu beachten

• Man kann nur von OSS-3.4.2 von OSS-4.0.1 von OSS-4.1 oder von CRANIX-4-2 auf CRANIX-4-3 updaten. Die Samba-Version von CRANIX-4.0 (4.6.X) kann nicht auf die Samba-Version von CRANIX-4.3 (4.11.X) aktualisiert werden. CRANIX-4.0 muss man zunächst auf CRANIX-4.0.1 aktualisieren und anschließend mindestens 1 Tag lang laufen lassen, damit die Samba-Datenbanken umgebaut werden.
• Da die Pakete des grafischen Systems xfce deinstalliert werden, kann die Migration nicht auf der grafischen Oberfläche durchgeführt werden.

1.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.1.0-lp151.11.1 des Paketes "oss-base" muss installiert sein.
• Migration mit dem Befehl /usr/share/oss/tools/migrate-to-cranix.sh starten.
• Die Migration erfolgt in 2 Schritten. Zunächst wird die Systemkonfiguration an CRANIX-4-3 angepasst. Anschließend wird per at ein Job gestartet, welche die Migration in Hintergrund durchführt. Dabei werden 3 Logdateien erstellt:
  • /var/log/MIGRATE-TO-CRANIX-1.log Ausgabe der von zypper ref.
  • /var/log/MIGRATE-TO-CRANIX-2.log Ausgabe der Paketenmigration.
  • /var/log/MIGRATE-TO-CRANIX-3.log Ausgabe der anschließenden Anpassung der Paketen.
• Bitte beachten Sie, dass während der Migration mehr als 2000 Pakete aktualisiert werden, deshalb kann die Migration je nach Qualität des Internetzugangs 20-90 Minuten lang dauern.
• Die Migration ist abgeschlossen, wenn die Datenbank CRX existiert und die letzten 2 Zeilen vom MIGRATE-TO-CRANIX-2.log folgendes enthalten:

 tail -n2 /var/log/MIGRATE-TO-CRANIX-2.log
 Core-Bibliotheken oder Dienste wurden aktualisiert.
 Ein Neustart wird benötigt, um sicher zu stellen, dass ihr System von diesen Updates profitiert

• Wenn die Migration abbricht bitte Supportanfrage stellen. Um Ihnen weiter helfen zu können, brauchen wir ssh-Zugang zu Ihrem Server.
• WICHTIG Bitte Migration nicht abbrechen!
• WICHTIG Auf keinen Fall neu starten, wenn ein Fehler bei der Migration aufgetreten ist. In diesem Fall bitte Supportanfrage stellen, aber auf keinen Fall neu starten!

1.3 Bemerkung

Als letzte Ausgabe sieht man in der Logdatei Folgendes:

 Using short domain name -- XXXX
 Joined 'PRINTSERVER' to dns domain 'xxx.xxx.xx'
 DNS Update for printserver.xxx.xxx.xx failed: ERROR_DNS_UPDATE_FAILED
 DNS update failed: NT_STATUS_UNSUCCESSFUL

Das ist kein Fehler. Der Printserver-Instanz muss erneut der Domäne zugefügt werden (Domain JOIN). Da dieser jedoch schon in der Domäne war, kann der DNS-Eintrag nicht erneut zugefügt werden, da dieser schon existiert. Deshalb kommt diese falsche Fehlermeldung.

1.4 Bekannte Probleme

Beim Server die als 4.0.0 aufgesetzt wurden, kann es vorkommen, dass apache2 nach der Migration von 4.0.1 auf 4.1.0 nicht mehr startet. Das Problem ist, dass auf 4.0.0 "md5" als "Signature Algorithm" für die Erstellung von Zertifikaten verwendet wurde. Das wird allerdings nicht mehr als sicher genug betrachtet und Apache arbeitet damit nicht mehr. Deshalb müssen in diesem Fall die Zertifikate neu erstellt werden:

 rm -r /etc/ssl/servercerts/*
 . /etc/sysconfig/schoolserver 
 /usr/share/oss/tools/create_server_certificates.sh -N CA
 /usr/share/oss/tools/create_server_certificates.sh -N admin
 /usr/share/oss/tools/create_server_certificates.sh -N schoolserver

Ob die Zertifikate mit dem richtigen Algorithmus erstellt worden sind, kann man mit folgendem Befehl überprüfen:

openssl x509 -in /etc/ssl/servercerts/certs/admin.<Ihr Domainnamen>.cert.pem -text  | grep 'Signature Algorithm'
Richtig: Signature Algorithm: sha256WithRSAEncryption
Falsch:  Signature Algorithm: md5WithRSAEncryption