Port XOOPS appliance to TurnKey 19 - #20
Open
lirazsiri wants to merge 9 commits into
Open
Conversation
Install the maintained official XOOPS Core 2.7.3 release at an exact commit and verified archive digest, update the LAMP integration for current PHP and MariaDB, and keep generated database and administrator credentials out of process arguments and build traces. Add an authenticated HTTPS acceptance probe for firstboot login, custom-block create and public read, database persistence, and the official stable update channel. The updater resolves official release tags to commits, preserves generated state, creates backups, and stages the upstream browser-supervised upgrader. Verified with Bash syntax checks, Python compilation, diff checks, source-tree secret-argument and documentation punctuation scans, updater usage-boundary behavior, and required test-environment failure behavior. Exact appliance acceptance remains pending because the shared Wave 2 runner is missing its cleanup dependency.
Do not install the unconfigured mainfile template before invoking the upstream wizard. Including that template on the first request leaves XOOPS_VAR_PATH empty, prevents the installer from establishing its session, and stops schema creation. Keep mainfile creation within the official page_configsave flow so the configured external data and library paths are written together.
Define the application root before loading XOOPS's guarded version file from CLI contexts. Without that bootstrap, build provenance, acceptance, and updater checks read the guard message instead of the runtime version. Keep all three identity boundaries on the same probe so recorded, tested, and updated source identities remain comparable.
Use the left block zone for the seeded welcome content and the authenticated create/read fixture. XOOPS maps side 0 to the left collection, which the pinned xbootstrap5 theme renders; its prior top-center side 5 is omitted by that theme. This keeps the appliance and acceptance flow aligned without carrying a theme override.
Bind direct persistence assertions to the appliance's XOOPS database instead of relying on an undeclared environment variable. This lets the already-passing web round trip proceed to its SQL and updater checks under nounset. The correction changes only test execution and does not alter appliance behavior.
Restart the XOOPS web service after the shared certificate hook and database credential rotation. Apache can enter active state while its certificate files are being replaced, then exit before the shared hook's active-service guard decides whether to restart it. This lane-local recovery keeps the normal first boot serving HTTPS without changing shared infrastructure.
Record the exact clean behavioral commit, source and harness hashes, configured-root boundary, runtime checks, updater result, cleanup, and retained report from the passing Wave 2 acceptance. Map each README identity claim to its observed result and preserve the two upstream-supervision limitations for independent review.
The web installer echoed generated database configuration into retained build logs even though shell tracing was disabled around credential creation. Send installer response bodies to /dev/null while retaining curl's fail-on-HTTP behavior and shell errexit propagation. Verified with bash syntax checking, diff validation, and focused installer-call counts before the exact Wave 2 rerun.
Replace the superseded credential-bearing run references with the exact passing rerun at the executable correction commit. Record the retained checksums and count-only disclosure scan so reviewers can verify that installer responses no longer expose bootstrap database credentials. Verified the documented run ID and source, input, and build hashes against report.txt; all retained checksums pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Source and update path
Validation
20260826t070502z-6411-28610e2fb4a0bb83751b378508b655e8d7e077ba9069579f2e8759aed69a2598c2addThe exact behavioral build used source commit
0e1801f327b13ceeffeffa153859fd2e872b02d0. The accepted PR tip adds the reviewed evidence and testing-documentation delta recorded in the commit history.Known limitation: Docker runtime does not exercise installer, kernel, or hardware behavior. The Docker kernel rejects the appliance hostname firstboot call and systemd-sysctl unit; application services are checked explicitly.
The Docker acceptance exercises the normal systemd and firstboot path, primary authentication, identity-defining behavior, persistence, required services, package provenance, and updater evidence. It deliberately does not repeat ISO or installer testing because the Core/TKLDev v19 format path was exercised separately.