On 01/18/2016 05:19 PM, Rob Crittenden wrote:
Prashant Bapat wrote:great eyes :-)
Not actually. When I read the replication status as "directory manager"What confuses me is the ldif using replace. What were you replacing? Can
I can see the agreements. It really boils down to the aci issue now.
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.
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.are you sure ldapsearch runs against the same server ? If you
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.
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