Updated eligibility requirements for project requests in the discussion template, clarifying the criteria for self-hosting, repository stars, and project age.
Server updates no longer abort on 401 or unreachable API; users can force deploy when security is enabled or the app is down. Node installs now pass --server during systemd setup, and Node updates skip the server-only API.
Add optional tag prefix filtering to GitHub/GitLab release helpers and use web-v2 for Storyteller install/update so latest non-web tags no longer break deployment.
* Update tools.func
- Add _TOOLS_FUNC_LOADED guard to prevent double-sourcing
- Remove duplicate is_alpine() (core.func version is more robust)
- Fix end_timer: now actually outputs duration (was silent)
- Fix SQL injection in setup_mariadb_db: escape single quotes in identifiers
- Fix SQL injection in setup_postgresql_db: escape single quotes in identifiers
- Fix sed injection in edit_yaml_config: escape | and & in value
- Fix command injection in curl_with_retry: use array instead of string eval
- Fix command injection in curl_api_with_retry: use array instead of string eval
* Update misc/tools.func
Co-authored-by: Sam Heinz <sam@samheinz.com>
---------
Co-authored-by: Sam Heinz <sam@samheinz.com>
* fix(hyperion): keep service running after container reboot
The packaged hyperion@.service declares "Requisite=network.target" but is
not ordered After=network.target. Inside an LXC the unit's start job can be
evaluated before network.target is active, and because Requisite= is stricter
than Requires= (it does not pull the unit in or wait for it) the job fails
with "Dependency failed", so Hyperion does not start after a reboot.
Add a systemd drop-in that clears Requisite=; ordering is still provided by
the base unit's Wants=/After=network-online.target.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Fix Hyperion service startup issue in LXC
Remove Requisite from Hyperion service to ensure it starts correctly in LXC environments.
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: CanbiZ (MickLesk) <47820557+MickLesk@users.noreply.github.com>
* fix(fileflows): install .NET 10 ASP.NET Core Runtime to match current release
FileFlows now ships its server/node binaries targeting .NET 10
(Microsoft.NETCore.App 10.0.0), but the install script still installs the
ASP.NET Core Runtime 8.0. On a fresh install the app therefore cannot start:
You must install or update .NET to run this application.
Framework: 'Microsoft.NETCore.App', version '10.0.0' (x64)
The following frameworks were found:
8.0.28 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]
so "dotnet FileFlows.Server.dll --systemd install" fails with exit code 150
(service failed to start) and the container aborts (issue #15686).
Bump the runtime to 10.0 on both branches: aspnetcore-runtime-10.0 from
packages.microsoft.com on amd64 (the same repo and package already used by
igotify, rdtclient and technitiumdns) and dotnet-install --channel 10.0 on
arm64.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(fileflows): ensure current .NET runtime on update too
An existing install set up under an older .NET (e.g. aspnetcore-runtime-8.0)
would download a newer FileFlows on update but keep the old runtime, failing to
start with the same framework-not-found error. Mirror the runtime handling used
by technitiumdns/rdtclient in update_script.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
AdventureLog's frontend install runs a bare `pnpm i`. On pnpm v10+, build
scripts of dependencies (esbuild, es5-ext, svelte-preprocess) are ignored by
default and pnpm aborts with ERR_PNPM_IGNORED_BUILDS (exit 1), so the install
never reaches `pnpm build`. The shipped frontend/pnpm-workspace.yaml already
pins esbuild, so those builds are expected to run.
Enable the builds for this app only by appending `dangerouslyAllowAllBuilds:
true` to the frontend's pnpm-workspace.yaml before `pnpm i`, in both the install
and update paths. The change is guarded so it is not duplicated on re-run, and
it is scoped to AdventureLog (which ships no onlyBuiltDependencies) to avoid the
global config conflict that a repo-wide setting would cause.
Fixes#15670
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
CanbiZ (MickLesk)