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

[Martin Kosek]

On 06/02/2015 06:00 PM, Alexander Bokovoy wrote:
> 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.

Cool! Who will do the work and make sure the group and the members are properly 
set on installation and upgrades? Petr1, Jan or anyone else? (The group should 
also move to sysaccounts container with this change).