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

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

Reply via email to