actions runners are in a vm on the same box. they come in through the traefik tls front door.
Gitea's Actions runners ask the server for work every 2 seconds, about 1,800 requests an hour. That is more than the new default of 1,500 an hour (#193), so behind smallwebwaf they would be banned. They are not on Gitea's Docker network, so the setup's allow-list for that network does not cover them.
Definition of done:
The Gitea setup (deploy/gitea, from #187) has one clearly marked setting for the address range of runners in a VM on the same host. Requests from that range are neither counted nor refused by the request and byte limits (SWWAF_RATE_LIMIT_EXEMPT_NETS); every other check still applies.
docs/gitea.md says how to find the address the VM's requests arrive from, as traefik and rproxy see them. A request through traefik's published TLS port may carry the VM's own address or the Docker gateway's, depending on the host's Docker settings.
The setup's test shows that a client in that range is not banned when it goes over the request limit, while a client outside it is. The test lowers the limit so it runs in seconds.
make check passes.
Model: opus-5-5
sneak, in chat on 6 November:
> actions runners are in a vm on the same box. they come in through the traefik tls front door.
Gitea's Actions runners ask the server for work every 2 seconds, about 1,800 requests an hour. That is more than the new default of 1,500 an hour (https://git.eeqj.de/sneak/smallwebwaf/issues/193), so behind smallwebwaf they would be banned. They are not on Gitea's Docker network, so the setup's allow-list for that network does not cover them.
**Definition of done:**
- The Gitea setup (`deploy/gitea`, from https://git.eeqj.de/sneak/smallwebwaf/pulls/187) has one clearly marked setting for the address range of runners in a VM on the same host. Requests from that range are neither counted nor refused by the request and byte limits (`SWWAF_RATE_LIMIT_EXEMPT_NETS`); every other check still applies.
- `docs/gitea.md` says how to find the address the VM's requests arrive from, as traefik and rproxy see them. A request through traefik's published TLS port may carry the VM's own address or the Docker gateway's, depending on the host's Docker settings.
- The setup's test shows that a client in that range is not banned when it goes over the request limit, while a client outside it is. The test lowers the limit so it runs in seconds.
- `make check` passes.
Model: opus-5-5
clawbot
self-assigned this 2026-11-06 18:53:55 +01:00
Plan for the implementer. Start from next once #187 has landed. No Go code changes: the existing setting SWWAF_RATE_LIMIT_EXEMPT_NETS already does this.
The setting: in deploy/gitea/compose.yaml, give servewafSWWAF_RATE_LIMIT_EXEMPT_NETS with a placeholder from the documentation range, 192.0.2.0/24, under a comment that says plainly: replace this with the address range the Actions runner VM's requests arrive from. Add the step to the compose file's header comment and to the start steps in docs/gitea.md.
Finding the address:docs/gitea.md's section "Actions runners" says how: start a runner, then read servewaf's log for its requests (path under /api/actions/) and take their client_ip. Say that this may be the VM's own address or the Docker network's gateway, depending on the host's Docker settings. If it is the gateway, say plainly not to exempt it, since every visitor that arrives from the gateway would be exempt too, and give the Docker setting that makes requests to a published port keep their own address, as far as this host can check it; disclose in the PR body what could not be checked. Drop the text that no longer applies (the runners that stay under the limits).
The test:script/gitea-setup runs the setup with the minute request limit lowered to a few requests, and shows that a client inside the exempt range goes over it without a ban, while a client outside the range is banned. Use whatever client address the test can control; say in the script's comment which.
make check and make gitea-setup pass.
#198 changes the same files at the same time; whichever lands second rebases and keeps both.
Model: opus-5-5
Plan for the implementer. Start from `next` once https://git.eeqj.de/sneak/smallwebwaf/pulls/187 has landed. No Go code changes: the existing setting `SWWAF_RATE_LIMIT_EXEMPT_NETS` already does this.
- **The setting:** in `deploy/gitea/compose.yaml`, give `servewaf` `SWWAF_RATE_LIMIT_EXEMPT_NETS` with a placeholder from the documentation range, `192.0.2.0/24`, under a comment that says plainly: replace this with the address range the Actions runner VM's requests arrive from. Add the step to the compose file's header comment and to the start steps in `docs/gitea.md`.
- **Finding the address:** `docs/gitea.md`'s section "Actions runners" says how: start a runner, then read `servewaf`'s log for its requests (path under `/api/actions/`) and take their `client_ip`. Say that this may be the VM's own address or the Docker network's gateway, depending on the host's Docker settings. If it is the gateway, say plainly not to exempt it, since every visitor that arrives from the gateway would be exempt too, and give the Docker setting that makes requests to a published port keep their own address, as far as this host can check it; disclose in the PR body what could not be checked. Drop the text that no longer applies (the runners that stay under the limits).
- **The test:** `script/gitea-setup` runs the setup with the minute request limit lowered to a few requests, and shows that a client inside the exempt range goes over it without a ban, while a client outside the range is banned. Use whatever client address the test can control; say in the script's comment which.
- `make check` and `make gitea-setup` pass.
https://git.eeqj.de/sneak/smallwebwaf/issues/198 changes the same files at the same time; whichever lands second rebases and keeps both.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
sneak, in chat on 6 November:
Gitea's Actions runners ask the server for work every 2 seconds, about 1,800 requests an hour. That is more than the new default of 1,500 an hour (#193), so behind smallwebwaf they would be banned. They are not on Gitea's Docker network, so the setup's allow-list for that network does not cover them.
Definition of done:
deploy/gitea, from #187) has one clearly marked setting for the address range of runners in a VM on the same host. Requests from that range are neither counted nor refused by the request and byte limits (SWWAF_RATE_LIMIT_EXEMPT_NETS); every other check still applies.docs/gitea.mdsays how to find the address the VM's requests arrive from, as traefik and rproxy see them. A request through traefik's published TLS port may carry the VM's own address or the Docker gateway's, depending on the host's Docker settings.make checkpasses.Model: opus-5-5
Plan for the implementer. Start from
nextonce #187 has landed. No Go code changes: the existing settingSWWAF_RATE_LIMIT_EXEMPT_NETSalready does this.deploy/gitea/compose.yaml, giveservewafSWWAF_RATE_LIMIT_EXEMPT_NETSwith a placeholder from the documentation range,192.0.2.0/24, under a comment that says plainly: replace this with the address range the Actions runner VM's requests arrive from. Add the step to the compose file's header comment and to the start steps indocs/gitea.md.docs/gitea.md's section "Actions runners" says how: start a runner, then readservewaf's log for its requests (path under/api/actions/) and take theirclient_ip. Say that this may be the VM's own address or the Docker network's gateway, depending on the host's Docker settings. If it is the gateway, say plainly not to exempt it, since every visitor that arrives from the gateway would be exempt too, and give the Docker setting that makes requests to a published port keep their own address, as far as this host can check it; disclose in the PR body what could not be checked. Drop the text that no longer applies (the runners that stay under the limits).script/gitea-setupruns the setup with the minute request limit lowered to a few requests, and shows that a client inside the exempt range goes over it without a ban, while a client outside the range is banned. Use whatever client address the test can control; say in the script's comment which.make checkandmake gitea-setuppass.#198 changes the same files at the same time; whichever lands second rebases and keeps both.
Model: opus-5-5
wrong repo. this is sysadmin work specific to our site, not smallwebwaf code.
Moved to sneak's sysadmin tracker as he said: sneak/sysadmin#5. Closing here.
Model: opus-5-5