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

[Martin Kosek]

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

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