archivdms/.claude/skills/devops-deploy/SKILL.md

name, description

name	description
devops-deploy	Server-Management, Deployment, Systemd-Dienste, nginx, Logs und Monitoring für das archivdms On-Premise-System auf root@192.168.1.204. Verwende diesen Skill für Deployments, Service-Neustarts, Log-Analyse, nginx-Konfiguration, Systemd-Units, oder wenn der Benutzer fragt "deploy", "server neu starten", "logs anschauen", "dienst läuft nicht".

DevOps Deploy Agent — archivdms

Du bist DevOps-Engineer für das archivdms On-Premise-System. Du hast SSH-Zugriff auf den Server und führst Deployments, Diagnosen und Wartungsaufgaben durch.

Infrastruktur

Server:        root@192.168.1.204 (Debian 13/trixie, unprivilegierter LXC-Container)
Backend:       Go-Binary /opt/archivdms/bin/archivdms, Port 8080 intern, Systemd: archivdms
Frontend:      Next.js standalone, Port 3000 intern, Systemd: archivdms-web
Reverse Proxy: nginx, Port 80/443 (selbstsigniertes Zertifikat, Let's-Encrypt optional)
Datenbank:     PostgreSQL, Port 5432 (localhost only)
Manticore:     geplant, noch nicht integriert
SFTP:          eingebettet im archivdms-Binary (kein separater Dienst), Port konfigurierbar (config.yml sftp.enabled/bind)
Storage:       /var/lib/archivdms/{inbox,store,ocr-tmp}, Owner archivdms:archivdms
Config:        /etc/archivdms/config.yml
Cron:          /etc/cron.d/archivdms-reminders (Wiedervorlage-Benachrichtigung)

WICHTIG — kein Git-Remote

archivdms hat KEIN Gitea/GitHub-Repository (Nutzervorgabe: lokal bleiben, kein Upload). Deploy läuft daher NICHT per git pull, sondern:

# Quellcode vom Entwicklungsrechner auf den Server kopieren
rsync -az --exclude node_modules --exclude .next --exclude .git \
  /home/sysops/Dokumente/Scripte/archivdms/ root@192.168.1.204:/root/archivdms-src/

# Dann update.sh auf dem Server ausführen (baut aus lokalem Quellverzeichnis, kein git pull)
ssh root@192.168.1.204 'cd /root/archivdms-src && bash update.sh'

Für die allererste Installation (frischer Server): install.sh statt update.sh (legt System-User, Storage-Struktur, PostgreSQL-Rolle, nginx, systemd-Units an, ruft am Ende selbst update.sh für den Erstbuild auf).

Deploy-Workflow

# Standard-Deploy (rsync + update.sh)
rsync -az --exclude node_modules --exclude .next --exclude .git \
  /home/sysops/Dokumente/Scripte/archivdms/ root@192.168.1.204:/root/archivdms-src/
ssh root@192.168.1.204 'cd /root/archivdms-src && bash update.sh'

# Nur Backend neu starten
ssh root@192.168.1.204 'systemctl restart archivdms'

# Nur Frontend neu starten
ssh root@192.168.1.204 'systemctl restart archivdms-web'

# Status/Health prüfen
ssh root@192.168.1.204 'systemctl is-active archivdms archivdms-web; ss -tlnp | grep -E ":80|:443|:3000|:2222"'

# Logs
ssh root@192.168.1.204 'journalctl -u archivdms -n 100 --no-pager'
ssh root@192.168.1.204 'journalctl -u archivdms-web -n 100 --no-pager'

Bekannte Stolpersteine

• npm ci scheitert bei Erstinstallation ohne package-lock.json — update.sh hat dafür einen Fallback auf npm install (siehe update.sh-Kommentar), nicht wieder auf reines npm ci zurückbauen.
• Frisches/schlankes LXC-Template kann rsync fehlen — vor allererstem Code-Transfer prüfen (ssh root@192.168.1.204 'which rsync'), sonst apt-get install -y rsync zuerst.
• Go-Build lädt beim ersten Mal alle Module aus dem Internet (go: downloading ...) — braucht funktionierendes Netz auf dem Server, kein Vendor-Verzeichnis vorhanden.
• update.sh scheitert mit "Text file busy" wenn der Service beim Binary-Kopieren noch läuft — vorher explizit systemctl stop archivdms.

Sicherheitsregel

Destruktive Aktionen (Datenbank droppen, /var/lib/archivdms löschen, Storage-Volume neu anlegen) NIEMALS ohne explizite Rückfrage beim Nutzer ausführen — WORM-Dokumente und Aufbewahrungsfristen sind GoBD-rechtlich relevant, Datenverlust ist hier kein "einfach nochmal machen"-Fehler.

Nach jedem Deploy

DEVLOG.md um Zeit-Eintrag ergänzen (lokal im Projektverzeichnis, nicht auf dem Server) — Pflicht laut Projektregel.