Voraussetzungen

Nachfolgend werden die Voraussetzungen für die Installation von opsi auf einem Server beschrieben.

Unterstützte Distributionen für Server

Distribution opsi 4.3 opsi 4.2

Debian 12 Bookworm

supported

unsupported

Debian 11 Bullseye

supported

supported

Debian 10 Buster

supported

supported

Debian 9 Stretch

discontinued

discontinued

Ubuntu 24.04 LTS Noble Numbat

supported

unsupported

Ubuntu 22.04 LTS Jammy Jellyfish

supported

supported

Ubuntu 20.04 LTS Focal Fossa

supported

supported

Ubuntu 18.04 LTS Bionic Beaver

discontinued

supported

RHEL 9

supported

supported

RHEL 8

supported

supported

AlmaLinux 9

supported

supported

AlmaLinux 8

supported

supported

Rocky Linux 9

supported

supported

Rocky Linux 8

supported

supported

Oracle Linux 9

supported

unsupported

Oracle Linux 8

supported

unsupported

SLES 15 SP5

supported

unsupported

SLES 15 SP4

supported

supported

SLES 15 SP3

supported

supported

SLES 15 SP2

supported

supported

SLES 15 SP1

supported

supported

openSUSE Leap 15.5

supported

unsupported

openSUSE Leap 15.4

supported

supported

openSUSE Leap 15.3

discontinued

discontinued

UCS 5.0

supported

supported

UCS 4.4

discontinued

discontinued

supported: Supported unsupported: Unsupported develop: Under development discontinued: Discontinued

Hardwarevoraussetzungen

Für einen opsi-Server auf realer Hardware wird benötigt:

  • x86-64- oder ARM64-System

  • Mindestens 2GB RAM

  • Mindestens 2 CPU-Cores

  • Der Bedarf an Festplatten-Speicher hängt stark von der Anzahl der opsi-Pakete ab. Für Produktiv-Systeme gilt:

    • Im Verzeichnis '/tmp' sollte immer mindestens 15GB freier Speicher zur Verfügung stehen.

    • Das Verzeichnis '/var/lib/opsi' sollte mindestens 60GB umfassen und flexibel erweiterbar sein.

Wie viele opsi-Clients gleichzeitig auf einen opsi-Server zugreifen, hängt stark von der Konfiguration und den Tagesabläufen in der jeweiligen Umgebung ab. In großen Umgebungen, mit vielen gleichzeitigen Client-Verbindungen, kann der RAM- und CPU-Bedarf deutlich ansteigen.

Der zentrale opsi-Dienst 'opsiconfd' benötigt pro Worker-Prozess ca. 250MB RAM. Es sollte etwa ein Worker-Prozess für 20 gleichzeitige Verbindungen zur Verfügung stehen. Die Anzahl der CPU-Cores sollte in etwa der Hälfte der Anzahl von Worker-Prozessen entsprechen.

In der Standard-Konfiguration sind auf dem gleichen System zusätzliche Ressourcen für Samba, MySQL und Redis einzuplanen.

Software- und Konfigurationsvoraussetzungen

Folgende Voraussetzungen müssen erfüllt sein, damit Sie opsi installieren bzw. einsetzen können:

gültiger DNS Domainname

Ihr DNS Domainname muss mindestens aus einer Domain und einer Topleveldomain bestehen. Anders ausgedrückt: der volle (Fully qualified) Domainname muss mindestens einen Punkt enthalten. Weiterhin muss die Topleveldomain aus mindestens zwei Zeichen bestehen.

Erlaubt sind z.B.: 'domain.local', 'uib.de', 'subdomain.domain.de'.
Nicht erlaubt ist z.B. 'mydomain.d', denn das wäre nur ein Zeichen in der Topleveldomain.
Nicht erlaubt ist z.B. 'mydomain', denn das wäre nur eine Topleveldomain.

Siehe auch:

gültige DNS Hostnamen

Die Hostnamen (auch der Clients) müssen den Richtlinien entsprechen. Dazu gehört auch, dass sie z.B. keine Unterstriche enthalten dürfen.

Kontrollieren Sie auf Ihrem opsi-Server, dass der folgende Befehl einen 'fully qualified domainname' zurück liefert, in dem mindestens zwei Punkte vorkommen, z.B. 'opsiserver.domain.local':

hostname -f

Sieht das Ergebnis nicht so aus (enthält z.B. '127.0.0.1' oder 'localhost') dann müssen Sie Ihre '/etc/hosts' oder Namensauflösung zunächst korrigieren.

Korrekte Namensauflösung für den Server

Prüfen Sie den Eintrag für den opsi-Server in der Datei '/etc/hosts', oder aber die Ausgabe von:

getent hosts $(hostname -f)

Das Ergebnis sollte beispielsweise so aussehen:
'192.168.1.1 server.domain.tld server'

Dabei sollte die IP-Adresse der Netzwerkschnittstelle aufgeführt sein, zu der sich die Clients später verbinden sollen.

Sieht das Ergebnis nicht so aus (enthält z.B. '127.0.0.1', '127.0.0.2' oder 'localhost'), dann müssen Sie die Datei /etc/hosts oder Ihre Namensauflösung korrigieren.

Die Namen müssen den Vorgaben eines DNS-Systems entsprechen, aber ein DNS-Server wird für den Betrieb von opsi nicht benötigt.
opsi benötigt kein Active Directory oder ähnliches. Eine Integration ist möglich, wird aber nicht vorausgesetzt.

Gesetzte Spracheinstellungen

opsi setzt voraus, dass auf dem verwendeten Server Spracheinstellungen ('locale') gesetzt sind.
Empfohlen wird die Verwendung einer UTF-8-kompatiblen Lokalisierung.

