Files
mhoennig ac6df1bb6b feat(tools): remote <ziel> <aktion> als Vordertuer zum Server (D77-Nachtrag)
Deployen, Log ansehen, Dienst schalten und fragen was laeuft waren vier
verschiedene Beschwoerungen, drei davon von Hand als ssh + systemctl. Jetzt:

  remote backend deploy|upload|setup|install-jdk|reset-password
  remote backend start|stop|restart|status|enable|disable
  remote backend log|info|documents|backup
  remote frontend deploy|preview|info
  remote ssh

Die Skripte unter scripts/ bleiben die Implementierung und einzeln aufrufbar;
tools/remote bringt nur mit, wofuer es bisher nichts gab. Wo ein Schalter
noetig war, kam er ins Skript statt ins Werkzeug: --unit-only in
deploy-backend.sh (sonst kennte eine zweite Stelle die Unit-Platzhalter) und
--dry-run in deploy-prod.sh, das die Befoerderung ausdruecklich mit abschaltet.

Neu ist die Sicherung: H2 haelt die Datei offen, also anhalten, holen, wieder
starten (gemessen ~8 s Auszeit) - und das Archiv lesen, bevor der Befehl es
behaelt. Gegenprobe von Hand: lokal ausgepackt, Backend mit --werkbaum.data-dir
dagegen gestartet, es liefert genau die Dokumente des Servers.

.envrc legt tools/ auf den PATH (direnv), 217 Plan-Knoten, 0 Warnungen.
2026-08-26 19:59:24 +02:00

17 lines
641 B
Bash

# direnv-Konfiguration.
#
# Legt `tools/` auf den PATH, solange man in diesem Verzeichnisbaum steht — dann
# genügt `remote backend deploy` statt `tools/remote backend deploy`. Wirkt nur
# hier und darunter, die globale Shell-Konfiguration bleibt unangetastet.
#
# Einmal pro Arbeitskopie freizugeben (direnv lädt eine Datei erst, wenn man ihr
# traut) — und erneut, sobald sich diese Datei ändert:
#
# direnv allow
#
# Bewusst `tools` und nicht `scripts`: Auf dem PATH hieße der Befehl sonst
# `deploy-prod.sh`. Die Skripte bleiben, wo sie sind, und einzeln aufrufbar;
# `tools/remote` ist die Vordertür davor.
PATH_add tools