Upgrade strategies

[Tom Yu]

Nico Williams <nico at cryptonector.com> writes:

> 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.

The upgrade strategies our ops people have used internally have tended
to involve upgrading slaves first.  (That also generally helps with
rollback, if needed.)