Upgrade strategies

[Nico Williams]

On Thu, Feb 28, 2013 at 6:12 AM, John Devitofranceschi
<jdvf at optonline.net> wrote:
> When upgrading from MIT Kerberos 1.X to 1.X+N what kind of general rules of thumb can one rely on in terms of compatibility?
>
> Should the slave KDCs be upgraded first, then the master?  Or upgrade the master first?

You can do the master first, but you must not use new features that
affect the KDB in ways that will break your slaves (e.g., multiple
MKVNOs) or which affect the KDB in ways that the slaves will ignore
but ignoring it is bad (e.g., new enctypes -- old KDCs won't be able
to decrypt tickets issued by new KDCs).  In fact, you should hold back
from using such new features even once all KDCs are updated until
you're ready to say there will be no rollback.

I think you'd be better off upgrading the slaves first as they'll
understand the older master's KDB format fully (the database format
hasn't really changed much since 1.3, except for extensions to the
policy DB and new TL_DATA in the principal DB; unknown TL_DATA types
are ignored, which in some cases is fine, in others not so much).
This isn't a hard and fast rule; you can upgrade the master first too,
but you have to be mindful of not using new features that might break
the slaves.  You might want to hear this from the MIT folks though!

> Any considerations when using incremental v. full propagation?

I wouldn't use iprop with any version prior to 1.11, as you know.

> When upgrading to 1.11, what's the oldest previous version that requires more effort than just replacing the binaries (and possibly dealing with the 'weak crypto' changes)?

1.4 is the youngest old version that I know upgrade from which is
relatively simple.  And yes, you have to mind your configuration
(allow_weak_crypto, permitted_enctypes, ...), not just upgrade the
binaries.

Nico
--