Re: [Freeipa-devel] Managed permission versioning
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
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
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
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
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
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
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
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
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
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
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
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