* Pin NextCloudPi installer to last known-good stable release
The floating "master" branch of nextcloud/nextcloudpi's install.sh
started rejecting our default Debian 12 base with "distro not
supported" (#15944) after a regression landed upstream; the script
is third-party code we don't audit or control. Pin to v1.57.1, the
latest stable (non-prerelease) release, which explicitly targets
Debian bookworm and predates the regression.
* Actually pin the branch nextcloudpi's install.sh clones internally
install.sh is only a thin bootstrapper: it clones BRANCH (default
"master") of the nextcloudpi repo itself and runs the real installer
from that fresh checkout, including the distro-support check. Fetching
install.sh from a pinned tag alone left BRANCH defaulting to "master",
so the internally-cloned code was unaffected and still failed with
"distro not supported" - confirmed by testing the previous fix. Pass
BRANCH explicitly so the internal clone also targets the pinned tag.
* Bump NextCloudPi to Debian 13, matching upstream's trixie move
Upstream's master ncp.cfg now targets release "trixie" (Debian 13);
bookworm (Debian 12) is no longer in the supported check_distro list
at all. Move our own default to Debian 13 and pin the installer ref
to v1.58.0-rc1, the only tagged ref with release=trixie so far (no
stable trixie release exists yet upstream).
* Revert installer pin, track master again
master now targets trixie itself (matches the Debian 13 bump), and
the only tagged trixie ref was an RC explicitly marked "expect bugs".
Tracking master gets upstream trixie fixes as they land instead of
being stuck on a stale test release.
* Work around nextcloudpi's broken ssh.socket restart on Debian 13
Debian 13's openssh-server ships socket-activated by default. NCP's
own bin/ncp/NETWORKING/SSH.sh detects that (systemctl is-active
ssh.socket) but then runs "systemctl restart ssh" in that branch
instead of reloading, which collides with the port ssh.socket already
holds and fails with "Job for ssh.service failed" (#15944). Switch the
container to classic ssh.service before handing off to their
installer so it takes the safe "systemctl reload ssh" branch instead.
* fix(error-handler): prevent silent() from re-enabling error handling during recovery
Root cause: silent() (core.func) unconditionally calls set -Eeuo pipefail
and trap 'error_handler' ERR after every command. When build_container()
intentionally disables error handling for its recovery section, any
intermediate call through silent()/ re-enables it. This causes the
grep/sed pipeline for missing_cmd extraction to trigger error_handler
(grep returns exit code 1 on no match + pipefail = fatal).
Fixes:
1. silent(): Save errexit state before disabling, only restore if it was
active. Callers that intentionally disabled error handling (e.g.
build_container recovery) are no longer silently re-enabled.
2. build.func: Add || true to missing_cmd grep pipeline as defense-in-depth
against pipeline failure propagation.
3. build.func: Add explicit set +Eeuo pipefail / trap - ERR after
post_update_to_api() call, before error classification grep/sed section.
4. build.func: Remove stale global combined_log variable from variables()
that used a different path format (/tmp/install-SESSION-combined.log)
than the actual local variable (/tmp/NSAPP-CTID-SESSION.log). The global
was never written to and caused confusion when error_handler displayed it.
* Update build.func
* chore(install): add Github source links to all setup_nodejs scripts
52 install scripts had a project website in '# Source:' but no GitHub
link. Merged the GitHub repo URL into the Source header as:
# Source: https://website.com/ | Github: https://github.com/OWNER/REPO
Repos sourced from fetch_and_deploy_gh_release calls, get_latest_github_release
calls, or known project repos for npm/pip installed apps.
Two scripts (fumadocs, pve-scripts-local) had no Source line at all —
added one. Shinobi skipped (GitLab-only, no GitHub repo).
* chore(install): add Github source links to all fetch_and_deploy scripts
77 additional install scripts had fetch_and_deploy_gh_release calls but
no GitHub link in the Source header. Merged the primary app repo into
the Source header as:
# Source: https://website.com/ | Github: https://github.com/OWNER/REPO
Where multiple fetch_and_deploy calls existed (app + dependency), the
primary app repo was selected:
- ersatztv: ErsatzTV/ErsatzTV (not ffmpeg)
- firefly: firefly-iii/firefly-iii (not data-importer)
- komga: gotson/komga (not kepubify dep)
- sabnzbd: sabnzbd/sabnzbd (not par2cmdline-turbo dep)
- signoz: SigNoz/signoz (not otel-collector)
- tunarr: chrisbenincasa/tunarr (not ffmpeg dep)
Also fixed cosmos-install.sh double https:// in Source URL.
Skipped: autocaliweb (source already on codeberg, GitHub repos are deps only)
* revert: restore misc/build.func and misc/core.func to main state
These error-handler fixes belong to fix/error-handler-recovery, not to
this sources-only branch.
* chore(ct,tools): sync Source headers with install/ and add Github links to addon scripts
* Update ALL CT's to new default
* Minor Changes
* Merge Bookstack from main
* Indention Bookstack
* Merge Vikunja from Main
* Merge Komga from Main
* Merge Unifi from Main
- The option to utilize Apt-Cacher-NG (Advanced settings) when creating LXCs. The added functionality is expected to reduce bandwidth usage and provide faster operating system updates.
- Requires the Apt-Cacher-NG LXC
CanbiZ (MickLesk)