OpenBSD: Systemkonfiguration nach der Installation

OpenBSD konfiguriert Systeme über Textdateien. Jedes Netzwerk-Interface erhält eine eigene Konfigurationsdatei in /etc/hostname.INTERFACE. Die Zeitsynchronisation erfolgt über ntpd mit eingebauter Zeitzonenunterstützung. Rechteverwaltung funktioniert über doas – OpenBSDs System für delegierte Root-Rechte. Kernel-Parameter lassen sich über sysctl anpassen.

Dieser Artikel erklärt Netzwerk-Konfiguration über hostname.if-Dateien - für nachträgliche Anpassung nach der Installation sowie erweiterte Setups für Server, Desktop-Systeme und spezielle Anforderungen. Die Dateisystem-Struktur folgt dabei konsequent den OpenBSD-Konventionen.

Netzwerk-Konfiguration mit hostname.if

Jedes Netzwerk-Interface wird über eine separate Datei gesteuert. Der Dateiname folgt dem Pattern /etc/hostname.INTERFACE – beispielsweise /etc/hostname.em0 für Intel-Netzwerkkarten oder /etc/hostname.vio0 bei virtuellen Maschinen.

Die Installation erstellt diese Dateien automatisch basierend auf den Installer-Eingaben. Manuelle Änderungen erfolgen über einen Texteditor:

$ doas vi /etc/hostname.vio0

Automatische Konfiguration via DHCP

Die einfachste Konfiguration nutzt DHCP für automatische IP-Zuweisung:

/etc/hostname.vio0:
inet autoconf
inet6 autoconf

inet autoconf aktiviert die automatische IPv4-Konfiguration auf dem Interface; dhcpleased übernimmt daraufhin die DHCP-Konfiguration. inet6 autoconf aktiviert die automatische IPv6-Konfiguration; slaacd verarbeitet dafür Router Advertisements und SLAAC. Gelernte DNS-Informationen werden an resolvd weitergegeben, das /etc/resolv.conf verwaltet.

IPv6-Verhalten steuern

IPv6-Autokonfiguration wird für ein Interface mit inet6 autoconf aktiviert. slaacd verarbeitet anschließend Router Advertisements und konfiguriert daraus unter anderem IPv6-Adressen.

IPv6 komplett deaktivieren:

/etc/hostname.vio0:
inet autoconf
-inet6

Dies entfernt alle IPv6-Adressen und deaktiviert die IPv6-Autoconfiguration auf dem Interface.

Die Konfiguration aktiviert sich beim nächsten Neustart oder sofort via:

$ doas sh /etc/netstart vio0

Das Skript /etc/netstart liest die hostname.if-Datei und wendet die Konfiguration auf das Interface an. Daemons wie dhcpleased reagieren auf den dabei gesetzten Interface-Zustand.

Statische IP-Konfiguration

Server benötigen häufig feste IP-Adressen. Statische Konfiguration definiert IP-Adresse, Netzmaske und Gateway explizit:

/etc/hostname.vio0:
inet 192.168.1.10 255.255.255.0
!route add default 192.168.1.1

Die erste Zeile konfiguriert IP und Netzmaske. Die zweite Zeile setzt die Default-Route. Das Ausrufezeichen ! führt den nachfolgenden Befehl während der Interface-Aktivierung aus.

CIDR-Notation (Classless Inter-Domain Routing) funktioniert ebenfalls. Statt der Netzmaske in Dezimalschreibweise gibt /24 die Anzahl gesetzter Bits an - 24 Bits ergeben 255.255.255.0:

/etc/hostname.vio0:
inet 192.168.1.10/24
!route add default 192.168.1.1

Der DNS-Resolver benötigt manuelle Konfiguration in /etc/resolv.conf:

/etc/resolv.conf:
nameserver 192.168.1.1
nameserver 192.168.1.2
lookup file bind

Die lookup-Zeile definiert die Reihenfolge für Namensauflösung – zuerst /etc/hosts, dann DNS-Abfragen.

Mehrere IP-Adressen auf einem Interface

Ein Interface kann mehrere IP-Adressen tragen – nützlich für virtuelle Hosts oder Service-Trennung:

/etc/hostname.vio0:
inet 192.168.1.10/24
inet alias 192.168.1.11/24
inet alias 192.168.1.12/24
!route add default 192.168.1.1

