docker: drive per-type wiring from a single TYPES list
docker.mk and dockerfile.mk both had a hand-written stanza per type:
four DOCKER_BUILD calls, four DOCKERFILE_RULE calls, four umbrellas.
Adding a fifth type meant editing every block. Collapse them into a
single DOCKER_TYPES / DOCKERFILE_TYPES list plus a double foreach over
images and types.
Per-type quirks (profiling's --build-arg=from=crossbuild and crossbuild
stamp dependency, the optional CB_FROM_$(IMG) override on crossbuild)
move into DOCKER_BUILD_ARGS_<type> / DOCKER_BUILD_DEPS_<type> recursive
variables, so the $(IMG) inside them resolves at the right point in the
foreach. Adding a new type is now: append to the list, drop in the m4
files, optionally set the two lookup vars.
docs-v4: update howto/modules/CHAP for v4, added diagram, and separated doc
into pages for increased readability.
Formatting, typo, and nav fixes (2nd commit).
ci: surface the docker build log when docker.yml fails
DOCKER_BUILD redirects buildkit output to build/docker/build.<image>.<type>
to keep parallel builds from interleaving on stdout. When CI fails,
the workflow log shows the BUILD echo then several silent minutes
followed by Post job cleanup, with no clue what broke. Add an
if-failure cat step in both job variants so the underlying error
surfaces in the run page.
ci: add workflow_dispatch trigger to the CI workflows
Lets a maintainer re-fire any of these from the Actions UI against an
arbitrary branch without having to push an empty commit. Useful when
the failure is in something the workflow consumes externally (an
internal-registry image, a third-party service) and the commit hasn't
changed.
ci: claude diagnosis dedupes against the most recent prior comment
When a CI failure persists across several pushes (e.g. a workflow
re-fires while we're iterating on a fix), the diagnosis bot was
posting an identical comment on every commit. Walk the first-parent
history back up to 20 commits looking for the bot's last diagnosis
for the same workflow, and if classification + failing step +
key evidence all match, skip posting. Print the duplicate-of-<sha>
line so the run log records the decision.
NetworkRADIUS's extras repo ships libkqueue0 only for amd64; on that
arch we install from there so libfreeradius4's `Depends: libkqueue0
(= <NR version>)` resolves cleanly. On every other arch (arm64,
armhf, ppc64el, ...) the toolchain layer source-builds libkqueue and
deposits the .debs in /opt/libkqueue-debs/ for the service runtime
stage to install.
The directory is created unconditionally so the runtime stage's
COPY --from=build /opt/libkqueue-debs/ /tmp/ succeeds whether or not
the build stage produced any .debs.
docker: move per-image state from scripts/docker/build/.state to build/docker
Stamps and build / configure / test logs land in the top-level build/
tree now, next to every other generated artifact. The whole build/ is
already gitignored at the repo root, so the per-dir .gitignore that
hid the old .state/ subtree is gone.
crossbuild.yml's "show build log" steps cat the same files under the
new path.
ci: dockerfile.* in Makefile filter, new state path in crossbuild.yml
Two stale references the docker-pipeline refactor missed:
* Makefile:48 / Makefile:120 filter only excludes targets matching
crossbuild.% / docker.% from the "need Make.inc" gate. The new
dockerfile.* targets weren't in the list, so `make dockerfile.crossbuild.check`
in CI fell through to "Missing 'Make.inc' Run './configure'".
* crossbuild.yml's post-test "show build log" steps cat'd
scripts/docker/crossbuild/{build,configure,log}.<OS>. The stamp +
log dir moved to scripts/docker/build/.state/ with .<type> suffixes
in commit 4f0ce71a6f, and the test cycle log is now test.<image>.crossbuild
rather than log.<image>.
ci: tag built service image under the new freeradius4-service namespace
The docker pipeline refactor renamed locally-built images from
freeradius4/<distro>:latest to freeradius4-service/<distro>:<short-sha>.
The multi-server-tests workflow's `docker tag ... freeradius-build:latest`
step still pointed at the old name and failed with "No such image"
after `make docker.service.ubuntu24` succeeded. Query the same short
sha that DOCKER_BUILD uses so the source tag resolves.
freeradius's libraries are shared objects. Rocky 10's default CFLAGS
ship with -flto=auto -ffat-lto-objects -fPIE but without -fPIC; on
aarch64 the linker then rejects R_AARCH64_ADR_PREL_PG_HI21 relocations
against symbols that might bind externally (e.g. _fr_dbuff_extend_talloc
when libfreeradius-util.la links). Adding -fPIC to the explicit CFLAGS
export keeps the shared-object link viable.
The why-now is unclear. binutils ld's diagnostic in bfd/elfnn-aarch64.c
is identical between binutils 2.35 (EL9) and 2.41 (EL10), and the
redhat-rpm-config macros for %optflags / _gcc_lto_cflags / hardened-cc1
also match. The most likely candidate is a gcc codegen change between
gcc-11 and gcc-14 -- gcc-14 on aarch64 appears more willing to emit
adrp direct references to extern functions under -fPIE, and that
survives into the -shared link where the linker (correctly) refuses.
Not confirmed by bisect or .s diff in this commit.
build: regenerate libbacktrace's configure on autoconf-2.70+ hosts
src/lib/backtrace's shipped configure was generated by an autoconf
older than 2.70 and rejects --runstatedir. Rocky 10's redhat-rpm-config
(and any other recent %configure / dh_auto_configure macro that runs
on autoconf >= 2.70) passes --runstatedir down to subdir configures
via AC_CONFIG_SUBDIRS, taking the whole build with it.
Run autoreconf -fi against src/lib/backtrace inside the parent
configure when the build host has autoreconf available, and add a
note next to the autoconf BuildRequires / Build-Depends so a future
reader sees why a project that ships a pre-generated configure
needs autoconf at build time.
docker: build libkqueue from source in the shared toolchain layers
Rocky's arm64 archives don't ship libkqueue at all, and the
NetworkRADIUS extras repo only carries amd64 .debs, so every
type that runs `dnf builddep` or `mk-build-deps` against
freeradius's spec / control was failing on the missing dep.
The runtime service images then re-tripped the same gap on
`dnf install` / `apt install` of the freeradius package.
Two new m4 fragments build libkqueue from upstream HEAD as
proper .rpm / .deb files with `-debuginfo` / `-dbg` sidecar
packages (CMAKE_BUILD_TYPE=RelWithDebInfo so symbols survive,
CPACK_RPM_DEBUGINFO_PACKAGE=ON with an out-of-tree build dir
long enough for cpack's source-path constraint, and
CPACK_DEBIAN_PACKAGE_NAME=libkqueue0 so the cpack-emitted name
matches what freeradius's debian/control expects). Both are
included from the shared toolchain m4 so service / ci /
crossbuild / profiling all pick the same libkqueue up.
The two service templates (deb + rpm) additionally COPY the
runtime package across to the second stage so the final
freeradius install resolves at install time. The inline
non-amd64 libkqueue workaround that used to live in
service.deb.m4 went away -- it's covered by the toolchain
layer now and was previously skipping the debug-symbols build.
Other fixes folded in to land the full image set:
- ci.deb.m4 drops `--no-install-recommends` from mk-build-deps's
apt-get arg so debian/control closures with Recommends-only
pulls actually install (apt's resolver was previously bailing
to "remove the dummy" rather than installing the deps).
- profiling.{deb,rpm}.m4 switch from distro cargo to a one-shot
rustup install, so inferno's transitive crate MSRVs no longer
collide with debian12's rustc 1.63 / Rocky's cargo. Toolchain
is removed after the install to keep the layer small.
- profiling.deb.m4 drops the `google-perftools` binary package
(gone from debiansid / ubuntu26 archives; libgoogle-perftools-dev
ships the pprof binaries directly now).
- profiling.rpm.m4 uses `dnf --skip-broken` so Rocky 10's
missing heaptrack doesn't take down the whole layer.
- common.deb.dbgsym.m4 / common.rpm.debuginfo.m4 install
per-package with `|| true` so the structural Ubuntu LTS
ddebs-vs-main version skew doesn't take down the layer
either; a WARNING line surfaces any miss.
31 / 32 image stamps now build on arm64-Mac. rocky10.service
remains blocked on a freeradius-source bug -- src/lib/backtrace's
configure (autogenerated by an older autoconf) doesn't recognize
the --runstatedir option that Rocky 10's redhat-rpm-config
injects via %configure. That's a freeradius source fix
(autoreconf the submodule), not a docker pipeline change.
docker: type-agnostic lifecycle, profiling for all distros, legacy crossbuild aliases
Splits the surface area further: docker.mk owns the generic image /
container / test machinery for every TYPE; crossbuild.mk is now a
thin alias layer (crossbuild.* -> docker.crossbuild.*) plus the
legacy crossbuild.help. DOCKER_TEST is the renamed type-parameterised
form of the old crossbuild test cycle, so docker.<type>.<image>.test
exists for every (image, type).
Profiling is no longer ubuntu24-only. A new profiling.rpm.m4 mirrors
the deb variant (valgrind, gperftools, heaptrack, kcachegrind, libkqueue
rebuild with debug symbols, FlameGraph, Inferno) using Rocky package
names, and common.rpm.debuginfo.m4 / common.deb.dbgsym.m4 are now
included unconditionally from both ci.* and crossbuild.* templates.
The deb repo URL was wrong (debian-debug.debian.net is unresolvable);
swapped to debug.mirrors.debian.org. The rpm side now goes through
`dnf debuginfo-install` (via dnf-plugins-core) so Rocky's per-version
debug-repo naming shifts don't break the build.
docker: split into dockerfile.mk + docker.mk, lifecycle for every type
Restructures the build-system surface area into two files:
dockerfile.mk owns m4 -> Dockerfile.<type> generation and exposes
dockerfile / dockerfile.TYPE / dockerfile.TYPE.check; docker.mk
includes it and adds the image-build + container-lifecycle layer.
The shared _common.mk / m4-macros.mk indirection went away -- each
macro now lives in the file that calls it.
Lifecycle was previously crossbuild-only (CROSSBUILD_IMAGE_RULE
define). Pulled out into DOCKER_LIFECYCLE and applied to all four
types, so docker.TYPE.IMAGE.up / .down / .sh / .log / .reset works
for service / ci / crossbuild / profiling. Containers are named
$(DOCKER_IMAGE_PREFIX)-TYPE-IMAGE and sleep forever with the host
git tree bind-mounted read-only at /srv/src; an operator can drop
into any image with `make docker.TYPE.IMAGE.sh`. The crossbuild test
cycle (refresh + configure + make test) stays crossbuild-specific
behind CROSSBUILD_TEST, with `crossbuild.IMAGE` retained as a legacy
alias for `docker.crossbuild.IMAGE.test`.
Workflow paths updated for the new target shape (docker.<image>.build
-> docker.service.<image>). The legacy `docker` / `crossbuild` /
`crossbuild.IMAGE` / `crossbuild.common` entry points are kept as
aliases so external muscle memory and existing CI invocations keep
working unchanged.
Restructures the m4-template / make-target surface area exposed by
scripts/docker/. Macros and phonies are now consistently named:
dockerfile.<type>[.check] regenerates files, docker.<type>[.IMAGE][.status][.clean]
acts on the corresponding image. Umbrellas dockerfile / dockerfile.check /
docker.clean cover every type; per-image clean only nukes the stamp
when docker rmi succeeds, so a clean against a still-running container
leaves the state coherent for retry. Image tag namespace lifted to a
single DOCKER_IMAGE_PREFIX variable, stamp + per-build-log paths
relocated under scripts/docker/build/.state/, and CB_DIR stripped of
the project-root prefix so the docker-build invocations log relative
paths.
Debug-symbol install factored into common.deb.dbgsym.m4 (deb/ubuntu
dispatcher) and common.rpm.debuginfo.m4. The deb dispatcher routes
to private _common.ubuntu.dbgsym.m4 / _common.debian.dbgsym.m4 (the
underscore marks them as dispatcher-only), each handling the t64
package-name transition internally. ci and crossbuild templates now
pull in the relevant snippet so test failures inside those images
yield resolvable backtraces. Soft-fail tolerance dropped: a renamed
or retired -dbgsym / -debuginfo package now fails the build at
image-create time instead of silently producing an image without
symbols.
ci: prune locally-built docker images via ci-ttl label
Every image built by the scripts/docker pipeline now carries a
ci-ttl=<duration> label (default 60m, see DOCKER_BUILD in
scripts/docker/m4-macros.mk). This workflow walks each self-hosted
runner host on a 30-minute cron, parses the per-image TTL, and
removes anything whose age exceeds the declared lifetime. Hub-published
images aren't subject to this since they live on Docker Hub rather
than the runners; this is purely a local-disk hygiene job.
Duration parsing accepts go-style suffixes (s / m / h / d); anything
else is logged and skipped so an operator who later sets ci-ttl=keep
or similar doesn't wedge the prune loop.
docker: add profiling image type, layered on the crossbuild base
Carry-over of PR 5834's profiling Dockerfile, refolded onto the
unified DOCKER_BUILD / M4_REGEN_* macros from the previous commit.
The image installs valgrind, gperftools, heaptrack, kcachegrind,
ubuntu-dbgsym repos and libkqueue with debug symbols on top of the
crossbuild image, plus FlameGraph and Inferno for callgraph
rendering.
The profiling step only makes sense on ubuntu (ddebs.ubuntu.com,
dbgsym suffixes), so the regen and build rules are gated to the
ubuntu24 distro via $(filter ...). Build prereqs include the
crossbuild stamp so make wires the dependency correctly, and the
docker build invocation passes --build-arg=from=
freeradius4-crossbuild/ubuntu24:<sha> so the profiling image is
genuinely a child layer rather than rebuilding the entire toolchain.
docker: dedupe service / ci / crossbuild build rules into shared macros
The four-and-soon-to-be-five m4-generated Dockerfile families were
each carrying their own hand-rolled per-image regen rule, drift
detector, and build rule. Fold the common shape into four reusable
macros in scripts/docker/m4-macros.mk: M4_REGEN_RULE for the per-image
m4 -> Dockerfile.<type> rule, M4_REGEN_BUNDLE for the umbrella regen
target, M4_REGEN_CHECK for the regen.check drift detector, and
DOCKER_BUILD for the per-image stamp-tracked docker build.
DOCKER_BUILD derives everything from (image, type): output is
freeradius4-<type>/<image>:<short-sha>, log lands at
$(DD)/build.<image>.<type>, stamp at $(DD)/stamp-image.<image>.<type>,
and every locally-built image is labelled ci-ttl=60m so the
periodic prune workflow can identify ephemeral builds. Local
build stamp paths gained the .<type> suffix; anyone with scripts
that rm the old stamp-image.<image> needs to know.
Adopt the Dockerfile.<type> convention across the m4-generated tree.
The production image is now scripts/docker/build/<distro>/Dockerfile.service
(was Dockerfile), the crossbuild image is Dockerfile.crossbuild (was
Dockerfile.cb). Dockerfile.ci was already correctly suffixed and is
unchanged.
scripts/docker/docker.mk and scripts/docker/crossbuild.mk point at
the new paths in their build / regen / regen.check rules. The
crossbuild.yml workflow comment that mentioned Dockerfile.cb was
updated too; matrix entries and other workflow paths were already
type-suffixed and didn't move.
docker: rename type identifiers to service / ci / crossbuild
The m4-generated Dockerfile family used inconsistent labels: the
production image was called "docker" (overloaded with the make
namespace), the CI base image was called "ci-base", and crossbuild
was already correctly named. Rename the m4 source files
(docker.{deb,rpm}.m4 -> service.{deb,rpm}.m4, ci-base.{deb,rpm}.m4
-> ci.{deb,rpm}.m4), the D_TYPE values passed to m4, and the make
bundle targets to docker.<type>.regen[.check] so all docker-adjacent
targets share a single namespace prefix.
The dispatcher template's "Rebuild this file with" header now points
at the bundle target (make docker.<type>.regen) since per-image regen
phonies were retired in an earlier commit. Workflow steps and the
top-level Makefile conditional include were updated to match; the
docker-refresh.yml inline comment that referenced ci-base.m4 was
corrected too.
skip: cap fr_skip_brackets / fr_skip_xlat recursion at 64
fr_skip_brackets recurses into itself for `(`, calls fr_skip_xlat for `${`/`%{`, and fr_skip_xlat recurses back into fr_skip_brackets. Nothing tracked depth, so an input like `${(((((...` consumed C-stack until SIGABRT. The new fuzzer_cf harness in CI found it; cf_expand_variables now reports the parse error instead of crashing.
Wrap the bodies in static skip_brackets / skip_xlat helpers that carry a depth counter; the public fr_skip_brackets / fr_skip_xlat call them at depth 0 so the API stays unchanged. Cap is 64, matching what fuzzer_cf already filters its inputs at.
docker / crossbuild: declare regen and regen.check targets .PHONY
These targets produce no file output, so make would skip them if a file with the matching name ever appeared in the cwd - cheap footgun, .PHONY is the right hygiene. Stay consistent with the per-image .build target which is .PHONY for the same reason.
crossbuild: regen deb Dockerfile.cb files for fakeroot
`fakeroot` was added to common.deb.toolchain.m4 earlier (to unstick `make deb` on newer dpkg) but the deb-family Dockerfile.cb files weren't regenerated then - only the production Dockerfile and Dockerfile.ci got refreshed. The newly-landed crossbuild.regen.check caught it.
docker / crossbuild: verify generated Dockerfiles match m4 source
New `docker.regen.check`, `ci-base.regen.check` and `crossbuild.regen.check` make targets render each m4 source to a temp file and diff against the committed Dockerfile / Dockerfile.ci / Dockerfile.cb. Fails noisily if a contributor edited an m4 template but forgot to regen + commit.
Wire the checks into docker.yml and crossbuild.yml as a pre-build step. Both workflows fire on push to any branch so the drift is caught at PR time, before stale Dockerfiles get used in a release-side build.
docker.yml: drop the explicit Regenerate Dockerfile step
The Dockerfiles under scripts/docker/build/<distro>/ are m4-generated by contributors locally and committed alongside the m4 source. The workflow doesn't need to rm + regen them before building - the committed file is the canonical version and matches the m4 by virtue of the regen happening at commit time. Drop the step from both job paths (selfhosted and public-fork variants).
docker / crossbuild: drop per-image .regen phony aliases
`docker.<distro>.regen`, `crossbuild.<distro>.regen` and (previously) `ci-base.<distro>.regen` were thin phony aliases over the underlying Dockerfile / Dockerfile.cb / Dockerfile.ci file targets. The file targets already track their m4 deps correctly, so `make scripts/docker/build/<distro>/Dockerfile` does the same job. The bundle targets `docker.regen`, `crossbuild.regen`, `ci-base.regen` now depend on the file targets directly.
While in here, fix the umbrella `docker` / `docker.common` targets - they depended on `docker.<distro>` (no suffix), which was never defined, so `make docker` was a latent error. Point them at `docker.<distro>.build` to match what the help text says they do.
crossbuild: use the workflow name as the job-title prefix
The hardcoded `v4.0.x-` prefix has been stale for years - the inner loop in crossbuild.{deb,rpm}.m4 iterates every `v[4-9]*.[0-9x]*.x` and master branch, so the displayed name was misleading. Use `${{ github.workflow }}` so the prefix follows whatever the workflow is called.
fuzzer: move util to standalone targets, unify test rules
util follows the per-protocol test_point shape (src/lib/util/fuzzer.c exposes util_tp_decode_proto / util_tp_encode_proto) but isn't a wire protocol, so it's a slightly odd entry in FUZZER_PROTOCOLS. Move it to FUZZER_NON_PROTOCOL_TARGETS alongside json/cf/value/xlat. fuzzer_util.c is the FUZZ_PROTOCOL template expansion baked out into a tracked source file; fuzzer_util.mk mirrors the other standalone .mk files.
While doing it, generalise the per-non-protocol test rule to read $(FUZZER_<name>_ARGS) so per-target extras flow through one mechanism. util's entry is "-D share/dictionary" (it needs the dict the same way the wire protocols do); the rest stay empty. The umbrella test.fuzzer and test.fuzzer.merge targets now span both lists.
fuzzer: wire json / cf / value / xlat into test.fuzzer and the schedule
Four fuzzer binaries (fuzzer_json, fuzzer_cf, fuzzer_value, fuzzer_xlat) were built but never run by `test.fuzzer` or the nightly fuzzing workflow - they had no test.fuzzer.<name> targets and weren't in FUZZER_PROTOCOLS. They cover meaningful surface (JSON parsing, config-section parsing, value boxes, xlat expansion) and have been silently unfuzzed for a while.
Add a FUZZER_NON_PROTOCOL_TARGETS list and a FUZZ_NON_PROTOCOL_TEST define that emits the per-target test / merge rules, mirroring fuzzer.mk's per-protocol shape minus the `-D share/dictionary` flag (json/cf/value parse raw bytes; xlat resolves the dictionary itself from argv[0]). Corpus directories are created on demand; no .tar files shipped yet, so the first runs start from scratch. ci-scheduled-fuzzing.yml's set-matrix concatenates both lists so the schedule fans out to all sixteen binaries instead of twelve.
ci-macos / ci-freebsd: parallelise the trailing `make test`
The two workflows already parallelise the per-target test runs above (test.keywords / test.unit / test.modules / test.auth / test.digest), then immediately run `make test` (umbrella target) without -j, serialising whatever sub-targets it pulls in. Match the line above so the final pass also fans out across nproc cores.
The main ci-tests action runs `make -j \`nproc\` test.unit ...` but the fuzzing workflow's test.unit invocation was missing the -j, so it ran sequentially across all unit tests on every fuzzer matrix entry (12 of them) - a significant chunk of the wall-clock per job. Match the main CI pattern.
fuzzer: explicitly link $(LIBS) into the non-protocol fuzzer binaries
fuzzer_value, fuzzer_xlat and fuzzer_cf were missing the TGT_LDLIBS := $(LIBS) line that fuzzer.mk (for the per-protocol fuzzers) and fuzzer_json.mk already carry. They've been getting libtalloc and friends transitively from libfreeradius-*; a binutils linker default flip (`--no-copy-dt-needed-entries` on ubuntu 24.04 vs the older `--copy-dt-needed-entries`) stopped tolerating that, and the link failed with `undefined reference to symbol _talloc_array@@TALLOC_2.0.2`.
These come up routinely in CI workflows: openssh-client for any git-over-ssh deploy step (broke deploy-antora-docs), jq for any JSON-shaping bash, rsync for tree copies. wget was already present. Bake them in once instead of letting each migrating workflow apt-get them per job.
documentation: install openssh-client in deploy-antora-docs
The testbed image carries the build toolchain but not openssh-client, and the deploy step git-clones via ssh from git.networkradius.com. Without ssh git fails with `cannot run ssh: No such file or directory`.
ci-scheduled-fuzzing: pass workflow-env CC to freeradius-deps
The set-matrix step emits PROTOCOL/TOTAL_RUNTIME/UPLOAD_SLOT/NUM_SLOTS but not CC, so `cc: ${{ matrix.env.CC }}` evaluated to empty and the freeradius-deps action's `Install LLVM` step (gated on `inputs.cc == 'clang'`) was skipped. clang-18 was already in the testbed image but the unsuffixed `clang` symlink that step's update-alternatives normally creates wasn't there, so the subsequent `$CC --version` failed with "clang: command not found". Pull CC from the workflow-level env where it actually lives.
GitHub Actions runs `run:` steps under sh (dash on the testbed image) when a `container:` block is set, not bash as on a bare runner. Several existing steps rely on bash arithmetic / quoting / arrays. Set the per-job default to bash on coverity, documentation, and scheduled-fuzzing so behaviour matches the pre-container workflows.
ci-scheduled-fuzzing: read FUZZER_PROTOCOLS from src/fuzzer/all.mk
The fuzzer code moved out of src/bin/ into its own directory in commit 1294535465, but the matrix-set step here kept reading src/bin/all.mk - the sed never matched, PROTOS was empty, and the build failed at `${P:0:-1}` with bash's misleading 'substring expression < 0' (because the empty-string substring index is degenerate). The workflow only runs on schedule so the silent breakage went unnoticed.
Lets us trigger these manually via `gh workflow run` (and the Actions UI) without having to push to coverity_scan / run-fuzzer-* branches just to kick a job. Useful for testing the just-landed self-hosted container migration ahead of the next scheduled run.
move coverity / documentation / fuzzing to self-hosted CI container
These three workflows ran on ubuntu-latest with ~30s of per-job apt setup (NetworkRADIUS repo, mk-build-deps, etc.) that's already baked into the self-hosted-ubuntu24 testbed image. They were also gated by `if:` conditions that mostly only fired for the FreeRADIUS org anyway - coverity needs the COVERITY_SCAN_TOKEN secret, the doc deploys push to FreeRADIUS-controlled infra, fuzzing pushes corpus updates back to the FreeRADIUS LFS. Drop the fork-compat branches, run on the self-hosted Proxmox fleet inside the standard CI container.
coverity loses ~30 lines of apt + mk-build-deps wiring. documentation keeps the asciidoctor/doxygen/graphviz/antora install since the testbed image doesn't carry doc-build tooling, but drops the sudo prefixes (we're root inside the container). scheduled-fuzzing's freeradius-deps action call flips from use_docker=false to use_docker=true so the action skips the host-setup steps it'd otherwise run on a bare ubuntu runner.
ci-freebsd: prefer self-hosted runners on the FreeRADIUS org
Mirror the existing ternary pattern from earlier crossbuild / ci-deb / ci-rpm work: when github.repository_owner is 'FreeRADIUS', use the self-hosted Proxmox fleet (which has the VM hypervisor cross-platform-actions needs for the FreeBSD VirtualBox VM and isn't subject to GH-hosted runner queue contention); otherwise fall through to ubuntu-latest so fork pushes and PRs still run.
All five `uses: ./.github/actions/setup-dind` invocations were anonymous, so the Actions UI displayed them as "Run ./.github/actions/setup-dind" - long, noisy, and not searchable in the step list. Add an explicit `name: setup-dind` to each so they render as "Run setup-dind" and line up with the other named steps.
crossbuild: fix double-slash in m4 paths and auth dind to internal registry
CB_DIR was constructed via `$(dir $(realpath ...))`, which always ends in `/`. Subsequent concatenations of the form `$(CB_DIR)/build` produced rendered paths like `/workspace/scripts/docker//build`, which made the BUILD/REGEN log lines and stamp-file paths ugly (though make itself happily collapses the doubled slash). Strip the trailing slash once at the CB_DIR definition with patsubst so every existing `/foo` concat stays readable.
The dind sidecar's daemon isn't pre-authenticated to docker.internal.networkradius.com - only the self-hosted runner host's daemon is, via the runner's job-started hook, and that auth doesn't propagate into dind. crossbuild now FROMs self-hosted-* via the CB_FROM_<distro> overrides, so the inner build was failing with `401 Unauthorized` on the manifest HEAD. Add an explicit `docker login` step via the existing DOCKER_REPO_USERNAME/_PASSWORD secrets, mirroring what ci-multi-server-tests.yml already does for the same reason.
ci-base.deb: keep the debian/ prefix when staging source for mk-build-deps
Newer dpkg (in ubuntu26, debiansid) routes through /usr/share/dpkg/buildapi.mk, which reads `debian/control` relative to CWD when debian/rules is invoked. The previous COPY flattened the contents of debian/ into /tmp/freeradius-debian/, leaving rules with no `debian/control` underneath it to find - the build failed with `dpkg-buildapi: error: cannot read debian/control: No such file or directory` and an opaque `intcmp: empty value` from buildapi.mk. Older dpkg (debian12, ubuntu22-24, debian13) tolerated the flat layout.
Stage the source as /tmp/freeradius-build/debian/ and run mk-build-deps from /tmp/freeradius-build so debian/rules sees the canonical layout.
ci-base.deb: drop the extras-control mk-build-deps pass
The deb-build job only needs debian/control's closure plus libnl for the eapol_test build; the full scripts/ci/extra-packages.debian.control file is for the self-hosted-ubuntu24 integration testbed (dovecot, freetds, firebird, collectd, ...), and several of its entries either don't exist on older ubuntu/debian releases or have differently-named substitutes. Trying to mk-build-deps it on ubuntu22 failed with the misleading 'Unable to install freeradius-build-deps' - the -f resolver invoked internally by mk-build-deps -i discards the unconfigured meta-package rather than fetch a missing dep.
Cut over to a single mk-build-deps against debian/control, plus an explicit apt-get install of libnl-3-dev / libnl-genl-3-dev. The extras file is left for its actual consumer (scripts/ci/docker/Dockerfile, the ubuntu24 testbed), which uses the equivs-meta-package install path that doesn't double up.
ci-base.deb: purge meta-package between mk-build-deps passes
debian/control and scripts/ci/extra-packages.debian.control both declare
`Source: freeradius`, so both mk-build-deps invocations emit a meta-package
named freeradius-build-deps. Older apt (debian12, ubuntu22) silently
downgraded the first install when the second arrived; newer apt (debian13,
debiansid, ubuntu26 - and likely ubuntu24 next) refuses to reconfigure
and removes the meta-package instead, causing the second pass to fail with:
mk-build-deps: Unable to install freeradius-build-deps
Mirror what scripts/ci/docker/Dockerfile (the self-hosted-ubuntu24 testbed
image) already does: apt-get -y --purge remove freeradius-build-deps after
each install. The transitively-pulled build deps stay installed (marked
auto-installed, but nothing in the image build ever runs autoremove), and
the second mk-build-deps installs cleanly without colliding.
factor common build setup into shared m4 snippets, add ci-base template
The production / crossbuild / CI base Dockerfiles all installed the same
apt retry config, same toolchain, same NetworkRADIUS extras repo - three
times each, slightly differently. The CI bases were also hand-written
under scripts/ci/docker, sitting outside the m4 system the production
and crossbuild Dockerfiles already used.
Extract the shared chunks into scripts/docker/m4/common.*.m4:
The four existing content templates (docker.{deb,rpm}.m4, crossbuild.{deb,rpm}.m4)
rewritten to include() the shared chunks instead of inlining their own copies.
Add a third content template family ci-base.{deb,rpm}.m4 which generates
Dockerfile.ci per-distro - replaces the hand-written Dockerfile.{debian,rocky}
under scripts/ci/docker.
docker.mk gains an M4_SHARED dep list so any snippet change invalidates all
generated Dockerfiles, plus a top-level ci-base.regen that bundles all eight
images (no per-image variant; m4 rendering is milliseconds, not worth the
extra rule duplication). Makefile conditional include extended so
`make ci-base.regen` actually loads docker.mk.
docker-refresh.yml matrix entries for the rocky / deb bases switch from
referencing scripts/ci/docker/Dockerfile.{rocky,debian} + per-row
build_args.from to referencing the generated scripts/docker/build/<distro>/
Dockerfile.ci files directly. No build-args needed because m4 bakes the
FROM at regen time. Paths filter extended so Dockerfile.ci changes trigger
the refresh.
Production / crossbuild renderings shift slightly as a side effect of
sharing the snippets:
- apt timeouts switch from full HTTP Timeout (15s) to TCP ConnectTimeout
(5s). Better behaviour: failover is bounded by reachability, not download
duration, so a slow but progressing mirror isn't aborted.
- All apt-get installs now use --no-install-recommends. Slightly smaller
images; no production-relevant Recommends were in play (lintian / dh-make
/ less were the main ones, none of which the build path needs).
- Production deb image picks up build-essential / ca-certificates /
gnupg2 / lsb-release / make explicitly (was relying on mk-build-deps
pull-through). Same end-state, more cache-stable layer.
- Rocky crossbuild now does the same rpmkeys --import the production
image does. Harmless on a stock rockylinux base, defensive after dnf
update if a key rotation lands.
The hand-written Dockerfile (self-hosted-ubuntu24 testbed),
Dockerfile.docker-cli, and Dockerfile.docker-dind under scripts/ci/docker
stay hand-written - they're specialised CI scaffolding (integration
testbed, dind sidecar, docker CLI wrapper), not build environments, and
don't fit the m4 build-image pattern.
bake CI build environments into pre-baked base images
The rpm/deb/crossbuild jobs previously pulled stock distro images on every
run and re-installed the build-dep closure inline. That made every job
flaky in the face of upstream mirror outages and left rocky-10 broken
because nothing was carving out git's `safe.directory` for the workspace
that the runner UID and the in-container root UID disagree on.
Add two new parametrised CI Dockerfiles under scripts/ci/docker/ - one
for the rpm side (rocky 9/10) and one for the deb side (debian 12/13/sid,
ubuntu 22/24/26). Each bakes in the toolchain, NetworkRADIUS extras,
the full mk-build-deps / dnf builddep closure against the source-tree
control/spec, and `git config --system --add safe.directory '*'`. The
matrix in docker-refresh.yml grows entries for all eight images and now
also triggers on changes to debian/control or redhat/freeradius.spec
(plus a nightly cron) so the closure stays current.
ci-rpm/ci-deb switch their build container to the matching internal
image. The per-job setup-the-world steps go away; mk-build-deps /
dnf builddep stay as cheap top-ups. Both workflows are gated to the
main repo (push) or PRs against it - fork pushes can't reach the
internal registry and were already broken by this transition.
The crossbuild Makefile gains a CB_FROM_<distro> override (empty by
default, so local builds still FROM upstream images and need no internal
infrastructure). crossbuild.yml exports the overrides per-distro, which
kills the docker.io FROM-pull inside dind on every job and lets the
Docker Hub login step go. CI Dockerfiles also relocated from scripts/ci
into scripts/ci/docker for clarity now that there are five of them.
David Korczynski [Sun, 17 May 2026 16:07:38 +0000 (09:07 -0700)]
add fuzzing harness to be consumed by OSS-Fuzz
Adds a fuzzing harness for the xlat* files, which are currently unfuzzed
(see xplat* files here:
https://storage.googleapis.com/oss-fuzz-coverage/freeradius/reports/20260517/linux/src/freeradius-server/src/lib/unlang/report.html)
This harness will be consumed by OSS-fuzz to be run continuously.
Signed-off-by: David Korczynski <david@adalogics.com>
Alan T. DeKok [Sun, 17 May 2026 12:48:52 +0000 (08:48 -0400)]
allow specifying a root attribute in FR_FUZZER_ROOT_ATTR
DER needs a root attribute, as the dictionary is really just
a large collection of OIDs. We need to be able to fuzz
certificates, CSRs, etc. all individually
David Korczynski [Sat, 16 May 2026 14:00:44 +0000 (15:00 +0100)]
add new harness targeting value parsing
The value.c has around 25% code coverage at the moment: https://storage.googleapis.com/oss-fuzz-coverage/freeradius/reports/20260514/linux/src/freeradius-server/src/lib/util/value.c.html
and this extends on that to achieve 70%+ from a local run.
Signed-off-by: David Korczynski <david@adalogics.com>
When several CI workflows fail on the same commit, the diagnosis
concurrency group queues their runs and any pending duplicates get
cancelled by GitHub. Those have conclusion=cancelled (not skipped)
so they were slipping past the cleanup. Include them.
cleanup: per-conclusion targeting (keep failures, drop noise)
Refine what each side of the cleanup deletes vs keeps:
Claude CI Failure Diagnosis
delete: skipped
keep: success (paired with the commit comment they posted)
keep: failure (we want to know if a diagnosis crashed)
Cleanup Skipped Diagnosis Runs (this workflow)
delete: success (job done, nothing to look at)
delete: skipped (defensive; the workflow doesn't currently produce
these but if a future change adds an if: that
could skip, we want them swept too)
keep: failure (we want to see when the cleanup itself broke)
cleanup: run every 10 minutes, delete all completed diagnosis runs
Previously hourly with a 1h grace window, only sweeping status=skipped.
Bump the cadence to every 10 minutes and broaden to status=completed so
all conclusions (skipped, success, failure, cancelled, timed_out) get
deleted. Successful diagnosis runs are pure noise after the fact - their
useful output is the commit comment, which lives on the commit, not the
run record.
Self-clean step now also deletes any completed cleanup run (still skips
the current one to avoid self-deletion mid-flight).
Net effect: Actions tab stops accumulating diagnosis-workflow noise
within at most ~10 minutes of any individual run finishing.
multi-server: rename framework repo from freeradius-multi-server to radenv
InkbridgeNetworks/freeradius-multi-server has been renamed to
InkbridgeNetworks/radenv. Update both:
- TEST_MULTI_SERVER_GIT_REPO (clone source URL)
- TEST_MULTI_SERVER_FRAMEWORK_DIR (local checkout path under
build/) so the on-disk directory matches the repo name.
All other references to the framework dir go through the variable so
this is a two-line change. The previous clone path (build/freeradius-
multi-server) will be left behind by an existing checkout; it's safe
to delete manually but doesn't have to be - make crossbuild.* will
just create a fresh build/radenv next to it.
fuzzer.mk: tolerate missing corpus tar (empty/new protocol case)
When a protocol is added to FUZZER_PROTOCOLS but doesn't yet have a
corresponding src/tests/fuzzer-corpus/<protocol>.tar, the prerequisite
recipe blew up at "tar -xf <protocol>.tar" with "no such file" and
make test.fuzzer.<protocol> failed before libfuzzer ever ran.
Check whether the tar exists before extracting; if not, create an
empty corpus directory and continue. libfuzzer accepts an empty
corpus directory and generates random inputs from there - the right
behaviour for a fresh protocol with no curated seeds yet.
Triggered by PR #5854 adding 'arp' to FUZZER_PROTOCOLS without an
accompanying arp.tar.
Gate @claude mention handler on author_association
PR review / comment events that originate on a fork PR run with
restricted GITHUB_TOKEN regardless of the permissions: block. The
Claude Code action needs id-token: write to fetch its OIDC token,
which GitHub denies in that restricted mode - so every first-time
contributor's @claude mention failed with "Could not fetch an OIDC
token. Did you remember to add `id-token: write` to your workflow
permissions?"
Limit the if: to OWNER/MEMBER/COLLABORATOR author_association on the
relevant event payload, matching the same pattern claude-code-review.yml
uses for its automatic reviews. External contributors can still get
Claude on their PR by asking a maintainer to re-mention @claude
in-thread.
At hourly cadence the previous 7-day retention would leave ~168 of
our own runs visible. Match the same 1h grace window the diagnosis-
cleanup step uses, so at most 1-2 cleanup runs are in the Actions tab
at any time.
Tighten diagnosis-cleanup to hourly + 1h grace window
Run the cleanup every hour instead of daily, and only delete skipped
diagnosis runs whose created_at is more than 1 hour old. That keeps
the Actions tab tidy in near-real-time while still leaving a brief
inspection window in case someone wants to look at a fresh skipped
run before it's swept.
Self-clean of the cleanup workflow's own runs stays at older-than-7-days.
Scheduled cleanup of skipped Claude CI Failure Diagnosis runs
The diagnosis workflow fires on every CI completion (its workflow_run
trigger can't filter on conclusion) and uses a job-level if: to gate
on push-failure-on-master/developer. Non-failures leave "Skipped"
entries in the Actions tab.
Add a small scheduled workflow that runs daily, finds completed
skipped runs of the diagnosis workflow, and deletes them via the
Actions API. Also self-cleans its own runs older than 7 days so
the cleanup itself doesn't become the new clutter.
Runs only on the FreeRADIUS org repo; gh.run.delete needs actions:write.
projects / thirdparty / freeradius-server.git / log
