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