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 as userdn = "ldap:///anyone"

Appreciate all the help. 

Thanks.
--Prashant

On 18 January 2016 at 21:57, Ludwig Krispenz <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@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@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=mapping
         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=mapping
         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=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@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
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org