Weird issue with searching cn=config

List overview All Threads
Download

newer

older

REST API

389 and TLS woes

Prashant Bapat

18 Jan 2016 18 Jan '16

1:23 a.m.

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-replicationmonitoring.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

Attachments:

attachment.html (text/html — 6.5 KB)

Show replies by date

William Brown

18 Jan 18 Jan

2:31 a.m.

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

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

Prashant Bapat

6:12 a.m.

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,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,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsds5replicaLastUpdateStatus: 1 Can't acquire busy replica

dn: cn=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.

Thanks. --Prashant

On 18 January 2016 at 14:01, William Brown 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

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

Ludwig Krispenz

9:15 a.m.

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@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

Prashant Bapat

10:09 a.m.

Indeed! When I specify -h localhost it returns empty result.

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 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,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,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsds5replicaLastUpdateStatus: 1 Can't acquire busy replica

dn: cn=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@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

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)shttp://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

Ludwig Krispenz

10:15 a.m.

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.

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.

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@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

Prashant Bapat

10:16 a.m.

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.

On 18 January 2016 at 21:45, Ludwig Krispenz 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 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,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,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsds5replicaLastUpdateStatus: 1 Can't acquire busy replica

dn: cn=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@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

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)shttp://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)shttp://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

Rob Crittenden

10:19 a.m.

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@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.

    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@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

Ludwig Krispenz

10:27 a.m.

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@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.

     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@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

Prashant Bapat

10:36 a.m.

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 lkrispen@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 <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.

     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@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

Rob Crittenden

11:25 a.m.

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@redhat.com mailto:lkrispen@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
        <lkrispen@redhat.com <mailto:lkrispen@redhat.com>
        <mailto: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>
                 <mailto:lkrispen@redhat.com
            <mailto:lkrispen@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>

                 <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@redhat.com
                <mailto:wibrown@redhat.com>
                <mailto: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> <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

William Brown

3:20 p.m.

On Mon, 2016-01-18 at 12:25 -0500, Rob Crittenden wrote:

...

...
Btw it works both with groupdn = "ldap:///anyone" as well asuserdn = "ldap:///anyone"

Interesting, good to know.

I would assume it means "so long as you are a member of at least one group on the server, you have access to this"

It would be worth trying something like:

uid=testaccount,dc=example,dc=com objectClass: top objectClass: account objectClass: simpleSecurityObject uid: testaccount cn: testaccount userPassword: bar

And then seeing if this has access to the cn=config, even though it has no group.....

-- Sincerely, William Brown Software Engineer Red Hat, Brisbane

3160

Age (days ago)

3160

Last active (days ago)

389-users@lists.fedoraproject.org

11 comments

4 participants

tags (0)

participants (4)

Ludwig Krispenz
Prashant Bapat
Rob Crittenden
William Brown