Re: [Freeipa-devel] Managed permission versioning

2014-04-23 Thread Petr Spacek

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 everything.

I think that what we need is to add a ipa schema version attribute
somewhere in cn=etc, and then always check this number in the updater
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 rely
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 will
be older and the update *will* run and at the end raise the version.

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 for
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 not
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 

Re: [Freeipa-devel] Managed permission versioning

2014-04-23 Thread Petr Viktorin

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
everything.

I think that what we need is to add a ipa schema version
attribute
somewhere in cn=etc, and then always check this number in the
updater
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
rely
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
will
be older and the update *will* run and at the end raise the
version.

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
for
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
not
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 

Re: [Freeipa-devel] Managed permission versioning

2014-04-23 Thread Martin Kosek
On 04/21/2014 02:48 PM, 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 everything.

 I think that what we need is to add a ipa schema version attribute
 somewhere in cn=etc, and then always check this number in the updater
 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 rely
 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 will
 be older and the update *will* run and at the end raise the version.

 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 for
 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 not
 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 

Re: [Freeipa-devel] Managed permission versioning

2014-04-23 Thread Simo Sorce
On Wed, 2014-04-23 at 16:10 +0200, Martin Kosek wrote:
 On 04/21/2014 02:48 PM, 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 
  everything.
 
  I think that what we need is to add a ipa schema version attribute
  somewhere in cn=etc, and then always check this number in the updater
  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 rely
  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 will
  be older and the update *will* run and at the end raise the version.
 
  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 for
  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 not
  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 

Re: [Freeipa-devel] Managed permission versioning

2014-04-23 Thread Martin Kosek
On 04/23/2014 05:19 PM, Simo Sorce wrote:
 On Wed, 2014-04-23 at 16:10 +0200, Martin Kosek wrote:
 On 04/21/2014 02:48 PM, 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 
 everything.

 I think that what we need is to add a ipa schema version attribute
 somewhere in cn=etc, and then always check this number in the updater
 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 rely
 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 will
 be older and the update *will* run and at the end raise the version.

 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 for
 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 not
 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 

Re: [Freeipa-devel] Managed permission versioning

2014-04-21 Thread Rob Crittenden

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 everything.

I think that what we need is to add a ipa schema version attribute
somewhere in cn=etc, and then always check this number in the updater
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 rely
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 will
be older and the update *will* run and at the end raise the version.

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 for
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 not
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 

Re: [Freeipa-devel] Managed permission versioning

2014-04-21 Thread Simo Sorce
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 everything.
 
  I think that what we need is to add a ipa schema version attribute
  somewhere in cn=etc, and then always check this number in the updater
  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 rely
  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 will
  be older and the update *will* run and at the end raise the version.
 
  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 for
  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 not
  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.
 
  

Re: [Freeipa-devel] Managed permission versioning

2014-04-17 Thread Simo Sorce
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 everything.

I think that what we need is to add a ipa schema version attribute
somewhere in cn=etc, and then always check this number in the updater
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 ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] Managed permission versioning

2014-04-17 Thread Rob Crittenden

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 everything.

I think that what we need is to add a ipa schema version attribute
somewhere in cn=etc, and then always check this number in the updater
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 rely 
on containers, ACIs, etc to exist but they wouldn't if the updates 
aren't run.


rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] Managed permission versioning

2014-04-17 Thread Simo Sorce
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 everything.
 
  I think that what we need is to add a ipa schema version attribute
  somewhere in cn=etc, and then always check this number in the updater
  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 rely 
 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 will
be older and the update *will* run and at the end raise the version.

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 for
cn=config would still need to be run on each server (although setting a
version there too would probably be beneficial).

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] Managed permission versioning

2014-04-17 Thread Rob Crittenden

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 everything.

I think that what we need is to add a ipa schema version attribute
somewhere in cn=etc, and then always check this number in the updater
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 rely
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 will
be older and the update *will* run and at the end raise the version.

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 for
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.


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.

rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] Managed permission versioning

2014-04-17 Thread Simo Sorce
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 everything.
 
  I think that what we need is to add a ipa schema version attribute
  somewhere in cn=etc, and then always check this number in the updater
  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 rely
  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 will
  be older and the update *will* run and at the end raise the version.
 
  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 for
  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 not
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