[Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation

[Alexander Bokovoy]

On Tue, 02 Jun 2015, Simo Sorce wrote:
>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.
I'm fine to have that too, we rely on it in trusts case so just follow
the pattern.
-- 
/ Alexander Bokovoy