2 Commits

Include renames

Author	SHA1	Message	Date
ChuckandClaude Opus 5	e75b99f787	fix(update): let the root pip wrapper install web_interface/requirements.txt ... Update Code, the automatic update's health check and Install Base Requirements install web_interface/requirements.txt through safe_pip_install.sh, which only allowed the root requirements.txt. The first commit changing that file would fail its dependency install, and the automatic updater rolls back any update whose dependencies did not install -- on every device, for every newer commit. The wrapper now lists both core requirement files. Only their folders are resolved, so a requirements.txt symlinked out of the project is compared by its target and refused (previously the root file's own symlink target was what got allowed). The updater's file list is a named constant, and a test runs the real wrapper (pip stubbed) on every file Update Code and the rollback install. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-17 08:50:33 -04:00
ChuckandClaude Sonnet 5	cbb8ec41e8	Fix: plugin/base requirements installed as web-user, invisible to root-run display service (#380) ... * fix: install plugin/base requirements as root so ledmatrix.service can see them ledmatrix-web.service runs as a non-root user, so "Reinstall plugin requirements" installed packages into that user's ~/.local site-packages. ledmatrix.service (the actual display, which loads and runs plugin code) runs as root and can't see another user's user-site packages, so plugins with dependencies not already present system-wide would silently fail at runtime with ModuleNotFoundError even after a "successful" reinstall. Reproduced and fixed live against a real device (weather plugin's astral dependency, used for moon-phase data): confirmed the exact failure ("No module named 'astral'" on every almanac cycle) and confirmed it's gone after this fix. Adds scripts/fix_perms/safe_pip_install.sh, a root-owned wrapper (mirroring the existing safe_plugin_rm.sh pattern) that validates the target is requirements.txt at the project root or under plugin-repos/ or plugins/ before running pip install as root. configure_web_sudo.sh provisions a narrowly-scoped sudoers rule for it. api_v3.py's install_base_requirements and install_plugin_requirements actions now use it via `sudo -n`, falling back to today's current-user-only install (with an explanatory note) if the wrapper isn't set up yet, so existing installs don't regress. Also uses --ignore-installed in the wrapper: root's site-packages often has apt/dpkg-managed copies of common libraries (requests, etc.) with no pip RECORD file, which pip refuses to upgrade in place and aborts the *entire* requirements.txt install over — discovered this while testing the fix live, since a plugin's other already-satisfied-for-the-web-user dependencies had never actually been attempted as root before. Also fixes a pre-existing bug in configure_web_sudo.sh where the display_controller.py/start_display.sh/stop_display.sh sudoers entries used PROJECT_DIR (scripts/install/, where this script lives) instead of PROJECT_ROOT (where those files actually live) — visible as the script's own "File access test" self-check failing. Verified fixed live. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KEZK1P1Q1fu5pcuVrkrCFZ * fix: invoke safe_pip_install.sh via explicit bash, matching sudoers rule CodeRabbit caught this on review: the sudoers rule configure_web_sudo.sh provisions is scoped to "$BASH_PATH $SAFE_PIP_INSTALL_PATH *" (matching the existing safe_plugin_rm.sh precedent in src/common/permission_utils.py), but _pip_install_requirements() called `sudo -n <wrapper> <req_file>` directly, relying on the script's shebang instead of an explicit bash prefix. sudo matches the literal command line, so this never matched the allowlisted rule on an install with only the specific sudoers entries this script provisions — it silently fell back to the non-root install path every time, which is the exact bug this PR set out to fix. This wasn't caught by live testing on ledpi.local because that device also has a broader, non-standard "NOPASSWD: ALL" grant which masked the mismatch. Confirmed the fix is correct by reading sudo's documented command-matching semantics and mirroring the already-proven-working bash-prefix pattern from permission_utils.py's safe_plugin_rm.sh call exactly. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KEZK1P1Q1fu5pcuVrkrCFZ * fix: harden safe_pip_install.sh invocation against bash-path drift + address CodeRabbit nitpicks CodeRabbit follow-up findings on the bash-prefix fix (7558aaab): 1. (Actionable) shutil.which('bash') at runtime could in principle resolve to a different absolute path than configure_web_sudo.sh's `command -v bash`, which is resolved once at setup time and baked into the static sudoers file as a literal string — sudo requires an exact match. Now tries /usr/bin/bash and /bin/bash (the standard Debian/Raspberry Pi OS locations, matching what the setup script virtually always produces) before falling back to this process's own PATH resolution, so a divergence in just one of them doesn't break the install. 2. (Nitpick) Any nonzero returncode was treated as "sudo denied", so a real pip failure (bad package, build error) would trigger a pointless duplicate non-root install attempt and a misleading error message. Now distinguishes "sudo -n rejected this exact command line" from "sudo ran it but the command itself failed" via sudo's own diagnostic text, and surfaces genuine failures immediately without retrying other bash candidates or falling back. 3. (Nitpick) Added structured logging for every fallback/failure path (wrapper missing, sudo denied, real install failure), previously only visible via the returned stdout note — needed for remote debugging on a headless Pi. Verified: function-level smoke test confirms a real failure (this sandbox's system python3 lacking pip) is now correctly classified as non-denial and returned immediately without retrying candidates or double-installing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KEZK1P1Q1fu5pcuVrkrCFZ --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-06 08:04:49 -04:00