- 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>
Problem: state-Datei vom letzten Update zeigte noch 'done'. pollUpdate()
las das direkt nach runUpdate() als "Update fertig" — bevor der neue
Prozess überhaupt startete. displayCurrent war dann noch die alte Version.
Fix:
- runUpdate() setzt state='starting' und löscht rc VOR dem Shell-Aufruf
- runUpdate() setzt rc=null, lowState='starting', postActionsDone=false zurück
- refreshLowLevelState(): Kommentar klärt dass 'starting' als running gilt
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- loadSslStatus(): clearstatcache() + renewal-Conf als primärer Existenzcheck
(renewal/ ist immer 755, zuverlässiger als is_dir auf live/ das 750 sein kann)
+ /usr/bin/openssl (voller Pfad für sudoers-Matching)
- restoreSslProvisioningState(): stellt letzten Provisioning-Zustand aus
State-Dateien wieder her, so dass Status nach Page-Reload sichtbar bleibt
- Button zeigt nach Abschluss "Erneut einrichten" statt disabled zu bleiben
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Scripts, Sudoers-Regeln und sbin-Binaries werden jetzt immer
aktualisiert — auch wenn kein Update verfügbar ist. Damit entfällt
das manuelle Nachtragen von Sudoers-Regeln nach neuen Releases.
ensure_system() wird aufgerufen:
- Vor jedem "bereits aktuell"-Exit (tags + branch mode)
- Am Ende jedes erfolgreichen Updates
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Problem: /etc/letsencrypt/archive/ ist chmod 700 (root only).
file_exists() auf Symlinks in live/ schlägt fehl weil Symlink-Ziel
in archive/ nicht lesbar ist. is_dir() auf live/domain/ funktioniert
da das Verzeichnis selbst 755 ist.
- SettingsForm: file_exists() → is_dir() für Existenzcheck
- SettingsForm: openssl-Aufruf via sudo -n (archive/ ist root-only)
- installer.sh + update.sh: sudoers-Regel für openssl auf LE-Cert-Pfade
(www-data darf nur exakt diesen openssl-Aufruf, keine anderen Pfade)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Auf Produktivservern gibt es fast immer kleine Änderungen (App-generierte
Dateien, Setup-Änderungen). Statt Abbruch: tracked Dateien via git reset
--hard zurücksetzen, untracked Nicht-Systemdateien via git clean entfernen.
.env, storage/ und node_modules/ werden dabei bewusst ausgespart.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Problem: Henne-Ei-Situation — alte Server haben alte CheckUpdates.php die
git fetch als www-data aufruft (schlägt wegen fehlender Credentials fehl).
Neue mailwolt-fetch-tags Helper sind noch nicht deployed.
Lösung:
- scripts/update.sh: --check-only Flag — ruft nur git ls-remote als App-User
auf, schreibt version_remote, beendet sich sofort (kein Update)
- update.sh: schreibt version_remote auch nach normalem Tag-Fetch (damit es
nach manuellen Updates aktuell bleibt)
- CheckUpdates.php: sichere Fallback-Kette:
1. mailwolt-update --check-only (nur wenn Skript das Flag kennt — kein
versehentliches Triggern auf alten Servern)
2. mailwolt-fetch-tags (ab v1.1.268)
3. lokale git tags (letzter Fallback)
+ version_remote wird nur verwendet wenn < 2h alt
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Neuer Abschnitt "SSL-Zertifikate" in den Einstellungen:
· Zeigt pro Domain (UI, Webmail, Mailserver) ob LE-Cert vorhanden ist,
Ablaufdatum und Status (OK / fehlt / läuft ab / abgelaufen)
· Button "Let's Encrypt Zertifikate einrichten" startet Provisioning
im Hintergrund (nohup, non-blocking)
· Live-Fortschrittsanzeige per wire:poll.2s mit Status-Icons pro Domain
(pending → running → done/error/skip)
- saveDomains() ruft apply-domains jetzt ohne certbot auf (--ssl-auto 0) —
Domains speichern und SSL einrichten sind damit getrennte Aktionen
- loadSslStatus() liest Certbot-Zertifikat-Info direkt aus openssl
- spin-Keyframe für Spinner-Animation in app.css
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Neu: scripts/mailwolt-fetch-tags ruft git ls-remote als App-User auf (hat Credentials),
schreibt neuesten Tag nach /var/lib/mailwolt/version_remote
- CheckUpdates.php nutzt jetzt sudo mailwolt-fetch-tags statt direktem git fetch als www-data
(www-data hat keine Git-Credentials für private Repos)
- SettingsForm.php zeigt tatsächliche Fehlerzeilen ([!], error, failed) im Toast statt
generischer "fehlgeschlagen"-Meldung
- installer.sh + update.sh installieren mailwolt-fetch-tags nach /usr/local/sbin/
- update.sh trägt mailwolt-fetch-tags automatisch in sudoers nach (Upgrade-Pfad)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- certbot_safe(): dig ist auf Ubuntu nicht immer installiert (kein dnsutils).
Mit set -euo pipefail crashte die Funktion lautlos → certbot nie ausgeführt.
Fallback auf getent ahostsv6 wenn dig fehlt; Zuweisung mit || has_aaaa=""
damit set -e nicht greift falls beide Befehle scheitern.
- echo "mailwolt-apply-domains fertig" am Ende: SettingsForm.php prüft ob
"fertig" im Output steht um ssl_configured=1 zu setzen — ohne diesen Echo
wurde SSL nie als konfiguriert markiert, selbst wenn Zertifikate vorhanden.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Alle Scripts zentral unter scripts/:
- scripts/update.sh (war update.sh)
- scripts/mailwolt-apply-domains
installer.sh und update.sh selbst auf neuen Pfad angepasst.
Update laufender Server (einmalig):
sudo install -m 755 /var/www/mailwolt/scripts/update.sh /usr/local/sbin/mailwolt-update
sudo install -m 755 /var/www/mailwolt/scripts/mailwolt-apply-domains /usr/local/sbin/mailwolt-apply-domains
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Beide Scripts werden jetzt bei jedem erfolgreichen Update eingespielt,
unabhängig von CHANGED_FILES — löst den Bootstrap-Problem wo die alte
mailwolt-update Version die neue Logik nicht kannte.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Bei Änderungen unter scripts/ wird mailwolt-apply-domains automatisch
nach /usr/local/sbin/ kopiert — kein manueller Eingriff mehr nötig.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Script aus installer.sh-Heredoc in scripts/mailwolt-apply-domains ausgelagert.
installer.sh kopiert es jetzt via install -m 755 statt Heredoc.
Vorteile:
- git pull + sudo cp reicht um das Script auf laufenden Servern zu aktualisieren
- Keine doppelte Pflege mehr (Heredoc vs. Datei)
- Änderungen direkt im Script-File sichtbar (git diff)
Update laufender Server:
sudo install -m 755 /var/www/mailwolt/scripts/mailwolt-apply-domains \
/usr/local/sbin/mailwolt-apply-domains
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
boban