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

Simo Sorce ssorce at redhat.com
Fri Nov 7 13:20:06 UTC 2014


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.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the Freeipa-devel mailing list