DAW/furt

Fork 0

Config-Strategy Research: Distribution Best Practices für Open Source (Research Phase) #71

New issue

Closed

opened 2025-06-22 18:44:49 +02:00 by Michael · 6 comments

Michael commented

2025-06-22 18:44:49 +02:00

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

🔬 STATUS: RESEARCH PHASE - DISTRIBUTION BEST PRACTICES

Current solution works - aber für Open Source brauchen wir Distribution-Standards-Research!

Research-Scope (Open Source Preparation)

Distribution-spezifische Config-Erwartungen:

OpenBSD: /etc/furt/ vs /usr/local/etc/furt/ - Was erwarten Admins?
Ubuntu/Debian: /etc/furt/ vs /etc/default/furt vs /usr/local/etc/furt/
Arch Linux: /etc/furt/ vs /etc/conf.d/furt
FreeBSD: /usr/local/etc/furt/ (BSD-Standard)
Alpine: /etc/furt/ vs /etc/conf.d/furt
CentOS/RHEL: /etc/sysconfig/furt vs /etc/furt/

Config-Segregation-Strategy:

Normal Config vs Secrets-Separation:

# Public Config (world-readable)
/etc/furt/furt.conf          # Basic settings, ports, features
/usr/local/etc/furt/config   # Alternative location

# Secrets (restricted access)  
/etc/furt/secrets            # SMTP passwords, API keys
/usr/local/etc/furt/secrets  # Alternative location
/var/lib/furt/credentials    # Alternative approach

# User Overrides
~/.config/furt/config        # User-specific settings
~/.furt                      # Alternative location

Open Source Distribution-Standards:

Research needed von etablierten Open Source-Projekten:

nginx: /etc/nginx/nginx.conf + /etc/nginx/conf.d/
apache: /etc/apache2/ (Debian) vs /etc/httpd/ (RHEL)
postgresql: /etc/postgresql/ vs /usr/local/pgsql/
docker: /etc/docker/daemon.json
ssh: /etc/ssh/sshd_config vs ~/.ssh/config

Current Working Solution (Interim)

Development: PROJECT_ROOT/.env
Production: /usr/local/etc/furt/environment (walter)

Problem: Nicht Distribution-agnostic, nicht secrets-segregated

Research Questions (To Answer)

Distribution Standards: Was ist Best Practice pro Distribution?
Secrets Management: Wie trennen andere Open Source-Projekte public/private config?
Permission Patterns: Welche File-Permissions sind Standard?
Config-Validation: Welche Validation-Patterns nutzen andere?
Multi-Instance: Wie supporten andere Multiple-Instances?
Packaging Integration: Wie integriert sich das mit pkg, apt, yum, etc.?

Deliverables (Research Phase)

Distribution-Survey: Config-Patterns von 10+ Distributionen
Open Source-Analysis: Config-Strategies von 10+ ähnlichen Projekten
Security-Best-Practices: Secrets-Management-Patterns
Standard-Recommendation: Furt-Config-Standard für Open Source
Migration-Plan: Current → Standard transition
Documentation: Admin-Guide für alle unterstützten Distributionen

Priority Justification

HIGH für Open Source: Config-Strategy affects adoption rate significantly

Timeline

Research Phase: 2-4 Wochen (parallel zu anderen Development)
Standard-Design: 1 Woche
Implementation: 2-3 Wochen
Testing: 1 Woche pro Distribution
Documentation: 1 Woche

Status: IMPORTANT RESEARCH FOR OPEN SOURCE SUCCESS

## 🔬 STATUS: RESEARCH PHASE - DISTRIBUTION BEST PRACTICES **Current solution works - aber für Open Source brauchen wir Distribution-Standards-Research!** ## Research-Scope (Open Source Preparation) ### **Distribution-spezifische Config-Erwartungen:** - **OpenBSD**: /etc/furt/ vs /usr/local/etc/furt/ - Was erwarten Admins? - **Ubuntu/Debian**: /etc/furt/ vs /etc/default/furt vs /usr/local/etc/furt/ - **Arch Linux**: /etc/furt/ vs /etc/conf.d/furt - **FreeBSD**: /usr/local/etc/furt/ (BSD-Standard) - **Alpine**: /etc/furt/ vs /etc/conf.d/furt - **CentOS/RHEL**: /etc/sysconfig/furt vs /etc/furt/ ### **Config-Segregation-Strategy:** **Normal Config vs Secrets-Separation:** ``` # Public Config (world-readable) /etc/furt/furt.conf # Basic settings, ports, features /usr/local/etc/furt/config # Alternative location # Secrets (restricted access) /etc/furt/secrets # SMTP passwords, API keys /usr/local/etc/furt/secrets # Alternative location /var/lib/furt/credentials # Alternative approach # User Overrides ~/.config/furt/config # User-specific settings ~/.furt # Alternative location ``` ### **Open Source Distribution-Standards:** Research needed von etablierten Open Source-Projekten: - **nginx**: /etc/nginx/nginx.conf + /etc/nginx/conf.d/ - **apache**: /etc/apache2/ (Debian) vs /etc/httpd/ (RHEL) - **postgresql**: /etc/postgresql/ vs /usr/local/pgsql/ - **docker**: /etc/docker/daemon.json - **ssh**: /etc/ssh/sshd_config vs ~/.ssh/config ## Current Working Solution (Interim) ``` Development: PROJECT_ROOT/.env Production: /usr/local/etc/furt/environment (walter) ``` **Problem**: Nicht Distribution-agnostic, nicht secrets-segregated ## Research Questions (To Answer) 1. **Distribution Standards**: Was ist Best Practice pro Distribution? 2. **Secrets Management**: Wie trennen andere Open Source-Projekte public/private config? 3. **Permission Patterns**: Welche File-Permissions sind Standard? 4. **Config-Validation**: Welche Validation-Patterns nutzen andere? 5. **Multi-Instance**: Wie supporten andere Multiple-Instances? 6. **Packaging Integration**: Wie integriert sich das mit pkg, apt, yum, etc.? ## Deliverables (Research Phase) - [ ] **Distribution-Survey**: Config-Patterns von 10+ Distributionen - [ ] **Open Source-Analysis**: Config-Strategies von 10+ ähnlichen Projekten - [ ] **Security-Best-Practices**: Secrets-Management-Patterns - [ ] **Standard-Recommendation**: Furt-Config-Standard für Open Source - [ ] **Migration-Plan**: Current → Standard transition - [ ] **Documentation**: Admin-Guide für alle unterstützten Distributionen ## Priority Justification **HIGH für Open Source**: Config-Strategy affects adoption rate significantly ## Timeline - **Research Phase**: 2-4 Wochen (parallel zu anderen Development) - **Standard-Design**: 1 Woche - **Implementation**: 2-3 Wochen - **Testing**: 1 Woche pro Distribution - **Documentation**: 1 Woche **Status: IMPORTANT RESEARCH FOR OPEN SOURCE SUCCESS**

