Prashant Bapat wrote: > 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. cn=config is not replicated. > 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. If you look in /etc/openldap/ldap.conf you'll see the default configuration. I'd guess URI points elsewhere though on an IPA master it should point to itself. > > Btw it works both with groupdn = "ldap:///anyone"; as well asuserdn > = "ldap:///anyone"; Interesting, good to know. rob > > Appreciate all the help. > > Thanks. > --Prashant > > On 18 January 2016 at 21:57, Ludwig Krispenz <lkrispen@xxxxxxxxxx > <mailto:lkrispen@xxxxxxxxxx>> 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@xxxxxxxxxx <mailto:lkrispen@xxxxxxxxxx> > <mailto: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> > <mailto: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> > > <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> > > <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> > > <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> > <mailto: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> <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 > > -- > 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
