feat(crowdsec): arm the bouncer everywhere, drop the per-host override

proxy-2 has been enforcing since 14:21:54 without incident, so the role
default moves to nftables and the host_vars override goes away rather than
being duplicated for proxy-1. proxy-2's rendered config is unchanged by this,
so it will not restart; only proxy-1 does.

The staged rollout did its job and can be read off the deploy log:

  proxy-1: deployed in mode "dry-run"
  proxy-2: deployed in mode "nftables"

and only proxy-2 restarted, which showed up as a 1,887,882-byte startup pull
from its address alone.

The delivery path was tested in enforcing mode with a decision on 192.0.2.1
(TEST-NET-1): both hosts had the ban 3s later as a 205-byte delta, and the
revocation as a 203-byte delta 1-2s after deletion.

What is still not proven is that a packet is actually dropped, and the
measurement for that argues for finishing the rollout rather than waiting.
Requests from banned addresses reaching Traefik stopped after proxy-2 armed —
1 at 14:02, 3 at 14:07, 22 at 14:08, 1 at 14:18, none after — but 25 of those
27 arrived in a single burst beforehand, so at this volume that is consistent
with enforcement rather than evidence of it. With both hosts armed the claim
becomes falsifiable instead: no request from an address in the decision set
should reach Traefik at all, and a single one would prove otherwise.

dry-run remains available per host through inventory/host_vars, which is what
a newly added proxy should get before it enforces.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.woodpecker/deploy-netbird-proxy.yml

@@ -10,6 +10,18 @@ when:
       # install-netbird-proxy.yml also applies the edge bouncer.
       - "ansible/roles/crowdsec-edge-bouncer/**"
       - "ansible/plays/install-netbird-proxy.yml"
+      # The variables that steer those roles, not just the roles themselves.
+      # Without these two, a change that only touches inventory never deploys
+      # and nothing says so: arming the bouncer lives in host_vars, and its
+      # LAPI key lives in group_vars, so both would sit in git looking applied
+      # while the hosts kept running the previous configuration.
+      #
+      # pve_hosts.yml is deliberately NOT listed. It is the single inventory
+      # file for the whole fleet, so listing it would redeploy the proxies for
+      # any unrelated host edit. The cost is that a change to [netbird_proxy]
+      # group membership needs a manual deployment run.
+      - "ansible/inventory/host_vars/proxy-*.yml"
+      - "ansible/inventory/group_vars/netbird_proxy/**"
       - ".woodpecker/deploy-netbird-proxy.yml"
   - event: deployment
     evaluate: 'CI_PIPELINE_DEPLOY_TARGET == "deploy-netbird-proxy"'

ansible/inventory/host_vars/proxy-2.renner.uno.yml

@@ -1,19 +0,0 @@
----
-# Arms the CrowdSec firewall bouncer on THIS host only.
-#
-# The role defaults to dry-run for the whole netbird_proxy group, so the two
-# members can be armed one at a time. proxy-2 goes first deliberately: it is
-# the dual-stack member, while proxy-1 is IPv6-only and the one where every
-# network-shaped problem has surfaced first — the dhcpcd/resolv.conf breakage,
-# and the GitHub download that could not work at all.
-#
-# What flipping this does: the bouncer stops logging what it would block and
-# creates two nftables tables (ip crowdsec, ip6 crowdsec6) with the decisions
-# it holds. It touches no existing chain and sets no chain policy.
-#
-# Rollback is `systemctl stop crowdsec-firewall-bouncer` — a clean stop deletes
-# both tables itself. Setting this back to dry-run and re-running the play does
-# the same through the handler.
-#
-# Remove this file once proxy-1 follows and the role default moves to nftables.
-crowdsec_bouncer_mode: nftables

ansible/roles/crowdsec-edge-bouncer/defaults/main.yml

@@ -28,14 +28,23 @@ crowdsec_bouncer_sha256: f86e4b72693549d99f40a9402abefb894108f047a3fbe6e72fada25
 crowdsec_bouncer_api_url: https://crowdsec.renner.uno/
 crowdsec_bouncer_api_key: "{{ vault_crowdsec_edge_bouncer_key }}"
 
-# STARTS INERT, and that is the point.
+# Enforcing. The bouncer creates two nftables tables (ip crowdsec, ip6
+# crowdsec6) holding the decisions it pulled, touches no existing chain and
+# sets no chain policy — SSH and :443 stay open unless the source is banned.
 #
-# dry-run pulls decisions and logs what it would block without creating a
-# single nftables rule. The first bouncer to arm anywhere enforces ~24k CAPI
-# decisions at once on the only external entry path, so the false-positive
-# window has to come before the enforcement, not after it. Flip to `nftables`
-# one host at a time once the log looks right.
-crowdsec_bouncer_mode: dry-run
+# `dry-run` is the other value: it pulls and logs what it would block without
+# creating a single rule. That is what a new host should be given before it
+# enforces, and what an existing one can be dropped back to, per host through
+# inventory/host_vars, without disarming the rest.
+#
+# Worth knowing before arming anything new: the first bouncer on a path
+# enforces the whole CAPI set at once — around 15k addresses today — so the
+# false-positive window belongs before the switch, not after it. And because
+# this chain sits on the INPUT hook while these hosts run no other firewall,
+# there is no conntrack rule accepting established flows ahead of it: a banned
+# address is dropped even when it is answering our own outbound connection.
+# That is why capi_whitelists.yaml carries the proxies and netbird.renner.uno.
+crowdsec_bouncer_mode: nftables
 
 crowdsec_bouncer_update_frequency: 10s
 crowdsec_bouncer_log_level: info

kubernetes/apps/llama-server/deployment.yaml

@@ -81,19 +81,23 @@ spec:
             # every exposed name, area and floor. At 16384 the request was
             # refused outright.
             #
-            # --ctx-size is per slot, not the total: /props reports
-            # n_ctx_slot equal to this value while running four slots, where a
-            # total would have divided down to 4096. Doubling it alone would
-            # therefore double the KV cache, so the slot count halves in step
-            # and the allocation stays where it is today — 24979 MiB of the
-            # 32Gi limit, most of it the 19.5 GiB of weights.
+            # --ctx-size is the total and llama.cpp divides it across the
+            # slots, so 65536 over two slots is 32768 each.
+            #
+            # It does not read that way without --parallel, and the reason is
+            # in `llama-server --help`: --kv-unified defaults to enabled only
+            # "if number of slots is auto". Leaving --parallel unset therefore
+            # bought a single KV buffer shared across sequences, where every
+            # slot could draw the full --ctx-size — which is why this server
+            # once reported n_ctx_slot 16384 across four slots. Naming a slot
+            # count turns that off and splits the context instead.
             #
             # Two slots is what is actually in use: one holds Home Assistant's
             # prompt, one holds Paperless's. A third caller would queue rather
             # than evict either, which is the better failure mode given a cold
             # prefill of this prompt costs around two minutes.
             - --ctx-size
-            - "32768"
+            - "65536"
             - --parallel
             - "2"
             # A micro-batch of 2048 or more makes this Vulkan/Mesa stack fail