Das Keyword alias definiert zusätzliche IP-Adressen auf dem Interface.

Zusätzliche Adressen können auch aus einem anderen direkt angeschlossenen Subnetz stammen. Durch die konfigurierte Adresse und Netzmaske kennt das System dieses Netz bereits; eine zusätzliche Gateway-Route ist dafür nicht allein aufgrund der zweiten Adresse erforderlich.

CIDR-Notation (/24) und Dezimalschreibweise (255.255.255.0) können bei der Konfiguration verwendet werden.

VLAN-Konfiguration

VLANs trennen Netzwerk-Traffic logisch. OpenBSD erstellt VLAN-Interfaces über vlan0, vlan1 usw.:

/etc/hostname.vlan10:
vnetid 10
parent vio0
inet 192.168.10.1/24
up
description "Management VLAN"

Die Konfiguration definiert:

• vnetid 10 - VLAN-ID
• parent vio0 - Basisinterface (hier: virtio in VM, auf Hardware z.B. em0)
• up - Interface aktivieren
• description - Optionale Beschreibung für ifconfig-Ausgabe

Das Basisinterface vio0 benötigt keine IP-Adresse, wenn nur VLANs darauf laufen:

/etc/hostname.vio0:
up

Mehrere VLANs nutzen dasselbe Parent-Interface:

/etc/hostname.vlan20:
vnetid 20
parent vio0
inet 192.168.20.1/24
description "Service VLAN"
up

Wireless-Netzwerke

WiFi-Konfiguration erfolgt über die entsprechenden Interface-Dateien. Der Interface-Name hängt vom Treiber ab – beispielsweise iwm0 für Intel-Chips oder athn0 für Atheros.

WPA2-Konfiguration mit PSK:

/etc/hostname.iwm0:
nwid "HomeNetwork" wpakey "supersecret123"
inet autoconf

Die Parameter definieren:

• nwid - SSID des Netzwerks
• wpakey - WPA2-Passphrase
• inet autoconf - DHCP nach erfolgreicher Verbindung

Hidden Networks (SSID wird nicht gebroadcastet) funktionieren mit derselben Syntax. Die SSID muss manuell angegeben werden – der Scan zeigt sie ohne Namen.

Bridge-Konfiguration

Bridges verbinden mehrere Netzwerk-Interfaces auf Layer 2. Typischer Anwendungsfall: Virtuelle Maschinen direkt ins physische Netzwerk integrieren.

/etc/hostname.bridge0:
add em0
add vio0
up

Die Bridge bridge0 verbindet die Interfaces em0 und vio0 auf Layer 2. Frames können dadurch zwischen den Bridge-Mitgliedern weitergeleitet werden.

Die verbundenen Interfaces benötigen keine IP-Adressen:

/etc/hostname.em0:
up

/etc/hostname.vio0:
up

Die IP-Konfiguration erfolgt auf der Bridge selbst:

/etc/hostname.bridge0:
add em0
add vio0
inet 192.168.1.10/24
!route add default 192.168.1.1
up

Netzwerk-Konfiguration aktivieren

Änderungen an hostname.if-Dateien aktivieren sich beim Neustart. Für sofortige Aktivierung:

$ doas sh /etc/netstart vio0

Das Skript wendet die Konfiguration aus der entsprechenden hostname.if-Datei auf das Interface an.

Die Netzwerkkonfiguration vollständig erneut anwenden:

$ doas sh /etc/netstart

Das System führt die Netzwerkinitialisierung anhand der vorhandenen Konfigurationsdateien erneut aus. Dabei werden auch konfigurierbare Interfaces wie VLAN-Interfaces berücksichtigt.

Zeit und Zeitsynchronisation

OpenBSD nutzt ntpd für Zeitsynchronisation. Der Daemon ist Teil des Base-Systems – keine zusätzlichen Pakete notwendig. ntpd wird auf einer Standardinstallation beim Boot gestartet.

ntpd-Konfiguration

Die Datei /etc/ntpd.conf steuert die Zeitsynchronisation:

/etc/ntpd.conf (Default):
servers pool.ntp.org
server time.cloudflare.com
sensor *

