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. I see you created "cn=replication managers,cn=etc,SUFFIX" group. I think this should work, with couple changes: - it should rather be in "cn=sysaccounts,cn=etc,SUFFIX", where other similar groups are. See for example "cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX" used for Trusts (populated by ipa-adtrust-install), it is exactly the same case, so it should follow the similar/same location and structure. - the group should be populated during new installation of 4.2 or upgrade to 4.2 so that Domain Level raise does not need to be overloaded and generate this group by itself. >> If this >> group is populated from FreeIPA 4.2+, raising to Domain Level 1 would mean no >> operation needed on FreeIPA side. >> >> This is part of the ticket >> https://fedorahosted.org/freeipa/ticket/3416 >> >> This looks as another change that should make it to the Alpha, no? >> >> Martin > -- 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