krb5-admin-server postinst has broken debconf if RUN_KADMIND set in /etc/default/krb5-admin-server

I think this is basically only a problem on upgrade from older versions of krb5, in particular from prior to the 1.12 era to the current packaging.
As part of adding support for systemd units, I decided to drop support for the run_kadmind variable, and bungled the upgrade path.
This is an issue for upgrades from trusty or precise to anything newer if you are running krb5-admin-server.
There's a very simple work around: remove run_kadmind from /etc/default/krb5-admin-server.
I'll fix for Debian shortly.
What Ubuntu versions is this worth doing a fix for?

We ran into this doing the upgrade from trusty to xenial. Perhaps address that transition (though trusty is nearing EOL). Maybe just remove the defaults file check all together so that package installs work reliably.

Thanks Clark and Sam.

Ubuntu doesn't support upgrade paths that skip LTS releases. So, ignoring EOL releases, we only need to consider Trusty->Xenial, Xenial->Bionic, Bionic->Cosmic and Cosmic->Disco. Does that save us a whole bunch of work? If only upgrading from 1.12 is affected, then from Ubuntu is Trusty->Xenial the only upgrade path affected? If so, is it just Xenial that we need to fix?

Robie any chance I could get you to sync krb5 1.17-2 from Debian
unstable to disco?
It's probably not a big deal but there's no reason not to take the fix
into Disco.

>>>>> "Robie" == Robie Basak <email address hidden> writes:

    Robie> Thanks Clark and Sam. Ubuntu doesn't support upgrade paths
    Robie> that skip LTS releases. So, ignoring EOL releases, we only
    Robie> need to consider Trusty->Xenial,
    Xenial-> Bionic, Bionic->Cosmic and Cosmic->Disco. If only upgrading from 1.12 is affected,
    Robie> then from Ubuntu is Trusty->Xenial the only upgrade path
    Robie> affected?

yes.

    Robie> If so, is it just Xenial that we need to fix?

I was working with this a bit testing the upgrade from wheezy to buster
on the Debian side. Wheezy is the only Debian release that is vaguely
extant where this could come up.
In my testing, Debconf didn't actually remove the template on an
upgrade.
So, The two cases where I found that I could reproduce the situation
Were:

* remove krb5-admin-server on the old release and install it on the new
  release (without doing an upgrade)

* Copy in a /etc/default/krb5-admin-server from another system.

Neither of those seems serious enough to backport a fix for. I'd rather
wait until we get a better understanding of how this gets triggered
before doing any changes to xenial. I agree though that if we need to
change any old release xenial is the only target.

--Sam

This bug was fixed in the package krb5 - 1.17-2

---------------
krb5 (1.17-2) unstable; urgency=medium

  * Finish removing the run kadmind debconf template which was obsoleted
    when the systemd units were installed, LP: #1817376

 -- Sam Hartman <email address hidden> Mon, 25 Feb 2019 13:55:57 -0500