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@xxxxxxxxxx > <mailto:lkrispen@xxxxxxxxxx>> 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@xxxxxxxxxx >> <mailto:lkrispen@xxxxxxxxxx>> 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@xxxxxxxxxx <mailto:wibrown@xxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxxxxxx >>> >>> >>> >>> >>> -- >>> 389 users mailing list >>> 389-users@%(host_name)s >>> http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx >> >> >> -- >> 389 users mailing list >> 389-users@%(host_name)s >> http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx >> >> >> >> >> -- >> 389 users mailing list >> 389-users@%(host_name)s >> http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx > > > -- > 389 users mailing list > 389-users@%(host_name)s > http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx > > > > > -- > 389 users mailing list > 389-users@%(host_name)s > http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx > -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
