Was die Server-Provisionierung installiert und einrichtet

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 bei deinem Provider erstellt hat oder nachdem du deinen eigenen VPS verbunden 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 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.

Wie die Provisionierung abläuft#

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

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, 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).

• 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).
• ~/.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 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 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: 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.

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.

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:

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.

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 am Laufen hält.

Abschluss und der Monitoring-Agent#

Die letzten Schritte:

• zwei geplante Standard-Jobs 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.

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 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.

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.

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.