On Tue, 2014-12-02 at 17:51 +0100, Martin Kosek wrote:
> On 12/02/2014 05:49 PM, Nathaniel McCallum wrote:
> > On Tue, 2014-12-02 at 17:48 +0100, Martin Kosek wrote:
> >> On 12/02/2014 05:36 PM, Simo Sorce wrote:
> >>> On Tue, 02 Dec 2014 11:12:11 -0500
> >>> Nathaniel McCallum <npmccal...@redhat.com> wrote:
> >>>
> >>>> On Thu, 2014-11-06 at 18:00 -0500, Nathaniel McCallum wrote:
> >>>>> On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote:
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> On 3.10.2013 23:43, Nathaniel McCallum wrote:
> >>>>>>>> Patch attached.
> >>>>>>>
> >>>>>>> I'm curious - what is the purpose of this patch? To prevent 1
> >>>>>>> second timeouts and re-transmits when OTP is in place?
> >>>>>>>
> >>>>>>> What is the expected performance impact? Could it be configured
> >>>>>>> for OTP separately - somehow? (I guess that it is not possible
> >>>>>>> now ...)
> >>>>>>
> >>>>>> It benefits also communication of large packets (when large
> >>>>>> MS-PAC or CAMMAC AD Data are attached), so it is a better choice
> >>>>>> for IPA in general. Especially given we have multiple KDC
> >>>>>> processes configured we do not want clients wasting KDC resources
> >>>>>> by making multiple processes do the same operation.
> >>>>>
> >>>>> So apparently this patch never got reviewed over a year ago.
> >>>>>
> >>>>> It was related to a bug which was opened in SSSD. However, when it
> >>>>> became clear we wanted to solve this in FreeIPA, the SSSD bug was
> >>>>> closed but no corresponding FreeIPA bug was opened. The patch then
> >>>>> fell through the cracks.
> >>>>>
> >>>>> Without this patch, if OTP validation runs long we get retransmits
> >>>>> and failures.
> >>>>>
> >>>>> One question I have is how to handle this for upgrades since (I
> >>>>> think) this patch only handles new installs.
> >>>>>
> >>>>> Anyway, this patch is somewhat urgent now. So help is appreciated.
> >>>>>
> >>>>> I have attached a rebased version which has no other changes.
> >>>>
> >>>> I still need a review on this. Any takers?
> >>>
> >>> The patch looks good to me
> >>>
> >>> Simo.
> >>
> >> This fixes the new installations. Can you please refresh the memory what 
> >> is the
> >> decision regarding the upgrades?
> > 
> > The need to fix upgrades will be documented. In the future, we will
> > get /etc/krb.conf.d and we will ship a file there.
> > 
> > Nathaniel
> > 
> 
> Nobody reads the documentation :-) What is the implication for users doing
> client update (majority of them) and using OTP feature?

They will get spurious failures. Most will think it is a bug or a
network issue. If the failures happen consistently enough, users might
get locked out.

Nathaniel

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to