Update variables to support Kali Linux

[straysheep-dev]

After seeing how Pop!_OS and Linux Mint were supported, it looks like the same can be done for Kali using a separate variable for the release string here:

docker_apt_ansible_distribution_release: "{{ 'bookworm' if ansible_distribution in ['Kali'] else ansible_distribution_release }}"

...and replacing the few instances of ansible_distribution_release with that new variable.

There may be a better way to do this since bookworm will need updated with each Debian major release. However it's infrequent enough that it may be acceptable for now, similar to the GPG key checksum being a static value.

[clem9669]

Hey @straysheep-dev @geerlingguy 👋

This looks great ! I hope this will be merge soon 🙏

Cheers

[mr-pmillz]

When will this PR be merged? @clem9669
I'm getting failing builds for installing docker on Kali via this role due to the wrong url getting set for this task: https://github.com/geerlingguy/ansible-role-docker/blob/master/tasks/setup-Debian.yml#L40

this causes it to fall back to attempting to download docker gpg key from a non-existent url "https://download.docker.com/linux/kali/gpg" and piping it to the now deprecated apt-key command.
starting at Debian 11 and Ubuntu 20.10, apt-key is now deprecated and it will no longer be available after Debian 11 and Ubuntu 22.04
https://community.learnlinux.tv/t/how-to-apt-key-is-deprecated-heres-how-to-fix-it/489

[straysheep-dev]

Updated this to work with the new deb822_repository module, and use Debian 13's trixie instead of 12's bookworm for Kali.

I also noticed the refactor may have accidentally removed support for POP!_OS and Linux Mint by pointing directly to ansible_facts.distribution and not docker_apt_ansible_distribution here. There may be a plan to handle these cases better, but if not, I wanted to mention this. 👍

[github-actions]

This pr has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

[straysheep-dev]

• Fixed rebase to include the latest upstream changes
• Tested locally on Kali 2025.4

@geerlingguy I checked back in on the documentation, but it still seems all the Debian and Ubuntu derivatives require this work around for now, similar to how Fedora, CentOS, and RHEL are handled in defaults/main.yml. There may be distro-specific packages that make more sense but this seems like the way to go just to continue support for Pop, Kali, and more.

If there's anything I can adjust to get this merged please let me know.

[geerlingguy]

Please see the code review above — it seems like to support Kali, there's a hardcoded trixie in there... but when the next version of Debian (then Kali) comes out, it seem like that'll break (I presume?) unless Kali is always set to trixie for now and forever...

[straysheep-dev]

Thanks for this! This is one of the trickiest parts when building with Kali. I'll try to summarize what I've been running into just to share my notes in case anyone else has a better idea:

The docs show either installing the older docker.io package, or manually setting the codename. For a number of reasons, when building Kali via CI/CD we might want to stick to the latest supported docker release directly from Docker. This role also makes additional configuration like adding users to the docker group easy, and is likely used by other assets being built. That's mainly why I've gone this route.

• cat /etc/os-release and lsb_release -c only reference "kali-rolling"
• Version ID's are different than Debian
• Nothing under /etc references the Debian codename (I search through the entire filesystem at that point)
• /usr/lib/python3/dist-packages/debian/debian_support.py lists all debian codenames, but this is not ideal to pull from
• https://http.kali.org/ and the relevant release files only reference debian-testing when it's not referencing the "kali-rolling" codenames
• https://download.docker.com/linux/debian/dists/ has no (easy) way of determining which codename is the "latest"
• I searched on Kali's Discord to see if there's any trick I might be missing
• It may be worth opening this as an issue over on Kali's Gitlab, since this likely doesn't affect only Docker

All of this is to avoid trying to create a static list mapping Kali versions to Debian versions, since this will never work reliably. Right now Kali is based on "Forky" (they always use Debian Testing as the base). I imagine only the latest stable release (currently, that's "Trixie") is ever going to be supported by Docker. That means even if Kali referenced its Debian codename, that still won't work.

Luckily, Debian's stable Release file is in a predictable path. This is the only reliable and dynamic solution I can work out after reviewing everything above, and sharing these notes and ideas with Claude. This isn't ideal but seems acceptable since this role already relies on network connections to function, and this seems like the option that would cover most cases on a rolling distro like Kali.