krb5kdc pausing while kdb5_util dumps database

[Kenneth MacDonald]

On Fri, 2014-04-25 at 09:52 -0400, Carlos Más wrote:
> I have experienced this issue before in a similar manner (we do a
> regular dump of a very large Kerberos database, and the Kerberos
> process would stop serving requests while this dump was happening).
> 
> 
> We solved this problem by completely disabling account lockout and
> access tracking, i.e.:
> 
> 
> [dbmodules]
>         db2 = {
>                 database_name = [...]
>                 disable_last_success = true
>                 disable_lockout = true
>         }

Unfortunately we need to keep account lockout turned on.

> 
> While the details are not fresh in my mind right now (and I could be
> completely mistaken, or your issue could be different), the root cause
> was around a locking issue - the dump process locks the database and
> it would clash with the Kerberos process trying to write to the
> database updating the records needed for account lockout.

Yes, I'm seeing in our logs successful authentications for a few seconds
during the dump until the first failure locks it until the dump
completes.

Thinking aloud ... I wonder how difficult it would be to have krb5kdc
optionally stop recording failures while the database is locked.

Cheers,

Kenny.

> On Fri, Apr 25, 2014 at 5:39 AM, Kenneth MacDonald
> <Kenneth.MacDonald at ed.ac.uk> wrote:
>         We have a (large?) principal database that takes forty seconds
>         to dump
>         with kdb5_util.  While this is going on krb5kdc stops
>         responding to
>         authentication and ticket requests.  It happily continues once
>         the dump
>         is complete.
>         
>         We are running MIT krb5 1.12.1 on Scientific Linux 6.
>         
>         Incremental propagation is turned on, account lockout policy
>         is in
>         place, and last successful authentication is not written.
>         
>         We see the same pause whenever a full resync is made, e.g.
>         after a
>         policy change.  This is not surprising as kadmind spawns a
>         kdb5_util
>         dump for this.
>         
>         Is this behaviour of krb5kdc to be expected or might we have
>         something
>         incorrect in our configuration?
>         
>         Cheers,
>         
>         Kenny.
>         
>         
>         
>         --
>         The University of Edinburgh is a charitable body, registered
>         in
>         Scotland, with registration number SC005336.
>         
>         ________________________________________________
>         Kerberos mailing list           Kerberos at mit.edu
>         https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.