Michael commented

2025-06-22 20:49:40 +02:00

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

Config-System Root-Cause-Analysis (22.06.2025)

Problem identifiziert: PATH vs Absolute-Pfade Konflikt

Ausgangssituation: Issue #70 (karl start.sh regression) zeigt systemweites Problem.

Root Cause

OpenBSD-Kompatibilität: command -v funktioniert nicht → Script-Änderung zu [ -x ]
Problem: [ -x "lua51" ] funktioniert nur mit absoluten Pfaden, nicht PATH-Commands
Workaround: karl läuft wieder mit LUA_COMMAND=/usr/bin/lua51 in .env
Scope: Betrifft alle DAW-Tools, nicht nur furt

Systemweite Implikationen

Betroffene Projekte:

✅ furt-lua - aktuell gefixt via absolute Pfade in Config
⚠️ gitea-testing - Scripts verwenden vermutlich ähnliche PATH-Checks
⚠️ future furt-c - wird gleiches Problem haben
⚠️ andere Tools - jq, curl, git, make - alle PATH-dependent

Lösungsansätze für DAW-weite Standardisierung

Option 1: OpenBSD-kompatible PATH-Detection

# POSIX-konform, funktioniert auf OpenBSD + Linux
check_command() {
    local cmd=$1
    if [ -x "$cmd" ]; then
        return 0  # Absolute path
    elif type "$cmd" >/dev/null 2>&1; then
        return 0  # Found in PATH
    else
        return 1  # Not found
    fi
}

Option 2: Config-Mandatory-Strategy

Prinzip: Jedes System braucht explizite absolute Pfade
Vorteile: Volle Kontrolle, keine Überraschungen
Nachteile: Mehr Setup-Aufwand pro System

Option 3: Plattform-Detection + Fallbacks

if [ "$(uname)" = "OpenBSD" ]; then
    # OpenBSD-spezifische PATH-Detection
else
    # Linux-Standard mit command -v
fi

Empfehlung für Config-Strategy

Multi-Layer-Config mit PATH-Hybrid:

System-Config: /usr/local/etc/furt/environment (absolute Pfade)
User-Config: $HOME/.config/furt/environment (absolute Pfade)
Project-Config: $REPO/.env (absolute oder relative Pfade)
Default-Fallback: PATH-Detection mit OpenBSD-kompatiblen Checks

Nächste Schritte

Standard-Funktionen für PATH-Detection entwickeln (shared/config/)
Config-Hierarchie definieren (system → user → project → defaults)
Migration-Guide für bestehende Projekte
Testing auf allen Zielplattformen (OpenBSD, Linux, unterschiedliche Shells)

Related: Issue #70 (karl regression - gefixt), walter SSL-Problem (separates Issue)

## Config-System Root-Cause-Analysis (22.06.2025) ### Problem identifiziert: PATH vs Absolute-Pfade Konflikt **Ausgangssituation:** Issue #70 (karl start.sh regression) zeigt systemweites Problem. ### Root Cause - **OpenBSD-Kompatibilität:** `command -v` funktioniert nicht → Script-Änderung zu `[ -x ]` - **Problem:** `[ -x "lua51" ]` funktioniert nur mit absoluten Pfaden, nicht PATH-Commands - **Workaround:** karl läuft wieder mit `LUA_COMMAND=/usr/bin/lua51` in .env - **Scope:** Betrifft alle DAW-Tools, nicht nur furt ### Systemweite Implikationen **Betroffene Projekte:** - ✅ **furt-lua** - aktuell gefixt via absolute Pfade in Config - ⚠️ **gitea-testing** - Scripts verwenden vermutlich ähnliche PATH-Checks - ⚠️ **future furt-c** - wird gleiches Problem haben - ⚠️ **andere Tools** - jq, curl, git, make - alle PATH-dependent ### Lösungsansätze für DAW-weite Standardisierung #### Option 1: OpenBSD-kompatible PATH-Detection ```bash # POSIX-konform, funktioniert auf OpenBSD + Linux check_command() { local cmd=$1 if [ -x "$cmd" ]; then return 0 # Absolute path elif type "$cmd" >/dev/null 2>&1; then return 0 # Found in PATH else return 1 # Not found fi } ``` #### Option 2: Config-Mandatory-Strategy - **Prinzip:** Jedes System braucht explizite absolute Pfade - **Vorteile:** Volle Kontrolle, keine Überraschungen - **Nachteile:** Mehr Setup-Aufwand pro System #### Option 3: Plattform-Detection + Fallbacks ```bash if [ "$(uname)" = "OpenBSD" ]; then # OpenBSD-spezifische PATH-Detection else # Linux-Standard mit command -v fi ``` ### Empfehlung für Config-Strategy **Multi-Layer-Config mit PATH-Hybrid:** 1. **System-Config:** `/usr/local/etc/furt/environment` (absolute Pfade) 2. **User-Config:** `$HOME/.config/furt/environment` (absolute Pfade) 3. **Project-Config:** `$REPO/.env` (absolute oder relative Pfade) 4. **Default-Fallback:** PATH-Detection mit OpenBSD-kompatiblen Checks ### Nächste Schritte 1. **Standard-Funktionen** für PATH-Detection entwickeln (shared/config/) 2. **Config-Hierarchie** definieren (system → user → project → defaults) 3. **Migration-Guide** für bestehende Projekte 4. **Testing** auf allen Zielplattformen (OpenBSD, Linux, unterschiedliche Shells) **Related:** Issue #70 (karl regression - gefixt), walter SSL-Problem (separates Issue)

michael added this to the v0.1.2 - Gateway Basics milestone 2025-08-14 05:20:48 +02:00

michael referenced this issue

2025-08-14 06:27:03 +02:00

Repository Redesign: Clean structure for v0.1.0 Open Source release #86

michael referenced this issue

2025-08-14 06:27:05 +02:00

Wiki-based Documentation: Replace monster scripts with user-friendly guides #87

michael referenced this issue

2025-08-14 06:27:07 +02:00

Package Distribution Strategy: Forgejo Packages + GitHub Mirror für Open Source #88

michael referenced this issue

2025-08-14 07:21:48 +02:00

Universal Config Detection für start.sh - Multi-Distribution Support #68

michael referenced this issue

2025-08-14 09:41:02 +02:00

Repository Redesign: Clean structure for v0.1.0 Open Source release #86

michael commented

2025-08-14 15:49:04 +02:00

Owner

OpenBSD Config-Standards Research - Zwischenergebnis (2025-08-14)

Analysierte OpenBSD-Services:

Base System Services:

httpd: /etc/httpd.conf (644 root:wheel)
relayd: /etc/relayd.conf (644 root:wheel)
pf: /etc/pf.conf (600 root:wheel - security-sensitive)
ntpd: /etc/ntpd.conf (644 root:wheel)

