The check_for_gh_release function already prints its own 'No update
available' message when the app is up to date. The else block using
${RELEASE} was redundant and caused an empty version string to be shown
(e.g. 'already at v').
Fixes: #14267
* Add matomo (ct)
* Remove flatten_matomo_layout function
Removed the flatten_matomo_layout function and its calls.
---------
Co-authored-by: push-app-to-main[bot] <203845782+push-app-to-main[bot]@users.noreply.github.com>
Co-authored-by: CanbiZ (MickLesk) <47820557+MickLesk@users.noreply.github.com>
* Patch for step-ca.sh
Patch for making $STD happy (/usr/bin/step is a symlink to /usr/bin/step-cli)
* Refactor step-ca installation script
Refactor step-ca installation script to improve configuration and template handling.
- Carve out step-ca-admin.sh
- Patch for making $STD happy (/usr/bin/step is a symlink to /usr/bin/step-cli)
- Define enhanced x509 CA and Certificate Templates
- Configure CA Provisioners, DB and CRL settings
- Generate Root CA Certificate and Key
- Validity: 219168h (~25 Years)
- maxPathLen: 1 (Root -> Intermediate -> Leaf) => Only one Intermediate CA allowed below Root CA
- Active revocation on Intermediate CA and Leaf Certificates by the usage of build-in Certificate Revocation List (CRL)
- Generate Intermediate CA Certificate Bundle and Key
- Validity: 175368h (~20 Years)
- maxPathLen: 0 (Root -> Intermediate -> Leaf) => Intermediate CA is only allowed to issue Leaf Certificates
- Active revocation on Leaf Certificates by the usage of build-in Certificate Revocation List (CRL)
- Bundle: Certificate Chain (including Root CA Certificate)
* Update source URL in step-ca.sh script
* fix(dawarich): run db:migrate before assets:precompile
In Rails production, eager loading during assets:precompile can execute
DB queries. Dawarich 1.7.0 adds new tables (monthly digest email
preferences, S3 storage settings). Running precompile before migrate
causes 'Operation not permitted' / exit code 1 when those tables do
not exist yet.
Reordered to: db:migrate -> assets:precompile -> data:migrate,
which is the correct Rails deployment sequence.
Fixes#14048
* add otp key
Previously the update script only upgraded .NET when aspnetcore-runtime-8.0
or 9.0 was detected via is_package_installed. Containers where detection
failed would silently skip the upgrade block, leaving Technitium v15
(requires .NET 10) starting against .NET 8/9 and immediately failing.
Changed condition to: install .NET 10 unless it is already installed.
Old 8.0/9.0 packages are removed with || true to avoid errors on clean
installs.
Fixes#14045
The update was failing with 'mv: cannot stat /opt/2fauth-backup/.env:
No such file or directory' on a system where a previous run had left
/opt/2fauth-backup behind. mv would then nest /opt/2fauth inside the
existing backup directory (as /opt/2fauth-backup/2fauth/), so the
restore step looked at the wrong path.
After fixing that, the app returned a 500 ('Key path
file:///opt/2fauth/storage/oauth-public.key does not exist or is not
readable') because chown/chmod ran before composer install and
php artisan 2fauth:install, leaving vendor/, bootstrap/cache/* and
the regenerated oauth keys owned by root and unreadable by www-data.
- Remove any stale /opt/2fauth-backup before creating the backup, and
remove it again at the end so the next run starts clean
- Use cp instead of mv when restoring .env/storage so the backup is
preserved until the update completes
- Move chown/chmod to AFTER composer + artisan, matching the order in
install/2fauth-install.sh
- Restart php8.4-fpm in addition to nginx so opcache picks up the new
cached config
- Drop redundant quotes around literal paths to match the rest of the
codebase
Stop vmagent and vmalert services (if present) before deploying the
vmutils tarball during updates, and restart them afterward. Running
vmutils daemons (vmagent-prod, vmalert-prod) cause cp to fail with
ETXTBSY when their binaries are overwritten in /opt/victoriametrics.
Fixes#14014