constraint from "9.9.9.9"              # quad9 v4 without DNS
constraint from "2620:fe::fe"          # quad9 v6 without DNS
constraints from "www.google.com"      # intentionally not 8.8.8.8

Die Zeilen definieren:

• servers pool.ntp.org - Nutzt alle IP-Adressen des NTP-Pools. Der Daemon synchronisiert mit mehreren Servern gleichzeitig.
• server time.cloudflare.com - Einzelner zusätzlicher NTP-Server.
• sensor * - Verwendet alle verfügbaren timedelta-Sensoren als zusätzliche Zeitquellen.
• constraint from - Definiert eine HTTPS-basierte Zeit-Constraint. Mehrere konfigurierte Constraints werden gemeinsam zur Validierung der NTP-Zeit verwendet.
• constraints from - Nutzt alle IP-Adressen eines aufgelösten Hostnamens als Constraints.

Die Constraints liefern eine authentifizierte Zeitgrenze über HTTPS. Dadurch können die Auswirkungen manipulierter oder gefälschter NTP-Antworten reduziert werden.

Zeitzone konfigurieren

Die Systemzeit läuft intern auf UTC. Die lokale Zeitzone wird über einen Symlink definiert:

$ ls -l /etc/localtime
lrwxr-xr-x  1 root  wheel  33 Nov  1 21:27 /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin

Zeitzone ändern:

$ doas rm /etc/localtime
$ doas ln -s /usr/share/zoneinfo/Europe/Zurich /etc/localtime

Verfügbare Zeitzonen liegen in /usr/share/zoneinfo/. Die Verzeichnisstruktur folgt der IANA-Zeitzonendatenbank – Kontinent/Stadt-Format.

ntpd-Daemon verwalten

Der NTP-Daemon startet automatisch beim Boot. Status prüfen:

$ rcctl check ntpd
ntpd(ok)

Status-Ausgabe (ok) bedeutet: Daemon läuft. Zeitliche Synchronisation prüfen:

$ ntpctl -s status
5/5 peers valid, 1/1 sensors valid, constraint offset -2s, clock synced, stratum 3

Die Ausgabe zeigt:

• 5/5 peers valid - Alle konfigurierten NTP-Server antworten
• 1/1 sensors valid - Ein Zeitsensor ist gültig
• constraint offset -2s - Zeitlicher Offset der ermittelten Constraint gegenüber der lokalen Systemzeit
• clock synced - System-Zeit ist synchronisiert
• stratum 3 - Synchronisationshierarchie des lokalen Systems. Niedrigere Stratum-Werte stehen für eine kürzere Hierarchie zu einer Referenzzeitquelle.

Detaillierte Peer-Informationen:

$ ntpctl -s peers
peer
   wt tl st  next  poll          offset       delay      jitter
162.159.200.1 time.cloudflare.com
    1 10  3 1551s 1627s         1.717ms    30.046ms     8.432ms
217.144.138.234 from pool pool.ntp.org
    1 10  2 1341s 1521s         3.957ms    42.019ms     9.079ms
94.130.35.4 from pool pool.ntp.org
    1 10  2    7s 1633s         1.234ms    40.783ms     8.753ms
45.9.61.155 from pool pool.ntp.org
 *  1 10  2 1381s 1565s         4.494ms    42.251ms    14.893ms
185.252.140.126 from pool pool.ntp.org
    1 10  2   30s 1641s         1.857ms    44.043ms    10.572ms

Die Spalten bedeuten:

• wt (weight) - Gewichtung der Zeitquelle; Standardwert ist 1
• tl (trust level) - Interner Vertrauenswert des Peers
• st (stratum) - Hierarchieebene des Servers
• next - Sekunden bis zur nächsten Abfrage
• poll - Aktuelles Poll-Intervall in Sekunden (passt sich automatisch an)
• offset - Zeitdifferenz zwischen Server und lokalem System
• delay - Netzwerk-Latenz zum Server (Round-Trip-Time)
• jitter - Schwankung der Zeitdifferenz über mehrere Messungen

Der Stern * markiert den Peer, zu dem die Systemuhr aktuell synchronisiert ist.

Zeitsynchronisation bei großen Abweichungen

