FreeIPA-users December 2019

freeipa-users@lists.fedorahosted.org

54 participants
74 discussions

Re: ipa-replica-install latest failure attempt:
by Florence Blanc-Renaud 03 Dec '19

03 Dec '19

On 12/2/19 7:10 PM, Auerbach, Steven via FreeIPA-users wrote: > 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? The suffix corresponds to your baseDN, but with escape characters (because the baseDN contains =). To find it, you can do # ldapsearch -D "cn=directory manager" -W -b "cn=mapping tree,cn=config" -s one -o ldif-wrap=no -LLL dn Enter LDAP Password: dn: cn=cn\3Dchangelog,cn=mapping tree,cn=config dn: cn=dc\3Dredhat\2Cdc\3Dcom,cn=mapping tree,cn=config dn: cn=o\3Dipaca,cn=mapping tree,cn=config So in my example, the suffix is dc=redhat,dc=com and the right way to escape chars is to write cn=dc\3Dredhat\2Cdc\3Dcom. > > 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: You probably did a search on your base DN (dc=fbog,dc=local), but the config you are looking for is in the cn=config subtree. The LDAP server is able to contain multiple baseDNs that are called suffixes or naming contexts. The user and group entries are stored below your usual base DN dc=fbog,dc=local but the configuration is stored separately below cn=config. Hope this clarifies, flo > # 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 > > _______________________________________________ > 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.fedorahost… >

1 0

Re: ipa-replica-install latest failure attempt:
by Mark Reynolds 02 Dec '19

02 Dec '19

On 12/2/19 1:10 PM, Auerbach, Steven via FreeIPA-users wrote: > 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? At the command prompt run the ldapmodify command, then you will be in a editor mode: # ldapmodify -D "cn=directory manager" -W <enter password when prompted> < You are now in the editor mode, enter these lines below, followed by two blank lines to initiate the operation. Then press Contorl-D to exit> dn: cn=replica,cn="dc=fbog,dc=local", cn=mapping tree,cn=config changetype: modify replace: nsds5ReplicaBindDNGroupCheckInterval nsds5ReplicaBindDNGroupCheckInterval: 3 <press enter twice> <press control-D to exit> HTH, Mark > 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 > > _______________________________________________ > 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.fedorahost… -- 389 Directory Server Development Team

1 0

Re: ipa-replica-install latest failure attempt:
by Rob Crittenden 02 Dec '19

02 Dec '19

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

4 3

autofs.service does not start
by Ronald Wimmer 02 Dec '19

02 Dec '19

After a reboot of a RHEL 7.7 machine autofs.service did not start:

1 1

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users December 2019