On Fri, 07 Nov 2014 14:26:06 +0100
Martin Kosek <mko...@redhat.com> wrote:

> On 11/07/2014 02:20 PM, Simo Sorce wrote:
> > On Fri, 07 Nov 2014 08:02:02 +0100
> > Martin Kosek <mko...@redhat.com> wrote:
> >
> >> On 11/07/2014 01:46 AM, Simo Sorce wrote:
> >>> On Thu, 06 Nov 2014 18:00:21 -0500
> >>> Nathaniel McCallum <npmccal...@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.

Well the concern (aside of duplication) is that  an admin may "correct"
the krb5.conf file to remove that option (for example because his
clients also connect to a differen (older) KDC and must use UDP in
preference. But now we end up messing with its krb5.conf every time an
update is released. An update tool that keep tracks of whether a
specific update has already been applied and does not retry every time
would be needed IMO.

Simo.

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

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to