Works for me.

On 25.11.2015 21:35, Oleg Fayans wrote:

Should I cover ticket N 3416 in the replica promotion test plan? It
should be tested, and IMO there is no sense in creating a separate test
plan for just that.

On 11/19/2015 03:43 PM, Jan Cholasta wrote:

the attached patches fix <>
and <>.

I worked around the issue of checking if the user is privileged to
perform replica promotion by using host credentials instead. The host
must be a member of the IPA servers host group "ipaservers" in order to
be able to promote itself. Using host credentials will also allow
replica install using one-time password.

User credentials are still used for connection check and to
automatically add the host to ipaservers if the user is privileged to do

Simo, is this approach OK? Could you check the new ACIs in patches 510
and 513?

I have a couple of questions:

1) Why are custodia keys for the replica added to LDAP using connection
to the remote master instead of local ldapi connection? Is it to
eliminate race conditions caused by replication timeout from the replica
to the remote master?

If the code was changed to use ldapi and wait until the key appears in
custodia on the remote master, we could lose the "IPA server hosts can
create own Custodia secrets" and "IPA server hosts can manage own
Custodia secrets" ACIs from patch 510. Not sure if it's worth the change

2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'?

If 'member' was used instead, we would gain referential integrity and
the ability to add ACIs based on the attribute (think

3) Why is 'memberPrincipal' used in cn=custodia at all?

The hostname of the replica is already in 'cn', so instead of searching
cn=custodia for entries matching (memberPrincipal=host/$HOSTNAME), we
could get cn={enc,sig}/$HOSTNAME,cn=custodia directly.


Jan Cholasta

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA:

Reply via email to