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 |
||
Debian 11 Bullseye |
||
Debian 10 Buster |
||
Debian 9 Stretch |
||
Ubuntu 24.04 LTS Noble Numbat |
||
Ubuntu 22.04 LTS Jammy Jellyfish |
||
Ubuntu 20.04 LTS Focal Fossa |
||
Ubuntu 18.04 LTS Bionic Beaver |
||
RHEL 9 |
||
RHEL 8 |
||
AlmaLinux 9 |
||
AlmaLinux 8 |
||
Rocky Linux 9 |
||
Rocky Linux 8 |
||
Oracle Linux 9 |
||
Oracle Linux 8 |
||
SLES 15 SP5 |
||
SLES 15 SP4 |
||
SLES 15 SP3 |
||
SLES 15 SP2 |
||
SLES 15 SP1 |
||
openSUSE Leap 15.6 |
||
openSUSE Leap 15.5 |
||
openSUSE Leap 15.4 |
||
openSUSE Leap 15.3 |
||
UCS 5.0 |
||
UCS 4.4 |
: Supported : Unsupported : Under development : 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.
Siehe auch: * https://de.wikipedia.org/wiki/Hostname#Richtlinien
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