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@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@FBOG.LOCAL,cn=services,cn=accounts,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
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@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@FBOG.LOCAL,cn=services,cn=accounts,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
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@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@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@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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
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@redhat.com Sent: Tuesday, November 19, 2019 3:31 AM To: Rob Crittenden rcritten@redhat.com; FreeIPA users list freeipa-users@lists.fedorahosted.org Cc: Auerbach, Steven Steven.Auerbach@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@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@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
freeipa-users@lists.fedorahosted.org
-
Auerbach, Steven -
Florence Blanc-Renaud -
Rob Crittenden -
thierry bordaz