Installed Packages:

nginx: /usr/local/etc/nginx/nginx.conf + conf.d/
postgresql: /usr/local/share/postgresql/ (samples) + /var/postgresql/data/ (active)
redis: /usr/local/etc/redis.conf

OpenBSD Config-Patterns (Discovered):

1. Location-Hierarchy:

Base system: /etc/service.conf
Packages: /usr/local/etc/package/ oder /usr/local/etc/package.conf
Runtime data: /var/service/

2. Naming-Conventions:

Single file: service.conf (httpd, relayd, pf)
Directory: /usr/local/etc/service/ für komplexere tools
Samples: /usr/local/share/service/ für templates

3. Permission-Patterns:

644 root🛞 Standard config files
600 root🛞 Security-sensitive (pf, secrets)
Service-user ownership: Nur für runtime data in /var/

4. Service-Separation-Principle:

Jeder Service = eigener /usr/local/etc/service/ Namespace
Keine Config-Vermischung zwischen Services

Furt OpenBSD-Recommendation:

Option A: Package-Style (Empfohlen)

/usr/local/etc/furt/
├── furt.conf              # Gateway-Config (644 root:wheel)
├── discovery.conf         # Service-Discovery-Rules  
└── secrets/               # Separate secrets (600 root:wheel)
    └── api-keys.conf

/usr/local/etc/sagjan/     # Separate sagjan namespace!
├── sagjan.conf           
└── secrets/
    └── database.env

Option B: Simple Single-File

/usr/local/etc/furt.conf   # All-in-one (redis-style)

Recommendation: Option A - skaliert besser für Multi-Service + folgt nginx-Pattern

Discovery-Integration-Pattern:

# /usr/local/etc/furt/discovery.conf  
[sagjan]
auto_discover=true
expected_port=8082
health_check=/health

# /usr/local/etc/sagjan/sagjan.conf
[furt_integration]
enabled=true
gateway_url=http://localhost:8080
register_endpoint=/register

Key Insights:

Service-Separation beibehalten - furt = Discovery-Coordinator, nicht Config-Owner
OpenBSD bevorzugt /usr/local/etc/ für packages vs /etc/ für base system
Permission-Standards sind konsistent (644 normal, 600 secrets)

Next Research Steps:

Ubuntu/Debian Standards vergleichen
Distribution-Differences identifizieren
Multi-Service-Config-Templates entwickeln
Migration-Path von aktueller /etc/furt/environment

Status: OpenBSD-Standards analysiert ✅ - Ubuntu/Debian Research next

## OpenBSD Config-Standards Research - Zwischenergebnis (2025-08-14) ### Analysierte OpenBSD-Services: **Base System Services:** - **httpd**: /etc/httpd.conf (644 root:wheel) - **relayd**: /etc/relayd.conf (644 root:wheel) - **pf**: /etc/pf.conf (600 root:wheel - security-sensitive) - **ntpd**: /etc/ntpd.conf (644 root:wheel) **Installed Packages:** - **nginx**: /usr/local/etc/nginx/nginx.conf + conf.d/ - **postgresql**: /usr/local/share/postgresql/ (samples) + /var/postgresql/data/ (active) - **redis**: /usr/local/etc/redis.conf ### OpenBSD Config-Patterns (Discovered): **1. Location-Hierarchy:** - Base system: `/etc/service.conf` - Packages: `/usr/local/etc/package/` oder `/usr/local/etc/package.conf` - Runtime data: `/var/service/` **2. Naming-Conventions:** - Single file: `service.conf` (httpd, relayd, pf) - Directory: `/usr/local/etc/service/` für komplexere tools - Samples: `/usr/local/share/service/` für templates **3. Permission-Patterns:** - 644 root:wheel: Standard config files - 600 root:wheel: Security-sensitive (pf, secrets) - Service-user ownership: Nur für runtime data in `/var/` **4. Service-Separation-Principle:** - Jeder Service = eigener `/usr/local/etc/service/` Namespace - Keine Config-Vermischung zwischen Services ### Furt OpenBSD-Recommendation: **Option A: Package-Style (Empfohlen)** ``` /usr/local/etc/furt/ ├── furt.conf # Gateway-Config (644 root:wheel) ├── discovery.conf # Service-Discovery-Rules └── secrets/ # Separate secrets (600 root:wheel) └── api-keys.conf /usr/local/etc/sagjan/ # Separate sagjan namespace! ├── sagjan.conf └── secrets/ └── database.env ``` **Option B: Simple Single-File** ``` /usr/local/etc/furt.conf # All-in-one (redis-style) ``` **Recommendation: Option A** - skaliert besser für Multi-Service + folgt nginx-Pattern ### Discovery-Integration-Pattern: ``` # /usr/local/etc/furt/discovery.conf [sagjan] auto_discover=true expected_port=8082 health_check=/health # /usr/local/etc/sagjan/sagjan.conf [furt_integration] enabled=true gateway_url=http://localhost:8080 register_endpoint=/register ``` ### Key Insights: - **Service-Separation beibehalten** - furt = Discovery-Coordinator, nicht Config-Owner - **OpenBSD bevorzugt** `/usr/local/etc/` für packages vs `/etc/` für base system - **Permission-Standards** sind konsistent (644 normal, 600 secrets) ### Next Research Steps: 1. Ubuntu/Debian Standards vergleichen 2. Distribution-Differences identifizieren 3. Multi-Service-Config-Templates entwickeln 4. Migration-Path von aktueller /etc/furt/environment **Status: OpenBSD-Standards analysiert ✅ - Ubuntu/Debian Research next**

michael commented

2025-08-14 15:55:17 +02:00

Owner

Debian Config-Standards Research - Zwischenergebnis (2025-08-14)

Analysierte Debian-Services:

System Services:

Apache2: /etc/apache2/apache2.conf + sites-available/enabled-System
nginx: /etc/nginx/nginx.conf + sites-available/enabled-System
OpenSSH: /etc/ssh/sshd_config + /etc/ssh/ssh_config
postfix: /etc/postfix/main.cf + /etc/postfix/master.cf

Database Services:

PostgreSQL: /etc/postgresql/15/main/postgresql.conf (version-isolated)

systemd Integration:

Services: /etc/systemd/system/service.service
Overrides: /etc/systemd/system/service.service.d/

Debian Config-Patterns (Discovered):

1. Location-Hierarchy:

Alle Services: /etc/package/ (nie /usr/local/etc/ wie OpenBSD)
Consistent location unabhängig von package vs base system

2. Available/Enabled-Pattern (Debian-spezifisch):

/etc/apache2/sites-available/mysite    # Config definiert
/etc/apache2/sites-enabled/mysite      # Symlink → aktiviert

3. Version-Isolation:

/etc/postgresql/15/main/    # Version in path
/etc/postgresql/14/main/    # Parallel installations möglich

4. Permission-Patterns:

644 root:root: Standard config files
600 root:root: Security-sensitive configs
service:service: Service-specific ownership wo nötig

Debian vs OpenBSD Key-Differences:

Aspekt	OpenBSD	Debian
Location	/etc/ (base) vs /usr/local/etc/ (packages)	/etc/ (alles)
Group	root:wheel	root:root
Management	Single files	available/enabled-System
Versioning	Single version	Multi-version support

Service-Separation-Principle (Beibehalten):

furt-Config (nur Discovery-Management):

/etc/furt/
├── furt.conf              # Gateway-Config  
├── discovery-available/   # Discovery-rules (Debian-style)
│   ├── sagjan.conf       # Wie furt sagjan discovert
│   └── mail.conf         # Wie furt mail discovert
├── discovery-enabled/     # Symlinks → aktive Discovery
│   └── sagjan.conf → ../discovery-available/sagjan.conf
└── secrets/
    └── api-keys.conf

Service-Configs (separate Namespaces):

/etc/sagjan/
├── sagjan.conf           # sagjan-spezifische Config
└── secrets/
    └── database.env

/etc/formular2mail/
├── mail.conf
└── secrets/
    └── smtp.env

Discovery-Integration-Pattern (Debian-Style):

Service aktivieren:

# furt discovert sagjan
ln -s /etc/furt/discovery-available/sagjan.conf /etc/furt/discovery-enabled/

Service deaktivieren:

# furt ignoriert sagjan
rm /etc/furt/discovery-enabled/sagjan.conf

Debian-Specific Insights:

available/enabled-Pattern sehr nützlich für Service-Discovery-Management
Consistent /etc/ location einfacher als OpenBSD /etc/ vs /usr/local/etc/
systemd-Integration wichtig für Debian-Packages
Service-Separation bleibt kritisch - jeder Service = eigener Namespace

Cross-Distribution Config-Strategy (Emerging):

OpenBSD:

/usr/local/etc/furt/       # Package-location
/usr/local/etc/sagjan/     # Service-separation

Debian:

/etc/furt/                 # Consistent location
/etc/sagjan/               # Service-separation

Common Pattern: Service-separation + Discovery-management in furt

Next Research Steps:

Arch Linux Standards analysieren
Distribution-agnostic Config-Template entwickeln
Package-specific location-mapping
Migration-strategy von /etc/furt/environment

Status: Debian-Standards analysiert ✅ - Arch Linux Research next

## Debian Config-Standards Research - Zwischenergebnis (2025-08-14) ### Analysierte Debian-Services: **System Services:** - **Apache2**: /etc/apache2/apache2.conf + sites-available/enabled-System - **nginx**: /etc/nginx/nginx.conf + sites-available/enabled-System - **OpenSSH**: /etc/ssh/sshd_config + /etc/ssh/ssh_config - **postfix**: /etc/postfix/main.cf + /etc/postfix/master.cf **Database Services:** - **PostgreSQL**: /etc/postgresql/15/main/postgresql.conf (version-isolated) **systemd Integration:** - **Services**: /etc/systemd/system/service.service - **Overrides**: /etc/systemd/system/service.service.d/ ### Debian Config-Patterns (Discovered): **1. Location-Hierarchy:** - Alle Services: `/etc/package/` (nie /usr/local/etc/ wie OpenBSD) - Consistent location unabhängig von package vs base system **2. Available/Enabled-Pattern (Debian-spezifisch):** ``` /etc/apache2/sites-available/mysite # Config definiert /etc/apache2/sites-enabled/mysite # Symlink → aktiviert ``` **3. Version-Isolation:** ``` /etc/postgresql/15/main/ # Version in path /etc/postgresql/14/main/ # Parallel installations möglich ``` **4. Permission-Patterns:** - 644 root:root: Standard config files - 600 root:root: Security-sensitive configs - service:service: Service-specific ownership wo nötig ### Debian vs OpenBSD Key-Differences: | Aspekt | OpenBSD | Debian | |--------|---------|---------| | **Location** | /etc/ (base) vs /usr/local/etc/ (packages) | /etc/ (alles) | | **Group** | root:wheel | root:root | | **Management** | Single files | available/enabled-System | | **Versioning** | Single version | Multi-version support | ### Service-Separation-Principle (Beibehalten): **furt-Config (nur Discovery-Management):** ``` /etc/furt/ ├── furt.conf # Gateway-Config ├── discovery-available/ # Discovery-rules (Debian-style) │ ├── sagjan.conf # Wie furt sagjan discovert │ └── mail.conf # Wie furt mail discovert ├── discovery-enabled/ # Symlinks → aktive Discovery │ └── sagjan.conf → ../discovery-available/sagjan.conf └── secrets/ └── api-keys.conf ``` **Service-Configs (separate Namespaces):** ``` /etc/sagjan/ ├── sagjan.conf # sagjan-spezifische Config └── secrets/ └── database.env /etc/formular2mail/ ├── mail.conf └── secrets/ └── smtp.env ``` ### Discovery-Integration-Pattern (Debian-Style): **Service aktivieren:** ```bash # furt discovert sagjan ln -s /etc/furt/discovery-available/sagjan.conf /etc/furt/discovery-enabled/ ``` **Service deaktivieren:** ```bash # furt ignoriert sagjan rm /etc/furt/discovery-enabled/sagjan.conf ``` ### Debian-Specific Insights: - **available/enabled-Pattern** sehr nützlich für Service-Discovery-Management - **Consistent /etc/ location** einfacher als OpenBSD /etc/ vs /usr/local/etc/ - **systemd-Integration** wichtig für Debian-Packages - **Service-Separation bleibt kritisch** - jeder Service = eigener Namespace ### Cross-Distribution Config-Strategy (Emerging): **OpenBSD:** ``` /usr/local/etc/furt/ # Package-location /usr/local/etc/sagjan/ # Service-separation ``` **Debian:** ``` /etc/furt/ # Consistent location /etc/sagjan/ # Service-separation ``` **Common Pattern:** Service-separation + Discovery-management in furt ### Next Research Steps: 1. Arch Linux Standards analysieren 2. Distribution-agnostic Config-Template entwickeln 3. Package-specific location-mapping 4. Migration-strategy von /etc/furt/environment **Status: Debian-Standards analysiert ✅ - Arch Linux Research next**

michael commented

2025-08-14 15:58:15 +02:00

Owner

Arch Linux Config-Standards Research - Zwischenergebnis (2025-08-14)

Analysierte Arch-Services:

Web Services:

nginx: /etc/nginx/nginx.conf + /etc/nginx/conf.d/ (no sites-available/enabled)
httpd (Apache): /etc/httpd/conf/httpd.conf (single main config)

Database Services:

PostgreSQL: /var/lib/postgres/data/postgresql.conf (runtime data location)
MariaDB: /etc/my.cnf + /etc/my.cnf.d/ (main + drop-ins)
Redis: /etc/redis/redis.conf (644 redis:redis)

System Services:

OpenSSH: /etc/ssh/sshd_config + /etc/ssh/ssh_config
systemd: /etc/systemd/system/ + service.service.d/ (drop-ins)

Arch Linux Config-Patterns (Discovered):

1. Location-Philosophy:

Standard configs: /etc/package/ (wie Debian)
Runtime data: /var/lib/package/ (postgresql, etc.)
User configs: ~/.config/package/ (XDG-compliant)

2. "The Arch Way" - No-Automation-Philosophy:

Debian: sites-available/enabled automation helpers
Arch:   Manual configuration preferred
        "User configures explicitly" - no magic

3. systemd-First-Approach:

systemd für Service-Management (core component)
Drop-in files für Service-Customization
Service dependencies via systemd units

4. Minimal-Defaults-Pattern:

Arch liefert minimal configs
User expected to customize heavily
No distribution-specific automation helpers

5. Service-User-Ownership:

Service-specific users common (redis:redis, postgres:postgres)
Not always root:root wie Debian

Three-Distribution Comparison:

Aspekt	OpenBSD	Debian	Arch
Location	/usr/local/etc/ (pkg) /etc/ (base)	/etc/ (alles)	/etc/ (alles)
Automation	Manual	available/enabled	Manual ("Arch Way")
systemd	Nicht vorhanden	Standard	Core/First-class
Defaults	Secure defaults	User-friendly helpers	Minimal defaults
Philosophy	Security-first	Convenience	User-control
Group	root:wheel	root:root	root:root

Arch-Specific furt Config-Strategy:

Option A: Arch-Style Minimal (Empfohlen)

/etc/furt/
├── furt.conf              # Main config (644 root:root)
├── services/              # Simple directory (no automation)
│   ├── sagjan.conf       # Discovery config
│   └── mail.conf         # Discovery config  
└── secrets/              # Separate secrets (600 furt:furt)
    └── api-keys.conf

Option B: systemd-Integration

/etc/furt/
├── furt.conf
└── systemd/              # systemd drop-ins
    └── service-discovery.conf

# Plus systemd service dependencies:
/etc/systemd/system/furt.service.d/
└── discovery.conf        # Service-Discovery overrides

Service-Separation (weiterhin getrennt):

/etc/sagjan/sagjan.conf      # Separate namespace
/etc/formular2mail/mail.conf # Separate namespace

systemd-Native Service-Discovery (Arch-Style):

furt.service with dependencies:

[Unit]
Wants=sagjan.service formular2mail.service
After=sagjan.service formular2mail.service

[Service]
ExecStartPost=/usr/bin/furt-discover-services

Service registration via systemd:

# Arch-style: explicit service dependencies
systemctl enable sagjan.service    # Manual enable
systemctl enable furt.service      # Auto-discovers enabled services

Arch-Specific Insights:

"The Arch Way" für furt:

Minimal config defaults - user konfiguriert explizit
Manual service registration - kein auto-discovery per default
systemd-native integration - nutze systemd für dependencies
No magic helpers - user versteht was passiert

Distribution-Pattern emerging:

OpenBSD: Security-first, manual config, BSD-locations
Debian: User-friendly, automation helpers, consistent /etc/
Arch: User-control, minimal defaults, systemd-native

Cross-Distribution Service-Discovery-Strategy:

OpenBSD approach:

# Manual rcctl service management
rcctl enable sagjan && rcctl enable furt

Debian approach:

# available/enabled pattern für discovery
ln -s /etc/furt/discovery-available/sagjan.conf /etc/furt/discovery-enabled/

Arch approach:

# systemd dependency management
systemctl enable sagjan.service furt.service

Key Takeaways:

Service-Separation critical across all distributions
Different automation philosophies require different approaches
systemd vs rcctl vs sysvinit affects service discovery implementation
Location standards vary (/etc/ vs /usr/local/etc/) but patterns consistent

Next Research Steps:

FreeBSD standards check (BSD-family completion)
Distribution-agnostic config template design
Service-Discovery protocol specification
Migration strategy development

Status: Arch Linux Standards analysiert ✅ - FreeBSD Research optional

## Arch Linux Config-Standards Research - Zwischenergebnis (2025-08-14) ### Analysierte Arch-Services: **Web Services:** - **nginx**: /etc/nginx/nginx.conf + /etc/nginx/conf.d/ (no sites-available/enabled) - **httpd** (Apache): /etc/httpd/conf/httpd.conf (single main config) **Database Services:** - **PostgreSQL**: /var/lib/postgres/data/postgresql.conf (runtime data location) - **MariaDB**: /etc/my.cnf + /etc/my.cnf.d/ (main + drop-ins) - **Redis**: /etc/redis/redis.conf (644 redis:redis) **System Services:** - **OpenSSH**: /etc/ssh/sshd_config + /etc/ssh/ssh_config - **systemd**: /etc/systemd/system/ + service.service.d/ (drop-ins) ### Arch Linux Config-Patterns (Discovered): **1. Location-Philosophy:** - Standard configs: `/etc/package/` (wie Debian) - Runtime data: `/var/lib/package/` (postgresql, etc.) - User configs: `~/.config/package/` (XDG-compliant) **2. "The Arch Way" - No-Automation-Philosophy:** ``` Debian: sites-available/enabled automation helpers Arch: Manual configuration preferred "User configures explicitly" - no magic ``` **3. systemd-First-Approach:** - systemd für Service-Management (core component) - Drop-in files für Service-Customization - Service dependencies via systemd units **4. Minimal-Defaults-Pattern:** - Arch liefert minimal configs - User expected to customize heavily - No distribution-specific automation helpers **5. Service-User-Ownership:** - Service-specific users common (redis:redis, postgres:postgres) - Not always root:root wie Debian ### Three-Distribution Comparison: | Aspekt | OpenBSD | Debian | Arch | |--------|---------|---------|------| | **Location** | /usr/local/etc/ (pkg)<br>/etc/ (base) | /etc/ (alles) | /etc/ (alles) | | **Automation** | Manual | available/enabled | Manual ("Arch Way") | | **systemd** | Nicht vorhanden | Standard | Core/First-class | | **Defaults** | Secure defaults | User-friendly helpers | Minimal defaults | | **Philosophy** | Security-first | Convenience | User-control | | **Group** | root:wheel | root:root | root:root | ### Arch-Specific furt Config-Strategy: **Option A: Arch-Style Minimal (Empfohlen)** ``` /etc/furt/ ├── furt.conf # Main config (644 root:root) ├── services/ # Simple directory (no automation) │ ├── sagjan.conf # Discovery config │ └── mail.conf # Discovery config └── secrets/ # Separate secrets (600 furt:furt) └── api-keys.conf ``` **Option B: systemd-Integration** ``` /etc/furt/ ├── furt.conf └── systemd/ # systemd drop-ins └── service-discovery.conf # Plus systemd service dependencies: /etc/systemd/system/furt.service.d/ └── discovery.conf # Service-Discovery overrides ``` **Service-Separation (weiterhin getrennt):** ``` /etc/sagjan/sagjan.conf # Separate namespace /etc/formular2mail/mail.conf # Separate namespace ``` ### systemd-Native Service-Discovery (Arch-Style): **furt.service with dependencies:** ```ini [Unit] Wants=sagjan.service formular2mail.service After=sagjan.service formular2mail.service [Service] ExecStartPost=/usr/bin/furt-discover-services ``` **Service registration via systemd:** ```bash # Arch-style: explicit service dependencies systemctl enable sagjan.service # Manual enable systemctl enable furt.service # Auto-discovers enabled services ``` ### Arch-Specific Insights: **"The Arch Way" für furt:** - **Minimal config defaults** - user konfiguriert explizit - **Manual service registration** - kein auto-discovery per default - **systemd-native integration** - nutze systemd für dependencies - **No magic helpers** - user versteht was passiert **Distribution-Pattern emerging:** - **OpenBSD**: Security-first, manual config, BSD-locations - **Debian**: User-friendly, automation helpers, consistent /etc/ - **Arch**: User-control, minimal defaults, systemd-native ### Cross-Distribution Service-Discovery-Strategy: **OpenBSD approach:** ```bash # Manual rcctl service management rcctl enable sagjan && rcctl enable furt ``` **Debian approach:** ```bash # available/enabled pattern für discovery ln -s /etc/furt/discovery-available/sagjan.conf /etc/furt/discovery-enabled/ ``` **Arch approach:** ```bash # systemd dependency management systemctl enable sagjan.service furt.service ``` ### Key Takeaways: - **Service-Separation critical** across all distributions - **Different automation philosophies** require different approaches - **systemd vs rcctl vs sysvinit** affects service discovery implementation - **Location standards vary** (/etc/ vs /usr/local/etc/) but patterns consistent ### Next Research Steps: 1. FreeBSD standards check (BSD-family completion) 2. Distribution-agnostic config template design 3. Service-Discovery protocol specification 4. Migration strategy development **Status: Arch Linux Standards analysiert ✅ - FreeBSD Research optional**