ntpd korrigiert Zeitabweichungen graduell über adjtime(2) und vermeidet dabei Zeitsprünge. Bei größeren Abweichungen kann die vollständige Korrektur entsprechend länger dauern.

Für schnellere initiale Synchronisation kann rdate die Systemzeit sofort setzen:

$ doas rdate pool.ntp.org
$ doas rcctl restart ntpd

Mit ntpctl -s status lässt sich prüfen, ob die Systemzeit bereits den Status clock synced erreicht hat. Wie lange dies nach dem Start dauert, hängt unter anderem von den erreichbaren Zeitquellen und dem Ausgangszustand der Systemuhr ab.

Rechteverwaltung mit doas

OpenBSD nutzt doas für privilegierte Befehle. Das Tool folgt dem OpenBSD-Prinzip der Einfachheit - wenige Konfigurationsoptionen, klare Syntax. Die Konfiguration erfolgt in /etc/doas.conf.

Basis-Konfiguration

Der Installations-Artikel zeigt eine minimale doas-Konfiguration. Für reguläre Nutzung empfiehlt sich eine erweiterte Konfiguration:

/etc/doas.conf:
permit persist :wheel
permit nopass keepenv root as root

Die Regeln im Detail:

permit persist :wheel - Mitglieder der wheel-Gruppe dürfen mit doas Befehle als andere Benutzer ausführen. Das persist-Flag merkt sich eine erfolgreiche Authentifizierung für eine begrenzte Zeit, sodass wiederholte doas-Aufrufe nicht sofort erneut nach dem Passwort fragen.

permit nopass keepenv root as root - Für root als aufrufenden und Zielbenutzer ist keine Passwortabfrage erforderlich; keepenv übernimmt zusätzlich die Umgebung des Aufrufers.

Benutzer-spezifische Regeln

Einzelne Benutzer können spezielle Rechte erhalten:

/etc/doas.conf:
permit persist :wheel
permit nopass michael cmd /usr/sbin/pkg_add
permit nopass michael cmd /usr/sbin/pkg_delete
permit nopass sandra cmd /usr/sbin/rcctl args restart httpd

Die Regeln definieren:

permit nopass michael cmd /usr/sbin/pkg_add - Benutzer michael darf pkg_add ohne Passwort ausführen. Nützlich für häufige Paket-Installationen.

permit nopass sandra cmd /usr/sbin/rcctl args restart httpd - Benutzer sandra darf nur rcctl restart httpd ausführen. Das args-Keyword beschränkt die erlaubten Parameter.

Umgebungsvariablen kontrollieren

Standardmäßig erzeugt doas eine neue Umgebung für den Zielbenutzer und setzt dabei unter anderem HOME, LOGNAME, PATH, SHELL und USER passend zum Ziel. Mit keepenv werden zusätzlich Variablen aus der Umgebung des aufrufenden Benutzers übernommen:

/etc/doas.conf:
permit persist keepenv :wheel

Präzisere Kontrolle bietet setenv mit vier Varianten:

/etc/doas.conf:
permit persist setenv { -ENV PS1=$DOAS_PS1 SSH_AUTH_SOCK PATH=/sbin:/bin } :wheel

Die Syntax unterstützt:

• SSH_AUTH_SOCK - Variable aus User-Environment behalten
• PS1=$DOAS_PS1 - Wert aus existierender Variable nehmen (mit $)
• PATH=/sbin:/bin - Auf festen Wert setzen
• -ENV - Variable explizit entfernen (mit -)

Mehrere Definitionen werden durch Leerzeichen getrennt.

doas-Konfiguration testen

Kann /etc/doas.conf nicht geparst werden, schlägt die Rechteprüfung fehl. Die Konfiguration lässt sich deshalb vor der Verwendung prüfen:

$ doas -C /etc/doas.conf

Der Parameter -C parst und prüft die Konfigurationsdatei, ohne einen Befehl auszuführen. Eine fehlerfreie Konfiguration gibt bei diesem Aufruf keine Ausgabe zurück. Syntaxfehler werden mit Zeilennummer gemeldet.

Kernel-Parameter mit sysctl

Das Tool sysctl liest und ändert Kernel-Parameter zur Laufzeit. Die Werte sind nach Kategorien gruppiert – Netzwerk, Dateisystem, Hardware, Sicherheit.

Verfügbare Parameter anzeigen

