jlxq0/lindner_web
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages 1 Wiki Activity Actions

This site is already on fondue; what is left is a stale copy, dead manifests, and xq0.net #1

New issue
Open
opened 2026-08-24 23:49:48 +00:00 by jlxq0 · 1 comment
jlxq0 commented 2026-08-24 23:49:48 +00:00
Owner
Copy link

Investigation only — nothing migrated, no DNS touched.

This one came to me as "hosted somewhere nobody knows, move it to our own infrastructure". That premise is wrong, and the real finding is more useful: the site is already on our infrastructure and has been since 2026-07-12. What is actually outstanding is a stale second copy of it here, a dead deployment in this tree, and a domain left pointing at nothing.

The site is on fondue

www.lindner.earth is served by static-sites on fondue, through the anycast edges:

$ curl -sSI https://www.lindner.earth
HTTP/2 200
cache-status: Souin; fwd=uri-miss; stored; key=HEAD-https-www.lindner.earth-/
content-security-policy: default-src 'self'; script-src 'self' 'sha256-EDv/...'

Edge Caddy vhost binds 2001:df7:2b40::4 and reverse-proxies [2001:df7:2b40:1::100]:80, the shared static-sites origin. Its comment reads "consolidated from jlxq0/lindner_web 2026-07". This repository's own README.md says the same thing: "The repository retains its xq0.net name for historical reasons. The canonical host is lindner.earth."

So the site is fine. Three things around it are not.

1. There are two copies of this site, and this one is the stale one

The live content is vendored at oddie-apps/static-sites/sites/www.lindner.earth/. Comparing it against this tree:

file
js/xq.js, css/crt.css, js/profile.js, robots.txt, sitemap.xml byte-identical
index.html differs — 8,638 bytes here, 9,516 bytes live

The live copy is ahead by two changes that were never made here:

  • Plausible analytics (static-sites 252859d, 2026-08-12) — the <script defer data-domain="lindner.earth" src="https://stats.oddie.app/js/script.js"> tag, together with a comment recording that data-domain must match a Plausible site exactly or every event is discarded server-side with no visible error, and that this host's stricter CSP needed stats.oddie.app in both script-src and connect-src — script-src alone loads the file and then connect-src blocks every event it sends, which looks exactly like "no visitors".
  • Cache-busting ?v=1 on the css and js references (599e711, 2026-07-12).

This repository's AGENTS.md tells you to edit src/xq.js, run npm run build, and commit both. That workflow is correct for the bundle and produces a site nothing deploys — and if the built output were ever copied over the live one, it would silently remove analytics. Two copies, and this is the wrong one.

Decide which is authoritative. Either this repository becomes the source and static-sites vendors from its build (which means bringing the two index.html changes back here first), or this repository is retired to a source-of-record for src/xq.js and the deployable truth is static-sites. Either is defensible; carrying both silently is not.

2. k8s/ describes a deployment that does not exist

k8s/deployment.yaml declares a lindner-web Deployment in namespace web, 2 replicas with pod anti-affinity, pulling from forge-registry. The web namespace on fondue contains exactly one Deployment:

$ kubectl get deploy -n web
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
static-sites   2/2     2            2           51d

lindner-web was superseded by the static-sites consolidation and its manifests were left behind. Anyone reading this tree would reasonably conclude the site runs from its own image. Delete them, or if the intent is to go back to a dedicated image, say so in the file.

3. xq0.net points at GitHub Pages and serves a certificate error

This is the only genuinely broken thing found, and it is the leftover of the migration this repository is named after.

$ dig +short xq0.net A
185.199.108.153  185.199.109.153  185.199.110.153  185.199.111.153   # GitHub Pages

$ curl -sSI https://xq0.net
curl: (60) SSL: no alternative certificate subject name matches target host name 'xq0.net'

