The upstream zerotier plugin template calls File.exists?, which Ruby 3.4
(Cinc Client 19) removed. The plugin failed to collect, so the
`zerotier` attribute disappeared from the node.
Use a local copy of the template with File.exist? and point the
ohai_plugin resource at it.
Gitea was CPU-saturated (load ~6 on 4 cores, 153 concurrent git
cat-file children) by mostly AI/SEO crawlers. PerplexityBot alone made
~43k requests/day to /kosmos/chef/pulls, enumerating tens of thousands
of distinct filter-permutation URLs; others deep-crawled blame/compare
and commit diff/patch pages. The existing edge rate-limit only matched
three user agents and caught none of the traffic.
- Add custom/public/robots.txt: disallow PerplexityBot entirely and,
for everyone else, disallow filter permutations (*?*) and the
expensive render routes (blame/compare/raw/archive/patch/diff).
- Hard-ban PerplexityBot at the edge (403); it ignores robots.txt.
- Add a per-IP "expensive" limit_req zone (10r/m, burst 5) covering the
expensive routes and pulls/issues/milestones filter queries. Normal
requests use an empty key and are unaffected.
- Wire the ban and the limit into the Gitea vhost, and reload OpenResty
when rate_limits.conf changes.
- Bump the openresty submodule so it builds under Ruby 3.4 (Cinc 19):
File.exists? was removed, use File.exist?.
Bump the npm version to 5.0.0-beta.2 and enable the new @sockethub/platform-email platform. Also track Node.js 24.22.2 in the repo-major selector.
The configuration schema change between beta.0 and beta.2 is purely additive, so the generated sockethub.config.json stays valid. Verified on sockethub-1: service active, /health ok, all platforms loaded at *-beta.2.
Runner 5.2.4 -> 5.4.0. No config.yaml changes were required.
5.3.0 scopes cache entries by ref, like GitHub: a job restores from its own
ref, then the base branch, then the repository's default branch, and writes
only to its own ref. Existing (unscoped) caches therefore start out cold once
after the upgrade. 5.3.0 also adds GITEA_* aliases for the built-in GITHUB_*
environment variables and updates dependencies for CVE-2026-78661.
5.4.0 adds Windows and FreeBSD support, runner.ca_file for trusting a private
CA, and container.volumes; it signs release checksums and fixes large cache
uploads, concurrent Dockerfile actions, and git-lfs checkouts on git-lfs
versions before 3.8.0.
The node was still running 5.2.2 because a converge from a branch that
predated the previous upgrade downgraded it. This re-establishes 5.4.0 on
gitea-2; Gitea reports the version sent on each heartbeat, so the runners
updated on restart. Checksum verified against the published binary and
checksums.txt.
BTCPay Server 2.4.7 is the latest release and a security release (fixes 85 findings, incl. 1 critical and 13 high severity). NBXplorer is bumped to 2.6.21 to match the version shipped with BTCPay 2.4.7.
Job containers were pinned to a single shared `gitea-actions` bridge
network, added with the Actions cache to give service containers DNS and a
fixed gateway for the built-in cache server. Because every job of every run
attached to that one network, concurrent jobs' service containers collided
on hostnames: two simultaneous jobs that both expose a `redis` service meant
either could resolve the other's container, causing intermittent cross-job
CI failures that vanished when runs did not overlap.
Set `container.network` back to empty so the runner auto-creates an isolated
user-defined network per job. Embedded DNS still works on each per-job
network, so service containers remain reachable by name, but jobs can no
longer resolve each other's containers.
`cache.host` is left empty for auto-detection; the runner here is a host
binary (systemd), not containerized, so the detected address is reachable
from job containers. The cache port stays fixed per runner. The cache
firewall rule now allows Docker's default address pool (172.16.0.0/12)
because per-job subnets are dynamic, and the now-unused `gitea-actions`
network is removed on converge once idle.
The migration script installed Cinc with no version, which floated and
triggered omnitruck's "You are installing a package without a version pin"
warning. Pass -v latest so omnitruck resolves the current stable build for
the node's platform (20.04 -> 19.2.12, 22.04+/24.04/26.04 -> 19.4.46) and
the warning is suppressed. Document the behavior in the README.
Drop the stale chef_version: 18.2.7 pins from the Test Kitchen suites:
dokken defaults chef_version to "latest", so passing -v is what actually
tracks the current stable client.
Add the missing provisioner.product_name: cinc to the deno and strfry
submodule suites so they run Cinc instead of the license-gated Chef Infra
Client.
Submodule pointers:
site-cookbooks/deno 3795c9e -> c78bc66
site-cookbooks/strfry 9c04b39 -> 8107b1e
Gitea 28.1.0 -> 28.3.0 (skipping 28.2.0). Both are maintenance releases
with no breaking changes and no app.ini changes. They carry a large set of
security fixes: token scope enforcement across many API and web routes,
OAuth2 ACCOUNT_LINKING=auto account takeover, review-triggered Actions
workflows running with repository secrets, stored XSS via Actions artifact
Content-Encoding, SSH certificate principal confusion, OpenID association
CSRF, and several private-data leaks in feeds, profiles, project boards and
issue timelines.
Behavior changes to be aware of, none requiring a cookbook change:
git maintenance now defaults to the gc strategy; profile pages treat token
requests as anonymous and user/org RSS/Atom feeds require read:user or
read:organization; the API rejects changes to issues, labels, milestones
and releases of archived repositories; review-triggered workflows run on
the pull request head; the gitea-vscode OAuth2 application is
pre-registered; email validation is relaxed to what Go's mail.ParseAddress
accepts.
Gitea Actions runner 5.2.2 -> 5.2.4. No config.yaml changes were required.
5.2.4 fixes the v4 artifact API in exec mode so upload-artifact v4 and
later work; 5.2.3 fixes the action header group, dry runs touching the
Docker daemon, and damaged shared action cache trees.
Checksums verified against the published binaries.
One-shot, idempotent helper that prepares an existing (Chef) node for
Cinc Workstation management: installs Cinc Client, points /etc/cinc at
the existing /etc/chef config, drops the deprecated attribute lists, and
pre-seeds the allowed_* attribute lists so the first converge does not
filter node attributes (e.g. vm_host). The node can then be converged as
usual. Verified against drone-1.
- kosmos_email: add the missing Berksfile so its declared dependencies
(hostname/unbound/postfix) resolve
- kosmos_garage: add local path deps for the internal cookbooks so
Berkshelf stops fetching them from Supermarket
- kosmos_rsk: bump rskj to 9.0.4~<codename> (current ppa:rsksmart/rskj
build) and update the matching InSpec assertion; suite now passes 9/9
- document the remaining suite work in doc/test-kitchen-open-tasks.md
Set `product_name: cinc` on the dokken provisioner so kitchen-dokken
uses cincproject/cinc and skips the Chef license prompt, and pin
chef_version where it was missing.
The root Vagrantfile used the license-gated chef_zero provisioner, and
Vagrant's built-in chef provisioner cannot provision Cinc. The
kosmos-bitcoin suite converged nothing (no run_list) and tor-full
targeted long-EOL platforms, so drop both rather than port them.
Cinc Workstation replaces Chef Workstation for driving knife-zero and
Test Kitchen; nodes run (or are moving to) Cinc Client.
- Pin .ruby-version to cinc-workstation
- Move knife config from .chef/ to .cinc/ (Cinc's USER_CONF_DIR) and
update .gitignore, README, AGENTS and docs accordingly. On-node config
now lives in /etc/cinc
- Drop the Gemfile/Gemfile.lock; install knife-zero into Cinc
Workstation's user gem dir with `cinc gem install knife-zero`
- README: rewrite setup/usage for Cinc Workstation
- scripts/postgresql/switch_primary.sh: drop `bundle exec`
CVE-2026-98432 is a use-after-free in the Linux IPv4 TCP option
handling (inet_opt/ireq_opt are freed with a plain kfree()) that is
reachable by sending a TCP SYN carrying IP options. No fixed kernel has
been released for any supported Ubuntu release yet, so mitigate in
role[base] until one is:
* Drop inbound IPv4 TCP segments that carry IP options (no legitimate
traffic uses them) and log the drops, rate limited, so probing is
visible. The rules are added to /etc/ufw/before.rules so they survive
ufw reloads, and are idempotent.
* Disable Multipath TCP where the kernel supports it (5.6+). Go
programs built with Go >= 1.24 open MPTCP listeners by default, which
is the precondition of the published exploit; nothing here needs
MPTCP. Hosts on older kernels (5.4, no MPTCP) skip this.
The sysctl drop-in is written directly rather than via the core sysctl
resource, whose reload runs `sysctl -p` against /etc/sysctl.conf - a
file that no longer exists on Ubuntu 26.04.
Opt node_exporter (Go >= 1.24, so it opened an MPTCP listener) out of
MPTCP with GODEBUG=multipathtcp=0, and restart it when the unit
changes so the change takes effect without a separate restart.
Bump the runtime Ruby to 4.0.9 (and the ruby-build definitions to
v20261023, the first release that defines it), matching upstream's
updated default Ruby for the 4.7.4 security release.
Probot 14 changed its default webhook path from "/" (Probot 7) to
"/api/github/webhooks", but the GitHub App still POSTs to
https://kredits-github.kosmos.org/. Every delivery returned 404, so the
app never processed pull_request events and never created the Kredits
check run. Serve "/" again via WEBHOOK_PATH.
Chef's systemd_unit :create only runs daemon-reload and never restarts a
running unit, so the env change above would not have taken effect until
the next repo change or reboot. Manage the unit with :create/:enable and
restart it from a service resource that subscribes to unit changes.
Apply the same fix to the kosmos-hubot bot resource.
Read the hal8000 webhook token from credentials/hubot in the mediawiki and
alertmanager recipes, and drop the now-unused botka_irc-libera-chat,
hal8000_xmpp and hal8000_freenode bags.
raucao
greg