2d24a764a8
Two mechanical sweeps, no behaviour change on a single-root install. The 14 `[[ "$p" == "$containers_dir"* ]]` prefix tests that decide manager-vs-container-user elevation become pathIsContainerData, so a file on a second storage root is no longer misclassified as manager-owned — which would have written it with the wrong owner and failed later, far from the cause. The 65 references to the WebUI's own tree become webuiDir(), which is pinned to the primary root by design. Two traps found while doing it: run_privileged.sh is sourced directly by init.sh without paths.sh, so it needs a fallback. Defining one named pathIsContainerData was wrong: generate_function_manifest.sh indexes top-level definitions, and the resulting autoload stub would have shadowed the real multi-root implementation with the primary-only fallback — silently classifying every file on a second disk as manager-owned, which is exactly the bug this sweep exists to prevent. Renamed to _runCfgIsContainerPath, which delegates when the real one is loaded. setup_lock.sh built its path in a top-level assignment, so it was evaluated at source time and needed the file flagged eager. Made it a function instead: the path resolves on call, and the file drops off LP_EAGER_FILES entirely. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
45 lines
2.3 KiB
Bash
Executable File
45 lines
2.3 KiB
Bash
Executable File
#!/bin/bash
|
|
|
|
installLibrePortalImageWebUI()
|
|
{
|
|
isHeader "LibrePortal WebUI Image"
|
|
|
|
isNotice "Building the LibrePortal WebUI Docker image..."
|
|
|
|
# The copy below writes into the dockerinstall-owned containers root. On a
|
|
# fresh install the general traversal/ownership reconcile runs LATER, so at
|
|
# this point the system root is still 750 (untraversable by the container user)
|
|
# and the containers root may still be manager-owned — the copy would fail.
|
|
# Establish traversal + containers-root ownership FIRST.
|
|
fixFolderPermissions
|
|
|
|
# A previous run that started the container before its config landed leaves
|
|
# libreportal.config as a Docker-created directory. The tar copy below can't
|
|
# extract a file over a directory ("Cannot open: File exists") and aborts the
|
|
# whole source copy, so clear the stub first.
|
|
repairStubDirForFile "$(webuiDir)/libreportal.config" "loud"
|
|
|
|
local result; result=$(copyFolder "$install_containers_dir/libreportal" "$containers_dir" "$sudo_user_name")
|
|
checkSuccess "Copy the LibrePortal to the containers folder"
|
|
|
|
reconcileWebuiDirOwnership
|
|
|
|
# copyFolder just restored the TEMPLATE docker-compose.yml, which carries raw
|
|
# #LIBREPORTAL|TAG|VALUE placeholders. On a fresh install the following
|
|
# dockerInstallApp (installLibrePortalAppWebUI) substitutes them; but on a
|
|
# REBUILD/update (libreportal already installed — this also runs via the WebUI
|
|
# deploy) nothing else does, leaving the at-rest compose unparseable by a plain
|
|
# `docker compose` (e.g. "invalid boolean: HEALTHCHECK_DATA"). Re-apply the tag
|
|
# processors here — the same self-heal up_app.sh uses — so the runtime compose
|
|
# is always fully substituted at rest, not just when started via the CLI.
|
|
if declare -F dockerConfigSetupFileWithData >/dev/null 2>&1 \
|
|
&& [[ "$(dockerCheckAppInstalled libreportal docker)" != "not_installed" ]]; then
|
|
initializeAppVariables libreportal >/dev/null 2>&1 || true
|
|
dockerConfigSetupFileWithData libreportal >/dev/null 2>&1 || true
|
|
checkSuccess "Re-applied LibrePortal WebUI compose tag substitutions"
|
|
fi
|
|
|
|
isNotice "Building libreportal-service image, this may take a while..."
|
|
local result; result=$(runFileOp docker build -t libreportal-service -f $(webuiDir)/Dockerfile $(webuiDir) >/dev/null 2>&1)
|
|
checkSuccess "Built LibrePortal WebUI Docker image"
|
|
} |