Alle verfügbaren Parameter auflisten:

$ sysctl -a
kern.ostype=OpenBSD
kern.osrelease=7.9
kern.osrevision=202605
kern.version=OpenBSD 7.9 (GENERIC.MP) #449: Wed May  6 13:17:25 MDT 2026
    deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

kern.maxvnodes=12277
kern.maxproc=1310
kern.maxfiles=7030
[...]

Die Ausgabe zeigt mehrere hundert Parameter. Nach Kategorien filtern:

$ sysctl net.inet.ip
net.inet.ip.forwarding=0
net.inet.ip.redirect=1
net.inet.ip.ttl=64
net.inet.ip.mtudisc=1

Die hierarchische Struktur ermöglicht präzisere Abfragen einzelner Bereiche und Parameter.

Wichtige Netzwerk-Parameter

IP-Forwarding aktivieren - notwendig, wenn das System IPv4-Pakete zwischen Interfaces routen soll:

$ doas sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1

Das System leitet IPv4-Pakete zwischen Interfaces weiter. Auf einer Standardinstallation ist IPv4-Forwarding deaktiviert.

IPv6-Forwarding funktioniert analog:

$ doas sysctl net.inet6.ip6.forwarding=1

Systemlimits anpassen:

$ doas sysctl kern.maxfiles=10000
$ doas sysctl kern.maxproc=2000

Der Parameter maxfiles begrenzt die systemweite Anzahl offener Dateien, maxproc die maximale Anzahl gleichzeitiger Prozesse. Ob diese Limits angepasst werden müssen, hängt vom konkreten Ressourcenbedarf des Systems und seiner Dienste ab.

Permanente Änderungen

Permanente Konfiguration erfolgt in /etc/sysctl.conf. Ist die Datei nicht vorhanden, kann sie bei Bedarf erstellt werden:

$ doas vi /etc/sysctl.conf

Inhalt:

net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1
kern.maxfiles=10000

Die Datei wird beim Boot automatisch gelesen. Syntax ist identisch zu sysctl-Befehlen, nur ohne das sysctl-Prefix – beispielsweise net.inet.ip.forwarding=1 statt sysctl net.inet.ip.forwarding=1.

Dateisystem-Struktur

OpenBSD folgt BSD-Konventionen bei der Dateisystem-Struktur. Einige Unterschiede zu Linux existieren – besonders bei System-Verzeichnissen und Package-Verwaltung.

Base-System vs. Packages

OpenBSD trennt Base-System und zusätzlich installierte Packages. Programme und Bibliotheken des Base-Systems liegen unter anderem in /bin, /sbin, /usr/bin und /usr/sbin. Packages werden grundsätzlich unter /usr/local installiert; einzelne Dateien können abhängig vom Package auch an dafür vorgesehenen anderen Stellen liegen. Der Artikel Paketverwaltung erklärt diese Trennung im Detail.

Wichtige System-Verzeichnisse

/etc - System-Konfiguration. Alle wichtigen Konfigurationsdateien liegen hier:

• hostname.* - Netzwerk-Konfiguration
• rc.conf.local - lokale Service-Konfiguration
• doas.conf - Rechteverwaltung
• sysctl.conf - persistente Kernel-Parameter

/var - Variable Daten. Log-Dateien, Spool-Verzeichnisse, temporäre Daten:

• /var/log - System-Logs
• /var/mail - Mail-Spool
• /var/www - Default-Webroot
• /var/run - Runtime-Dateien (PIDs, Sockets)

/usr/local - Installierte Packages:

• /usr/local/bin - Ausführbare Programme
• /usr/local/lib - Bibliotheken
• /usr/local/share - Gemeinsame Daten
• /usr/local/etc - Package-spezifische Konfiguration (wird bei Bedarf erstellt)

/home - Benutzer-Verzeichnisse. Standard-Layout mit versteckten Konfigurationsdateien (.profile, .kshrc).

X11-Struktur

X11-Komponenten liegen unter /usr/X11R6 - allerdings nur wenn die X11-Sets bei der Installation ausgewählt wurden:

/usr/X11R6/bin       # X11-Programme (xterm, xclock)
/usr/X11R6/lib       # X11-Bibliotheken
/usr/X11R6/share     # Fonts, Icons, Themes

