Anpassungsmöglichkeiten

Wie in früheren Versionen bietet der CRANIX verschieden Anpassungsmöglichkeiten.

1 Netzwerkkonfiugration anpassen

Die Netzwerkkonfiugration des Transportnetzes kann man einfach mit dem yast2 lan modul oder durch die Anpassung der Konfigurationsdateien in /etc/sysconfig/network/ erledigen. Auf einem CRANIX-Server müssen jedoch noch folgende Änderungen durchgeführt werden:

• /etc/hosts extip-Eintrag muss geändert werden.
• /etc/sysconfig/cranix Folgende Variablen müssen angepasst werden: CRANIX_SERVER_EXT_GW, CRANIX_SERVER_EXT_IP, CRANIX_SERVER_EXT_NETMASK
• Anschließend apache2 neu starten: systemctl restart apache2

Die Änderung der Konfiguration des internen Netzwerks kann mit einfachen Handgriffen überhaupt nicht bewerkstelligt werden. Wenn es doch erforderlich sein sollte, können Sie uns mit der Durchführung beauftragen.

2 Passwortüberprüfung

Grundsätzlich wird das Script /usr/share/cranix/tools/check_password_complexity.sh ausgeführt um die Qualität der Benutzerpasswörter zu überprüfen. Sowohl samba als auch cranix-api verwendet dieses Script. Das Verhalten dieses Scripts kann man durch die System-Variablen CHECK_PASSWORD_QUALITY, MINIMAL_PASSWORD_LENGTH und MAXIMAL_PASSWORD_LENGTH steuern. Ist CHECK_PASSWORD_QUALITY auf ‘’’yes’’’ gesetzt, gelten folgende Regeln:

• MINIMAL_PASSWORD_LENGTH und MAXIMAL_PASSWORD_LENGTH müssen eingehalten sein.
• Passwort muss mindestens ein Großbuchstaben enthalten.
• Passwort muss mindestens ein Kleinbuchstaben enthalten.
• Passwort muss mindestens einen Ziffer enthalten.
• /usr/sbin/cracklib-check muss das Passwort gut finden.

Möchte man völlig andere Regel verwenden, muss eine Ausführbare Datei namens /usr/share/cranix/tools/custom_check_password_complexity.sh erstellt werden, welche das zu überprüfende Passwort vom STDIN liest. Ist das Passwort nicht in Ordnung muss das Script den Grund in STDOUT liefern. Sonst darf keine Ausgabe erfolgen.

Auch wenn CHECK_PASSWORD_QUALITY auf no steht oder eigene Regel gelten, muss ein Passwort mindestens 6 Zeichen erhalten.

3 Gruppenrichtlinien (GPO)

Seit der Version 4 ist der CRANIX Server ein (fast) vollwertige AD-Server. Als solcher speichert er für Windows-Domänen Gruppenrichtlinien und verteilt diese automatisch beim Starten von Windows-Clients die Mitglied in der Domäne sind. Gruppenrichtlinien ermöglichen spezifische Konfigurationen für Benutzer und Computer zu implementieren. Der CRANIX-Server selbst bietet keine Möglichkeiten GPO-s zu erstellen bzw zu bearbeiten. Diese Arbeit muss als Domänenadministrator von einem Windows-Client aus erledigt werden. Das dazu nötige Programm wird mit jedem Windows 10 Education oder Professional mitgeliefert muss jedoch als optionales Feature aktiviert werden. Melden Sie sich dazu als Benutzer Administrator an einem Windows-Domainmitgliedrechner an und führen Sie folgende Schritte aus:

• 

  Apps und Features starten

• 

  Optionale Features

• 

  Features zufügen

• 

  Gruppenrichtlinienverwaltung installieren

Wichtig Um optionale Features aktivieren zu könne muss das Windowsupdateservice laufen. Bitte beachten Sie, dass dieser Dienst auf CRANIX-Clients durch SALT beim Hochfahren ausgeschaltet wird. Sie können den Dienst von der Konsole mit folgendem Befehl starten:

 net start wuauserv

3.1 Ein Gruppenrichtlinienobjekt erstellen

Wie man ein Gruppenrichtlinienobjekt erstellt, zeigen wir Ihnen an einem konkreten Beispiel. Im Juli 2016 hat Microsoft ein Update veröffentlicht, um Sicherheitsprobleme im Windows-Druckspooler zu beheben. Dieses Update ändert das Verhalten und schränkt Unterstützung für nicht paketfähige Druckertreiber. Im Oktober 2016 hat Microsoft ein Update veröffentlicht, um diese Probleme in einem AD-Umgebung zu entschärfen. Weitere Einzelheiten finden Sie unter MS16-087. Dieser Abschnitt beschreibt das Verfahren zur Umgehung dieses Problems. Diese GPO muss auf jeden CRANIX Server erstellt werden, damit der Server für Windows-Clients Druckertreiber verteilen kann.

• 

  Gruppenrichtlinienverwaltung starten

• 

  Neues GPO Erstellen

• 

  Name des neuen GPO

4 Pluginskripten

Bei verschieden Aktionen werden sog. Pluginscripten am CRANIX gestartet. Solche Aktionen sind das Erstellen, Ändern und Löschen von verschiedenen Objekten über die Adminoberfläche, die Auf und Abbau von Verbindungen zu den verschiedenen Freigaben des CRANIX-Server bzw. das Starten von Clients die als salt-Minion an CRANIX angemeldet sind.

Die Pluginskripten befinden sich auf dem CRANIX unter /usr/share/cranix/plugins in verschiedenen Verzeichnissen.

Der CRANIX selbst liefert einige Plugins die zur Funktionsfähigkeit des Server zwingend erforderlich sind. Diese Scripte soll man weder löschen noch ändern, da diese beim Updates neu erstellt werden. Die von CRANIX gelieferten Pluginkripten fangen immer mit "100" an. Will man selbst Skripten kann man den Ausführungszeitpunkt durch den Namen steuern. Möchte man ein eigenes Skript nach dem vom CRANIX ausführen lassen, muss dieses Script mit einem Zahl größer als 100 anfangen.

4.1 Objekt-Plugins

Die Objekt-Pluginscripten werden durch das Programm /usr/share/cranix/plugins/plugin_handler.sh aufgerufen und liegen in Ordner mit den Namen der Objektaktionen. Für folgende Objektaktionen existieren Pluginscripten.

• add_device
• add_group
• add_user
• modify_device
• modify_group
• modify_user
• delete_device
• delete_group
• delete_user
• change_member

Die Scripten lesen die Daten aus dem STDIN. Die Daten haben folgendes Format:

<parameter1>: <value1>
<parameter2>: <value2>
usw.

4.2 Share-Plugins

Die Pluginscripten für die Freigaben befinden sich in im Verzeichnis /usr/share/cranix/plugins/shares/ und werden folgender Weise sortiert:

/usr/share/cranix/plugins/shares/<Share-Name>/<Aktion>

Es gibt zwei Aktionen: open oder close. Die Share-Pluginscripten werden mit folgenden Argumenten aufgerufen:

1. Uid des Benutzers
2. IP-Adresse des Clients
3. Arhitektur des Clients
4. Hostname des Clients
5. Kerberos/AD Realm

4.3 Client-Plugins

Die Client-Pluginskripten befinden sich im Verzeichnissen

/usr/share/cranix/plugins/clients/<Atkion>

Wobei Aktion lost start present sein kann. Die Client-Pluginskripten werden mit dem Minionnamen (normaler Weise ist das der FQHN des Clients) als Argument aufgerufen.

5 Automatische Konfiguration mit Salt

Salt wird vom CRANIX u.a. für die Softwareverteilung benutzt und ist daher auf dem System vorhanden und vorkonfiguriert. Das vorhandene System beruht auf einem sogenannten Environment namens base. Es ist möglich, ein zweites, völlig unabhängiges Environment namens z.B. schule aufzusetzen und in diesem Environment die automatische Konfiguration von Client-Rechnern an die eigene Schule durchzuführen.

5.1 Eigenes Salt-Environment

Die Datei

/etc/salt/master.d/crx.conf

enthält die Variable file_roots, die um die Zeilen für das eigene Environment ergänzt werden muss:

file_roots:
  base:
    - /srv/salt
    - /srv/salt/packages
  schule:
    - /srv/salt/schule

Damit das neue Environment auch korrekt verwendet wird, muss noch in der Datei

/etc/salt/master

die Zeile

top_file_merging_strategy: merge_all

eingebaut werden. Diese Zeile ist vorhanden, aber auskommentiert.

Nach einem Neustart des salt-master ist das System einsatzbereit.

systemctl restart salt-master
systemctl restart crx_salt_event_watcher

5.2 Verwendung des eigenen Environments

Im folgenden wird beschrieben, wie das Environment zur Konfiguration von Linux-Clients verwendet werden kann.

• Linuxrechner_am_OSS_ab_Version_4.0
• Automatische Konfiguration mit salt