michael commented

2025-08-14 16:03:38 +02:00

Owner

FreeBSD Config-Standards Research - Zwischenergebnis (2025-08-14)

Analysierte FreeBSD-Services:

Ports-System Services:

nginx: /usr/local/etc/nginx/nginx.conf + conf.d/
Apache24: /usr/local/etc/apache24/httpd.conf (versioned package name)
PostgreSQL: /usr/local/pgsql/data/postgresql.conf + samples in /usr/local/share/
Redis: /usr/local/etc/redis.conf (644 redis:redis)

Base System Services:

OpenSSH: /etc/ssh/sshd_config + /etc/ssh/ssh_config
rc.d System: /etc/rc.d/ (base) + /usr/local/etc/rc.d/ (ports)

FreeBSD Config-Patterns (Discovered):

1. Ports vs Base System Separation:

Base system: /etc/ (wie OpenBSD)
Ports/Packages: /usr/local/etc/ (wie OpenBSD)
Runtime data: /var/db/service/ (FreeBSD-spezifisch vs OpenBSD /var/service/)

2. Versioned-Package-Pattern:

/usr/local/etc/apache24/    # Version in package name
/usr/local/etc/php81/       # Multiple versions parallel möglich

3. rc.conf-Central-Management:

# /etc/rc.conf - Central service configuration
nginx_enable="YES"
postgresql_enable="YES"
service_flags="-f /custom/path"    # Service-specific flags

4. Sample-Config-Pattern:

/usr/local/share/package/sample.conf  # Template configs
/usr/local/etc/package.conf           # Active configs

FreeBSD vs OpenBSD Key-Differences:

Aspekt	OpenBSD	FreeBSD
Package Names	Simple (nginx, php)	Versioned (apache24, php81)
Service Management	rcctl enable nginx	nginx_enable="YES" in rc.conf
Runtime Data	/var/service/	/var/db/service/
Philosophy	Minimal/Security-first	Ports-flexibility
Corporate Influence	Resistant	Increasing

Four-Distribution Complete Comparison:

Aspekt	OpenBSD	FreeBSD	Debian	Arch
Config Location	/usr/local/etc/	/usr/local/etc/	/etc/	/etc/
Versioning	Simple names	Versioned packages	Multi-version dirs	Simple names
Service Management	rcctl	rc.conf	systemctl	systemctl
Automation	Manual	rc.conf-central	available/enabled	Manual ("Arch Way")
Philosophy	Security-first	Flexibility	User-friendly	User-control
Group Ownership	root:wheel	root:wheel	root:root	root:root

BSD-Family vs Linux-Family Patterns:

BSD-Familie (OpenBSD + FreeBSD):

/usr/local/etc/ für packages/ports
root:wheel group ownership
Manual/rc.conf service management (no systemd)

Linux-Familie (Debian + Arch):

/etc/ für alles
root:root group ownership
systemd service management

FreeBSD-Specific Insights:

Corporate-Influence-Drift:

Komplexere Package-Versioning vs OpenBSD-Simplicity
More "Enterprise-Features" (parallel versions, etc.)
Weniger Minimalismus als OpenBSD

furt FreeBSD-Strategy:

/usr/local/etc/furt/
├── furt.conf              # Main config (644 root:wheel)
├── services/              # Service discovery configs
│   ├── sagjan.conf
│   └── mail.conf
└── secrets/              # Separate secrets (600 root:wheel)
    └── api-keys.conf

# Service-separation beibehalten:
/usr/local/etc/sagjan/sagjan.conf      # Separate namespace
/usr/local/etc/formular2mail/mail.conf

rc.conf-Integration:

# /etc/rc.conf
furt_enable="YES"
sagjan_enable="YES"
formular2mail_enable="YES"

Cross-Distribution Service-Discovery Summary:

Service-Separation Pattern (Universal):

Jeder Service = eigener /etc/service/ oder /usr/local/etc/service/ namespace
furt = Service-Discovery-Coordinator, nicht Config-Owner
Kritisch für alle vier Distributionen

Location-Mapping:

OpenBSD:  /usr/local/etc/furt/
FreeBSD:  /usr/local/etc/furt/
Debian:   /etc/furt/
Arch:     /etc/furt/

Service-Management-Integration:

OpenBSD:  rcctl enable furt
FreeBSD:  furt_enable="YES" in rc.conf
Debian:   systemctl enable furt + available/enabled pattern
Arch:     systemctl enable furt + manual config

Research-Completion Status:

