Skip to main content

CLI-Befehle im Container

CLI-Befehle im Container

Diese Befehle stehen im SSH-Zugang deines Containers zur Verfuegung. Alle laufen als dein Container-User (kein sudo noetig, kein Root-Zugriff).

webunit-supervisor — Hintergrund-Prozesse

Verwaltung von Symfony-Messenger-Workern, Queue-Workern, Node-Daemons.

webunit-supervisor reload         # ~/.webunit/supervisor.d/*.conf einlesen
webunit-supervisor status         # Status aller Programme
webunit-supervisor restart <name> # Ein Programm neu starten
webunit-supervisor tail <name>    # Log-Zeilen (stdout)
webunit-supervisor tail-err <name># Log-Zeilen (stderr)
webunit-supervisor validate       # Syntax-Check ohne Reload
webunit-supervisor help

Details siehe Hintergrund-Prozesse (Supervisor).

webunit-ssh — SSH-Auth-Verwaltung

webunit-ssh status                    # Aktueller PW-Auth-Modus + Key-Anzahl
webunit-ssh list-keys                 # Aktive SSH-Keys auflisten
webunit-ssh add-key '<pubkey>'        # SSH-Public-Key hinzufuegen
webunit-ssh remove-key <fingerprint>  # SSH-Key loeschen (fp aus list-keys)
webunit-ssh password-auth on|off      # Passwort-Login erlauben / sperren
webunit-ssh help

Beispiel-Ausgabe:

== SSH-Auth-Konfiguration ==
Passwort-Login:   DEAKTIVIERT (nur Key)
Aktive Keys:      3
Verwaltet in:     /etc/webunit/sshpiper_pub.key (managed — nicht editieren)
Key hinzufuegen:  webunit-ssh add-key '<public-key>'

Wichtig zu ~/.ssh/authorized_keys: Diese Datei wird von unserer Infrastruktur IGNORIERT. Eintraege dort haben keine Wirkung. Die Datei enthaelt bewusst nur einen Hinweis-Text und ist read-only — sshd im Container liest ausschliesslich /etc/webunit/sshpiper_pub.key, was vom Admin-System zentral verwaltet wird.

Keys hinzufuegen: webunit-ssh add-key '<public-key>' (siehe unten) oder im Admin-Panel unter „SSH-Keys".

Keys auflisten:

$ webunit-ssh list-keys
== Aktive SSH-Keys (3) ==
  SHA256:HkkktzVstpsuXhuWUej/qTQ24CL+6CB8YkUMhnjZ+ow
     Label:    Vom Container 05.09.2026 10:20 — eddsa-key-20260905
     Angelegt: 2026-09-05 10:20:20   Laeuft ab: -

  SHA256:...
     ...

Loeschen: webunit-ssh remove-key <fingerprint>

Key loeschen (Fingerprint aus list-keys kopieren):

$ webunit-ssh remove-key SHA256:HkkktzVstpsuXhuWUej/qTQ24CL+6CB8YkUMhnjZ+ow
Loesche Key SHA256:... — dies ist SOFORT wirksam.
Fortfahren? [j/N] j
Key geloescht — SHA256:... (Vom Container 05.09.2026 10:20 — eddsa-key-20260905)
In wenigen Sekunden verweigert sshpiper Logins mit diesem Key.

Nach Loeschung: ein spaeteres webunit-ssh add-key mit demselben Public-Key stellt den Key wieder her (gleicher DB-Eintrag, restored) statt neu anzulegen. Doppel-Adds sind idempotent (already_known).

Passwort-Login-Toggle: webunit-ssh password-auth on|off oder im Admin-Panel.

webunit-password — Passwoerter selbst rotieren

webunit-password ssh              SSH-/SFTP-Passwort neu setzen
webunit-password db <label>       Datenbank-Passwort neu setzen
webunit-password help

Detaillierte Anleitung inkl. Sicherheits-Hinweisen: siehe Passwoerter selbst aendern.

webunit-opcache-reset — OPcache leeren (Deployer-freundlich)

Leert den PHP-OPcache im Apache-Prozess ohne Restart, ohne Downtime. Zusaetzlich werden der realpath-Cache und (falls aktiv) APCu geleert — zusammen sind das exakt die Caches, die nach einem Symlink-Umbiegen (current -> releases/N) noch auf die alte Release zeigen wuerden.

