Make the hosting layout a value, not a literal in allod site #165

New issue

Closed

opened 2026-09-06 23:05:44 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-09-06 23:05:44 +01:00

Contributor

Stop hardcoding one hosting product's directory layout into allod site, so a second deployment on different hosting is a value rather than a fork of the command.

Primary goals:

The docroot pattern is data — domains/<domain>/public_html is DirectAdmin's layout, not a fact about static sites, and it is currently a string literal in the command.
The exclusion list is data — the four protected paths are DirectAdmin fixtures, and a host that keeps ACME challenges somewhere else needs a different list, not a patched binary.
Centralisation survives the change — the list must not migrate back into each site repository, because the whole reason it lives in the command is that a per-repository copy eventually goes stale and silently breaks certificate renewal.
Nothing changes for the existing deployment — DirectAdmin stays the default and its current values stay the defaults.

Current state and specifics

Two DirectAdmin-specific facts are compiled in:

cmd/allod/site.go:443 builds the destination as <remote>:domains/<domain>/public_html.
The filter written at deploy time protects /.well-known/**, /.htaccess, /stats/** and /cgi-bin/**.

Both are correct for the hosting this was written against and wrong for hosting that puts a docroot at public_html/<domain> or www/<domain>, or that answers ACME from elsewhere. Because the command writes the filter itself, a deployment cannot override either without changing this repository.

That was the right trade when there was one consumer, and it is worth naming as a deliberate debt rather than discovering it when a second one appears. The trigger for doing this work is a second deployment whose hosting layout differs; until then the defaults are the only values in use and the cost of the abstraction is not yet paid for.

Where the values should live is the open question. A hosting-profile name selecting a built-in set keeps site repositories at one line and keeps the list central. Putting the layout in each site's site.toml would return the exclusion list to N copies, which is the failure this design exists to prevent, so it is the wrong answer even though it is the obvious one.

Scope

In: how a deployment selects a hosting layout, and where the docroot pattern and exclusion list live once they are no longer literals.

Out: adding a second backend to rclone's invocation, and any change to what the exclusion list contains for DirectAdmin. Marked exploratory: the shape should be decided against a real second consumer rather than invented ahead of one.

Stop hardcoding one hosting product's directory layout into `allod site`, so a second deployment on different hosting is a value rather than a fork of the command. Primary goals: - **The docroot pattern is data** — `domains/<domain>/public_html` is DirectAdmin's layout, not a fact about static sites, and it is currently a string literal in the command. - **The exclusion list is data** — the four protected paths are DirectAdmin fixtures, and a host that keeps ACME challenges somewhere else needs a different list, not a patched binary. - **Centralisation survives the change** — the list must not migrate back into each site repository, because the whole reason it lives in the command is that a per-repository copy eventually goes stale and silently breaks certificate renewal. - **Nothing changes for the existing deployment** — DirectAdmin stays the default and its current values stay the defaults. ### Current state and specifics Two DirectAdmin-specific facts are compiled in: - `cmd/allod/site.go:443` builds the destination as `<remote>:domains/<domain>/public_html`. - The filter written at deploy time protects `/.well-known/**`, `/.htaccess`, `/stats/**` and `/cgi-bin/**`. Both are correct for the hosting this was written against and wrong for hosting that puts a docroot at `public_html/<domain>` or `www/<domain>`, or that answers ACME from elsewhere. Because the command writes the filter itself, a deployment cannot override either without changing this repository. That was the right trade when there was one consumer, and it is worth naming as a deliberate debt rather than discovering it when a second one appears. The trigger for doing this work is a second deployment whose hosting layout differs; until then the defaults are the only values in use and the cost of the abstraction is not yet paid for. Where the values should live is the open question. A hosting-profile name selecting a built-in set keeps site repositories at one line and keeps the list central. Putting the layout in each site's `site.toml` would return the exclusion list to N copies, which is the failure this design exists to prevent, so it is the wrong answer even though it is the obvious one. ### Scope In: how a deployment selects a hosting layout, and where the docroot pattern and exclusion list live once they are no longer literals. Out: adding a second backend to rclone's invocation, and any change to what the exclusion list contains for DirectAdmin. Marked exploratory: the shape should be decided against a real second consumer rather than invented ahead of one.