docs: show the log, and that it holds no addresses
Build docker image and push to registry.bitdeals.org / main-build-job (push) Successful in 24s
Build docker image and push to registry.bitdeals.org / main-build-job (push) Successful in 24s
The Notes explain at length that no visitor's IP address reaches the log and why both loggers are hand-written to keep it that way. Nothing showed it. A reader had to take the claim on faith or read haproxy.cfg. Add a "the log" section to Usage in both READMEs: a real `docker compose logs haproxy` excerpt from a running node, the two log formats broken down field by field, and the point the sample exists to make — the first field is the X-Client-Id pseudonym, and it is all the log knows about who connected.
This commit is contained in:
@@ -75,6 +75,41 @@ docker run --rm -v "$PWD/docker/haproxy.cfg:/tmp/haproxy.cfg:ro" \
|
||||
registry.bitdeals.org/haproxy -c -f /tmp/haproxy.cfg
|
||||
```
|
||||
|
||||
## the log
|
||||
|
||||
`docker compose logs haproxy` on a running node:
|
||||
|
||||
```text
|
||||
haproxy-1 | XFF_HMAC_KEY was not set — generated one for this container.
|
||||
haproxy-1 | [NOTICE] (1) : Automatically setting global.maxconn to 32745.
|
||||
haproxy-1 | rlj13BvDLpJLzzHbutTiC5fjK0OR4YRlPrYnJIHpO7Y= [18/Aug/2026:10:25:25.196] http 1/1 Success
|
||||
haproxy-1 | wgM6JB1uN2AGFKkl67+O7SCx+DHrGttufQw0HDQMSIU= [18/Aug/2026:10:45:10.700] https~ 1/1 SSL handshake failure
|
||||
haproxy-1 | 5056er7Wogz59zFJfaNNelKpEnxzEISztzbgn/omnHg= [18/Aug/2026:10:54:38.337] https~ 1/1 Connection closed during SSL handshake
|
||||
haproxy-1 | 6TPbf9FXhRxBoy+SSpFrOuTvYjZF3RjTQmdCteZWH3s= [19/Aug/2026:04:13:17.521] https~ default-backend-http/main 400 289 0/497 SSTP_DUPLEX_POST /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/
|
||||
```
|
||||
|
||||
**No line carries an IP address, and none can.** The first field is the
|
||||
pseudonym from `X-Client-Id` — HMAC-SHA256 of the visitor's address under
|
||||
`XFF_HMAC_KEY`, base64 — and it is everything the log knows about who
|
||||
connected. Both loggers are written out by hand for exactly that reason: their
|
||||
defaults open with `%ci:%cp`, the address and the port. See Notes.
|
||||
|
||||
The four request lines are the two formats:
|
||||
|
||||
- connection level, `%[var(sess.cid)] [%tr] %ft %ac/%fc %[fc_err_str]` —
|
||||
pseudonym, time, frontend, connection counts, how the connection ended.
|
||||
Everything that dies before a request exists lands here: a client that offers
|
||||
nothing above TLS 1.1, a scanner that hangs up mid-handshake, a probe that
|
||||
opened the port and left.
|
||||
- transaction level, `… %ft %b/%s %ST %B %TR/%Ta %HM %HP` — pseudonym, time,
|
||||
frontend, backend/server, status, bytes, timers, method, path. The last line
|
||||
is a 400 for a stray SSTP probe. The path ends where the query string starts;
|
||||
that part is never logged.
|
||||
|
||||
Successful requests write nothing at all (`option dontlog-normal`), so a log
|
||||
this quiet is the normal state of a working node, not a sign that the loggers
|
||||
are misconfigured.
|
||||
|
||||
## build and publish
|
||||
|
||||
A push to `main` builds and publishes the image
|
||||
|
||||
Reference in New Issue
Block a user