[32778] in Kerberos
Re: Database locking during kprops, MIT 1.8
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Oct 7 11:39:49 2010
From: Greg Hudson <ghudson@mit.edu>
To: Dominic Hargreaves <dominic.hargreaves@oucs.ox.ac.uk>
In-Reply-To: <i8kcda$roq$1@news.ox.ac.uk>
Date: Thu, 07 Oct 2010 11:39:40 -0400
Message-ID: <1286465980.19112.104.camel@ray>
Mime-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Thu, 2010-10-07 at 07:54 -0400, Dominic Hargreaves wrote:
> With 1.8, it looks like (some?) getprinc requests also end up modifying
> the principal database mtime (log correlation suggests that not all
> getprincs have this effect, and there is a lag of several seconds; but
> that's the best idea I've got). I can't spot immediately what in the
> code is doing this; any ideas?
I'm not sure about getprinc requests through kadmin, but we did add
account lockout support in 1.8. A consequence is that initial
authentication requests to preauth-required principals will update the
"last successful authentication", "last failed authentication", and
"failed password attempts" fields of principals.
In 1.9 we're adding dbmodules variables names disable_last_success and
disable_lockout to suppress those database updates, but that doesn't
help you immediately.
As for your larger problem, I don't have any bright ideas besides
increasing the retry time on database locks. iprop is designed to allow
fast propagation without the kind of disruption you're seeing, but that
doesn't sound like it's an option for you right now.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
