Retire orphaned Django EB app (giten-site2) + decide fate of the ~55k-book catalog (static rebuild vs sunset)

[rdhyee]

Summary

The GITenberg web presence has effectively already moved to static/low-maintenance hosting — gitenberg.org is now a WordPress site on a managed shared host. The old Django site in this repo (giten_site, the giten-site2 Elastic Beanstalk environment) is now an orphaned zombie: nothing in DNS points to it, all its routes are offline, yet it's still running — on the retired Amazon Linux 2 platform (the "AL2 retirement, deadline 2026-06-30" notices) and quietly costing money.

This issue captures the current state and proposes two clean decisions: (1) retire the dead EB app + RDS, and (2) decide whether the ~55k-book catalog / metadata API should be rebuilt as static, or sunset.

Investigated 2026-07-03 (read-only). No secrets in this write-up.

---

Current state (verified)

Content site — already static/low-maintenance ✅

• gitenberg.org and www.gitenberg.org → 67.208.34.241 = WordPress / LiteSpeed on GreenGeeks (managed shared host, off AWS entirely). It's a single "Gitenberg Project" marketing page — no book catalog, no links to books.

Django app (giten_site) — orphaned zombie ❌

• ry.gitenberg.org (the app's own subdomain in ALLOWED_HOSTS) no longer resolves — the EB app is out of the DNS path.
• Every Django route 404s on the live WordPress site: /books, /search, /all_repos.txt, /books/<id>.json|yaml, /faq. The EB URL itself only 301-redirects. So the app's features — ~55,000-book catalog + title search + metadata API — are currently offline.
• The app is Django 1.8.11 (~2015) — uses patterns/url + include(admin.site.urls), pre-1.10 syntax. Last real deploy 2025-04-30.

AWS footprint still running (FEF-master account, us-east-1):

Resource	Detail
EB env	giten-site2-dev3 (app giten_site2) — Status Ready / Health Green right now
Platform	Python 3.8 on 64bit Amazon Linux 2 v3.8.0 — the retired AL2 platform (deadline 2026-06-30)
EC2	1× t3a.micro (i-00c6887dad2339f54, up since 2025-03-29)
Load balancer	1× Application Load Balancer (awseb-AWSEB-QAP8XHEM27XZ) — the biggest cost line
RDS	aaptgauwoocjjj — db.t3.micro Postgres, available, created 2022-04-21 (the Book catalog DB)

Rough idle cost ≈ $35–45/month (ALB + RDS + instance + EBS) for something serving no traffic — plus the maintenance/security liability of an EOL platform and the recurring health/retirement alerts.

What the app actually is (why staticizing is easy)

The entire dynamic surface is one Book table (gitensite/apps/bookinfo/models.py): book_id, repo_name, title, language, yaml. Its source of truth is the GITenberg GitHub metadata — each book repo's metadata.yaml loaded via gitenberg.metadata.Pandata. The Postgres table is just a cache; the catalog is regenerable from GitHub.

Routes (gitensite/urls.py):

• /, /faq, /get-involved, /license, /newsletter/<n> → already static TemplateViews (no data).
• /books, /search → SearchView: lists Book, optional ?q= → title__icontains. That's the whole "search."
• /all_repos.txt → dump of book_id\trepo_url.
• /books/<id>.json|yaml → per-book metadata.

Catalog scale ≈ 55,312 books (assets/GITenberg_repos_list_2.tsv).

Decision 1 — Retire the orphaned EB app + RDS

Nothing points to it; features are offline; platform is retired. Retiring it ends the alerts, the AL2 deadline, and the ~$35–45/mo.

• Preserve first: dump the RDS Book table (or confirm the catalog is fully re-derivable from GitHub) and snapshot the RDS before teardown.
• Then terminate the EB environment (removes EC2 + ALB + ASG) and delete/snapshot the RDS.

Decision 2 — Catalog + metadata API: rebuild static, or sunset?

It's currently offline, so "do nothing" = permanent sunset. If it should live on, it's trivially static (this is the actual "archive mode" work, and it's small):

• Content pages → static HTML (or fold into the WordPress site).
• /books + search → one pre-generated static JSON index (~55k rows) + client-side search (Pagefind/Lunr). title__icontains maps directly to client-side filtering.
• /all_repos.txt + /books/<id>.json|yaml → generated static files, regenerated from GitHub metadata via a scheduled GitHub Action.
• Host on S3 + CloudFront (the stated preference, "like the EbookFoundation site") or GitHub Pages (org is already on GitHub).

Why GITenberg is a good "archive-mode" pilot

It's ~80% done already (content site is off AWS). The only live questions are "retire the zombie" (clearly yes) and "resurrect the catalog as static or let it stay gone?" — a small, low-stakes decision that also clears a standing alert. Much more concrete than speculating about archive mode on unglue.it.

Access note

The AWS inventory above was read-only from the FEF-master account. Teardown (Decision 1) and any S3/CloudFront hosting (Decision 2) are also in that account — coordinate access accordingly.

[rdhyee]

Working static demo of the catalog — live

Built a self-contained static version of the catalog as a proof that Decision 2 ("rebuild the catalog as static") is a small job, not a rebuild:

Live demo: https://gitenberg-dev.github.io/catalog-static/
Source: https://github.com/gitenberg-dev/catalog-static (build.py regenerates the whole site from the GITenberg metadata snapshot — no server, no DB, no AWS)

What it includes:

• Home + live stats, and content pages (FAQ / Get Involved / License).
• Full-catalog search running entirely in the browser (client-side over the whole dataset), ranked by downloads; each book links to its GitHub repo + Project Gutenberg page.
• Everything the old Django giten_site app served (/books search, per-book links/metadata, all_repos) as plain static files hosted on GitHub Pages.

Count correction: the catalog is 43,248 unique books (rows with a Gutenberg id), not ~55k. The earlier 55,312 figure was the raw line count of GITenberg_repos_list_2.tsv, ~12k lines of which have no usable id. (58 languages; ~3.2M recorded downloads.)

This is also the concrete argument for Decision 1 (retire the EB app): its entire user-facing function now runs as static files needing zero maintenance. Could equally be hosted on S3/CloudFront if that's preferred over GitHub Pages.

[rdhyee]

Meeting outcomes (Eric + Raymond, 2026-07-03) + two corrections

Correction 1 — the domain was NOT "migrated to WordPress"; it was lost. gitenberg.org's registration expired and was caught by a drop-catch service: registry Creation Date reset to 2026-06-19, registrar DropCatch.com 953 LLC (NameBright), nameservers → GreenGeeks, and the "Gitenberg Project" WordPress placeholder there was published 2026-06-24. Earlier language in this issue implying an intentional WordPress migration is wrong. Eric suspects Seth held the old registration — investigating before any recover-vs-abandon decision. Meanwhile we should remove links pointing at gitenberg.org from project properties (they now feed the squatter's page).

Correction 2 — the static demo's count (43,248) is stale. It was generated from assets/GITenberg_repos_list_2.tsv, a snapshot that predates the catalog's growth to ~75–76k entries (updates stopped ~a year+ ago). The fuller catalog lives in the EB RDS database.

Decisions:

1. Static-site direction approved.
2. Regenerate the static catalog from the RDS database (not the TSV), review remaining page content for staleness, publish.
3. Then retire the EB environment (dump/snapshot the DB first) — Decision 1 of this issue is confirmed, sequenced after (2).
4. The demo URL (gitenberg-dev.github.io) is unaffected by the domain loss.

[rdhyee]

Catalog regenerated from the live database — count settled

The static catalog now reflects the real database, not the stale 43k TSV. Live: https://gitenberg-dev.github.io/catalog-static/

Definitive count: 74,275 books (settles the meeting's 43k/67k/76k confusion — it's ~74k). Harvested the full bookinfo_book table from the retiring EB app's own HTTP endpoints (the DB itself is firewalled to the EB instances + its password is EB-managed/unretrievable, so this went through the app):

• 69,455 books with clean titles (list pages + per-book JSON metadata) — 22,323 distinct authors, language where available
• 4,820 books whose JSON metadata is broken (endpoint 500s) — recovered title from the HTML book page (derived from repo name); no author/language for these
• 565 candidate ids confirmed absent from the DB (clean 404s)

Search now covers title and author; alphabetical sort; download counts removed (never in the DB — the old TSV's were a one-off 2015 snapshot).

Optional polish (not blocking): a direct SELECT from the DB would give clean titles + language for the 4,820 broken-metadata books and an exact-to-the-row count. That needs a temporary RDS master-password reset (the app is disposable, so it's safe) — teed up but not required. Otherwise this is the publishable archive, and the EB environment can now be retired (snapshot gitensite-pre-dump-20260704 recommended first).

[rdhyee]

Follow-up: refresh download counts from current Project Gutenberg data

The catalog now has an optional "Most downloaded" sort, but with an important caveat baked into the labels: the numbers are Project Gutenberg's download stats from a 2015 snapshot (Eric's GITenberg_repos_list_2.tsv, committed 2015-07-15), covering ~41.8k of the 74k books. They're a decade stale and cover only ~56% of the catalog.

Key finding: the active gitensite database stores no download counts at all — it only ever held bibliographic metadata (verified against the Book/BookRepo models and the live per-book metadata endpoint). So "download popularity" was never GITenberg's data; it was always Project Gutenberg's.

The opportunity (worth Eric's attention — he's PG's director): since the counts are PG's, PG is also the authoritative current source. A refresh could replace the 2015 snapshot with live per-book download counts for all 74k books, turning "Most downloaded" into a real, current ranking of the whole catalog. PG already publishes these (per-ebook pages + the bulk catalog feeds), and Eric has direct access to the authoritative figures.

Proposed follow-up (small, not urgent):

• Pull current PG download counts (bulk catalog feed, or directly from Eric) keyed by Gutenberg id.
• Re-run build.py with those as the download source (the sort machinery is already in place — it just reads a per-id number).
• Drop the "(2015)" label once the data is current.

Filing so it's not lost. Nice side effect: a GITenberg catalog ranked by live PG popularity is a genuinely useful artifact for PG itself.

[eshellman]

download counts are from the rdf feed at the time of addition. No followup needed

[rdhyee]

Thanks Eric — let me play back our understanding so you can correct it if we've got it wrong: the download numbers came from Project Gutenberg's RDF feed at the time each book was added to GITenberg — a point-in-time snapshot per book, not a live count — which is why refreshing them wouldn't mean much. That also lines up with what we saw: there's no download field in the current DB/metadata, so those figures only ever lived in your 2015 repo-list TSV.

So I've left the static catalog's "Most downloaded" sort using those 2015 numbers, labeled (2015) so nobody mistakes them for current, and dropped the refresh idea. Correct us if any of that's off.