On 6/10/2020 5:26 PM, Nate Coraor (n...@bx.psu.edu) wrote: > On Wed, Jun 10, 2020 at 5:04 PM Greg Hudson <ghud...@mit.edu> wrote: > >> MIT krb5 switched to using "replica" for non-primary KDCs as of release >> 1.17. This was an easy change technically, as the old term was only >> used in a user-visible way in documentation and in the name of one >> profile relation. The pull request for that change was here: >> https://github.com/krb5/krb5/pull/851 > > > Hi Greg, > > This is fantastic and encouraging news, thanks! I'm not sure how I missed > this. If I can find the time I'll see if it'd be as simple for Heimdal, or > perhaps someone from the Heimdal side will chime in. In specific, iprop > uses "slave" even more prominently than kprop did, I believe.
For Heimdal, the term "slave" is part of the both the iprop process name and command line switches for the iprop_master. Changing these could adversely impact end user deployments that are not expecting their configuration scripts and packaging to break. >> Replacing the term "master" is a larger technical challenge. We use >> that term in a DNS SRV record label (_master_kdc), and migrating that >> would come with a cost in network traffic and latency. Aside from the >> kprop architecture, we also use the term "master key" to describe the >> key used to encrypt long-term keys in the KDC database. >> Changing the name in DNS SRV records is really untenable. The impact on end user organizations would be significant. The support for master_kdc lookups and configuration parsing could not be removed because doing so would result in interop failures. Likewise end user organizations would be required to publish both the new record and the old. > Technical considerations are certainly factors. I wonder if it'd be > reasonable to allow clients to specify a preference when performing the SRV > record lookup? Not really. It doesn't change anything other than adding a new configuration option that must reference the "master_kdc" service name in its documentation. As a real world example, in 2011 the IETF deprecated the use of AFSDB records in favor of SRV records for AFS services. This was an official standardization action that took more than a year to complete. It has been nearly a decade and by my most recent inventory nearly 2/3 of AFS cells are still configured with AFSDB records and only 40% have SRV records. Approximately five percent support both. As a result it has been impossible to even consider removing the support for AFSDB records and the additional delays that result from trying one and falling back to the other. > I have rationalized to myself that the term "master" is the less >> problematic of the two terms, as it is used in a lot of different >> contexts (such as physical master keys, martial arts masters, master >> plumbers, and master recordings of records). But I don't know if that >> rationalization is adequate; from recent discussion I know that git's >> use of "master" for the initial default branch name has become a point >> of contention. >> > I largely agree here, it's less problematic. I do think it'd be preferable > to refer to the "master" server as e.g. "primary", but master key seems > fine as it has an established unencumbered meaning. The term "master" applies to the database not the server. The question is whether or not the answer to a query is definitive. All of the KDCs can serve data from the "master" database. The client needs to know that it should retry against another server when it can determine that the database isn't a "master" as a noun; its "master" as an adjective. Where the use of "master" indicates being an expert, principal or instructor. Heimdal's documentation should be rewritten to remove the master-slave relationship. If and when there is ever a volunteer to perform that work along with all of the other changes that Heimdal's documentation requires I will happily merge the pull request. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
