A couple of follow-up questions and some results of an ldap search...
In your suggested ldapmodify statement:
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
1: Is the command only the first line and the remaining lines responses to interactive
prompts?
2: I know that <master host> is my host fqdn. What is supposed to replace
<suffix> in the dn=<suffix> declaration?
I did an ldapsearch on this ipa master. I was trying to determine the current settings on
this option before I modify it. Looking specifically for ReplicaBindDN section I found
the following:
# System: Read Replication Information, permissions, pbac, fbog.local
dn: cn=System: Read Replication Information,cn=permissions,cn=pbac,dc=fbog,dc= local
ipaPermTargetFilter: (objectclass=nsds5replica)
ipaPermRight: read
ipaPermRight: compare
ipaPermRight: search
ipaPermBindRuleType: all
ipaPermissionType: SYSTEM
ipaPermissionType: V2
ipaPermissionType: MANAGED
cn: System: Read Replication Information
objectClass: top
objectClass: groupofnames
objectClass: ipapermission
objectClass: ipapermissionv2
ipaPermDefaultAttr: nsds5replicatombstonepurgeinterval
ipaPermDefaultAttr: nsds5replicareferral
ipaPermDefaultAttr: nsstate
ipaPermDefaultAttr: cn
ipaPermDefaultAttr: nsds5flags
ipaPermDefaultAttr: nsds5replicacleanruv
ipaPermDefaultAttr: nsds5replicabinddn
ipaPermDefaultAttr: nsds5replicaprotocoltimeout
ipaPermDefaultAttr: nsds5replicatype
ipaPermDefaultAttr: nsds5replicachangecount
ipaPermDefaultAttr: nsds5replicaroot
ipaPermDefaultAttr: nsds5replicabackoffmin
ipaPermDefaultAttr: nsds5replicaname
ipaPermDefaultAttr: objectclass
ipaPermDefaultAttr: nsds5replicalegacyconsumer
ipaPermDefaultAttr: nsds5replicapurgedelay
ipaPermDefaultAttr: nsds5replicaid
ipaPermDefaultAttr: nsds5replicaautoreferral
ipaPermDefaultAttr: nsds5replicabackoffmax
ipaPermDefaultAttr: nsds5replicaabortcleanruv
ipaPermDefaultAttr: nsds5task
ipaPermLocation: cn=replication,cn=etc,dc=fbog,dc=local
There is not telling me what the current values are. I could not locate declarations for
nsds5ReplicaBindDNGroupCheckInterval. Does that even exist in ipa v3.0?
-Steven Auerbach
-----Original Message-----
From: thierry bordaz <tbordaz(a)redhat.com>
Sent: Tuesday, November 19, 2019 3:31 AM
To: Rob Crittenden <rcritten(a)redhat.com>; FreeIPA users list
<freeipa-users(a)lists.fedorahosted.org>
Cc: Auerbach, Steven <Steven.Auerbach(a)flbog.edu>
Subject: Re: [Freeipa-users] ipa-replica-install latest failure attempt:
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=acco
> unts,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=acco
> unts,dc=fbog,dc=local
>
>
>
> 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