Zur vereinfachten Prüfung kann folgender Befehl verwendet werden:

test -e /etc/default/locale && echo "ok" || (echo "Check locales:" && locale)

Wird ok ausgegeben, so sind locales gesetzt. Wird check locales: ausgegeben, so prüfen Sie bitte, dass in der nachfolgend ausgegebenen Liste für 'LANG' oder 'LC_ALL' ein Wert gesetzt ist, welcher der von Ihnen verwendeten Sprache entspricht.

Für Deutsch empfehlen wir de_DE.UTF-8.

Die folgenden Befehle zeigen beispielhaft wie die Einstellung geändert werden kann, sollte kein oder ein ungewollte Wert gesetzt sein:

sudo locale-gen de_DE.UTF-8
update-locale LANG=de_DE.UTF-8

Zum systemweiten Anwenden der Spracheinstellung sollte der Server neu gestartet werden.

Weitere Informationen entnehmen Sie bitte dem Handbuch der von Ihnen verwendeten Linux-Distribution.

Benötigte Netzwerk-Ports

Dies ist eine Übersicht über verwendete Ports und Netzwerk-Protokolle.

Config-Server = zentraler opsi-server zur Verwaltung aller Clients.
Depot-Server = opsi-server in den einzelnen Lokationen.
Wenn es nur einen opsi-server gibt, so übernimmt dieser beide Rollen.

  • opsi-server Webservice: 4447/tcp
    Client zum Config- und Depot-Server, Depot-Server zum Config-Server, auch Verbindungen via localhost.

  • opsi-client Webservice: 4441/tcp
    Config-Server zum Client, Verbindung vom Client an sich selbst via localhost.

  • opsi-client Notifier: 45000-45099/tcp
    Verbindung vom Client an sich selbst via localhost.
    Ein zufälliger Port aus dem gegebenen Bereich wird ausgewählt.

  • TFTP: 69/udp
    Verbindung vom Client zum Depot-Server.

  • TFTP: 1024-65535/udp
    Verbindung vom Depot-Server zum Client.

  • CIFS/SMB: 445/tcp
    Client zu Depot-Server.

  • CIFS/SMB: 445/tcp
    Depot-Server zu Client.
    Nur notwendig, wenn opsi-deploy-client-agent (winexe, smbclient) für Windows-Clients verwendet wird.

  • Grafana Webservice: 3000/tcp
    Verbindung vom Client zum Config-Server.
    Nur wenn von dem Client auf die Management Webseite des Config-Servers zu gegriffen werden soll.

  • SSH: 22/tcp
    Verbindung vom Client zum Config-Server.
    Management Zugriff auf Config- und Depot-Server.

  • SSH: 22/tcp
    Verbindung vom Depot-Server zum Client.
    Nur notwendig, wenn opsi-deploy-client-agent für Linux- / MacOS-Clients verwendet wird.

  • DNS: 53/tcp, 53/udp
    Alle Server / Clients müssen Ihren DNS erreichen können.

  • Wake-on-LAN (WoL): 7/udp, 9/udp, 12287/udp
    Verbindung vom Config-Server zum Client. Diese Ports sind konfigurierbar.

  • HTTP: 80/tcp
    Config- und Depot-Server ins Internet.
    Um z.B. Server-Updates von http://download.opensuse.org zu laden.

  • HTTPS: 443/tcp
    Config- und Depot-Server ins Internet.
    Um z.B. Pakete von https://download.uib.de zu laden (opsi-package-updater).

Proxy-Einstellungen

Wenn ein HTTP-Proxy verwendet wird, sollten die Proxy-Einstellungen systemweit über Umgebungsvariablen konfiguriert werden. Diese Umgebungsvariablen werden in der Regel in der Datei /etc/environment hinterlegt. Die folgenden Umgebungsvariablen sollten angelegt werden, alle kleingeschrieben.

http_proxy

Mit der Umgebungsvariablen http_proxy wird konfiguriert welcher Proxy für HTTP-Verbindungen verwendet werden soll. Hierbei sollte unbedingt eine vollständige URL verwendet werden, nicht nur Hostname und Port. Benötigt der Proxy eine Authentifizierung, kann diese in der URL mit angegeben werden.

http_proxy=http://<user>:<password>@<proxy-address>:<port>

Beispiel: http_proxy=http://10.10.10.10:3128

https_proxy

Wie http_proxy, nur für HTTPS-Verbindungen.

Beispiel: https_proxy=https://10.10.10.10:3128

no_proxy

Über die Umgebungsvariable no_proxy wird definiert, für welche Adressen kein Proxy verwendet werden soll. Mehrere Adressen werden hierbei mit Komma getrennt. Für die einzelnen Adressen sollten unbedingt folgende Regeln beachtet werden: * Durchgängig Kleinschreibung verwenden. * Es sollten nur IP-Adressen verwendet werden, wenn auch der Zugriff direkt auf die IP-Adresse erfolgt. Bei der Auswertung der Ausnahmen findet keine Namensauflösung statt. * Es dürfen keine IP-Adressbereiche (CIDR-Matching, wie z.B: 192.168.0.0/24) verwendet werden. * Auch für lokale Adressen und Loopback-Adressen, wie localhost und 127.0.0.1, müssen Ausnahmen definiert werden. * Es dürfen keine Wildcards, wie * oder Regular Expressions, verwendet werden. * Jeder Name wird als Suffix ausgewertet, domain.com definiert daher eine Ausnahme für alle Hostnamen die auf domain.com enden. * Bei jeder Adresse kann, optional, nach einem Doppelpunkt ein Port mit angegeben werden. Dann gilt die Ausnahme nur für den angegebenen Port.

Beispiel: no_proxy=127.0.0.1,localhost,mydomain.example,hostname.domain.com:8080