Indeed! When I specify -h localhost it returns empty result. 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 <[email protected]> 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 <[email protected]> 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/[email protected] >> > 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/[email protected] >> > > > > -- > 389 users mailing list > 389-users@%(host_name)shttp://lists.fedoraproject.org/admin/lists/[email protected] > > > > -- > 389 users mailing list > 389-users@%(host_name)s > > http://lists.fedoraproject.org/admin/lists/[email protected] >
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/[email protected]
