* Move the top 25 scripts onto the core engine
The engine work of the last few days reaches 30 of 561 ct scripts, about 5% of
ProxmoxVE traffic: retry on engine downloads, exit 227 instead of a misfiled
dpkg error, the umask fix that stops a hardened host producing containers apt
cannot resolve in, the TMPDIR guard, the toolchain restore. All of it has been
sitting where almost nobody runs it.
All eighteen at once rather than in waves. A slow rollout does not exercise the
paths only some scripts take, and broad exposure is what surfaces bugs -- a
deliberate call about release risk.
Checked before touching anything, because "migrate" meant far more than a line
swap last time:
- None of the eighteen has an alpine-* variant, so there is no merge to do.
- No script references misc/ outside its bootstrap line.
- Of the 61 functions that exist only in misc/, none is called by any of them.
So it is one line per script, and every head is now byte-identical to the ones
migrated earlier. With these, ProxmoxVE goes from 30 scripts on the core engine
to 48 -- and from roughly 5% of traffic to the majority, since these are the
ones people actually install.
Two to watch: immich sits at 44.7% success and vaultwarden at 42.1% before
this. If their numbers move, the engine is one of two changed variables rather
than the only one.
* Move update-apps onto the core engine
Entry 11 of the list and the only one that is not a ct script, so it was left
out of the previous commit. It is a host tool: it never used build.func at all,
it sources misc/core.func and misc/api.func directly.
The swap is therefore two lines rather than one, and worth checking rather than
assuming. It uses exactly five engine functions -- header_info,
init_tool_telemetry, msg_info, msg_ok, msg_error -- all present in the core, and
both files load standalone, which they had not had to do before: everywhere else
they arrive through build.func.
That completes the list. All 25 now run on the core engine.
Fixing this one matters beyond the migration: update-apps is what drives
unattended updates across every container on a host, and it is the path where
PHS_SILENT was being ignored (#16593). It now gets the engine that honours it.
* netbox: serve on plain HTTP too, port 80 forced HTTPS redirect broke reverse proxies
* Update netbox-install.sh for Apache configuration
Modify Apache configuration to serve NetBox on port 80.
* Set default ProxmoxVE raw URL in UPS script
Define `_CS_DEFAULT_URL` at the top of `ct/pve-ups.sh` and remove the outdated bootstrap comments, aligning the script with the newer URL-default pattern used for script sourcing.
* Branch var_cpu by OS where the two variants actually differ
The merged scripts branch var_ram, var_disk and var_version on var_os but
left var_cpu above the branch, so both variants inherited the Debian value.
On Vaultwarden that meant an Alpine container was told it wanted four cores
for an update that runs apk and restarts a service.
Only seven scripts are affected. Comparing each merged script against the
alpine-* script it replaced, 22 of the 29 already had the same CPU count on
both sides, so moving the line there would be churn with no behaviour change.
These seven did not:
docker, forgejo, ironclaw, syncthing, transmission, zigbee2mqtt 2 -> 1
vaultwarden 4 -> 1
The Alpine values are the ones those scripts carried before the merge, read
back out of the deleted alpine-* files rather than picked. The Debian arm
keeps what it has now.
Needs the matching core change: until build.func derives var_os inside a
container, an update never reaches the Alpine arm at all.
* fix: source url
* Update script to source build functions from URLs
---------
Co-authored-by: Tobias <96661824+CrazyWolf13@users.noreply.github.com>
DocuSeal switched to its own PDFium fork (upstream commit "adjust pdfium",
2026-08-15) and now attaches functions that only exist in that build, e.g.
FPDFPage_GetAnnotCountRaw from the added fpdf_annots_raw.h. The generic
bblanchon/pdfium-binaries library the script installed does not export them,
so lib/pdfium.rb raises FFI::NotFoundError while Rails eager-loads and both
docuseal.service and docuseal-sidekiq.service fail to start:
Unable to load application: FFI::NotFoundError: Function
'FPDFPage_GetAnnotCountRaw' not found in [libpdfium.so]
Install the library from docusealco/pdfium-binaries instead, matching the
upstream Dockerfile. It is only published as a musl build (DocuSeal's image is
Alpine based), so the musl runtime is installed and its library directory is
added to the loader search path - the shared object needs "libc.so" (musl) at
dlopen time. Verified on glibc: the library loads, resolves the raw annotation
functions and renders pages correctly.
The update path now refreshes PDFium too, so existing containers are repaired
by running "update" even when DocuSeal itself is already up to date.
* Skip mount points during backup and clean install
Prevent accidental deletion or backup of mount points:
- In create_backup(), skip paths that are mount points with a warning
- In _deploy_source_tarball(), _deploy_unpacked_archive(), and fetch_and_deploy_from_url(), use find with mountpoint pruning to avoid deleting mount point directories during CLEAN_INSTALL
* change comments for new variant
Update `_deploy_source_tarball` and related helper comments to note that CLEAN_INSTALL wipes target contents including dotfiles while preserving mount points. This improves guidance around backup/restore of config dotfiles during source deployments.
* networkoptimizer: mitigate dotnet publish hang in LXC
* Optimize networkoptimizer.sh by removing duplicate restore
Removed redundant restore_backup call after deployment.
* Clean up comments in networkoptimizer-install.sh
Removed comments about MSBuild issues in the installation script.
* Let docker-install.sh take its three answers up front
The script asked three questions with no way to answer them in advance,
so a Docker container could not be deployed unattended: Portainer, the
Portainer Agent, and whether to expose the TCP socket.
Each now reads a variable and prompts only when it is unset, the same
shape install/forgejo-runner-install.sh already uses:
var_portainer yes | no
var_portainer_agent yes | no
var_docker_socket n | l (127.0.0.1) | a (0.0.0.0)
Interactive behaviour is unchanged — with nothing set, all three still
ask exactly as before.
The matching declaration for the script's PocketBase record, which the
website generator reads to offer these as form fields:
"app_vars": [
{"name":"var_portainer","label":"Install Portainer","type":"boolean","default":"no"},
{"name":"var_portainer_agent","label":"Install Portainer Agent","type":"boolean","default":"no",
"help":"Only used when Portainer itself is not installed"},
{"name":"var_docker_socket","label":"Expose Docker TCP socket","type":"select",
"options":["n","l","a"],"default":"n",
"help":"l = 127.0.0.1 only, a = all interfaces (insecure)"}
]
CONTRIBUTING.md documents the convention so the next script follows it.
* Let docker-install.sh take its three answers up front
The script asked three questions with no way to answer them in advance,
so a Docker container could not be deployed unattended: Portainer, the
Portainer Agent, and whether to expose the TCP socket.
Each now reads a variable and prompts only when it is unset, the same
shape install/forgejo-runner-install.sh already uses:
var_portainer yes | no
var_portainer_agent yes | no
var_docker_socket n | l (127.0.0.1) | a (0.0.0.0)
Interactive behaviour is unchanged — with nothing set, all three still
ask exactly as before.
The matching declaration for the script's PocketBase record, which the
website generator reads to offer these as form fields:
"app_vars": [
{"name":"var_portainer","label":"Install Portainer","type":"boolean","default":"no"},
{"name":"var_portainer_agent","label":"Install Portainer Agent","type":"boolean","default":"no",
"help":"Only used when Portainer itself is not installed"},
{"name":"var_docker_socket","label":"Expose Docker TCP socket","type":"select",
"options":["n","l","a"],"default":"n",
"help":"l = 127.0.0.1 only, a = all interfaces (insecure)"}
]
CONTRIBUTING.md documents the convention so the next script follows it.
* Let forgejo-runner and pangolin take their answers up front
forgejo-runner already exported two of the three values its install
script requires, but not var_forgejo_runner_uuid — so an unattended
install passed the ct-level guard and then stopped at a prompt inside
the container, which is the one place nobody can answer it. The guard
missed it for the same reason.
pangolin asked for its URL and email with no way to supply them. Both
sides are needed: the read in install/ now only fires when the variable
is unset, and ct/ exports it, because lxc-attach carries the caller's
environment but only what was exported.
Reverts the docker change from the previous commit; it is superseded by
work on another branch.
* Teach the PocketBase workflows the capability fields
All three wrote fields the site no longer reads. The slash bot and the
AI bot accepted has_arm=true and github=owner/repo; push-json mapped
has_arm into the payload. After the schema change those writes would
have gone to columns that are not there.
architectures and platforms are multi-selects over a closed set, so
both bots reject an unknown value instead of storing it — the same
guarantee the field type gives in the admin UI.
push-json still reads has_arm when architectures is absent, because
ProxmoxVED's json files carry the old key until they are converted.
* Drop the docker change again
It came back through the merge in 35735dae: the branch was pushed
before the revert, so merging the remote copy restored it. Removing it
forward rather than rewriting history that is already published.
* 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.
* remove portainer from tools.func
* remove comment in tools.func and remove portainer from docker setup
* remove portainer from alpine-docker
* formatting alpine docker
* remove portainer update in docker ct and homeassistant
* Add host CA inheritance for container builds
Introduces `var_inherit_host_ca` (default `auto`) across variable loading, validation, defaults, and persisted app vars. The advanced settings flow now includes a dedicated Host CA Inheritance step and surfaces the selection in the final summary.
Adds `_apply_host_ca_certs_in_container()` to copy host certificates from `/usr/local/share/ca-certificates/*.crt` into the container and refresh trust with `update-ca-certificates` when available. This runs during container setup after proxy configuration, with safe no-op behavior when no host certs exist or inheritance is disabled.
* Warn when host CA inheritance is disabled
Changes the log level from info to warning when host CA inheritance is skipped by configuration, and includes the number of host certificates detected. This makes intentional skips more visible while still showing useful context.
* core: make host CA inheritance opt-in (default no)
Addresses review feedback: default to 'no' instead of 'auto' so certs are
only inherited when explicitly enabled in advanced mode, preserving LXC
isolation by default.
---------
Co-authored-by: michel.roegl-brunner@htl-braunau.at <michel.roegl-brunner@htl-braunau.at>
* Harden remote func bootstrapping
Replace bare `source <(curl ...)` calls with a `_bootstrap_source` helper that validates both the download exit code and the presence of a probe function after sourcing. This prevents silent failures when DNS is not yet available in a freshly booted container or when a download fails mid-stream. Applies to build.func, install.func, and alpine-install.func. Also adds retry flags and a connect timeout to curl/wget.
* Refactor bootstrap error handling with helper
Extract repeated fatal-error logic into a `_bootstrap_die` helper across alpine-install.func, build.func, and install.func. The helper uses `msg_error` when available, falling back to stderr, then exits with code 115. Inline error blocks are replaced with cleaner one-liner `|| _bootstrap_die` calls.
* Bump GitHub Actions across workflows
Update workflow dependencies to newer major versions in repository automation files. This upgrades `actions/checkout` to v7, `actions/github-script` to v9, `actions/create-github-app-token` to v3, and GitHub Pages actions (`upload-pages-artifact` and `deploy-pages`) to v5 to keep CI/CD and maintenance workflows current.
* add dependabot for gh actions
* Pin Vikunja install/update to v2.3.0
Set both install and update scripts to deploy Vikunja v2.3.0 instead of latest. The update flow now checks against this pinned release and includes context that v2.4.0 is temporarily avoided due to an upstream startup failure caused by the packaged systemd SystemCallFilter.
* minor fix
Clarify the upgrade prompt options in `create_lxc_container`, treat empty or unrecognized input as ignore instead of implicit cancel, and explicitly abort container creation when the user chooses Cancel.