webunit-opcache-reset

Beispiel-Ausgabe:

OPcache geleert.
Vorher: 4231 Scripts im Cache, 84318720 Bytes belegt.

Warum es dieses CLI gibt: Die uebliche Empfehlung cachetool.phar opcache:reset --fcgi=/run/php-fpm.sock funktioniert bei uns NICHT — unser Image faehrt Apache mit mod_php (kein PHP-FPM, kein .sock). Fuer denselben Zweck gibt es genau dieses CLI.

Wenn du in einem Deployer-Task ohne SSH-Sitzung arbeiten willst, bleibt auch Cachetool im --web-Adapter moeglich:

php cachetool.phar opcache:reset \
    --web=curl --web-path=./public --web-url=https://deine.domain

Cachetool legt dazu kurz eine Adapter-PHP-Datei ins Public, ruft sie per HTTP an und loescht sie wieder. Das erwischt denselben mod_php-OPcache. Vorteil webunit-opcache-reset: kein Public-Endpoint, kein Aufraeumen, zusaetzlich realpath+apcu.

Gibt eine URL aus, die dich einmalig fuer 12 Stunden zu phpMyAdmin auf deiner Node lotst. Die URL ist ein signierter Tageslink — ohne den ist das PMA-Login-Formular von aussen nicht mal erreichbar.

Beispiel:

PMA-Zugang (12h gueltig ab jetzt, Tages-Grenze 04:00 Berlin):

  https://pma.<node>.webunit.cloud/pma-open?daykey=...&cid=...&node=...

Link im Browser oeffnen — Admin validiert und leitet weiter zu PMA.

Wichtig: die URL ist nur einen "Arbeitstag" gueltig. Tages-Grenze ist 04:00 Berlin — falls du morgens frueh anfaengst, laeuft dein Cookie ab 04:00 ab und du brauchst einen neuen Link. Nachts arbeitende Kunden haben von 04:00 an denselben Link 24 Stunden minus 12 Cookie-Timeout.

Wer die URL kennt, kommt zu PMA — nicht in oeffentlichen Chats posten.

Was du KEIN CLI dafuer brauchst

  • Passwort/Zugangsdaten anzeigen: Admin-Panel oder Access-Link
  • Passwort rotieren: Admin-Panel (Subscription → SSH → "Passwort neu wuerfeln" oder Datenbanken → "Rotieren")
  • DB anlegen/aendern: Admin-Panel
  • PHP-Werte tunen: Admin-Panel (Custom-INI-Textblock pro Hostname)
  • MariaDB-Werte tunen: Admin-Panel (Custom-Config-Textblock pro DB)

Bash-Zusatzausstattung im Container

Beim ersten Login findest du in deinem Home:

  • ~/.bashrc mit Aliases (ll, www fuer cd /var/www)
  • ~/www → Symlink auf /var/www (Docroot)
  • ~/logs → Symlink auf /var/log/apache2 — pro vhost gibt es hier <domain>-access.log und <domain>-error.log. Persistent ueber Container-Recreate hinweg und im taeglichen Backup enthalten.
  • ~/.webunit/ — deine eigenen Supervisor-Configs (supervisor.d/) und Programm-Logs (logs/). Auch persistent + im Backup.
  • ~/.ssh/authorized_keys — wird von unserer Infrastruktur IGNORIERT. Die Datei enthaelt einen Hinweis-Text und ist read-only. sshd liest ausschliesslich /etc/webunit/sshpiper_pub.key (zentral verwaltet). Zum Key-Hinzufuegen: webunit-ssh add-key '<public-key>' oder Admin-Panel.
  • ~/.ssh/id_rsa, ~/.ssh/config, ~/.ssh/known_hosts — voll unter deiner Kontrolle, fuer OUTGOING SSH (Deploy, git clone via SSH, rsync). Nur authorized_keys ist speziell.

Zusaetzlich vorinstalliert: composer, wp (WP-CLI), node, npm, git, curl, mariadb, msmtp (Mail via /usr/sbin/sendmail), nano, zstd.

Fehlendes Tool? Kurz per Support melden — wir installieren pauschal ins Image, alle Kunden bekommen es.

Back to top