[Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients

Nathaniel McCallum npmccallum at redhat.com
Fri Dec 5 16:23:54 UTC 2014


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 <npmccallum at 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.

Also, I updated the commit message to be more thorough.

Nathaniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-npmccallum-0019.1-Prefer-TCP-connections-to-UDP-in-krb5-clients.patch
Type: text/x-patch
Size: 2898 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20141205/237c945b/attachment.bin>


More information about the Freeipa-devel mailing list