[32779] in Kerberos
Re: Database locking during kprops, MIT 1.8
daemon@ATHENA.MIT.EDU (Dominic Hargreaves)
Thu Oct 7 14:10:41 2010
Date: Thu, 7 Oct 2010 17:01:26 +0100
From: Dominic Hargreaves <dominic.hargreaves@oucs.ox.ac.uk>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <20101007160126.GO3965@gunboat-diplomat.oucs.ox.ac.uk>
MIME-Version: 1.0
In-Reply-To: <1286465980.19112.104.camel@ray>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: multipart/mixed; boundary="===============0534544995=="
Errors-To: kerberos-bounces@mit.edu
--===============0534544995==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="EVcIhgQsEzAXu06J"
Content-Disposition: inline
--EVcIhgQsEzAXu06J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Oct 07, 2010 at 11:39:40AM -0400, Greg Hudson wrote:
> 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?
>=20
> 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.
Aha! That sounds quite likely -- I'd started from the false assumption
that only kadmind modified the database, which explains why my log
correlation didn't really tally.
> 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.
*nod*
> As for your larger problem, I don't have any bright ideas besides
> increasing the retry time on database locks.
I think this will be a workable solution for us in the short term,
and you haven't screamed that I shouldn't do that, so thanks :)
> 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.
Well, it's possible, but since we've just this week stablised on our
current platforms it would be nice not to have to start again :) I
suspect what we'll do is make upgrading our slaves a priority once
the next release of Debian, which includes 1.8 by default, is available.
Thanks for your response.
Dominic.
--=20
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
--EVcIhgQsEzAXu06J
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkyt7tIACgkQJoBKzwmMf2Y+nACeIZdaIZAMBBkiAix+0Tu+bvwG
HxQAmgO6LQ4WZV2rJAl+z/zGJU1mhirB
=QSxP
-----END PGP SIGNATURE-----
--EVcIhgQsEzAXu06J--
--===============0534544995==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============0534544995==--
