stevens-smartpark/smartpark-app
4
0
Fork 0
Code Issues 4 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Update docs/gitea-operations.md

Browse Source
This commit is contained in:
jjradzz
2026-09-29 22:02:56 +00:00
parent 5d639aec2c
commit de01f8cd0f
1 changed files with 22 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/gitea-operations.md
+22 -10
View File
@@ -71,19 +71,31 @@ After moving public TCP 80 from the old app container to Caddy, independent
external checks confirmed that both Gitea and the Two Buttons site redirect
HTTP to trusted HTTPS pages. Gitea's backend TCP 3000, database TCP 5432, and
remote Docker management TCP 2375/2376 were unreachable from the test source.
An SSH connection from the approved administrator source succeeded; a separate
external check could not reach SSH. Record test source and time in the manual.
The DigitalOcean Cloud Firewall was then attached to the correct Droplet;
screenshots show its inbound rules and Droplet assignment. After attachment,
the approved administrator completed a fresh SSH login, public HTTP redirected
to working HTTPS, and external checks found TCP 3000 and 5432 unreachable.
An unapproved-source SSH denial was not retested after attachment. Record the
test sources and times in the manual.
The Gitea certificate was issued by Let's Encrypt for the temporary hostname
and was valid through 2026-12-28 UTC when checked. Caddy manages renewal and
its `/data` state persists, but a renewal test or dry run still needs to be
recorded before claiming that rubric item is complete.
its `/data` state persists. A separate staging-CA hostname successfully
completed an ACME issuance dry run on 2026-09-29; it returned HTTP 200 with a
matching staging certificate. The staging route was then removed and both
live HTTPS sites were rechecked. This proves the ACME challenge and issuance
path works; it does not claim an observed renewal of the live certificate.
## Recovery and records
This deployment has not yet passed a backup-and-restore test. A container
replacement leaves the data volume in place but cannot recover deleted or
corrupt volume contents. Keep a separate consistent backup of both the Gitea
application data and SQLite database, then test restoration in an isolated
instance before claiming recovery. Maintain dated, sanitized evidence in the
team manual and update this page after infrastructure changes.
A container replacement leaves the data volume in place but cannot recover
deleted or corrupt volume contents. On 2026-09-29, the operator briefly stopped
Gitea and archived the entire named data volume, including SQLite, application
configuration, and Git repositories. Gitea restarted normally. The archive was
restored into a separate volume and Gitea instance bound only to Droplet
localhost. The restored test repository and issue returned HTTP 200; the issue
retained its unique marker, and the restored Git endpoint returned the expected
commit. Original and restored browser screenshots were recorded. The backup
archive contains secrets and remains root-only on the Droplet; do not publish
it. Maintain dated, sanitized evidence in the team manual and update this page
after infrastructure changes.