On Mon, 2016-01-18 at 12:53 +0530, Prashant Bapat wrote: > Hi, > > There close to a dozen 389-DS as part of our FreeIPA infra. On one of > these > servers, I'm encountering a strange problem. > > We monitor the state of replication among the 389 servers using a > python-ldap based script. This works on all servers except 1. > > What I'm doing is fairly basic. Something along lines of ; > > ldapsearch -x -b cn=config '(objectclass=nsds5replicationagreement)' > nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no > > Corresponding python code is below; > > conn.search_s("cn=config" ,ldap.SCOPE_SUBTREE, > '(objectclass=nsds5replicationagreement)', ["nsDS5ReplicaHost", > "nsds5replicaLastUpdateStatus", "nsds5replicaLastUpdateStart", > "nsds5replicaLastUpdateEnd"]) > > Now for the strange issue. > > The above commands return the status of replication on all servers > except 1 > which returns an empty response. This happens only for the python and > the > example perl script here > <http://directory.fedoraproject.org/docs/389ds/howto/howto-replicatio > nmonitoring.html>. > The ldapsearch command works fine!!! > > Below is the log from a server where this runs fine. > > [18/Jan/2016:07:09:19 +0000] conn=420951 fd=564 slot=564 connection > from > ::1 to ::1 > [18/Jan/2016:07:09:19 +0000] conn=420951 op=0 BIND dn="" method=128 > version=3 > [18/Jan/2016:07:09:19 +0000] conn=420951 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="" > [18/Jan/2016:07:09:19 +0000] conn=420951 op=1 SRCH base="cn=config" > scope=2 > filter="(objectClass=nsds5replicationagreement)" > attrs="nsDS5ReplicaHost > nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart > nsds5replicaLastUpdateEnd" > [18/Jan/2016:07:09:19 +0000] conn=420951 op=1 RESULT err=0 tag=101 > nentries=3 etime=0 > [18/Jan/2016:07:09:19 +0000] conn=420951 op=2 UNBIND > [18/Jan/2016:07:09:19 +0000] conn=420951 op=2 fd=564 closed - U1 > > Below is the log from the 1 server where this fails. > > [18/Jan/2016:07:05:20 +0000] conn=226 fd=80 slot=80 connection from > ::1 to > ::1 > [18/Jan/2016:07:05:20 +0000] conn=226 op=0 BIND dn="" method=128 > version=3 > [18/Jan/2016:07:05:20 +0000] conn=226 op=0 RESULT err=0 tag=97 > nentries=0 > etime=0 dn="" > [18/Jan/2016:07:05:20 +0000] conn=226 op=1 SRCH base="cn=config" > scope=2 > filter="(objectClass=nsds5replicationagreement)" > attrs="nsDS5ReplicaHost > nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart > nsds5replicaLastUpdateEnd" > [18/Jan/2016:07:05:20 +0000] conn=226 op=1 RESULT err=0 tag=101 > nentries=0 > etime=0 > [18/Jan/2016:07:05:20 +0000] conn=226 op=2 UNBIND > [18/Jan/2016:07:05:20 +0000] conn=226 op=2 fd=80 closed - U1 > > I have an ACI which allows anonymous access to the replication info. > > Version is : 389-ds-base-1.3.3.13-1.fc21.x86_64 > > Any help would be appreciated. > > Thanks. > --Prashant > -- > 389 users mailing list > 389-users@%(host_name)s > http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproj > ect.org The obvious first check is, does the server actually have a valid replication agreement? You can check this by looking at /etc/dirsrv/slapd-INSTANCE_NAME/dse.ldif. Second, check the aci on the server. Hope this helps. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

On 01/18/2016 01:12 PM, Prashant Bapat wrote: It does. Running the ldapsearch command gives me the expected output. Below is what I'm running. $ ldapsearch -x -b cn=config '(objectclass=nsds5replicationagreement)' nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no dn: cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental update succeeded dn: cn=meToipa3.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsds5replicaLastUpdateStatus: 1 Can't acquire busy replica dn: cn=meToipa4.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental update succeeded This also indicates that the aci is proper. are you sure ldapsearch runs against the same server ? If you don't specify -H or -h -p it could take the target from the ldap.conf Thanks. --Prashant On 18 January 2016 at 14:01, William Brown <wibrown(a)redhat.com&gt; wrote: > On Mon, 2016-01-18 at 12:53 +0530, Prashant Bapat wrote: > > Hi, > > > > There close to a dozen 389-DS as part of our FreeIPA infra. On one of > > these > > servers, I'm encountering a strange problem. > > > > We monitor the state of replication among the 389 servers using a > > python-ldap based script. This works on all servers except 1. > > > > What I'm doing is fairly basic. Something along lines of ; > > > > ldapsearch -x -b cn=config '(objectclass=nsds5replicationagreement)' > > nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no > > > > Corresponding python code is below; > > > > conn.search_s("cn=config" ,ldap.SCOPE_SUBTREE, > > '(objectclass=nsds5replicationagreement)', ["nsDS5ReplicaHost", > > "nsds5replicaLastUpdateStatus", "nsds5replicaLastUpdateStart", > > "nsds5replicaLastUpdateEnd"]) > > > > Now for the strange issue. > > > > The above commands return the status of replication on all servers > > except 1 > > which returns an empty response. This happens only for the python and > > the > > example perl script here > > <http://directory.fedoraproject.org/docs/389ds/howto/howto-replicatio > > nmonitoring.html>. > > The ldapsearch command works fine!!! > > > > Below is the log from a server where this runs fine. > > > > [18/Jan/2016:07:09:19 +0000] conn=420951 fd=564 slot=564 connection > > from > > ::1 to ::1 > > [18/Jan/2016:07:09:19 +0000] conn=420951 op=0 BIND dn="" method=128 > > version=3 > > [18/Jan/2016:07:09:19 +0000] conn=420951 op=0 RESULT err=0 tag=97 > > nentries=0 etime=0 dn="" > > [18/Jan/2016:07:09:19 +0000] conn=420951 op=1 SRCH base="cn=config" > > scope=2 > > filter="(objectClass=nsds5replicationagreement)" > > attrs="nsDS5ReplicaHost > > nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart > > nsds5replicaLastUpdateEnd" > > [18/Jan/2016:07:09:19 +0000] conn=420951 op=1 RESULT err=0 tag=101 > > nentries=3 etime=0 > > [18/Jan/2016:07:09:19 +0000] conn=420951 op=2 UNBIND > > [18/Jan/2016:07:09:19 +0000] conn=420951 op=2 fd=564 closed - U1 > > > > Below is the log from the 1 server where this fails. > > > > [18/Jan/2016:07:05:20 +0000] conn=226 fd=80 slot=80 connection from > > ::1 to > > ::1 > > [18/Jan/2016:07:05:20 +0000] conn=226 op=0 BIND dn="" method=128 > > version=3 > > [18/Jan/2016:07:05:20 +0000] conn=226 op=0 RESULT err=0 tag=97 > > nentries=0 > > etime=0 dn="" > > [18/Jan/2016:07:05:20 +0000] conn=226 op=1 SRCH base="cn=config" > > scope=2 > > filter="(objectClass=nsds5replicationagreement)" > > attrs="nsDS5ReplicaHost > > nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart > > nsds5replicaLastUpdateEnd" > > [18/Jan/2016:07:05:20 +0000] conn=226 op=1 RESULT err=0 tag=101 > > nentries=0 > > etime=0 > > [18/Jan/2016:07:05:20 +0000] conn=226 op=2 UNBIND > > [18/Jan/2016:07:05:20 +0000] conn=226 op=2 fd=80 closed - U1 > > > > I have an ACI which allows anonymous access to the replication info. > > > > Version is : 389-ds-base-1.3.3.13-1.fc21.x86_64 > > > > Any help would be appreciated. > > > > Thanks. > > --Prashant > > -- > > 389 users mailing list > > 389-users@%(host_name)s > > http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproj > > ect.org > > > The obvious first check is, does the server actually have a valid > replication agreement? You can check this by looking at > /etc/dirsrv/slapd-INSTANCE_NAME/dse.ldif. > > Second, check the aci on the server. > > Hope this helps. > > -- > Sincerely, > > William Brown > Software Engineer > Red Hat, Brisbane > > > -- > 389 users mailing list > 389-users@%(host_name)s > > http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org > -- 389 users mailing list 389-users@%(host_name)shttp://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

On 01/18/2016 05:09 PM, Prashant Bapat wrote: Indeed! When I specify -h localhost it returns empty result. this indicates that you really don't have a replication agreement on this server, the search without localhost goes to another server. You can check by looking into the config file: /etc/dirsrv/slapd-<INSTANCE>/dse.ldif So here is the problem. I have the below aci to read the replication status anonymously. dn: cn=mapping tree,cn=config changetype: modify replace: aci aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement) (objectclass=nsDSWindowsReplicationAgreement))")(version 3.0; aci "permission:Read Replication Agreements"; allow (read, search, compare) groupdn = "ldap:///anyone";) I have the exact same aci which seems to work on my other servers. But on this one server its not working. I have double checked that the aci is present. Also, I'm able to read the replication status as "directory manager". Any help appreciated. Thanks. --Prashant On 18 January 2016 at 20:45, Ludwig Krispenz <lkrispen(a)redhat.com&gt; wrote: > > On 01/18/2016 01:12 PM, Prashant Bapat wrote: > > It does. > > Running the ldapsearch command gives me the expected output. Below is > what I'm running. > > $ ldapsearch -x -b cn=config '(objectclass=nsds5replicationagreement)' > nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no > dn: cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config > nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: > Incremental update succeeded > > dn: cn=meToipa3.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config > nsds5replicaLastUpdateStatus: 1 Can't acquire busy replica > > dn: cn=meToipa4.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping > tree,cn=config > nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: > Incremental update succeeded > > This also indicates that the aci is proper. > > are you sure ldapsearch runs against the same server ? If you don't > specify -H or -h -p it could take the target from the ldap.conf > > > Thanks. > --Prashant > > On 18 January 2016 at 14:01, William Brown <wibrown(a)redhat.com&gt; wrote: > >> On Mon, 2016-01-18 at 12:53 +0530, Prashant Bapat wrote: >> > Hi, >> > >> > There close to a dozen 389-DS as part of our FreeIPA infra. On one of >> > these >> > servers, I'm encountering a strange problem. >> > >> > We monitor the state of replication among the 389 servers using a >> > python-ldap based script. This works on all servers except 1. >> > >> > What I'm doing is fairly basic. Something along lines of ; >> > >> > ldapsearch -x -b cn=config '(objectclass=nsds5replicationagreement)' >> > nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no >> > >> > Corresponding python code is below; >> > >> > conn.search_s("cn=config" ,ldap.SCOPE_SUBTREE, >> > '(objectclass=nsds5replicationagreement)', ["nsDS5ReplicaHost", >> > "nsds5replicaLastUpdateStatus", "nsds5replicaLastUpdateStart", >> > "nsds5replicaLastUpdateEnd"]) >> > >> > Now for the strange issue. >> > >> > The above commands return the status of replication on all servers >> > except 1 >> > which returns an empty response. This happens only for the python and >> > the >> > example perl script here >> > <http://directory.fedoraproject.org/docs/389ds/howto/howto-replicatio >> > nmonitoring.html>. >> > The ldapsearch command works fine!!! >> > >> > Below is the log from a server where this runs fine. >> > >> > [18/Jan/2016:07:09:19 +0000] conn=420951 fd=564 slot=564 connection >> > from >> > ::1 to ::1 >> > [18/Jan/2016:07:09:19 +0000] conn=420951 op=0 BIND dn="" method=128 >> > version=3 >> > [18/Jan/2016:07:09:19 +0000] conn=420951 op=0 RESULT err=0 tag=97 >> > nentries=0 etime=0 dn="" >> > [18/Jan/2016:07:09:19 +0000] conn=420951 op=1 SRCH base="cn=config" >> > scope=2 >> > filter="(objectClass=nsds5replicationagreement)" >> > attrs="nsDS5ReplicaHost >> > nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart >> > nsds5replicaLastUpdateEnd" >> > [18/Jan/2016:07:09:19 +0000] conn=420951 op=1 RESULT err=0 tag=101 >> > nentries=3 etime=0 >> > [18/Jan/2016:07:09:19 +0000] conn=420951 op=2 UNBIND >> > [18/Jan/2016:07:09:19 +0000] conn=420951 op=2 fd=564 closed - U1 >> > >> > Below is the log from the 1 server where this fails. >> > >> > [18/Jan/2016:07:05:20 +0000] conn=226 fd=80 slot=80 connection from >> > ::1 to >> > ::1 >> > [18/Jan/2016:07:05:20 +0000] conn=226 op=0 BIND dn="" method=128 >> > version=3 >> > [18/Jan/2016:07:05:20 +0000] conn=226 op=0 RESULT err=0 tag=97 >> > nentries=0 >> > etime=0 dn="" >> > [18/Jan/2016:07:05:20 +0000] conn=226 op=1 SRCH base="cn=config" >> > scope=2 >> > filter="(objectClass=nsds5replicationagreement)" >> > attrs="nsDS5ReplicaHost >> > nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart >> > nsds5replicaLastUpdateEnd" >> > [18/Jan/2016:07:05:20 +0000] conn=226 op=1 RESULT err=0 tag=101 >> > nentries=0 >> > etime=0 >> > [18/Jan/2016:07:05:20 +0000] conn=226 op=2 UNBIND >> > [18/Jan/2016:07:05:20 +0000] conn=226 op=2 fd=80 closed - U1 >> > >> > I have an ACI which allows anonymous access to the replication info. >> > >> > Version is : 389-ds-base-1.3.3.13-1.fc21.x86_64 >> > >> > Any help would be appreciated. >> > >> > Thanks. >> > --Prashant >> > -- >> > 389 users mailing list >> > 389-users@%(host_name)s >> > http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproj >> > ect.org >> >> >> The obvious first check is, does the server actually have a valid >> replication agreement? You can check this by looking at >> /etc/dirsrv/slapd-INSTANCE_NAME/dse.ldif. >> >> Second, check the aci on the server. >> >> Hope this helps. >> >> -- >> Sincerely, >> >> William Brown >> Software Engineer >> Red Hat, Brisbane >> >> >> -- >> 389 users mailing list >> 389-users@%(host_name)s >> >> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org >> > > > > -- > 389 users mailing list > 389-users@%(host_name)shttp://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org > > > > -- > 389 users mailing list > 389-users@%(host_name)s > > http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org > -- 389 users mailing list 389-users@%(host_name)shttp://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

Prashant Bapat wrote: > Not actually. When I read the replication status as "directory manager" > I can see the agreements. It really boils down to the aci issue now. What confuses me is the ldif using replace. What were you replacing? Can you search for the actual installed ACI? I'd have used userdn = "ldap://anyone" and not groupdn. I'm not sure if that is the problem or not.

rob > On 18 January 2016 at 21:45, Ludwig Krispenz <lkrispen(a)redhat.com > <mailto:lkrispen@redhat.com>> wrote: > > > On 01/18/2016 05:09 PM, Prashant Bapat wrote: >> Indeed! When I specify -h localhost it returns empty result. > this indicates that you really don't have a replication agreement on > this server, the search without localhost goes to another server. > You can check by looking into the config file: > /etc/dirsrv/slapd-<INSTANCE>/dse.ldif > > >> So here is the problem. I have the below aci to read the >> replication status anonymously. >> >> dn: cn=mapping tree,cn=config >> changetype: modify >> replace: aci >> aci: >> (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement) >> (objectclass=nsDSWindowsReplicationAgreement))")(version 3.0; aci >> "permission:Read Replication Agreements"; allow (read, search, >> compare) >> groupdn = "ldap:///anyone";) >> >> I have the exact same aci which seems to work on my other servers. >> But on this one server its not working. I have double checked that >> the aci is present. Also, I'm able to read the replication status >> as "directory manager". >> >> Any help appreciated. >> >> Thanks. >> --Prashant >> >> >> >> On 18 January 2016 at 20:45, Ludwig Krispenz <lkrispen(a)redhat.com >> <mailto:lkrispen@redhat.com>> wrote: >> >> >> On 01/18/2016 01:12 PM, Prashant Bapat wrote: >>> It does. >>> >>> Running the ldapsearch command gives me the expected output. >>> Below is what I'm running. >>> >>> $ ldapsearch -x -b cn=config >>> '(objectclass=nsds5replicationagreement)' >>> nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no >>> dn: cn=meToipa2.example.com >>> <http://meToipa2.example.com>,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=... >>> tree,cn=config >>> nsds5replicaLastUpdateStatus: 0 Replica acquired >>> successfully: Incremental update succeeded >>> >>> dn: cn=meToipa3.example.com >>> <http://meToipa3.example.com>,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=... >>> tree,cn=config >>> nsds5replicaLastUpdateStatus: 1 Can't acquire busy replica >>> >>> dn: cn=meToipa4.example.com >>> <http://meToipa4.example.com>,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=... >>> tree,cn=config >>> nsds5replicaLastUpdateStatus: 0 Replica acquired >>> successfully: Incremental update succeeded >>> >>> This also indicates that the aci is proper. >> are you sure ldapsearch runs against the same server ? If you >> don't specify -H or -h -p it could take the target from the >> ldap.conf >> >>> Thanks. >>> --Prashant >>> >>> On 18 January 2016 at 14:01, William Brown >>> <wibrown(a)redhat.com <mailto:wibrown@redhat.com>> wrote: >>> >>> On Mon, 2016-01-18 at 12:53 +0530, Prashant Bapat wrote: >>> > Hi, >>> > >>> > There close to a dozen 389-DS as part of our FreeIPA >>> infra. On one of >>> > these >>> > servers, I'm encountering a strange problem. >>> > >>> > We monitor the state of replication among the 389 >>> servers using a >>> > python-ldap based script. This works on all servers >>> except 1. >>> > >>> > What I'm doing is fairly basic. Something along lines of ; >>> > >>> > ldapsearch -x -b cn=config >>> '(objectclass=nsds5replicationagreement)' >>> > nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no >>> > >>> > Corresponding python code is below; >>> > >>> > conn.search_s("cn=config" ,ldap.SCOPE_SUBTREE, >>> > '(objectclass=nsds5replicationagreement)', >>> ["nsDS5ReplicaHost", >>> > "nsds5replicaLastUpdateStatus", >>> "nsds5replicaLastUpdateStart", >>> > "nsds5replicaLastUpdateEnd"]) >>> > >>> > Now for the strange issue. >>> > >>> > The above commands return the status of replication on >>> all servers >>> > except 1 >>> > which returns an empty response. This happens only for >>> the python and >>> > the >>> > example perl script here >>> > >>> <http://directory.fedoraproject.org/docs/389ds/howto/howto-replicatio >>> > nmonitoring.html>. >>> > The ldapsearch command works fine!!! >>> > >>> > Below is the log from a server where this runs fine. >>> > >>> > [18/Jan/2016:07:09:19 +0000] conn=420951 fd=564 >>> slot=564 connection >>> > from >>> > ::1 to ::1 >>> > [18/Jan/2016:07:09:19 +0000] conn=420951 op=0 BIND >>> dn="" method=128 >>> > version=3 >>> > [18/Jan/2016:07:09:19 +0000] conn=420951 op=0 RESULT >>> err=0 tag=97 >>> > nentries=0 etime=0 dn="" >>> > [18/Jan/2016:07:09:19 +0000] conn=420951 op=1 SRCH >>> base="cn=config" >>> > scope=2 >>> > filter="(objectClass=nsds5replicationagreement)" >>> > attrs="nsDS5ReplicaHost >>> > nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart >>> > nsds5replicaLastUpdateEnd" >>> > [18/Jan/2016:07:09:19 +0000] conn=420951 op=1 RESULT >>> err=0 tag=101 >>> > nentries=3 etime=0 >>> > [18/Jan/2016:07:09:19 +0000] conn=420951 op=2 UNBIND >>> > [18/Jan/2016:07:09:19 +0000] conn=420951 op=2 fd=564 >>> closed - U1 >>> > >>> > Below is the log from the 1 server where this fails. >>> > >>> > [18/Jan/2016:07:05:20 +0000] conn=226 fd=80 slot=80 >>> connection from >>> > ::1 to >>> > ::1 >>> > [18/Jan/2016:07:05:20 +0000] conn=226 op=0 BIND dn="" >>> method=128 >>> > version=3 >>> > [18/Jan/2016:07:05:20 +0000] conn=226 op=0 RESULT err=0 >>> tag=97 >>> > nentries=0 >>> > etime=0 dn="" >>> > [18/Jan/2016:07:05:20 +0000] conn=226 op=1 SRCH >>> base="cn=config" >>> > scope=2 >>> > filter="(objectClass=nsds5replicationagreement)" >>> > attrs="nsDS5ReplicaHost >>> > nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart >>> > nsds5replicaLastUpdateEnd" >>> > [18/Jan/2016:07:05:20 +0000] conn=226 op=1 RESULT err=0 >>> tag=101 >>> > nentries=0 >>> > etime=0 >>> > [18/Jan/2016:07:05:20 +0000] conn=226 op=2 UNBIND >>> > [18/Jan/2016:07:05:20 +0000] conn=226 op=2 fd=80 closed >>> - U1 >>> > >>> > I have an ACI which allows anonymous access to the >>> replication info. >>> > >>> > Version is : 389-ds-base-1.3.3.13-1.fc21.x86_64 >>> > >>> > Any help would be appreciated. >>> > >>> > Thanks. >>> > --Prashant >>> > -- >>> > 389 users mailing list >>> > 389-users@%(host_name)s >>> > >>> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproj >>> > ect.org <http://ect.org> >>> >>> >>> The obvious first check is, does the server actually have >>> a valid >>> replication agreement? You can check this by looking at >>> /etc/dirsrv/slapd-INSTANCE_NAME/dse.ldif. >>> >>> Second, check the aci on the server. >>> >>> Hope this helps. >>> >>> -- >>> Sincerely, >>> >>> William Brown >>> Software Engineer >>> Red Hat, Brisbane >>> >>> >>> -- >>> 389 users mailing list >>> 389-users@%(host_name)s >>> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org >>> >>> >>> >>> >>> -- >>> 389 users mailing list >>> 389-users@%(host_name)s >>> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org >> >> -- >> 389 users mailing list >> 389-users@%(host_name)s >> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org >> >> >> >> >> -- >> 389 users mailing list >> 389-users@%(host_name)s >> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org > > -- > 389 users mailing list > 389-users@%(host_name)s > http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org > > > > > -- > 389 users mailing list > 389-users@%(host_name)s > http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org > -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

