Gabor Gombas <
gombasgg@gmail.com> writes:
On Mon, Feb 10, 2025 at 08:59:47AM +1100, Brian May wrote:
Is it appropriate to use update-alternatives for kadmin that is supplied
with {Heimdal,MIT} Kerberos?
... in the real world, KDCs tend to be heavily locked down machines with
not much else installed, due to their sensitivity. So while allowing
random tools to be co-installed is generally a good thing, I don't think
that would be a valid goal for a KDC. Making heimdal-kdc Conflicts: with krb5-user might not be the most elegant solution, but it would be fine
for real-world KDC setups.
The kadmin client and the KDC package are very different things. The
kadmin client you can run from anywhere (and often wish to do so).
As someone who used to have to regularly deal with multi-implementation Kerberos setups, I can confirm that there is a real need to be able to
install the Heimdal clients and the MIT clients (including kadmin) at the
same time. This is something that people have been asking for constantly
for over a decade and it would be great to accomplish it.
The problem from the Debian perspective is that the syntax of the kadmin command lines is almost completely different, so normally that would not qualify for alternatives because the tools are absolutely not drop-in replacements for each other. This is to some extent true of the stuff in krb5-clients and heimdal-clients as well (the flags to klist are very different, for instance), and we have hand-waved this away and used alternatives anyway because the benefits seem to outweigh the risks, but
it's a bit more stark with kadmin.
It's unfortunate that the commands have the same names in both Kerberos distributions, although it's understandable from a user UI perspective.
I don't have a good solution. Either using alternatives or not using alternatives runs some risk of breaking things. I think I'd lean towards
using alternatives for kadmin because I think anyone installing both
kadmin client packages probably knows what they're doing and can cope, but technically it is a policy violation because the two commands do not
implement the same interface.
I think this is a "I shot myself in the foot and it hurts" situation. If
you don't want to add an explicit conflict, then you could add a note to README.Debian which says that mixing different Kerberos implementaions
on a host which is meant to be a KDC is not necessarily a good idea.
I don't think anyone wants to mix implementations on the KDC itself.
--
Russ Allbery (
rra@debian.org) <
https://www.eyrie.org/~eagle/>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)