Deployment Script: karl→walter furt-lua Updates #76

New issue

Closed

opened 2025-06-23 09:24:43 +02:00 by Michael · 0 comments

Michael commented

2025-06-23 09:24:43 +02:00

(Migrated from gitea.dragons-at-work.de)

Problem

Aktuell müssen furt-lua Dateien manuell von karl (Development) nach walter (OpenBSD Production) übertragen werden. Ein automatisiertes Deployment-Script würde den Development-Workflow erheblich vereinfachen.

Current Workflow (Manual)

Development auf karl: /home/michael/Develop/DAW/furt/furt-lua/
Manual file copy/edit auf walter: /usr/local/furt/furt-lua/
Manual permission fix für _furt user
Manual service restart

Required Functionality

Deploy-Script Anforderungen:

Source: karl furt/furt-lua/ directory
Target: walter /usr/local/furt/furt-lua/ für _furt user
SSH-based Transfer (rsync oder scp)
Automatic Permission-Fix (chown _furt:_furt)
Service-Restart (stop→deploy→start)
Backup vor Deployment (rollback capability)

Files zu transferieren:

furt-lua/
├── src/
│   ├── main.lua
│   └── smtp.lua
├── config/
│   └── server.lua
├── scripts/
│   └── start.sh
└── tests/
    └── test_http.lua

Ausgeschlossene Files:

.env (karl-spezifisch)
Local development configs
Backup files (.backup, .orig)

Implementation Plan

1. Deploy-Script erstellen:

# scripts/deploy_walter.sh
#!/bin/bash

# Pre-deployment checks
- walter SSH-connectivity
- _furt service status
- Backup current version

# Deployment
- rsync karl→walter 
- chown _furt:_furt
- Service restart
- Health check

# Post-deployment validation
- HTTP health check
- SMTP functionality test

2. Safety Features:

Dry-run mode (--dry-run flag)
Automatic backup vor deployment
Rollback-functionality bei failures
Health-check validation nach deployment

3. SSH Configuration:

SSH-Key-based authentication (no passwords)
Dedicated deploy key für walter
Limited sudo permissions für _furt user management

Acceptance Criteria

scripts/deploy_walter.sh funktioniert
Dry-run mode zeigt planned changes
Automatic backup vor deployment
Files korrekt nach /usr/local/furt/furt-lua/ deployed
Permissions automatisch auf _furt:_furt gesetzt
Service restart funktioniert
Health-check validation nach deployment
Rollback-functionality bei deployment failures
Documentation in README.md

Priority Rationale

High Priority - Kritisch für Development-Workflow. Manuelle Deployments sind fehleranfällig und zeitaufwändig.

Technical Context

Network: karl und walter im gleichen lokalen Netz
karl SSH-Host: Lokale IP, SSH-Key-Auth
walter Target: /usr/local/furt/furt-lua/ (OpenBSD Staging)
Service User: _furt (OpenBSD)
Service Control: ./scripts/start.sh stop/start
Config: walter verwendet /usr/local/etc/furt/environment

Strategic Importance

walter = OpenBSD Staging-Environment für kommenden Production-Server im Rechenzentrum. Deployment-Script wird später auch für Production-Deployment verwendet.

Alles was auf walter funktioniert → funktioniert auf Production OpenBSD-Server.

Security Considerations

SSH-Key nur für deployment-specific actions
Limited sudo rights (nur für _furt user management)
Backup retention policy (keep last 3 deployments)
No credentials in deployment scripts

## Problem Aktuell müssen furt-lua Dateien manuell von karl (Development) nach walter (OpenBSD Production) übertragen werden. Ein automatisiertes Deployment-Script würde den Development-Workflow erheblich vereinfachen. ## Current Workflow (Manual) 1. Development auf karl: `/home/michael/Develop/DAW/furt/furt-lua/` 2. Manual file copy/edit auf walter: `/usr/local/furt/furt-lua/` 3. Manual permission fix für _furt user 4. Manual service restart ## Required Functionality ### **Deploy-Script Anforderungen:** - **Source:** karl `furt/furt-lua/` directory - **Target:** walter `/usr/local/furt/furt-lua/` für _furt user - **SSH-based Transfer** (rsync oder scp) - **Automatic Permission-Fix** (chown _furt:_furt) - **Service-Restart** (stop→deploy→start) - **Backup vor Deployment** (rollback capability) ### **Files zu transferieren:** ``` furt-lua/ ├── src/ │ ├── main.lua │ └── smtp.lua ├── config/ │ └── server.lua ├── scripts/ │ └── start.sh └── tests/ └── test_http.lua ``` ### **Ausgeschlossene Files:** - `.env` (karl-spezifisch) - Local development configs - Backup files (`.backup`, `.orig`) ## Implementation Plan ### **1. Deploy-Script erstellen:** ```bash # scripts/deploy_walter.sh #!/bin/bash # Pre-deployment checks - walter SSH-connectivity - _furt service status - Backup current version # Deployment - rsync karl→walter - chown _furt:_furt - Service restart - Health check # Post-deployment validation - HTTP health check - SMTP functionality test ``` ### **2. Safety Features:** - **Dry-run mode** (--dry-run flag) - **Automatic backup** vor deployment - **Rollback-functionality** bei failures - **Health-check validation** nach deployment ### **3. SSH Configuration:** - SSH-Key-based authentication (no passwords) - Dedicated deploy key für walter - Limited sudo permissions für _furt user management ## Acceptance Criteria - [ ] `scripts/deploy_walter.sh` funktioniert - [ ] Dry-run mode zeigt planned changes - [ ] Automatic backup vor deployment - [ ] Files korrekt nach /usr/local/furt/furt-lua/ deployed - [ ] Permissions automatisch auf _furt:_furt gesetzt - [ ] Service restart funktioniert - [ ] Health-check validation nach deployment - [ ] Rollback-functionality bei deployment failures - [ ] Documentation in README.md ## Priority Rationale **High Priority** - Kritisch für Development-Workflow. Manuelle Deployments sind fehleranfällig und zeitaufwändig. ## Technical Context - **Network:** karl und walter im gleichen lokalen Netz - **karl SSH-Host:** Lokale IP, SSH-Key-Auth - **walter Target:** /usr/local/furt/furt-lua/ (OpenBSD Staging) - **Service User:** _furt (OpenBSD) - **Service Control:** ./scripts/start.sh stop/start - **Config:** walter verwendet /usr/local/etc/furt/environment ## Strategic Importance **walter = OpenBSD Staging-Environment** für kommenden Production-Server im Rechenzentrum. Deployment-Script wird später auch für Production-Deployment verwendet. Alles was auf walter funktioniert → funktioniert auf Production OpenBSD-Server. ## Security Considerations - SSH-Key nur für deployment-specific actions - Limited sudo rights (nur für _furt user management) - Backup retention policy (keep last 3 deployments) - No credentials in deployment scripts