On Thu, Feb 28, 2013 at 6:12 AM, John Devitofranceschi <[email protected]> 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 -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