✅ Completed Distribution Analysis:

OpenBSD: Security-first, minimal, BSD-locations
Debian: User-friendly, automation helpers, consistent locations
Arch: User-control, minimal defaults, systemd-native
FreeBSD: Ports-flexibility, versioned packages, BSD-locations

🎯 Ready for Next Phase:

Cross-Distribution Config-Template Design
Service-Discovery Protocol Specification
Migration Strategy from /etc/furt/environment
Package-Distribution Structure for Issue #88

Key Insight: Service-separation + Distribution-specific locations = Universal pattern für Multi-Service-Architecture

Status: Four-Distribution Research Complete ✅ - Ready for Config-Design Phase

## FreeBSD Config-Standards Research - Zwischenergebnis (2025-08-14) ### Analysierte FreeBSD-Services: **Ports-System Services:** - **nginx**: /usr/local/etc/nginx/nginx.conf + conf.d/ - **Apache24**: /usr/local/etc/apache24/httpd.conf (versioned package name) - **PostgreSQL**: /usr/local/pgsql/data/postgresql.conf + samples in /usr/local/share/ - **Redis**: /usr/local/etc/redis.conf (644 redis:redis) **Base System Services:** - **OpenSSH**: /etc/ssh/sshd_config + /etc/ssh/ssh_config - **rc.d System**: /etc/rc.d/ (base) + /usr/local/etc/rc.d/ (ports) ### FreeBSD Config-Patterns (Discovered): **1. Ports vs Base System Separation:** - Base system: `/etc/` (wie OpenBSD) - Ports/Packages: `/usr/local/etc/` (wie OpenBSD) - Runtime data: `/var/db/service/` (FreeBSD-spezifisch vs OpenBSD /var/service/) **2. Versioned-Package-Pattern:** ``` /usr/local/etc/apache24/ # Version in package name /usr/local/etc/php81/ # Multiple versions parallel möglich ``` **3. rc.conf-Central-Management:** ```bash # /etc/rc.conf - Central service configuration nginx_enable="YES" postgresql_enable="YES" service_flags="-f /custom/path" # Service-specific flags ``` **4. Sample-Config-Pattern:** ```bash /usr/local/share/package/sample.conf # Template configs /usr/local/etc/package.conf # Active configs ``` ### FreeBSD vs OpenBSD Key-Differences: | Aspekt | OpenBSD | FreeBSD | |--------|---------|---------| | **Package Names** | Simple (nginx, php) | Versioned (apache24, php81) | | **Service Management** | rcctl enable nginx | nginx_enable="YES" in rc.conf | | **Runtime Data** | /var/service/ | /var/db/service/ | | **Philosophy** | Minimal/Security-first | Ports-flexibility | | **Corporate Influence** | Resistant | Increasing | ### Four-Distribution Complete Comparison: | Aspekt | OpenBSD | FreeBSD | Debian | Arch | |--------|---------|---------|---------|------| | **Config Location** | /usr/local/etc/ | /usr/local/etc/ | /etc/ | /etc/ | | **Versioning** | Simple names | Versioned packages | Multi-version dirs | Simple names | | **Service Management** | rcctl | rc.conf | systemctl | systemctl | | **Automation** | Manual | rc.conf-central | available/enabled | Manual ("Arch Way") | | **Philosophy** | Security-first | Flexibility | User-friendly | User-control | | **Group Ownership** | root:wheel | root:wheel | root:root | root:root | ### BSD-Family vs Linux-Family Patterns: **BSD-Familie (OpenBSD + FreeBSD):** - `/usr/local/etc/` für packages/ports - `root:wheel` group ownership - Manual/rc.conf service management (no systemd) **Linux-Familie (Debian + Arch):** - `/etc/` für alles - `root:root` group ownership - systemd service management ### FreeBSD-Specific Insights: **Corporate-Influence-Drift:** - Komplexere Package-Versioning vs OpenBSD-Simplicity - More "Enterprise-Features" (parallel versions, etc.) - Weniger Minimalismus als OpenBSD **furt FreeBSD-Strategy:** ``` /usr/local/etc/furt/ ├── furt.conf # Main config (644 root:wheel) ├── services/ # Service discovery configs │ ├── sagjan.conf │ └── mail.conf └── secrets/ # Separate secrets (600 root:wheel) └── api-keys.conf # Service-separation beibehalten: /usr/local/etc/sagjan/sagjan.conf # Separate namespace /usr/local/etc/formular2mail/mail.conf ``` **rc.conf-Integration:** ```bash # /etc/rc.conf furt_enable="YES" sagjan_enable="YES" formular2mail_enable="YES" ``` ### Cross-Distribution Service-Discovery Summary: **Service-Separation Pattern (Universal):** - Jeder Service = eigener `/etc/service/` oder `/usr/local/etc/service/` namespace - furt = Service-Discovery-Coordinator, nicht Config-Owner - Kritisch für alle vier Distributionen **Location-Mapping:** ``` OpenBSD: /usr/local/etc/furt/ FreeBSD: /usr/local/etc/furt/ Debian: /etc/furt/ Arch: /etc/furt/ ``` **Service-Management-Integration:** ``` OpenBSD: rcctl enable furt FreeBSD: furt_enable="YES" in rc.conf Debian: systemctl enable furt + available/enabled pattern Arch: systemctl enable furt + manual config ``` ### Research-Completion Status: **✅ Completed Distribution Analysis:** - OpenBSD: Security-first, minimal, BSD-locations - Debian: User-friendly, automation helpers, consistent locations - Arch: User-control, minimal defaults, systemd-native - FreeBSD: Ports-flexibility, versioned packages, BSD-locations **🎯 Ready for Next Phase:** 1. Cross-Distribution Config-Template Design 2. Service-Discovery Protocol Specification 3. Migration Strategy from /etc/furt/environment 4. Package-Distribution Structure for Issue #88 **Key Insight:** Service-separation + Distribution-specific locations = Universal pattern für Multi-Service-Architecture **Status: Four-Distribution Research Complete ✅ - Ready for Config-Design Phase**

michael commented

2025-08-14 19:04:51 +02:00

Owner

Config-Strategy Research: Distribution Best Practices - COMPLETE (2025-08-14)

Four-Distribution Analysis Complete

Research-Scope: OpenBSD, Debian, Arch Linux, FreeBSD config-patterns für Open Source-Tools

Distribution-Standards Findings

Distribution	Config Location	Service Management	Permission Pattern	Philosophy
OpenBSD	`/usr/local/etc/furt/`	`rcctl enable furt`	`644 root:wheel`	Security-first, minimal
Debian	`/etc/furt/`	`systemctl enable furt` + available/enabled pattern	`644 root:root`	User-friendly, automation helpers
Arch	`/etc/furt/`	`systemctl enable furt` (manual config)	`644 root:root`	User-control, minimal defaults
FreeBSD	`/usr/local/etc/furt/`	`furt_enable="YES"` in rc.conf	`644 root:wheel`	Ports-flexibility, versioned packages

