singlefile mode writes the asset to <target>/<app name>:
local target_file="$app"
[[ "${USE_ORIGINAL_FILENAME:-false}" == "true" ]] && target_file="$filename"
so with the app renamed to Scanopy the binary lands at /usr/bin/Scanopy
while the unit starts /usr/bin/scanopy-server, and the service never
comes up on a fresh install. Rename it after the deploy, the same way
the daemon block already renames "Scanopy Daemon".
Keeping the app name is what matters here: it is also the version file
(~/.scanopy), and changing it would make every existing container
report an update it does not need.
The health check put the previous binary back but nothing else, and the
source tree it needs was already gone by then: the update deleted
/opt/scanopy/ui before starting the new server, and removed
SCANOPY_WEB_EXTERNAL_PATH from the env at the same time. A failed
health check therefore left the old binary running without the UI it
serves from disk, so the rollback produced an API-only server.
Back up the env file and the unit alongside the binary, restore all
three when the check fails, and delete the source tree only once the
new server has answered. Nothing the old version needs is removed
before the new one has proven itself.
Upstream confirmed in scanopy/scanopy#698 that scanopy-server-linux-*
has carried the built UI since v0.17.13, fixtures and service logos
included, served on the same port as the API. The release notes never
said so, which is why we kept building it.
That removes the source tarball, the Rust toolchain and
generate-fixtures, Node with npm ci and npm run build, and
SCANOPY_WEB_EXTERNAL_PATH. With the variable set to a directory that no
longer has an index.html, v0.17.14 and earlier refuse to start, so the
update deletes the line rather than leaving it. build-essential,
libssl-dev and pkg-config go too: the release binary is static-pie with
no INTERP segment, so it has no runtime library dependencies.
/opt/scanopy stays, now only for .env and oidc.toml, and the unit's
WorkingDirectory follows it out of the removed backend directory. Since
nothing wipes that directory any more, the config survives an update on
its own, which is the report upstream passed on of an update coming
back without SCANOPY_WEB_EXTERNAL_PATH and the server starting API-only.
The update keeps the running binary until the new one answers
/api/health and puts it back if it does not, so a bad release leaves a
working server instead of a stopped one.
check_for_gh_release now keys on scanopy-server, matching the version
file the binary deploy writes; the Scanopy key belonged to the tarball
that is gone. Existing containers run one extra update, then agree.
Adds five optional var_jitsi_* settings to the install script. All default
to empty, which keeps the previous LAN-only behaviour (container IP,
self-signed certificate):
- var_jitsi_domain public hostname instead of the container IP
- var_jitsi_le_email Let's Encrypt via the packaged debconf option
- var_jitsi_public_ip static NAT mapping in jvb.conf (JVB 2.3+)
- var_jitsi_admin_user secure domain: only authenticated users create rooms
- var_jitsi_admin_pass password for that user (generated when empty)
Tested on Proxmox VE 9.2 as unprivileged Debian 13 LXC, both with all
variables set (self-signed) and with none set.
Co-authored-by: klanghans <13657862+klanghans@users.noreply.github.com>
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
* Add gotenberg (ct)
* Update messages in gotenberg.sh for clarity
* Implement unoconverter update in gotenberg.sh
* Fix formatting and add Go version setup in script
* Update Gotenberg installation script for Go version
---------
Co-authored-by: push-app-to-main[bot] <203845782+push-app-to-main[bot]@users.noreply.github.com>
Co-authored-by: Tobias <96661824+CrazyWolf13@users.noreply.github.com>
