On Tue, 14 Oct 2014 11:46:47 +0200
Ludwig Krispenz <lkris...@redhat.com> wrote:

> On 10/10/2014 06:21 PM, Simo Sorce wrote:
> > On Fri, 10 Oct 2014 17:52:15 +0200
> > Ludwig Krispenz <lkris...@redhat.com> 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

> 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  add/delete segments from
> the shared tree, verify connectivity and then say go and let the
> shared tree become authoritative.

Why automatically importing agreements would not work ?
The plugin itself can bypass topology checks when importing so you
should simply end up with whatever is the current situation in your
domain once all servers have been upgraded.

I think it is actually crucial that it can work this way because server
will take some times to be upgraded one after the other, so for some
time there will be some servers with the topology plugin activated and
some that do not have it. Incomplete topology info will be expected.
Also exposing the topology plugin in rootDSE here gain us a big win as
the UI can show which servers still do not have the plugin enabled (as
opposed to malfunctioning servers) and can mark deal appropriately
with missing topology links by showing them grayed out until the old
replica gets updated or something like that.

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

Actually I was not a ware this decision was made, seriously, one of the
main drivers for this feature is to get replica installation to finally
stop needing DM passwords, so I am completely taken back by this
decision to not touch ipa-replica-install/ipa-replica-manage and insted
introduce ipa-topology-manage, I think we are only adding more work
later to reconcile tools and change them and making life harder by
adding this problem that new replicas can't properly add themselves to
the topology until after they are fully installed. Sounds wrong.


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

Reply via email to