MartijnVisser opened a new pull request, #29184:
URL: https://github.com/apache/flink/pull/29184
## What is the purpose of the change
The test KDC image is built `FROM debian:bullseye`. Debian 11 is
oldoldstable and its security
pool has been emptied: the `bullseye-security` index still advertises `krb5
1.18.3-6+deb11u8`, but
the `.deb` is a 404 on `deb.debian.org` and is not served under the same
path on
`archive.debian.org`. Building the image therefore fails in `apt-get install
locales krb5-kdc
krb5-admin-server`, `build_image` gives up after five retries with `Could
not build hadoop image`,
and the Kerberized and PyFlink YARN Docker e2e tests have not been able to
start a cluster since
2026-09-05.
The image is identical on every branch, so it is equally unbuildable here;
release-1.20 is the
only branch that still runs those tests, and there all five non-jdk11
profiles are red every
night. This PR fixes master, the `[BP-1.20]` backport is what unblocks CI.
## Brief change log
- `docker-hadoop-secure-cluster/kdc/Dockerfile` builds `FROM
debian:bookworm` instead of
`debian:bullseye`
That is one Debian major version (11 to 12), which moves krb5 1.18.3 to
1.20.1 and glibc 2.31 to
2.36. The current stable, trixie, also builds and passes the same checks,
but it is Debian 13 and
would skip a release; the smaller jump is preferred here. bookworm is
oldstable, so this will need
revisiting when Debian 12 is archived.
## Verifying this change
This change is already covered by the existing `Running Kerberized YARN
per-job on Docker test`
and `PyFlink YARN per-job on Docker test` e2e tests, which cannot run at all
today.
The failure is deterministic, not a flake — it reproduced on every one of
the 19 release-1.20
nightly and push runs in the last week — so a single red and a single green
run are conclusive and
a stress loop would measure nothing.
- `docker build --no-cache --pull kdc` on the base: fails, `apt-get
install ... exit code: 100`,
404s on `krb5-user`, `libkdb5-10`, `libicu67`, `libc-l10n` and
`locales`. Identical to CI
except for the arch, which is immaterial since the pool is empty for
every arch.
- The same build on this branch: succeeds.
- Reverting the single `FROM` line and rebuilding: fails again with the
same error.
- The resulting KDC (`/etc/debian_version` 12.15, `krb5-kdc
1.20.1-2+deb12u5`) starts `krb5kdc`
and `kadmind`, and `addprinc` + `kinit` + `klist` issue a
`krbtgt/[email protected]`
ticket. The entrypoint needed no change.
- Cross-version check, since the Hadoop containers are built from
`eclipse-temurin:8-jdk-jammy`
and so run a krb5 1.19.2 client: that client gets a TGT from the new KDC
unchanged.
- Java-side check, since Hadoop authenticates with a keytab through
`UserGroupInformation.loginUserFromKeytab`: a `ktadd`-generated keytab
for
`[email protected]` (aes256-cts-hmac-sha1-96,
aes128-cts-hmac-sha1-96) drives a
`Krb5LoginModule` keytab login on JDK 8u502 in
`eclipse-temurin:8-jdk-jammy` against the new
KDC: login succeeds and yields a `krbtgt/[email protected]` ticket
with session key
type 18 (aes256-cts-hmac-sha1-96).
## Does this pull request potentially affect one of the following parts:
- Dependencies (does it add or upgrade a dependency): **yes** — the base
image of a test-only
container, `debian:bullseye` (11) to `debian:bookworm` (12). It is not a
Maven dependency, ships in no
released artifact, and does not affect `NOTICE` or `LICENSE`.
- The public API, i.e., is any changed class annotated with
`@Public(Evolving)`: no
- The serializers: no
- The runtime per-record code paths (performance sensitive): no
- Anything that affects deployment or recovery: JobManager (and its
components), Checkpointing,
Kubernetes/Yarn, ZooKeeper: no — this is the YARN e2e test fixture, not
deployment code
- The S3 file system connector: no
## Documentation
- Does this pull request introduce a new feature? no
- If yes, how is the feature documented? not applicable
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes (please specify the tool below)
Generated-by: Claude Code (Claude Opus 5)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
