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

[Martin Kosek]

On 11/07/2014 02:20 PM, Simo Sorce wrote:
> On Fri, 07 Nov 2014 08:02:02 +0100
> Martin Kosek <mkosek at redhat.com> wrote:
>
>> On 11/07/2014 01:46 AM, Simo Sorce wrote:
>>> On Thu, 06 Nov 2014 18:00:21 -0500
>>> Nathaniel McCallum <npmccallum at redhat.com> 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.
>>
>> Right - without an associated ticket tracking the patch, it is too
>> easy to loose it unless the author prods people to review it.
>>
>>>> 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.
>>>>
>>>> Nathaniel
>>>
>>> I am not sure we can do much on updates, we do not have a
>>> client-update tool, I would just document it I guess.
>>> Otherwise we'd have to go back to sssd which can inject additional
>>> values in krb5.conf, however I am not sure it would be ok to set
>>> something like this in the sssd's pubconf includes ...
>>
>> Agreed, pubconf update does not sound right.
>>
>> However, we already update krb5.conf on client updates, in %post:
>>
>> %post client
>> if [ $1 -gt 1 ] ; then
>>       # Has the client been configured?
>>       restore=0
>>       test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' &&
>> restore=$(wc -l '/var/lib/ipa-client/sysrestore/sysrestore.index' |
>> awk '{print $1}')
>>
>>       if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then
>>           if ! grep -E -q
>> '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf
>>    2>/dev/null ; then
>>               echo "includedir /var/lib/sss/pubconf/krb5.include.d/" >
>> /etc/krb5.conf.ipanew
>>               cat /etc/krb5.conf >> /etc/krb5.conf.ipanew
>>               mv /etc/krb5.conf.ipanew /etc/krb5.conf
>>               /sbin/restorecon /etc/krb5.conf
>>           fi
>>       fi
>> ...
>>
>>
>> This particular update is more difficult as not a first line needs to
>> be changed. Without adding ipa client update tool with some
>> reasonable krb5.conf parser, we could do something along the lines of
>>
>> sed -E 0i 's/(forwardable = \w+)/\1\n udp_preference_limit =
>> 0/g' /etc/krb5.conf
>>
>> (tested), but it is not pretty.
>
> What happen the next time you run it again ?
>
> Simo.
>

It would of course be added again, you would need to first grep for presence of 
udp_preference_limit setting. Question is if this approach is safe enough to be 
in our client %post upgrade. We already upgrade krb5.conf here, just the change 
is much easier as we just add a line to the beginning of the file.

Martin