Clock skew failures in selftest

[Alexander Bokovoy]

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.

-- 
/ Alexander Bokovoy