On 06/02/2015 06:53 PM, Martin Kosek wrote:
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).

I will do it.
--
Petr Vobornik

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