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.0.1 bzw. 4.1 sind:

• Basissystem: openLeap 15.2
• Die zentrale Konfiugrationsdatei heißt nun /etc/sysconfig/cranix
• Die oss_ Befehle fangen jetzt alle mit crx_ an.
• Neue Variable in der Konfiugrationsdatei: ALLOW_WINDOWS_UPDATES ist diese Variable auf no gesetzt, wird auf dem Windows-Rechner beim Hochfahren das wuauserv gestoppt und deaktiviert.
• 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 folgenden Versionen auf CRANIX-4-3 eine Migration durchführen: OSS-3.4.2, OSS-4.1, CRANIX-4-2
• Die Samba-Version von OSS-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 OSS-4.0.1 aktualisieren und anschließend mindestens 1 Tag lang laufen lassen, damit die Samba-Datenbanken umgebaut werden.
• OSS-4.0.1 muss zunächst auf OSS-4-1 migriert 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.
• OSS-4-1: Migration mit dem Befehl /usr/share/oss/tools/migrate-to-cranix.sh starten.
• CRANIX-4-2: Migration mit dem Befehl /usr/share/cranix/tools/migrate-to-4.3.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 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/cranix 
 /usr/share/cranix/tools/create_server_certificates.sh -N CA
 /usr/share/cranix/tools/create_server_certificates.sh -N admin
 /usr/share/crnaix/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