Skip Menu |
 

Date: Wed, 3 Oct 2012 19:21:41 -0500
Subject: All kadm5srv consumers should log writes to the iprop ulog
From: Nico Williams <nico@cryptonector.com>
To: krb5-bugs@mit.edu
Apparently only kadmind and kadmin.local mmap() in the iprop ulog, and
only they log to the ulog.

Evidently the intention was that kadm5srv consumers that want their
transactions iprop'ed should call kadm5_init_iprop(), but that makes
no sense: why would one want to modify the KDB on the master and not
log then in the ulog? Also, if one might want to do that, then why
doesn't kadmin.local have an option to not write transactions to the
ulog?

The fix is simple: make kadm5_init_iprop() a no-op and make
kadm5_init() on the server-side do what kadm5_init_iprop() was doing.
Date: Fri, 5 Oct 2012 11:57:10 -0500
Subject: Re: [krbdev.mit.edu #7405] All kadm5srv consumers should log writes to the iprop ulog
From: Nico Williams <nico@cryptonector.com>
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:
Although, only kadm5 consumers on master KDCs should all log to the ulog.

There's no nice programmatic distinction between master and slave.
The distinction lies in what services they run. (And if we ever get
read-only kadmind then the distinction will lie in what services they
run and how they are configured.) Today, running kadmin.local on a
slave will screw up iprop, likely resulting in a full resync (which
will clobber the local change).

This is a bit of a mess.

A simple fix would be to have kpropd mark a ulog as being
"slave-side", then iprop can simply not log any local changes to the
ulog (or, perhaps, log them, but not change the ulog header). An
alternative would be to have two ulogs: one for slave-side operations,
one for master-side operations, with one being named by suffixing the
other, say.
Date: Fri, 5 Oct 2012 11:57:10 -0500
Subject: Re: [krbdev.mit.edu #7405] All kadm5srv consumers should log writes to the iprop ulog
From: Nico Williams <nico@cryptonector.com>
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:
Although, only kadm5 consumers on master KDCs should all log to the ulog.

There's no nice programmatic distinction between master and slave.
The distinction lies in what services they run. (And if we ever get
read-only kadmind then the distinction will lie in what services they
run and how they are configured.) Today, running kadmin.local on a
slave will screw up iprop, likely resulting in a full resync (which
will clobber the local change).

This is a bit of a mess.

A simple fix would be to have kpropd mark a ulog as being
"slave-side", then iprop can simply not log any local changes to the
ulog (or, perhaps, log them, but not change the ulog header). An
alternative would be to have two ulogs: one for slave-side operations,
one for master-side operations, with one being named by suffixing the
other, say.
Date: Mon, 22 Oct 2012 21:48:14 -0500
Subject: Re: [krbdev.mit.edu #7405] All kadm5srv consumers should log writes to the iprop ulog
From: Nico Williams <nico@cryptonector.com>
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:
Also, some writers must not log to the ulog, namely: kdb5_util load
(there's no way for it to know if it's a master or not, so assume it's
a master) and kpropd (since it doesn't now, though it does update the
header, of course). Also, as long as krb5kdc only modifies
non-replicated attributes we might as well not ulog from it either.
Date: Mon, 22 Oct 2012 21:48:14 -0500
Subject: Re: [krbdev.mit.edu #7405] All kadm5srv consumers should log writes to the iprop ulog
From: Nico Williams <nico@cryptonector.com>
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
RT-Send-Cc:
Also, some writers must not log to the ulog, namely: kdb5_util load
(there's no way for it to know if it's a master or not, so assume it's
a master) and kpropd (since it doesn't now, though it does update the
header, of course). Also, as long as krb5kdc only modifies
non-replicated attributes we might as well not ulog from it either.