* RustDesk Server: run the official server, make the web UI optional
lejianwen/rustdesk-server has had no commit since 2025-09-01 and is 45
commits behind upstream, missing the UDP reflection/amplification and
mio security fixes. hbbs, hbbr and utils now come from
rustdesk/rustdesk-server; the packages and units are the same, so
existing installs upgrade in place and keep their keys.
lejianwen/rustdesk-api is unmaintained as well and becomes an opt-in
prompt. When chosen it is configured with this server's IP and key
instead of its 192.168.1.66 defaults, and Debian gets an admin password
like Alpine did. ~/rustdesk.creds now always holds the server key, and
the API is only updated where it is installed.
* RustDesk Server: answer the web UI prompt with var_rustdesk_api
yes or no skips the question, so unattended installs can choose; unset still asks.
* RustDesk Server: write the creds file with heredocs
Matches how the other install scripts write their creds; the file is unchanged.
* Caddy: install the .deb from GitHub instead of the Cloudsmith repo
Cloudsmith answered 402 Payment Required for two days once Caddy's
bandwidth quota ran out, and upstream expects it to happen again
(caddyserver/dist#142). Each GitHub release carries the identical
package (same SHA256), so Debian installs it from there now. The update
drops the Cloudsmith source, seeds ~/.caddy from the installed package
so nothing is reinstalled, and keeps a customised Caddyfile.
* Remove outdated comment from caddy.sh
---------
Co-authored-by: Tobias <96661824+CrazyWolf13@users.noreply.github.com>
Thirty-six yes/no prompts for optional components in 26 install
scripts could only be answered at the terminal, so an unattended
install stopped at the first one. Each now takes var_<app>_<option>
first and still asks when it is unset. The four conditions that only
matched a single y now take yes as well, since that is what the website
sends.
The thirteen install scripts and two update paths that run an external
installer each carried the same warning and y/N read. The core helper
does the same and also takes var_external_installer, so unattended
installs can answer it. Needs community-scripts/core
feat/confirm-external-installer merged first.
* hermesagent: match the relaunched root gateway regardless of interpreter
Upstream now starts the gateway through its bundled python via runpy, so
the venv-path pattern from #17126 matched nothing and the root gateway
survived; its writes then raced chown -R and aborted the update.
* Clean up comments in hermesagent.sh
Removed comments regarding hermes update and matching patterns.
* Radicale: install the bcrypt and argon2 extras
The update replaces pyproject.toml and the venv, so a bcrypt or argon2
module added by hand was gone afterwards and Radicale refused to start
with htpasswd_encryption = bcrypt, argon2 or autodetect. The service now
runs uv with --extra bcrypt --extra argon2, which upstream already
defines. The update patches existing units and restarts the service.
* Radicale: enable the extras only once the code defines them
argon2 is an extra since v3.5.4 and uv refuses unknown extras, so patching
before the release update broke older installs. Patch after it instead,
and only when pyproject.toml defines the extra.
* docker: take the lxcfs toggle, TCP socket and Compose choice from app variables
var_docker_lxcfs is exported for the core helper; var_docker_tcp_socket
(no/local/all) and var_docker_compose replace the prompts when set, so
the website generator can offer them. Alpine wrote daemon.json through
silent(), which captured the output and left the file empty.
* docker: use var_docker_socket, the name the catalog record already carries
The update path chowned a hardcoded /opt/paperclip-data and always moved
root-run services to a dedicated user. Installs that keep their data
elsewhere (for example an NFS bind mount reachable only by root) failed
with "chown: cannot access '/opt/paperclip-data'" after the rebuild, and a
non-root user could not have reached that data anyway.
Read PAPERCLIP_HOME from the install's .env. Keep the service as root when
it points somewhere other than /opt/paperclip-data, and only chown
/opt/paperclip-data when it is the configured data dir and exists.
Co-authored-by: root <root@paperclip.pilz.dev>
Co-authored-by: Claude <noreply@anthropic.com>
v2.0.0 reads the config strictly and stops at the v1 keys the addon
wrote (server.port, conditionals, indexingIntervalMinutes). It also only
imports the old BoltDB when server.database.migrateFrom names it and no
database.db is left in the working directory. The update now rewrites
the config, renames the database and points migrateFrom at it, keeping
a copy of the v1 config. New installs write the v2 layout.
Collabora 26.04.4 ignores frame-ancestors set in content_security_policy,
so the editor iframe is blocked. Use net.frame_ancestors (as
opencloud-compose does) on install, and add it on update when missing.
* Immich: survive an interrupted update and a failing ML build
An update cancelled midway leaves /opt/immich/app empty, and the next run
died at once on cd /opt/immich/app/bin to enable maintenance mode (#17796).
Maintenance mode is now only toggled when immich-admin exists.
uv sync fetching the ml-models git dependency failed with "Could not resolve
host" behind DNS filters such as AdGuard while DNS itself worked (#17797);
running uv one download at a time got through. Retries now do that.
If machine learning still cannot be built, the update no longer stops with
maintenance mode on and every service down: it finishes, starts the web
service, puts the previous version back into ~/.immich so the next update
retries, and exits with an error. Updates are also announced as taking
5-15 minutes, since the first report came from cancelling one that looked
stuck.
* Immich: point immich-ml at the moved ml_start.sh and clear failed units
The update moves ml_start.sh into app/machine-learning, but only rewrote
immich-web's ExecStart, so older containers kept starting ML from
/opt/immich/ml_start.sh and failed with 203/EXEC. Rewrite immich-ml the same
way. A crash loop before the update can also leave both units rate-limited,
which makes the final restart fail; reset them first.
* Add localai (ct)
* Refactor localai.sh to clean up comments and exports
Removed comments regarding ARM64 support and clarified install script export variables.
* Refactor variable assignments and clean up comments
Rearranged variable assignments and removed comments about SQLite and PostgreSQL.
---------
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>
The build-debian tarballs of v2.3.0 carry the Alpine build of
better_sqlite3.node, so the DB migration dies with ERR_DLOPEN_FAILED on
libc.musl and Homarr no longer starts after an update (#17783,
homarr-labs/homarr#7097). When the bundled module is musl, swap in
better-sqlite3's own glibc prebuild for the running Node ABI. The update runs
the check outside the release check, so containers already on 2.3.0 are
repaired too; it does nothing once upstream ships a correct tarball.
