Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On 10/14/2014 04:38 PM, Simo Sorce wrote: On Tue, 14 Oct 2014 11:46:47 +0200 Ludwig Krispenz wrote: On 10/10/2014 06:21 PM, Simo Sorce wrote: On Fri, 10 Oct 2014 17:52:15 +0200 Ludwig Krispenz wrote: Hello, this is the current status of my work on #4302, and there are a few pieces still missing, eg the management command needs more input checking and error handling, but - I wanted to give people interested a chance to have a look again and get feedback - there came up the following questions I would like to get an opinion. First thing, I do not think we want a new command here. If we need commands outside of the ipa framework they should be integrated in the ipa-replica-manage tool. But really one of the reasons to move data in the shared tree was that we could grow native framework command to handle the topology so we can manage the topology directly from the UI. So I am not happy with ipa-tology-manage when thinking how to move from an existing deployment with direct management of replication agreement to the new way, there should not be any intermediate disconnects, and if possible transition should be made easy. So I think we should have defined a few modes of operation for the plugin: - initial/bootstrap [optional] - the plugin detects existing agreements and transforms it to segments in the shared tree This should not be optional imo, its the only way to do sane upgrades. When the plugin starts it needs to check if there are replication agreements with other freeipa servers (it should ignore anything else). it is fine for me if it is not optional, I agree that it is needed for smooth upgrades. the reason that I brought this up is that I had the impression that it is not wanted, that configuration should be in full responsibility of an admin creating the shared topology from scratch. If we agree that the shared topology should be populated from existing agreements I'm happy, if not I would make it at least optional. Yes I think it makes sense to do so. We want a change as transparent as possible. the problem to solve is, when does this auto generation stop ? My idea is that the new replication agreements in cn=config are tagged so only those that are untagged get "imported" at startup. Once the plugin has started we deny access to create arbitrary agreements between 2 ipa servers, so "import" will simply not happen. NOTE: I think the code must allow creation of agreements between 1 IPA server and an unrelated server, but those will not match the 'both server are IPA servers condition so no "import" will happen. I think it should be done only once, at the initial startup of the plugin and not allow to bypass the topology plugin later by stopping th eserver, editing cn=config to add a new agreement and having it added at startup to the shared tree, so there shoul be some way to flag that the initial phase is done. I do not think this is necessary. I think it is fine to import whatever untagged agreements are found if both servers they reference are IPA servers. I'm not sure if this can and should be handled with naming conventions. I think agreements that are generate by the topology must be tagged so you know this is not a pre-existing agreement that you have to import, rather an agreement you have to validate or delete. Tagging can be done via naming convention or by adding some additional attribute. I think naming convention would be the easiest solution. Then check if these agreements have been autogenerated (this should be determined by new naming conventions for agreements in cn=config) or if they are pre-existing, if they are pre-existing then new shared entries will be generated in the shared tree. Note: this upgrade thing could also be done in ipa-upgrade plugins, at server upgrade time. Whichever is easier (main concern is if 2 servers are upgraded at the same time replication conflicts may arise). - pending - the plugin handles and propagates segments in the shared tree, but does not enforce teh deletion or creation of replication agreements Not sure what you mean here, but I think that once the plugin is active it should stay active and actively prevent manual changes to automatically created replication agreements. why I wanted this state had two reasons. - Since the information in the shared tree is authoritative and if you start to build the shared tree from scratch (if the above initialization would not be done) there is the problem that adding the shared topology is not atomic, one segment is added, all others do not yet exist and other replication agreements would be deleted, in the best case replication is just interrupted. I am not sure I follow this, can you give an example of how this would happen ? If we agree that initially existing replication agreements will be loaded and made into segments this is not a concern. So I was suggesting a pending mode, you can add/delete segments from the shared tree, verify connectivity and then say go and
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On Tue, 14 Oct 2014 09:17:46 -0400 Rob Crittenden wrote: > Simo Sorce wrote: > > On Tue, 14 Oct 2014 10:21:57 +0200 > > Ludwig Krispenz wrote: > > > >> we already have ipa-replica-manage and ipa-csreplica-manage, and > >> - I did'n want to integrate the topology management into both and > >> duplicate code > >> - there is much change on the way to refactor the ipa commands, to > >> move code into libraries, to expose to openLMI > >> and I have no clear picture yet how this will look like, so I > >> thought implementing the management command as subclasses of > >> admintool would be a good starting point - I do not insist that > >> ipa-topology-manage will survive as a command in the end, but I > >> also do not want to mess with ipa-replica-manage and > >> ipa-csreplica-manage now, when these changes also probably would > >> have no future. > > > > The ideal outcome is to have commands in the admintools indeed. > > I thought the ideal was to have this in the framework so it was > manageable via the UI, which the admin tools are not. Isn't that one > of the main drivers for this reorganization? And to not require DM for > anything? Sorry I had a brain fart, I wrote admintools, but I meant ipa tool. That's really non-negotiable to me, as we want this stuff to be available in the UI, and we do not want to end up maintaining 2 sets of tools that do the same things. Thank you for pointing that out Rob ! 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] [PATCH] move replication topology to shared tree
On Tue, 14 Oct 2014 11:46:47 +0200 Ludwig Krispenz wrote: > > On 10/10/2014 06:21 PM, Simo Sorce wrote: > > On Fri, 10 Oct 2014 17:52:15 +0200 > > Ludwig Krispenz wrote: > > > >> Hello, > >> > >> this is the current status of my work on #4302, and there are a few > >> pieces still missing, eg the management command needs more input > >> checking and error handling, but > >> - I wanted to give people interested a chance to have a look again > >> and get feedback > >> - there came up the following questions I would like to get an > >> opinion. > > First thing, I do not think we want a new command here. > > If we need commands outside of the ipa framework they should be > > integrated in the ipa-replica-manage tool. > > But really one of the reasons to move data in the shared tree was > > that we could grow native framework command to handle the topology > > so we can manage the topology directly from the UI. > > So I am not happy with ipa-tology-manage > > > >> when thinking how to move from an existing deployment with direct > >> management of replication agreement to the new way, there should > >> not be any intermediate disconnects, and if possible transition > >> should be made easy. So I think we should have defined a few modes > >> of operation for the plugin: > >> - initial/bootstrap [optional] - the plugin detects existing > >> agreements and transforms it to segments in the shared tree > > This should not be optional imo, its the only way to do sane > > upgrades. When the plugin starts it needs to check if there are > > replication agreements with other freeipa servers (it should ignore > > anything else). > it is fine for me if it is not optional, I agree that it is needed > for smooth upgrades. > the reason that I brought this up is that I had the impression that > it is not wanted, that > configuration should be in full responsibility of an admin creating > the shared topology from > scratch. > If we agree that the shared topology should be populated from > existing agreements I'm happy, if not I would make it at least > optional. Yes I think it makes sense to do so. We want a change as transparent as possible. > the problem to solve is, when does this auto generation stop ? My idea is that the new replication agreements in cn=config are tagged so only those that are untagged get "imported" at startup. Once the plugin has started we deny access to create arbitrary agreements between 2 ipa servers, so "import" will simply not happen. NOTE: I think the code must allow creation of agreements between 1 IPA server and an unrelated server, but those will not match the 'both server are IPA servers condition so no "import" will happen. > I think it should be done only once, at the initial startup of the > plugin and not allow to bypass the topology plugin later by stopping > th eserver, editing cn=config to add a new agreement and having it > added at startup to the shared tree, > so there shoul be some way to flag that the initial phase is done. I do not think this is necessary. I think it is fine to import whatever untagged agreements are found if both servers they reference are IPA servers. > I'm not sure if this can and should be handled with naming > conventions. I think agreements that are generate by the topology must be tagged so you know this is not a pre-existing agreement that you have to import, rather an agreement you have to validate or delete. Tagging can be done via naming convention or by adding some additional attribute. I think naming convention would be the easiest solution. > > > > Then check if these agreements have been autogenerated (this should > > be determined by new naming conventions for agreements in > > cn=config) or if they are pre-existing, if they are pre-existing > > then new shared entries will be generated in the shared tree. > > > > Note: this upgrade thing could also be done in ipa-upgrade plugins, > > at server upgrade time. Whichever is easier (main concern is if 2 > > servers are upgraded at the same time replication conflicts may > > arise). > > > >> - pending - the plugin handles and propagates segments in the > >> shared tree, but does not enforce teh deletion or creation of > >> replication agreements > > Not sure what you mean here, but I think that once the plugin is > > active it should stay active and actively prevent manual changes to > > automatically created replication agreements. > why I wanted this state had two reasons. > - Since the information in the shared tree is authoritative and if > you start to build the shared tree from scratch (if the above > initialization would not be done) > there is the problem that adding the shared topology is not atomic, > one segment is added, all others do not yet exist and other > replication agreements > would be deleted, in the best case replication is just interrupted. I am not sure I follow this, can you give an example of how this would happen ? > So I was suggesting a pending mode, you can
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On Tue, 14 Oct 2014 15:10:21 +0200 Ludwig Krispenz wrote: > > On 10/14/2014 02:39 PM, Simo Sorce wrote: > > On Tue, 14 Oct 2014 10:12:24 +0200 > > Ludwig Krispenz wrote: > > > >> ok for me, I was just straightforward reading cn=config to get > >> cn=config info, but I like the idea to do it via rootdse. > >> we have to expose the suffix(es) controlled by the topology plugin > >> and the entry point for the shared config info. > > I was thinking in rootDSE we'd expose just if the feature was > > available. For IPA that would suffice, for generic 389ds then you'd > > have top look at configuration to find DNs. > > I am not sure exposing DNs directly from rootDSE is necessary. > I had two cases in mind, which I think would apply to IPA. > > - in an IPA installation in many scenarios you two suffixes: > "dc=.,dc=com" and "o=ipaca". It could be possible to use the > plugin to manage "dc=.." only. Or do you say it's all or nothing ? > If there is a choice, client utilities need to be able to find out > which suffix is managed. > > - even in an ipa installation nobody prevents an admin to add other > backends to the directory server for other usage, so you might have > "dc=example,dc=com" > "dc=test,dc=com" > "dc=anotherbackend,dc=com" > "o=ipaca" > > in which suffix is the shared topology data ? should we query each > suffix to see if something useful is returned ? Well, at least for the IPA case I do not think we want to have multiple topology trees, even for multiple topologies, rather we want to have the ability to mark the same segment as used for X,Y,Z topologies (1-1 between topology and database). This will make it much simpler to handle simple configurations in which you simply want the CA and IPA topologies to be identical, by having a default that says new segments cover both topologies in the UI. Of course we also need to be able eventually to separate those, but again I see it done better by 'tagging' the single object with the topology it belongs to, than having completely different trees by default. (Having separate trees supported is also a desirable feature for the generic plugin so one does not exclude the other). 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] [PATCH] move replication topology to shared tree
Simo Sorce wrote: > On Tue, 14 Oct 2014 10:21:57 +0200 > Ludwig Krispenz wrote: > >> we already have ipa-replica-manage and ipa-csreplica-manage, and >> - I did'n want to integrate the topology management into both and >> duplicate code >> - there is much change on the way to refactor the ipa commands, to >> move code into libraries, to expose to openLMI >> and I have no clear picture yet how this will look like, so I thought >> implementing the management command as subclasses of admintool would >> be a good starting point - I do not insist that ipa-topology-manage >> will survive as a command in the end, but I also do not want to mess >> with ipa-replica-manage and ipa-csreplica-manage now, when these >> changes also probably would have no future. > > The ideal outcome is to have commands in the admintools indeed. I thought the ideal was to have this in the framework so it was manageable via the UI, which the admin tools are not. Isn't that one of the main drivers for this reorganization? And to not require DM for anything? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On 10/14/2014 02:39 PM, Simo Sorce wrote: On Tue, 14 Oct 2014 10:12:24 +0200 Ludwig Krispenz wrote: ok for me, I was just straightforward reading cn=config to get cn=config info, but I like the idea to do it via rootdse. we have to expose the suffix(es) controlled by the topology plugin and the entry point for the shared config info. I was thinking in rootDSE we'd expose just if the feature was available. For IPA that would suffice, for generic 389ds then you'd have top look at configuration to find DNs. I am not sure exposing DNs directly from rootDSE is necessary. I had two cases in mind, which I think would apply to IPA. - in an IPA installation in many scenarios you two suffixes: "dc=.,dc=com" and "o=ipaca". It could be possible to use the plugin to manage "dc=.." only. Or do you say it's all or nothing ? If there is a choice, client utilities need to be able to find out which suffix is managed. - even in an ipa installation nobody prevents an admin to add other backends to the directory server for other usage, so you might have "dc=example,dc=com" "dc=test,dc=com" "dc=anotherbackend,dc=com" "o=ipaca" in which suffix is the shared topology data ? should we query each suffix to see if something useful is returned ? Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On Tue, 14 Oct 2014 10:21:57 +0200 Ludwig Krispenz wrote: > we already have ipa-replica-manage and ipa-csreplica-manage, and > - I did'n want to integrate the topology management into both and > duplicate code > - there is much change on the way to refactor the ipa commands, to > move code into libraries, to expose to openLMI > and I have no clear picture yet how this will look like, so I thought > implementing the management command as subclasses of admintool would > be a good starting point - I do not insist that ipa-topology-manage > will survive as a command in the end, but I also do not want to mess > with ipa-replica-manage and ipa-csreplica-manage now, when these > changes also probably would have no future. The ideal outcome is to have commands in the admintools indeed. 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] [PATCH] move replication topology to shared tree
On Tue, 14 Oct 2014 10:12:24 +0200 Ludwig Krispenz wrote: > ok for me, I was just straightforward reading cn=config to get > cn=config info, but I like the idea to do it via rootdse. > we have to expose the suffix(es) controlled by the topology plugin > and the entry point for the shared config info. I was thinking in rootDSE we'd expose just if the feature was available. For IPA that would suffice, for generic 389ds then you'd have top look at configuration to find DNs. I am not sure exposing DNs directly from rootDSE is necessary. 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] [PATCH] move replication topology to shared tree
On 10/10/2014 06:21 PM, Simo Sorce wrote: On Fri, 10 Oct 2014 17:52:15 +0200 Ludwig Krispenz wrote: Hello, this is the current status of my work on #4302, and there are a few pieces still missing, eg the management command needs more input checking and error handling, but - I wanted to give people interested a chance to have a look again and get feedback - there came up the following questions I would like to get an opinion. First thing, I do not think we want a new command here. If we need commands outside of the ipa framework they should be integrated in the ipa-replica-manage tool. But really one of the reasons to move data in the shared tree was that we could grow native framework command to handle the topology so we can manage the topology directly from the UI. So I am not happy with ipa-tology-manage when thinking how to move from an existing deployment with direct management of replication agreement to the new way, there should not be any intermediate disconnects, and if possible transition should be made easy. So I think we should have defined a few modes of operation for the plugin: - initial/bootstrap [optional] - the plugin detects existing agreements and transforms it to segments in the shared tree This should not be optional imo, its the only way to do sane upgrades. When the plugin starts it needs to check if there are replication agreements with other freeipa servers (it should ignore anything else). it is fine for me if it is not optional, I agree that it is needed for smooth upgrades. the reason that I brought this up is that I had the impression that it is not wanted, that configuration should be in full responsibility of an admin creating the shared topology from scratch. If we agree that the shared topology should be populated from existing agreements I'm happy, if not I would make it at least optional. the problem to solve is, when does this auto generation stop ? I think it should be done only once, at the initial startup of the plugin and not allow to bypass the topology plugin later by stopping th eserver, editing cn=config to add a new agreement and having it added at startup to the shared tree, so there shoul be some way to flag that the initial phase is done. I'm not sure if this can and should be handled with naming conventions. Then check if these agreements have been autogenerated (this should be determined by new naming conventions for agreements in cn=config) or if they are pre-existing, if they are pre-existing then new shared entries will be generated in the shared tree. Note: this upgrade thing could also be done in ipa-upgrade plugins, at server upgrade time. Whichever is easier (main concern is if 2 servers are upgraded at the same time replication conflicts may arise). - pending - the plugin handles and propagates segments in the shared tree, but does not enforce teh deletion or creation of replication agreements Not sure what you mean here, but I think that once the plugin is active it should stay active and actively prevent manual changes to automatically created replication agreements. why I wanted this state had two reasons. - Since the information in the shared tree is authoritative and if you start to build the shared tree from scratch (if the above initialization would not be done) there is the problem that adding the shared topology is not atomic, one segment is added, all others do not yet exist and other replication agreements would be deleted, in the best case replication is just interrupted. So I was suggesting a pending mode, you can add/delete segments from the shared tree, verify connectivity and then say go and let the shared tree become authoritative. - A similar problem arises when adding a new replica, we had decided to leave ipa-replica-install untouched, so it will install a new server and try to setup replication agreements between the server replica-prepare was run and the new replica, but it would be rejected by the plugin when it is enforcing new agreements to be generated only via shared config. So temporariliy disable the authority of the plugin could help. - active - directe management of replicatio agreements is rejected, existing segments ond their modifications are applied This should always be. I did run my tests of the management command as directory manager since admin did not have permissions to read plugin configuration in cn=config, Why would you need to access cn=config ? All management should happen in the shared tree, moving to be able to avoid directly touching cn=config and avoid the need for DM password is one of the main reasons to do this work ... I can add permissions, probably will also need permissions for the part in the shared tree, so what is the expected operation mode, which user needs access to the shared config data and configuration ? We need to introduce a role for "Replication Admins" and make the admins group a member by default, then use normal permissions fr
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On 10/14/2014 10:21 AM, Ludwig Krispenz wrote: On 10/10/2014 06:21 PM, Simo Sorce wrote: On Fri, 10 Oct 2014 17:52:15 +0200 Ludwig Krispenz wrote: Hello, this is the current status of my work on #4302, and there are a few pieces still missing, eg the management command needs more input checking and error handling, but - I wanted to give people interested a chance to have a look again and get feedback - there came up the following questions I would like to get an opinion. First thing, I do not think we want a new command here. If we need commands outside of the ipa framework they should be integrated in the ipa-replica-manage tool. But really one of the reasons to move data in the shared tree was that we could grow native framework command to handle the topology so we can manage the topology directly from the UI. So I am not happy with ipa-tology-manage we already have ipa-replica-manage and ipa-csreplica-manage, and - I did'n want to integrate the topology management into both and duplicate code - there is much change on the way to refactor the ipa commands, to move code into libraries, to expose to openLMI and I have no clear picture yet how this will look like, so I thought implementing the management command as subclasses of admintool would be a good starting point - I do not insist that ipa-topology-manage will survive as a command in the end, but I also do not want to mess with ipa-replica-manage and ipa-csreplica-manage now, when these changes also probably would have no future. +1 Given the pending refactoring of ipa-replica-manage, I think a separate tool for now is better way to get to the result Simo wants. For now I'd put a TODO in ipa_topology_manage saying the CLI is not final. Of course, if anything can be moved to framework commands, that should happen now. Ludwig, please use self.log.info(...) (or .error(), etc.) instead of print for messages, unless the message doesn't make sense in a log file (e.g. prompting for interactive input). -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On 10/10/2014 06:21 PM, Simo Sorce wrote: On Fri, 10 Oct 2014 17:52:15 +0200 Ludwig Krispenz wrote: Hello, this is the current status of my work on #4302, and there are a few pieces still missing, eg the management command needs more input checking and error handling, but - I wanted to give people interested a chance to have a look again and get feedback - there came up the following questions I would like to get an opinion. First thing, I do not think we want a new command here. If we need commands outside of the ipa framework they should be integrated in the ipa-replica-manage tool. But really one of the reasons to move data in the shared tree was that we could grow native framework command to handle the topology so we can manage the topology directly from the UI. So I am not happy with ipa-tology-manage we already have ipa-replica-manage and ipa-csreplica-manage, and - I did'n want to integrate the topology management into both and duplicate code - there is much change on the way to refactor the ipa commands, to move code into libraries, to expose to openLMI and I have no clear picture yet how this will look like, so I thought implementing the management command as subclasses of admintool would be a good starting point - I do not insist that ipa-topology-manage will survive as a command in the end, but I also do not want to mess with ipa-replica-manage and ipa-csreplica-manage now, when these changes also probably would have no future. e when thinking how to move from an existing deployment with direct management of replication agreement to the new way, there should not be any intermediate disconnects, and if possible transition should be made easy. So I think we should have defined a few modes of operation for the plugin: - initial/bootstrap [optional] - the plugin detects existing agreements and transforms it to segments in the shared tree This should not be optional imo, its the only way to do sane upgrades. When the plugin starts it needs to check if there are replication agreements with other freeipa servers (it should ignore anything else). Then check if these agreements have been autogenerated (this should be determined by new naming conventions for agreements in cn=config) or if they are pre-existing, if they are pre-existing then new shared entries will be generated in the shared tree. Note: this upgrade thing could also be done in ipa-upgrade plugins, at server upgrade time. Whichever is easier (main concern is if 2 servers are upgraded at the same time replication conflicts may arise). - pending - the plugin handles and propagates segments in the shared tree, but does not enforce teh deletion or creation of replication agreements Not sure what you mean here, but I think that once the plugin is active it should stay active and actively prevent manual changes to automatically created replication agreements. - active - directe management of replicatio agreements is rejected, existing segments ond their modifications are applied This should always be. I did run my tests of the management command as directory manager since admin did not have permissions to read plugin configuration in cn=config, Why would you need to access cn=config ? All management should happen in the shared tree, moving to be able to avoid directly touching cn=config and avoid the need for DM password is one of the main reasons to do this work ... I can add permissions, probably will also need permissions for the part in the shared tree, so what is the expected operation mode, which user needs access to the shared config data and configuration ? We need to introduce a role for "Replication Admins" and make the admins group a member by default, then use normal permissions framework to regulate access. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On 10/13/2014 08:19 AM, Martin Kosek wrote: On 10/10/2014 06:44 PM, Simo Sorce wrote: On Fri, 10 Oct 2014 18:38:36 +0200 Ludwig Krispenz wrote: On 10/10/2014 06:30 PM, James wrote: On 10 October 2014 12:21, Simo Sorce wrote: First thing, I do not think we want a new command here. If we need commands outside of the ipa framework they should be integrated in the ipa-replica-manage tool. But really one of the reasons to move data in the shared tree was that we could grow native framework command to handle the topology so we can manage the topology directly from the UI. So I am not happy with ipa-tology-manage I agree here... I think the current interface of ipa-replica-manage is fine, however the need to copy the credentials around and the need for a password are the problem. In fact, I particularly like the current interface, and puppet-ipa has already wrapped this successfully. In other words, the design checks out. Good job IPA team. All management should happen in the shared tree, moving to be able to avoid directly touching cn=config and avoid the need for DM password is one of the main reasons to do this work ... I'll comment later on Simmo's other comments, but I need access to cn=config for two reasons, - I need to know if the plugin is deployed and enabled Let's expose something in rootDSE then, that's the "standard" way to do this (though it is unnecessary, if the shared tree is present you already know it is available). +1, ok for me, I was just straightforward reading cn=config to get cn=config info, but I like the idea to do it via rootdse. we have to expose the suffix(es) controlled by the topology plugin and the entry point for the shared config info. for the plugin enabled/disabled status. However, in case you really need to let admin or other privileged person to look in specified part of cn=config, this can be done with standard permissions. We already have for example permission for reading replication agreements: dn: cn=config aci: (targetattr = "cn || createtimestamp || description || entryusn || modifytimestamp || nsds50ruv || nsds5beginreplicarefresh || nsds5debugreplicatimeout || nsds5flags || nsds5replicaabortcleanruv || ... winsyncsubtreepair || winsyncwindowsfilter")(targetfilter = "(|(objectclass=nsds5Replica)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectClass=nsMappingTree))")(version 3.0;acl "permission:System: Read Replication Agreements"; allow (compare,read,search) groupdn = "ldap:///cn=System: Read Replication Agreements,cn=permissions,cn=pbac,dc=ipa,dc=example";) Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On 10/10/2014 06:44 PM, Simo Sorce wrote: > On Fri, 10 Oct 2014 18:38:36 +0200 > Ludwig Krispenz wrote: > >> >> On 10/10/2014 06:30 PM, James wrote: >>> On 10 October 2014 12:21, Simo Sorce wrote: >>> >>> First thing, I do not think we want a new command here. If we need commands outside of the ipa framework they should be integrated in the ipa-replica-manage tool. But really one of the reasons to move data in the shared tree was that we could grow native framework command to handle the topology so we can manage the topology directly from the UI. So I am not happy with ipa-tology-manage >>> I agree here... I think the current interface of ipa-replica-manage >>> is fine, however the need to copy the credentials around and the >>> need for a password are the problem. In fact, I particularly like >>> the current interface, and puppet-ipa has already wrapped this >>> successfully. In other words, the design checks out. Good job IPA >>> team. >>> All management should happen in the shared tree, moving to be able to avoid directly touching cn=config and avoid the need for DM password is one of the main reasons to do this work ... >> I'll comment later on Simmo's other comments, but I need access to >> cn=config for two reasons, >> - I need to know if the plugin is deployed and enabled > > Let's expose something in rootDSE then, that's the "standard" way to > do this (though it is unnecessary, if the shared tree is present you > already know it is available). +1, for the plugin enabled/disabled status. However, in case you really need to let admin or other privileged person to look in specified part of cn=config, this can be done with standard permissions. We already have for example permission for reading replication agreements: dn: cn=config aci: (targetattr = "cn || createtimestamp || description || entryusn || modifytimestamp || nsds50ruv || nsds5beginreplicarefresh || nsds5debugreplicatimeout || nsds5flags || nsds5replicaabortcleanruv || ... winsyncsubtreepair || winsyncwindowsfilter")(targetfilter = "(|(objectclass=nsds5Replica)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectClass=nsMappingTree))")(version 3.0;acl "permission:System: Read Replication Agreements"; allow (compare,read,search) groupdn = "ldap:///cn=System: Read Replication Agreements,cn=permissions,cn=pbac,dc=ipa,dc=example";) Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On Fri, 10 Oct 2014 18:38:36 +0200 Ludwig Krispenz wrote: > > On 10/10/2014 06:30 PM, James wrote: > > On 10 October 2014 12:21, Simo Sorce wrote: > > > > > >> First thing, I do not think we want a new command here. > >> If we need commands outside of the ipa framework they should be > >> integrated in the ipa-replica-manage tool. > >> But really one of the reasons to move data in the shared tree was > >> that we could grow native framework command to handle the topology > >> so we can manage the topology directly from the UI. > >> So I am not happy with ipa-tology-manage > > I agree here... I think the current interface of ipa-replica-manage > > is fine, however the need to copy the credentials around and the > > need for a password are the problem. In fact, I particularly like > > the current interface, and puppet-ipa has already wrapped this > > successfully. In other words, the design checks out. Good job IPA > > team. > > > >> All management should happen in the shared tree, moving to be able > >> to avoid directly touching cn=config and avoid the need for DM > >> password is one of the main reasons to do this work ... > I'll comment later on Simmo's other comments, but I need access to > cn=config for two reasons, > - I need to know if the plugin is deployed and enabled Let's expose something in rootDSE then, that's the "standard" way to do this (though it is unnecessary, if the shared tree is present you already know it is available). > - the plugin configuration contains the location in the the shared > tree where the toplogy information is > stored. I do not like to have hardcoded paths. In IPA it will be absolutely hardcoded with no chance of changing it. So it is not a problem for IPA tools. 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] [PATCH] move replication topology to shared tree
On 10/10/2014 06:30 PM, James wrote: On 10 October 2014 12:21, Simo Sorce wrote: First thing, I do not think we want a new command here. If we need commands outside of the ipa framework they should be integrated in the ipa-replica-manage tool. But really one of the reasons to move data in the shared tree was that we could grow native framework command to handle the topology so we can manage the topology directly from the UI. So I am not happy with ipa-tology-manage I agree here... I think the current interface of ipa-replica-manage is fine, however the need to copy the credentials around and the need for a password are the problem. In fact, I particularly like the current interface, and puppet-ipa has already wrapped this successfully. In other words, the design checks out. Good job IPA team. All management should happen in the shared tree, moving to be able to avoid directly touching cn=config and avoid the need for DM password is one of the main reasons to do this work ... I'll comment later on Simmo's other comments, but I need access to cn=config for two reasons, - I need to know if the plugin is deployed and enabled - the plugin configuration contains the location in the the shared tree where the toplogy information is stored. I do not like to have hardcoded paths. I'd just like to +1 / re-iterate this point... In addition, thank you for hacking on this and for posting this for early review. Cheers, James ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On 10 October 2014 12:21, Simo Sorce wrote: > First thing, I do not think we want a new command here. > If we need commands outside of the ipa framework they should be > integrated in the ipa-replica-manage tool. > But really one of the reasons to move data in the shared tree was that > we could grow native framework command to handle the topology so we can > manage the topology directly from the UI. > So I am not happy with ipa-tology-manage I agree here... I think the current interface of ipa-replica-manage is fine, however the need to copy the credentials around and the need for a password are the problem. In fact, I particularly like the current interface, and puppet-ipa has already wrapped this successfully. In other words, the design checks out. Good job IPA team. > All management should happen in the shared tree, moving to be able to > avoid directly touching cn=config and avoid the need for DM password is > one of the main reasons to do this work ... I'd just like to +1 / re-iterate this point... In addition, thank you for hacking on this and for posting this for early review. Cheers, James ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] move replication topology to shared tree
On Fri, 10 Oct 2014 17:52:15 +0200 Ludwig Krispenz wrote: > Hello, > > this is the current status of my work on #4302, and there are a few > pieces still missing, eg the management command needs more input > checking and error handling, but > - I wanted to give people interested a chance to have a look again > and get feedback > - there came up the following questions I would like to get an > opinion. First thing, I do not think we want a new command here. If we need commands outside of the ipa framework they should be integrated in the ipa-replica-manage tool. But really one of the reasons to move data in the shared tree was that we could grow native framework command to handle the topology so we can manage the topology directly from the UI. So I am not happy with ipa-tology-manage > when thinking how to move from an existing deployment with direct > management of replication agreement to the new way, there should not > be any intermediate disconnects, and if possible transition should be > made easy. So I think we should have defined a few modes of operation > for the plugin: > - initial/bootstrap [optional] - the plugin detects existing > agreements and transforms it to segments in the shared tree This should not be optional imo, its the only way to do sane upgrades. When the plugin starts it needs to check if there are replication agreements with other freeipa servers (it should ignore anything else). Then check if these agreements have been autogenerated (this should be determined by new naming conventions for agreements in cn=config) or if they are pre-existing, if they are pre-existing then new shared entries will be generated in the shared tree. Note: this upgrade thing could also be done in ipa-upgrade plugins, at server upgrade time. Whichever is easier (main concern is if 2 servers are upgraded at the same time replication conflicts may arise). > - pending - the plugin handles and propagates segments in the shared > tree, but does not enforce teh deletion or creation of replication > agreements Not sure what you mean here, but I think that once the plugin is active it should stay active and actively prevent manual changes to automatically created replication agreements. > - active - directe management of replicatio agreements is rejected, > existing segments ond their modifications are applied This should always be. > I did run my tests of the management command as directory manager > since admin did not have permissions to read plugin configuration in > cn=config, Why would you need to access cn=config ? All management should happen in the shared tree, moving to be able to avoid directly touching cn=config and avoid the need for DM password is one of the main reasons to do this work ... > I can add permissions, probably will also need permissions > for the part in the shared tree, so what is the expected operation > mode, which user needs access to the shared config data and > configuration ? We need to introduce a role for "Replication Admins" and make the admins group a member by default, then use normal permissions framework to regulate access. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
