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>
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>
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>
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>
- 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>
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>
boban