On 10/10/2014 06:21 PM, Simo Sorce wrote:
On Fri, 10 Oct 2014 17:52:15 +0200
Ludwig Krispenz <[email protected]> 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
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
