This is the documentation of an old opsi version. The documentation for the current version 4.3 can be found here.

Requirements

Subsequently the requirements for the installation of an opsi-server will be described.

Supported distributions for server

Distribution

Opsi 4.2

Debian 11 Bullseye

supported

Debian 10 Buster

supported

Debian 9 Stretch

discontinued

Ubuntu 22.04 LTS Jammy Jellyfish

supported

Ubuntu 20.04 LTS Focal Fossa

supported

Ubuntu 18.04 LTS Bionic Beaver

supported

Ubuntu 16.04 LTS Xenial Xerus

unsupported

RHEL 9

supported

RHEL 8

supported

RHEL 7

unsupported

CentOS 8

discontinued

CentOS 7

unsupported

Alma Linux 9

supported

Alma Linux 8

supported

Rocky Linux 9

supported

Rocky Linux 8

supported

SLES 15 SP4

supported

SLES 15 SP3

supported

SLES 15 SP2

supported

SLES 15 SP1

supported

SLES 12 SP*

unsupported

SLES 12

unsupported

openSuse Leap 15-4

supported

openSuse Leap 15-3

discontinued

openSuse Leap 15-2

discontinued

openSuse Leap 15-1

discontinued

openSuse Leap 15

discontinued

UCS 5.0

supported

UCS 4.4

supported

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

Hardware requirements

For an opsi-server on real hardware is needed:

  • x86-64 or ARM64 system.

  • At least 2GB RAM

  • At least 2 CPU cores

  • Disk space requirements depend heavily on the number of opsi packages. For productive systems the following applies:

    • There should always be at least 15GB of free space in the '/tmp' directory.

    • The directory '/var/lib/opsi' should have at least 60GB and should be flexible expandable.

How many opsi clients access an opsi server at the same time depends on the configuration and the daily routines in the respective environment. In large environments, with many simultaneous client connections, the RAM and CPU requirements can increase significantly.

The central opsi service 'opsiconfd' needs about 250MB RAM per worker process. There should be about one worker process available for 20 simultaneous connections. The number of CPU cores should be about half the number of worker processes.

In the standard configuration, additional resources for Samba, MySQL and Redis should be planned on the same system.

Notes on determining hardware requirements

Hardware requirements depend heavily on usage. So here are a few tips to calculate the system requirements.

Memory requirements

Each active Samba connection starts its own Samba process. Estimates vary between 800 kB and 4 MB. How many opsi clients access an opsi server at the same time depends heavily on the daily routines in your environment.

The following values ​​were recommended for Samba 3:

Process

1 user

130 users

500 users

smbd

4 MB

520 MB

2000 MB

Since we do not have any values ​​for current Samba versions, the above figures can only be regarded as a rough estimate and should be extended with a safety margin of 50%.

The memory consumption of opsiconfd depends heavily (but not only) on the number of clients. The following minimum memory consumption can be derived from existing installations. The specified number of users are not active users at the same time, but the total number.

Process

100 users

2000 users

4000 users

opsiconfd

500 MB

1000 MB

2000 MB

You should also implement a safety margin here.

CPU

Opsiconfd currently uses only one core. This core is only fully loaded when many opsi clients (> 100) access the server exactly at the same time. But the operating system, Samba, the database, etc. also require computing time.

I.e. with 500 clients two CPU cores should be sufficient, with 1000 clients four CPU cores should be provided.

Also note that opsi-depots put a strain on the opsi-configserver, which is significantly larger than that of a single client.

Configuration requirements

Your server and your network have to comply to the following requirements to install and work with opsi:

Valid DNS domain name

Your DNS domain name must consist of at least one domain and one toplevel domain. In other words: the fully qualified domain name must contain at least one point. Furthermore, the toplevel domain must consist of at least two characters.

Valid domain names are e.g.: 'domain.local' , 'uib.de', 'subdomain.domain.de'. An invalid example: 'mydomain.d' because this is only one character at the top-level domain An invalid example: 'mydomain' because this is only a top-level domain

see also:

Valid DNS hostname

The hostnames (also of the clients) must comply with the guidelines. This includes, for example, that they must not contain any underscores.

Make sure that at your opsi-server, returns a 'fully qualified domainname', in which at least come two dots, e.g. 'opsiserver.domain.local':

hostname -f

Should the result not look like this (e.g. '127.0.0.1' or 'localhost') then you check your '/etc/hosts' directory or the name resolution first.

see also:
* https://en.wikipedia.org/wiki/Hostname

Correct name resolution for the server

Check the entry for the opsi-server in the file '/etc/hosts', or check the output of:

getent hosts $(hostname -f)

The result should look like the following example:
'192.168.1.1 server.domain.tld server'

Here the IP address should belong to the network interface, to which the Clients will be connecting.

If the result looks different from the above example (contains eg. '127.0.0.1' or 'localhost'), or the full qualified hostname does not contain one or more dots, then you must correct your name resolution (DNS or /etc/hosts file).

The names must be in accordance of the rules of a DNS system but a DNS server is not required for the usage of opsi.
opsi does not require Active Directory or similar. Integrating opsi is possible but not required.

Localization settings

opsi requires configured language settings ('locale') on the server. It is recommended to use an UTF-8 compatible locale.

The following command performs a simplified check:

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

If the output is ok locales are set. If the output is check locales: you should check if the following list has settings for LANG or LC_ALL that are according to your used language.

For English we recommend en_GB.UTF-8 or en_US.UTF-8.

The following commands show how these settings can be changed if nothing or an undesired value is set:

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

To apply these settings systemwide the server should be restarted.

For more information please consult the documentation of your Linux distribution.

Needed network ports

This is an overview of the used ports and network protocols.

Config server = central opsi-server to manage all clients.
Depot server = opsi-server in the individual locations.
If there is only one opsi-server, it takes both roles.

  • opsi-server web service: 4447/tcp +. Client to config and depot server, depot server to config server, also connections via localhost.

  • opsi-client web service: 4441/tcp
    Config server to client, connection from client to itself via localhost.

  • opsi-client Notifier: 45000-45099/tcp
    Connection from client to itself via localhost.
    A random port from the given range is selected.

  • TFTP: 69/udp
    Connection from the client to the depot server.

  • TFTP: 1024-65535/udp
    Connection from the depot server to the client.

  • CIFS/SMB: 445/tcp
    Client to depot server.

  • CIFS/SMB: 445/tcp + connection from Depot server to client.
    Only necessary if opsi-deploy-client-agent (winexe, smbclient) is used for Windows clients.

  • Grafana web service: 3000/tcp
    Connection from client to config server.
    Only if the management web page of the config server is to be accessed from the client.

  • SSH: 22/tcp
    Connection from client to Config server.
    Management access to Config and Depot server.

  • SSH: 22/tcp
    Connection from depot server to client.
    Only necessary if opsi-deploy-client-agent is used for Linux / MacOS clients.

  • DNS: 53/tcp, 53/udp +. All servers / clients must be able to reach your DNS.

  • Wake-on-LAN (WoL): 7/udp, 9/udp, 12287/udp
    Connection from config server to client. These ports are configurable.

  • HTTP: 80/tcp
    Config and depot server to the Internet.
    To load e.g. server updates from http://download.opensuse.org.

  • HTTPS: 443/tcp + Config and depot server to the Internet. Config and depot server to the Internet.
    To load e.g. packages from https://download.uib.de (opsi-package-updater).

Proxy settings

If a HTTP-proxy is used, the proxy settings should be configured system-wide using environment variables. These environment variables are usually stored in the /etc/environment file. The following environment variables should be created, all lowercase.

http_proxy

The environment variable http_proxy configures which proxy should be used for HTTP connections. A complete URL should be used, not only hostname and port. If the proxy requires authentication, this can be specified in the URL.

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

Example: http_proxy=http://10.10.10.10:3128

https_proxy

Like http_proxy, but for HTTPS connections.

Example: https_proxy=https://10.10.10.10:3128

no_proxy

The environment variable no_proxy defines for which addresses no proxy should be used. Multiple addresses are separated by commas. The following rules should be observed for the individual addresses: * Use lower case throughout. * Only IP addresses should be used if access is also made directly to the IP address. No name resolution takes place when evaluating the exceptions. * No IP address ranges (CIDR matching, such as: 192.168.0.0/24) may be used. * Exceptions must also be defined for local addresses and loopback addresses, such as localhost and 127.0.0.1. * No wildcards, such as * or regular expressions, may be used. * Each name is evaluated as a suffix, so domain.com defines an exception for all hostnames ending with domain.com. * For each address, optionally, a port can be specified after a colon. Then the exception applies only to the specified port.

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