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.


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?
      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/" >
              cat /etc/krb5.conf >> /etc/krb5.conf.ipanew
              mv /etc/krb5.conf.ipanew /etc/krb5.conf
              /sbin/restorecon /etc/krb5.conf

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 ?


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.


Freeipa-devel mailing list

Reply via email to