$ echo | openssl s_client -connect xq0.net:443 -servername xq0.net | openssl x509 -noout -text
SAN: *.github.com, *.github.io, *.githubusercontent.com, github.com, github.io, githubusercontent.com

No Pages site claims the apex, so GitHub serves its default wildcard. Ignoring the certificate, the response is a 404. And www.xq0.net does not resolve at all — there is no record for it.

Every HTTPS visitor to xq0.net gets a browser certificate warning followed by a 404. It has presumably been that way since the site became lindner.earth.

Three options, and this is Julian's call because it is about what the domain is for:

  • Redirect it. Point the apex at the web anycast and add an edge vhost 301ing xq0.net and www.xq0.net to https://www.lindner.earth/. Preserves any old inbound link and costs one vhost.
  • Retire the web records. Delete the eight A/AAAA, keep the zone for mail. xq0.net still receives and sends mail through Stalwart and Postal with DMARC p=reject, so the zone stays either way.
  • Leave it. Only defensible if nobody ever visits it, and a certificate warning on a personal domain is a poor advertisement.

Two more dangling records in this zone

jf.xq0.net and mc.xq0.net both A to 101.100.163.70, and both answer — with a certificate for CN=unifi.yuzu.fish, from the home nginx. Same class as bluemap-create.lindner.earth, which is already tracked in oddie-apps/infrastructure#4. Either they are live services that need their own certificate, or they are leftovers to delete. Worth establishing what jf and mc were.

What is already fine and should not be disturbed

xq0.net's mail posture is complete and deliberate: MX 10 mx.kampong.social, Stalwart RSA and ed25519 DKIM, Postal with its own selector, DMARC p=reject with aggregate and failure reporting, TLSRPT, and the three FastMail fm1-3 DKIM CNAMEs restored byte-for-byte on 2026-07-30 after the estate-wide lockdown had bounced legitimate family mail. None of the options above touches any of it.

Remote

This checkout points at github.com/jlxq0/xq0.net. On this forge the repository is jlxq0/lindner_web — the same repository, renamed, and jlxq0/xq0.net still 301s to it. Both are at 3b01b1c, so nothing has diverged; the forge remote is canonical and repointing the checkout is independent of everything above.

Investigation only — nothing migrated, no DNS touched. This one came to me as "hosted somewhere nobody knows, move it to our own infrastructure". That premise is wrong, and the real finding is more useful: **the site is already on our infrastructure and has been since 2026-07-12.** What is actually outstanding is a stale second copy of it here, a dead deployment in this tree, and a domain left pointing at nothing. ### The site is on fondue `www.lindner.earth` is served by `static-sites` on fondue, through the anycast edges: ``` $ curl -sSI https://www.lindner.earth HTTP/2 200 cache-status: Souin; fwd=uri-miss; stored; key=HEAD-https-www.lindner.earth-/ content-security-policy: default-src 'self'; script-src 'self' 'sha256-EDv/...' ``` Edge Caddy vhost binds `2001:df7:2b40::4` and reverse-proxies `[2001:df7:2b40:1::100]:80`, the shared `static-sites` origin. Its comment reads "consolidated from jlxq0/lindner_web 2026-07". This repository's own `README.md` says the same thing: *"The repository retains its `xq0.net` name for historical reasons. The canonical host is `lindner.earth`."* So the site is fine. Three things around it are not. ### 1. There are two copies of this site, and this one is the stale one The live content is vendored at `oddie-apps/static-sites/sites/www.lindner.earth/`. Comparing it against this tree: | file | | |---|---| | `js/xq.js`, `css/crt.css`, `js/profile.js`, `robots.txt`, `sitemap.xml` | byte-identical | | `index.html` | **differs** — 8,638 bytes here, 9,516 bytes live | The live copy is ahead by two changes that were never made here: - **Plausible analytics** (`static-sites` `252859d`, 2026-08-12) — the `<script defer data-domain="lindner.earth" src="https://stats.oddie.app/js/script.js">` tag, together with a comment recording that `data-domain` must match a Plausible site *exactly* or every event is discarded server-side with no visible error, and that this host's stricter CSP needed `stats.oddie.app` in **both** `script-src` and `connect-src` — `script-src` alone loads the file and then `connect-src` blocks every event it sends, which looks exactly like "no visitors". - **Cache-busting** `?v=1` on the css and js references (`599e711`, 2026-07-12). This repository's `AGENTS.md` tells you to edit `src/xq.js`, run `npm run build`, and commit both. That workflow is correct for the bundle and produces a site nothing deploys — and if the built output were ever copied over the live one, it would silently remove analytics. Two copies, and this is the wrong one. Decide which is authoritative. Either this repository becomes the source and `static-sites` vendors from its build (which means bringing the two `index.html` changes back here first), or this repository is retired to a source-of-record for `src/xq.js` and the deployable truth is `static-sites`. Either is defensible; carrying both silently is not. ### 2. `k8s/` describes a deployment that does not exist `k8s/deployment.yaml` declares a `lindner-web` Deployment in namespace `web`, 2 replicas with pod anti-affinity, pulling from `forge-registry`. The `web` namespace on fondue contains exactly one Deployment: ``` $ kubectl get deploy -n web NAME READY UP-TO-DATE AVAILABLE AGE static-sites 2/2 2 2 51d ``` `lindner-web` was superseded by the `static-sites` consolidation and its manifests were left behind. Anyone reading this tree would reasonably conclude the site runs from its own image. Delete them, or if the intent is to go back to a dedicated image, say so in the file. ### 3. `xq0.net` points at GitHub Pages and serves a certificate error This is the only genuinely broken thing found, and it is the leftover of the migration this repository is named after. ``` $ dig +short xq0.net A 185.199.108.153 185.199.109.153 185.199.110.153 185.199.111.153 # GitHub Pages $ curl -sSI https://xq0.net curl: (60) SSL: no alternative certificate subject name matches target host name 'xq0.net' $ echo | openssl s_client -connect xq0.net:443 -servername xq0.net | openssl x509 -noout -text SAN: *.github.com, *.github.io, *.githubusercontent.com, github.com, github.io, githubusercontent.com ``` No Pages site claims the apex, so GitHub serves its default wildcard. Ignoring the certificate, the response is a **404**. And `www.xq0.net` does not resolve at all — there is no record for it. Every HTTPS visitor to `xq0.net` gets a browser certificate warning followed by a 404. It has presumably been that way since the site became `lindner.earth`. Three options, and this is Julian's call because it is about what the domain is for: - **Redirect it.** Point the apex at the web anycast and add an edge vhost 301ing `xq0.net` and `www.xq0.net` to `https://www.lindner.earth/`. Preserves any old inbound link and costs one vhost. - **Retire the web records.** Delete the eight `A`/`AAAA`, keep the zone for mail. `xq0.net` still receives and sends mail through Stalwart and Postal with `DMARC p=reject`, so the zone stays either way. - **Leave it.** Only defensible if nobody ever visits it, and a certificate warning on a personal domain is a poor advertisement. ### Two more dangling records in this zone `jf.xq0.net` and `mc.xq0.net` both `A` to `101.100.163.70`, and both answer — with a certificate for `CN=unifi.yuzu.fish`, from the home nginx. Same class as `bluemap-create.lindner.earth`, which is already tracked in `oddie-apps/infrastructure#4`. Either they are live services that need their own certificate, or they are leftovers to delete. Worth establishing what `jf` and `mc` were. ### What is already fine and should not be disturbed `xq0.net`'s mail posture is complete and deliberate: `MX 10 mx.kampong.social`, Stalwart RSA and ed25519 DKIM, Postal with its own selector, `DMARC p=reject` with aggregate and failure reporting, TLSRPT, and the three FastMail `fm1-3` DKIM CNAMEs restored byte-for-byte on 2026-07-30 after the estate-wide lockdown had bounced legitimate family mail. None of the options above touches any of it. ### Remote This checkout points at `github.com/jlxq0/xq0.net`. On this forge the repository is `jlxq0/lindner_web` — the same repository, renamed, and `jlxq0/xq0.net` still 301s to it. Both are at `3b01b1c`, so nothing has diverged; the forge remote is canonical and repointing the checkout is independent of everything above.
jlxq0 commented 2026-08-26 05:12:20 +00:00
Author
Owner
Copy link

Three things in this issue are no longer true, and one of them was never true. Re-measured 2026-08-26T05:11Z.

Section 3 is done

xq0.net no longer serves a *.github.io certificate and a 404. The redirect option was taken, in oddie-apps/edge-config PR #15 (feat(xq0): redirect the website to www.lindner.earth), merged as 0a58334.

$ dig +short xq0.net A       ->  203.24.209.4
$ dig +short xq0.net AAAA    ->  2001:df7:2b40::4
$ curl -sSI https://xq0.net
HTTP/2 308
location: https://www.lindner.earth/
x-oddie-edge: sgp-01

No certificate warning, no 404. This section no longer needs Julian's decision.

"www.xq0.net does not resolve at all" is no longer true

Same change. www.xq0.net resolves to 203.24.209.4 and returns the same 308 to https://www.lindner.earth/.

"already tracked in oddie-apps/infrastructure#4" was never true

This is the one worth reading twice. jf.xq0.net and mc.xq0.net were described here as the same class as bluemap-create.lindner.earth, "which is already tracked in oddie-apps/infrastructure#4". They are not in that issue. Its body mentions neither jf, nor mc, nor xq0, nor yuzu, and it is still open.

They still answer:

$ dig +short jf.xq0.net A   ->  101.100.163.70
$ dig +short mc.xq0.net A   ->  101.100.163.70
subject=CN=unifi.yuzu.fish
notAfter=Aug 29 01:05:14 2026 GMT

Untracked while an issue says otherwise is worse than untracked, because it stops anyone looking. Filed properly as oddie-apps/infrastructure#6.

Section 1 and the drift

Both addressed, in this repository:

  • #3 deleted k8s/ and .forgejo/workflows/docker.yaml. The pipeline was not dormant: its last run, #20, was triggered by the merge of #2, the pull request whose content was documenting it as dead. Observed after the deletion: the merge of #3 produced no run, and the merge of #4, a content change to index.html, produced no run and no chore(deploy) commit. main is at the merge commit rather than a self-bump for the first time since 2026-07-11.
  • #4 brought index.html level with the deployed copy, so all twelve runtime files are now byte-identical to oddie-apps/static-sites/sites/www.lindner.earth/. The Plausible tag and ?v=1 are in both. There is still no automation keeping them equal.

Still open, and still Julian's

Which copy is authoritative. Recommendation on the record: retire this repository to source-of-record for src/xq.js and leave oddie-apps/static-sites the deployable, because it is what ArgoCD syncs and a second deployment path for one static site buys nothing.

Two things that follow from whichever way that goes, so they are not being decided here:

  • Dockerfile and Caddyfile describe an origin nobody builds. Two tests hold them to a runtime asset allowlist and a CSP. The CSP is now byte-equal to the one the edge actually serves, checked against the live response header, but it is a copy of a policy that lives in oddie-apps/edge-config and nothing keeps it in step.
  • oddie-apps/static-sites has no AGENTS.md note about www.lindner.earth at all, so nothing on that side records that a second copy exists. Filing that separately.

Unrelated to any of the above, and now done: the repository had a stale master branch at 6837735, 43 commits behind main and 0 ahead, fully contained in main. Deleted, along with the branch protection rule that guarded it. That rule was the only branch protection in the repository, so main now has none, as it had none before. Whether main should be protected is a separate question and has not been answered here.

Three things in this issue are no longer true, and one of them was never true. Re-measured 2026-08-26T05:11Z. ### Section 3 is done `xq0.net` no longer serves a `*.github.io` certificate and a 404. The redirect option was taken, in `oddie-apps/edge-config` PR #15 (`feat(xq0): redirect the website to www.lindner.earth`), merged as `0a58334`. ``` $ dig +short xq0.net A -> 203.24.209.4 $ dig +short xq0.net AAAA -> 2001:df7:2b40::4 $ curl -sSI https://xq0.net HTTP/2 308 location: https://www.lindner.earth/ x-oddie-edge: sgp-01 ``` No certificate warning, no 404. This section no longer needs Julian's decision. ### "`www.xq0.net` does not resolve at all" is no longer true Same change. `www.xq0.net` resolves to `203.24.209.4` and returns the same `308` to `https://www.lindner.earth/`. ### "already tracked in `oddie-apps/infrastructure#4`" was never true This is the one worth reading twice. `jf.xq0.net` and `mc.xq0.net` were described here as the same class as `bluemap-create.lindner.earth`, "which is already tracked in `oddie-apps/infrastructure#4`". They are not in that issue. Its body mentions neither `jf`, nor `mc`, nor `xq0`, nor `yuzu`, and it is still open. They still answer: ``` $ dig +short jf.xq0.net A -> 101.100.163.70 $ dig +short mc.xq0.net A -> 101.100.163.70 subject=CN=unifi.yuzu.fish notAfter=Aug 29 01:05:14 2026 GMT ``` Untracked while an issue says otherwise is worse than untracked, because it stops anyone looking. Filed properly as `oddie-apps/infrastructure#6`. ### Section 1 and the drift Both addressed, in this repository: - #3 deleted `k8s/` and `.forgejo/workflows/docker.yaml`. The pipeline was not dormant: its last run, #20, was triggered by the merge of #2, the pull request whose content was documenting it as dead. Observed after the deletion: the merge of #3 produced no run, and the merge of #4, a content change to `index.html`, produced no run and no `chore(deploy)` commit. `main` is at the merge commit rather than a self-bump for the first time since 2026-07-11. - #4 brought `index.html` level with the deployed copy, so all twelve runtime files are now byte-identical to `oddie-apps/static-sites/sites/www.lindner.earth/`. The Plausible tag and `?v=1` are in both. There is still no automation keeping them equal. ### Still open, and still Julian's Which copy is authoritative. Recommendation on the record: retire this repository to source-of-record for `src/xq.js` and leave `oddie-apps/static-sites` the deployable, because it is what ArgoCD syncs and a second deployment path for one static site buys nothing. Two things that follow from whichever way that goes, so they are not being decided here: - `Dockerfile` and `Caddyfile` describe an origin nobody builds. Two tests hold them to a runtime asset allowlist and a CSP. The CSP is now byte-equal to the one the edge actually serves, checked against the live response header, but it is a copy of a policy that lives in `oddie-apps/edge-config` and nothing keeps it in step. - `oddie-apps/static-sites` has no `AGENTS.md` note about `www.lindner.earth` at all, so nothing on that side records that a second copy exists. Filing that separately. Unrelated to any of the above, and now done: the repository had a stale `master` branch at `6837735`, 43 commits behind `main` and 0 ahead, fully contained in `main`. Deleted, along with the branch protection rule that guarded it. **That rule was the only branch protection in the repository, so `main` now has none, as it had none before.** Whether `main` should be protected is a separate question and has not been answered here.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
bug

   
duplicate

   
enhancement

   
invalid

   
question

   
waiting-on-julian
Blocked on Julian. The ask is in the issue.

  
wontfix
No labels
bug
duplicate
enhancement
invalid
question
waiting-on-julian
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
jlxq0/lindner_web#1
No description provided.