Thanks all for the inputs. Its finally working now. Somehow the ldapmodify command was not adding the aci to the localhost. I guess in other servers this was added thru replication but not on this one.

Finally below command is what fixed it. ldapmodify -h localhost -D "cn=directory manager" -W -f repl-status-aci.ldif I was not specifying "-h localhost" previously.

Btw it works both with groupdn = "ldap:///anyone" as well asuserdn = "ldap:///anyone"

Appreciate all the help. Thanks. --Prashant On 18 January 2016 at 21:57, Ludwig Krispenz <lkrispen(a)redhat.com <mailto:lkrispen@redhat.com>> wrote: On 01/18/2016 05:19 PM, Rob Crittenden wrote: Prashant Bapat wrote: Not actually. When I read the replication status as "directory manager" I can see the agreements. It really boils down to the aci issue now. What confuses me is the ldif using replace. What were you replacing? Can you search for the actual installed ACI? I'd have used userdn = "ldap://anyone" and not groupdn. I'm not sure if that is the problem or not. great eyes :-) should be userdn rob On 18 January 2016 at 21:45, Ludwig Krispenz <lkrispen(a)redhat.com <mailto:lkrispen@redhat.com> <mailto:lkrispen@redhat.com <mailto:lkrispen@redhat.com>>> wrote: On 01/18/2016 05:09 PM, Prashant Bapat wrote: Indeed! When I specify -h localhost it returns empty result. this indicates that you really don't have a replication agreement on this server, the search without localhost goes to another server. You can check by looking into the config file: /etc/dirsrv/slapd-<INSTANCE>/dse.ldif So here is the problem. I have the below aci to read the replication status anonymously. dn: cn=mapping tree,cn=config changetype: modify replace: aci aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement) (objectclass=nsDSWindowsReplicationAgreement))")(version 3.0; aci "permission:Read Replication Agreements"; allow (read, search, compare) groupdn = "ldap:///anyone";) I have the exact same aci which seems to work on my other servers. But on this one server its not working. I have double checked that the aci is present. Also, I'm able to read the replication status as "directory manager". Any help appreciated. Thanks. --Prashant On 18 January 2016 at 20:45, Ludwig Krispenz <lkrispen(a)redhat.com <mailto:lkrispen@redhat.com> <mailto:lkrispen@redhat.com <mailto:lkrispen@redhat.com>>> wrote: On 01/18/2016 01:12 PM, Prashant Bapat wrote: It does. Running the ldapsearch command gives me the expected output. Below is what I'm running. $ ldapsearch -x -b cn=config '(objectclass=nsds5replicationagreement)' nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no dn: cn=meToipa2.example.com <http://meToipa2.example.com> <http://meToipa2.example.com>,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=... tree,cn=config nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental update succeeded dn: cn=meToipa3.example.com <http://meToipa3.example.com> <http://meToipa3.example.com>,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=... tree,cn=config nsds5replicaLastUpdateStatus: 1 Can't acquire busy replica dn: cn=meToipa4.example.com <http://meToipa4.example.com> <http://meToipa4.example.com>,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=... tree,cn=config nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental update succeeded This also indicates that the aci is proper. are you sure ldapsearch runs against the same server ? If you don't specify -H or -h -p it could take the target from the ldap.conf Thanks. --Prashant On 18 January 2016 at 14:01, William Brown <wibrown(a)redhat.com <mailto:wibrown@redhat.com> <mailto:wibrown@redhat.com <mailto:wibrown@redhat.com>>> wrote: On Mon, 2016-01-18 at 12:53 +0530, Prashant Bapat wrote: > Hi, > > There close to a dozen 389-DS as part of our FreeIPA infra. On one of > these > servers, I'm encountering a strange problem. > > We monitor the state of replication among the 389 servers using a > python-ldap based script. This works on all servers except 1. > > What I'm doing is fairly basic. Something along lines of ; > > ldapsearch -x -b cn=config '(objectclass=nsds5replicationagreement)' > nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no > > Corresponding python code is below; > > conn.search_s("cn=config" ,ldap.SCOPE_SUBTREE, > '(objectclass=nsds5replicationagreement)', ["nsDS5ReplicaHost", > "nsds5replicaLastUpdateStatus", "nsds5replicaLastUpdateStart", > "nsds5replicaLastUpdateEnd"]) > > Now for the strange issue. > > The above commands return the status of replication on all servers > except 1 > which returns an empty response. This happens only for the python and > the > example perl script here > <http://directory.fedoraproject.org/docs/389ds/howto/howto-replicatio > nmonitoring.html>. > The ldapsearch command works fine!!! > > Below is the log from a server where this runs fine. > > [18/Jan/2016:07:09:19 +0000] conn=420951 fd=564 slot=564 connection > from > ::1 to ::1 > [18/Jan/2016:07:09:19 +0000] conn=420951 op=0 BIND dn="" method=128 > version=3 > [18/Jan/2016:07:09:19 +0000] conn=420951 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="" > [18/Jan/2016:07:09:19 +0000] conn=420951 op=1 SRCH base="cn=config" > scope=2 > filter="(objectClass=nsds5replicationagreement)" > attrs="nsDS5ReplicaHost > nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart > nsds5replicaLastUpdateEnd" > [18/Jan/2016:07:09:19 +0000] conn=420951 op=1 RESULT err=0 tag=101 > nentries=3 etime=0 > [18/Jan/2016:07:09:19 +0000] conn=420951 op=2 UNBIND > [18/Jan/2016:07:09:19 +0000] conn=420951 op=2 fd=564 closed - U1 > > Below is the log from the 1 server where this fails. > > [18/Jan/2016:07:05:20 +0000] conn=226 fd=80 slot=80 connection from > ::1 to > ::1 > [18/Jan/2016:07:05:20 +0000] conn=226 op=0 BIND dn="" method=128 > version=3 > [18/Jan/2016:07:05:20 +0000] conn=226 op=0 RESULT err=0 tag=97 > nentries=0 > etime=0 dn="" > [18/Jan/2016:07:05:20 +0000] conn=226 op=1 SRCH base="cn=config" > scope=2 > filter="(objectClass=nsds5replicationagreement)" > attrs="nsDS5ReplicaHost > nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart > nsds5replicaLastUpdateEnd" > [18/Jan/2016:07:05:20 +0000] conn=226 op=1 RESULT err=0 tag=101 > nentries=0 > etime=0 > [18/Jan/2016:07:05:20 +0000] conn=226 op=2 UNBIND > [18/Jan/2016:07:05:20 +0000] conn=226 op=2 fd=80 closed - U1 > > I have an ACI which allows anonymous access to the replication info. > > Version is : 389-ds-base-1.3.3.13-1.fc21.x86_64 > > Any help would be appreciated. > > Thanks. > --Prashant > -- > 389 users mailing list > 389-users@%(host_name)s > http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproj > ect.org <http://ect.org> <http://ect.org> The obvious first check is, does the server actually have a valid replication agreement? You can check this by looking at /etc/dirsrv/slapd-INSTANCE_NAME/dse.ldif. Second, check the aci on the server. Hope this helps. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org