Skip to content

Port Rails appliance to TurnKey 19 - #22

Open
lirazsiri wants to merge 6 commits into
masterfrom
wish/rails-v19-trixie
Open

Port Rails appliance to TurnKey 19#22
lirazsiri wants to merge 6 commits into
masterfrom
wish/rails-v19-trixie

Conversation

@lirazsiri

Copy link
Copy Markdown
Member

Summary

  • port the Rails appliance to TurnKey 19 on Debian Trixie
  • update application installation, configuration, and runtime integration for the supported Trixie stack
  • add executable v19 smoke coverage and retain the accepted migration evidence

Validation

  • passed the configured Trixie root build in the Docker-based TKLDev 19 harness
  • passed noninteractive firstboot and the primary application workflow
  • passed dependency provenance and updater checks recorded in TESTING.md
  • git diff --check origin/master...HEAD

Replace the changing rbenv and latest-gem build with Debian 13 packages for Ruby, Rails, Passenger, MariaDB and Node.js. Generate and locally lock a minimal sample application, update the Apache and first-boot integration for the packaged runtime, and remove the obsolete JavaScript asset pipeline.

Add functional acceptance coverage for normal service supervision, Apache and Passenger delivery, TLS, the documented Webmin surface, Rails credential rotation, a MariaDB write/read/delete roundtrip, and signed APT updater candidates. Verification: Bash syntax checks, git diff --check, Trixie package-policy checks, and a disposable Debian container proof of Rails 7.2 through Passenger with a MariaDB roundtrip.
The Debian-only build no longer runs the shared Rails configuration that previously moved application logs into /var/log. The first exact Trixie build therefore reached the final ownership step with no railsapp log directory.

Move the generated log directory to /var/log/railsapp and retain the application symlink before applying runtime ownership. This preserves the established logrotate and Passenger paths. Verification: bash -n conf.d/main; git diff --check; exact run 20260824t084016z-2148-10635 reached this step after Rails generation and local Bundler resolution.
The second exact run completed build, import, normal boot and firstboot, then stopped at the first delivery assertion after the Passenger module check. A focused Trixie reproduction confirms the module assertion itself passes, leaving the test-only requirement for one exact redirect status as the failed gate.

Follow the HTTP entry path and verify that it reaches the Rails landing page, then retain the direct HTTPS, Passenger header and live process checks. This tests the documented SSL-enabled application flow without depending on an undocumented redirect code. Verification: bash -n tests/v19.sh; git diff --check; focused Debian Trixie Passenger module assertion.
Passenger otherwise falls back to an account with no usable home directory and cannot read the root-owned Rails master key, causing the documented application endpoint to return HTTP 500 after firstboot regenerates credentials.

Enable a global Passenger default user that matches the application runtime directories and the master-key group. This keeps the existing root-owned application source contract while allowing the normal Apache request path to boot Rails.

Verified shell syntax and Apache directive placement against the retained runtime failure evidence.
The runtime test had already loaded Passenger and served the Rails application over HTTP and HTTPS, but passenger-status then failed because its harness-generated Unix socket path exceeded the kernel limit.

Keep the main-flow proof focused on the loaded Apache module, successful production application requests, and the Passenger response header. This avoids treating an environment-specific diagnostic command limitation as an appliance failure.

Verified shell syntax, documentation crosswalk consistency, and whitespace checks.
Link the exact passing harness run to its tested source and harness revisions, report checksum, package versions, and verified application flows so reviewers can reproduce and audit the v19 candidate.

Record the two low-impact diagnostic warnings observed during functional testing and explain why neither changes the normal appliance contract.

Verified the retained evidence bundle with SHA256SUMS, documentation formatting, shell syntax, and whitespace checks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant