On Tue, 2015-06-02 at 17:45 +0200, Martin Kosek wrote: > On 06/02/2015 05:41 PM, Alexander Bokovoy wrote: > > On Tue, 02 Jun 2015, Martin Kosek wrote: > >> On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: > >>> On Tue, 02 Jun 2015, Martin Kosek wrote: > >>>> On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: > >>>>> > >>>>> On 06/02/2015 05:16 PM, Martin Kosek wrote: > >>>>>> On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: > >>>>>>> On 06/02/2015 03:53 PM, Petr Vobornik wrote: > >>>>>>>> On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: > >>>>>>>>> On 06/02/2015 12:09 PM, Oleg Fayans wrote: > >>>>>>>>>> Hi all, > >>>>>>>>>> > >>>>>>>>>> The following error was caught during replica installation (I used > >>>>>>>>>> all > >>>>>>>>>> the latest patches from Ludwig and Martin Basti): > >>>>>>>> - except ldap.TYPE_OR_VALUE_EXISTS: > >>>>>>>> + except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): > >>>>>>>> > >>>>>>>> What happens if all replicas are updated and domain level is raised? > >>>>>>>> I > >>>>>>>> don't > >>>>>>>> think that the group will be populated. Or will it be? Without it, > >>>>>>>> topology > >>>>>>>> plugin won't work, right? > >>>>>>> good point, > >>>>>>> it will be limited, when adding a new segment a replication agreement > >>>>>>> will be > >>>>>>> created, but it will not have the credentials to replicate. > >>>>>>>> There should be a moment where all the DNs are added. > >>>>>>> yes, there could probably be a check when topology plugin gets active > >>>>>>> if > >>>>>>> the > >>>>>>> binddn group exists and if not create and populate it > >>>>>> Should we finally start maintaining by default IPA Masters hostgroup? > >>>>>> *That* > >>>>>> should be the BIND DN group which Topology plugins works with, no? > >>>>> what would be the members of this group ? > >>>>> the binddn group needs all the ldap principals in it so that a replica > >>>>> can do > >>>>> gssapi replication to another replica. > >>>> > >>>> Ah. Hosts would be members of the group, i.e. host/server1.example.test > >>>> principals. If this is the case, the IPA Masters group does not look that > >>>> helpful. > >>> No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This > >>> is exception in the way Kerberos services addressed. > >> > >> Sure. But my point here was that host principals (and a hostgroup) are not > >> helpful here as DS will be authenticating with ldap/... principals. > > Correct, so you need to go one step more and simply add > > krbprincipalname=ldap/ipa.master,... to the list. You know that if the > > host from IPA Masters hostgroup, then it has to have ldap service and if > > it is not, then it is not a master, so you'd skip that one. > > Ah, so this is what you though. I am not sure here, I do not think we made > services members of host group in the past. And I am not convinced we want to > start with it now. CCing Simo for reference. > > Wouldn't a system group (sysaccounts) of "replication managers" with just the > ldap/ principals cleaner and perfectly inline with what we did with > "cn=adtrust > agents,cn=sysaccounts,cn=etc,SUFFIX"?
I do not have a strong preference, the advantage of a host group is that admins can see and manipulate it ... and that is also the disadvantage in this case. As it is a great way to break replication. So perhaps, yes, having a masters groups under sysaccount may be safer for now. Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
