8b5e02c760
The main sweep — ~260 call sites across ~100 files move from string
concatenation on a single root to appDir/storageAppDirs/storageAppConfigs.
On a single-root install the resolved paths are identical, so this is a
no-op until a location is registered.
Enumerators were the interesting half. `for d in "$containers_dir"/*/`
appears in the menus, the registry/artifact scanners and the DNS setup —
and a shell glob cannot list a rootless 751 tree at all, which is the
same bug config_find_file.sh already documents in a comment. Routing them
through storageAppDirs (which enumerates as the owning user) fixes that
alongside the multi-root work.
Three places needed judgement rather than substitution:
db_app_scan.sh deletes database rows and port allocations for apps whose
folder is missing, and reaps "empty" app dirs. With a storage location
unmounted, every app on it looks exactly like that. Each of those
branches now gates on appStorageAvailable first — an app on an unplugged
drive is skipped with a notice, never deleted.
instance_create.sh rewrites cloned hooks so an instance touches its own
directory instead of the base app's. Its sed matched ${containers_dir}<type>,
which this sweep just replaced with $(appDir <type>) — so it would have
silently stopped redirecting, and an instance would have written to the
original's files (the adguard auth adapter case its own comment warns
about). Now matches both appDir forms, verified against bare, quoted,
unrelated-app, legacy and prose cases.
peer_shell/peer_pull streamed and extracted relative to the primary root.
Both now use the app's own root, and peer_shell keeps a single-root
fallback since it runs as a restricted SSH shell with no LibrePortal env.
Also fixes a pre-existing bug found on the way: webui_app_config.sh
tested "$containers_dir/frontend/data/last_update", one level short of the
real tree under the libreportal app dir, so the WebUI refresh trigger
after a config update has never once fired.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
62 lines
3.0 KiB
Bash
62 lines
3.0 KiB
Bash
#!/bin/bash
|
|
|
|
# Prometheus install hooks — drop the prometheus.yml template alongside the
|
|
# compose, and 0777 the storage dirs so the container can write its TSDB
|
|
# regardless of the host UID mapping.
|
|
|
|
prometheus_install_post_compose()
|
|
{
|
|
local app_name="$1"
|
|
|
|
local result
|
|
result=$(createFolders "loud" $docker_install_user "$(appDir "$app_name")/$app_name")
|
|
checkSuccess "Created $app_name folder in $app_name"
|
|
|
|
result=$(createTouch "$(appDir "$app_name")/$app_name/$app_name.yml" $docker_install_user)
|
|
checkSuccess "Created $app_name.yml file for $app_name"
|
|
|
|
result=$(copyResource "$app_name" "$app_name.yml" "$app_name" | runInstallWrite -a "$logs_dir/$docker_log_file" 2>&1)
|
|
checkSuccess "Copying $app_name.yml to containers folder."
|
|
}
|
|
|
|
prometheus_install_post_start()
|
|
{
|
|
local app_name="$1"
|
|
|
|
if [ -f "$(appDir prometheus)/prometheus/prometheus.yml" ]; then
|
|
updateFileOwnership "$(appDir prometheus)/prometheus/prometheus.yml" $docker_install_user $docker_install_user
|
|
fi
|
|
# Prometheus runs as nobody (65534) inside the container, which rootless maps
|
|
# to a subuid outside this user's authority (65534 -> 296605 here). Two
|
|
# different needs, and the old blanket `chmod -R 777` on both got the second
|
|
# one wrong:
|
|
#
|
|
# prometheus/ config, READ-only to the container. a+rX is enough — world
|
|
# WRITE on a config the container obeys is not something to
|
|
# hand out, and -R is safe here because nothing but LibrePortal
|
|
# writes this dir. go-w is included so the fix actually lands on
|
|
# installs the old 777 already touched: a+rX only ADDS bits, so
|
|
# without it every existing prometheus.yml stays world-writable
|
|
# by any local user. Everything here is written through
|
|
# runFileOp — i.e. by the owner — so owner-write is all it needs.
|
|
#
|
|
# prom_data/ the container's own store. It needs write on the DIRECTORY to
|
|
# create prom_data/data on first boot; everything under that is
|
|
# created by, and belongs to, prometheus itself. Recursing into
|
|
# it meant chmod'ing files owned by 296605 as the docker install
|
|
# user: "Operation not permitted" per file and a failed step on
|
|
# every REINSTALL (a fresh install passed only because the dir
|
|
# was still empty). Those files must keep prometheus's ownership
|
|
# anyway — that is what lets it write them.
|
|
if [ -d "$(appDir prometheus)/prometheus" ]; then
|
|
local result
|
|
result=$(runFileOp chmod -R a+rX,go-w "$(appDir prometheus)/prometheus")
|
|
checkSuccess "Set permissions to prometheus folder."
|
|
fi
|
|
if [ -d "$(appDir prometheus)/prom_data" ]; then
|
|
local result
|
|
result=$(runFileOp chmod 0777 "$(appDir prometheus)/prom_data")
|
|
checkSuccess "Set permissions to prom_data folder."
|
|
fi
|
|
}
|