Skip Menu |
 

Date: Fri, 01 Jun 2012 18:28:00 -0400
From: Richard Basch <basch@alum.mit.edu>
Subject: krb5-1.10.1 iprop fixes
To: krb5-bugs@mit.edu
CC: basch@alum.mit.edu, richard.basch@gs.com
Download (untitled) / with headers
text/plain 27.5KiB

Message body is not shown because it is too large.

Date: Sun, 03 Jun 2012 02:42:38 -0400
From: Richard Basch <basch@alum.mit.edu>
Subject: RE: [krbdev.mit.edu #7157] AutoReply: krb5-1.10.1 iprop fixes
To: rt@krbdev.mit.edu
CC: krb5-bugs@mit.edu, basch@alum.mit.edu, richard.basch@gs.com
RT-Send-Cc:
Download (untitled) / with headers
text/plain 4.5KiB
Enclosed is a revised patch.
The main difference since my last patch is the ability for an intermediate
slave in the hierarchy to respond to lower leaf nodes immediately after it
has itself performed a full resync and prior to accumulating any entries in
its ulog (obviously, any nodes it services will perform a full resync).

Summary of changes
==================
+ Kadmind can be started with "-proponly" which will enable iprop
distribution services only (but leave other kadmin services inactive)

+ Policy adds/deletes/changes will re-initialize the ulog so slaves will
receive a consistent copy of the database with the updated policies. The
full resync occurs after the next non-policy change.

+ When kpropd invokes ulog_replay() to process the upstream log entries, it
will also populate the local ulog with those same entries.

+ Removed idle timer which was causing spurious UPDATE_BUSY messages on busy
masters with many slaves.

+ Changed ulog_get_entries so it does not wait for a ulog_lock (if it cannot
get a lock, it will return UPDATE_BUSY).

+ Added additional consistency checking of the ulog file to detect possible
corruption.

No protocol or API changes were introduced, though I did have to remove the
"static" keyword of some functions to allow them to be used by other library
functions in different source files. New command-line arguments were
introduced in kpropd & kadmind to support tree replication.

No functional changes were made to kproplog, though some ulog parsing
functions did require some minor logic revision.


Show quoted text
-----Original Message-----
From: krb5 [mailto:rt@krbdev.mit.edu]
Sent: Friday, June 01, 2012 6:44 PM
To: basch@alum.mit.edu
Subject: [krbdev.mit.edu #7157] AutoReply: krb5-1.10.1 iprop fixes


Greetings,

This message has been automatically generated in response to the
creation of a trouble ticket regarding:
"krb5-1.10.1 iprop fixes",
a summary of which appears below.

There is no need to reply to this message right now. Your ticket has been
assigned an ID of [krbdev.mit.edu #7157].

Please include the string:

[krbdev.mit.edu #7157]

in the subject line of all future correspondence about this issue. To do so,

you may reply to this message.

Thank you,


-------------------------------------------------------------------------
I have been trying to fix the iprop code in a significant way. it has a lot
of issues in a large environment with 30 or so slaves especially with short
polling intervals (Kerberos 1.4 with UMich krep code scaled better).

First and foremost, a tree distribution mechanism is required, i.e. the
master can sync a few systems which in turn can sync others. This paradigm
will work better with WAN links, especially if you have an organization with
international WAN links. Second, I removed some bad assumptions (e.g. the
log started with sno=1). And third, I found a few conditions which iprop
does not handle, and even worse, can leave replicas in an inconsistent state
with respect to the master (e.g. policy changes).

Summary of changes (the patch is ~800 lines long):
- Kadmind can be started with "-proponly" which will enable iprop
distribution services only (but leave other kadmin services inactive)
- Policy adds/deletes/changes will re-initialize the ulog so slaves
will receive a consistent copy of the database with the updated policies.
(Full resync is delayed until the next non-policy change is registered in
the ulog.)
- Fixed several sections of code to not assume the ulog starts with
sno=1 (particularly on downstream slaves); also fixed some edge conditions
to ensure consistency (i.e. ulogsize >= 2, or a math exception would
result).
- When kpropd invokes ulog_replay() to process the upstream log
entries, it will also populate the local ulog with those same entries.
(Note: Full resync's do not transmit the master's ulog along with the dump.
This would be ideal, but may require a protocol change.)
- Removed idle timer which was causing spurious UPDATE_BUSY messages
on busy masters with many slaves.
- Changed ulog_get_entries so it does not wait for a ulog_lock (if it
cannot get a lock, it will return UPDATE_BUSY).
- Added additional consistency checking of the ulog file to detect
possible corruption.
Changes were made to kpropd, kadmin, kproplog, and some library components
(though nothing which should affect any published API). There were a few
library functions which I had to promote from static visibility. This
version remains protocol-compatible (adding policy entry encoding or
transmitting the ulog with a full resync would have broken such).
Download iprop.patch
application/octet-stream 33.9KiB

Message body not shown because it is not plain text.

Date: Sun, 03 Jun 2012 02:42:38 -0400
From: Richard Basch <basch@alum.mit.edu>
Subject: RE: [krbdev.mit.edu #7157] AutoReply: krb5-1.10.1 iprop fixes
To: rt@krbdev.mit.edu
CC: basch@alum.mit.edu, krb5-bugs@mit.edu, richard.basch@gs.com
RT-Send-Cc:
Download (untitled) / with headers
text/plain 4.5KiB
Enclosed is a revised patch.
The main difference since my last patch is the ability for an intermediate
slave in the hierarchy to respond to lower leaf nodes immediately after it
has itself performed a full resync and prior to accumulating any entries in
its ulog (obviously, any nodes it services will perform a full resync).

Summary of changes
==================
+ Kadmind can be started with "-proponly" which will enable iprop
distribution services only (but leave other kadmin services inactive)

+ Policy adds/deletes/changes will re-initialize the ulog so slaves will
receive a consistent copy of the database with the updated policies. The
full resync occurs after the next non-policy change.

+ When kpropd invokes ulog_replay() to process the upstream log entries, it
will also populate the local ulog with those same entries.

+ Removed idle timer which was causing spurious UPDATE_BUSY messages on busy
masters with many slaves.

+ Changed ulog_get_entries so it does not wait for a ulog_lock (if it cannot
get a lock, it will return UPDATE_BUSY).

+ Added additional consistency checking of the ulog file to detect possible
corruption.

No protocol or API changes were introduced, though I did have to remove the
"static" keyword of some functions to allow them to be used by other library
functions in different source files. New command-line arguments were
introduced in kpropd & kadmind to support tree replication.

No functional changes were made to kproplog, though some ulog parsing
functions did require some minor logic revision.


Show quoted text
-----Original Message-----
From: krb5 [mailto:rt@krbdev.mit.edu]
Sent: Friday, June 01, 2012 6:44 PM
To: basch@alum.mit.edu
Subject: [krbdev.mit.edu #7157] AutoReply: krb5-1.10.1 iprop fixes


Greetings,

This message has been automatically generated in response to the
creation of a trouble ticket regarding:
"krb5-1.10.1 iprop fixes",
a summary of which appears below.

There is no need to reply to this message right now. Your ticket has been
assigned an ID of [krbdev.mit.edu #7157].

Please include the string:

[krbdev.mit.edu #7157]

in the subject line of all future correspondence about this issue. To do so,

you may reply to this message.

Thank you,


-------------------------------------------------------------------------
I have been trying to fix the iprop code in a significant way. it has a lot
of issues in a large environment with 30 or so slaves especially with short
polling intervals (Kerberos 1.4 with UMich krep code scaled better).

First and foremost, a tree distribution mechanism is required, i.e. the
master can sync a few systems which in turn can sync others. This paradigm
will work better with WAN links, especially if you have an organization with
international WAN links. Second, I removed some bad assumptions (e.g. the
log started with sno=1). And third, I found a few conditions which iprop
does not handle, and even worse, can leave replicas in an inconsistent state
with respect to the master (e.g. policy changes).

Summary of changes (the patch is ~800 lines long):
- Kadmind can be started with "-proponly" which will enable iprop
distribution services only (but leave other kadmin services inactive)
- Policy adds/deletes/changes will re-initialize the ulog so slaves
will receive a consistent copy of the database with the updated policies.
(Full resync is delayed until the next non-policy change is registered in
the ulog.)
- Fixed several sections of code to not assume the ulog starts with
sno=1 (particularly on downstream slaves); also fixed some edge conditions
to ensure consistency (i.e. ulogsize >= 2, or a math exception would
result).
- When kpropd invokes ulog_replay() to process the upstream log
entries, it will also populate the local ulog with those same entries.
(Note: Full resync's do not transmit the master's ulog along with the dump.
This would be ideal, but may require a protocol change.)
- Removed idle timer which was causing spurious UPDATE_BUSY messages
on busy masters with many slaves.
- Changed ulog_get_entries so it does not wait for a ulog_lock (if it
cannot get a lock, it will return UPDATE_BUSY).
- Added additional consistency checking of the ulog file to detect
possible corruption.
Changes were made to kpropd, kadmin, kproplog, and some library components
(though nothing which should affect any published API). There were a few
library functions which I had to promote from static visibility. This
version remains protocol-compatible (adding policy entry encoding or
transmitting the ulog with a full resync would have broken such).
Download iprop.patch
application/octet-stream 33.9KiB

Message body not shown because it is not plain text.

Date: Sun, 03 Jun 2012 03:41:09 -0400
From: Richard Basch <basch@alum.mit.edu>
Subject: Revised krb5-1.10.1 iprop patch [krbdev.mit.edu #7157]
To: krb5-bugs@mit.edu
CC: basch@alum.mit.edu, richard.basch@gs.com
RT-Send-Cc:
Download (untitled) / with headers
text/plain 36.6KiB

Message body is not shown because it is too large.

Download (untitled) / with headers
text/html 200.5KiB

Message body is not shown because it is too large.

We'll need the following (either from Richard or from us as we have time)
to accept this, per http://k5wiki.kerberos.org/wiki/Contributing_code:

* Each independent change needs to be in a separate patch.
* Automated tests. This is a little tricky since we don't yet have
Python tests for incremental propagation.
* Documentation (in the form of changes to doc/rst_source) of the new
flags and features.

These changes are also substantial enough that we'll need either
copyright assignment (saying "I assign copyright of these changes to MIT"
is good enough) or permission to distribute the new code under a BSD-like
license.
Date: Wed, 06 Jun 2012 21:13:13 -0400
From: Richard Basch <basch@alum.mit.edu>
Subject: RE: [krbdev.mit.edu #7157] krb5-1.10.1 iprop fixes
To: rt-comment@krbdev.mit.edu
RT-Send-Cc:
I assign copyright of these changes to MIT.

That said, I will package the patch in a few smaller patches, but some
patches will have the others as prerequisites. (I may have to rework part of
the patch to allow it to be broken apart.)

Show quoted text
-----Original Message-----
From: Greg Hudson via RT [mailto:rt-comment@krbdev.mit.edu]
Sent: Tuesday, June 05, 2012 10:32 PM
To: basch@alum.mit.edu
Subject: [krbdev.mit.edu #7157] krb5-1.10.1 iprop fixes

We'll need the following (either from Richard or from us as we have time)
to accept this, per http://k5wiki.kerberos.org/wiki/Contributing_code:

* Each independent change needs to be in a separate patch.
* Automated tests. This is a little tricky since we don't yet have
Python tests for incremental propagation.
* Documentation (in the form of changes to doc/rst_source) of the new
flags and features.

These changes are also substantial enough that we'll need either
copyright assignment (saying "I assign copyright of these changes to MIT"
is good enough) or permission to distribute the new code under a BSD-like
license.
It's fine if the patches aren't completely independent, as long as
they're ordered such that each patch applied in sequence doesn't break
the build.