On 12/05/2014 05:23 PM, Nathaniel McCallum wrote: > On Fri, 2014-12-05 at 09:19 +0100, Martin Kosek wrote: >> On 12/04/2014 07:17 PM, Nathaniel McCallum wrote: >>> On Tue, 2014-12-02 at 11:55 -0500, Nathaniel McCallum wrote: >>>> 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. >>> >>> So what is the plan with this patch? We need to get it sorted. :) >> >> Ok, I am fine with your original approach then and only fix the new >> installations. You just need to rebase your patch, it does not apply to >> ipa-4-1 >> or master. > > Fixed. > >> Also, I am not convinced we should touch contrib/RHEL4/ipa-client-setup, did >> you try the script and are you confident this option is available on RHEL4? >> :-) >> If not, I would only update current installers. > > Agreed. Fixed.
This one worked fine in my tests. > Also, I updated the commit message to be more thorough. Thanks. I just changed the SSSD ticket to the FreeIPA one, to fix commit automated processing. ACK, pushed to: master: 7ad9f5d3d5ff2eec43bc355c4e7e9514aff01a31 ipa-4-1: d73ed48cf7fa820b6ff8c46b394ff6da19bc7087 Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel