130 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
shadowdaoandClaude Opus 5	9343a56ccf	Merge branch 'fix/lsphp-parity-hardening' ... Hardening for the cac-path-parity PHP extension, which moves cac-lsphp-normalize.php out of userland so the php-fpm -> ols/lsphp switch is clean. - pin the runtime PHP to the headers the extension was built against (the reverse, pinning -dev to the runtime, is unsatisfiable: the LiteSpeed repo carries only the current release) - close an ini-injection hole in the entrypoint heredoc (quoting plus a charset check, since quoting alone does not stop php.ini ${VAR} interpolation) - make the FPM parity harness actually runnable (it exited 0 while verifying nothing) and add the .phpt suite as a build gate - guard to="/" and non-absolute mappings; both narrow what runs, neither adds an error path - fix PHP_MINFO reporting 'active' for an inert mapping — that signal is what the post-deploy canary reads Reviewed twice; RINIT verified byte-identical at the instruction level across the predicate refactor. Fail-open invariant intact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 14:09:53 -07:00
shadowdaoandClaude Opus 5	3047123f2b	docs(lsphp): correct three comments that overstated what the code does ... Review found all three describing behaviour the code does not have: - The range bound does NOT prevent opcache's shared-memory startup failure. With 99-prod-overrides setting interned_strings_buffer=16, a memory_consumption of 8 or 16 is accepted here and still aborts opcache. Documented rather than raising the floor, which would forfeit the superset property. - memory_consumption's 4096 ceiling is ours, not PHP's — PHP imposes no upper bound on that directive. Only the max_accelerated_files range is a vendor clamp. Also records that an out-of-range value resets to PHP's COMPILED default, discarding the image's own override. - The stale-fragment rm -f is defensive, not a bug fix: changing these env vars requires a recreate, which starts from a fresh layer, so the scenario the comment described is not reachable via docker restart. Comments only; no behaviour change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 14:08:09 -07:00
Claude	07378506a7	harden(cac-lsphp): close the two remaining unvetted ini emissions; stop MINFO lying ... Three non-blocking findings from the re-review of this branch. No design change: the extension's fail-open-absolute invariant is untouched (still zero error emitters, every RINIT return is SUCCESS) and both RINIT guards stay pure narrowing. 1. entrypoint-lsphp.sh: 99-user-opcache.ini was still emitted unquoted ------------------------------------------------------------------- Twenty-five lines below the mapping fix, the opcache override block interpolated the raw env into an unquoted `echo` — the same injection class the mapping fix closed. Measured on this branch's image, before this commit: OPCACHE_MEMORY_MB=$'128\nprecision = 7\n; ' -> 99-user-opcache.ini gained a `precision = 7` line -> lsphp -i reported precision => 7 => 7 WHP casts (int) and clamps 32-512 / 2000-32000 (site-pool-env.php), so this is not exploitable today — but "the panel validates it" is precisely the argument this branch already rejected for `domain`, and the panel is a different repo on a different release cadence. Both siblings in the block are now validated at the point of use (digits only, length-capped, range-checked) and emitted double-quoted. A rejected value is dropped with a WARNING and the image default applies; nothing here is ever fatal. The accepted ranges are PHP's own limits for these directives (>= 8 MB; [200, 1000000] files), deliberately a strict SUPERSET of the panel's clamps, so widening a panel clamp later cannot start silently rejecting real sites. The block now also removes a stale fragment when it has nothing valid to write: the container filesystem outlives `docker restart`, so without that an override that is later cleared — or rejected — would keep applying from the previous boot's file. 2. 99-user-error-log.ini was written from an unvetted $user -------------------------------------------------------- It was emitted before the INI_TOKENS_OK branch. Contained in practice (a newline is inert inside the quotes, and a `${`-bearing user cannot exist because useradd would have failed under `set -euo pipefail`), but "this particular unvetted value happens to be contained" is the reasoning this branch rejected one screenful up. Now gated identically. Costs a rejected user nothing it needs: `log_errors = On` is already baked in by 99-prod-overrides.ini, so PHP still logs — to stderr, i.e. `docker logs`, which is more visible than a per-site file, not less. Verified fleet-wide that no legitimate user reaches the branch (30 shared_ols sites, 4 hosts). 3. MINFO reported "active" for mappings RINIT ignores --------------------------------------------------- The absolute-path guard was added to RINIT and MINFO kept testing only "both values non-empty", so: from=mnt/users/bob/site.com (relative -> INERT since the guard landed) lsphp -i -> Rewriting => active That row is what the post-deploy fleet canary greps to confirm parity is live, so the diagnostic would have masked exactly the failure the canary exists to find — and the C comment added by this branch documents it as the only runtime signal. RINIT and MINFO now share one predicate pair (cacpp_mapping_configured / cacpp_mapping_active) rather than two longhand copies, which is what drifted. MINFO now distinguishes "inactive (mapping not absolute)" from "inactive (unconfigured)" — different operational problems. Pure reporting change: the predicates are side-effect-free and cannot fail, so MINFO gains no error path. Tests: two new .phpt cover both directions of the MINFO fix (009 relative mapping must report inactive, 010 well-formed mapping must still report active), so tightening it cannot overshoot into the opposite lie. The build gate's EXPECTED count is derived from `ls tests/*.phpt`, so it picked them up: 10/10. Non-vacuity, all five demonstrated by mutation: - opcache quoting reverted -> injection lands, `precision => 7` observed - error-log gate removed -> fragment written from the unvetted user - MINFO reverted to non-empty -> 009 FAILS, build gate exits 1 - MINFO forced always-inactive -> 010 FAILS, build gate exits 1 - all restored -> 10/10, build exit 0	2026-08-05 13:46:52 -07:00
shadowdaoandClaude Opus 5	9761157a6b	harden(cac-path-parity): make degenerate mappings inert instead of subtly wrong ... Three loose ends from the review, none reachable from entrypoint-lsphp.sh today. The rewrite semantics and the prefix-boundary logic are untouched; both new guards only NARROW the set of configurations that do anything, and neither adds an error path — fail-open is unchanged. - to="/" produced "//public_html": cacpp_trim() keeps a lone separator, and the tail already starts with one. Collapse the prefix when there is a tail, keep it when there is not (value == from exactly, where "/" is correct). A doubled leading slash is not the same string as the cac-fpm value, which is the entire point of the extension. - a non-absolute `from`/`to` was accepted and applied. Both are now required to start with '/', otherwise RINIT returns exactly as it does for an absent mapping: inert, no diagnostic, request proceeds. - a well-formed but WRONG mapping stays undetectable, and now the FAILURE MODES block says so explicitly rather than leaving it as an unlisted gap, along with why that is acceptable (the entrypoint derives from/to from the same two variables it builds the compatibility symlink from, so a wrong mapping means the symlink is wrong too and the site is already broken more loudly) and where the only runtime signal is (`lsphp -i`). Two tests added, both non-vacuous — 007 rewrites without the absolute-path guard, 008 returns "//public_html" without the collapse. 8/8 pass on PHP 8.1/8.3/8.5, and the FPM harness still reports 9/9 against the changed .so. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 13:06:34 -07:00
shadowdaoandClaude Opus 5	61bfdcfaf9	test(cac-path-parity): run the .phpt suite as a build gate ... Nothing executed ext/cac-path-parity/tests/ — not Dockerfile.lsphp, not .gitea/workflows/build-push.yaml. The suite passed, but as shipped it was documentation, not a gate. `make test` now runs in the ext-build stage, against the same lsphp build the .so ships next to. It costs ~1s per PHP version. The lsphp packages turn out to include a real CLI binary (php-config --php-binary => /usr/local/lsws/lsphpNN/bin/phpN.N), so run-tests.php works with no extra tooling. Guarded twice, because `make test` fails silently by default: - if PHP_EXECUTABLE is missing, the Makefile prints "Cannot run tests without CLI sapi." and EXITS 0. Asserted rather than assumed. - a run that executes zero tests also exits 0, so the summary is checked against the number of .phpt files on disk, plus "Tests failed : 0". Same reasoning as the `lsphp -i` probe: an assertion that cannot fail is worse than no assertion. Verified 8/8 on PHP 8.1/8.3/8.5. Mutation-tested both guards: breaking 001-rewrite.phpt's expectation fails the build ("FATAL: cac_path_parity .phpt suite FAILED"); adding a test that always SKIPs makes run-tests.php still exit 0 but the build fails on "expected all 9 .phpt tests to run" (summary read "Number of tests : 9 8"). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 13:06:23 -07:00
shadowdaoandClaude Opus 5	fb4946641a	fix(cac-path-parity): make the FPM proof harness actually runnable as shipped ... The artifact cited as the web-SAPI evidence could not have been run as it stood. Measured in an official php:8.3-fpm container with the extension built in place: - as shipped, no args: "SKIP: php-fpm not found", exit 0. The default was `php-fpm8.3`, which matches neither the official images (`php-fpm`) nor this repo's images. - with the binary supplied by hand: 9 FAIL, every one with an empty `got:`. The generated pool had no user/group, so php-fpm refused to start as root ("please specify user and group other than root"). A startup failure was wearing the costume of nine parity bugs. Changes: - auto-detect the binary (php-fpm, php-fpm8.N, /usr/local/sbin, /usr/sbin) and print which one was chosen plus its version; - pre-flight the extension with `php-fpm -m`, so a .so that will not load into THIS php-fpm reports as a harness failure naming the ABI mismatch rather than as nine wrong paths; - emit user/group in the pool when running as root, resolved from accounts that actually exist (www-data / nobody / daemon), and chmod the fixture tmpdir so the non-root worker can read it; - run_case() now returns non-zero when php-fpm never answered, and every call site routes that to die_startup(), which prints the php-fpm output and the pool error_log and exits 2 — an exit code deliberately distinct from 1 (assertion failure). After: 9/9 ALL PASS from a clean checkout with no arguments and no environment fixing, running as root in php:8.3-fpm. Mutation-tested both new paths: a pool user that does not exist reports "HARNESS FAILURE ... STARTUP/environment failure" with the real php-fpm error and exit 2; an EXT_SO that is not a loadable extension is caught by the pre-flight, also exit 2. Also fixes doc drift: 001-rewrite.phpt pointed at tests/web-sapi-parity-check.sh, which has never existed. The file it means is tests/fpm-parity-check.sh. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 13:06:10 -07:00
shadowdaoandClaude Opus 5	690ff8738d	fix(cac-lsphp): stop generating php.ini fragments from unquoted interpolation ... The two generated ini drop-ins interpolated $user/$domain into an unquoted heredoc. Measured against the pre-fix script in a real cac-lsphp:php83 container with domain=$'evil.com\nprecision = 7\n; ': 99-cac-path-parity.ini contained the injected line and lsphp reported `precision => 7 => 7` — an arbitrary ini directive supplied through the domain env var and applied to every request. The `from` value was silently truncated at the newline too, so the site also got a wrong (but "active") mapping. Both values are panel-validated and both already feed `ln -sfn` and the shared-ols vhost config, so this is defense-in-depth rather than a live hole. It is worth closing anyway because the OTHER two hostile inputs the reviewer measured — `$(...)` (ini parse error) and `"` (empty value) — leave the parity extension INERT, which is precisely the silent failure this whole change set exists to eliminate. Two layers, neither of which can fatal a request: - values are emitted double-quoted via printf instead of heredoc interpolation. php.ini double-quoted values may span newlines, so a newline is data, not a new directive. - $user/$SAFE_DOMAIN are checked against [A-Za-z0-9._-]+ first, because quoting does NOT stop php.ini's own ${VAR} interpolation. A rejected value logs a WARNING, writes no mapping at all (not even the degraded auto_prepend fallback, which would not be right for such a site either) and reports `path parity = none (user/domain rejected)` on the startup line. After: same container, same hostile domain — no 99-cac-path-parity.ini is written, `precision => 14` (default), and the warning names the rejected values. Happy path re-verified for domain=site.com and domain=*.site.com: mapping written, `Rewriting => active`, from/to parse back byte-identical. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 13:05:57 -07:00
shadowdaoandClaude Opus 5	06df1c410b	fix(cac-lsphp): pin the shipped lsphp to the version the .so was built against ... The comment claimed the extension was "built against THIS image's own lsphp so the API/ABI always match". It was not, and could not be: `lsphp<NN>-dev` is absent from the LiteSpeed apt repo at the version every prebuilt OLS base image ships, because that repo carries only the current release. Measured on OLS 1.8.4 (2026-08-05), base image vs repo candidate: lsphp81 8.1.33-5+noble -> 8.1.34-1+noble lsphp83 8.3.28-1+noble -> 8.3.32-1+noble lsphp85 8.5.0-3+noble -> 8.5.8-1+noble and the literal fix — `apt-get install lsphp<NN>-dev="$(dpkg-query lsphp<NN>)"` — fails on all three with `E: Version '<base>' for 'lsphp<NN>-dev' was not found` (apt exit 100). So installing -dev necessarily upgrades lsphp in the build stage; the only satisfiable direction is to move the runtime to meet it. The skew the reviewer measured (a .so built on 8.3.32 shipped beside an 8.3.30 runtime, lsphp83-common at 8.3.31) was not vendor randomness: BOTH stages resolve "repo latest" independently and Docker caches them independently. `COPY ./ext` sits at the top of the ext-build stage, so editing the extension invalidated that stage's apt layer while stage 2's stayed cached — i.e. every extension edit rebuilt the .so against fresh headers and shipped it next to a stale runtime. Fixed by making them one system: - the toolchain layer moves ABOVE the source COPY, so editing the extension no longer re-resolves the PHP version; - it records the resolved version to /build-out/lsphp.version and asserts lsphp<NN> == lsphp<NN>-dev in that stage; - stage 2 COPYs that file in BEFORE its apt layer (so the version is part of that layer's cache key) and pins lsphp/-common/-ldap to it, then asserts the installed versions match. Unsatisfiable pin => loud apt failure with the remediation, never a silent fallback. Verified: builds clean on PHP 8.1/8.3/8.5; the shipped php83 image now reports a uniform lsphp83 family at 8.3.32 (the previous image shipped lsphp83 8.3.30 / -common 8.3.31 / -ldap 8.3.30). Mutation-tested by recording a version the repo no longer has: build fails at stage 2 rather than shipping the skew. The `lsphp -i | grep` build assertion is kept but its comment now says what it does and does not prove: it catches a .so that will not LOAD, never silent struct-layout drift. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 13:05:36 -07:00
shadowdaoandClaude Opus 5	a3aa9f2b26	fix(lsphp): repair the comment my sed mangled ... My previous commit used sed with | as both delimiter and literal, which corrupted the comment line rather than changing -m to -i. The assertion command itself was never touched and is correct. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 11:41:28 -07:00
shadowdao	83522b00ef	Merge branch 'feat/lsphp-server-path-parity' ... Guarantees $_SERVER path parity between cac-fpm and cac-lsphp via a PHP extension rewriting the filesystem-path keys from RINIT, configured by two PHP_INI_SYSTEM entries a customer's .user.ini cannot reach. The prepend it replaces was PHP_INI_PERDIR, so any site with its own auto_prepend_file displaced it -- 7 live shared_ols sites are in that state. Hardening the hook was self-defeating: PHP resolves ONE winning auto_prepend_file after the .user.ini chain, so you cannot chain from the losing side, and php_admin_value would make ours win by making the customer's Wordfence WAF never run. An extension occupies no userland hook at all. The symlink-farm alternative was rejected twice over: followSymLink in a shared multi-tenant OLS is a cross-tenant read risk, and /home/<user> is ambiguous in the single shared-ols container when one user has several sites.	2026-08-05 11:41:03 -07:00
shadowdaoandClaude Opus 5	15e304e0c3	docs(lsphp): the build assertion probes with -i, not -m ... The comment describing the assertion still said 'lsphp -m | grep' while the code correctly uses -i. That is the exact trap documented three lines below -- lsphp is the LSAPI SAPI and answers -m by printing usage and exiting 0, so an -m based check never matches and never fails. Leaving the comment wrong would invite someone to 'restore' it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 11:41:03 -07:00
shadowdaoandClaude Opus 5	da16faaff5	feat(cac-lsphp): guarantee $_SERVER path parity via a PHP extension ... A site moved from cac-fpm to cac-lsphp must see byte-identical $_SERVER['DOCUMENT_ROOT'] and ['SCRIPT_FILENAME'] (/home/<user>/...). The auto_prepend_file normaliser that did this was PHP_INI_PERDIR, so any site with its own .user.ini auto_prepend_file silently displaced it — the state 7 live shared_ols sites (Wordfence, cPanel imports) are actually in. Hardening the hook was not an option either: making our prepend win would have disabled those Wordfence WAFs. Replace it with cac_path_parity, a small PHP extension that rewrites the filesystem-path $_SERVER keys from RINIT. RINIT cannot be displaced by .user.ini, and it occupies no userland hook, so the customer's own auto_prepend_file stays the only prepend in play and keeps working. The mapping lives in two PHP_INI_SYSTEM settings, which .user.ini (PERDIR / USER only) and ini_set() cannot reach. Mechanism is a path-component-bounded string prefix swap, not realpath(): byte-identical to cac-fpm by construction (realpath would resolve a customer's own symlinked public_html to some third path), no syscall, and no failure path. Every guard fails open and leaves $_SERVER untouched; nothing here can warn, throw or 500 a site. Unconfigured it is fully inert, so cac-fpm and cac-litespeed are unaffected. Built in a separate Dockerfile stage keyed off the existing ARG PHPVER — gcc/phpize/headers never reach the shipped image (verified absent; the image grows ~155kB), and a base-image PHP bump recompiles with no human step. A `lsphp -i | grep` assertion fails the build if the .so does not load, so an image can never ship having silently lost parity. The entrypoint selects the extension when present and removes any stale prepend ini left by an older image; if the extension is somehow not loadable it falls back to the old normaliser and logs a WARNING rather than losing normalisation entirely. It also now logs the active parity mode, and warns when lsphp reports no ini scan dir (previously silent). Probe lsphp with `-i` only: it is the LSAPI SAPI, not the CLI, and answers `-m`/`-r` by printing usage and exiting 0 — a `lsphp -m | grep` check never matches and never errors, which is the exact class of silent always-false assertion this change exists to remove. Verified: 6 .phpt tests; tests/fpm-parity-check.sh proves under the FPM SAPI that with a customer .user.ini auto_prepend_file present both keys are still corrected AND the customer's prepend still runs, and that the old mechanism does not; and in a real built cac-lsphp:php83 container that SCRIPT_FILENAME is rewritten, the customer prepend still fires, and another tenant's path is left untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-05 11:38:19 -07:00
jknapp	03b8f3f730	Merge pull request 'fix(cac-lsphp): enable .user.ini support (LSPHP_ENABLE_USER_INI)' (#21) from fix/lsphp-enable-user-ini into trunk	2026-08-02 22:38:03 +00:00
Claude	433e74975c	fix(cac-lsphp): enable .user.ini support (LSPHP_ENABLE_USER_INI) ... php-lsapi compiles .user.ini support in but leaves it DISABLED by default. sapi/litespeed/lsapi_main.c has `static int parse_user_ini = 0;` and only sets it when the process environment contains LSPHP_ENABLE_USER_INI=on. WHP never set it, so lsphp never entered the user-ini chain at all. The failure was silent: phpinfo() still reports user_ini.filename=.user.ini and user_ini.cache_ttl=300, because those are core INI defaults that are simply inert under this SAPI. Every other WHP PHP tier (cac, cac-fpm, cac-litespeed) honors .user.ini, so shared_ols was quietly inconsistent. Impact found in production (whp01/whp02/sdbees/TrueSelfCA, 29 sites): - Per-site memory_limit / max_input_vars overrides were ignored. A Divi site's max_input_vars stayed at the 2000 default while its .user.ini asked for 20000. - Wordfence's auto_prepend_file WAF never loaded on ANY shared_ols site. 11 sites had the plugin installed and reporting "Extended Protection" enabled while the prepend was never executed. Verified on a live sidecar (shadowdao.com, whp01) before this commit by injecting the env var via whp.container_types.startup_env and recreating: before: auto_prepend_file=/scripts/cac-lsphp-normalize.php (WAF absent) after: auto_prepend_file=/home/shadowdao/public_html/wordfence-waf.php wordfence-waf.php present in get_included_files() class_exists('wfWAF') === true The platform normalize prepend still chains in behind Wordfence's bootstrap, so DOCUMENT_ROOT canonicalisation is not lost. Set in two places on purpose: the Dockerfile ENV makes the value visible in `docker inspect` and survives an entrypoint override, and the entrypoint re-exports it with the same default because the runuser fallback exec path resets the environment. Still overridable per-container (LSPHP_ENABLE_USER_INI=off) as an escape hatch for a site whose legacy cPanel-generated .user.ini has not been remediated yet. NOTE: enabling this activates every previously-inert .user.ini at once. Audit the fleet for stale cPanel directives before rolling this image — session.save_path values under /var/cpanel/ that do not exist in the container, memory_limit above the cgroup cap, and upload_max_filesize values below the platform default were all found and remediated first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 15:23:05 -07:00
jknapp	cc72fda741	Merge pull request 'fix(shared-ols): never cache logged-in pages (disable tier private cache)' (#20) from fix/shared-ols-no-logged-in-cache into trunk ... Reviewed-on: #20	2026-06-27 04:04:49 +00:00
shadowdaoandClaude Opus 4.8	a865a13940	fix(shared-ols): never cache logged-in pages (disable tier private cache) ... OLS tier had enablePrivateCache=1 + checkPrivateCache=1 at module scope on the assumption that with no LiteSpeed Cache WP plugin nothing would be cached. In practice OLS privately cached logged-in / cookie-bearing responses regardless of the plugin, serving stale wp-admin pages for the full privateExpireInSeconds TTL (observed: a WordPress 'automated update failed' nag persisting after the cause was cleared). Disable private caching at the tier (enablePrivateCache 0 + checkPrivateCache 0) so logged-in pages are always served fresh. Public/anonymous caching is unchanged (enableCache 1 + checkPublicCache 1), still honored from the plugin's X-LiteSpeed-Cache-Control headers. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 20:58:23 -07:00
shadowdaoandClaude Opus 4.8	8dbfdf599a	fix(shared-ols): useIpInProxyHeader 2->1 so real client IP reaches lsphp ... Mode 2 ("trusted IP only") extracts the real client IP from X-Forwarded-For ONLY when the connecting peer is in a TRUSTED access-control list — which this tier never configured (accessControl is `allow ALL`, no trusted designation). So OLS kept HAProxy's container IP (172.18.0.34) as REMOTE_ADDR for EVERY request across ALL tenants. WP security plugins (Wordfence etc.) then saw all traffic as one IP; blocking it locked every site — and the admin — out. HAProxy already sends X-Forwarded-For and is the ONLY peer that connects to this tier (client-net, no host-published ports), and it OVERWRITES XFF with %[src] (set-header), so spoofing is impossible. Mode 1 (always trust XFF) is correct and safe here — it matches the working standalone configs/litespeed config which has always used 1. Verified on whp01: lsphp now receives the forwarded client IP end-to-end (REMOTE_ADDR=<real-ip>, was 172.18.0.34). Live-hotpatched whp01+whp02 pending this image rebuild. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-11 07:58:07 -07:00
jknapp	2e85f458d3	Merge pull request 'feat: OLS tier images — cac-lsphp (detached lsphp) + shared-ols' (#19) from feature/cac-lsphp-image into trunk ... Reviewed-on: #19	2026-06-10 16:56:38 +00:00
shadowdaoandClaude Opus 4.8	08f35032c5	fix(shared-ols): re-review hardening — bounded flock + stale-tmp sweep ... Follow-up to the review fixes, from a second review pass: - flock now uses -w 30 (bounded wait) so a hung render can't block the panel's docker-exec (and the site-save request) indefinitely; the dead-code timeout error path is now reachable. - sweep stale .httpd_config.conf.tmp.* left by a prior SIGKILL (trap EXIT doesn't run on SIGKILL); safe under flock since each render uses a unique $$ suffix. Verified: render still produces a valid config + serves; stale tmp is swept. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-10 09:25:05 -07:00
shadowdaoandClaude Opus 4.8	6bb494c72f	fix(shared-ols): review fixes — watcher starvation, atomic render, O(N) chown, safe meta parse ... Addresses the local code-review on the OLS-tier images: - [HIGH] ols-htaccess-watcher.sh: the debounce drain read ALL inotify events unfiltered, so on a busy multi-tenant server it never timed out and the restart was STARVED (rewrite changes silently never applied). Now coalesces with a hard DEBOUNCE-bounded window. Verified under continuous noise. - [HIGH] render-shared-ols-config.sh: built httpd_config.conf in-place across several appends, so a concurrent OLS restart (watcher) or parallel render could read a half-written config and 503 the whole tier. Now flock-serialized, built in a temp file and atomically moved into place; refuses to publish empty. - [MED] render + entrypoint: replaced recursive chown of the whole conf tree (O(N-sites) on every single-site change / boot) with a targeted chown of just the file written. - [MED] render: parse site.meta with sed instead of sourcing it (do not execute panel-written data as shell). - [cleanup] removed the unused configs/shared-ols/vhconf.tpl (the panel copy is the single source; the image never read it). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-10 08:35:26 -07:00
shadowdaoandClaude Opus 4.8	7552760ba0	fix(cac-lsphp): normalize $_SERVER DOCUMENT_ROOT/SCRIPT_FILENAME to /home ... The symlink makes __FILE__/__DIR__/realpath/getcwd report /home/<user>/public_html (WordPress/frameworks), but $_SERVER['DOCUMENT_ROOT']/['SCRIPT_FILENAME'] are raw env vars OLS sets to its /mnt/users view — apps that build/compare paths from them would see /mnt/users. Added a tiny auto_prepend (cac-lsphp-normalize.php, wired via a scan-dir ini) that realpath-canonicalises those two back to /home. Customer sites have no auto_prepend by default, so no conflict. Verified clean-room (committed image, fresh boot): DOCUMENT_ROOT and SCRIPT_FILENAME both report /home/<user>/public_html through the shared OLS. Now byte-for-byte 1:1 with cac-fpm/cac-litespeed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-10 07:02:54 -07:00
shadowdaoandClaude Opus 4.8	fc65b68bd6	fix(cac-lsphp): mount docroot at /home/$user + symlink for true 1:1 compatibility ... Customer concern: sites with /home/<user>/public_html baked into config or the DB must keep working — a changed in-container docroot path would break WordPress ABSPATH, hardcoded includes, cached absolute paths, etc., making the upgrade a non-drop-in. Fix: the sidecar now mounts the docroot at /home/$user (IDENTICAL to cac-fpm/cac-litespeed) and the entrypoint symlinks /mnt/users/<user>/<domain> -> /home/$user. OLS still serves from its bulk /mnt/users mount and sends lsphp that path (no remap available), but the symlink resolves it to the real /home/$user files AND PHP canonicalises it — so __FILE__/__DIR__/realpath/ABSPATH all report /home/<user>/public_html. Verified end-to-end through the shared OLS: a request reports __FILE__=/home/homeuser/public_html/probe.php, ABSPATH=/home/homeuser/public_html/, and stored /home paths resolve. True 1:1 drop-in. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-10 06:54:28 -07:00
shadowdaoandClaude Opus 4.8	e99b8cb2d1	fix(cac-lsphp): entrypoint operates on the /mnt/users docroot, not /home/$user ... Code-review integration fixes: - entrypoint-lsphp.sh: the shared-ols tier mounts the docroot at /mnt/users/<user>/<domain> (NOT /home/$user). Discover the mount via glob (one site per sidecar; wildcard-safe), create public_html + logs/php-fpm under it (so OLS docRoot exists), point lsphp error_log there, and chown just those dirs. Verified: sidecar creates public_html under the mount, runs as the per-site user, OLS serves PHP (SAPI=litespeed) end-to-end. - shared-ols vhconf.tpl: per-vhost logs -> /usr/local/lsws/logs/<vhname>.* (the shared-ols container has no /home/<user>). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-10 06:42:31 -07:00
shadowdaoandClaude Opus 4.8	19db8f170a	feat(shared-ols): shared OpenLiteSpeed tier image (webserver-only, fronts cac-lsphp sidecars) ... One OLS container fronting many tenants' detached cac-lsphp sidecars — the OLS analogue of shared-httpd. Runs NO PHP locally; every site's PHP goes to its own sidecar over LSAPI (extProcessor type lsapi, address <sidecar>:9000). Key design fact (established by PoC): OLS has NO top-level 'include' directive, so render-shared-ols-config.sh assembles httpd_config.conf from the panel's per-site files (vhconf.conf + site.meta) at boot and on every change — the 'include' OLS lacks. Per-site detail uses the OLS-native configFile + vhost-scoped extprocessor model. LSCache is module-level (a configFile-loaded vhost rejects a bare cache{} block); the WP LiteSpeed plugin controls cacheability via X-LiteSpeed-Cache-Control headers. - Dockerfile.shared-ols: litespeed base + inotify-tools/envsubst/openssl, admin bound to loopback, :80/:443 self-signed, healthz HEALTHCHECK. - entrypoint-shared-ols.sh: cert + health vhost + render + watcher, then daemon-mode OLS supervision (reused from cac-litespeed so self-restarts don't kill PID 1). - render-shared-ols-config.sh: strip stock (incl local lsphp) + append base + per-site stanzas + listeners with all maps + catch-all health vhost. - ols-htaccess-watcher.sh: inotify debounce+floor -> lswsctrl restart (spec 5.3). - configs/shared-ols/{httpd_config_base,vhconf}.tpl. - CI: Build-Shared-OLS job. Verified locally end-to-end: zero-site boot healthy on :443; add site via the panel contract -> Host-routed to the right sidecar (SAPI=litespeed); real client IP + HTTPS behind X-Forwarded headers; LSCache miss->hit; .htaccess change triggers graceful restart; unknown Host hits health catch-all (200). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-10 01:22:14 -07:00
shadowdaoandClaude Opus 4.8	19092911a3	feat(cac-lsphp): detached lsphp (LSAPI) site image for the shared-ols tier ... New slim per-site PHP backend that runs 'lsphp -b 0.0.0.0:9000' (detached LSAPI) and nothing else — the LiteSpeed analogue of cac-fpm, sitting behind a shared OpenLiteSpeed container. Built on the same litespeedtech prebuilt base as cac-litespeed so the lsphp runtime/extensions are identical. - Dockerfile.lsphp: base + lsphpNN-ldap parity, reuses shared lsphp-overrides.ini, exposes only :9000, no webserver started (guaranteed by entrypoint, not by stripping OLS binaries). - entrypoint-lsphp.sh: same uid/user contract + /home/$user/logs layout + ini drop-in mechanism as entrypoint-litespeed.sh; sizes PHP_LSAPI_CHILDREN from container memory (detect-memory-lsphp.sh) with panel override precedence; execs lsphp -b as the per-site user via setpriv (PID 1). - detect-memory-lsphp.sh: LSAPI_CHILDREN sizing, no OLS daemon reserve. - healthcheck-lsphp.sh: TCP :9000 + lsphp-alive (LSAPI isn't FastCGI). - CI: Build-LSPHP-Images job, php81-85 matrix, OLS 1.8.4, cac-lsphp:phpNN. Verified locally: builds php83+php85; sidecar runs lsphp as the per-site user (uid 61045) as PID 1, healthcheck green, and a real shared OLS in front serves PHP over LSAPI (HTTP 200, SAPI=litespeed) with identical docroot path. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-09 18:28:34 -07:00
shadowdaoandClaude Opus 4.8	50202538e4	cac-litespeed: supervise OLS in daemon mode so self-restarts don't kill PID 1 ... cac-litespeed containers were dying at random intervals and staying 503 until manually restarted. Root-caused on whp02 (alsacorp, 2026-06-06): the LiteSpeed Cache / QUIC.cloud integration refreshes the QUIC.cloud IP allowlist on a schedule and, when it changes, sends SIGUSR1 → "request a graceful server restart". The entrypoint ran `openlitespeed -n & wait "$OLS_PID"`, so when the OLD main PID exited after the zero-downtime handoff, `wait` returned, PID 1 (bash) exited, and the whole container went down. The exit was clean (code 0), so even a restart policy wouldn't reliably catch it — HAProxy just served 503 until someone ran `docker start`. Replace the `-n` foreground+wait model with a daemon-mode supervisor: start OLS via `lswsctrl start` (its native model, where it owns the SIGUSR1 handoff and keeps listeners bound across generations) and have PID 1 follow `lswsctrl status`. A graceful self-restart is now invisible here (verified zero-downtime); PID 1 only relaunches on a genuine crash (no live main), with a 5-in-60s crash-loop cap that bails out to Docker's restart policy / the site monitor. SIGTERM still drains and exits cleanly for docker stop / recreate. Verified on a scratch php85 container: survives `lswsctrl restart`, survives a raw SIGUSR1 to the main (the exact QUIC.cloud path that used to kill it), relaunches after `kill -9` of the main, and stops cleanly in ~6s on docker stop. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-05 19:15:25 -07:00
shadowdaoandClaude Opus 4.8	2837d40f00	cac-litespeed: forward real client IP to logs and PHP behind HAProxy ... OLS had no equivalent of the Apache cac:phpNN mod_remoteip wiring (configs/remote_ip.conf + RemoteIPInternalProxy), so every migrated LiteSpeed site logged HAProxy's docker-bridge IP and handed that same internal IP to lsphp as $_SERVER['REMOTE_ADDR']. That silently broke traffic analytics, WP security plugins, brute-force detection, Coraza source-IP correlation, geo, and rate-limiting. Add server-level `useIpInProxyHeader 1` to the httpd_config append fragment. OLS then rewrites the remote IP from X-Forwarded-For for both logging and the LSAPI REMOTE_ADDR before PHP sees it. Value 1 mirrors the Apache trust model (container is only reachable via HAProxy, never bound publicly). Confirmed HAProxy customer backends are mode http with `option forwardfor` and set X-Forwarded-For to the resolved real client IP. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-04 15:51:25 -07:00
shadowdaoandClaude Opus 4.7	cfdaae116a	tune(litespeed): bump opcache 32→64 MB / 4000→8000 files + add per-site override ... 32M/4000 was too aggressive for heavy WP+Divi+WC sites: 3000+4000 unique PHP files each blow through max_accelerated_files, causing constant eviction + recompilation thrash. Manifested 2026-06-03 as ~40% sustained CPU on alphaoneaminos and 5378 oom_kills/9h on brain-jar. 64M/8000 fits Divi + WC + WP core bytecode without eviction. N lsphp × 64 MB ≈ 512 MiB shmem worst case — still under the per-instance setUIDMode fan-out from the original 128M problem (which was 1+ GiB). Per-site override (OPCACHE_MEMORY_MB / OPCACHE_MAX_FILES env vars) lets the panel push down for low-traffic sites or up for outliers without rebuilding the image. WHP panel UI ships in a follow-up commit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-06-03 06:21:37 -07:00
shadowdaoandClaude Opus 4.7	87f154cdc8	refactor(litespeed): drop setUIDMode for shared lsphp + cut opcache 128→32M ... OLS runs as the customer user end-to-end (server-level user/group set by create-vhost-litespeed.sh), so lsphp inherits that uid without per-request suEXEC. Eliminates the per-httpd-worker lsphp instance fan-out — one shared lsphp parent now serves all httpd workers via the shared socket. Combined with opcache.memory_consumption 128→32M, brain-jar measured shmem dropped from ~880 MiB → 32 MiB and memory.current from ~1.1 GiB → 67 MiB at the 1.5 GiB cap. No new oom_kills since the change. Safe because cac-litespeed is one-customer-per-container — the container boundary is the privsep boundary. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-06-02 20:06:56 -07:00
shadowdaoandClaude Opus 4.7	f463519998	tune(litespeed): bump LSPHP_WORKER_ESTIMATE_MB 115 → 130 ... 115 was set from idle-state per-worker memory. Active workers on heavy WP/Divi grow to ~130-150 MB (shmem + anon + file), and the 115 formula gave brain-jar.com CHILDREN=8 at 1 GiB — which produced 142 OOM-kills overnight because there was zero headroom once page renders started. 130 backs off slightly on the bigger sites: 512 MiB: 3 workers (unchanged) 1 GiB: 7 workers (was 8 — brain-jar's failure point) 1.5 GiB: 11 workers (was 12) 2 GiB: 15 workers (was 17) 4 GiB: 30 workers (was 33) Per-site FPM_MAX_CHILDREN override still wins for sites that need tighter caps regardless of formula default. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-06-02 18:54:28 -07:00
shadowdaoandClaude Opus 4.7	03cca745f7	feat(litespeed): wire up dynamic LSAPI tuning + idle reduction ... Two correctness fixes and a tuning improvement. CORRECTNESS: 1. Strip the stock 'extProcessor lsphp' from httpd_config.conf before appending ours. Previously the stock block (hard-coded PHP_LSAPI_CHILDREN=10 regardless of container memory) always won because our APPEND fragment didn't include an extProcessor block. detect-memory-litespeed.sh was computing LSAPI_CHILDREN but never plumbing it anywhere — silent dead code. 2. Bump LSPHP_WORKER_ESTIMATE_MB from 96 → 115 per the 2026-06-02 memory-sizing finding (vantagehealth OOM-spawn loop). Each lsphp carries ~115 MB shmem-rss accounted per worker. 115 MB matches the real per-worker baseline. TUNING (idle reduction, the original ask): - LSAPI_MAX_IDLE_CHILDREN=2 (was CHILDREN/2 = 5 default) - LSAPI_MAX_IDLE=60s (was 300s default) - PHP_LSAPI_MAX_REQUESTS=500 (recycle workers, prevents bloat) - memSoftLimit=1024M / memHardLimit=1500M per worker (RLIMIT_AS; catches runaway scripts at the worker level, cgroup still backstops the container) Effective LSAPI_CHILDREN per container: 2 GiB → ~17 (was 10 — brain-jar was saturating) 1 GiB → ~8 512 MiB → ~3 (cap-marginal per the memory note; bump container if site grows) Dropped LSAPI_MEM_SOFT/HARD computation in detect-memory: AVAILABLE/CHILDREN was conflating VSZ with RSS-budget arithmetic and would have killed legitimate workers. The 1024/1500 hard-coded values in the template comfortably fit typical Divi/WooCommerce VSZ (280-365 MB). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-06-02 16:36:25 -07:00
shadowdaoandClaude Opus 4.7	d1c3cfadc0	feat(litespeed): make log paths drop-in compatible with cac:phpNN ... OLS now writes: access -> /home/$user/logs/apache/access_log error -> /home/$user/logs/apache/error_log PHP -> /home/$user/logs/php-fpm/error.log Matches the cac:phpNN bundled image convention exactly, so existing WHP log-gathering code (whp-traffic-aggregator.php, process-log-review.php) works for migrated sites without any panel-side changes. Customer-facing paths are stable across migrations — "where do I find my access log?" gets the same answer regardless of image family. Server-level OLS logs (/usr/local/lsws/logs/) are unchanged — those are internal diagnostics, not customer-relevant. PHP error_log is set via a runtime-rendered tiny ini in lsphp's scan dir (can't be in the static lsphp-overrides.ini because the path is per-customer). Customers on the four whp01 migrations (alphaone, peptides, shadowdao, brain-jar) need a container recreate after CI publishes the new tags. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-06-02 10:53:44 -07:00
shadowdaoandClaude Opus 4.7	80fa06592b	perf(litespeed): defer mariadb-server + memcached install to DEV runtime ... Drops these from the build-time apt install in Dockerfile.litespeed; they now install at entrypoint time only when environment=DEV, guarded by 'command -v mysqld' so container restarts skip the apt step. Mirrors the cac:phpNN pattern. The mysql CLI client is already in the litespeedtech/openlitespeed base, so wp-cli + DEV creds-bootstrap still work without a build-time client install. Measured (php83 / OLS 1.8.4): PROD image: 1.64 GB -> 1.20 GB (~440 MB savings) PROD first-200 boot: unchanged at ~1.5s DEV first boot: ~51s (apt install cost — one-time per container) DEV second boot: ~6s (cache hit, same as PROD) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-06-02 08:26:19 -07:00
shadowdaoandClaude Opus 4.7	9e13571d61	Drop stale configs/litespeed/vhconf.tpl ... Leftover from v1 direct-virtualHost iteration. Superseded by site-template.tpl when we switched to the vhTemplate + member pattern. Nothing references it in scripts/ or configs/; was only included in the initial commit by oversight. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-06-02 07:33:06 -07:00
shadowdaoandClaude Opus 4.7	55c28a0c11	Add cac-litespeed image family (OpenLiteSpeed, native LSAPI) ... New paid-tier per-customer image built on litespeedtech/openlitespeed:1.8.4-lsphpNN. Matrix: 8.1-8.5. Native LSAPI suexec to customer uid, server-level LSCache, all WP/WooCommerce extensions (memcached, redis, imagick, mbstring, etc.) baked in. Files: - Dockerfile.litespeed (FROM prebuilt LiteSpeed base, layers wp-cli/composer/mariadb) - configs/litespeed/{httpd_config,site-template,lsphp-overrides}.tpl - scripts/{entrypoint,create-vhost,detect-memory}-litespeed.sh + install-lscache-wp.sh CI: new Build-LiteSpeed-Images matrix job. OLS_VERSION pinned to 1.8.4 (only release with prebuilt images for all 5 PHP versions on Docker Hub). Spec: whp/docs/superpowers/specs/2026-06-01-cac-litespeed-design.md Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-06-02 07:32:47 -07:00
Claude Code	1756d496e5	detect-memory: raise PHP_WORKER_ESTIMATE_MB default 60→128 ... The 60 MB worker estimate was optimistic for plugin-heavy WordPress and WooCommerce stacks. Concrete measurement on alphaone 2026-06-01: Container memory : 1024 MiB (later 2048 MiB) Pool sized by formula : pm.max_children = (1024-100)/60 = 15 Actual per-worker RSS : ~193 MB (anon+file+shmem from kernel OOM dumps) Worst-case peak : 15 × 193 MB ≈ 2.9 GB That math put traffic-burst peak demand well over the container cap, producing 1,586 cumulative oom_kills across alphaone's two containers over 18 days and intermittent fork-starvation for unrelated tenants on the host. 128 MB is a more realistic baseline: closer to actual WP+Woo+page- builder worker footprint, still conservative enough that lighter sites continue to get reasonable concurrency. The matrix at common container tiers: Tier (MiB) | old children | new children | new peak demand 256 | 2 (floored) | 2 (floored) | ~256 MB 512 | 6 | 3 | ~384 MB 768 | 11 | 5 | ~640 MB 1024 | 15 | 7 | ~896 MB 2048 | 15 (capped*) | 15 | ~1.9 GB (* old formula returned 32 at 2 GiB but production containers were booted at lower tiers and never recalculated; see whp01 audit.) Existing containers keep their boot-time pm.max_children until they are recreated — this change only affects new containers. Customers or operators can override per-container via FPM_MAX_CHILDREN env.	2026-06-01 08:23:09 -07:00
shadowdaoandClaude Opus 4.7	d5d027c0ab	chore(ci): trigger fresh build to verify older PHP tags repopulate ... The registry currently only carries cac:{latest,php84,php85} and cac-fpm:{latest,php84,php85}, even though run #49's runner log shows all 14 jobs (74,80,81,82,83,84,85 × cac, cac-fpm) successfully pushed on 2026-04-02. The older manifests have since been deleted from the registry — direct probe by digest returns 404, so it's not just an orphaned-tag situation. We do not believe there is an active cleanup process. This empty commit triggers a fresh push so we can confirm the workflow is still producing all 14 images and that the tags persist after build. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-29 07:59:12 -07:00
shadowdaoandClaude Opus 4.6	28bb1055da	Use proxy_block placeholder in vhost template for FPM load balancing ... Replaced hardcoded SetHandler + ProxyFCGISetEnvIf directives with a ~~proxy_block~~ placeholder. The shared_httpd_manager generates either a direct SetHandler (single container) or a mod_proxy_balancer config (multiple containers) depending on the site's container count. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-02 09:03:11 -07:00
shadowdaoandClaude Opus 4.6	e9604b8721	Fix shared httpd log tailing for dynamically added vhosts ... The entrypoint used 'tail -f /var/log/httpd/*' which expands the glob at startup. Log files created later (when new vhost configs are added) were never tailed, so 'docker logs' showed nothing for sites added after the container started. Replaced with a loop that re-discovers log files every 60 seconds and restarts tail to include new ones. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-01 22:22:10 -07:00
shadowdaoandClaude Opus 4.6	e81b0df5b8	Reduce idle PHP-FPM memory footprint ... Opcache: - memory_consumption: 128MB → 64MB (most WordPress sites use <40MB) - max_accelerated_files: 10000 → 4000 (sufficient for WordPress) - revalidate_freq: 2s → 60s (reduce stat() calls in production) - enable_cli: Off (don't cache scripts run from command line) FPM workers: - process_idle_timeout: 10s → 5s (faster worker teardown when idle) - max_requests: 500 → 200 (recycle workers sooner to release leaked memory) These changes primarily reduce the baseline memory of idle containers where opcache was reserving 128MB even for small sites. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-01 15:58:42 -07:00
shadowdaoandClaude Opus 4.6	c65f533dcc	Add HEIC/HEIF/AVIF support + fix MariaDB repo for AlmaLinux 10 ... Added ImageMagick-heic package to both Dockerfile and Dockerfile.fpm. This is a separate EPEL subpackage that provides HEIC, HEIF, and AVIF format support via libheif. Without it, ImageMagick is installed but cannot process iPhone photos and modern image formats. Also fixed MariaDB repo URL: AlmaLinux 10 uses $releasever=10 but MariaDB mirrors don't have an 'almalinux10' directory. Changed to 'rhel10' which is the supported path for EL10 derivatives. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-01 15:48:58 -07:00
shadowdaoandClaude Opus 4.6	c6f1f42987	Final vhost template: SetHandler + ProxyFCGISetEnvIf for both paths ... Reverts from ProxyPassMatch back to SetHandler + ProxyFCGISetEnvIf. ProxyPassMatch couldn't override DOCUMENT_ROOT (Apache sets it as a CGI param after all directives run). SetHandler with unconditional ProxyFCGISetEnvIf correctly overrides both: - DOCUMENT_ROOT: set to /home/{user}/public_html (FPM path) - SCRIPT_FILENAME: constructed from DOCUMENT_ROOT + SCRIPT_NAME This fixes WordFence WAF and other plugins that use DOCUMENT_ROOT to locate config/log files. Tested on live sites with WordPress pretty URLs, wp-admin, static assets, and WordFence WAF optimization. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-01 13:58:11 -07:00
shadowdaoandClaude Opus 4.6	e20f5620d7	Fix DOCUMENT_ROOT for PHP-FPM in shared httpd mode ... WordPress plugins like WordFence use $_SERVER['DOCUMENT_ROOT'] to locate config/log files. With ProxyPassMatch, Apache sends its own mount path (/mnt/users/...) as DOCUMENT_ROOT, which doesn't exist in the FPM container. ProxyFCGISetEnvIf can't override DOCUMENT_ROOT when using ProxyPassMatch (Apache sets it after the directive evaluates). Instead, set it via the FPM pool config's env[] directive which takes precedence. create-php-config.sh now adds env[DOCUMENT_ROOT] = /home/$user/public_html when in TCP listen mode (shared httpd), giving PHP the correct path. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-01 13:04:53 -07:00
shadowdaoandClaude Opus 4.6	1490bde56e	Switch shared vhost from SetHandler to ProxyPassMatch for PHP-FPM ... SetHandler + ProxyFCGISetEnvIf doesn't work for path remapping because reqenv('SCRIPT_FILENAME') is empty when the directive evaluates with the SetHandler approach. ProxyPassMatch directly maps .php URLs to the FPM container's filesystem path, bypassing the SCRIPT_FILENAME rewrite issue entirely: ^/(.*\.php(/.*)?)$ -> fcgi://fpm:9000/home/{user}/public_html/$1 Static assets (CSS, JS, images) bypass the proxy since they don't match \.php and are served directly by Apache from the read-only mount. Tested and confirmed working on live site with WordPress (including pretty URLs via .htaccess mod_rewrite). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-01 12:50:54 -07:00
shadowdaoandClaude Opus 4.6	e5e055d198	Fix ProxyFCGISetEnvIf syntax for SCRIPT_FILENAME rewrite ... The previous expr= with s|...|...| substitution syntax doesn't exist in Apache expressions — it silently failed, leaving SCRIPT_FILENAME pointing to /mnt/users/ which PHP-FPM can't find. Fixed to use regex match in the conditional with backreferences: reqenv('SCRIPT_FILENAME') =~ m#^/mnt/users/([^/]+)/([^/]+)/public_html(.*)# -> /home/$1/public_html$3 This is also generic (captures user from the path) so the template no longer needs per-user placeholder substitution for this directive. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-01 12:32:52 -07:00
shadowdaoandClaude Opus 4.6	c68b555a5f	Fix PHP-FPM path mismatch in shared httpd vhost template ... The shared httpd serves files from /mnt/users/{user}/{domain}/public_html but PHP-FPM containers have them at /home/{user}/public_html. When Apache proxied PHP requests via fcgi, SCRIPT_FILENAME pointed to the Apache path which doesn't exist inside the FPM container, causing "File not found". Added ProxyFCGISetEnvIf to rewrite SCRIPT_FILENAME from the shared httpd path to the FPM container path before proxying the request. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-01 12:22:53 -07:00
shadowdaoandClaude Opus 4.6	7f7cb456f0	Add openssl to package installs for AlmaLinux 10 ... AlmaLinux 10 base image does not include openssl by default (AL9 did). Add it explicitly to all three Dockerfiles since it's needed for self-signed cert generation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-01 11:11:10 -07:00
shadowdaoandClaude Opus 4.6	dc6ce2bf12	Upgrade base image from AlmaLinux 9 to AlmaLinux 10 ... Bump all three Dockerfiles to almalinux/10-base with matching EPEL 10 and Remi 10 repository URLs. AlmaLinux 10.1 has been stable since Nov 2025. All PHP versions (7.4-8.5) confirmed available via Remi for EL10. Also removes --allowerasing from shared-httpd Dockerfile since AL10 base does not ship curl-minimal. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-01 10:55:26 -07:00
shadowdaoandClaude Opus 4.6	fc55752379	Fix curl-minimal conflict in shared-httpd Dockerfile ... The almalinux/9-base image ships curl-minimal which conflicts with the full curl package. Add --allowerasing to allow dnf to replace it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-01 10:44:24 -07:00
shadowdaoandClaude Opus 4.6	367da7806c	Fix ImageMagick install: use EPEL packages instead of upstream RPMs ... The official ImageMagick 7.1.2-18 RPMs require GLIBC 2.38 which is not available on AlmaLinux 9 (ships GLIBC 2.34). Switch to EPEL-provided ImageMagick packages which are built for EL9 and guaranteed compatible. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-01 10:44:03 -07:00