Combined database propagation environment possible (Traditional and Incremental kprop)?

[William Clark]

I think I came to the conclusion in testing that the only way to do this is Alternate Plan A.  When you turn on kiprop, it disables the ability to traditionally push and install a principal DB.

William Clark




On Sep 26, 2013, at 2:07 PM, William Clark <majorgearhead at gmail.com> wrote:

> Greetings,
> 
> I have been charged with migrating an existing large Kerberos infrastructure to a new one using the latest version of Kerberos.  I intend to use incremental propagation on the new environment (kiprop), and have this working quite well in my sandbox.
> 
> The issue:  I must do this with the minimal amount of downtime.  I was wondering if anyone knows of a way to set up a mixed propagation environment?
> 
> What I envision is something like the following:
> 
> - old master kdc would propagate it's principal db file to new master via traditional propagation methods.
> - new master uses incremental propagation to propagate down to slave servers
> - all tools used to interact with the kdc's continue to be pointed at the old master kdc until all clients are pointed to new servers at which time we shut off propagation from the old server to the new and repoint tools to the new server.
> 
> Difficulties:
> I am unsure that this would even work since kiprop is based on the ulog, and I don't know if the ulog would have any updates if a principal file is pushed over via traditional methods.
> 
> Alternate Plan A:
> - old kdc would propagate its principal db to all of the new master/slave servers via traditional method
> - all tools used to interact with the kdc's continue to be pointed at the old master kdc until all clients are pointed to new servers at which time we shut off replication from the old server to the new and repoint tools to the new server.
> - At the time of the cutoff of propagation from the old master, I would ensure the new master DB is properly replicated to all slaves and then I would turn on incremental propagation.
> 
> Alternate Plan B:
> - old kdc would propagate its principal db to all new hosts master/slave servers via traditional method
> - Incremental propagation would be enabled on the new master to slaves to replicate any changes made in kadmin or tools pointing to the new master
> - all tools used to interact with the kdc's continue to be pointed at the old master kdc until all clients are pointed to new servers at which time we shut off replication from the old server to the new and repoint tools to the new server.
> - At the time of the cutoff of propagation from the old master, I would ensure the new master DB is properly replicated to all slaves and then I would turn on incremental propagation.
> 
> I know this is an odd situation, but it is necessary for me to bring our large infrastructure to modern hosts and version of Kerberos.
> 
> Any help would be greatly appreciated!
> 
> William Clark
> 
> 
> 
>