Key Insights Discovered

1. Universal Pattern: Service-Separation Critical

furt = Service-Discovery-Coordinator (nicht Config-Owner)
sagjan = Separate namespace /etc/sagjan/ oder /usr/local/etc/sagjan/
formular2mail = Separate namespace /etc/formular2mail/
Kritisch für alle vier Distributionen

2. Location-Mapping-Pattern:

BSD-Familie (OpenBSD + FreeBSD): /usr/local/etc/
Linux-Familie (Debian + Arch): /etc/

3. Service-Management-Integration:

OpenBSD: rcctl enable furt
FreeBSD: furt_enable="YES" in rc.conf  
Debian: systemctl enable furt + available/enabled pattern
Arch: systemctl enable furt + manual config

4. Config-Format-Expectations:

All Distributions: Prefer simple key=value or nginx-style configs
Avoid: Lua-configs (developer-friendly, not admin-friendly)
Prefer: .conf files with [sections] and comments

Open Source-Analysis (Verified Patterns)

nginx: /etc/nginx/nginx.conf + conf.d/ (all distributions)
postgresql: Distribution-specific paths but consistent patterns
ssh: /etc/ssh/sshd_config (universal)
apache: /etc/apache2/ (Debian) vs /etc/httpd/ (others)

furt-Standard-Recommendation

1. Distribution-Agnostic Install:

# install.sh detects and maps:
OpenBSD/FreeBSD: /usr/local/etc/furt/furt.conf
Debian/Arch: /etc/furt/furt.conf

2. Service-Separation-Architecture:

/usr/local/etc/furt/furt.conf          # Gateway-only config
/usr/local/etc/sagjan/sagjan.conf      # Service-specific config  
/usr/local/etc/formular2mail/mail.conf # Service-specific config

3. Admin-Friendly Config-Format:

# nginx-style sections
[server]
port = 8080
host = 127.0.0.1

[api_keys]
hugo_key = xxx
admin_key = yyy

4. Package-Distribution-Strategy:

Universal tar + install.sh with distribution-detection
No distribution-specific packages initially
Service-separation allows independent packaging later

Migration-Strategy (from /etc/furt/environment)

Not needed for current deployments (only karl + walter)

Manual config-conversion sufficient
Simple key=value → [sections] mapping

Documentation Requirements (Next Steps)

Admin-Guide for all four distributions
Config-Format-Specification (nginx-style)
Service-Separation-Guidelines for additional services
Package-Distribution-Templates for each distribution

Research-Status: COMPLETE ✅

Ready for: Config-Implementation-Phase based on these standards

Dependencies: None - Research-phase complete

Next Issue: Implementation of distribution-agnostic config-system based on these findings

## Config-Strategy Research: Distribution Best Practices - COMPLETE (2025-08-14) ### Four-Distribution Analysis Complete **Research-Scope:** OpenBSD, Debian, Arch Linux, FreeBSD config-patterns für Open Source-Tools ### Distribution-Standards Findings | Distribution | Config Location | Service Management | Permission Pattern | Philosophy | |--------------|-----------------|--------------------|--------------------|------------| | **OpenBSD** | `/usr/local/etc/furt/` | `rcctl enable furt` | `644 root:wheel` | Security-first, minimal | | **Debian** | `/etc/furt/` | `systemctl enable furt` + available/enabled pattern | `644 root:root` | User-friendly, automation helpers | | **Arch** | `/etc/furt/` | `systemctl enable furt` (manual config) | `644 root:root` | User-control, minimal defaults | | **FreeBSD** | `/usr/local/etc/furt/` | `furt_enable="YES"` in rc.conf | `644 root:wheel` | Ports-flexibility, versioned packages | ### Key Insights Discovered **1. Universal Pattern: Service-Separation Critical** - **furt** = Service-Discovery-Coordinator (nicht Config-Owner) - **sagjan** = Separate namespace `/etc/sagjan/` oder `/usr/local/etc/sagjan/` - **formular2mail** = Separate namespace `/etc/formular2mail/` - **Kritisch für alle vier Distributionen** **2. Location-Mapping-Pattern:** ``` BSD-Familie (OpenBSD + FreeBSD): /usr/local/etc/ Linux-Familie (Debian + Arch): /etc/ ``` **3. Service-Management-Integration:** ``` OpenBSD: rcctl enable furt FreeBSD: furt_enable="YES" in rc.conf Debian: systemctl enable furt + available/enabled pattern Arch: systemctl enable furt + manual config ``` **4. Config-Format-Expectations:** - **All Distributions:** Prefer simple key=value or nginx-style configs - **Avoid:** Lua-configs (developer-friendly, not admin-friendly) - **Prefer:** .conf files with [sections] and comments ### Open Source-Analysis (Verified Patterns) **nginx**: `/etc/nginx/nginx.conf` + `conf.d/` (all distributions) **postgresql**: Distribution-specific paths but consistent patterns **ssh**: `/etc/ssh/sshd_config` (universal) **apache**: `/etc/apache2/` (Debian) vs `/etc/httpd/` (others) ### furt-Standard-Recommendation **1. Distribution-Agnostic Install:** ```bash # install.sh detects and maps: OpenBSD/FreeBSD: /usr/local/etc/furt/furt.conf Debian/Arch: /etc/furt/furt.conf ``` **2. Service-Separation-Architecture:** ``` /usr/local/etc/furt/furt.conf # Gateway-only config /usr/local/etc/sagjan/sagjan.conf # Service-specific config /usr/local/etc/formular2mail/mail.conf # Service-specific config ``` **3. Admin-Friendly Config-Format:** ```ini # nginx-style sections [server] port = 8080 host = 127.0.0.1 [api_keys] hugo_key = xxx admin_key = yyy ``` **4. Package-Distribution-Strategy:** - **Universal tar** + `install.sh` with distribution-detection - **No distribution-specific packages** initially - **Service-separation** allows independent packaging later ### Migration-Strategy (from /etc/furt/environment) **Not needed for current deployments** (only karl + walter) - Manual config-conversion sufficient - Simple key=value → [sections] mapping ### Documentation Requirements (Next Steps) 1. **Admin-Guide** for all four distributions 2. **Config-Format-Specification** (nginx-style) 3. **Service-Separation-Guidelines** for additional services 4. **Package-Distribution-Templates** for each distribution ### Research-Status: COMPLETE ✅ **Ready for:** Config-Implementation-Phase based on these standards **Dependencies:** None - Research-phase complete **Next Issue:** Implementation of distribution-agnostic config-system based on these findings

michael referenced this issue

2025-08-14 19:13:27 +02:00

Multi-Tenant Config-System: Ein furt für viele Websites #89

michael

2025-08-15 05:53:11 +02:00