> From: Chris Hecker > Sent: Wednesday, December 03, 2014 4:21 PM > > I am going to need to make the exact same update at some point, so a report > back on how it went would be great!
We finally finished this upgrade last week, and it went fine. Upgraded the schema on everything first, then one kdc at a time (a week or two apart), no problems no issues… > On Dec 3, 2014 2:28 PM, "Paul B. Henson" <hen...@acm.org > <mailto:hen...@acm.org> > wrote: > > > We currently have three Kerberos servers running 1.9.4 using the LDAP > backend and are planning to upgrade to 1.13. Historically we have > always > upgraded servers one at a time, slaves first, then the master, and done > the > upgrade in place with the temporary existence of different versions. > > This is the first upgrade we have done since switching to the LDAP > backend. > We have account lockout enabled (shakes angry fist at ridiculous ISO > audit > checkbox), and our LDAP backend is multi master, so technically even > though > we have a load balancer in front directing kadmin load at any given time > to > only one of the three servers, they are all masters and updating the > local > database simultaneously. > > I see that four new attributes (krbPwdAttributes, krbPwdMaxLife, > krbPwdMaxRenewableLife, and krbPwdAllowedKeysalts) have been > added to the > krbPwdPolicy object class in the schema. openldap gets quite unhappy if > one > server tries replicating anattribute to another which does not have it > defined 8-/, so I want to be sure to avoid that scenario. > > I am tentatively thinking of updating the openldap schema on the > existing > systems prior to the update, and then updating Kerberos itself one > system at > a time as we have historically done. Does this seem reasonable, and will > hopefully succeed without any interoperability issues? > > Thanks much for any thoughts or suggestions. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
