Dies ist die Dokumentation einer alten opsi-Version. Die Dokumentation für die aktuelle Version 4.3 finden Sie hier.

opsi-Server

Überblick

Die Funktionalitäten eines opsi-Servers lassen sich auf vielen Business gängigen Linuxdistributionen installieren.

Grob lassen sich zwei wichtige Funktionalitäten unterscheiden, die auf einem Server vereint sein können:

  • opsi-configserver
    Die Funktionalität des configserver umfasst die Speicherung und Verarbeitung der Konfigurationsdaten in unterschiedlichen Backends und deren Bereitstellung über einen Webservice und auf Kommandozeile.

  • opsi-Depotserver
    Die Funktionalität des depotserver umfasst die Speicherung der eigentlichen Installationsdateien der zu verteilenden Software, Betriebssysteme, Bootimages und deren Bereitstellung für den Client per smb/cifs, https, tftp.

Die aus diesen Diensten entstehenden Hardwareanforderungen sind in der Regel gering, so das ein Betrieb eines opsi-servers in einer Virtualisierungsumgebung kein Problem darstellt.

Seit Version 4.2 wird die In-Memory-Datenbank Redis eingesetzt (https://redis.io/). Der opsi-Server speichert folgende Daten in Redis:

Die Statistiken werden von Grafana (https://grafana.com/) ausgelesen und angezeigt. Das Grafana Dashboard ist über die Adminseite https://<opsi-server>:4447/admin erreichbar.

Grafana Dashboard

Installation und Inbetriebnahme

Die Installation und Inbetriebnahme eines opsi-Servers ist in dem gesonderten Handbuch: opsi-getting-started ausführlich erläutert.

Samba Konfiguration

Um den Client-PCs Zugriff auf die Softwarepakete zu ermöglichen, stellt der opsi-server Shares bereit, die von den Clients als Netzlaufwerke gemountet werden können. Für die Windows-Clients wird dazu die Software Samba eingesetzt. Die Korrekte Sambakonfiguration können Sie erstellen bzw. reparieren durch den Aufruf von:

opsi-setup --auto-configure-samba

Nach einer Änderung der Samba-Konfigurationsdateien ist ein Neustart der Samba-Software notwendig (systemctl restart smbd.service).

Der Daemon opsiconfd

Der opsiconfd ist der zentrale Konfigurations-Daemon von opsi. Alle Client-Komponenten (opsi-client-agent, opsi-configed, opsi-Linux-Bootimage, …​) verbinden sich mit diesem Service um auf die Konfigurationen in den Backends zuzugreifen. Der opsiconfd wird über die Datei /etc/opsi/opsiconfd.conf, über Umgebungsvariablen oder über Kommandozeilen-Parameter konfiguriert.

Die einzelnen Konfigurations-Optionen können über den Befehl opsiconfd --help abgefragt werden. Um Optionen bei jedem Start des opsiconfd zu verwenden, können die Option aus dem Hilfetext ohne das -- in die Konfigurationsdatei eingetragen werden.

Außerdem ist es möglich, die Umgebungsvariablen, wie im Hilfetext gezeigt, zu verwenden.

Werden die einzelnen Ansätze miteinander kombiniert, gilt die folgende Reihenfolge: Einträge in der Konfigurationsdatei überschreiben die Defaults, Umgebungsvariablen überschreiben Einträge in der Konfigurationsdatei, Kommandozeilen-Parameter überschreiben Umgebungsvariablen.

Notwendige System-User und Gruppen

  • User opsiconfd
    Dies ist der user unter dem der opsiconfd Daemon läuft.

  • User pcpatch
    Dies ist der user, den der opsi-client-agent verwendet um den depotshare zu mounten und von diesem zu lesen. Dieser User hat per Voreinstellung das Heimatverzeichnis /var/lib/opsi. Das Passwort des Benutzers kann mittels opsi-admin -d task setPcpatchPassword gesetzt werden.

  • Gruppe opsifileadmins
    Mitglieder dieser Gruppe haben Zugriff auf eine opsi-Paket-Daten, wie Depot, Repository und Workbench. Die Systemadministratoren des opsi-Servers sollten daher Mitglieder dieser Gruppe sein.

Ehemals hieß diese Gruppe pcpatch, seit opsi 4.2 wird standardmäßig opsifileadmins als Gruppenname verwendet. Wird eine bestehende opsi-Umgebung auf opsi 4.2 aktualisiert wird der verwendete Gruppenname jedoch beibehalten.

Bei Anbindung des opsi-Servers an ein Active Directory muss in jedem Fall der Gruppenname opsifileadmins verwendet werden.

  • Gruppe opsiadmin
    Die Mitglieder dieser Gruppe können sich gegenüber dem opsi-webservice authentifizieren und damit z.B. mit dem opsi-configed arbeiten. Daher sollten alle Mitarbeiter die mit opsi arbeiten, Mitglied dieser Gruppe sein.

Notwendige Shares

  • Bereich: Depotshare mit Softwarepaketen (opsi_depot)
    Auf dem depot-Share liegen die für die Installation durch das Programm opsi Winst vorbereiteten Softwarepakete.
    In der Voreinstellung liegt dieses Verzeichnis auf dem opsi-server unter /var/lib/opsi/depot.
    Unterhalb von diesem Verzeichnis findet sich für jedes Softwarepaket ein Verzeichnis mit dem Namen des Softwarepakets.
    Wiederum unterhalb dieses Verzeichnisses liegen dann die Installationsskripte und -dateien.

    Das Verzeichnis wird mit dem Freigabe-Namen opsi_depot per Samba read-only exportiert.

    In alten Versionen von opsi war das entsprechende Verzeichnis /opt/pcbin und der Share hieß 'opt_pcbin'.

  • Bereich: Arbeitsverzeichnis zum Pakethandling (opsi_workbench)
    Unter /var/lib/opsi/workbench ist der Bereich um Pakete zu erstellen und in dem Pakete vor der Installation mit opsi-package-manager abgelegt werden sollen. Dieses Verzeichnis ist als share opsi_workbench freigegeben.

    Seit opsi 4.1 kann der Pfad Depot-spezifisch über das Attribut workbenchLocalUrl konfiguriert werden.

  • Bereich: Konfigurationsdateien File-Backend (opsi_config)
    Unter /var/lib/opsi/config liegen die Konfigurationsdateien des file Backends. Dieses Verzeichnis ist als share opsi_config freigegeben.

    Wenn Sie über diesen Share auf den Dateien arbeiten, verwenden Sie keine Editoren die das Dateiformat (Unix/DOS) verändern und entfernen Sie Sicherungsdateien wie z.B. *.bak.

opsi PAM Authentifizierung

opsi verwendet zur Authentifizierung der User diverse PAM-Module. Bisher wurden für verschiedene Distributionen verschiedene PAM-Module verwendet. In der folgenden Auflistung werden die eingesetzten PAM Module aufgelistet:

Standard: common-auth
openSUSE / SLES: sshd
CentOS und RedHat: system-auth
RedHat 6: password-auth

Wie man aus der Liste erkennen kann, wurden diverse PAM-Konfigurationen verwendet, diese können sich aber je nach lokaler PAM Konfiguration wieder ändern. Da für diese Anpassungen immer ein Eingriff in den Code nötig war gibt es nun die Möglichkeit unter: /etc/pam.d/ die Datei opsi-auth an zu legen und für opsi eine eigene PAM-Konfiguration zu hinterlegen. Wenn es diese Datei gibt, benutzt opsi automatisch diese Konfiguration.

Folgendes einfaches Beispiel soll das Verhalten verdeutlichen: Wenn Sie ein Debian/Ubuntu System betreiben und bei der Anmeldung am opsi-configed eine PAM-Fehlermeldung bekommen, obwohl mit den selben Benutzerdaten eine SSH Verbindung zum Server geöffnet werden kann, kann man die Datei /etc/pam.d/opsi-auth mit folgendem Inhalt erstellen:

@include sshd

Nach einem Neustart von opsiconfd benutzt opsi automatisch das sshd-PAM-Modul zur authentifizierung.

Bitte beachten Sie, dass die Anwendung der ACL auf case-sensitive arbeitende Schnittstellen zurückgreift, wohingegen die Authentifizierung über PAM case-insensitiv geschehen kann. Dadurch kann der Fall eintreten, dass trotz erfolgreicher Authentifizierung keine Arbeit mit dem Service möglich ist, da die ACL dies verhindern.

opsi LDAP/Active Directory Authentifizierung

Statt PAM für die Authentifizierung zu nutzen, ist es auch möglich einen LDAP-Server bzw. ein Active Directory direkt zu verwenden. Hierfür ist die opsi-Erweiterung 'opsi directory connector' notwendig. Dieses Modul ist momentan eine kofinanzierte opsi Erweiterung.

Die Konfiguration findet über die Datei /etc/opsi/opsi.conf statt. In der Sektion 'ldap_auth' muss hierfür die Option ldap_url gesetzt werden. Die ldap_url besitzt dabei den folgenden Aufbau: ldap[s]://<adresse-des-ldap-servers>[:port]/<base-dn>

Zusätzlich kann, wenn notwendig, die Option username verwendet werden. Damit kann definiert welcher Benutzername bei der Authentifizierung am LDAP/AD übergeben werden soll. Hierbei können die Platzhalter {username} und {base} verwendet werden.

Beispiel zur Anbindung an ein Active Directory bzw. Samba 4:

[ldap_auth]
ldap_url = ldaps://ad.company.de/dc=ad,dc=company,dc=de

Beispiel zur Anbindung an einen OpenLDAP:

[ldap_auth]
ldap_url = ldaps://ldap.company.org:636/dc=company,dc=org
username = uid={username},dc=Users,{base}

Damit die Änderungen übernommen werden, muss der opsiconfd neu gestartet werden.

Bitte beachten Sie, dass die in der Variable admingroup definierte Gruppe auch im LDAP verfügbar ist.