Skip to content

Retire the old deployment's config and docs once its replacement is running #722

Description

@willhea

What needs doing

The repository still carries configuration and documentation written for a hosted instance that is being shut down, and it should be removed or rewritten once its replacement exists, not before. The old instance ran under the previous GitHub organisation and is being retired as part of the move to civictechdc. A new deployment is planned to replace it, and until that lands these files are the only written description of how the service was actually run, so deleting them now would destroy the reference needed to stand the new one up.

This issue is the list of what to revisit at cutover. Each item is inert today and none of it blocks anything.

Four artifacts, all present on develop:

  1. web/webapp/.htaccess contains Apache RewriteRule directives that force HTTPS. Two things make it removable rather than merely stale. It was already unused while the old site was running, because Apache proxied every request to uvicorn rather than processing the directory, and the application serves it to the public. web/app.py mounts web/webapp/ as StaticFiles at /, so the file is reachable at /.htaccess on any deployment of this app.

  2. The redeploy line in docs/web-compare.md: After deploy: `git pull && uv sync --no-dev && sudo systemctl restart deltatrack` (see private deployment runbook). Both the command and the pointer describe the retired host. The pointer is one of the two references tracked by Production deployment and recovery instructions are only accessible to one maintainer #546 (the production deployment and recovery instructions exist only on one maintainer's machine).

  3. The production rate-limit guidance in docs/web-compare.md, which states that production runs a single uvicorn worker and warns that putting a CDN in front of Apache breaks the rate-limit key, because _rate_limit_key reads the last X-Forwarded-For entry and a CDN edge address collapses every client into one shared bucket. The topology it describes will not exist, but the trap is real and applies to any replacement that fronts the app with a proxy or CDN. This one wants rewriting against the new topology rather than deleting.

  4. force_https_behind_proxy in web/app.py, an HTTP to HTTPS redirect middleware that only does anything when a proxy forwards X-Forwarded-Proto: http or port 80. Whether to keep it depends on how the new deployment terminates TLS. It is host-agnostic and harmless, so the default is to keep it.

Three mentions of the old hostname also survive under docs/research/. Those are dated analyses rather than current instructions, so the reasonable default is to leave them; they are listed here only so the sweep is complete.

How it surfaced

Found while repointing the repository's references after the organisation transfer. The hostname and organisation rename was done then; these four are the artifacts that outlive a rename because they describe a deployment rather than a name.

Verified on branch worktree-repo-ownership-civictechdc @ 977e9345, which is develop plus the rename work and touches none of the four files above. The public exposure in item 1 was checked against the application rather than the old host, so the result does not depend on that host still being up:

>>> TestClient(app).get('/.htaccess')
status: 200
first line: # DeltaTrack public site — force HTTPS for all requests.

Why it matters

It unblocks nothing on its own, which is the point of filing it rather than doing it. The risk being managed is the opposite one: a future contributor reads systemctl restart deltatrack or the single-worker rate-limit note as current fact and acts on a topology that no longer exists. docs/web-compare.md now labels these as describing the outgoing setup, which holds the line until the replacement is real, and this issue is the reminder to finish the job at that point.

Item 1 is the only one with any present-day consequence, and it is small: a dead Apache config file is publicly readable on whatever is serving the app. It discloses no credential. It can reasonably be removed ahead of the rest.

Related work

The new deployment likely touches, and may resolve, several existing issues. Worth reading together rather than in isolation:

Note for #546

#546 argues its case partly by citing docs/https-redirect.md as an existing example of deployment configuration the project publishes rather than keeps private. That file has since been deleted, because it documented the retired host's Apache and ISPConfig setup specifically and does not survive it. The argument in #546 still stands on its other example, but the reference itself is now stale.

Unverified

Whether the new deployment will terminate TLS at a proxy at all, which is what decides item 4. No replacement topology has been chosen yet.

Refs #112, #546, #400, #545, #555

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions