Retirement: shut down giten_site (ELB) and replace with deprecation page

[rdhyee]

Decision: shut down giten_site

Per a 2026-04-30 conversation with @eshellman, the GITenberg experiment site (this repo, deployed on AWS Elastic Beanstalk as giten_site2 / env giten-site2-dev3 in account 256928630920 us-east-1) will be retired and replaced with a static deprecation page.

Rationale: The experiment was successful — its core technology has been deployed on Project Gutenberg itself, so the standalone site no longer adds value. Ongoing AWS costs (ELB + RDS + S3) without benefit; aligns with broader 2026 simplification.

Pre-shutdown checklist

• Postgres dump from RDS aaptgauwoocjjj (Postgres 12.22, db ebdb, user ebroot) — see "Postgres backup" section below
• Static deprecation page authored (content describes experiment success + link to Project Gutenberg)
• DNS cutover plan — placeholder live before original goes dark
• Rotate / disable IAM keys referenced by this app (tracked privately — see EbookFoundation/security-private#15)
• Terminate ELB environment (eb terminate giten-site2-dev3) — note this CloudFormation-cascades to the RDS, so dump must be in hand first
• Verify cleanup: ELB application records, security groups, RDS final snapshot retention, S3 buckets, IAM roles tied only to this app

Postgres backup plan

The RDS is CloudFormation-managed by the ELB stack — eb terminate will delete it. The 1-day automated backup retention provides no margin. Take an explicit snapshot or pg_dump before any termination.

# Pg 12 source. pg_dump from Pg 12+ client supports backward compatibility.
# Run from a workstation in the VPC, or via SSH tunnel through the EB instance, or directly on the EB instance.
PGPASSWORD='<from-RDS-master-password>' pg_dump \
  -h aaptgauwoocjjj.cd80uhnba3in.us-east-1.rds.amazonaws.com \
  -U ebroot \
  -d ebdb \
  -Fc -v \
  -f gitenberg-final-$(date +%Y%m%d).dump

Three connectivity options:

1. Add your IP to security group sg-07fab1e8c02ccb16f temporarily (cleanest)
2. SSH tunnel via the EB instance (i-00c6887dad2339f54)
3. Run pg_dump from inside the EB instance and aws s3 cp the result

Suggested archival: s3://<retention-bucket>/gitenberg/2026-final/gitenberg-final-YYYYMMDD.dump. Verify the dump restores into a throwaway local Pg 12 (or compatible) before authorizing the RDS deletion.

Closes implicit

Closes the public security alert in #100 (the fix is "the site is going away"). Detailed rotation tracking lives in a private issue in EbookFoundation/security-private#15 since the public alert and the matching secret in ELB env vars together form the full credential.

Owner / role split

• @eshellman — owns the shutdown decision and execution; performs ELB + RDS teardown; places placeholder
• @rdhyee — assists with locating resources (already done — see Obsidian [[GITenberg Shutdown 2026]]); can run the pg_dump if Eric prefers; tracks the IAM key rotation in security-private

Reference

• Internal tracking note: [[GITenberg Shutdown 2026]] in Raymond's Obsidian vault — has the full AWS resource inventory (ELB, RDS, VPC, SG, EC2 instance ID), connectivity options, and risks.
• Related: EbookFoundation/security-private#15 for the IAM key rotation

[rdhyee]

Stage 1 backup: RDS snapshot complete ✅

Manual pre-retirement snapshot taken from aaptgauwoocjjj (PostgreSQL 12.22, ~20GB):

Snapshot ID:  gitenberg-pre-retirement-20260430-1222
ARN:          arn:aws:rds:us-east-1:256928630920:snapshot:gitenberg-pre-retirement-20260430-1222
Status:       available (100% progress)
Created:      2026-04-30 19:22 UTC
Tags:         Purpose=pre-retirement-backup, CreatedBy=rdhyee, RelatedIssue=gitenberg-dev_giten_site_101

Correction to my earlier framing

I previously claimed eb terminate would delete the RDS via CloudFormation cascade. That's wrong. The CloudFormation template has DBDeletionPolicy: Snapshot, so termination produces a final snapshot before deletion. There's a built-in safety net.

Combined inventory of preservation today:

Layer	Snapshot	Status
1	gitenberg-pre-retirement-20260430-1222 (manual, just taken)	✅ available
2	rds:aaptgauwoocjjj-2026-04-30-04-51 (automated daily)	✅ available
3	rds:aaptgauwoocjjj-2026-04-29-04-52 (automated daily)	✅ available
4	rds:aaptgauwoocjjj-2026-04-28-04-51 (automated daily)	✅ available
5	last-v11 (manual, pre-existing — likely a pre-Pg11→Pg12-upgrade milestone, 2025-01-28)	✅ available
6	Auto-final-snapshot when env terminates	will fire on eb terminate

Data-loss risk: effectively zero. No urgency.

Stage 2 (separate, lower priority): portable pg_dump artifact

Snapshots are AWS-native — they're great for in-AWS restore but not portable to other systems. For a portable archival artifact (a .dump file you can stash in S3, restore into any Postgres, archive long-term), the cleanest path is:

1. Restore gitenberg-pre-retirement-20260430-1222 to a temporary RDS instance (aaptgauwoocjjj-dump-temp or similar) with a fresh known master password
2. pg_dump -Fc from the temp instance to a local file
3. Upload to S3 with an appropriate retention policy
4. Delete the temp RDS instance

Cost: ~$0.02–0.05 for a few hours of db.t3.micro. Can be done at any leisurely point — no time pressure since the snapshots are already preserving the data.

@eshellman if you'd prefer to provide the master password directly so I can pg_dump from the live RDS, that's also fine and saves the temp-instance round-trip; otherwise I'll plan the snapshot-restore approach.