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.
On 18 January 2016 at 21:45, Ludwig Krispenz <[email protected]> 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 <[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)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]
