docs(identity): replace 6f items 6 and 7 with monitoring work - #414
Merged
Conversation
Both items were a person standing in for instrumentation that does not exist, which covers the day somebody looked and no day after it. Two hand readings of /dev/shm give the slope on one particular Tuesday. "Watch for real member traffic" needed that traffic inferred from authentik's authorization events, because Caddy writes no access log and the gates record nothing themselves. That second gap is the interesting one, because it is load-bearing for more than one item. A /beheer 403 leaves no trace anywhere, a member refused at a gate leaves no trace, and item 2's negative cases could not be corroborated today for exactly that reason. Turning on Caddy access logging for the gated hosts, filtered to non-2xx, makes all of it directly greppable and is a log directive in the template. The /dev/shm metric plus an alert is the smaller half and warns long before the tmpfs matters rather than after somebody stopped taking readings. Recorded with what was actually observed first: a member did reach the music gate from a mobile carrier on Android, so item 7 is partly met and the rest is tooling rather than patience, and a /dev/shm baseline of 1.1M of 512M was taken because it costs nothing and gives the future alert a sanity check. The member is deliberately not named; the repo is public. Neither replacement counts until its signal has been fired on purpose once. That is the #401 lesson and it is the whole reason this gate is evidence-based: an alert nobody has watched arrive is indistinguishable from silence.
This was referenced Aug 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Scope change to the approved 6f evidence list, agreed with the user. Items 6
and 7 stop being things a person watches and become things the monitoring
covers.
Why
Both items were a human standing in for instrumentation that does not exist.
That is the weakest kind of evidence: it covers the day somebody looked and no
day afterwards.
df /dev/shmreadings a day apart. That gives the slope onone particular Tuesday and nothing after it.
the traffic inferred from authentik's authorization events, because
Caddy writes no access log and the gates record nothing themselves.
That second gap is the interesting one, because it is load-bearing for more
than one item. Today a
/beheer403 leaves no trace anywhere, a member refusedat a gate leaves no trace, and item 2's negative cases could not be
corroborated for exactly that reason.
The replacement
A
logdirective inweb/caddy/Caddyfile.j2; Alloy already ships thecontainer's output. Mind the existing drop stages when adding a source.
/dev/shmusage metric forauthentik-server, plus an alert.Continuous, and it warns long before the tmpfs is a problem. Filling it
stops the outpost writing sessions, which after 6f has no Authelia to fall
back to.
Neither counts until its signal has been fired on purpose once. That is the
#401 lesson and it is not negotiable here: an alert nobody has watched arrive
is indistinguishable from silence, which is precisely how every notification
went nowhere for a month.
What was observed first
Recorded before superseding, because both are real and cost nothing:
address on Android 17 / Firefox 153, off the house network entirely. Item 7
is therefore partly met: music is proven, the apex and
mtghave seen onlythe operator and test accounts and will close themselves as members use the
landing page.
/dev/shmbaseline: 512M total, 1.1M used, 1%, 6 files, container up 3 hours.Kept so the future alert has a sanity check.
The member is deliberately not named in the doc. The repo is public, and a
username plus their mobile carrier is not something to publish.
tests/test-opsec.shdoes not catch that class, only the operator's own username, so it needed
catching by hand.
Checks
bash tests/run.shgreen, zero failing suites.tests/test-opsec.sh7/7. Noem dashes, no lines over 80 columns in the edited range.
Docs only. Does not touch the Status table or the 6f-pre section. Branched from
c4f2106, so it already includes #413.