# Was die Server-Provisionierung installiert und einrichtet

> Genau das installiert Vimonto Deploy bei der Provisionierung eines Ubuntu-Servers: Benutzer, SSH, ufw, fail2ban, Swap, Nginx, PHP, Datenbanken, Redis und mehr.

Die Provisionierung macht aus einem frischen Ubuntu-Server einen Server, der für deine Anwendungen bereit ist. Vimonto Deploy führt sie direkt aus, nachdem es [einen Server](https://ops.vimonto.com/docs/de/servers/create-a-server) bei deinem Provider erstellt hat oder nachdem du [deinen eigenen VPS verbunden](https://ops.vimonto.com/docs/de/servers/custom-vps) hast. Sie aktualisiert das System, legt den Serverbenutzer an, sichert SSH ab, schaltet die Firewall und automatische Sicherheitsupdates ein und installiert die Software, die der [Servertyp](https://ops.vimonto.com/docs/de/servers/server-types) braucht.

Die Provisionierung läuft als ein Job, Schritt für Schritt, per SSH. Jeder Schritt ist ein Bash-Skript, das als root läuft, beim ersten Fehler abbricht und gefahrlos erneut ausgeführt werden kann. Eine fehlgeschlagene Provisionierung kannst du also einfach neu starten. Sie dauert meist 5 bis 15 Minuten.

![Die Detailseite eines Jobs mit seinen Schritten, ihrem Status und der Ausgabe jedes Schritts](https://ops.vimonto.com/docs-media/de/task-detail.webp?v=161e760d "Die Provisionierung ist ein Job wie jeder andere: jeder Schritt mit seiner Ausgabe")

## Wie die Provisionierung abläuft

Der Job gruppiert seine Schritte in vier Phasen: **Startet**, **Wird abgesichert**, **Software wird installiert** und **Wird abgeschlossen**.

| Phase | Schritte |
| --- | --- |
| Startet | **Privates Netzwerk anlegen** (wenn du ein neues angefordert hast), **Server bei … anlegen**, **Warten, bis der Server gestartet ist**, **Warten, bis der Server SSH akzeptiert** |
| Wird abgesichert | **System vorbereiten**, **Benutzer und SSH einrichten**, **Firewall einrichten**, **Automatische Sicherheitsupdates aktivieren** |
| Software wird installiert | **Nginx installieren**, **PHP … installieren**, **Node.js installieren**, die Datenbank **installieren**, **Redis und Memcached installieren**, **Meilisearch installieren**, **Supervisor installieren**, je nach Typ |
| Wird abgeschlossen | **Abschließen**, **Monitoring-Agent installieren** |

Ein eigener VPS überspringt die Provider-Schritte und beginnt bei **Warten, bis der Server SSH akzeptiert**. Den Fortschritt siehst du auf der Seite des Servers und auf der Seite [Aktivität](https://ops.vimonto.com/docs/de/organization/activity), mit der vollständigen Ausgabe jedes Befehls unter **Details und Log**. Du musst die Seite nicht geöffnet lassen.

Solange der Server eingerichtet wird (er wird angelegt, wartet auf seinen Verbindungsbefehl, wird provisioniert oder ist dabei fehlgeschlagen), ist seine Übersicht mit dem Fortschritt seine einzige Seite: Es gibt keine Seitenleiste, und jede andere Seite des Servers und seiner Sites führt zurück zur Übersicht. Seine **Einstellungen** öffnen sich weiterhin von der Übersicht aus, damit du einen Server löschen kannst, dessen Einrichtung fehlgeschlagen ist. Die Seitenleiste kommt von selbst zurück, sobald der Server aktiv ist.

## System vorbereiten

- Prüft, ob auf dem Server Ubuntu 24.04 oder 26.04 läuft, und bricht sonst ab.
- Wartet, bis cloud-init fertig ist, falls der Provider es verwendet.
- Setzt den Hostnamen auf den Servernamen (außer die Umgebung verwaltet den Hostnamen selbst) und die Zeitzone auf UTC.
- Führt `apt-get update` und `apt-get upgrade` aus.
- Installiert Basispakete: `software-properties-common`, `ca-certificates`, `curl`, `gnupg`, `lsb-release`, `unzip`, `zip`, `git`, `jq`, `acl`, `rsync`, `ufw`, `fail2ban`, `unattended-upgrades`, `cron`, `logrotate` und `htop`.
- Legt **Swap** an, falls der Server keinen hat: die Hälfte des Arbeitsspeichers, mindestens 1 GB und höchstens 4 GB, in `/swapfile`. Hosts, die keinen Swap erlauben (manche Container), machen ohne weiter.
- Optimiert den Kernel: `vm.swappiness = 10`, `fs.inotify.max_user_watches = 524288` und `net.core.somaxconn = 65535`.

## Der Serverbenutzer und SSH

Jeder Server hat einen **Systembenutzer**, standardmäßig `vimonto`. Deine Sites, Deployments, Queue-Worker und geplanten Jobs laufen unter diesem Benutzer (eine Site, die du isoliert anlegst, bekommt einen eigenen Linux-Benutzer; siehe [Eine Site erstellen](https://ops.vimonto.com/docs/de/sites/create-a-site)).

- Der Benutzer wird mit einem Home-Verzeichnis in `/home/vimonto` angelegt und tritt den Gruppen `sudo` und `www-data` bei.
- Sein **Sudo-Passwort** wird für diesen Server generiert: 24 zufällige Buchstaben und Ziffern. Es wird beim Erstellen des Servers einmalig angezeigt (siehe [Die Passwörter des Servers speichern](https://ops.vimonto.com/docs/de/servers/create-a-server#die-passwörter-des-servers-speichern)).
- `~/.ssh/authorized_keys` erhält den Schlüssel von Vimonto Deploy für diesen Server, die beim Anlegen des Servers gewählten Account-Schlüssel, die Schlüssel der Organisation und die Schlüssel, die die Seite **SSH-Schlüssel** des Servers für diesen Benutzer schon anzeigt. Root akzeptiert dieselben Schlüssel.
- Der Benutzer bekommt einen eigenen Ed25519-Schlüssel (`~/.ssh/id_ed25519`), den **Öffentlichen Schlüssel des Servers** in seiner Übersicht, mit dem er Repositories klonen kann. Die SSH-Host-Keys von GitHub, GitLab und Bitbucket werden zu seinen `known_hosts` hinzugefügt.
- SSH wird gehärtet: Anmeldungen per Passwort und keyboard-interactive sind abgeschaltet, und root darf sich nur mit einem Schlüssel anmelden (`PermitRootLogin prohibit-password`).

Deployments dürfen PHP-FPM und Nginx ohne Passwort neu laden und Supervisor steuern; für alles andere braucht der Benutzer `sudo` mit dem Sudo-Passwort.

### Der SSH-Schlüssel des Servers in Vimonto Deploy

Unabhängig davon bekommt jeder Server beim Erstellen ein eigenes Ed25519-Schlüsselpaar in Vimonto Deploy. Vimonto Deploy verbindet sich damit für die Provisionierung, Deployments und alles andere; der private Schlüssel wird verschlüsselt gespeichert und nie zwischen Servern geteilt. Bei der ersten Verbindung wird der SSH-Host-Key des Servers gespeichert, und Vimonto Deploy verweigert die Verbindung, falls sich dieser Schlüssel jemals ändert.

## Firewall und fail2ban

Die Firewall `ufw` wird zurückgesetzt und so eingestellt, dass sie jeden eingehenden Verkehr abweist und jeden ausgehenden Verkehr erlaubt. Sie erlaubt:

- den SSH-Port (22 oder der Port, den du für einen eigenen VPS eingegeben hast) sowie den Port, auf dem `sshd` tatsächlich lauscht, falls dieser abweicht (für Server hinter NAT);
- die Ports 80 und 443 auf App-Servern, Webservern und Load Balancern;
- auf Datenbank-, Cache- und Meilisearch-Servern in einem [privaten Netzwerk](https://ops.vimonto.com/docs/de/servers/server-types#server-in-einem-privaten-netzwerk) deren Dienst-Ports, nur aus dem Adressbereich dieses Netzwerks: 3306 (MySQL, MariaDB) oder 5432 (PostgreSQL) auf einem Datenbankserver, 6379 (Redis) und 11211 (Memcached) auf einem Cache-Server und 7700 auf einem Meilisearch-Server. Ohne privates Netzwerk kommt keine solche Regel hinzu, und diese Ports bleiben geschlossen.

`fail2ban` wird eingeschaltet und sperrt Adressen, die sich wiederholt erfolglos per SSH anzumelden versuchen. Firewall-Regeln verwaltest du danach auf der Seite [Netzwerk](https://ops.vimonto.com/docs/de/servers/network) des Servers, wo die Regeln aus der Provisionierung aufgeführt sind. Willst du SSH später auf einen anderen Port verlegen, ändere den **SSH-Port** in den [Servereinstellungen](https://ops.vimonto.com/docs/de/servers/server-settings#den-ssh-port-ändern): Die Firewall-Regel und fail2ban ziehen mit.

## Automatische Sicherheitsupdates

`unattended-upgrades` wird eingeschaltet: Paketlisten werden täglich aktualisiert und Sicherheitsupdates täglich installiert, alte Pakete werden wöchentlich aufgeräumt.

## Nginx

Auf App-Servern, Webservern und Load Balancern:

- Nginx läuft als Serverbenutzer und verbirgt seine Version (`server_tokens off`).
- Anfragen bis 64 MB sind erlaubt (`client_max_body_size 64M`), und die gzip-Komprimierung ist für Text, CSS, JavaScript, JSON, XML und SVG eingeschaltet.
- Die Standard-Site wird entfernt. Ein Catch-all-Server beantwortet Anfragen für unbekannte Hostnamen mit gar nichts (Status 444), statt die erste Site anzuzeigen.
- Die Konfiguration wird mit `nginx -t` geprüft, bevor Nginx neu gestartet wird.

Jede Site erhält später ihre eigene Konfiguration; siehe [Nginx](https://ops.vimonto.com/docs/de/sites/nginx).

## PHP

Auf App-, Web- und Worker-Servern wird die gewählte PHP-Version (8.1 bis 8.5) aus dem Repository `ondrej/php` installiert, mit PHP-FPM und diesen Erweiterungen: bcmath, cli, curl, fpm, gd, igbinary, imagick, intl, mbstring, memcached, msgpack, mysql, pgsql, readline, redis, soap, sqlite3, xml und zip.

- PHP-FPM läuft als Serverbenutzer mit bis zu 5 Prozessen.
- PHP-FPM-Einstellungen: `memory_limit` 512 MB, Uploads bis 64 MB, `max_execution_time` 60 Sekunden, `max_input_vars` 1000, OPcache an, `expose_php` aus, Zeitzone UTC.
- Die Kommandozeile erhält `memory_limit = 1G`.
- **Composer** wird in `/usr/local/bin/composer` installiert, nachdem die Signatur seines Installers geprüft wurde.

Diese Einstellungen änderst du und weitere Versionen installierst du auf der Seite [PHP](https://ops.vimonto.com/docs/de/servers/php).

## Node.js

App- und Webserver erhalten Node.js 22 mit npm von NodeSource, um bei Deployments Frontend-Assets zu bauen.

## Datenbank

App-Server (außer du hast **Keine** gewählt) und Datenbankserver erhalten die gewählte Datenbank:

| Datenbank | Installiert aus |
| --- | --- |
| MySQL 8.4 LTS | Oracles MySQL-Repository |
| MySQL 8.0 | Ubuntu |
| MariaDB 11.4 LTS | Repository von MariaDB |
| MariaDB 10.11 LTS | Ubuntu |
| PostgreSQL 18 oder 17 | Das PostgreSQL-Repository |
| PostgreSQL 16 | Ubuntu |

Für jede Datenbank gilt:

- Ein nach dem Serverbenutzer benannter Datenbankbenutzer (`vimonto`) wird mit vollen Rechten und dem **Datenbankpasswort** angelegt: 32 zufällige Buchstaben und Ziffern, einmalig angezeigt. Eine Datenbank mit demselben Namen wird ebenfalls angelegt.
- MySQL und MariaDB verwenden `utf8mb4` mit `utf8mb4_unicode_ci`, UTC und bis zu 300 Verbindungen. Der Benutzer root hat kein Passwort und kann sich nur auf dem Server selbst anmelden.
- PostgreSQL verwendet UTC und bis zu 300 Verbindungen und akzeptiert Anmeldungen per Passwort (`scram-sha-256`); die Firewall entscheidet, wer sich verbinden darf.
- Auf einem **App-Server** lauscht die Datenbank nur auf dem Server selbst. Auf einem **Datenbankserver** lauscht sie auf allen Adressen, damit sich deine anderen Server verbinden können: In einem privaten Netzwerk lässt die Firewall sie bereits zu (siehe oben), sonst sobald du eine Regel für sie hinzufügst.

Die Provisionierung prüft außerdem, ob die installierte Version der gewählten entspricht. Datenbanken und Benutzer verwaltest du auf der Seite [Datenbanken](https://ops.vimonto.com/docs/de/servers/databases).

## Redis und Memcached

App-Server und Cache-Server erhalten Redis und Memcached. Auf einem App-Server lauschen sie nur auf dem Server selbst. Auf einem Cache-Server lauschen sie auf allen Adressen, und Redis läuft ohne Protected Mode, damit deine anderen Server sie nutzen können; in einem privaten Netzwerk erlaubt die Firewall ihre Ports nur aus diesem Netzwerk.

## Meilisearch

Ein Meilisearch-Server erhält die neueste Meilisearch-Binary. Sie läuft unter systemd als eigener Systembenutzer `meilisearch`, im Produktionsmodus auf Port 7700, mit Daten in `/var/lib/meilisearch`. Der Master Key ist das generierte Passwort, das einmalig als **Meilisearch Master Key** angezeigt wird.

## Supervisor

App-, Web- und Worker-Server erhalten Supervisor, der deine Queue-Worker und andere [Prozesse](https://ops.vimonto.com/docs/de/servers/processes) am Laufen hält.

## Abschluss und der Monitoring-Agent

Die letzten Schritte:

- zwei geplante Standard-[Jobs](https://ops.vimonto.com/docs/de/servers/scheduler) hinzufügen, die als root laufen: **Composer aktualisieren** (nächtlich) und **Ungenutzte Pakete aufräumen** (wöchentlich);
- nicht mehr benötigte Pakete entfernen und den Paket-Cache leeren;
- die Ubuntu-Version und den öffentlichen Schlüssel des Servers speichern;
- den **Monitoring-Agent** installieren: ein kleines Bash-Skript, das Cron jede Minute ausführt. Es misst CPU, Load, Arbeitsspeicher, Festplatte und Netzwerk und sendet die Werte an Vimonto Deploy. Dafür lauscht nichts auf dem Server. Siehe [Monitoring](https://ops.vimonto.com/docs/de/servers/monitoring).

Schlägt nur die Installation des Agents fehl, ist der Server trotzdem aktiv; du kannst den Agent auf der Seite **Monitoring** erneut installieren.

Ist alles erledigt, wird der Server **Aktiv**, und was installiert wurde, erscheint auf seinen Seiten: die Firewall-Regeln, die PHP-Version, die Datenbank und ihr Benutzer, die SSH-Schlüssel und die geplanten Jobs.

Mitglieder, die den Server sehen können, bekommen die Benachrichtigung **Server bereit** oder, wenn die Einrichtung mit einem Fehler abbricht, **Einrichten eines Servers fehlgeschlagen**, über die Kanäle, die sie unter [Benachrichtigungen](https://ops.vimonto.com/docs/de/more/notifications) gewählt haben.

## Was, wenn die Provisionierung fehlschlägt?

Schlägt ein Schritt fehl, stoppt der Job, der Server erhält den Status **Fehlgeschlagen**, und seine Seite zeigt **Provisionierung fehlgeschlagen** mit dem Schritt und seinem Exit-Code. Die Ausgabe unter **Details und Log** zeigt, was schiefging.

1. Lies die Ausgabe des fehlgeschlagenen Schritts. Häufige Ursachen: ein vorübergehend nicht erreichbarer Paketspiegel, ein Server, der nicht innerhalb von 15 Minuten startet oder SSH akzeptiert, eine Firewall beim Provider, die SSH blockiert, oder ein System, das nicht Ubuntu 24.04 oder 26.04 ist.
2. Behebe die Ursache, falls sie bei dir liegt.
3. Wähle auf der Seite des Servers **Erneut versuchen**. Dafür brauchst du die Berechtigung, Server zu erstellen.

Die Provisionierung läuft dann noch einmal von vorn. Das ist sicher: Ein bereits beim Provider erstellter Server wird nicht erneut erstellt, jeder Schritt prüft, was schon erledigt ist, und `apt-get` wartet auf Sperren durch automatische Updates und versucht es erneut. Hattest du die Passwörter bereits bestätigt, werden neue Sudo- und Datenbankpasswörter generiert und noch einmal einmalig angezeigt. Es werden dieselben SSH-Schlüssel installiert wie beim ersten Versuch, auch wenn ein Account-Schlüssel inzwischen gelöscht wurde.

> [!TIP]
> Ein Schritt darf bis zu 25 Minuten laufen, bevor er abgebrochen wird. Ein Schritt, der zu hängen scheint, wartet meist auf `apt-get`, das nach dem ersten Start bis zu 10 Minuten auf eine Sperre durch Ubuntus eigene Updates wartet.

## Häufig gestellte Fragen

### Wie lange dauert die Provisionierung?

Meist insgesamt 5 bis 15 Minuten. Das Aktualisieren von Ubuntu und das Installieren der Datenbank dauern am längsten; ein Cache- oder Load-Balancer-Server ist schneller fertig als ein App-Server.

### Kann ich die ausgeführten Befehle sehen?

Ja. Die Ausgabe jedes Schritts steht im Job, unter **Details und Log** auf der Seite des Servers oder auf der Seite [Aktivität](https://ops.vimonto.com/docs/de/organization/activity).

### Wie heißt der Systembenutzer?

Standardmäßig `vimonto`. Der Name wird beim Erstellen pro Server gespeichert.

### Ändert die Provisionierung meinen Server, nachdem sie abgeschlossen ist?

Nein. Nach der Provisionierung ändert sich nur etwas, wenn du oder ein Deployment etwas ändert, dazu kommen Ubuntus automatische Sicherheitsupdates und die geplanten Standard-Jobs.