On Wed, Jun 10, 2020 at 8:01 PM Jeffrey Altman <jalt...@secure-endpoints.com> wrote:
> 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. > People installing by hand aside, isn't this more of a vendor packaging issue? They deal with changes like this pretty regularly. Can the switch to iprop_master can be deprecated but left in place, and ipropd-slave linked to ipropd-replica and similarly deprecated? > 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'm not suggesting removing support, simply for providing a path forward. 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. > This seems like reasonable framing to me. > 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. > I'm glad to hear that these changes will be accepted. I'll have a look and see what the scope would be. Thanks, --nate ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
