On 11/19/19 9:31 AM, thierry bordaz via FreeIPA-users wrote:
On 11/18/19 11:24 PM, Rob Crittenden wrote:
> Auerbach, Steven via FreeIPA-users wrote:
>> Executed ipa-replica-prepare on an RHEL 6.9 server running ipa-server
>> 3.0.0.1_51 (name : ipa01)
>>
>> Yum installed ipa-server, ipa-server-dns, bind-dyndb-ldap on the target
>> Linux 7.6 server (name: ipa04)
>>
>> Copied the file to the target server to which ipa-server 4.6.5-11.0.1 is
>> installed (ipa04)
>>
>> Copied the file :/usr/share/ipa/copy-schema-to-ca.py from ipa v4.6
>> server to the ipa v3.0 server and executed it successfully.
>>
>> Edited the /etc/resolv.con on ipa04 to include ipa01. Did not reboot.
>>
>> Executed ipa-replica-install --setup-dns --forwarder=8.8.8.8 --setup-ca
>> /var/lib/ipa/replica-info-ipa04.fbog.local.gpg (on ipa04)
>>
>>
>> 2019-11-16T16:23:24Z DEBUG The ipa-replica-install command failed,
>> exception: NotFound: wait_for_entry timeout on
>> ldap://ipa01.fbog.local:389 for
>>
krbprincipalname=HTTP/ipa04.fbog.local(a)FBOG.LOCAL,cn=services,cn=accounts,dc=fbog,dc=local
>>
>>
>> 2019-11-16T16:23:24Z ERROR wait_for_entry timeout on
>> ldap://ipa01.fbog.local:389 for
>>
krbprincipalname=HTTP/ipa04.fbog.local(a)FBOG.LOCAL,cn=services,cn=accounts,dc=fbog,dc=local
>>
>>
Hi,
Your issue looks a lot like this issue: 7976 Issue with adding multiple
RHEL 7 IPA replica to RHEL 6 IPA master [1].
Can you check the content of
cn=replica,cn=dc\3Ddomain\2Cdc\3Dcom,cn=mapping tree,cn=config on the
master (replace domain.con with your domain name)?
It should contain
nsDS5ReplicaBindDN:
krbprincipalname=ldap/replica.domain.com(a)DOMAIN.COM,cn=services,cn=accounts,dc=domain,dc=com
If it's not the case, it's likely that you are hitting the same bug.
flo
[1]
https://pagure.io/freeipa/issue/7976
>>
>> Not sure where to go from here. Did I leave out some declaration or
>> specification on the initial command?
> The problem isn't in the command invocation, replication is just slow
> enough for some reason that the new principal(s) weren't replicated to
> the existing master.
>
> I seem to recall a 389-ds option to mitigate this but I can't remember
> it off the to of my head (or maybe it isn't applicable for RHEL 6
> master). cc'ing someone who would know.
>
> rob
It is difficult to be sure without all logs (ipa-replica-install, DS
logs) and config.
From the top of my head I recall an old bug where the replica agreement
replica->master was failing to bind because master did not lookup the
updated bind group.
Rob, is it the bug you were thinking of ?
If it is this bug, you may try to set nsds5ReplicaBindDNGroupCheckInterval
ldapmodify -h <master_host> -p 389 -D "cn=directory manager" -W
dn: cn=replica,cn=<suffix>, cn=mapping tree,cn=config
changetype: modify
replace: nsds5ReplicaBindDNGroupCheckInterval
nsds5ReplicaBindDNGroupCheckInterval: 3
This modification does not require restart.
best regards
thierry
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...