- ensure_system() jetzt direkt nach git_safe/git_dirty_check aufgerufen
- Sbin wird bei JEDEM Update-Aufruf aktualisiert, nicht nur auf bestimmten Pfaden
- Root-Ursache: alte sbin (v1.0.137, April 23) hatte kein ensure_system → alle
Fixes in scripts/update.sh wurden nie auf dem Server ausgeführt
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- fix_ownership() getrennt von fix_permissions() (nur chown/chmod, kein optimize)
- _cleanup: bei Erfolg nur fix_ownership, bei Fehler fix_permissions (mit optimize)
- Verhindert dass _cleanup nach erfolgreichem Update den View-Cache wieder löscht
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- fix_permissions (chown + optimize) läuft jetzt VOR restart_php_fpm
- config:cache + route:cache aus dem Update-Flow entfernt (fix_permissions/optimize übernimmt das)
- artisan up erfolgt NACH PHP-FPM Restart – App geht erst online wenn alles korrekt ist
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- dvx.blade.php: Virenschutz-Link (ClamAV) in Sicherheits-Sektion eingefügt
- fix_permissions: optimize:clear + optimize hintereinander – Cache wird nach
Permissions-Fix neu aufgebaut, kein leerer/fehlender Cache mehr
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- frontend_build_quiet: altes public/build/ als .bak sichern,
bei npm-Fehler wiederherstellen → Site bleibt immer erreichbar
- fix_permissions: wenn manifest.json fehlt, automatisch neu bauen
→ kein manueller Eingriff nach fehlgeschlagenem Update nötig
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
ensure_system() wird bei JEDEM Update aufgerufen, selbst wenn kein
Code geändert wurde. fix_permissions dort garantiert saubere Rechte
und frischen Cache unabhängig von der sbin-Version.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- git_safe: chown -R APP_DIR immer (kein bedingter Check)
- git_dirty_check + alle git fetch/checkout: als root → kein
"permission denied" / "dubious ownership" mehr
- _cleanup: fix_permissions() immer aufrufen (auch bei Fehler-Abbruch)
→ kein 404/500 nach fehlgeschlagenem Update mehr
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
chown -R nur wenn APP_DIR nicht dem APP_USER gehört, sonst nur .git.
Verhindert "Your local changes would be overwritten" nach root-Läufen.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Neue Seite /security/clamav: Status, Aktivieren/Deaktivieren,
Signatur-Update, RAM-Hinweis, Info-Box
- Optionale Dienste (ClamAV) im Dashboard nur sichtbar wenn aktiv
- mailwolt-clamav sbin-Wrapper + sudoers-Regel in ensure_system
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Nach APP_USER-Wechsel von mailwolt→www-data schlägt git mit "dubious
ownership" fehl. git config --system schreibt /etc/gitconfig (root),
gilt für alle User. Zusätzlich .git vollständig neu besitzen.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- loadServices() liest Monit-Cache, fällt zurück auf woltguard.php Karten
mit direkten systemd/tcp-Probes wenn Cache leer ist
- Monit als Dienst in woltguard.php ergänzt
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Artisan-Befehle (config:cache, route:cache, optimize:clear) liefen als
'mailwolt'-User, PHP-FPM läuft als 'www-data' → Cache-Dateien nicht
lesbar → 404 nach jedem Update. Default auf www-data gesetzt damit
beide User übereinstimmen.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Zertifikate einrichten/erneuern nur noch unter Sicherheit → SSL/TLS
- SSL-Seite: Provisioning mit Fortschritt, Ablaufdatum + Tage in Tabelle
- Einstellungen: nur noch read-only Status + Link zu SSL-Seite
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- mailwolt-apply-domains: MAIL_HOST wird in ACME-Challenge-Block aufgenommen,
certbot wird auch für die Mail-Domain ausgeführt, Postfix + Dovecot erhalten
danach automatisch das neue Zertifikat
- SslCertificatesTable: certbot-Ausgabe korrekt geparst (Einrückung mit Leerzeichen)
- settings-form: "kein Zertifikat nötig" entfernt (Mail-Domain braucht Zertifikat)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
exec > >(tee -a LOG_FILE) leitet stdout an tee weiter:
- CLI: Ausgabe weiterhin im Terminal + in Log-Datei
- UI (nohup >/dev/null): stdout geht nach /dev/null aber tee
schreibt trotzdem in die Log-Datei
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
boban