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 <lkris...@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 <lkris...@redhat.com >>> <mailto:lkris...@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 <lkris...@redhat.com >>>> <mailto:lkris...@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 >>>>> <wibr...@redhat.com <mailto:wibr...@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 >
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
