Clock skew failures in selftest

[Andrew Bartlett]

On Fri, 2018-07-13 at 13:53 +0300, Alexander Bokovoy wrote:
> On pe, 13 heinä 2018, Andrew Bartlett via samba-technical wrote:
> > On Fri, 2018-07-13 at 09:52 +0300, Alexander Bokovoy wrote:
> > > On pe, 13 heinä 2018, Andrew Bartlett via samba-technical wrote:
> > > > I was thinking about why we might be seeing errors like this:
> > > > 
> > > > [789(4384)/888 at 1h12m28s]
> > > > samba4.ldap_schema.python(ad_dc_ntvfs)(ad_dc_ntvfs)
> > > > GSS client Update(krb5)(1) Update failed:  Miscellaneous failure (see
> > > > text): Clock skew too great
> > > > UNEXPECTED(error):
> > > > samba4.ldap_schema.python(ad_dc_ntvfs).__main__.SchemaTests.test_genera
> > > > ted_mAPIID(ad_dc_ntvfs)
> > > > REASON: Exception: Exception: Traceback (most recent call last):
> > > >   File
> > > > "/memdisk/abartlet/a/b409336/samba/source4/dsdb/tests/python/ldap_schem
> > > > a.py", line 1173, in test_generated_mAPIID
> > > >     self.ldb.modify_ldif(ldif)
> > > >   File "bin/python/samba/__init__.py", line 241, in modify_ldif
> > > >     self.modify(msg, controls)
> > > > LdbError: (3, 'ldb_wait from (null) with LDB_WAIT_ALL: Time limit
> > > > exceeded (3)')
> > > > 
> > > > For the first part (krb5):
> > > > 
> > > > We run with lockskew = 5 in the krb5.conf of the test client, and I
> > > > think what his happening here isn't that the packet takes 5 seconds to
> > > > get to the client, it is that if there is DB locking then the packet
> > > > takes 5 seconds inside the KDC.
> > > > 
> > > > Because the kdc time is set (by Samba, in the packet read handler)
> > > > before the KDC process() routine runs, if the LDB layer blocks on a
> > > > lock, the ticket can be expired before it leaves the server. 
> > > > 
> > > > The second message suggests the same thing, that something had the DB
> > > > locked for quite some time.
> > > 
> > > What was a reason to reduce to 5 seconds from a default 5 minutes for
> > > Kerberos libraries? Kerberos clock skew isn't a timeout thing so we
> > > really shouldn't use it to trigger timeouts.
> > 
> > ac5427c6eba0 (Andreas Schneider 2016-09-26 18:51:33 +0200 242)  # Set the grace clocskew to 5 seconds
> > ac5427c6eba0 (Andreas Schneider 2016-09-26 18:51:33 +0200 243)  # This is especially required by samba3.raw.session krb5 and
> > ac5427c6eba0 (Andreas Schneider 2016-09-26 18:51:33 +0200 244)  # reauth tests
> > ac5427c6eba0 (Andreas Schneider 2016-09-26 18:51:33 +0200 245)  clockskew = 5
> > 
> > It went in with a pile of the things for the MIT KDC.
> 
> My understanding is that this is because in test_session_expire1 test we 
>    - we acquire tickets with 4 seconds life time (git grep requested_life_time)
>    - we wait up to 10 seconds between several operations to be sure we
>      trigger reauthentication
>    - as clockskew value is used for allowing existing ticket to be used
>      for a time < clockskew after expiration, the ticket above would be
>      valid 9 seconds in total.
> 
> However, this is the only test that requires clockskew reduced to 5
> seconds. The rest of our tests do not require it. I think we should
> consider updating a test environment for source3.raw.session instead of
> applying its conditions to everything else.

I totally agree.  Any chance someone wants to fight selftest and make a
patch?

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba