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 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.

3.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.

3.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

3.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.

4 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.

4.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

4.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