On 04/23/2014 01:55 PM, Petr Spacek wrote:
On 21.4.2014 14:48, Simo Sorce wrote:
On Mon, 2014-04-21 at 08:39 -0400, Rob Crittenden wrote:
Simo Sorce wrote:
On Thu, 2014-04-17 at 18:25 -0400, Rob Crittenden wrote:
Simo Sorce wrote:
On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote:
Simo Sorce wrote:
On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote:
I would like to discuss more on the managed read permissions
upgrades [1].
Right now, we simply merge an old permission with the new one,
making sure that
we only add new attributes instead of just replacing them, to
prevent a managed
permission to be spoiled by a lower FreeIPA server version
which runs an updates.

I was thinking about it some more and seems to me we could run
in problems when
we for example find out that some permission is too relaxed and
we want to
remove some default attribute. Or when we want to update the
permission filter.
Or when object has anonymous and authenticated permission and
we want to move
attribute from anonymous to authenticated permission.

Changes like this can happen, especially in the first release
and we do not
have means to address them. What about simply versioning the
permissions as we
do with our configs? I.e.

1) Introduce new MUST numeric attribute ipaPermVersion
2) Add 'version' field to managed permissions:

        managed_permissions = {
            'System: Read Roles': {
                'version': 1,
                'replaces_global_anonymous_aci': True,
                'ipapermbindruletype': 'permission',
                'ipapermright': {'read', 'search', 'compare'},
                'ipapermdefaultattr': {
                    'businesscategory', 'cn', 'description',
'member', 'memberof',
                    'o', 'objectclass', 'ou', 'owner', 'seealso',
                'default_privileges': {'RBAC Readers'},
3) Modify updater to only update the permission if it's version
is higher than
the one in LDAP. In that case, it should simply replace the
managed permission
attributes with the new one, no merging (except the attributes
that we allow
users to change).

When we want to change the permission, we simply do the
changes, bump the
version and we are done and we do not need to fear some older
FreeIPA will
overwrite it. That of course assumes that the versioning would
be available
from FreeIPA 4.0.

Makes sense?

[1] http://www.freeipa.org/page/V3/Managed_Read_permissions

Uhmm, yes, and no, let me explain.

What you say *does* make sense, but you are being too focused :-)
The upgrade issue is not limited to permissions, but affects

I think that what we need is to add a "ipa schema version"
somewhere in cn=etc, and then always check this number in the
script. if this number is higher than what we know we
immediately stop
and do not perform updates that affect anything but our own
server data.

This will protect the whole tree from unintentional changes
caused by an
older replica.

Makes sense ?

This could lead to new features not working. Those features would
on containers, ACIs, etc to exist but they wouldn't if the updates
aren't run.

Sorry I don't get this, if they are new features, then the version
be "older" and the update *will* run and at the end raise the

We just prevent old updates from running and current updates from
running multiple times, for the shared tree.

Do we depend on having updates run multiple times for the data in the
shared tree ?

Note that I am not saying that all updates should stop, any update
cn=config would still need to be run on each server (although
setting a
version there too would probably be beneficial).

Ok, so the update runs, adds data, which gets replicated out to
potentially old servers, and we're at the place you said we
wouldn't be.

I am not following you, the aim here is not to avoid replicating new
data to old server, the aim is that if you update the rpm of an older
replica and the rpm runs the ldap updater with the *old* code, we do
end up with that updater *undoing* what a more recent update did.

Updates are all loaded and sorted so that all changes to a given DN
should be applied at once, so it isn't like applying a old update
and a
new update are two separate operations. In fact, it would likely be a
no-op in the case that they have already been applied.

Do you have any examples to clarify your concerns? I'm not
following you.

Sure at some point version freeipa version 4.2 is released and it
has an
update that changes a default object so that now attribute 'foo' is
added, this is done through the updater.

Later on we release freeipa version 5.0 and we realize we will have
again to remove attribute 'foo' because we never really needed it, plus
if it is still there it causes issues to new feature XYZ.

The admin installs 5.0 and all are happy, then a week later he runs a
simply yum update on th eolder replicas still running 4.2 and 4.2.1 is
available, and gets installed and ... bah the 4.2.1 updater re-adds
attribute 'foo' back ... and 5.0 servers are now broken.

If we have an updater version field when the 4.2.1 update goes on it
will see that all updates that were necessary (and more) have already
been added and just quits.

Ok, this won't happen in a modify case. When changing data we only
change a known existing value, so exact match is required.

The only risk is in adding and deleting data.

So if we delete a permission named "Do cool stuff" in 5.0 and that was
something previously added in 4.2 then yeah, re-running the 4.2 updates
will re-apply the data. Similarly deletes would always be applied.

I would not be keen on adding a global version value though, as we've
had issues with updates in the past where re-running the updater would
fix things. This would short circuit that.

Well we could allow the updater to run on "same version" values, this
would preserve this ability while still blocking older updaters.

Besides modifies can be affected too, say we have default value of 10,
we change it to 20 in 4.2 then change it back to 10 in 5.0 as we found
an issue with the new value. If you run 4.2 updater it puts it back to

All cases of flipping values are also affected.

Something more fine-grained might work but carries its own problems.

I think in this case we really want a domain level version, as the tree
is shared and we want updates to be consistent, so the update need to be
applied in full or not at all IMO.

We do have some fine-grained approach as we will have a separate version
for he shared tree than the cn=config tree (and I guess another one for
the CA tree).
Each tree is a Silo, and should have its own tree version.

IMHO more granular "versions" would be handy. Specifically for DNSSEC,
we need to somehow distinguish old installation with centralized key
management from new installation with distributed key management and
different key storage etc. etc.

Maybe we can invent some generic mechanism for "component versioning"?
(Recall Dogtag 9 vs. 10 ...)

I don't like this idea. With very granular versioning we'd need to correctly identify which part each particular update belongs to and what happens when components of various versions are mixed. And we couldn't hope to test all the combinations. Making this into a generic mechanism now, with just a few very different current uses, sounds dangerously over-engineered.

I'd like to see something very simple: only update if stored version <= current API version; store current API version at end of update.
The bugs will be much easier to identify that way.

Of course this supposes a monolithic IPA and e.g. isn't very friendly to external plugins, but I don't think we can design a good story for external plugins without actually writing some first. Let's do something simple and iterate later.


Freeipa-devel mailing list

Reply via email to