Diese Trennung hält die mit OpenBSD ausgelieferten X11-Komponenten in einem eigenen Verzeichnisbaum.

Device-Nodes

Device-Nodes liegen in /dev. Sie bilden die Schnittstelle zu den vom Kernel bereitgestellten Geräten. Die benötigten Special Files werden unter OpenBSD unter anderem mit /dev/MAKEDEV erzeugt:

$ ls -l /dev/sd0*
brw-r-----  1 root  operator  4,  0 Jun  9 10:26 /dev/sd0a
brw-r-----  1 root  operator  4,  1 Jun  9 10:26 /dev/sd0b
brw-r-----  1 root  operator  4,  2 Jun  9 10:26 /dev/sd0c
[...]

Die Buchstaben-Suffixe bezeichnen Partitionen des OpenBSD-Disklabels:

• a - auf der Bootdisk konventionell die Root-Partition (/)
• b - auf der Bootdisk konventionell Swap
• c - das gesamte physische Device; diese Partition hat eine besondere Bedeutung
• d-p - weitere Partitionen nach Bedarf

Die konkreten Zuordnungen außer c hängen vom jeweiligen Disklabel ab. Das Skript /dev/MAKEDEV erzeugt Device-Nodes bei Bedarf.

Mount-Punkte

Die Datei /etc/fstab definiert automatische Mounts beim Boot:

$ cat /etc/fstab
1d2d758e4ba30877.b none swap sw
1d2d758e4ba30877.a / ffs rw 1 1
1d2d758e4ba30877.k /home ffs rw,nodev,nosuid 1 2
1d2d758e4ba30877.d /tmp ffs rw,nodev,nosuid 1 2
1d2d758e4ba30877.f /usr ffs rw,nodev 1 2
1d2d758e4ba30877.g /usr/X11R6 ffs rw,nodev 1 2
1d2d758e4ba30877.h /usr/local ffs rw,wxallowed,nodev 1 2
1d2d758e4ba30877.j /usr/obj ffs rw,nodev,nosuid 1 2
1d2d758e4ba30877.i /usr/src ffs rw,nodev,nosuid 1 2
1d2d758e4ba30877.e /var ffs rw,nodev,nosuid 1 2

Die hexadezimalen Strings sind DUIDs – eindeutige Device-IDs. In /etc/fstab können DUIDs statt Gerätenamen wie /dev/sd0a verwendet werden. Dadurch bleibt die Referenz auf ein Dateisystem unabhängig davon, unter welchem Gerätenamen die Festplatte erkannt wird. Die Partitionsbuchstaben (a, b, d, e, …) werden bei der Installation vergeben und variieren je nach gewähltem Partitionierungsschema.

Die Mount-Optionen:

• rw - Read-Write-Zugriff
• nodev - Special Files auf diesem Dateisystem werden nicht als Devices interpretiert
• nosuid - Set-user-ID- und Set-group-ID-Bits werden beim Ausführen nicht wirksam
• wxallowed - erlaubt ausführbare, zugleich beschreibbare Speicherabbildungen für Programme auf diesem Dateisystem, beispielsweise für Software mit JIT-Compiler

Temporäre Dateisysteme

In der gezeigten Installation liegt /tmp auf einem separaten Dateisystem. Bei Systemen mit ausreichend verfügbarem Speicher kann /tmp als tmpfs gemountet werden:

$ cat /etc/fstab
swap /tmp tmpfs rw,nodev,nosuid,-s=2G 0 0

Das tmpfs verwendet virtuellen Speicher statt eines persistenten Blockgeräts. Der Parameter -s=2G limitiert die Größe auf 2 Gigabyte. Da das Dateisystem nicht persistent ist, sind seine Inhalte nach einem Neustart nicht mehr vorhanden.

Verwendete Informationen

Diese Anleitung bezieht sich auf:

• OpenBSD: 7.8, 7.9
• Architektur: amd64 (primär), allgemeine Konzepte gelten für alle Plattformen
• Kontext: Server- und Desktop-Konfiguration
• Stand: August 2026

Die Systemkonfiguration bildet die Grundlage für produktive OpenBSD-Systeme. Der nächste Artikel behandelt die Paketverwaltung – Software-Installation und Updates.