[389-users] Re: Documentation as to how replication works

[Ludwig Krispenz]

Hi,

I think you cannot understand it by using the concept of CSN alone, you 
need also to be aware of RUV (replication update vector) and URP (update 
resolution protocol).


A CSN is generated with each externally applied modification, not for a 
replicated operation, it cantains a time stamp and the replica ID, so 
the CSNs are totally ordered. The CSN will be stored in the attribute 
value which was modified and at som etime will be purged.


The RUV is a vector of CSNs for all replicaids a specific replica has 
seen, in your example where alle replicas are in sync, the RUV on all 
replicas might be (97A,98B, 98C, 99D, 98E). Now you get simultaneous 
updates on all replicas at timestamp 100 and CSNs 100A,...100E will be 
generated. Before replication taking place all RUVs will be updated  
with the local change. So on replica C, the RUV will become  (97A,98B, 
100C, 99D, 98E). When a replication session C-->A will start it detects 
that it has updates to send, it will position at 98C in the changelog an 
start sending newer changes (eg 100C), A will process and apply this 
update and also update its RUV to (100A,98B, 100C, 99D, 98E). Since 
there will be other replication connections this will finally update all 
replica and RUVs to (100A,100B, 100C, 100D, 100E) and all replicas are 
in sync again.


Now assume that the updates 100x have been conflicting, eg an D an 
attribute was replaced by XXX and on by by YYY. The update resolution 
ensures that on all replicas the latest update (by CSN, not received) 
wins. sind D>B all attributes will finally have th valus XXX. This 
contains an atrificial decison on ordering CSNs but ensures that finally 
all replicas will hav the same data.


Hope this helps,

Ludwig

On 15.11.23 20:02, William Faulk wrote:

it isn't necessary to keep track of a list of CSNs

If it doesn't keep track of the CSNs, how does it know what data needs to be 
replicated?

That is, imagine replica A, whose latest CSN is 48, talks to replica B, whose 
latest CSN is 40. Clearly replica A should send some data to replica B. But if 
it isn't keeping track of what data is associated with CSNs 41 through 48, how 
does it know what data to send?


by asking the other node for its current ruv
can determine which if any of the changes it has need to be propagated to the 
peer.

In addition, the CSNs are apparently a timestamp and replica ID. So imagine a 
simple ring topology of replicas, A-B-C-D-E-(A), all in sync. Now imagine 
simultaneous changes on replicas A and C. C has a new CSN of, say, 100C, and it 
replicates that to B and D. At the same time, A replicates its new CSN of 100A 
to B and E. Now E has a new CSN. Is it 100A or 101E?

If E's new max CSN is 100A, then when it checks with D, D has a latest CSN of 
100C, which is greater than 100A, so the algorithm would seem to imply that 
there's nothing to replicate and the change that started at A doesn't get 
replicated to D.

If E's max CSN is 101E, then, when D checks in with its 101D, it thinks it 
doesn't have anything to send. I suppose in this scenario that the data would 
get there coming from the other direction. But if E's max CSN is 101E, 
eventually it's going to check in with A, which has a max CSN of 100A, so it 
would think that it needed to replicate that same data back to A, but it's 
already there. This is an obvious infinite loop.

I'm certain I'm missing something or misunderstanding something, but I don't 
understand what, and these details are what I'm trying to unravel.
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: Procedure to change the AD used to sync users

[Ludwig Krispenz]

Hi Mark,

I was late in the thread and missed that it is about winsync where 
things are different, sorry.


Regards,

Ludwig

On 16.09.22 22:11, Ludwig Krispenz wrote:



On 16.09.22 20:12, Mark Reynolds wrote:



On 9/16/22 1:40 PM, Ludwig Krispenz wrote:



On 16.09.22 19:16, Mark Reynolds wrote:



On 9/12/22 3:38 PM, Mihai Carabas wrote:



On Mon, Sep 12, 2022 at 6:35 PM Mark Reynolds 
 wrote:



On 9/12/22 10:58 AM, Mihai Carabas wrote:



On Fri, Sep 9, 2022 at 10:31 PM Mihai Carabas
 wrote:



On Wed, Aug 31, 2022 at 8:25 PM Mark Reynolds
 wrote:

Mihai,

Start with the docs:


https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/setting_up_windows_synchronization_between_active_directory_and_directory_server#configuring_the_database_for_synchronization_and_creating_the_synchronization_agreement_using_the_command_line

# dsconf slapd-INSTANCE repl-winsync-agmt list

# dsconf slapd-INSTANCE repl-winsync-agmt set --help

# dsconf slapd-INSTANCE repl-winsync-agmt set
--host=


# dsconf slapd-INSTANCE repl-winsync-agmt init



I did this:

[root@ldap ~]# dsconf slapd-ldap repl-winsync-agmt list
--suffix "dc=curs,dc=xxx,dc=yy" | grep Host
nsDS5ReplicaHost: ad--01.curs.xxx.yy
But in the logs:

[09/Sep/2022:22:23:43.366356845 +0300] - INFO -
NSMMReplicationPlugin - windows sync - windows_tot_run -
Beginning total update of replica
"agmt="cn=ad.curs.xxx.yy" (ad:636)".

And it connects to the old server (ad:636) [the old was
ad.curs.xxx.yy]. From where is getting that ad?


Any input here? A reboot is needed? Dropping changelog?


Try a server restart "dsctl slapd-ldap restart".  If it still
pulling in that old host then maybe you have an
extra/conflicting agreement?  "cn=ad.curs.xxx.yy" refers the
DN of the replication agreement.  So check if that is the same
DN of the agreement you have been modifying.




restart worked like a charm.

Is there a way to find out what config changes needs restart? (for 
future reasons)


Well in this case a replication agreement is processed at server 
startup or when it is first created.  The server will spawn a 
separate thread for each replication agreement.  Changes to things 
like port and hostname are not picked up in this agreement thread.  
So all changes to a replication agreement's configuration will 
require a server restart.



Are you sure ?


No :-)

Well changing the host name is only picked up on new replication 
connections.  So if the connection is long lived it will not pick up 
on the change.  Maybe that's what was happening here?


but there is agmt_set_host_from_entry() which calls 
prot_notify_agmt_changed(), so it should be picked up


We have/had a function "prot_notify_agmt_changed" which sets the 
state to EVENT_AGMT_CHANGED and the state machin will capture this 
and restart the incremantal protocol.


Ludwig


Mark

--
Directory Server Development Team

___
389-users mailing list --389-users@lists.fedoraproject.org
To unsubscribe send an email to389-users-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


___
389-users mailing list --389-users@lists.fedoraproject.org
To unsubscribe send an email to389-users-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue

--
Directory Server Development Team


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-

[389-users] Re: Procedure to change the AD used to sync users

[Ludwig Krispenz]

On 16.09.22 20:12, Mark Reynolds wrote:



On 9/16/22 1:40 PM, Ludwig Krispenz wrote:



On 16.09.22 19:16, Mark Reynolds wrote:



On 9/12/22 3:38 PM, Mihai Carabas wrote:



On Mon, Sep 12, 2022 at 6:35 PM Mark Reynolds  
wrote:



On 9/12/22 10:58 AM, Mihai Carabas wrote:



On Fri, Sep 9, 2022 at 10:31 PM Mihai Carabas
 wrote:



On Wed, Aug 31, 2022 at 8:25 PM Mark Reynolds
 wrote:

Mihai,

Start with the docs:


https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/setting_up_windows_synchronization_between_active_directory_and_directory_server#configuring_the_database_for_synchronization_and_creating_the_synchronization_agreement_using_the_command_line

# dsconf slapd-INSTANCE repl-winsync-agmt list

# dsconf slapd-INSTANCE repl-winsync-agmt set --help

# dsconf slapd-INSTANCE repl-winsync-agmt set
--host=


# dsconf slapd-INSTANCE repl-winsync-agmt init



I did this:

[root@ldap ~]# dsconf slapd-ldap repl-winsync-agmt list
--suffix "dc=curs,dc=xxx,dc=yy" | grep Host
nsDS5ReplicaHost: ad--01.curs.xxx.yy
But in the logs:

[09/Sep/2022:22:23:43.366356845 +0300] - INFO -
NSMMReplicationPlugin - windows sync - windows_tot_run -
Beginning total update of replica
"agmt="cn=ad.curs.xxx.yy" (ad:636)".

And it connects to the old server (ad:636) [the old was
ad.curs.xxx.yy]. From where is getting that ad?


Any input here? A reboot is needed? Dropping changelog?


Try a server restart "dsctl slapd-ldap restart". If it still
pulling in that old host then maybe you have an
extra/conflicting agreement? "cn=ad.curs.xxx.yy" refers the DN
of the replication agreement.  So check if that is the same DN
of the agreement you have been modifying.




restart worked like a charm.

Is there a way to find out what config changes needs restart? (for 
future reasons)


Well in this case a replication agreement is processed at server 
startup or when it is first created.  The server will spawn a 
separate thread for each replication agreement. Changes to things 
like port and hostname are not picked up in this agreement thread.  
So all changes to a replication agreement's configuration will 
require a server restart.



Are you sure ?


No :-)

Well changing the host name is only picked up on new replication 
connections.  So if the connection is long lived it will not pick up 
on the change.  Maybe that's what was happening here?


but there is agmt_set_host_from_entry() which calls 
prot_notify_agmt_changed(), so it should be picked up


We have/had a function "prot_notify_agmt_changed" which sets the 
state to EVENT_AGMT_CHANGED and the state machin will capture this 
and restart the incremantal protocol.


Ludwig


Mark

--
Directory Server Development Team

___
389-users mailing list --389-users@lists.fedoraproject.org
To unsubscribe send an email to389-users-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


___
389-users mailing list --389-users@lists.fedoraproject.org
To unsubscribe send an email to389-users-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue

--
Directory Server Development Team
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: Procedure to change the AD used to sync users

[Ludwig Krispenz]

On 16.09.22 19:16, Mark Reynolds wrote:



On 9/12/22 3:38 PM, Mihai Carabas wrote:



On Mon, Sep 12, 2022 at 6:35 PM Mark Reynolds  
wrote:



On 9/12/22 10:58 AM, Mihai Carabas wrote:



On Fri, Sep 9, 2022 at 10:31 PM Mihai Carabas
 wrote:



On Wed, Aug 31, 2022 at 8:25 PM Mark Reynolds
 wrote:

Mihai,

Start with the docs:


https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/setting_up_windows_synchronization_between_active_directory_and_directory_server#configuring_the_database_for_synchronization_and_creating_the_synchronization_agreement_using_the_command_line

# dsconf slapd-INSTANCE repl-winsync-agmt list

# dsconf slapd-INSTANCE repl-winsync-agmt set --help

# dsconf slapd-INSTANCE repl-winsync-agmt set
--host=


# dsconf slapd-INSTANCE repl-winsync-agmt init



I did this:

[root@ldap ~]# dsconf slapd-ldap repl-winsync-agmt list
--suffix "dc=curs,dc=xxx,dc=yy" | grep Host
nsDS5ReplicaHost: ad--01.curs.xxx.yy
But in the logs:

[09/Sep/2022:22:23:43.366356845 +0300] - INFO -
NSMMReplicationPlugin - windows sync - windows_tot_run -
Beginning total update of replica "agmt="cn=ad.curs.xxx.yy"
(ad:636)".

And it connects to the old server (ad:636) [the old was
ad.curs.xxx.yy]. From where is getting that ad?


Any input here? A reboot is needed? Dropping changelog?


Try a server restart "dsctl slapd-ldap restart".  If it still
pulling in that old host then maybe you have an extra/conflicting
agreement?  "cn=ad.curs.xxx.yy" refers the DN of the replication
agreement.  So check if that is the same DN of the agreement you
have been modifying.




restart worked like a charm.

Is there a way to find out what config changes needs restart? (for 
future reasons)


Well in this case a replication agreement is processed at server 
startup or when it is first created.  The server will spawn a separate 
thread for each replication agreement.  Changes to things like port 
and hostname are not picked up in this agreement thread.  So all 
changes to a replication agreement's configuration will require a 
server restart.


Are you sure ? We have/had a function "prot_notify_agmt_changed" which 
sets the state to EVENT_AGMT_CHANGED and the state machin will capture 
this and restart the incremantal protocol.


Ludwig


Mark

--
Directory Server Development Team

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Re: Default browsing index generation

[Ludwig Krispenz]

On 31.12.21 02:04, Mark Reynolds wrote:


If your clients are already using that "old" VLV index, you can look 
under cn=config of a 1.3.x server (after creating browsing index), and 
simply copy the VLV entries to 1.4.x and reindex.


or you could turn on audit logging, create a browsing index via console 
and use it to create the index with ldapmodify commands


So do you need to know how to recreate 1.3.x VLV indexes, or do you 
need help defining new ones?  The issue with VLV searches is that 
client must use very specific controls and parameters to engage the 
index.  If you have to create a new or different index the client will 
then have to be configured to use those new parameters.


Mark

On 12/30/21 6:07 PM, Joe Fletcher wrote:


Thanks for that. That presents a problem of sorts as I am going to 
have to try to design a suitable VLV index for a very aggressive 3^rd 
party client application.


Hopefully the vendor can be of assistance.

*From:*Mark Reynolds 
*Sent:* 30 December 2021 21:35
*To:* General discussion list for the 389 Directory server project. 
<389-users@lists.fedoraproject.org>; Joe Fletcher 

*Subject:* Re: [389-users] Re: Default browsing index generation

 The e-mail below is from an external source. Please do not open 
attachments or click links from an unknown or suspicious origin. 


On 12/30/21 3:01 PM, Joe Fletcher wrote:

Thanks for the reply. Is it possible to find out exactly what the
“create browsing index” feature in management console actually
did? Whatever it was it worked for us and I’m having a hard time
recreating the function.

The old java console created specific VLV indexes for "itself" (not 
for other clients).  So you could browse the Directory Tree in the 
java console without terrible performance hits.  So the VLV 
search/indexes it created were specific to the forms the console 
used.  Of course clients could use these VLV indexes, but they were 
only designed to be used by the console.


HTH,

Mark

*From:*Marc Sauton  
*Sent:* 30 December 2021 01:51
*To:* General discussion list for the 389 Directory server
project. <389-users@lists.fedoraproject.org>

*Subject:* [389-users] Re: Default browsing index generation

 The e-mail below is from an external source. Please do not
open attachments or click links from an unknown or suspicious
origin. 

in the web UI, it should be under "Database | Suffixes | dc=xx |
VLV Indexes"

to create a VLV index "Database | Suffixes | dc=xx | VLV Indexes
| Create VLV Index"

to re-index an existing VLV index "Database | Suffixes | dc=xx |
VLV Indexes |  select an existing VLV index | Action=Reindex VLV
Index"

-> popup window "Are you sure you want to reindex this VLV index?

carlicense

NO YES

->

Successfully completed VLV indexing

using the command line, for example with an instance-name called m1:

create some "dummy-non-sense-example" VLV index:

dsconf m1 backend vlv-index add-search --name=test1
--search-base=ou=people,dc=example,dc=test
--search-filter=carlicense=6ZBC246 --search-scope=2
dc=example,dc=test

dsconf m1 backend vlv-index add-index --sort roomNumber
--parent-name test1 --index-name indextest1  userroot

dsconf m1 backend vlv-index list userroot

( nothing )

dsconf m1 backend vlv-index reindex --index-name carlicense-index
--parent-name carlicense userroot

Index task index_vlv_12292021_162709 completed successfully
Successfully reindexed VLV indexes
[root@m1 ~]#

dsconf m1 backend vlv-index list userroot

dn: cn=test1,cn=userroot,cn=ldbm database,cn=plugins,cn=config
cn: test1
vlvbase: ou=people,dc=example,dc=test
vlvscope: 2
vlvfilter: (carlicense=1ABC123)
Sorts:
 - dn: cn=indextest1 ,cn=test1,cn=userroot,cn=ldbm
database,cn=plugins,cn=config
 - cn: indextest1
 - vlvsort: roomNumber
 - vlvenabled: 1
 - vlvuses: 0
Error: info() missing 1 required positional argument: 'msg'
[root@m1 ~]#

On Wed, Dec 29, 2021 at 2:56 PM Joe Fletcher
 wrote:

Hi,

We’re looking at 389 DS v1.4. Is there an equivalent in the
linux 8 cockpit to the feature that used to exist in the v
1.3 management console such that it can create default
browsing indexes?

In the old GUI it was simply a case of right-click and go
which did offer a certain level of convenience. So far I have
not found an equivalent in cockpit.

Currently most of my potential LDAP clients are unable to
browse the directory with the usual “Unwilling to perform:
search is not indexed”.

TIA

Joe

This email with all information contained herein or attached
hereto may contain confidential and/or privileged information

[389-users] Re: 389-DS Internal unindexed search

[Ludwig Krispenz]

On 15.11.21 15:55, Mark Reynolds wrote:



On 11/15/21 9:46 AM, Pierre Rogier wrote:
I feel a bit weird that we try to perform substring searches in the 
referential integrity plugin.

I would rather expect equality searches.
Does anyone know why the * are needed ?


It is used for MODRDN's like Thierry stated.  The code states that we 
use the substring filter to find the children memberships of the old 
DN so they can be properly cleaned up. I'm not sure this can be 
optimized to /not/ use a substring filter


yes, if the MODRDN is applied to an entry with children, like 
inThierry's example, I don't think the subtree search can be avoided. 
But when the referential integrity function is applied, it should be 
known if the renamed entry has children or is a leaf node - and could 
avoid the substring searches in most cases.


Regards,

Ludwig


Mark



On Mon, Nov 15, 2021 at 3:22 PM Thierry Bordaz  
wrote:


Hi,

The referential integrity plugins uses internal searches to retrieve
which entries referred to the target entry. The plugin uses equality
searches, that are indexed, but for MODRDN it uses substring
filter. As
membership attributes (member, uniquemember,...) are not indexed in
substring, each MODRDN triggers 4 (4 membership attributes)
unindexed
searches. referint being a betxn plugin, unindexed search are
prone to
create db retries and could be related to replication failure.

I would recommand that you try adding substring index to the member,
uniquemember, owner and seealso.

regards
thierry

On 11/15/21 3:00 PM, Ciber dgtnt wrote:
> Hi, I have a problem in 389-ds version 1.3.10.2-10 intalled on
Centos7 , we have a multimaster enviroment with consumers and
suppliers, we have referential integrity plugin to control the
group members. In the master node where we have the referential
integrity pluggin enabled, ocasionally we get this message in the
error log :
>
> NOTICE - ldbm_back_search - Internal unindexed search: source
(cn=referential integrity postoperation,cn=plugins,cn=config)
search base="c=es" scope=2 filter="(member=*uid=dmarmedr,ou=Baja
de cuentas,c=es)" conn=0 op=0
> NOTICE - ldbm_back_search - Internal unindexed search: source
(cn=referential integrity postoperation,cn=plugins,cn=config)
search base="c=es" scope=2
filter="(uniquemember=*uid=dmarmedr,ou=Baja de cuentas,c=es)"
conn=0 op=0
> NOTICE - ldbm_back_search - Internal unindexed search: source
(cn=referential integrity postoperation,cn=plugins,cn=config)
search base="c=es" scope=2 filter="(owner=*uid=dmarmedr,ou=Baja
de cuentas,c=es)" conn=0 op=0
> NOTICE - ldbm_back_search - Internal unindexed search: source
(cn=referential integrity postoperation,cn=plugins,cn=config)
search base="c=es" scope=2 filter="(seeAlso=*uid=dmarmedr,ou=Baja
de cuentas,c=es)" conn=0 op=0
>
> And when it happends the slapd proccess takes up to 100% CPU
usage and we see the message you can see bellow, because this
master node begins to avoid replication sessions from other
master nodes:
>
> ERR - NSMMReplicationPlugin - process_postop - Failed to apply
update (615f51ea0023) error (51). Aborting replication
session(conn=1145 op=4)
>
> All those internal unindexed searchs have filters with the
attributes configured in the referential integrity plugin,
member=*, uniquemember=*, owner=* and seealso=*. Those attributes
has equality and presence indexes, we don't understand why the
log says "internal unindexed search".
>
> Can anyone help me with this problem?, maby is it necessary
other type of index?
>
> Thanks & Regards
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to
389-users-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:

https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to
389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure



--
--

389 Directory Server Development Team

[389-users] Re: ACI with groupdn to target multiple groups

[Ludwig Krispenz]

On 05.02.21 03:33, William Brown wrote:



On 5 Feb 2021, at 12:30, William Brown  wrote:




On 4 Feb 2021, at 22:23, Pierre Rogier  wrote:

Hi Nicolas,

The documentation does not say that wildcard is supported in groupdn evaluation 
and I have not seen anything in the code that handles it.
IMHO The comment about group dn filter is a bit confusing:
the only place it is supported while evaluating groupdn is within the (filter) 
part when using the full ldap url notation (dn??scope?(filter)) but that is not 
really a wildcard but a substring or a presence ldap
filter .
And I do not see how it could be implemented efficiently because
it would mean that either all groups are checked or that
  something similar to the ismemberof plugin is used
(and that is neither scalable nor efficient).
Note: for user dn things are easier because there is a single bind dn   (and we 
can easily check if it matches).





I'm not an English native speaker, so please forgive me if there's
mistakes in this e-mail.

OS : Fedora 30
389ds version / build number : 1.4.1.14 / 2020.023.2226

I'm struggling with ACI and despite hours of documentation reading, I
don't understand how to make it work as I want.

Basic directory structure
==
dc=domain,dc=tld
|
+---ou=Servers
 |
 +---cn=proxy < here is where I add the ACI
 |
 +---cn=group1
 |
 +---cn=group2
===
Container "proxy" is a "iphost" object.


Sorry for the messy email. I rewrote it a few times: This should be clearer.

A way to achieve this is with the memberOf plugin.

You enable memberOf plugin on your system. This means that members Of 
cn=group1,cn=proxy,ou=Servers,dc=domain,dc=tld would have that set into their 
account such as:

dn: uid=william,ou=people,dc=domain,dc=tld
...
memberOf: cn=group1,cn=proxy,ou=Servers,dc=domain,dc=tld


Then you can use:


(targetattr = "*") (target =
"ldap:///cn=proxy,ou=Servers,dc=domain,dc=tld;) (version 3.0;acl
"Allow only groups members to query this object";allow (all)
(userdn = 
"ldap:///ou=People,dc=domain,dc=tld??sub??(memberOf=cn=*,cn=proxy,ou=Servers,dc=domain,dc=tld)")
;)


I haven't tried this my self, but it should work. You'll need to make sure 
there is a substring index on memberOf.


it might work, but enabling memberof, and especially substring index for 
it, could be very costly.


If the groupdn with the ldap url with filter doesn't work, I think 
listing all the groups would be the most efficient method, at the cost 
that maintining the aci becomes a more challenging task.


I think acis with groupdn do handle nested groups, so to keep theaci 
simple, one could create a group, containing all the groups, eg:


cn=acigroup, cn=proxy1, ..

member: cn=g1, cn=proxy1,...

member: cn=g2, cn=proxy1,..



aci:  (groupdn=cn=acigroup, cn=proxy1,...)







—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: ACI with groupdn to target multiple groups

[Ludwig Krispenz]

On 03.02.21 16:23, N R wrote:

Hi everyone,

I'm not an English native speaker, so please forgive me if there's
mistakes in this e-mail.

OS : Fedora 30
389ds version / build number : 1.4.1.14 / 2020.023.2226

I'm struggling with ACI and despite hours of documentation reading, I
don't understand how to make it work as I want.

Basic directory structure
==
dc=domain,dc=tld
|
+---ou=Servers
 |
 +---cn=proxy < here is where I add the ACI
 |
 +---cn=group1
 |
 +---cn=group2
===
Container "proxy" is a "iphost" object.

I'm trying to allow only members of any group inside "cn=proxy" to
access attributes of "cn=proxy".

Relying on redhat directory server documentation, I've tried the
following ACI which didn't worked the way I wanted:
you don't say in which way it did not work, didn't the group members get 
access or was access granted for dns outside the groups, maybe an 
example of a group and a search would be useful. And in a next step you 
should eventually turn on acl logging, which is very verbose, but coul help.

(targetattr = "*") (target =
"ldap:///cn=proxy,ou=Servers,dc=domain,dc=tld;) (version 3.0;acl
"Allow only groups members to query this object";allow (all)(groupdn =
"ldap:///cn=proxy,ou=Servers,dc=domain,dc=tld??sub;);)


did you try to add a filter, like

"ldap:///cn=proxy,ou=Servers,dc=domain,dc=tld??sub?(objectclass=groupofnames");)
 or groupofuniquenames if you define your group with uniquemembers



(targetattr = "*") (target =
"ldap:///cn=proxy,ou=Servers,dc=domain,dc=tld;) (version 3.0;acl
"Allow only groups members to query this object";allow (all)(groupdn =
"ldap:///cn=*,cn=proxy,ou=Servers,dc=domain,dc=tld;);)

this should work if the dn of your groups matches this pattern


I used informations  provided on
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/defining_bind_rules#using_the_groupdn_keyword_with_an_ldap_filter
but I don't understand how to adapt them to my use-case.

The ugly and suboptimal way of solving it would be to list every group
within "cn=proxy" in the ACI, but I'm almost sure there's a better way
to do it.

Thanks in advance for your replies and any possible help.

Cheers,


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: aci doubt

[Ludwig Krispenz]

On 28.09.20 14:56, Alberto Viana wrote:

William,

I don't think thatś the way to do that:

additional info: targetattr "objectclass=person" does not exist in 
schema. Please add attributeTypes "objectclass=person" to schema if 
necessary (Also tried objectclass=*)


what aci did you try ?

what William was saying is that if you use a searchfilter like 
"Objectclass=*" you need an aci that gives the user "search" rights for 
the attribute objectclass, so you would have to extend the targetattr in 
your original aci from


(targetattr="uid || givenName || cn || sn || manager || mail")

to

(targetattr="objectclass || uid || givenName || cn || sn || manager || 
mail")



or create another aci giving only search rigthts for objectclass


Ludwig



This one works:

(targetattr!="userPassword")(targetfilter="(|(objectclass=person)(objectclass=organizationalperson)(objectclass=inetOrgPerson)(objectClass=ntUser)(objectClass=eduPerson)(objectClass=brPerson)(objectClass=schacPersonalCharacteristics)(objectClass=pwmUser)(objectClass=inetuser)(objectClass=ntGroup))")

but I really need to restrict the attributes for this specific group 
of users.


Couldn find a way to do what I want, maybe I'll have to change the filter.

Thanks

Alberto Viana

On Sun, Sep 27, 2020 at 8:49 PM William Brown > wrote:




> On 26 Sep 2020, at 05:43, Alberto Viana mailto:alberto...@gmail.com>> wrote:
>
> Hey Guys,
>
> Is it possible to restrict some users to read,search,compare
just specific attributes but still use objectclass=* as a filter?
>
> My aci:
> aci: (targetattr="uid || givenName || cn || sn || manager ||
mail")(targetfilter="(objectclass=*)")(version 3.0;aci "Access for
app to specific needed attributes";allow (read,compare,search)
groupdn="ldap:///cn=my-group;;)
>
> If I do a ldapsearch with this user (myuser is in the group
my-group):
>
> ldapsearch -b "dc=rnp,dc=local" -W -D "uid=myuser" uid=alberto.viana
>
> Returns me the user alberto.viana and the attributes that acis
allows
>
> but if I do:
>
> ldapsearch -b "dc=rnp,dc=local" -W -D "uid=myuser" objectclass=*
> returns me nothing.

I think you need objectClass in your targetAttr set. if You can't
read the attribute, you can't do a comparison/filter on it.


>
>
> Thanks!!
>
> Alberto Viana
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org

> To unsubscribe send an email to
389-users-le...@lists.fedoraproject.org

> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:

https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-users mailing list -- 389-users@lists.fedoraproject.org

To unsubscribe send an email to
389-users-le...@lists.fedoraproject.org

Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: dbchangelog Question

[Ludwig Krispenz]

Do you really need to change the changelog directory, the changelog has 
a separate path only for historical reasons and in future versions will 
be fully integrated to the database -  so this option will go away.


Regards,

Ludwig

On 08.07.20 18:21, Ghiurea, Isabella wrote:


Morning Gurus

I am running multimaster replication with 
389-ds-base-1.3.7.5-24.el7_5.x86_64, I will like to know if I can 
update  dbchange log path while DS is online accepting transactions 
without


 any implication for replication?

Thank you

Isabella


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: LMDB vs BDB where locks are exhausted

[Ludwig Krispenz]

On 23.06.20 19:19, Mark Reynolds wrote:


On 6/23/20 12:22 PM, David Boreham wrote:


On 6/23/2020 10:07 AM, Mark Reynolds wrote:


In 389 what we are seeing is that our backend txn plugins are doing 
unindexed searches, but I would not call it a bug.


The unindexed search is fine per se (although probably not a great 
idea if you want the op the plugin hooked to complete quickly).


What's not fine is that all the DB reads under that search should be 
done in the same transaction with strong isolation.


First I'm not that intimately familiar with this issue, Thierry and 
Ludwig did most of that investigation.  But this happens during a 
modify operation that triggers some BE txn plugins that do searches 
and updates under the same parent transaction.  So under these 
conditions is when it just starts consuming a ton of db locks.
If a transactional operation (eg modify) triggers a search by a plugin 
it already holds a coupke of page locks as write locks. If the search 
would try to access this pages without using the txn of the parent it 
would have to wait - and the whole operation would self deadlock. So all 
db accesses inside a txn need to use this txn directly or as a paent txn.


Unindexed searches by themselves do not cause this issue, it's when we 
are updating the database under the same txn.  So the mod takes a lock 
on a db page, then we call the be postop plugins, which in turn starts 
doing these expensive searches and updates - that is when the db lock 
issue pops up.  I seem to recall from previous similar cases that this 
"mod update" involved a very large static group, and the RI or 
memberOf plugin doing its work. Maybe Thierry recalls some of the past 
cases?




It's really a configuration/indexing issue.  But yes, there are long 
running operations/txns in regards to many plugins doing a lot of 
things while the database is being updated in the same nested 
operation.  Now when these internal searches are properly indexed 
the db lock issue completely goes away.


If missing an index were to result in poor performance, agreed -- 
it's a configuration issue. The server process exiting seems quite an 
extreme consequence.
It's not exactly crashing, but the db can get corrupted and it needs 
to be reinitialized.  That sounds like a libdb bug to me :-) Running 
out of db locks should not corrupt the database.



Wondering if this is the result of an old fix for a deadlock problem 
(bringing the internal op under the main transaction to cure the 
deadlock)?

Maybe :-)  Haven't looked at that code in quite a few years...


How is a regular (non-internal) unindexed search run? Surely that 
doesn't burn through one lock per page touched?


No it doesn't.  See my comment above, standalone unindexed searches do 
not trigger this issue.


Mark



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: urp_fixup_add_cenotaph errors

[Ludwig Krispenz]

On 09/10/2019 02:37 AM, William Brown wrote:



On 10 Sep 2019, at 09:58, Morgan, Iain (ARC-TN)[InuTeq, LLC] 
 wrote:



On 9/8/19, 15:40, "William Brown"  wrote:




On 7 Sep 2019, at 08:33, Morgan, Iain (ARC-TN)[InuTeq, LLC] 
 wrote:

Hello Marc,

Yes, it is 389-ds-base1.3.9.1-10.el7, but we are not using IPA and there are no 
memberOf plugin errors. The actual modrdn operations have error=0.

If we may, can we ask what the modrdn operations were, and to ask a little 
about your tree layout so we could try to understand more about this?


Sure, there's nothing unusual regarding the tree layout. There's a single 
backend with ou=People, and ou=Groups, One thing that may be relevant 
is that this is a stand-alone server -- replication has not been configured.

Have you configured the replica id, replication agreement or changelog though? 
I want to follow up with our replication expert about why URP is getting 
involved here, when you say replication isn't configured.
if this is really a standalone consumer without replication configured, 
this is probably a consequence of splitting the multimaster(mmr) and the 
other plugin calls and the mmr plugin could be called and do nothing, 
just try :-(

so the messages is harmless although annoying and we should fix it.



 From the access log:

[09/Sep/2019:15:05:08.577399600 -0700] conn=2233897 op=2 SRCH 
base="ou=Groups,dc=nas,dc=nasa,dc=gov" scope=2 filter="(|(cn=temp)(cn=testgroup))" 
attrs="cn"
[09/Sep/2019:15:05:08.577630700 -0700] conn=2233897 op=2 RESULT err=0 tag=101 
nentries=1 etime=0.323261
[09/Sep/2019:15:05:08.578316196 -0700] conn=2233897 op=3 MODRDN 
dn="cn=temp,ou=Groups,dc=nas,dc=nasa,dc=gov" newrdn="cn=testgroup" 
newsuperior="(null)"
[09/Sep/2019:15:05:08.581595207 -0700] conn=2233897 op=3 RESULT err=0 tag=109 
nentries=0 etime=0.0003326527

 From the errors log:

[09/Sep/2019:15:05:08.580235717 -0700] - ERR - conn=2233897 op=3 - 
urp_fixup_add_cenotaph - failed to add cenotaph, err= 21

I think you can ignore this - with no replication cenotaphs not being added is 
not an issue. If you were in a replication topology this would be a more 
significant error. Cenotaphs are needed to resolve some replication edge cases 
in update resolution and are an internal part of our replication system. But as 
mentioned, I will follow up why URP is being accessed here, so I need some more 
information from you.

Thanks, hope this helps,




--
Iain Morgan

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: urp_fixup_add_cenotaph errors

[Ludwig Krispenz]

Is this a reeadonly consumer ? we had

https://pagure.io/389-ds-base/issue/50078

It was fixed, but I am not sure into what versions it was included

On 09/06/2019 07:29 PM, Morgan, Iain (ARC-TN)[InuTeq, LLC] wrote:


On 9/5/19, 18:11, "Iain Morgan"  wrote:

 Hello,
 
 While testing 389-ds 1.3.9.1 on RHEL 7.7, I noticed the the errors

 listed below. The actual LDAP operations all succeed, but I find the
 errors disconcerting.
 
 
 [28/Aug/2019:10:42:13.446609256 -0700] - ERR - conn=44 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21

 [28/Aug/2019:10:42:14.202854398 -0700] - ERR - conn=52 op=5 - 
urp_fixup_add_cenotaph - failed to add cenotaph, err= 21
 [28/Aug/2019:10:42:18.504412946 -0700] - ERR - conn=95 op=3 - 
urp_fixup_add_cenotaph - failed to add cenotaph, err= 21
 [28/Aug/2019:10:42:24.412896470 -0700] - ERR - conn=160 op=8 - 
urp_fixup_add_cenotaph - failed to add cenotaph, err= 21
 
These all appear to be related to modrdn operations.




--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: Windows Sync Agreement issue

[Ludwig Krispenz]

On 09/04/2019 08:21 AM, DaV wrote:

Hi William,
I set nsslapd-errorlog-level to 8192 and see one line:
[04/Sep/2019:14:15:00.264779375 +0800] - DEBUG - NSMMReplicationPlugin 
- windows sync - windows_inc_run - agmt="cn=ou1" (win2k16dc:389): 
State: wait_for_window_to_open -> wait_for_window_to_open
the window is the window of time configured in 
nsDS5ReplicaUpdateSchedule and you said you have "1200-1210 4" which 
means it will only open on thursday for 10 miutes


So I will check why win2k16 can't open.

BTW, I have many windows sync agreements, but I only see one agmt 
debug log.


Sincerely,
--
DaV

On Thu, Aug 29, 2019, at 07:23, William Brown wrote:
>
>
> > On 27 Aug 2019, at 11:25, DaV  wrote:
> >
> > OK.
> > 1.  I have win2016 AD  and 389ds 1.3.8.4 on CentOS 7.6
> > 2. the data flow is from AD to 389ds, I don't want any data from 
389ds to AD

>
> Great, this helps a lot.
>
> > 3.  The time interval  sync from 389ds to AD controlled by   
nsDS5ReplicaUpdateSchedule. This is why I set it  as 1200-1210 4 
(actually I want to disable it at all)

>
> Because replication is push based, you can just disable or remove the
> agreements. Only the AD supplier needs agreements to connect to the
> 389-ds side. Saying this Mark is more experienced here and may have
> better insight as to what you should do here ...
>
> > 4. The time interval sync from AD to 389ds controlled by 
WinSyncInterval, it's 5 minutes default. But I can't find any error 
log on my 389ds server,  the sync doesn't happen.

>
> You may need to enable replication logging (I think it's errorlog level
> 8192). This will show you the incoming replication events.
>
> >
> > Sincerely,
> > --
> > DaV
> >
> > On Tue, Aug 27, 2019, at 08:54, William Brown wrote:
> >>
> >>
> >>> On 27 Aug 2019, at 10:44, DaV  wrote:
> >>>
> >>> Thanks for your reply.
> >>> This is my configuration on 389ds server.
> >>> Please tell me if the attribute of "oneWaySync: fromWindows" is 
correct.

> >>>
> >>> Now, the new users in AD can't be synced to 389ds every 5 
minutes, I have to click "Initiate full Re-synchronized" manually. I'm 
stuck for days.

> >>
> >> I think they are *not* syncing because your schedule is:
> >>
> 
>  nsDS5ReplicaUpdateSchedule: 1200-1210 4
> 
>  nsDS5ReplicaUpdateSchedule: 1211-1220 4
> 
> >>
> >> This translates to "between 12:00 and 12:10 on thursday" and 
"between

> >> 12:11 and 12:20 on thursday.".
> >>
> >> IE you are syncing for a 10 minute window once a week, rather than
> >> every five minutes all the time.
> >>
> >> You probably want something more like:
> >>
> >> nsDS5ReplicaUpdateSchedule : -2359 0123456
> >>
> >> If you want to sync all the time.
> >>
> >> I think I'm a bit confused about the "bigger picture" of what you 
are

> >> trying to achieve here. Can you please describe:
> >>
> >> * Your servers (AD, ldap etc)
> >> * How you want the data to flow
> >> * When you want the data to flow
> >>
> >> Just describe, we don't need to see configs. I think that is really
> >> going to help us think through answers to your questions.
> >>
> >>
> >>
> >>>
> >>> Sincerely,
> >>> --
> >>> DaV
> >>>
> >>>
> >>>
> >>>
> >>> On Tue, Aug 27, 2019, at 02:18, Mark Reynolds wrote:
> 
> 
>  On 8/23/19 5:38 AM, DaV wrote:
> > Hi all,
> > For OneWaySync, AD to 389ds.
> >
> > I have read this guide
> > 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/using_windows_sync-modifying_the_sync_agreement

> >
> >> Synchronization works two ways. The Directory Server sends 
its updates to Active Directory on a configurable schedule, similar to 
replication, using the nsds5replicaupdatescheduleattribute. The 
Directory Server polls the Active Directory to check for changes; the 
frequency that it checks the Active Directory server is set in the 
winSyncInterval attribute.
> >> By default, the Directory Server update schedule is to always 
be in sync. The Active Directory interval is to poll the Active 
Directory every five minutes.
> >> To change the schedule the Directory Server uses to send its 
updates to the Active Directory, edit the nsds5replicaupdateschedule 
attribute. The schedule is set with start () and end () times 
in the form HHMM, using a 24-hour clock. The days to schedule sync 
updates are use ranging from 0 (Sunday) to 6 (Saturday).

> >
> > I want to know how to disable the nsds5replicaupdateschedule 
attribute. Because I just want sync from AD to 389ds.
>  
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/core_server_configuration_reference#Replication_Attributes_under_cnReplicationAgreementName_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5ReplicaUpdateSchedule

> 
>  You can set it to "-0001 0" to disable synchronizing 
according to the link above

> 
> 
> 
> > Thanks in advance!
> 

[389-users] Re: Question on EQUALITY on index and schema definition

[Ludwig Krispenz]

On 08/05/2019 03:05 PM, Mark Reynolds wrote:



On 8/5/19 8:57 AM, Mark Reynolds wrote:



On 8/4/19 9:55 AM, Lutz Berger wrote:

Hello,

I've come across a web site
that claims that an "equality index" is only allowed for attributes
that have "EQUALITY" in their description, "otherwise terrible things
will happen".

For example
>> *attributeTypes: ( 1.3.6.1.4.1.13299.2.3.7.xxx NAME 'abCLZ'  
EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE X-ORIGIN 'user defined' )**

*
For the sake of correctness, I've tried to build an equality-index 
for an attribute missing such description, e.g.


*>> attributeTypes: ( 1.3.6.1.4.1.13299.2.3.7.xyz NAME 'abID'  
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user 
defined' )*


So what is happening is that the first example has a "matching rule" 
defined:   EQUALITY caseIgnoreMatch.  If you define such an attribute 
with this syntax you MUST have an equality index for that attribute.  
Otherwise the server has to manually perform this matching - which is 
VERY expensive. Hence why you see an etime of 26 seconds.  Once its 
indexed for equality the matching rule can efficiently be processed.


Sorry this is actually incorrect.  The matching rule is not the 
problem in the case, since you are not using the matching rule in the 
search filter.   See 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/finding_directory_entries-ldap_search_filters#using-matching-rules 
   So this is just an issue of basic indexing.  You are doing an 
equality search, so you need an equality index, otherwise the server 
has to sequentially scan the database for matching entries.


and regarding  the question of defining the matching rule in the schema 
I think there is a default matching rule used for the syntax



Regards,

Mark

But you do not NEED to use this matching rule: EQUALITY 
caseIgnoreMatch, unless you have a requirement for it.  But you 
should always index your attribute for how you plan to use it.  In 
this case you are doing an equality search: = 
so you would want an equality index (regardless of the presence of a 
matching rule).


HTH,

Mark



*Withour EQ-Index:*
[root@ur1 slapd-ur1devims]# fgrep "conn=34" access
[03/Aug/2019:14:21:00 +0200] conn=34 fd=65 slot=65 connection from 
192.168.69.152 to 192.168.69.152
[03/Aug/2019:14:21:00 +0200] conn=34 op=0 BIND dn="cn=Directory 
Manager" method=128 version=3
[03/Aug/2019:14:21:00 +0200] conn=34 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[03/Aug/2019:14:21:00 +0200] conn=34 op=1 SRCH 
base="ou=users,c=de,o=creditreform" scope=2 
filter="(abID=7022544)" attrs=ALL
*[03/Aug/2019:14:21:26 +0200] conn=34 op=1 RESULT err=0 tag=101 
nentries=1 etime=26 notes=A*

[03/Aug/2019:14:21:26 +0200] conn=34 op=2 UNBIND
[03/Aug/2019:14:21:26 +0200] conn=34 op=2 fd=65 closed - U1
[root@ur1 slapd-ur1devims]#

*With EQ-Index:*
[root@ur1 slapd-ur1devims]# fgrep "conn=35" access
[03/Aug/2019:14:24:18 +0200] conn=35 fd=65 slot=65 connection from 
192.168.69.152 to 192.168.69.152
[03/Aug/2019:14:24:18 +0200] conn=35 op=0 BIND dn="cn=Directory 
Manager" method=128 version=3
[03/Aug/2019:14:24:18 +0200] conn=35 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[03/Aug/2019:14:24:18 +0200] conn=35 op=1 SRCH 
base="ou=users,c=de,o=creditreform" scope=2 
filter="(abID=7022544)" attrs=ALL
*[03/Aug/2019:14:24:18 +0200] conn=35 op=1 RESULT err=0 tag=101 
nentries=1 etime=0*

[03/Aug/2019:14:24:18 +0200] conn=35 op=2 UNBIND
[03/Aug/2019:14:24:18 +0200] conn=35 op=2 fd=65 closed - U1

*My question is now, is the EQUALITY part of the schema description 
really necessary**
**for building equality-indexes on attributes, since I couldn't 
reproduce any**obvious

problem.*

From the access pattern I see in the access log, building such an 
index is

definitely beneficial in sense of performance.

Thanks for your efforts!

Best regards,
  Lutz


--
Dipl.-Inform. Univ. Lutz Berger
Email: lutz.ber...@multigrid.de

Multigrid-Logo 

___
389-users mailing list --389-users@lists.fedoraproject.org
To unsubscribe send an email to389-users-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

--

389 Directory Server Development Team

___
389-users mailing list --389-users@lists.fedoraproject.org
To unsubscribe send an email to389-users-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 

[389-users] Re: Question on EQUALITY on index and schema definition

[Ludwig Krispenz]

Hallo Lutz,

bist Du's :-)

Servus,
Ludwig

On 08/04/2019 03:55 PM, Lutz Berger wrote:

Hello,

I've come across a web site
that claims that an "equality index" is only allowed for attributes
that have "EQUALITY" in their description, "otherwise terrible things
will happen".

For example
>> *attributeTypes: ( 1.3.6.1.4.1.13299.2.3.7.xxx NAME 'abCLZ'  
EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE X-ORIGIN 'user defined' )**

*
For the sake of correctness, I've tried to build an equality-index for 
an attribute missing such description, e.g.


*>> attributeTypes: ( 1.3.6.1.4.1.13299.2.3.7.xyz NAME 'abID'  SYNTAX 
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )*



*Withour EQ-Index:*
[root@ur1 slapd-ur1devims]# fgrep "conn=34" access
[03/Aug/2019:14:21:00 +0200] conn=34 fd=65 slot=65 connection from 
192.168.69.152 to 192.168.69.152
[03/Aug/2019:14:21:00 +0200] conn=34 op=0 BIND dn="cn=Directory 
Manager" method=128 version=3
[03/Aug/2019:14:21:00 +0200] conn=34 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[03/Aug/2019:14:21:00 +0200] conn=34 op=1 SRCH 
base="ou=users,c=de,o=creditreform" scope=2 
filter="(abID=7022544)" attrs=ALL
*[03/Aug/2019:14:21:26 +0200] conn=34 op=1 RESULT err=0 tag=101 
nentries=1 etime=26 notes=A*

[03/Aug/2019:14:21:26 +0200] conn=34 op=2 UNBIND
[03/Aug/2019:14:21:26 +0200] conn=34 op=2 fd=65 closed - U1
[root@ur1 slapd-ur1devims]#

*With EQ-Index:*
[root@ur1 slapd-ur1devims]# fgrep "conn=35" access
[03/Aug/2019:14:24:18 +0200] conn=35 fd=65 slot=65 connection from 
192.168.69.152 to 192.168.69.152
[03/Aug/2019:14:24:18 +0200] conn=35 op=0 BIND dn="cn=Directory 
Manager" method=128 version=3
[03/Aug/2019:14:24:18 +0200] conn=35 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="cn=directory manager"
[03/Aug/2019:14:24:18 +0200] conn=35 op=1 SRCH 
base="ou=users,c=de,o=creditreform" scope=2 
filter="(abID=7022544)" attrs=ALL
*[03/Aug/2019:14:24:18 +0200] conn=35 op=1 RESULT err=0 tag=101 
nentries=1 etime=0*

[03/Aug/2019:14:24:18 +0200] conn=35 op=2 UNBIND
[03/Aug/2019:14:24:18 +0200] conn=35 op=2 fd=65 closed - U1

*My question is now, is the EQUALITY part of the schema description 
really necessary**
**for building equality-indexes on attributes, since I couldn't 
reproduce any**obvious

problem.*

From the access pattern I see in the access log, building such an index is
definitely beneficial in sense of performance.

Thanks for your efforts!

Best regards,
  Lutz


--
Dipl.-Inform. Univ. Lutz Berger
Email: lutz.ber...@multigrid.de

Multigrid-Logo 


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: Replicate 389DS with another LDAP server

[Ludwig Krispenz]

On 02/20/2019 03:24 PM, Howard Chu wrote:

Mark Reynolds wrote:

On 2/20/19 5:59 AM, Howard Chu wrote:

Date: Tue, 19 Feb 2019 13:50:11 +0100
From: wodel youchi 

Hi,

is it possible to create a replication matser/master or master/slave
between 389DS and another LDAP server openldap for example?

Regards.

Maybe. OpenLDAP has recently added support for replication using a retro 
changelog.
It has only been tested against Sun/Oracle DSEE so far

389's retro changelog should be the same as DSEE, so this would be an option.  
Howard, does this new replication feature in OpenLDAP work in both directions?

Not at the moment. It only allows OpenLDAP to replicate from DSEE. It probably 
wouldn't be
difficult to write an overlay to generate a compatible changelog, for going the 
other
direction.
390ds also impelments SyncRepl as a plugin, so this could also be an 
option to try, but it would still provide only the direction 389ds 
-->openldap.
For the other direction 389ds would have to offer some "pull 
replication" feature, which doesn't exist.
A further problem would be in synchronizing updates from several 
sources, 389ds uses CSNs and RUVs, openldap also has CSN, which are a 
similar concept, but not directly compatible.

So, even if there are approaches to do it, I think we are not there.


The commit is here, includes the code and a test script that sets up the DS and
polls it for changes. We'll probably add persistent search on top of this soon 
as well.

http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=e8c62bf8b478411ca162ef4928904ca85738a600


but it may also work with
389DS/RHDS, and if it doesn't work at the moment it probably wouldn't take much 
to
make it work. I haven't examined the 389DS schema to see how closely it matches 
DSEE yet.




--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: Limiting access to same ou

[Ludwig Krispenz]

On 11/29/2018 12:12 PM, Alistair Cunningham wrote:
On 29/11/2018 20:12, Ludwig Krispenz wrote:> On 11/29/2018 12:32 AM, 
Alistair Cunningham wrote:
Is there a neat way to replace the ACL below that needs to be added 
once for each ou with one single ACL that works for every ou? 
Perhaps some way of saying that the "ou=2,dc=example,dc=com" in the 
target part must match the same string in the userdn part?


aci: (target="ldap:///ou=2,dc=example,dc=com;)(targetattr=*)(version 
3.0;acl "aci2";allow (read,search) 
userdn="ldap:///cn=*,ou=2,dc=example,dc=com;;)

you should look into Macro ACIs, cahp 18.16
soemthing like:
aci: 
(target="ldap:///*($dn*),dc=example,dc=com")(targetattr=*)(version 
3.0;acl "aci2";allow (read,search) 
userdn="ldap:///cn=*,*($dn)*,dc=example,dc=com";


or maybe [$dn] in the userdn to be able to target subentries.

Now it is  question if you should use this. If your tree is very 
dynamic and you add or remove subtrees and don't want to change the 
acis each time macro acis are the right approach, but if you have a 
few subtrees which are stable, macroacis can be a bit of overhead in 
evaluating and adding indiuvidual acis is only a bit tedious in the 
beginning


The tree design will be simple and stable, with one ou for each tenant 
directly under the base. However, there may be a very large number of 
them - potentially hundreds of thousands. Would you recommend Macro 
ACIs in this case?

yes, if they work for you.

There is always two phases in aci evaluation:
1] find all the acis applying to the target, this is negatively impacted 
by a high number of acis and the complexity, eg macros or wildcards, 
targetfilterss 
2] applying the aci, which means evaluating the bind rules, also 
negatively affected by complexity, eg macros, targetattrs,.. and/or 
clauses 


In your case I think it is more efficient to match and apply one macro 
aci than finding the one simple aci in thousands of acis



--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: Limiting access to same ou

[Ludwig Krispenz]

On 11/29/2018 12:32 AM, Alistair Cunningham wrote:

Thank you, it's now working correctly! We don't need anonymous access.

Is there a neat way to replace the ACL below that needs to be added 
once for each ou with one single ACL that works for every ou? Perhaps 
some way of saying that the "ou=2,dc=example,dc=com" in the target 
part must match the same string in the userdn part?


aci: (target="ldap:///ou=2,dc=example,dc=com;)(targetattr=*)(version 
3.0;acl "aci2";allow (read,search) 
userdn="ldap:///cn=*,ou=2,dc=example,dc=com;;)

you should look into Macro ACIs, cahp 18.16
soemthing like:
aci: (target="ldap:///*($dn*),dc=example,dc=com")(targetattr=*)(version 
3.0;acl "aci2";allow (read,search) 
userdn="ldap:///cn=*,*($dn)*,dc=example,dc=com";


or maybe [$dn] in the userdn to be able to target subentries.

Now it is  question if you should use this. If your tree is very dynamic 
and you add or remove subtrees and don't want to change the acis each 
time macro acis are the right approach, but if you have a few subtrees 
which are stable, macroacis can be a bit of overhead in evaluating and 
adding indiuvidual acis is only a bit tedious in the beginning




On 29/11/2018 03:54, Mark Reynolds wrote:


On 11/27/18 8:15 PM, Alistair Cunningham wrote:

On 28/11/2018 12:08, Mark Reynolds wrote:

On 11/27/18 7:24 PM, Alistair Cunningham wrote:
I've added these acis, but a telephone (with objectClass 'person') 
in tenant1 can still see people (with objectClass 'inetOrgPerson') 
in tenant2. Presumably there needs to also be a blanket aci to 
forbid all telephones from viewing other tenants, that these 
tenant-specific allow acis then override?


There might be an aci that is allowing anonymous access to basic 
entries.  By default if there are no ACI's then access is 
completely blocked except for Directory Manager.  So some aci is 
allowing access. We need to see all the ACI's you have:


For example, this would list all the aci's under dc=example,dc=com:

# ldapsearch -D "cn=directory manager" -W -b "dc=example,dc=com" 
aci=* aci


I suspect there is an aci with a userdn that equals "anyone", but 
we'll see...


There is indeed. Shall I delete it?
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable 
anonymous ac

  cess"; allow (read, search, compare) userdn="ldap:///anyone;;)

That depends.  Do you have any clients that expect to have anonymous 
access to entries?  Removing this aci will block everyone from access 
to the database - then you need to add aci's to open up access to the 
users/groups of your choosing.


So to accomplish what you want in this email then yes delete it, but 
it could break clients that be expecting anonymous access to be 
allowed. So be careful :-)




$ ldapsearch -x -D "cn=Directory Manager" -w secret -b 
"dc=integrics,dc=com" "aci=*" aci

# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: aci=*
# requesting: aci
#

# integrics.com
dn: dc=integrics,dc=com
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable 
anonymous ac

 cess"; allow (read, search, compare) userdn="ldap:///anyone;;)
aci: (targetattr="carLicense || description || displayName || 
facsimileTelepho
 neNumber || homePhone || homePostalAddress || initials || jpegPhoto 
|| labele
 dURI || mail || mobile || pager || photo || postOfficeBox || 
postalAddress ||
  postalCode || preferredDeliveryMethod || preferredLanguage || 
registeredAddr
 ess || roomNumber || secretary || seeAlso || st || street || 
telephoneNumber
 || telexNumber || title || userCertificate || userPassword || 
userSMIMECertif
 icate || x500UniqueIdentifier")(version 3.0; acl "Enable self write 
for commo

 n attributes"; allow (write) userdn="ldap:///self;;)
aci: (targetattr ="*")(version 3.0;acl "Directory Administrators 
Group";allow
 (all) (groupdn = "ldap:///cn=Directory Administrators, 
dc=integrics,dc=com");

 )

# 2, integrics.com
dn: ou=2,dc=integrics,dc=com
aci: 
(target="ldap:///ou=2,dc=integrics,dc=com;)(targetattr=*)(version 
3.0;acl
  "aci2";allow (read,search) 
userdn="ldap:///uid=*,ou=2,dc=integrics,dc=com;;)


# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org 





--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: deref interop question

[Ludwig Krispenz]

The easiest way to find out is just to try it :-)

ldapsearch -LLL -o ldif-wrap=no -h localhost  -p 38901 -x -D 
"cn=directory manager"  -w ... -b "dc=example,dc=com" uid=kwinters 
objectclass description uid

dn: uid=kwinters,ou=People,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: kwinters

ldapsearch -LLL -o ldif-wrap=no -h localhost  -p 38901 -x -D 
"cn=directory manager"  -w ... -b "dc=example,dc=com" uid=trigden 
objectclass description uid

dn: uid=trigden,ou=People,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
description: used for deref
uid: trigden

dn: cn=PD Managers,ou=Groups,dc=example,dc=com
ldapsearch -LLL -o ldif-wrap=no -h localhost  -p 38901 -x -D 
"cn=directory manager"  -w ... -b "dc=example,dc=com" -E 
'deref=uniquemember:objectClass,description,uid' 'cn=PD Managers'
# uniquemember: 
;uid=kwinters,ou=People,dc=example,dc=com


# uniquemember: 
for deref>;;uid=trigden,ou=People,dc=example,dc=com


objectClass: top
objectClass: groupOfUniqueNames
cn: PD Managers
ou: groups
uniqueMember: uid=kwinters,ou=People,dc=example,dc=com
uniqueMember: uid=trigden,ou=People,dc=example,dc=com
description: People who can manage engineer entries


So the answer is, if an attribute, like description in the example does 
not exist in the derefed entry it is just not there, like in a normal 
search where it was requested. In addition 389-ds also checks if the 
user requesting the deref attrs also has access rights to the attr in 
the derefed entry


Ludwig



On 11/08/2018 12:25 AM, William Brown wrote:

On Thu, 2018-11-08 at 00:12 +0100, Michael Ströder wrote:

On 11/7/18 11:22 PM, William Brown wrote:

On Sat, 2018-11-03 at 21:46 +0100, Michael Ströder wrote:

I vaguely remember that 389-DS also implements deref search
control
[1].

My question as a client developer:
How does 389-DS deal with reference attributes being absent?

I am assuming that you mean a request for dereference where no
attributeList is requested?

No, I meant the attributes holding the reference are not present in
the
entry.

To be clear that I understand the problem, can you send an example case
of what is occuring? Thanks,


Off the top of my head, I do not know, but
this is something we should check to see if our behaviour is
correct
according to the provided RFC. Reading the RFC it doesn't seem to
specify how an empty attributeList should be handled, but in my
view,
it should "do nothing" since no attributes were requested.

The I-D does not say much about error conditions.

But I also think if anything's missing the server should simply
return
what's present and can be returned but not error out.


[1] https://tools.ietf.org/html/draft-masarati-ldap-deref-00

Ciao, Michael.


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: error moving an user

[Ludwig Krispenz]

On 10/04/2018 10:20 PM, Kreuzenstein, Luke (OIT) wrote:

Thank you very much Ludwig,

Disabling referential integrity would not be an attractive workaround 
in this implementation so I'm grateful for any assistance and happy to 
help all I can. 

I understand and we should make it work.

As far as I see we have three potential issues here.
Issue 1) the modrdn operation fails with err=1 and the message indicates 
that it is the result of a failing plugin, and based on Alberto's 
findings it is the referential integrity plugin. But we do not know why 
it is failing. You grepped for modrdn in the errors log, is there more 
logging which could give a hint ? Otherwise we need to find a pattern 
which modrdns are failing and which are not, maybe also considering the 
context when they fail (eg you said some are failing after one day) so 
that we finally will be able to reproduce this reliably.


The modrdn operation and all the plugin operation triggered by it are 
processed inside one transaction and if something fails the 
operation/transaction is aborted and the state of the database should be 
and should be seen as before the transaction started, but looks like it 
is not the case, which leads to


Issue 2) after a failed modrdn ldapsearches can return incorrect 
results. I can somehow reproduce this by enforcing the failure in gdb 
and have opened this ticket to fix it: 
https://pagure.io/389-ds-base/issue/49967
The core problem of this issue that we have an entry cache which is not 
properly cleared after the transaction abort, the cache operations are 
not transacted. But this is a transient issue and after cache reload (eg 
triggered by a restart) everything is consistent again.


This seems not to be the case for
Issue 3) "Restart does not resolve the residual incorrect uniqueMember 
values in groups."
I did not expect this and it would be great if you could provide some 
data to show the effect.


Thanks for your patience,
Ludwig

PS I will be on vacation next week, so I hope someone else will look 
into it as well

Responses are in-line below.

Ludwig Krispenz wrote on 10/4/2018 12:23 AM:

Hi Alberto, Luke,

thanks for reporting the issue and tracking it down to the 
referential integrity plugin.


I am investigating another issue where after a failing modrdn with 
err=1 there is an entry cache corruption, but was failing to 
reproduce locally.
In a quick try with the referential integrity plugin enabled and 
moving a user to another subtree everything worked for me.


So could you give me some more information.
- did  the failure occur consistently or randomly, did a restart help 
(ruling out entry cache issues)
The failure is random. Restart resolves some instances of dn-uid 
mismatch, but not every instance. There are some differences in the 
logged errors which might be related. Restart does not resolve the 
residual incorrect uniqueMember values in groups.

- did it fail for all modrdns or only specific users
Only some users, but I have been able to reproduce errors by creating 
test users and not trying to rename them until the following day or 
later. This led me to suspect a possible relationship to periodic 
scripted tasks (such as group membership management) but I have not 
been able to confirm any such relationship.
- could you provide the referential integrity configuration from the 
dse.ldif

dn: cn=referential integrity postoperation,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
cn: referential integrity postoperation
nsslapd-pluginPath: libreferint-plugin
nsslapd-pluginInitfunc: referint_postop_init
nsslapd-pluginType: betxnpostoperation
nsslapd-pluginEnabled: on
nsslapd-pluginprecedence: 40
referint-update-delay: 0
referint-logfile: /var/log/dirsrv/slapd-dirmaster/referint
referint-logchanges: 0
referint-membership-attr: member
referint-membership-attr: uniquemember
referint-membership-attr: owner
referint-membership-attr: seeAlso
nsslapd-plugin-depends-on-type: database
nsslapd-pluginId: referint
nsslapd-pluginVersion: 1.3.7.5
nsslapd-pluginVendor: 389 Project
nsslapd-pluginDescription: referential integrity plugin
modifiersName: cn=directory manager
modifyTimestamp: 20180321162105Z

- and some information on the user group structure of the failing 
users/groups
Our DIT is fairly flat, as is evident from the DNs in the excerpts 
below. The specific group in this example is our largest at about 
11000 members, but not all of the affected entries have been members 
of this group.


*Audit log excerpts:*

time: 2018092519
dn: uid=lktestA,ou=People,o=state.ak.us
result: 0
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: soaOrgPerson
objectClass: inetLocalMailRecipient
stellentusertype: Internal
sn: lktestA
cn: lktestA
ou: Administration
l: Anchorage
uid: lktestA
creatorsName: uid=lk*,ou=people,o=state.ak.us
modifiersName: uid=lk*,o

[389-users] Re: error moving an user

[Ludwig Krispenz]

Hi Alberto, Luke,

thanks for reporting the issue and tracking it down to the referential 
integrity plugin.


I am investigating another issue where after a failing modrdn with err=1 
there is an entry cache corruption, but was failing to reproduce locally.
In a quick try with the referential integrity plugin enabled and moving 
a user to another subtree everything worked for me.


So could you give me some more information.
- did  the failure occur consistently or randomly, did a restart help 
(ruling out entry cache issues)

- did it fail for all modrdns or only specific users
- could you provide the referential integrity configuration from the 
dse.ldif
- and some information on the user group structure of the failing 
users/groups


Thanks,
Ludwig

On 10/02/2018 03:41 PM, Alberto Viana wrote:
I had to disable this plugin to solve the problem (workaround) in my 
master.


My first guess to solve the problem is:

Delete my agreements, my replication DB, and re-create everything, and 
after that try to enable the plugin again. But I couldn't do it so 
far...I will later in this month.


On Fri, Sep 28, 2018 at 4:00 PM Kreuzenstein, Luke (OIT) 
mailto:luke.kreuzenst...@alaska.gov>> 
wrote:


 >>> From: "Alberto Viana" mailto:alberto...@gmail.com>>
 >>> To: "General discussion list for the 389 Directory server
project."
<389-users@lists.fedoraproject.org
>
 >>> Sent: Tuesday, March 20, 2018 6:15:46 PM
 >>> Subject: [389-users] error moving an user
 >>>
 >>> Hey Guys,
 >>>
 >>> 389 version: 389-Directory/1.3.7.4
.20170912git26a9426 B2017.255.1330
 >>>
 >>> I'm trying to move one of my users to another OU and I see
this kind of
 >>> error:
 >>>
 >>> Error while moving entry
 >>> - [LDAP: error code 1 - Operations Error]
 >>> java.lang.Exception: [LDAP: error code 1 - Operations Error]
 >>> at
 >>>
 >>>
 >>> In the log I see:
 >>>
 >>> [20/Mar/2018:14:12:27.172553808 -0300] - ERR - ldbm_back_modrdn -
 >>> SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN plugin returned error but did
not set
 >>> SLAPI_RESULT_CODE
 >>>
 >>> I thought that was related to my windows replication, but I
disabled it and
 >>> I'm still getting the error.
 >>>
 >>> Any clues?
 >>>
 >>> ___
 >>> 389-users mailing list -- 389-users@lists.fedoraproject.org

 >>> To unsubscribe send an email to
389-users-le...@lists.fedoraproject.org

 >>>

On Wed, Mar 21, 2018 at 12:00 PM, Simon Pichugin
mailto:spich...@redhat.com>>
wrote:

 >>Hi,
 >>could you please enable 16385 errorlog-level (16384
defaults and
1 trace) just before the operation and send us the
/var/log/dirsrv/slapd-INSTNAME/errors:
 >>
 >>ldapmodify -h localhost -p 389 -D "cn=Directory manager" -w
password << EOF
 >>dn: cn=config
 >>changetype: modify
 >>replace: nsslapd-errorlog-level
 >>nsslapd-errorlog-level: 16385
 >>EOF
 >>
 >>Thanks,
 >>Simon

Alberto Viana wrote on 3/23/2018 8:08 AM:
 > Simon,
 >
 > I was able to reproduce the problem in a new fresh install (I just
imported my database), and It's related to "Referential Integrity
Postoperation Plugin" that I use in my environment. When I disable
it,
the moving works just fine.
 >
 > I have a single master, replication to one AD.
 >
 > I changed the log level, but it's really hard to find the root
cause.
 >
 > Do you want to take a look on it?
 >
 >
 > Once it has some info about my tree, I'd prefer to send the
link to
download the file directly to you.
 >
 > Thanks.

Was this issue ever resolved?  I'm experiencing the same symptom
intermittently in a production environment but haven't managed to
reproduce it in my test environment. The DN gets updated but the uid
(naming attribute) does not. Restarting slapd has helped in one
instance
(to apparently fix a corrupted entry) but not every instance.

[27/Sep/2018:11:29:31.994645991 -0800] - ERR - ldbm_back_modrdn -
SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN plugin returned error but did
not set
SLAPI_RESULT_CODE

It's a single master configuration with two consumer replicas and
about
37000 entries.
The Referential Integrity Postoperation Plugin is enabled on the
master
only.

using:
 > rpm -qa | grep 389-ds-base
389-ds-base-1.3.7.5-25.el7_5.x86_64
389-ds-base-libs-1.3.7.5-25.el7_5.x86_64
 > uname -a
Linux 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14
21:49:04 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux

[389-users] Re: Attempting to make memberUID searches case insensitive

[Ludwig Krispenz]

yes, the index was created, but an index is always only a means to 
improve performance of a specific operation, not a functional part.


if you have an attribute with a specific syntax and a default matching 
rule you can use anotehr one, but you need to tell the server which 
matching rule to use in the search filter. Otherwise teh default on 
ewill be used. On extra index can speed up the use of an alternative MR.


so the search filter shoud look somehow like: "(memberuid::=c12345)"

On 08/10/2018 03:29 PM, Patrick Landry wrote:

If I run

db_dump -p memberuid.db

I see entries like this

#\e1\04\00
:caseIgnoreIA5Match:c1096\00
BD\03\00
:caseIgnoreIA5Match:c1096\00
\98D\03\00
:caseIgnoreIA5Match:c1096\00
\a0D\03\00
:caseIgnoreIA5Match:c1096\00
\b0D\03\00
:caseIgnoreIA5Match:c1096\00

and also

 #\e1\04\00
 =C1096\00
 BD\03\00
 =C1096\00
 \98D\03\00
 =C1096\00
 \a0D\03\00
 =C1096\00
 \b0D\03\00
 =C1096\00

which seems to indicate that adding the matching rule to the index 
definition

did something.



*From: *"William Brown" 
*To: *"General discussion list for the 389 Directory server
project." <389-users@lists.fedoraproject.org>
*Sent: *Thursday, August 9, 2018 6:07:17 PM
*Subject: *[389-users] Re: Attempting to make memberUID searches
case insensitive

On Thu, 2018-08-09 at 08:23 -0500, Patrick Landry wrote:
> So what is the point of adding the matching rule when defining the
> index? Is that
> simply so that the index is built with the *capability* of
supporting
> searches using
> that matching rule explicitly?

I think it would be worth trying Ludwig's suggestion so we can
work out
*what's* going on. Perhaps the assumption we are making about what the
MR does is incorrect, and it's building a supplemental index. It's
good
to check these things to understand the behaviours.

Perhaps something else to do is check to see what content is in the
memberuid.db file to see what indexes were added.

Finally, did you run db2index again? I don't know if you answered
this.

-- 
Sincerely,


William
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to
389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/WZZPSVL7QQWQSR43BHTJ6NTPVESYPZ2N/




--



*Patrick Landry
*Director, UCSS*
*University of Louisiana at Lafayette*
*patrick.lan...@louisiana.edu 





___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/TEHKFUHBOUMSFOGNM3N4VJURJSXI7H47/


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/TG2QZWJIKMV3D3QU2YMGXJ2HZ4PWV333/

[389-users] Re: Attempting to make memberUID searches case insensitive

[Ludwig Krispenz]

On 08/09/2018 02:04 AM, William Brown wrote:

On Wed, 2018-08-08 at 07:23 -0500, Patrick Landry wrote:

Here is the index definition:

# memberuid, index, userRoot, ldbm database, plugins, config
dn: cn=memberuid,cn=index,cn=userRoot,cn=ldbm
database,cn=plugins,cn=config
objectClass: top
objectClass: nsIndex
nsSystemIndex: false
cn: memberuid
nsIndexType: eq
nsIndexType: pres
nsMatchingRule: caseIgnoreIA5Match

Seems correct to me.


Searches on memberuid do run much faster now so the index does seem
to be working.

I have groups which have multivalued memberuid attributes. A search
for (memberuid=C12345)
returns several group entries but a search for (memberuid=c12345)
does not return any entries.
I think you need to specify the matching rule in the search if you do 
not want to use the default one

Have you done a db2index since you made the index change above? It
could still be using the original index (which is case sensitive), and
we only take syntax into account as we create the index.





From: "William Brown" 
To: "General discussion list for the 389 Directory server project."
<389-users@lists.fedoraproject.org>
Sent: Tuesday, August 7, 2018 7:04:01 PM
Subject: [389-users] Re: Attempting to make memberUID searches case
insensitive

On Tue, 2018-08-07 at 16:52 -0500, Patrick Landry wrote:

I am attempting to create an index which will allow searches on

the

memberUID
attribute to be case insensitive. Using the 389-console, I

created an

Additional Index
for memberuid and added "caseIgnoreIA5Match" as a Matching Rule.

This

did not
produce the desired result.

It would be best to see your complete index definition from
cn=config
for memberUID. I think something like:

ldapsearch -b cn=config -D "cn=Directory Manager" ...
'(cn=memberuid)'

would suffice to find the index rules.


Initially I would simply like to know if what I am asking for is
possible. From reading
the docs it seems it should be. I am able to force a
caseIgnoreIA5Match by using an
extensible match search filter.

It seems like a reasonable request IMO.


Once I know it is possible and that I am following the correct
procedure then I can
provide as much detail as necessary to assist in debugging.



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to
389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/3M4FAD37YMU63GUFMKY6AYDLWIHIPUCX/


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/37DAPAKHLI7UVV2RRL4MJE7KSWGH7IQI/

[389-users] Re: disk i/o: very high write rates

[Ludwig Krispenz]

On 08/09/2018 01:53 AM, William Brown wrote:

In the audit-log there is nothing what would explain this. But in
iotop
I see a lot of threads like:

The audit log itself (and search log) will generate IO themself :)


  1621 be/4 dirsrv  0.00 B/s3.95 K/s  0.00 %  0.46 % ns-slapd
-D
/etc/dirsrv/slapd-ldap0 -i /var/run/dirsrv/slapd-ldap0.pid -w
/var/run/dirsrv/slapd-ldap0.startpid


Sadly this doesn't tell us much :(
we could get a pstack along with iotop to see which threads do teh IO, 
regular mods or the BDB regulars like trickle, checkpointing 



I configured caching and have entrycachehits about 99 - but anyway
this
would have only impact to read-operations.

DBcache would help with writes.


What's conspicuous: One of the three server has a significant higher
write rate than the others. When I watch our munin stats the two
other
have  with 40 to 60 write operations per second 10 times less. And
one
of the server suddenly reduces write-rates from more than 100 to
averate 50.

It would be good to see the ldbm config here I think. It would also be
good to know what kind of work load you have. In some configurations of
the network, things like load balancers could be sending more
read/write traffic to one server, rather than over all of them.

Another spot to check is your log buffer size, as it may be small
(causing the threads to all be writing small ammounts). The logging
subsystem is slated for a rework in the future to make it more
scalable.

Hope that helps,



Any idea?
Regards
Jan
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to
389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/5RJFPA26IXAGXXLJWEFLZF2QVCBFUED5/


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/5UZUN4N32SK33DHR4ZWMZE52A2HBFYV7/

[389-users] Re: ldapsearch performance problem

[Ludwig Krispenz]

On 06/15/2018 11:50 PM, Mark Reynolds wrote:



On 06/15/2018 05:41 PM, Jan Kowalsky wrote:

Hi Marc,

thanks for help.

Am 15.06.2018 um 22:50 schrieb Mark Reynolds:

You did not run logconv.pl the way I requested, can you please run it
again this way:

logconv.pl -ulatn  

I omitted the detailed searches because there are user-data in it...

but this here does't look like this is a problem:

- Top 20 Most Frequent etimes -

64902   etime=0
157 etime=1
34  etime=3
27  etime=2
18  etime=4

I think the next step, besides gathering the right logconv output, 
would

be to get several pstacks of the ns-slapd process at the same time the
"hang" occurs.  Then we can at least see what all the threads are doing
and hopefully get better information.  I would try and get the
389-ds-base-debuginfo package installed first though (this should give
us more readable pstacks).

hm, I installed 389-ds-base-dbg and 389-ds-base-libs-dbg. What else do I
have to do?

pstack gives me:

pstack 13463

13463: /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-ldap0 -i
/var/run/dirsrv/slapd-ldap0.pid -w /var/run/dirsrv/slapd-ldap0.startpid
(No symbols found)
0x7f808a7717bc:  (7f803c03cf20, 0, 7f803c0421f0, 0, 7f808c0dc5d6,
5615f1d4bc80) + d695834bb170
0x30157:  (0, 20, 0, 31, 3, 0) + a9ea0c848bd3
crawl: Input/output error
Error tracing through process 13463

Does this help:
Are you sure the "debuginfo" packages are the same version as 
389-ds-base/libs?


Run:  rpm -qa | grep 389-ds-base

The other option is attach gdb to the process and get a stack trace 
that way:


# gdb -p PID
(gdb) thread apply all bt
(gdb) quit




If everything runs fast:

root@ldap0:~# cat /proc/13463/stack
[] hrtimer_start_range_ns+0x1aa/0x3d0
[] hrtimer_init+0x110/0x110
[] poll_schedule_timeout+0x46/0x70
[] do_sys_poll+0x44f/0x560
[] loopback_xmit+0x65/0xa0
[] tcp_rate_gen+0x105/0x180
[] tcp_ack+0xd97/0x16e0
[] poll_select_copy_remaining+0x150/0x150
[] poll_select_copy_remaining+0x150/0x150
[] poll_select_copy_remaining+0x150/0x150
[] poll_select_copy_remaining+0x150/0x150
[] poll_select_copy_remaining+0x150/0x150
[] poll_select_copy_remaining+0x150/0x150
[] poll_select_copy_remaining+0x150/0x150
[] poll_select_copy_remaining+0x150/0x150
[] __fput+0x17d/0x220
[] recalibrate_cpu_khz+0x10/0x10
[] ktime_get_ts64+0x46/0xf0
[] SyS_poll+0x67/0x120
[] do_syscall_64+0x91/0x1a0
[] entry_SYSCALL_64_after_swapgs+0x58/0xc6
[] 0x


When it hangs:

root@ldap0:~# cat /proc/13463/stack
[] futex_wait_queue_me+0xd3/0x140
[] futex_wait+0xfc/0x260
[] poll_select_copy_remaining+0x150/0x150
[] do_futex+0x2b7/0xb40
[] lock_timer_base+0x67/0x80
[] internal_add_timer+0x1a/0x70
[] __check_object_size+0x10b/0x1dc
[] move_addr_to_user+0xbe/0xe0
[] SYSC_getsockname+0x80/0xd0
[] SyS_futex+0x83/0x180
[] SyS_setsockopt+0xb7/0xf0
[] do_syscall_64+0x91/0x1a0
[] entry_SYSCALL_64_after_swapgs+0x58/0xc6
[] 0x
Its hard to say for sure if this relates or not to the issue. This 
looks to be more of OS issue (polling) than a DS issue, but I can't 
say be sure.  Lets try and get some useful stack traces using gdb and 
go from there.
these stacks don't look like slapd stacks, also for ns-slapd process 
there should be many threads.

Are you sure you run pstack on the right process ?


Thanks,
Mark


This is reproducable.

Regards
Jan
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/AH4EBT7XK6T6F6GHOIW4V46IVOAWXTRN/

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/HPUTRKEP7OUVUEBDEUVTUU2YPKGABJA3/


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

[389-users] Re: Experiences with Large Groups (>100k Members)

[Ludwig Krispenz]

On 04/26/2018 08:06 PM, Fong, Trevor wrote:


Hi Everyone,

I was wondering what experiences people have had with large groups (> 
100k members) in 389 DS?


Particularly interested in loading, managing and syncing them.

WRT syncing – how do people efficiently sync large groups?  Most sync 
utilities sync at the attribute level; if the changed attribute (eg 
member) is multivalued, it just replaces all values.  That’s OK if 
there’s only a few values, but is not efficient when there are a large 
number of them.  A more efficient way would be to diff the 2 
attributes and add/delete the differences; does anyone know of any 
sync tools that do something like this?


389-ds does syncing/replicaten by replictaing the operation, so if you 
add one member only this modify/add operation will be replicated and 
applied. So the efficiency depends on your client application, if it 
always does a replace the the full group will be replicated, if it does 
add/del of single members the replication footprint is very small


Background:

I have a few particularly large groups of > 500k members that are 
currently handled in a DBMS, but want to migrate them to LDAP instead.


When I try to load them via ldapmodify, doing an add:member per member 
was going to take more than 24 hrs at rate of processing at the time 
of abort.


Trying to add all members instead, with a single add:member and 
listing all members after that instruction, eventually ended with an 
Operations Error.  Turning on housekeeping error level showed it was 
getting “Lock table is out of available lock entries” error – I’m in 
the process of retrying with adjusted nsslapd-db-locks in 
cn=config,cn=ldbm database,cn=plugins,cn=config.


Thanks,

Trev

_

*Trevor Fong*

/Senior Programmer Analyst/

Information Technology | Engage. Envision. Enable.

*The University of British Columbia*

trevor.f...@ubc.ca  | 1-604-827-5247 
 | it.ubc.ca 




___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Is it possible to show user only groups he belongs to via ACI

[Ludwig Krispenz]

On 04/16/2018 05:17 PM, Mariusz Gronczewski wrote:

Hi,

Each of our users have DN like uid=xani,ou=users,dc=root,dc=example,dc=com

There is also group hierarchy with POSIX groups having users as memberUid

I have aci (at the ou=groups):

(targetattr = "*") (targetfilter = (|(memberUid=xani)(ou=groups))) (version 3.0;acl "test 
auth";allow (read,compare,search)(userdn = "ldap:///anyone;);)

that allows a certain user to see only POSIX groups where they belong by 
filtering them by (memberUid=xani).

Is it possible to make a filter that would do same but dynamically take current 
binded user uid in the filter. Basically I'd like to filter by  
(memberUid=$binded_user_uid), is that possible ?
It should be possible, read about "defining access based on value 
matching. Your aci should look something like


... allow() userattr = memberuid#USERDN

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Configuring single-master replication from the cli

[Ludwig Krispenz]

On 03/09/2018 05:27 PM, Julian Kippels wrote:

Am Fri, 09 Mar 2018 17:23:39 +0100
schrieb Ludwig Krispenz <lkris...@redhat.com>:


did you look into chapter 15.2:  Configuring Replication from the
Command Line ?


Somehow I feel incredibly stupid right now…

no, it's always ok to ask

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Configuring single-master replication from the cli

[Ludwig Krispenz]

did you look into chapter 15.2:  Configuring Replication from the 
Command Line ?


On 03/09/2018 04:47 PM, Julian Kippels wrote:

Hi

Is it possible to configure single master replication from the cli? In
the documentation it is only described using the admin-server interface:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/Managing_Replication-Configuring_Single_Master_Replication

I would like to be able to automate this step, hence I need a way to do
this in a scriptable way.

Thanks,
Julian
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: ACI to allow group to access one attribute

[Ludwig Krispenz]

On 02/27/2018 01:44 PM, Angel Bosch wrote:

A better way to write this is:

(targetattr = "mycustomattr")(version 3.0; acl "allow admins
mycustomattr"; allow (all) groupdn =
"ldap:///cn=admins,ou=Groups,dc=company,dc=global;;)

That's a better rule.


I've tried this and I still can see the attribute without binding (anonymous 
search).
this means you have another aci which allows access for anonymous. The 
"deny" method works as the evaluation of the deny acis has precedence 
over the allow acis.
But I think what Williams point is, you are fixing specific access and 
thene will do it again ... and again. The preferable way is to design 
acis based on who should be allowed to do what and anly have explicite 
allow rules, and no broad allows which need to get holes punched into by 
denys



here you can see the custom attr imasLocalAdminPass

dn: uid=provamaquina01,ou=users,dc=example.net,dc=petratest,dc=proves,dc=global
imasLocalAdminPass: 12345678test
objectClass: account
objectClass: top
objectClass: posixAccount
objectClass: imasMaquines
uidNumber: 99
homeDirectory: /dev/null
gidNumber: 99
cn: provamaquina01
uid: provamaquina01
entryLevelRights: vn
attributeLevelRights: userPassword:wo, imasLocalAdminPass:rscwo, objectClass:r
  scwo, uidNumber:rscwo, homeDirectory:rscwo, gidNumber:rscwo, cn:rscwo, uid:r
  scwo

  


thanks for your time, william.
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: [SOLVED] Account lockout for failed logins not working as expected

[Ludwig Krispenz]

On 01/17/2018 01:50 PM, Mark Reynolds wrote:


On 01/16/2018 07:28 PM, William Brown wrote:

On Tue, 2018-01-16 at 23:22 +, Mitch Patenaude wrote:

So the problems were
1) I needed to set 'passwordUnlock: on' even though that's supposed
to be the default value
2) In 'cn=config' I needed to set 'passwordIsGlobalPolicy: on' on
every server to enable replication of lockout params.

I wonder if either of these are bugs. Mark?

passwordIsGlobalPolicy is what you need to replicate these attributes - not a 
bug.
I think the reason it is off is that even when it is on we do not have a 
real global account lockout management. replicating changes will 
replicate the changes eg to failcount, but it is a replace operation, 
which will be replicated, and as replication always has a latency, even 
if it is very low you could have situations like this:


assume you 5 servers and have failcount == 0 everywhere, on all servers 
simultaneously do a failed login, on each failedcount will changed to 1, 
by doing replace(failedcount,1) and this will be replicated, in the end 
you have 5 failed logins, but failedcount == 1 everywhere. and so on.


It can be even worse with specific timing. on sever 1 do 4 failed 
logins, and before it is replicated do one on server2. the change on 
server2 can have the highest csn and will win after replication, so it 
will reset 4-->1 on server 1 and keep 1 on server 2, and you can start 
again.


To get closer to a global policy we would first need to implement the 
ldap-modify-increment operation (rfc4525), this would ensure that each 
failed login is really counted. because of replication latency it could 
still exceed the configured max fail count.
To do it absolutely we would need to define a "preferred" master, 
changes to pw attribute would have to be chained to this master and the 
replicated back, this gets complicated and we haven't yet talked about 
failover of the preferred master.


So, enabling repl of pw policy attributes could make it more global, but 
there are limitations. And so it is off by default and you need to know 
what you do when you enable it


passwordUnlock is supposed to be "on" by default, but...  If you use a subtree/user 
policy (aka local policy) the global policy default value of "on" is NOT picked up.  That 
is a bug, and should of been fixed in https://pagure.io/389-ds-base/issue/49370, but in the patch 
passwordUnlock is not set to a default.  I'll fix this today...




Thanks to Kevin Kelly for pointing me in the right direction.  The
relevant documentation can be found here:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Serve
r/8.2/html/Administration_Guide/Managing_the_Password_Policy-
Configuring_the_Account_Lockout_Policy.html

   -- Mitch

On 1/16/18, 1:44 PM, "Mitch Patenaude" 
wrote:

 I'm trying to implement account lockouts for  failed login
attempts in a multi-master environment.
 
 I used something like the following ldif to enable to lockouts:

 dn:
cn="cn=nsPwPolicyEntry,ou=people,dc=example,dc=com",cn=nsPwPolicyCont
ainer,ou=people,dc=example,dc=com
 changetype: modify
 add: passwordLockout
 passwordLockout: on
 -
 add: passwordMaxFailure
 passwordMaxFailure: 5
 -
 add: passwordResetFailureCount
 passwordResetFailureCount: 1800
 -
 add: passwordLockoutDuration
 passwordLockoutDuration: 1800
 
 It works (kind of), but there are 2 problems:

 1) Even though the passwordLockoutDuration is only 30 minutes, it
locks the user out indefinitely (i.e. accountUnlockTime:
1970010100Z)
 2) The accountUnlockTime attribute doesn't get replicated, so the
user is only locked out of 1 of the 4 master servers.
 
 Any idea what I am doing wrong?
 
 Thanks,

-- Mitch Patenaude  mpatena...@shutterfly.com  Systems
engineer
 
 
 ___

 389-users mailing list -- 389-users@lists.fedoraproject.org
 To unsubscribe send an email to 389-users-leave@lists.fedoraproje
ct.org
 


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o
rg

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: dirsrv hangs on starting

[Ludwig Krispenz]

Rob,
there seem to be two issues here, one is the claim that dirsrv hangs and 
we need data, logs, pstack .


and the other is that ipactl status seems to loop

Ludwig

On 01/09/2018 05:26 PM, Rob Crittenden wrote:

pgb 205 wrote:

we are running
FC26
ds-389 1.3.6.6-2

This is actually when starting freeipa with ipact -d start
I get
ipactl -d status
ipa: DEBUG: importing all plugin modules in ipaserver.plugins...
ipa: DEBUG: importing plugin module ipaserver.plugins.aci
ipa: DEBUG: importing plugin module ipaserver.plugins.automember
ipa: DEBUG: importing plugin module ipaserver.plugins.automount
ipa: DEBUG: importing plugin module ipaserver.plugins.baseldap
ipa: DEBUG: ipaserver.plugins.baseldap is not a valid plugin module
ipa: DEBUG: importing plugin module ipaserver.plugins.baseuser
ipa: DEBUG: importing plugin module ipaserver.plugins.batch
ipa: DEBUG: importing plugin module ipaserver.plugins.ca
ipa: DEBUG: importing plugin module ipaserver.plugins.caacl
ipa: DEBUG: importing plugin module ipaserver.plugins.cert
ipa: DEBUG: importing plugin module ipaserver.plugins.certprofile
ipa: DEBUG: importing plugin module ipaserver.plugins.config
ipa: DEBUG: importing plugin module ipaserver.plugins.delegation
ipa: DEBUG: importing plugin module ipaserver.plugins.dns
ipa: DEBUG: importing plugin module ipaserver.plugins.dnsserver
ipa: DEBUG: importing plugin module ipaserver.plugins.dogtag
ipa: DEBUG: importing plugin module ipaserver.plugins.domainlevel
ipa: DEBUG: importing plugin module ipaserver.plugins.group
ipa: DEBUG: importing plugin module ipaserver.plugins.hbac
ipa: DEBUG: ipaserver.plugins.hbac is not a valid plugin module
ipa: DEBUG: importing plugin module ipaserver.plugins.hbacrule
ipa: DEBUG: importing plugin module ipaserver.plugins.hbacsvc
ipa: DEBUG: importing plugin module ipaserver.plugins.hbacsvcgroup
ipa: DEBUG: importing plugin module ipaserver.plugins.hbactest
ipa: DEBUG: importing plugin module ipaserver.plugins.host
ipa: DEBUG: importing plugin module ipaserver.plugins.hostgroup
ipa: DEBUG: importing plugin module ipaserver.plugins.idrange
ipa: DEBUG: importing plugin module ipaserver.plugins.idviews
ipa: DEBUG: importing plugin module ipaserver.plugins.local
ipa: DEBUG: importing plugin module ipaserver.plugins.join
ipa: DEBUG: importing plugin module ipaserver.plugins.krbtpolicy
ipa: DEBUG: importing plugin module ipaserver.plugins.ldap2
ipa: DEBUG: importing plugin module ipaserver.plugins.location
ipa: DEBUG: importing plugin module ipaserver.plugins.migration
ipa: DEBUG: importing plugin module ipaserver.plugins.misc
ipa: DEBUG: importing plugin module ipaserver.plugins.netgroup
ipa: DEBUG: importing plugin module ipaserver.plugins.otp
ipa: DEBUG: ipaserver.plugins.otp is not a valid plugin module
ipa: DEBUG: importing plugin module ipaserver.plugins.otpconfig
ipa: DEBUG: importing plugin module ipaserver.plugins.otptoken
ipa: DEBUG: importing plugin module ipaserver.plugins.passwd
ipa: DEBUG: importing plugin module ipaserver.plugins.permission
ipa: DEBUG: importing plugin module ipaserver.plugins.ping
ipa: DEBUG: importing plugin module ipaserver.plugins.pkinit
ipa: DEBUG: importing plugin module ipaserver.plugins.privilege
ipa: DEBUG: importing plugin module ipaserver.plugins.pwpolicy
ipa: DEBUG: Starting external process
ipa: DEBUG: args=klist -V
ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: stdout=Kerberos 5 version 1.15.1
ipa: DEBUG: stderr=
ipa: DEBUG: importing plugin module ipaserver.plugins.rabase
ipa: DEBUG: ipaserver.plugins.rabase is not a valid plugin module
ipa: DEBUG: importing plugin module ipaserver.plugins.radiusproxy
ipa: DEBUG: importing plugin module ipaserver.plugins.realmdomains
ipa: DEBUG: importing plugin module ipaserver.plugins.role
ipa: DEBUG: importing plugin module ipaserver.plugins.schema
ipa: DEBUG: importing plugin module ipaserver.plugins.selfservice
ipa: DEBUG: importing plugin module ipaserver.plugins.selinuxusermap
ipa: DEBUG: importing plugin module ipaserver.plugins.server
ipa: DEBUG: importing plugin module ipaserver.plugins.serverrole
ipa: DEBUG: importing plugin module ipaserver.plugins.serverroles
ipa: DEBUG: importing plugin module ipaserver.plugins.service
ipa: DEBUG: importing plugin module ipaserver.plugins.servicedelegation
ipa: DEBUG: importing plugin module ipaserver.plugins.session
ipa: DEBUG: importing plugin module ipaserver.plugins.stageuser
ipa: DEBUG: importing plugin module ipaserver.plugins.sudo
ipa: DEBUG: ipaserver.plugins.sudo is not a valid plugin module
ipa: DEBUG: importing plugin module ipaserver.plugins.sudocmd
ipa: DEBUG: importing plugin module ipaserver.plugins.sudocmdgroup
ipa: DEBUG: importing plugin module ipaserver.plugins.sudorule
ipa: DEBUG: importing plugin module ipaserver.plugins.topology
ipa: DEBUG: importing plugin module ipaserver.plugins.trust
ipa: DEBUG: importing plugin module ipaserver.plugins.user
ipa: DEBUG: importing plugin module ipaserver.plugins.vault
ipa: DEBUG: importing 

[389-users] Re: ACI help

[Ludwig Krispenz]

On 09/07/2017 02:25 AM, William Brown wrote:

On Wed, 2017-09-06 at 16:55 -0300, Alberto Viana wrote:

Hi Folks,

389-Directory/1.3.7.3.20170901gite67788a B2017.244.1727

I'm trying to give a specific read/search/compare permissions to an user in
a sub OU in my tree.

I deleted the default ACI "anonymous access" (For tests purposes)

I'm tried the following ACIs:

OU scope:

dn: OU=pop-ac,ou=pops,dc=my,dc=domain
changetype: modify
add: aci
aci: (targetattr!="userPassword") (version 3.0;acl "All attributes PoP-AC
Permissions";allow (read,search,compare)
userdn="ldap:///uid=my-test-user,ou=aplicacoes,dc=my,dc=domain;;)

Log:
06/Sep/2017:16:15:32.427750186 -0300] - DEBUG - NSACLPlugin -
print_access_control_summary - conn=47 op=1 (main): Deny search on
entry(uid=rodrigo.nonato,ou=pop-ac,ou=pops,dc=my,dc=domain).attr(objectClass)
to uid=my-test-user,ou=aplicacoes,dc=my,dc=domain: no aci matched the
subject by aci(242): aciname= "SIE Group", acidn="dc=my,dc=domain"

=> SIE Group is one of the default 389 ACIs.

or

Whole domain scope:

dn: dc=my,dc=domain
changetype: modify
add: aci
aci:
(target="ldap:///OU=pop-ac,ou=pops,dc=my,dc=domain;)(targetattr!="userPassword")
(version 3.0;acl "All attributes PoP-AC Permissions";allow
(read,search,compare)
userdn="ldap:///uid=my-test-user,ou=aplicacoes,dc=my,dc=domain;;)


Log:
[06/Sep/2017:16:41:33.824679480 -0300] - DEBUG - NSACLPlugin -
print_access_control_summary - conn=50 op=1 (main): Deny search on
entry(uid=rodrigo.nonato,ou=pop-ac,ou=pops,dc=my,dc=domain).attr(objectClass)
to uid=my-test-user,ou=aplicacoes,dc=my,dc=domain: no aci matched the
subject by aci(253): aciname= "All attributes PoP-AC Permissions",
acidn="dc=my,dc=domain"



What I need: An user that has no other rights on my tree to read/search all
attributes/users on an specific OU.

Is that possible? What am I missing?

So the aci guide is really long: we've been working to improve it lately
to help with common aci questions like this so this is a great place to
start:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_access_control


So the aci you have here:


dn: OU=pop-ac,ou=pops,dc=my,dc=domain
changetype: modify
add: aci
aci: (targetattr!="userPassword") (version 3.0;acl "All attributes

PoP-AC

Permissions";allow (read,search,compare)
userdn="ldap:///uid=my-test-user,ou=aplicacoes,dc=my,dc=domain;;)

Should be the correct one.

it is, and it works for me. The ( ) around the bind rule are not required.

So I just have a wild guess. I think you anonymized the aci for this 
post using "test-user" and "dc=my,dc=domain". could you verify that you 
haven't a typo in the real aci for the userdn ?

My guess is the that the aci should be:

(targetattr!="userPassword")(version 3.0;acl "All attributes PoP-AC
Permissions"; allow
(read,search,compare)(userdn="ldap:///uid=my-test-user,ou=aplicacoes,dc=my,dc=domain;);)

The change is the parens around the userdn.

This should be on the OU=pop-ac,ou=pops,dc=my,dc=domain object.

As well, you may need to start your query basedn at
OU=pop-ac,ou=pops,dc=my,dc=domain rather than dc=my,dc=domain too.



As a follow up, please don't use targetattr!=userPassword. This exposes
a *lot* of internal system attributes to the user object in question.
It's much better if you limit this to just the attributes required like:

aci: (targetattr="objectClass || nsUniqueId || uid || displayName ||
loginShel
  l || uidNumber || gidNumber || gecos || homeDirectory || givenName ||
cn || m
  emberOf || mail || sshPublicKey || nsAccountLock ||
userCertificate")( target
  ="ldap:///uid=*,ou=People,dc=blackhats,dc=net,dc=au;
)(targetfilter="(&(objec

tClass=account)(objectClass=person)(objectClass=posixaccount))")(version
3.0;
   acl "Enable anonymous partial user read"; allow (read, search,
compare)(user
  dn="ldap:///anyone;);)

Hope that helps a little bit.



Thanks

Cheers,

Alberto Viana
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Problem adding users to group.

[Ludwig Krispenz]

On 08/09/2017 09:48 PM, Lucas Diedrich wrote:
Willian, i can make that, is there any manual on how to get the data 
trough gstack?


Another thing, as i needed to resolve the issue, i had ldapmodify my 
group adding the members, using the method below it took like 16 sec. 
peer user and leading to un-reponsive system after the 30th user:


*/dn: cn=mygorup,cn=groups,cn=accounts,dc=domain/*
*/changetype: modify/*
*/add: member/*
*/dn: uid=user1,cn=users,cn=accounts,dc=domain/*
*/-/*
*/dn: cn=mygorup,cn=groups,cn=accounts,dc=domain
/*
*/changetype: modify/*
*/add: member/*
*/dn: uid=user2,cn=users,cn=accounts,dc=domain/*
*/-/*
*/dn: cn=mygorup,cn=groups,cn=accounts,dc=domain
/*
*/changetype: modify/*
*/add: member/*
*/dn: uid=user3,cn=users,cn=accounts,dc=domain/*
*/-/*
+ 50 users

But, changing to the method below, i was able to add all 600 users in 
only 16 sec with no un-responsive time:


*/dn: cn=mygorup,cn=groups,cn=accounts,dc=domain/*
*/changetype: modify/*
*/add: member/*
*/dn: uid=user1,cn=users,cn=accounts,dc=domain/*
*/dn: uid=user2,cn=users,cn=accounts,dc=domain/*
*/dn: uid=user3,cn=users,cn=accounts,dc=domain/*
*/+55/*
/*this is no surprise. in on case you have >50 operations and over 50 
invocations of teh memberof plugin and in the other case there is only 
one operation and one plugin call*/

*/-/*

Em ter, 8 de ago de 2017 às 19:57, William Brown > escreveu:


On Mon, 2017-08-07 at 17:30 +, Lucas Diedrich wrote:
> Hello guys,
>
> i have a *Freeipa 4.4.1* with 389
(389-ds-base-1.3.5.18-1.fc25.x86_64), my
> problem is, i have a huge group with 5400 users, but i've to add
more 800
> to it, when i try to add more than 10 my dirsrv goes unresponsive.
>
> When the system starts to replicate all my Freeipa's goes
unresponsive,
> asking over #389 some guys susgest that could be a bug with the
*memberof
> plugin*, is there anything i can do to fix this?

Morning,

Would you mind taking a gstack of the ns-slapd process when it goes
un-responsive? This would help me to see why it's showing high latency
like this.

Thanks,

--
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

___
389-users mailing list -- 389-users@lists.fedoraproject.org

To unsubscribe send an email to
389-users-le...@lists.fedoraproject.org




___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Index corruption message in multimaster replication

[Ludwig Krispenz]

On 07/17/2017 02:53 AM, William Brown wrote:

On Sun, 2017-07-16 at 19:49 +, tda...@email.arizona.edu wrote:

Which version of 389-ds-base do you have configured?


I'm running on RHEL 6.9
In the errors log, it shows 389-Directory/1.2.11.15 B2015.345.187
The RPM for it is 389-ds-base-1.2.11.15-69.el6_7.x86_64 is the RPM

I'll need to check with the team, but I do not believe we are supporting
this version any more. We have some newer 1.2.x series release, but we
won't backport fixes to anything in this series (even if we find the
root cause).


Sorry, there is no way to see which index it is easily. It looks like a
substring index, but you likely need to correlate this to an access log
that made a query of "*zon".


I searched all the access logs there and couldn't find a string matching *zon. 
Subsequently, another identical error message showed up for the string "*urs". 
I was not able to find that in the access logs either.

So, I started doing dbscans on the indexes and eventually found two that are 
most likely the culprits, cn.db4 and ismemberof.db4. In the dbscans for these I 
found the following:

cn.db4:
*urs403595
*zon409451

ismemberof.db4:
*urs403926
*zon28

Are you saying then that I may not actually have a corrupt index?

Correct. I think the issue is we don't have enough space to read in your
index during a search process. I suspect it's the later index, for
ismemberof. I'll see if I can reproduce this on my system.

For now a solution *could* be to remove substr on ismember of and cn,
and allow the other indexes to be searched. It would be good to see the
queries that cause the issue because that could help me advise better on
if this is an adquete temporary work around.
the buffer cannot really be to small, in c_get(... DB_MULTIPLE) we 
provide the buffer and its size and the buffer will be filled by the bdb 
functions. Since in a substring index our key always has a size of 4 and 
the data is an ID with size 4 always at least one key/data pair will fit.


But there are two issues, the BUFFER_SMALL was on one server and the 
*zon error on the other. And it explicitely said that the data size was 
5 instead of the expected 4, so this indicates that there is really 
someting broken in that index.


I would suggest to combine your and Mark's proposal: remove the 
substring index and reindex the database




___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: invalid bind dn

[Ludwig Krispenz]

On 07/07/2017 09:44 AM, Ludwig Krispenz wrote:


On 07/07/2017 02:04 AM, William Brown wrote:

On Thu, 2017-07-06 at 14:35 +0200, Ludwig Krispenz wrote:

dn="Directory Manager,dc=text,dc=in" is not a valid dn (err=34)

the attribute for "directory manager" is missing. you need to verify what is teh proper 
dn, most likely:"cn=directory Manager,dc=text,dc=in"
but you have to make sure this entry exists


On 07/06/2017 12:14 PM, narendra laga wrote:

Hi,
Please suggest me to reslove this issue.
we are trying to integrate 389 ldap to cyberoam, while doing test connection we 
are facing below issue.

If you are trying to access the "directory manager" IE the root account,
it has no suffix:

"cn=Directory Manager"

Maybe that helps?
yes, as I said before this will work, but it is the intended bind. 

wanted to write "is it the intended bind ??"
We should not push to just use "cn=directory manager" just because it 
works. If they have an external application like "cyberoam" (whatever 
this is (kind of access manager?)), i would really recommend NOT to 
let it use "cn=directory manager"

cyberoam




___
389-users mailing list --389-users@lists.fedoraproject.org
To unsubscribe send an email to389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: invalid bind dn

[Ludwig Krispenz]

On 07/07/2017 02:04 AM, William Brown wrote:

On Thu, 2017-07-06 at 14:35 +0200, Ludwig Krispenz wrote:

dn="Directory Manager,dc=text,dc=in" is not a valid dn (err=34)

the attribute for "directory manager" is missing. you need to verify what is teh proper 
dn, most likely:"cn=directory Manager,dc=text,dc=in"
but you have to make sure this entry exists


On 07/06/2017 12:14 PM, narendra laga wrote:

Hi,
Please suggest me to reslove this issue.
we are trying to integrate 389 ldap to cyberoam, while doing test connection we 
are facing below issue.

If you are trying to access the "directory manager" IE the root account,
it has no suffix:

"cn=Directory Manager"

Maybe that helps?
yes, as I said before this will work, but it is the intended bind. We 
should not push to just use "cn=directory manager" just because it 
works. If they have an external application like "cyberoam" (whatever 
this is (kind of access manager?)), i would really recommend NOT to let 
it use "cn=directory manager"

cyberoam




___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: IIAP - Ldap authentication

[Ludwig Krispenz]

On 07/06/2017 03:17 PM, Mark Reynolds wrote:



On 07/06/2017 05:59 AM, Narendra Laga wrote:



Hi,


can any one help on below issue.


we are integrating 389-DS with cyberoam, while doing test connection 
we are facing below error.




Please check the below Ldap authentication errors and check for  the 
solution.




*@ green color is anonymous, yellow color is error of admin integration*

*
*

*
*


[05/Jul/2017:05:36:47.061794640 -0400] conn=18 fd=76 slot=76 
connection from 192.168.1.xx to 192.168.1.xx
[05/Jul/2017:05:36:47.061901295 -0400] conn=18 op=0 BIND dn="" 
method=128 version=3
[05/Jul/2017:05:36:47.061967021 -0400] conn=18 op=0 RESULT err=0 
tag=97 nentries=0 etime=0 dn=""

[05/Jul/2017:05:36:47.062430621 -0400] conn=18 op=1 UNBIND
[05/Jul/2017:05:36:47.062449012 -0400] conn=18 op=1 fd=76 closed - U1
[05/Jul/2017:05:38:01.813877357 -0400] conn=19 fd=76 slot=76 
connection from 192.168.1.xx to 192.168.1.xx
[05/Jul/2017:05:38:01.814000145 -0400] conn=19 op=0 BIND 
dn="Directory Manager,dc=text,dc=in" authzid="(null)", invalid bind dn
[05/Jul/2017:05:38:01.814048128 -0400] conn=19 op=0 RESULT err=34 
tag=97 nentries=0 etime=0
The bind dn has an invalid syntax.  I think you should try 
"cn=directory manager", not "Directory Manager,dc=text,dc=in", as your 
bind dn
not necessarily. This would work, but not sure if it was the intended 
bind, could be a user with less privileges. I already answered in the 
other thread that they need to find out which user they want to use for 
binding

[05/Jul/2017:05:38:01.814627178 -0400] conn=19 op=1 UNBIND
[05/Jul/2017:05:38:01.814642192 -0400] conn=19 op=1 fd=76 closed - U1
[05/Jul/2017:05:38:59.609119006 -0400] conn=20 fd=76 slot=76 
connection from 192.168.1.254 to 192.168.1.159
[05/Jul/2017:05:38:59.609238893 -0400] conn=20 op=0 BIND 
dn="Directory Manager,dc=text,dc=in" authzid="(null)", invalid bind dn



Thanks & Regards,
Narendra.Laga
Engineer, NOC Operations
Locuz Enterprise Solutions Ltd | Tel : +91- 4045004678
http://www.locuz.com 



___
389-users mailing list --389-users@lists.fedoraproject.org
To unsubscribe send an email to389-users-le...@lists.fedoraproject.org




___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: invalid bind dn

[Ludwig Krispenz]

dn="Directory Manager,dc=text,dc=in" is not a valid dn (err=34)

the attribute for "directory manager" is missing. you need to verify what is teh proper 
dn, most likely:"cn=directory Manager,dc=text,dc=in"
but you have to make sure this entry exists


On 07/06/2017 12:14 PM, narendra laga wrote:

Hi,

Please suggest me to reslove this issue.
we are trying to integrate 389 ldap to cyberoam, while doing test connection we 
are facing below issue.

[05/Jul/2017:05:38:01.814000145 -0400] conn=19 op=0 BIND dn="Directory 
Manager,dc=text,dc=in" authzid="(null)", invalid bind dn

Thanks,
Narendra
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Migration from OpenLDAP to 389 DS

[Ludwig Krispenz]

Hi,

389-ds has an access control mechanism which allows fine grained access 
to entries, attributes for different types of operation and based on 
various criteria like d,n group membership, role, and you should get 
familiar with the basics before just adding specific acis:


https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_access_control

for your specific request you could do something like:

dn: l=kranj,c=si
aci: (targetattr = "*")(version 3.0; acl "Admin rights"; allow( all ) 
userdn = "ldap:///uid=mnadmin,ou=user,l=Kranj,c=si;;)


not that in 389-ds acis have to be placed at the top of the subtree they 
should apply


Ludwig

On 06/22/2017 12:31 PM, Kalan Blaz wrote:


Hi Mark,

Thank you very much for your help. Now I hit to another problem and 
maybe you can help me. At OpenLDAP we have two “super users” which has 
read/write/delete access for whole tree. Now in 389 DS I can do 
changes or view the data only if I am login as cn=directory manager. 
All my “super users” are already in 389 DS database, but I do not know 
how to set them proper rights. Here is an example with ldapsearch:


ldapsearch -D "cn=directory manager" -w iskratel -b "l=kranj,c=si" -p 
1317 -h kalanvm1.csi.iskratel.mak | grep numResponses


# numResponses: 108

ldapsearch -D "uid=mnadmin,ou=user,l=Kranj,c=si" -w mzPLlgQ3 -b 
"l=kranj,c=si" -p 1317 -h kalanvm1.csi.iskratel.mak | grep numResponses


# numResponses: 1

So my question here is, what I must do, that user mnadmin have r/w/d 
permissions and will see the same tree as directory manager does?


Best regards,

Blaz



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: notes=A for filter with undefined attribute

[Ludwig Krispenz]

On 06/09/2017 03:27 PM, albert@uwindsor.ca wrote:

Hi,

Xerox printer's LDAP connectivity's default search filter is 
(|(uid=someone)(samaccountname=someone)). samaccountname is not a defined 
attribute. This search filter will result notes=A, causing performance issue.

Is there a way to avoid searching samaccountname=someone, since samaccountname 
is not a defined attribute. Thank you!
no, I don't think so, and it should be easier to change the client to 
not use undefined attributes in searches instead of extending the server 
to handle all kinds of "..." requests.
If you want to bypass this, you can define the attribute and index it, 
it will be one quick index lookup for (samaccountname=someone)returning 
nothing and the results should be only based on (uid=someone)

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Migration from OpenLDAP to 389 DS

[Ludwig Krispenz]

openldap heavily uses the "orderd value or entry prefix", so youhave 
numbers {nnn} in the dns and attributes like:


cn={12}itnetmanager

or

olcAttributeTypes: {262} ...

I would first try to remove these {nnn} stuff and retry


On 06/07/2017 10:25 AM, b.ka...@iskratel.si wrote:

Hi,

I'm completely new in LDAP and I have one task to do. Task is migration from 
OpenLDAP to 389 DS.
I have installed 389 and now I try to import schema from OpenLDAP. First I 
create export of schema from OpenLDAP.

config.ldif is done with command:   slapcat -F /opt/ldap/mn/slapd.d/ -b 
"cn=config" > conf.ldif
itnetmanager.ldif is done via java LDAP Browser.

Then I try to convert this ldif files with scripts at 
http://www.port389.org/docs/389ds/scripts.html, but I did not succeed.
Can someone help me, how can I convert ldif files from OpenLDAP, that be useful 
for import to 389 DS?

Here are few rows from both file:

itnetmanager_schema_export.ldif
dn: cn={12}itnetmanager, cn=schema, cn=config
olcObjectClasses: {0} ( 1.3.6.1.4.1.1332.1000.30.1 NAME 'itPrepaidPinSub' DES
  C 'IskratelprepaidPinSub' MUST ( itPrepaidPin $ itDirectoryNumber ) )
olcObjectClasses: {1} ( 1.3.6.1.4.1.1332.1000.30.2 NAME 'itPrepaidCgPNSub' DE
  SC 'IskratelprepaidCgPNSub' MUST ( itCgPN $ itDirectoryNumber ) )
olcObjectClasses: {2} ( 1.3.6.1.4.1.1332.1000.30.3 NAME 'itPrepaidSubAccount'
   DESC 'IskratelprepaidSubAccount' MUST ( itDirectoryNumber $ itAccountStatus
   $ itAccountBalance $ itDateOfLastUsed $ itDateOfExpiry $ itLanguageCode $ i
  tUnsucRechargeAtt $ itStatGroupId $ itPrepaidSetId))
olcObjectClasses: {3} ( 1.3.6.1.4.1.1332.1000.30.4 NAME 'itPrepaidSet' DESC '
  IskratelprepaidSet' MUST ( itPrepaidSetId $ itPrepaidSetName $ itWelcomeMsgM
  ode $ itLanguageMode $ itCbMode $ itRechargeAuth $ itLockAuth $ itRrReqMode
  $ itMaxCallAtt $ itMaxRechargeAtt $ itSimultCallsAuth $ itLowBalanceWarn $ i
  tNearExpiryWarn $ itNegAccBalance $ itMaxAccBalance $ itSuspensionDur $ itMi
  nCallDur $ itLowBalanceValue1 $ itLowBalanceValue2 $ itCnPNDisplayMode $ itP
  repaidSubsType $ itAvailDurMsgAuth $ itAccBalMsgAuth $ itOrgChargeCode $ itV
  alidityTime ))
...
olcAttributeTypes: {262} ( 1.3.6.1.4.1.1332.1000.10.266 NAME ('itDefaultPolic
  yProfile') DESC 'Is User Policy Default' EQUALITY booleanMatch SUBSTR caseIg
  noreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcAttributeTypes: {263} ( 1.3.6.1.4.1.1332.1000.10.267 NAME ('itPasswordHist
  ory') DESC 'User Password History' EQUALITY caseIgnoreMatch SUBSTR caseIgnor
  eSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
objectClass: olcSchemaConfig
cn: {12}itnetmanager



config.ldif
dn: cn=config
olcLogLevel: 0
olcConnMaxPending: 100
olcConcurrency: 0
olcWriteTimeout: 0
olcArgsFile: /var/run/openldap/slapd_mn.args
olcIndexSubstrAnyStep: 2
olcSockbufMaxIncoming: 262143
olcTLSCertificateKeyFile: /opt/ldap/mn/certs/password
objectClass: olcGlobal
olcIndexIntLen: 4
olcConnMaxPendingAuth: 1000
olcTLSCertificateFile: "OpenLDAP Server"
cn: config
olcIndexSubstrIfMinLen: 2
olcAttributeOptions: lang-
olcPidFile: /var/run/openldap/slapd_mn.pid
olcConfigDir: /opt/ldap/mn/slapd.d/
olcReverseLookup: FALSE
olcGentleHUP: FALSE
olcTLSCACertificatePath: /opt/ldap/mn/certs
olcReadOnly: FALSE
olcTLSVerifyClient: never
olcThreads: 16
olcIndexSubstrAnyLen: 4
olcToolThreads: 1
olcSockbufMaxIncomingAuth: 16777215
olcIdleTimeout: 0
olcSaslSecProps: noplain,noanonymous
olcConfigFile: /opt/ldap/mn/slapd.conf
olcAuthzPolicy: none
olcIndexSubstrIfMaxLen: 4
olcAllows: bind_v2
olcLocalSSF: 71

dn: cn=schema, cn=config
olcObjectClasses: ( 2.5.6.0 NAME 'top' DESC 'top of the superclass chain' ABS
  TRACT MUST objectClass )
olcObjectClasses: ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' DESC
   'RFC4512: extensible object' SUP top AUXILIARY )
olcObjectClasses: ( 2.5.6.1 NAME 'alias' DESC 'RFC4512: an alias' SUP top STR
  UCTURAL MUST aliasedObjectName )
...
olcAccess: {2}to attrs=itPasswordFtp  by group/groupOfUniqueNames/uniqueMembe
  r.exact="cn=adminrole,ou=group,l=Kranj,c=SI" write  by * none
olcAccess: {3}to attrs=itPasswordDb  by group/groupOfUniqueNames/uniqueMember
  .exact="cn=adminrole,ou=group,l=Kranj,c=SI" write  by * none
olcDbConfig: {0}# Set location for txn log files
olcDbConfig: {1}set_lg_dir /opt/ldap/mn/ldapDB
olcDbConfig: {2}# Set cache size 20MB
olcDbConfig: {3}set_cachesize 0 20971520 0
olcDbConfig: {4}set_lg_regionmax 262144
olcDbConfig: {5}set_lg_bsize 2097152
olcDbConfig: {6}# Automatically remove log files that are no longer needed.
olcDbConfig: {7}set_flags DB_LOG_AUTOREMOVE
olcDbConfig: {8}# Just use these settings when doing slapadd...
olcDbConfig: {9}# set_flags DB_TXN_NOSYNC
olcDbIDLcacheSize: 0
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDbShmKey: 0
olcMaxDerefDepth: 10
olcLastMod: TRUE
olcDbCacheFree: 5
olcDbCacheSize: 15
olcDbDirtyRead: FALSE
olcReadOnly: FALSE
olcDbSearchStack: 16
olcDatabase: {2}bdb
olcDbDNcacheSize: 0
olcRootPW: 

[389-users] Re: enabled account policy plugin and incrace changelog db size

[Ludwig Krispenz]

On 05/31/2017 01:44 AM, William Brown wrote:

On Tue, 2017-05-30 at 15:42 +0300, Alparslan Ozturk wrote:

this is my person object and it has lastlogintime (the operational
attribute) so if many user bind the lastlogintime information updated so
replication is started. now I am changed agreement exclude lastlogintime
many replication is not accured. so changelogdb size slowly incrace. but
still incrace the size.



I don't think you can use fractionalReplication like this. Because you
end up commiting a change on either A or B master that can't be resolved
by the other, so the cl will grow forever.

Allow the replication of the attr :)
the changes will be logged independent if they are replicated or not, so 
trimming is the only way to limit the size.
if you mean that trimming doesn't happen if the change is not 
rpelicated, this should be handled by the regular update of the "keep 
alive" entry, which will be replicated and update the consumer ruv, so 
that trimming can procede




___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: password not expire 389

[Ludwig Krispenz]

On 03/03/2017 10:23 AM, Predrag Zečević - Technical Support Analyst wrote:

On 02/28/17 03:15 PM, Mark Reynolds wrote:

I can confirm that something is wrong, also in 389-ds-base-1.3.5.14
(e.g. also having same problem).

Make sure you are NOT using Directory manager to change passwords.
Directory manager bypasses password policies.



Thanks, that might be a reason. I will make note and check scripts.

On a side note -  this is documented in the Administration guide.

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/User_Account_Management.html#Managing_the_Password_Policy-Setting_User_Passwords 



This doc refers to the Directory Manager account as the root DN, which
is correct but could be confusing.  This could be "clearer" so I've
opened a doc bug on this.

Regards,
Mark


Hi Mark,

I have checked scripts and found following - for changing password we 
have 2 scenarios:

a) user changes it self (via PHP web interface - that works fine BTW)
b) member of group "Directory Administrators" (with proper ACI) 
changes it for user (from shell script - works fine)


I have cases that user IS able to authorize against LDAP even if 
password has been expired... In global password policy we have set this:


passwordMaxAge: 31536000 # 365 days (I guess that is default)

In local one (per user policy 
"cn=nsPwPolicyContainer,ou=people,dc=2e-systems,dc=com") we have 
redefined that value:


passwordMaxAge: 7776000 # which is 90 days

Can be that be a problem? User name is replaced in output below:

#= Global PP Setup ===
# ldapsearch -xLLL  -D "cn=Directory Manager" -b 'cn=config' -s base 
'objectClass=*' '*' passwordHistory | grep ^password

passwordInHistory: 7
passwordUnlock: on
passwordGraceLimit: 3
passwordMustChange: off
passwordWarning: 604800
passwordLockout: on
passwordMinLength: 8
passwordMinDigits: 1
passwordMinAlphas: 1
passwordMinUppers: 1
passwordMinLowers: 1
passwordMinSpecials: 0
passwordMin8bit: 0
passwordMaxRepeats: 0
passwordMinCategories: 4
passwordMinTokenLength: 3
passwordMaxFailure: 3
passwordMaxAge: 31536000
passwordResetFailureCount: 1800
passwordIsGlobalPolicy: on
passwordLegacyPolicy: on
passwordTrackUpdateTime: off
passwordChange: on
passwordExp: off
passwordSendExpiringTime: off
passwordLockoutDuration: 3600
passwordCheckSyntax: on
passwordMinAge: 0
passwordStorageScheme: SSHA
passwordAdminDN:
passwordHistory: on

#= User PP setup ===
# ldapsearch -xLLL  -D "cn=Directory Manager" -b 
"cn=nsPwPolicyContainer,ou=people,dc=2e-systems,dc=com" 
"(&(objectClass=ldapsubentry)(objectClass=passwordPolicy)(cn=*GivenName Surname*))" 

dn: cn=cn\3DnsPwPolicyEntry\2Ccn\3Dgivenname 
surname\2Cou\3Dpeople\2Cdc\3D2e-s

 ystems\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=2e-systems,dc=com
passwordInHistory: 5
passwordMinAge: 600
passwordChange: on
passwordUnlock: on
passwordLockoutDuration: 1800
passwordResetFailureCount: 600
passwordLockout: on
passwordMaxFailure: 10
passwordMaxRepeats: 0
passwordStorageScheme: ssha
passwordMaxAge: 7776000
passwordExp: on
passwordGraceLimit: 6
passwordMin8bit: 0
passwordMinAlphas: 0
passwordMinSpecials: 1
passwordMinDigits: 1
passwordMinLowers: 1
passwordMinUppers: 1
passwordMinTokenLength: 5
passwordMinCategories: 4
passwordMinLength: 8
passwordCheckSyntax: on
passwordMustChange: off
objectClass: top
objectClass: ldapsubentry
objectClass: passwordpolicy
cn: cn=nsPwPolicyEntry,cn=givenname 
surname,ou=people,dc=2e-systems,dc=com


#= User DN Setup ===
# ldapsearch -xLLL  -D "cn=Directory Manager" -b 
"dc=2e-systems,dc=com" 
"(&(objectclass=additionalPersonalData)(cn=GivenName Surname))"

dn: cn=GivenName Surname,ou=People,dc=2e-systems,dc=com
passwordExpirationTime: 20170223113208Z
passwordExpWarned: 0
passwordGraceUserTime: 2
passwordRetryCount: 0
passwordAllowChangeTime: 20161125114208Z
passwordHistory: 
20151015062612Z{SSHA}yFVx6mQasMSPFIb1cgrEMPQoxDYgLk3Lnl5MWA==
passwordHistory: 
20160331065019Z{SSHA}kRLwA3OjzKnmsYwk31dIHHWEZWIO2P3RISBXxQ==
passwordHistory: 
20160622062736Z{SSHA}P8iQemcypxBwWaFOaqcJe+KLNTFyNrNxBT3VAw==
passwordHistory: 
20160915064325Z{SSHA}a9WrOm5IDrhc3mN+P9DmHGj6QZl4ZpWGLbRQ/w==
passwordHistory: 
20161125113208Z{SSHA}peCYxS8AY7t7HagqdDeyXTTTJHMNNErOkGHcEg==


In this last output one can see that password has expired at 
20170223113208Z - but user still can log-in into LDAP?


What could be wrong here?

you have configured a
passwordGraceLimit: 6

which means the user can login 6 times after the pw expired


With best regards.
Predrag Zečević


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To 

[389-users] Re: 389DS v1.3.4.x after fixes for tickets 48766 and 48954

[Ludwig Krispenz]

On 09/07/2016 08:55 AM, Ludwig Krispenz wrote:


On 09/06/2016 02:02 PM, Ivanov Andrey (M.) wrote:

Hi Ludwig,

<http://www.polytechnique.edu>




the fixes for the tickets you mention did change the iteration
thru the changelog and how it handles situtations when the start
csn is not found in the changelog. and it also did change the
logging, so you might see messages now which were not there or
hidden before. 


That was my understanding too.
so far I have not seen any replication problems related to these 
messages, all generatedcsns seem to be replicated. What makes it a bit 
more difficult is that most of the updates are updates of 
lastlogintime and the original MOD is not logged. I still do not 
understand why we have these messages so frequently, I will try to 
reproduce.
Or, if it possible, could you run the servers for just an hour with 
replication logging enabled ?
no more need for this, I found the messages in a deployment where repl 
logging was enabled. I think it happens when the smallest consumer 
maxCSN is ahead of the local maxCSN for this replicaID.
It should do no harm, but in some scenarios could slow down replication 
a bit.

I will continue to investigate and work on a fix


When looking into the provided data set I did notice three replicated 
ops with err=50, insufficient access. This should not happen and 
requires a separate investigation



But I am very surprised to see them so frequently and I would
like to understand it.
First some questions, do you have changelog trimming enabled and
how, do you have fractional replication ?

yes for both questions.

Trimming: 14 days
Fractional replication:
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE entryusn memberOf
nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn
nsds5ReplicaStripAttrs: modifiersName modifyTimestamp 
internalModifiersName internalModifyTimestamp internalCreatorsname


Changelog:
cn=changelog5,cn=config
objectClass: top
objectClass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /Local/dirsrv/var/lib/dirsrv/slapd-ens/changelogdb
nsslapd-changelogmaxage: 14d


replica:
cn=replica,cn=dc\\3Did\\2Cdc\\3Dpolytechnique\\2Cdc\\3Dedu,cn=mapping 
tree,cn=config

objectClass: top
objectClass: nsDS5Replica
cn: replica
nsDS5ReplicaId: 1
nsDS5ReplicaRoot: dc=id,dc=polytechnique,dc=edu
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=RepliX,cn=config
nsds5ReplicaPurgeDelay: 604800
nsds5ReplicaTombstonePurgeInterval: 86400
nsds5ReplicaLegacyConsumer: False
nsDS5ReplicaType: 3
nsState:: AQDCrc5XAQABAA==
nsDS5ReplicaName: eeb6d304-736c11e6-9bc5a1ff-40280b8e
nsds5ReplicaChangeCount: 114948
nsds5replicareapactive: 0


Typical replication agreement:

cn=Replication from ldap-lab. to ldap-adm.name>,cn=replica,cn=dc\\3Did\\2Cdc\\3Dpolytechnique\\2Cdc\\3Dedu,cn=mapping 
tree,cn=config

objectClass: top
objectClass: nsDS5ReplicationAgreement
cn: Replication from ldap-lab. to ldap-adm.
description: Replication agreement from server ldap-lab. 
to server ldap-adm.

nsDS5ReplicaHost: ldap-adm.
nsDS5ReplicaRoot: dc=id,dc=polytechnique,dc=edu
nsDS5ReplicaPort: 636
nsDS5ReplicaTransportInfo: SSL
nsDS5ReplicaBindDN: cn=RepliX,cn=config
nsDS5ReplicaBindMethod: simple
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE entryusn memberOf
nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn
nsds5ReplicaStripAttrs: modifiersName modifyTimestamp 
internalModifiersName internalModifyTimestamp internalCreatorsname

nsds5replicaBusyWaitTime: 5
nsds5ReplicaFlowControlPause: 500
nsds5ReplicaFlowControlWindow: 1000
nsds5replicaTimeout: 120
nsDS5ReplicaCredentials: {AES-...
nsds50ruv: {replicageneration} 57cd73770002
nsds50ruv: {replica 2 ldap://ldap-adm.:389}
nsruvReplicaLastModified: {replica 2 ldap://ldap-adm.name>:389} 

nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 20160906115520Z
nsds5replicaLastUpdateEnd: 20160906115520Z
nsds5replicaChangesSentSinceStartup: 3:13525/670 1:3671/0 2:1/0
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: 
Incremental update succeeded

nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 1970010100Z
nsds5replicaLastInitEnd: 1970010100Z



Next, is it possible to get the access and error logs for a
period of an hour from all servers (you can send them off list) ?
I would like to track some of the reported csns.

Sure, i will send it to you off list in a moment.

Thank you,

Regards,
Andrey



Regards,
Ludwig


On 09/06/2016 12:31 PM, Ivanov Andrey (M.) wrote:

Hi,

We are successfully using the compiled 1.3.4 git branch of
389DS in production on CentOS 7 since about a year
(approximately 40 000 entries, about 4000 groups, hundreds of
reads and tens of writes per second).
Our current topology c

[389-users] Re: 389DS v1.3.4.x after fixes for tickets 48766 and 48954

[Ludwig Krispenz]

On 09/06/2016 02:02 PM, Ivanov Andrey (M.) wrote:

Hi Ludwig,






the fixes for the tickets you mention did change the iteration
thru the changelog and how it handles situtations when the start
csn is not found in the changelog. and it also did change the
logging, so you might see messages now which were not there or
hidden before. 


That was my understanding too.
so far I have not seen any replication problems related to these 
messages, all generatedcsns seem to be replicated. What makes it a bit 
more difficult is that most of the updates are updates of lastlogintime 
and the original MOD is not logged. I still do not understand why we 
have these messages so frequently, I will try to reproduce.
Or, if it possible, could you run the servers for just an hour with 
replication logging enabled ?


When looking into the provided data set I did notice three replicated 
ops with err=50, insufficient access. This should not happen and 
requires a separate investigation



But I am very surprised to see them so frequently and I would like
to understand it.
First some questions, do you have changelog trimming enabled and
how, do you have fractional replication ?

yes for both questions.

Trimming: 14 days
Fractional replication:
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE entryusn memberOf
nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn
nsds5ReplicaStripAttrs: modifiersName modifyTimestamp 
internalModifiersName internalModifyTimestamp internalCreatorsname


Changelog:
cn=changelog5,cn=config
objectClass: top
objectClass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /Local/dirsrv/var/lib/dirsrv/slapd-ens/changelogdb
nsslapd-changelogmaxage: 14d


replica:
cn=replica,cn=dc\\3Did\\2Cdc\\3Dpolytechnique\\2Cdc\\3Dedu,cn=mapping 
tree,cn=config

objectClass: top
objectClass: nsDS5Replica
cn: replica
nsDS5ReplicaId: 1
nsDS5ReplicaRoot: dc=id,dc=polytechnique,dc=edu
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=RepliX,cn=config
nsds5ReplicaPurgeDelay: 604800
nsds5ReplicaTombstonePurgeInterval: 86400
nsds5ReplicaLegacyConsumer: False
nsDS5ReplicaType: 3
nsState:: AQDCrc5XAQABAA==
nsDS5ReplicaName: eeb6d304-736c11e6-9bc5a1ff-40280b8e
nsds5ReplicaChangeCount: 114948
nsds5replicareapactive: 0


Typical replication agreement:

cn=Replication from ldap-lab. to ldap-adm.name>,cn=replica,cn=dc\\3Did\\2Cdc\\3Dpolytechnique\\2Cdc\\3Dedu,cn=mapping 
tree,cn=config

objectClass: top
objectClass: nsDS5ReplicationAgreement
cn: Replication from ldap-lab. to ldap-adm.
description: Replication agreement from server ldap-lab. 
to server ldap-adm.

nsDS5ReplicaHost: ldap-adm.
nsDS5ReplicaRoot: dc=id,dc=polytechnique,dc=edu
nsDS5ReplicaPort: 636
nsDS5ReplicaTransportInfo: SSL
nsDS5ReplicaBindDN: cn=RepliX,cn=config
nsDS5ReplicaBindMethod: simple
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE entryusn memberOf
nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn
nsds5ReplicaStripAttrs: modifiersName modifyTimestamp 
internalModifiersName internalModifyTimestamp internalCreatorsname

nsds5replicaBusyWaitTime: 5
nsds5ReplicaFlowControlPause: 500
nsds5ReplicaFlowControlWindow: 1000
nsds5replicaTimeout: 120
nsDS5ReplicaCredentials: {AES-...
nsds50ruv: {replicageneration} 57cd73770002
nsds50ruv: {replica 2 ldap://ldap-adm.:389}
nsruvReplicaLastModified: {replica 2 ldap://ldap-adm.name>:389} 

nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 20160906115520Z
nsds5replicaLastUpdateEnd: 20160906115520Z
nsds5replicaChangesSentSinceStartup: 3:13525/670 1:3671/0 2:1/0
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: 
Incremental update succeeded

nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 1970010100Z
nsds5replicaLastInitEnd: 1970010100Z



Next, is it possible to get the access and error logs for a period
of an hour from all servers (you can send them off list) ? I would
like to track some of the reported csns.

Sure, i will send it to you off list in a moment.

Thank you,

Regards,
Andrey



Regards,
Ludwig


On 09/06/2016 12:31 PM, Ivanov Andrey (M.) wrote:

Hi,

We are successfully using the compiled 1.3.4 git branch of
389DS in production on CentOS 7 since about a year
(approximately 40 000 entries, about 4000 groups, hundreds of
reads and tens of writes per second).
Our current topology consists of 3 servers in triangle (each
server is a master replicating to 2 others, so two read-write
replication agreements on each).

Since the fixes for the Ticket 48766 ("Replication changelog
can incorrectly skip over updates") and Ticket 48954
("Replication fails because anchorcsn cannot be found") I’ve
started to see the following 

[389-users] Re: 389DS v1.3.4.x after fixes for tickets 48766 and 48954

[Ludwig Krispenz]

On 09/06/2016 02:02 PM, Ivanov Andrey (M.) wrote:

Hi Ludwig,






the fixes for the tickets you mention did change the iteration
thru the changelog and how it handles situtations when the start
csn is not found in the changelog. and it also did change the
logging, so you might see messages now which were not there or
hidden before. 


That was my understanding too.


But I am very surprised to see them so frequently and I would like
to understand it.
First some questions, do you have changelog trimming enabled and
how, do you have fractional replication ?

yes for both questions.

Trimming: 14 days
Fractional replication:
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE entryusn memberOf
nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn
nsds5ReplicaStripAttrs: modifiersName modifyTimestamp 
internalModifiersName internalModifyTimestamp internalCreatorsname


Changelog:
cn=changelog5,cn=config
objectClass: top
objectClass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /Local/dirsrv/var/lib/dirsrv/slapd-ens/changelogdb
nsslapd-changelogmaxage: 14d


replica:
cn=replica,cn=dc\\3Did\\2Cdc\\3Dpolytechnique\\2Cdc\\3Dedu,cn=mapping 
tree,cn=config

objectClass: top
objectClass: nsDS5Replica
cn: replica
nsDS5ReplicaId: 1
nsDS5ReplicaRoot: dc=id,dc=polytechnique,dc=edu
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=RepliX,cn=config
nsds5ReplicaPurgeDelay: 604800
nsds5ReplicaTombstonePurgeInterval: 86400
nsds5ReplicaLegacyConsumer: False
nsDS5ReplicaType: 3
nsState:: AQDCrc5XAQABAA==
nsDS5ReplicaName: eeb6d304-736c11e6-9bc5a1ff-40280b8e
nsds5ReplicaChangeCount: 114948
nsds5replicareapactive: 0


Typical replication agreement:

cn=Replication from ldap-lab. to ldap-adm.name>,cn=replica,cn=dc\\3Did\\2Cdc\\3Dpolytechnique\\2Cdc\\3Dedu,cn=mapping 
tree,cn=config

objectClass: top
objectClass: nsDS5ReplicationAgreement
cn: Replication from ldap-lab. to ldap-adm.
description: Replication agreement from server ldap-lab. 
to server ldap-adm.

nsDS5ReplicaHost: ldap-adm.
nsDS5ReplicaRoot: dc=id,dc=polytechnique,dc=edu
nsDS5ReplicaPort: 636
nsDS5ReplicaTransportInfo: SSL
nsDS5ReplicaBindDN: cn=RepliX,cn=config
nsDS5ReplicaBindMethod: simple
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE entryusn memberOf
nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn
nsds5ReplicaStripAttrs: modifiersName modifyTimestamp 
internalModifiersName internalModifyTimestamp internalCreatorsname

nsds5replicaBusyWaitTime: 5
nsds5ReplicaFlowControlPause: 500
nsds5ReplicaFlowControlWindow: 1000
nsds5replicaTimeout: 120
nsDS5ReplicaCredentials: {AES-...
nsds50ruv: {replicageneration} 57cd73770002
nsds50ruv: {replica 2 ldap://ldap-adm.:389}
nsruvReplicaLastModified: {replica 2 ldap://ldap-adm.name>:389} 

nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 20160906115520Z
nsds5replicaLastUpdateEnd: 20160906115520Z
nsds5replicaChangesSentSinceStartup: 3:13525/670 1:3671/0 2:1/0
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: 
Incremental update succeeded

nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 1970010100Z
nsds5replicaLastInitEnd: 1970010100Z



Next, is it possible to get the access and error logs for a period
of an hour from all servers (you can send them off list) ? I would
like to track some of the reported csns.

Sure, i will send it to you off list in a moment.
Thanks, I will look into it, given the size it may take some time, and 
then will come back to you


Thank you,

Regards,
Andrey



Regards,
Ludwig


On 09/06/2016 12:31 PM, Ivanov Andrey (M.) wrote:

Hi,

We are successfully using the compiled 1.3.4 git branch of
389DS in production on CentOS 7 since about a year
(approximately 40 000 entries, about 4000 groups, hundreds of
reads and tens of writes per second).
Our current topology consists of 3 servers in triangle (each
server is a master replicating to 2 others, so two read-write
replication agreements on each).

Since the fixes for the Ticket 48766 ("Replication changelog
can incorrectly skip over updates") and Ticket 48954
("Replication fails because anchorcsn cannot be found") I’ve
started to see the following regular warnings in error logs:

[06/Sep/2016:01:21:43 +0200] clcache_load_buffer_bulk -
changelog record with csn (57cdfe0600010001) not found for
DB_NEXT
[06/Sep/2016:01:21:43 +0200] agmt="cn=Replication from
ldap-adm. to ldap-lab." (ldap-lab:636) - Can't
locate CSN 57cdfe0600010001 in the changelog (DB
rc=-30988). If replication stops, the consumer may need to be
reinitialized.
[06/Sep/2016:02:35:25 +0200] - 

[389-users] Re: 389DS v1.3.4.x after fixes for tickets 48766 and 48954

[Ludwig Krispenz]

Hi,

the fixes for the tickets you mention did change the iteration thru the 
changelog and how it handles situtations when the start csn is not found 
in the changelog. and it also did change the logging, so you might see 
messages now which were not there or hidden before.
But I am very surprised to see them so frequently and I would like to 
understand it.
First some questions, do you have changelog trimming enabled and how, do 
you have fractional replication ?
Next, is it possible to get the access and error logs for a period of an 
hour from all servers (you can send them off list) ? I would like to 
track some of the reported csns.


Regards,
Ludwig


On 09/06/2016 12:31 PM, Ivanov Andrey (M.) wrote:

Hi,

We are successfully using the compiled 1.3.4 git branch of 389DS in 
production on CentOS 7 since about a year (approximately 40 000 
entries, about 4000 groups, hundreds of reads and tens of writes per 
second).
Our current topology consists of 3 servers in triangle (each server is 
a master replicating to 2 others, so two read-write replication 
agreements on each).


Since the fixes for the Ticket 48766 ("Replication changelog can 
incorrectly skip over updates") and Ticket 48954 ("Replication fails 
because anchorcsn cannot be found") I’ve started to see the following 
regular warnings in error logs:


[06/Sep/2016:01:21:43 +0200] clcache_load_buffer_bulk - changelog 
record with csn (57cdfe0600010001) not found for DB_NEXT
[06/Sep/2016:01:21:43 +0200] agmt="cn=Replication from 
ldap-adm. to ldap-lab." (ldap-lab:636) - Can't locate 
CSN 57cdfe0600010001 in the changelog (DB rc=-30988). If 
replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:02:35:25 +0200] - replica_generate_next_csn: 
opcsn=57ce0f4e00050002 <= basecsn=57ce0f4e00050003, adjusted 
opcsn=57ce0f4e00060002
[06/Sep/2016:04:10:11 +0200] clcache_load_buffer_bulk - changelog 
record with csn (57ce257e00040003) not found for DB_NEXT
[06/Sep/2016:05:16:58 +0200] - replica_generate_next_csn: 
opcsn=57ce352b0002 <= basecsn=57ce352b00010001, adjusted 
opcsn=57ce352b00010002
[06/Sep/2016:06:56:04 +0200] agmt="cn=Replication from 
ldap-adm. to ldap-ens." (ldap-ens:636) - Can't locate 
CSN 57ce4c6200010003 in the changelog (DB rc=-30988). If 
replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:07:29:00 +0200] agmt="cn=Replication from 
ldap-adm. to ldap-ens." (ldap-ens:636) - Can't locate 
CSN 57ce541a00020003 in the changelog (DB rc=-30988). If 
replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:07:34:20 +0200] agmt="cn=Replication from 
ldap-adm. to ldap-lab." (ldap-lab:636) - Can't locate 
CSN 57ce555900010001 in the changelog (DB rc=-30988). If 
replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:07:34:27 +0200] agmt="cn=Replication from 
ldap-adm. to ldap-lab." (ldap-lab:636) - Can't locate 
CSN 57ce55610001 in the changelog (DB rc=-30988). If 
replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:07:40:17 +0200] clcache_load_buffer_bulk - changelog 
record with csn (57ce56c50003) not found for DB_NEXT
[06/Sep/2016:07:40:24 +0200] clcache_load_buffer_bulk - changelog 
record with csn (57ce56c500010003) not found for DB_NEXT
[06/Sep/2016:08:08:36 +0200] clcache_load_buffer_bulk - changelog 
record with csn (57ce5d5f000f0001) not found for DB_NEXT
[06/Sep/2016:08:12:39 +0200] clcache_load_buffer_bulk - changelog 
record with csn (57ce5e5400020003) not found for DB_NEXT
[06/Sep/2016:08:12:39 +0200] agmt="cn=Replication from 
ldap-adm. to ldap-ens." (ldap-ens:636) - Can't locate 
CSN 57ce5e5400020003 in the changelog (DB rc=-30988). If 
replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:08:26:45 +0200] clcache_load_buffer_bulk - changelog 
record with csn (57ce61a300020003) not found for DB_NEXT
[06/Sep/2016:08:27:40 +0200] clcache_load_buffer_bulk - changelog 
record with csn (57ce61d800020003) not found for DB_NEXT
[06/Sep/2016:08:27:40 +0200] agmt="cn=Replication from 
ldap-adm. to ldap-ens." (ldap-ens:636) - Can't locate 
CSN 57ce61d800020003 in the changelog (DB rc=-30988). If 
replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:08:31:42 +0200] clcache_load_buffer_bulk - changelog 
record with csn (57ce62c800030001) not found for DB_NEXT
[06/Sep/2016:08:34:05 +0200] clcache_load_buffer_bulk - changelog 
record with csn (57ce635a00010001) not found for DB_NEXT
[06/Sep/2016:08:44:28 +0200] clcache_load_buffer_bulk - changelog 
record with csn (57ce65c900020003) not found for DB_NEXT
[06/Sep/2016:08:52:25 +0200] agmt="cn=Replication from 
ldap-adm. to ldap-ens." (ldap-ens:636) - Can't locate 
CSN 57ce67aa00010003 in the changelog (DB rc=-30988). If 
replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:08:53:04 +0200] - replica_generate_next_csn: 

[389-users] Re: Operational attributes

[Ludwig Krispenz]

On 07/27/2016 03:35 PM, Mark Reynolds wrote:


On 07/27/2016 09:28 AM, Mitja Mihelič wrote:

Hi!

We have an application, that does not honour the shadowExpire
attribute. It does however use a search filter to find users. The idea
is, that we would extend the search filter to include an additional
attribute. We would then set this attribute to 0 or 1 and the filter
would NOT return users that have it set to 0. Missing or set to 1 and
the user gets returned.

The search filters themselves do not provide any advanced comparisons
like: if (shadowExpire =< today) then...
Operation attributes seem to provide some more flexibility there. We
could solve the problem if we could set up an operational attribute
that would do
if (shadowExpire =< today) then
   return 0
else
   return 1

Hi Mitja,

If I am understanding you correctly, then there is no such thing.  There
are no "attributes" that do any kind of "calculation".  Operational
attributes are attributes internal to the server, and these attribute
are not returned to the client by default.  That is there only special
quality.

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Examples-of-common-ldapsearches.html#searching-for-operational-attr

It sounds like you need some type of custom plugin to do this
calculation for you.
there is something like computed attributes, but it requires a plugin to 
provide a compute function and the it can also register a search filter 
rewriter, see:


https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Plug-in_Guide/Plugin_Programming_Guide-Function_Reference-Functions_for_Managing_Computed_Attributes.html

But I think it is not widely used and requires some experimentation


Regards,
Mark



Is it possible to add one's own operational attributes to 389DS? If it
is, how should it be done the right way?

Kind regards,
Mitja

--
Mitja Mihelič
ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia
tel: +386 1 479 8800, fax: +386 1 479 88 99
--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Schemas, filters, attributes and values

[Ludwig Krispenz]

On 07/06/2016 02:12 PM, Mitja Mihelič wrote:

Hi!

We would like to connect our services to 389DS. Each user would have 
an attribute that would determine their quota for each service.
We have a registered space within the OID tree for our organization 
and the attributes would go there.
For for the quota attribute I was thinking multivalue. Something like 
(numbers and names are arbitrary):

userQuota:
  mail:500
  ftp:20
  webapp1:30
  webapp2:35
The service would request the attribute and then parse out its own 
value. All nice and good for our in-house apps.


There is a problem, when a service like dovecot expects the value to 
be a number. Then, as we tested, the multivalue idea does not work.


Is there a way to use the filters so a query returns only the number 
(500 from mail:500)?
which attribute does dovecat request ? if it requests userQuota you 
would have to return all values, and if you strip the qualifier and only 
return (500,20,30,35) how would the app know what is what ?
and if you write a plugin to return a single value, how would it know to 
return the number for mail and not ftp ?


I think the closet you could get is using tags:
userQuota;mail: 500
userQuota; ftp: 20
userQuota;webapp1: 30
userQuota;webapp2: 35


Could it be done with 389DS plugins?

Kind regards,

--
Mitja Mihelič
ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia
tel: +386 1 479 8800, fax: +386 1 479 88 99
--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org 



--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander
--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: ACI value selector?

[Ludwig Krispenz]

On 04/27/2016 01:00 AM, William Brown wrote:

On Tue, 2016-04-26 at 12:30 +0200, Simon Oscarsson wrote:

Hi,

I wonder if there is an ACI statement that allows to filter the response on
attribute values. OpenLDAP has something called ACI value selector (for
example "attrs=memberof val.childern='ou=Dummy,dc=test,dc=org'" that will
only return attribute values for 'memberof' having a value being part of
the subtree 'ou=Dummy,dc=test,dc=org' and filter away other memberof
values). There is an 'targattrfiltes' statement in 389 DS, but that only
applies on 'add' or 'delete' operations (would like to have one for 'read')

Unless I am misunderstanding your question,
yes, he wants additional access control by the value of the attr like we 
support it with targattrfilters for add/del of values. We don't have it 
for search.
targattrfilters was introduced with a specific use case in mind, like 
allowing users to assign roles to themselve, but restrict from specific 
roles.

It was not generalized for all operation types.

Simon,
if you need this feature you can open an RFE, but it might take some 
time (versions) until it would be available.


Ludwig


you can use targetattr = "attr" to control read access to an attribute. IE:

(targetAttr = "uid" || "gid")(version3.0; acl "Read access to uid and gid"; allow (read, 
search) userdn="ldap:///anyone;)





--
389-users mailing list
389-users@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael 
O'Neill

--
389-users mailing list
389-users@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Change users password using horde's module passwd

[Ludwig Krispenz]

Hi,
I was not talking about access control, but about password policy - 
quality of passwords, reuse, expiration, when it can be changed ...

Please read:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/User_Account_Management.html#User_Account_Management-Managing_the_Password_Policy


On 04/12/2016 12:35 PM, wodel youchi wrote:

Hi, and thanks

But as I understand, there is and AC created for 
ou=people,dc=example,dc=com called "Allow self entry modification" and 
userPassword attribute is selected for write.

is there another AC that supersedes this one?

Regards.

2016-04-12 11:19 GMT+01:00 Ludwig Krispenz <lkris...@redhat.com 
<mailto:lkris...@redhat.com>>:



On 04/12/2016 11:50 AM, wodel youchi wrote:

Hi,

I am trying to make horde's module passwd let users change their
passwords.

In the configuration file of the moduke there are two options for
ldap :

- ldap : this option uses the users credentials to modify the
password (the user change his password with his credentials).

- ldapadmin : this option uses the admin, such as the Directory
Manager to modify the user's password.

the first one, didn't work for me, I get in the horde log : could
not replace userPassword attribute, LDAP server : constraint
violation.

the second one worked.

In the error log of 389DS, I didn't find any useful error message.

PS : tls is enabled.


any idea?

changing th pw as user, you probably violate the password policy




Regards.


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


-- 
Red Hat GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn,

Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, 
Michael O'Neill


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


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael 
O'Neill

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Change users password using horde's module passwd

[Ludwig Krispenz]

On 04/12/2016 11:50 AM, wodel youchi wrote:

Hi,

I am trying to make horde's module passwd let users change their 
passwords.


In the configuration file of the moduke there are two options for ldap :

- ldap : this option uses the users credentials to modify the password 
(the user change his password with his credentials).


- ldapadmin : this option uses the admin, such as the Directory 
Manager to modify the user's password.


the first one, didn't work for me, I get in the horde log : could not 
replace userPassword attribute, LDAP server : constraint violation.


the second one worked.

In the error log of 389DS, I didn't find any useful error message.

PS : tls is enabled.


any idea?

changing th pw as user, you probably violate the password policy




Regards.


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael 
O'Neill

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Default values for attributes when creating new users

[Ludwig Krispenz]

On 04/06/2016 08:30 AM, wodel youchi wrote:

Hi,

is it possible to configure 389DS to give some attributes default values?

We're migrating from openLDAP to 389DS, which will be used to 
authenticate mail users, we want to give for example *mailQuota* a 
default value for new accounts.
in 389ds you have the COS ("class of service") mechanism to assign 
default values to attributes in many ways, please check:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Advanced_Entry_Management-Assigning_Class_of_Service.html


is this possible?


Regards.


--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael 
O'Neill

--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Replication critical problem

[Ludwig Krispenz]

On 03/22/2016 03:34 PM, Dael Maselli wrote:
Our authentication and authorization infrastructure is based on 3 
multi-master server and 2 slaves with 35 databases each, all have the 
following version of 389:


389-ds-1.2.2-1.el6.noarch
389-ds-base-1.2.11.15-60.el6.x86_64
389-ds-base-libs-1.2.11.15-60.el6.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-dsgw-1.1.11-1.el6.x86_64

We are experiencing a strange behavior, replication of new attributes, 
new values of attributes and modification of values are propagated 
correctly, but deleting a value of attribute are propagated randomly, 
no matter of what master starts the modification or what database we 
modify, big or little ones.

did the problem just start recently or have you just noticed it ?
what do you mean by propagated randomly ? sometimes or always but 
different on different replicas ?


can you give an example of an entry which is the same on all servers and 
how it looks like after the del of an value ?


I tried reinitializing database from one master but the problem 
persists, no errors are logged.


Now our server are not synchronized and this is, as you can imagine, 
very bad ;-)


Thank you very much!

Regards,
   Dael Maselli.




--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael 
O'Neill
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: NSACLPlugin warning/error

[Ludwig Krispenz]

On 03/03/2016 07:18 PM, ghiureai wrote:

Hi List,
I am seeing this warning/error in one of my LDAP log, ( version 1.2.11)

" NSACLPlugin - Can't find the acl in the tree for moddn 
operation:olddnuid=" I would like to know more details , is this 
related to  an aci  issue/missing etc?
this message is only logged if aci logging is enabled, in that case in 
many places aci code logs what it is doing.
For any modif yoperatiopn add/mod/del/modrdn the aci code checks if the 
aci cache or group cache is affected. For the given message it checks if 
the old dn is in the aci cache and would update it with the new dn. If 
the entry changed does not have an aci, it is not found and the message 
is logged.


Isabella
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael 
O'Neill
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: multimaster replication -preventing clients writes

[Ludwig Krispenz]

On 01/22/2016 04:09 PM, German Parente wrote:


- Original Message -

From: "William Brown" 
To: "General discussion list for the 389 Directory server project." 
<389-users@lists.fedoraproject.org>
Sent: Friday, January 22, 2016 4:28:57 AM
Subject: [389-users] Re: multimaster replication -preventing clients writes

On Thu, 2016-01-21 at 22:50 -0200, carne_de_passaro wrote:

Hi, I don't know if it will perform well but, you can create an ACI
on the
top of the tree and negate writes for all, except the master 2 IP.


The aci will replicate because this is MMR.


Yes, but it will be evaluated as false only in master 2.
So, master 2 will allow writes while in master 1, they will be forbidden.
the ip address in the ip aci rule defines and uses the client ip 
address, so it can control "from" where it is writable.


But I agree it could be nicer to have a read only replica.


  

Hi List,
I would like to know if there is a cfg option in a multimaster
replication
( 2 servers both accept read-writes) to prevent users/clients
application
writes to one of the master   without affecting the replication
agreements.
my env 389-ds 1.3.4.4
Thank you
Isabella

You are actually asking for a read only replica ... if a rw master
accepts no writes, it's a read only. If it accepts no writes it has
nothing to transmit back to the other master  you want a read only
replica.


Otherwise, if you want rw masters, there is no reason to limit yourself
to writes only on one master. That's the point of the replication
protocol, to remove the point of failures in write targets.


--
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] Re: Weird issue with searching cn=config

[Ludwig Krispenz]

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 > 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
>
 nmonitoring.html>.
> The ldapsearch command works fine!!!
>
> Below is the log from a server where this runs fine.
>
> [18/Jan/2016:07:09:19 +] conn=420951 fd=564 slot=564 connection
> from
> ::1 to ::1
> [18/Jan/2016:07:09:19 +] conn=420951 op=0 BIND dn="" method=128
> version=3
> [18/Jan/2016:07:09:19 +] conn=420951 op=0 RESULT err=0 tag=97
> nentries=0 etime=0 dn=""
> [18/Jan/2016:07:09:19 +] conn=420951 op=1 SRCH base="cn=config"
> scope=2
> filter="(objectClass=nsds5replicationagreement)"
> attrs="nsDS5ReplicaHost
> nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart
> nsds5replicaLastUpdateEnd"
> [18/Jan/2016:07:09:19 +] conn=420951 op=1 RESULT err=0 tag=101
> nentries=3 etime=0
> [18/Jan/2016:07:09:19 +] conn=420951 op=2 UNBIND
> [18/Jan/2016:07:09:19 +] 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 +] conn=226 fd=80 slot=80 connection from
> ::1 to
> ::1
> [18/Jan/2016:07:05:20 +] conn=226 op=0 BIND dn="" method=128
> version=3
> [18/Jan/2016:07:05:20 +] conn=226 op=0 RESULT err=0 tag=97
> nentries=0
> etime=0 dn=""
> [18/Jan/2016:07:05:20 +] conn=226 op=1 SRCH base="cn=config"
> scope=2
> filter="(objectClass=nsds5replicationagreement)"
> attrs="nsDS5ReplicaHost
> nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart
> nsds5replicaLastUpdateEnd"
> [18/Jan/2016:07:05:20 +] conn=226 op=1 RESULT err=0 tag=101
> nentries=0
> etime=0
> [18/Jan/2016:07:05:20 +] conn=226 op=2 UNBIND
> [18/Jan/2016:07:05:20 +] 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

[389-users] Re: Weird issue with searching cn=config

[Ludwig Krispenz]

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 <lkris...@redhat.com
<mailto:lkris...@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-/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 <lkris...@redhat.com
 <mailto:lkris...@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
 <wibr...@redhat.com <mailto:wibr...@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
 >
  

[389-users] Re: Weird issue with searching cn=config

[Ludwig Krispenz]

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-/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 <lkris...@redhat.com 
<mailto:lkris...@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 <wibr...@redhat.com
<mailto:wibr...@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 +] conn=420951 fd=564 slot=564
connection
> from
> ::1 to ::1
> [18/Jan/2016:07:09:19 +] conn=420951 op=0 BIND dn=""
method=128
> version=3
> [18/Jan/2016:07:09:19 +] conn=420951 op=0 RESULT err=0
tag=97
> nentries=0 etime=0 dn=""
> [18/Jan/2016:07:09:19 +] conn=420951 op=1 SRCH
base="cn=config"
> scope=2
> filter="(objectClass=nsds5replicationagreement)"
> attrs="nsDS5ReplicaHost
> nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart
> nsds5replicaLastUpdateEnd"
> [18/Jan/2016:07:09:19 +] conn=420951 op=1 RESULT err=0
tag=101
> nentries=3 etime=

[389-users] Re: multimaster replication and index corruption

[Ludwig Krispenz]

On 11/24/2015 06:11 PM, Rich Megginson wrote:

On 11/24/2015 10:02 AM, ghiureai wrote:



Rich and the List Thank for your  continue support,

We are still  seeing a index issues with memberof plugging, we  are 
not sure at this point if this is related to our software or the 
plugin cfg  behavior, I see 2 entries files.db4 for memberof plugin  
see bellow, is this correct?
the 389-admin GUI shows only the memberof indexed, when I try to 
check for index corruption and run


-rw--- 1 ldap-ds ldap-ds   4005888 Oct 20 13:01 memberOf.db4
--rw--- 1 ldap-ds ldap-ds   3915776 Nov 23 07:58 memberof.db4


That's very bad.  I thought we fixed that case issue with db files a 
long time ago.




when I try to check for index values and use either  memberof  or 
memberOf files for the following attribute fails, what I am missing?



   dbscan -f /var/lib/dirsrv/slapd-ldap/db/userRoot/memberof.db4
  -k "dc=xxx,dc=com"
  Can't find key 'dc=xxx,dc=com'



Not sure.  Try doing dbscan -f 
/var/lib/dirsrv/slapd-ldap/db/userRoot/memberof.db4 first, to see what 
the keys look like
I think all the keys have a prefix indicating presence, substr or 
equality, so it should ne more likely "=dc=xxx,dc=com"




same for


  memberOf.db4 file







Thank you
Isabella

On 11/10/2015 11:12 AM, ghiureai wrote:

Rich, thank you for all support  for last day , unfortunately there is a
strong wave in developers team:" the multimaster replication is creating
issues with UI"  ( I do not  totally agree since  can not  be reproduce+
full describe the issues).
Is been decided to moved down to master slave,  please I need to know if
I still need to  exclude member of plugin from replication in this case ?



Thanks a lot
Isabella
   On 11/10/2015 09:23 AM, Rich Megginson wrote:

On 11/10/2015 10:14 AM, Adrian Damian wrote:

Rich,

Thanks for your help. Let me jump in with more details.

We've seen index corruption on a number of occasions. It seems to
affect searchable attributes for which there are indexes. Queries on
an attribute in LDAP that used to work suddenly stopped working. They
would return incomplete results and no results at all, although the
data on the server was the same. The fix on those situations was to
drop the index corresponding to the attribute and re-create it.

So in this case, you have some sort of LDAP search client, and you are
doing a search for '(indexed_attribute=known_value)' and you are not
seeing a result, and this is what you mean by "index corruption"?

Are you aware of the dbscan tool?
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/dbscan.html

This tool allows you to examine the index file in the database directly.

dbscan -f
/var/lib/dirsrv/slapd-instance_name/db/userRoot/indexed_attribute.db4 -k
known_value

This will allow you to look at the indexed_attribute index directly for
the value "known_value".


We've run the db fix script that the LDAP distribution comes with

What db fix script?  Do you have a link to it, or a link to the product
documentation for the script?


and there are no reports of corruption when this problem occurs. That
makes it very hard to detect. We don't know what else to look for when
we run into this again and more importantly, we don't know what
triggers it and how to prevent it.

Mind you we are currently doing active development changing both the
software clients that access the LDAP servers as well as the
configurations of the servers. It is possible to had been written to
both masters in the master replication configuration when the problem
occurred but because there were multiple clients concurrently
accessing the servers it is hard to figure out what triggered the issue.


Adrian



On 11/09/2015 05:06 PM, Rich Megginson wrote:

On 11/09/2015 05:47 PM, Ghiurea, Isabella wrote:

Hi Rich,
Thank you for your feedback , as always greatly appreciate when
comes from  389-DS RH support.
We are  not using vm just plain hardware, here is the description
I  got from developers team related to the issues they are seeing
when running   integration tests with multimaster replication :
"index corruption: put content, run tests: OK, do more stuff (reads,
writes, etc), ru tests: FAIL, notice "missing attributes", rebuild
index(ices), run tests: OK. "

What does this mean?  What program is printing these index corruption
messages?  Is it some tool provided by Red Hat?


Unfortunately, I understood  this cases/issue can not be reproduce
on regular basis,  no mode details can be provide at this time

All reads and writes are going to  only the master replication DS,
not slave .
  I totally agree with your this is the way to cfg and maintain
Directory  Server in a operation critical  env: multmaster
replication only one master for writes.
 Here is the DS version:
 rpm -qa | grep 389-ds
389-ds-console-doc-1.2.6-1.el6.noarch
389-ds-base-libs-1.2.11.15-34.el6_5.x86_64

Re: [389-users] uid case sensitivity

[Ludwig Krispenz]

On 10/12/2015 05:42 PM, Rich Megginson wrote:

On 10/09/2015 12:33 AM, Juan Ramón Moral wrote:

Hi,

is it possible to change config to make uid case insensitive?

this search return no entries.
ldapsearch -x -D "uid=*U*ser01,cn=users,dc=XXX,dc=XXX" -w XXX -s base 
-b "cn=users,dc=XXX,dc=XXX"

ldap_bind: No such object (32)
matched DN: cn=users,dc=ujaen,dc=es

but this return one entry
ldapsearch -x -D "uid=*u*ser01,cn=users,dc=XXX,dc=XXX" -w XXX -s base 
-b "cn=users,dc=XXX,dc=XXX"

...
# numEntries: 1

In my case, what I want is both searches returning the exact same record.

in 00core.ldif
attributeTypes: ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' )
  EQUALITY *caseIgnore*Match
  SUBSTR caseIgnoreSubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  X-ORIGIN 'RFC 4519'
  X-DEPRECATED 'userid' )

Using 389-ds-base-1.3.3.1-20.el7_1 in centos 7.


This sounds like a bug.  It should already be case insensitive. Please 
file a ticket at https://fedorahosted.org/389/newticket
I just tried and it is case insensitive, Also the err=32 refers to the 
bind dn and DNs are case insesnsitive, so I thin something else is going on





Regards
--



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] performance Q with ldapsearch

[Ludwig Krispenz]

On 09/11/2015 04:58 AM, Rich Megginson wrote:

On 09/10/2015 04:00 PM, ghiureai wrote:

Hi Gurus,
we are seening some performance issues when running ldapsearch with 
tree ou=Groups, ou=ds , dc=abc, dc=net takes longer than when looking 
for same user but from one level up of tree up aka :ou=ds, 
dc=abc,dc=net, the difference in time very high , any idea why we 
seeing this ?
Also we are seeing time exec diff when running from same levele of 
DS( under ou=ds) but  different ou's  ?


Can you provide:
rpm -q 389-ds-base
exact ldapsearch command lines
and the access log for the searches and how many entries are in th 
especific subtrees




Isabella
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Restict master-master replication

[Ludwig Krispenz]

On 08/10/2015 11:54 AM, German Parente wrote:

Hi Vinay,

you could add an aci to deny replication user from doing delete operations on the whole 
replicated suffix. But note this aci will be by user and not by host.

If not, you could also restrict the aci by ip address of primary node to 
achieve exactly what you want to do.
this will not work, acis are not evaluated again in a replication 
session, only on the master the op was seen first.


But, all the effort we do in replication is to make the databases 
consistent on master and replica, you are asking explicitely to make it 
inconsistent, this should not be supported. the only exception is 
fractional replication.


Regards,

German.


- Original Message -

From: vinay garg vinay.g...@fosteringlinux.com
To: 389-users@lists.fedoraproject.org
Sent: Monday, August 10, 2015 10:57:07 AM
Subject: [389-users]  Restict master-master replication

hi list,

we have multi-master settup
1. Primary master
2. Secondary Master

HOw can we apply restriction on Primary master that primary master can
replicaiton only modify, add on secondary master. But Primary master dont
have permission to delete replication data on secondary master.

Any idea how to restrict From Primary Master to Secondary master

--
Regards
Vinay Garg
Keen  Able Comp. Pvt. ltd.
9990770734

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] 389-DS poor performance retrieving groups

[Ludwig Krispenz]

On 08/04/2015 08:32 PM, Mark Reynolds wrote:



On 08/04/2015 12:53 PM, German Parente wrote:


- Original Message -

From: Mark Reynolds marey...@redhat.com
To: General discussion list for the 389 Directory server project. 
389-users@lists.fedoraproject.org

Sent: Tuesday, August 4, 2015 6:04:17 PM
Subject: Re: [389-users] 389-DS poor performance retrieving groups



On 08/04/2015 11:57 AM, ghiureai wrote:



We are seeing poor performance from LDAP retrieving 2500-4500 
entries compare
with one of our regular RDBMS , here is bellow the result for a 
ldapsearch.
We are questioning if for general cn=(.*..) search string , LDAP has 
to run a

round trip for each subset result entry ?

What cfg needs tuned to see some performance improvements beside 
cache mem

size ?
There isn't any, besides indexing, and by default cn is indexed for 
substring

searches.

Can you provide the output from the access log during one of these 
searches?



Seems that by default, substring indexing is done on lenght 3.

But * counts as part of the key (*mt, mt*), so it should be indexed
no, * is the wildcard separating initial,any,final parts of the 
substring filter, the only exception from the 3 char is start and and of 
string (^MT),(MT$)


So, probably the keys with lenght 2 will provoke this search to be 
unindexed.





ldapsearch -x -s one -H -b 'ou=Groups,ou=ds,dc=cxxx,dc=net' -W -D
'uid=xx,ou=Users,ou=ds,dc=cxxxr,dc=net' 'cn=*MT*' 'cn, nsaccountlock'
# search result
search: 2
result: 0 Success

# numResponses: 2608
# numEntries: 2607

real 0m19.284s
user 0m0.040s
sys 0m0.052s


--
389 users mailing list 389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] _cl5CompactDBs: failed to compact

[Ludwig Krispenz]

On 06/19/2015 03:25 PM, Rich Megginson wrote:

On 06/19/2015 04:29 AM, Ivanov Andrey (M.) wrote:

Hi Noriko,




There are three MMR replicating servers. It's one month of
uptime and the servers wanted to trim the replication log.
Here is what i've found in error log on each of them :

1st server:
[18/Jun/2015:08:04:31 +0200] - libdb: BDB2055 Lock table is
out of available lock entries

May not matter, but could you please try increasing the value of
this db config parameter?  The default value is 1.

dn: cn=config,cn=ldbm database,cn=plugins,cn=config
nsslapd-db-locks: 1

Ok. I've increased nsslapd-db-locks to 2 and reduced 
nsslapd-changelogcompactdb-interval to 3600 in 
cn=changelog5,cn=config to see the changelog free event more 
frequently. No change. I have still :


[19/Jun/2015:10:36:46 +0200] - libdb: BDB2055 Lock table is out of 
available lock entries
[19/Jun/2015:10:36:46 +0200] NSMMReplicationPlugin - changelog 
program - _cl5CompactDBs: failed to compact 
a45fa684-f28d11e4-af27aa63-5121b7ef; db error - 12 Cannot allocate memory




[18/Jun/2015:08:04:31 +0200] NSMMReplicationPlugin -
changelog program - _cl5CompactDBs: failed to compact
a45fa684-f28d11e4-af27aa63-5121b7ef; db error - 12 Cannot
allocate memory

I don't thing there is any problem even if the DBs are not
compacted.  It was introduced just to release the free pages in
the db files.  But I'd also like to learn why the compact fails
with ENOMEM here.

Ok, thanks.


I'm guessing that bdb returns ENOMEM when it runs out of locks.

I think the only remedy is to just keep increasing the number of locks 
until this error goes away.  I don't know how to estimate how many 
locks are required ahead of time.
I think compact can be consuming many locks, maybe for each of the pages 
in the cldb, and then there is this bug: 
https://fedorahosted.org/389/ticket/47934

did you verify that your changes have been effective ? try the db_stat:
db_stat -c -h /var/lib/dirsrv/slapd-INSTANCE/db/ | grep locks







--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] multimaster replication one host offline

[Ludwig Krispenz]

On 04/27/2015 12:59 AM, William wrote:

On Fri, 2015-04-24 at 12:50 -0700, ghiureai wrote:

Hi  List,
I have cfg LDAP multimaster replication, one of the hosts will be
offline for some days, do I need to disable the replication agreement
completely at this point? (what will be the minimum cfg)
What are  the steps to resync the master after is  been brought online ?
Thank you
Isabella


I think that removing the replication agreement is the best course of
action.

Say you have A - B, and you plan to disable B.

You would disable the replication agreement of B - A first, then A - B

Then when you reactivate B, you would add the replication agreement for
A - B, with the attribute nsds5beginreplicarefresh: start

Then once complete, you would re-add B - A.
you can avoid the reinitialization if you ensure that the changelog is 
not purged too much, if the server is down for somedays set 
nsds5replicapurgedelay: somedays+1,
when the other server is coming online replication should catch up 
(disabling and reenabling should be enough)


Sincerely,



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] LDAP allows null bases

[Ludwig Krispenz]

On 03/11/2015 03:04 PM, Rob Crittenden wrote:

Ludwig Krispenz wrote:

Hi,

in my opinion this is not a security issue, but a feature compliant to
the ldap rfcs. A server should expose a minimal set of information about
itself, eg supported controls, saslmechanisms, namingcontexts even to
anonymous users - and many applications rely on this.
If you really want to turn this off, you need to modify the aci for the
dn: entry

He might also want to look at nsslapd-allow-anonymous-access to disable
all anonymous access to the server. I agree that being able to read the
rootDSE probably isn't a big deal.

In RFC 4513 it explicitely states:

LDAP servers SHOULD allow all clients --
   even those with an anonymous authorization -- to retrieve the
   'supportedSASLMechanisms' attribute of the root DSE both before and
   after the SASL authentication exchange.  The purpose of the latter is
   to allow the client to detect possible downgrade attacks (see Section
   6.4 and [RFC4422], Section 6.1.2).




rob


Ludwig

On 03/11/2015 11:23 AM, Kay Cee wrote:

All clients connecting to our 389-ds server showed up this
vulnerability on the scan. How do I fix this on my 389-ds server?

LDAP allows null bases

Risk:High
Application:ldap
Port:389
Protocol:tcp
ScriptID:10722
Summary:
It is possible to disclose LDAP information.
Description :
Improperly configured LDAP servers will allow the directory BASE to be
set to NULL. This allows information to be culled without any prior
knowledge of the directory structure. Coupled with a NULL BIND, an
anonymous user can query your LDAP server using a tool such as
'LdapMiner'

Solution:
Disable NULL BASE queries on your LDAP server
CVSS Base Score : 5.0
Family name: Remote file access
Category: infos
Copyright: Copyright (C) 2000 John lampej_la...@bellsouth.net
mailto:lampej_la...@bellsouth.net
Summary: Check for LDAP null base
Version: $Revision: 128 $



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] LDAP allows null bases

[Ludwig Krispenz]

Hi,

in my opinion this is not a security issue, but a feature compliant to 
the ldap rfcs. A server should expose a minimal set of information about 
itself, eg supported controls, saslmechanisms, namingcontexts even to 
anonymous users - and many applications rely on this.
If you really want to turn this off, you need to modify the aci for the 
dn: entry


Ludwig

On 03/11/2015 11:23 AM, Kay Cee wrote:
All clients connecting to our 389-ds server showed up this 
vulnerability on the scan. How do I fix this on my 389-ds server?


LDAP allows null bases

Risk:High
Application:ldap
Port:389
Protocol:tcp
ScriptID:10722
Summary:
It is possible to disclose LDAP information.
Description :
Improperly configured LDAP servers will allow the directory BASE to be 
set to NULL. This allows information to be culled without any prior 
knowledge of the directory structure. Coupled with a NULL BIND, an 
anonymous user can query your LDAP server using a tool such as 
'LdapMiner'


Solution:
Disable NULL BASE queries on your LDAP server
CVSS Base Score : 5.0
Family name: Remote file access
Category: infos
Copyright: Copyright (C) 2000 John lampej_la...@bellsouth.net 
mailto:lampej_la...@bellsouth.net

Summary: Check for LDAP null base
Version: $Revision: 128 $



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Increase in search time operation in 1.2.11 vs 1.2.5

[Ludwig Krispenz]

Hi,

I don't know what has changed since 1.2.5, but aci caching always was a 
difficult area, it tends to cache results of aci evaluation, but there 
have been cases where this was incorrect, so  the different behaviour 
could be teh effect of some bug fixing. but this is speculation,. we 
would need to get all your acis and then verify if handling is correct 
or not.

If you want to do this, please open a ticket and provide all necessary data

Ludwig

On 11/26/2014 01:04 PM, Bartek wrote:

I manage to come across the following piece of code (aci.c):

/* get the acl */
acl_info[0] = '\0';
if (acl_reason-deciding_aci) {
if (acl_reason-reason == ACL_REASON_RESULT_CACHED_DENY ||
acl_reason-reason == ACL_REASON_RESULT_CACHED_ALLOW) {
/* acl is in cache. Its detail must have been printed before.
* So no need to print out acl detail this time.
*/
PR_snprintf( acl_info[0], BUFSIZ, %s by aci(%d),
access_reason,
acl_reason-deciding_aci-aci_index);
}
else {
PR_snprintf( acl_info[0], BUFSIZ, %s by aci(%d): aciname=%s, 
acidn=\%s\,

access_reason,
acl_reason-deciding_aci-aci_index,
acl_reason-deciding_aci-aclName,
slapi_sdn_get_ndn (acl_reason-deciding_aci-aci_sdn) );
}
}

Looking at logs i've posted formely it seems to me that aci's are not 
cached hence cached allow by aci(7) entries in logs. According to 
the code above if they were cached there would be an cached 
context/parent allow in log (ACL_REASON_RESULT_CACHED_ALLOW would 
evaluate to true).


I dug through documentation but still there's no trace of a property 
in cn=config etc i'm missing that would fix that.


2014-11-24 23:07 GMT+01:00 Rich Megginson rmegg...@redhat.com 
mailto:rmegg...@redhat.com:


On 11/24/2014 08:19 AM, Bartek wrote:

Hello
I have an use case where particular search operations on the same
data in 1.2.5 and 1.2.11 differ significantly.
1.2.5 is on Centos 5.9 and 1.2.11 on Centos 5.11. I'm asking this
as i'm in the middle of upgrade process and I come across this
performance issue.

After feeding both versions with data from the same text dump,
particular search operation takes 0.5s in 1.2.5 to complete
whereas in 1.2.11 it takes 6s:

ldapsearch -D 'uid=root,ou=users,o=xxx' -x -b
'uid=someuser,dc=domain,dc=pl,o=xxx' -s subtree -w pass
'(objectClass=someObjectClass)'

There is a set of 40 acls at the dc=pl,o=xxx node and 9 more on
dc=domain,dc=pl,o=xxx. The acl allowing 'uid=root,ou=users,o=xxx'
to access everything is at o=xxx.

I did already manage to figure out that the more acis i remove
the shorter the search operation is. However even with those aci
in place, search on 1.2.5 returns significantly faster.

I would like to ask if there are any factors that would make
search operations longer while jumping from 1.2.5 to 1.2.11?


Not that I know of.

You can rule out acis as the source of the performance issue by
using -D cn=directory manager as the bind dn.

Use logconv.pl http://logconv.pl to analyze your access logs for
common problems.



-- 
Regards

Bartek


--
389 users mailing list
389-users@lists.fedoraproject.org  
mailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
mailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] add user aci problem

[Ludwig Krispenz]

On 11/13/2014 03:49 PM, Rich Megginson wrote:

On 11/13/2014 07:26 AM, Mark Reynolds wrote:


On 11/13/2014 07:22 AM, Alberto Viana wrote:

Mark,

It works, but when I do a ldapserch to this entry, it shows me that:

passwordAdminDN:: C9cq90J/

Is the expected behavior?

Hi Alberto,

Yeah this is a known bug (the value is being base64 encoded), but the 
feature should still work correctly though.


Regards,
Mark


What is the value supposed to be?  A human readable DN?

$ python
 import base64
 base64.b64decode('C9cq90J/')
'\x0b\xd7*\xf7B\x7f'

That doesn't look like a DN - it looks like random bytes.

looks like: https://fedorahosted.org/389/ticket/47952




I put a group on it. In 389-console show even more strange 
characters  :)


Thanks

On Mon, Nov 10, 2014 at 5:10 PM, Mark Reynolds marey...@redhat.com 
mailto:marey...@redhat.com wrote:



On 11/10/2014 12:22 PM, Alberto Viana wrote:

389-Directory/1.3.2.17 http://1.3.2.17 B2014.182.124


I'm trying to add an user (whitout using the manager, with a
regular user):

Without any aci:

ldap_add: Insufficient access (50)
additional info: Insufficient 'add' privilege to the
'userPassword' attribute


My aci:

dn: ou=test,dc=my,dc=domain
changetype: modify
add: aci
aci: (targetattr = *) (target =
ldap:///test,dc=my,dc=domain;) (version 3.0;acl POP-AL write
permission;allow (all) (userdn =
ldap:///uid=my_user,ou=app,dc=my,dc=domain;);)

Also tried without target with same result.

ldap_add: Constraint violation (19)
additional info: invalid password syntax - passwords with
storage scheme are not allowed

Hi Alberto

Only a Password Administrator or the root dn(cn=directory
manager) can add prehashed passwords.  Please see this doc for
more info:

http://www.port389.org/docs/389ds/design/password-administrator.html

Regards,
Mark



I have an older server 389-Directory/1.3.2.17 http://1.3.2.17
B2014.182.124, and this works fine.
What am I missing in the newer version? Or is that a bug?

Thanks

Alberto Viana



--
389 users mailing list
389-users@lists.fedoraproject.org  
mailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] replicate_now script help

[Ludwig Krispenz]

ok, so there are two questions
- why doesn't the script work
- is th escript necesseray

To see why the script isn't working, could you provide the full script 
and commandline of your latest attempt


I think the doc is not fully correct. If a consumer is taken offline the 
supplier can no longer reach it and will try in increasing intervals, up 
to 5 mins, but in my understanding it should retry every 5 mins. If the 
cinsumer comes online the supplier does not know about this, and so it 
could be up to 5 mins until the next retry. If you really want immediate 
respons from the supplier the the suplier has to be notified eg by this 
script.
But if the consumer has been offline for some time it could probaly be 
acceptable to wait the 5 extra mins


Ludwig

On 11/13/2014 05:09 PM, ghiureai wrote:




As per RHES doc:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Forcing_Replication_Updates.html#Forcing_Replication_Updates-Forcing_Replication_Updates_from_the_Command_Line

Even if the replication agreements are configured to keep the 
supplier and consumer servers always in sync, it is not sufficient to 
bring back up-to-date a server that has been offline for over five 
minutes. The *Always Keep in Sync* option means that the server 
generates a replication operation for every update operation it 
processes. However, if this replication operation cannot be performed 
because the consumer is offline, the operation times out after 10 
minutes.

11.15.2. Forcing Replication Updates from the Command Line
From the consumer that requires updating, run a script that prompts 
the supplier to send replication updates immediately. This script is 
shown in Example 11.5, “replicate_now Script Example” 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Forcing_Replication_Updates.html#ex.Replicate_Now_Script_Example. 

Copy this example script and name it something like 
|replicate_now.sh|. Substitute the actual values for the variables 
listed in Example 11.5, “replicate_now Script Example” 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Forcing_Replication_Updates.html#ex.Replicate_Now_Script_Example. 



*NOTE*

This script must be run manually since it cannot be configured to run 
automatically as soon as the server, which was offline, comes back 
online again.''






On 11/12/2014 09:54 AM, ghiureai wrote:

Hi LIst,
I'm new to 389-ds  admin , I have cfg a multimaster replication 
system , and read the RHES -DS documentation  find the replicate_now 
script which is suppose to trigger master rep updates  10 min, the 
script fails , there is no option for -1 in ldapsearch ...etc
Wodner if any of you have an update script , I 'm running 389-ds on 
CentoS 6.5 .


Thank you
Isabella





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] replicate_now script help

[Ludwig Krispenz]

Hi,
On 11/13/2014 05:57 PM, ghiureai wrote:


 Hi Ludwing,
Glad to hear some things make sense, the doc says 10 min to wait until 
in sync data, I can't afford  wasting time  if there are  24 hours 
logs to be applied to slave and users are connecting right away.


Bellow  is my script, I done some changes as per Rich advise.

my OS :
 Linux el6.x86_64 #1 SMP Thu Nov 21 13:35:52 CST 2013 x86_64 x86_64 
x86_64 GNU/Linu

 running from host2,
:scripts$ ./replicate_now.sh
 ./replicate_now.sh
+ SUP_HOST=host1.org.com
+ SUP_PORT=636
+ SUP_MGRPW=passwd
+ MY_HOST=host2.org.com
+ MY_PORT=636
+ export SUP_HOST SUP_PORT SUP_MGRDN SUP_MGRPW MY_HOST MY_PORT
+ ldapsearch -x -LLL -h proc5-01.cadc.dao.nrc.ca -p 636 -D 
'cn=directory manager' -w 04sirnea -b 'cn=mapping tree,cn=config'
did you edit the output of the script ? the listing of the variables and 
the use in ldapsearch doesn't match eg host1.org.com  
proc5-01.cadc.dao.nrc.ca


and in the script itself, is it a copy and paste issue or do you have 
the continuation char '\' at the new line instead of at the end of the 
line to be continued, the +ldapsearch output seems truncated


*
Here is my script:
#!/bin/sh -x
SUP_HOST=host1.org.com
SUP_PORT=636
#SUP_MGRDN=cn=directory manager
SUP_MGRPW=passwd
MY_HOST=host2.org.com
MY_PORT=636
export SUP_HOST SUP_PORT SUP_MGRDN SUP_MGRPW MY_HOST MY_PORT

ldapsearch -x -LLL -h ${SUP_HOST} -p ${SUP_PORT} -D cn=directory 
manager \

 -w ${SUP_MGRPW} -b cn=mapping tree,cn=config
\((objectclass=nsds5replicationagreement)(nsDS5ReplicaHost=${MY_HOST})
 \(nsDS5ReplicaPort=${MY_PORT})) dn nsds5ReplicaUpdateSchedule 
|perl -p0e 's/\n //g'  /tmp/$$


cat /tmp/$$ |awk 'BEGIN { s = 0 }/^dn: / { print $0;print changetype: 
modify;print
 replace: nsds5ReplicaUpdateSchedule;print 
nsds5ReplicaUpdateSchedule: -2359

 0123456;print -;print ;print $0;print changetype: modify;
 print replace:nsds5ReplicaUpdateSchedule;}

/^nsds5ReplicaUpdateSchedule: / { s = 1; print $0; }/^$/{if ( $s == 1 
){ print - ;
 print ; }else{ print nsds5ReplicaUpdateSchedule: -2359 
0123456;print - ;

 print ; };s = 0; }

'  /tmp/ldif.$$echo Ldif is in /tmp/ldif.$$echo

ldapmodify -x -c -h ${SUP_HOST} -p ${SUP_PORT} -D ${SUP_MGRDN} \-w 
${SUP_MGRPW}

 -f /tmp/ldif.$$



On 11/12/2014 09:54 AM, ghiureai wrote:

Hi LIst,
I'm new to 389-ds  admin , I have cfg a multimaster replication 
system , and read the RHES -DS documentation  find the replicate_now 
script which is suppose to trigger master rep updates  10 min, the 
script fails , there is no option for -1 in ldapsearch ...etc
Wodner if any of you have an update script , I 'm running 389-ds on 
CentoS 6.5 .


Thank you
Isabella





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Proper handling of No original_tombstone for changenumber errors

[Ludwig Krispenz]

On 09/29/2014 11:15 PM, Anthony Messina wrote:

Thanks, Ludwig.  I will open a ticket.  Can you elaborate on whether or not
this is a logging issue, or actually an issue with my replication/changelog,
etc.  As I said, I'm concerned about the flakiness of 389 DS prior to the
upgrade to FreeIPA 4.
This is just an additional message, which can become annoying, but it 
does not influence the path of execution (no return code chenaged, 
branch,..), so the effective behaviour should be as before.


-A

On Monday, September 29, 2014 02:24:08 PM Ludwig Krispenz wrote:

Hi,

I think the message was introduced when tombstone handling was partly
rewritten to fix some bugs and improve entry cache management.
It is logged if a delete transaction has to be retried and no tombstone
entry is found. In the normal case this should not happen, but looks
like this is in the retro changelog during changelog trimming and for
the changelog a delete does not create a tombstone.
In my opinion there should be an additional check before logging this
message.

Can you open a ticket ?

Thanks,
Ludwig

On 09/29/2014 11:56 AM, Anthony Messina wrote:

Using two fully updated FreeIPA F20 masters with freeipa-
server-3.3.5-1.fc20.x86_64 and 389-ds-base-1.3.2.23-1.fc20.x86_64, I've
noticed that I'm getting a lot of the following errors in the 389 DS error
log, especially at server startup.

No original_tombstone for changenumber=511851,cn=changelog!!

Most often, the same changenumber repeats over and over, but there are
some
other changenumbers listed as well.  The changenumbers are different on
each master.

My concern is I'm preparing my thought process about the upcoming upgrade
from F20 to F21 and it looks like I may need to create a new FreeIPA
master and migrate the Dogtag stuff, etc. rather than a simple yum
upgrade on each master.  Yuck!

What is the proper way to correct for these apparent errors and get these
masters working with each other in a clean manner?



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Attribute with Boolean issue

[Ludwig Krispenz]

On 09/02/2014 06:36 PM, Chase Miller wrote:

userPasswordNeverExpires: false

ds checks boolean values according to the RFC:

/* Per RFC4517:
 *
 * Boolean =  TRUE / FALSE
 */

and it does a case sensitive match.



On Tue, Sep 2, 2014 at 9:57 AM, Rob Crittenden rcrit...@redhat.com 
mailto:rcrit...@redhat.com wrote:


Chase Miller wrote:
 Hello,

 I have an old fedora directory server, and I'm migrating it to a new
 server, and on the new server, I have installed the latest version.

 I had a custom attribute with a Boolean data type in the old
one, and
 now, when I try to ldif import into the new server, I receive an
error
 value #0 invalid per syntax

 However, I changed the data type to Directory String, and it
imports.

 Thoughts?

More strict syntax checking has been implemented which is probably the
issue.

I think the only legal values are TRUE and FALSE. What is it
blowing up on?

rob

--
389 users mailing list
389-users@lists.fedoraproject.org
mailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Back up of database for desaster recovery

[Ludwig Krispenz]

there was an answer the same day you asked, if it doesn't work let us 
know what issues you have.


On 08/19/2014 01:27 PM, Alberto Suárez wrote:

Any answer?

Regards,

Alberto Suárez

On 14/08/14 09:56, Alberto Suárez wrote:

Hello:

I would like to make a valid copy of the LDAP data so that I could 
restore it in another 389 installation in case of a crash. ¿What is 
the best way? I have tried the 389 commands but came across with issues.


Thank you.

Alberto Suárez
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] cfg archiving transactions log

[Ludwig Krispenz]

for the the location of the __db* files you need to configure: 
nsslapd-db-home-directory


Ludwig

On 08/13/2014 09:33 PM, Ghiurea, Isabella wrote:

_
*From: *Ghiurea, Isabella
*Sent: *August-13-14 12:13 PM
*To: *89-us...@lists.fedoraproject.org
*Subject: *cfg archiving transactions log
Hi List,
I'm trying to cfg db archive transaction logs, I create a new dir for 
log files, cp the old log.* and restart the server , the log .*file is 
there in the new dir BUT
in /var/lib/dirsrv/slapd-ldap/db threre are still active a series  of 
files :_db.* , I removed all  this files prior restarting the service 
but they got create it in the default location.

What do I miss ?
Thank you
Isabella


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] db2bak.pl issuess

[Ludwig Krispenz]

On 08/13/2014 09:03 PM, Ghiurea, Isabella wrote:

Thank you !  that works only with cn=directory manager

It works only with the DN configured as: nsslapd-rootdn



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Removing entries with invalid DN syntax

[Ludwig Krispenz]

On 06/27/2014 10:16 AM, Audun Røe wrote:
This works for me as well. However, when added with (what I assume to 
be) proper escaping in the first place like in this case, the entries 
also appear with visible escaping when browsing the directory. The 
problematic entries don't.


I also can't add more entries of the latter type, as the server 
responds with 34 - syntax error, just like when attempting to delete 
the ones that are already there. In any case, I guess I'll just go for 
the big hammer, re-import and be done with it :)

did you try with quotes:
ldapmodify .
dn: ou=myproblematicentry,suffix
changetype: delete

if that doesn't work, I'm afraid export/import is the last resort



-Audun


On Thu, Jun 26, 2014 at 4:58 PM, Ludwig Krispenz lkris...@redhat.com 
mailto:lkris...@redhat.com wrote:


Hi,
This works for me:
more inv.txt

dn: ou=ny\group\mmm,dc=redhat,dc=com
changetype: add
objectclass: organizationalunit

 ldapmodify -x -h localhost -p 1390 -D cn=directory manager -w
secret12 -f inv.txt
adding new entry ou=ny\group\mmm,dc=redhat,dc=com

[ludwig@elkris ~]$ ldapdelete -x -h localhost -p 1390 -D
cn=directory manager -w secret12
ou=ny\group\mmm,dc=redhat,dc=com


[26/Jun/2014:16:53:26 +0200] conn=9 op=1 ADD
dn=ou=ny\3Cgroup\3Emmm,dc=redhat,dc=com
[26/Jun/2014:16:53:27 +0200] conn=9 op=1 RESULT err=0 tag=105
nentries=0 etime=1
[
[26/Jun/2014:16:54:23 +0200] conn=10 op=1 DEL
dn=ou=ny\3Cgroup\3Emmm,dc=redhat,dc=com
[26/Jun/2014:16:54:26 +0200] conn=10 op=1 RESULT err=0 tag=107
nentries=0 etime=3



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Removing entries with invalid DN syntax

[Ludwig Krispenz]

Hi,
This works for me:
more inv.txt

dn: ou=ny\group\mmm,dc=redhat,dc=com
changetype: add
objectclass: organizationalunit

 ldapmodify -x -h localhost -p 1390 -D cn=directory manager -w 
secret12 -f inv.txt

adding new entry ou=ny\group\mmm,dc=redhat,dc=com

[ludwig@elkris ~]$ ldapdelete -x -h localhost -p 1390 -D cn=directory 
manager -w secret12

ou=ny\group\mmm,dc=redhat,dc=com


[26/Jun/2014:16:53:26 +0200] conn=9 op=1 ADD 
dn=ou=ny\3Cgroup\3Emmm,dc=redhat,dc=com
[26/Jun/2014:16:53:27 +0200] conn=9 op=1 RESULT err=0 tag=105 nentries=0 
etime=1

[
[26/Jun/2014:16:54:23 +0200] conn=10 op=1 DEL 
dn=ou=ny\3Cgroup\3Emmm,dc=redhat,dc=com
[26/Jun/2014:16:54:26 +0200] conn=10 op=1 RESULT err=0 tag=107 
nentries=0 etime=3


On 06/26/2014 04:21 PM, Audun Røe wrote:

Rich, thanks for the suggestions.

I tested setting both nsslapd-dn-validate-strict 
and nsslapd-syntaxcheck to off, but no luck. Finally had a go at 
disabling cn=Distinguished Name Syntax,cn=plugins,cn=config entirely 
(nsslapd-pluginEnabled: off) but the server wouldn't start at all with 
this gone. Can't see any other attributes in dse.ldif that seem to apply.


-Audun


On Thu, Jun 26, 2014 at 4:01 PM, Rich Megginson rmegg...@redhat.com 
mailto:rmegg...@redhat.com wrote:


On 06/26/2014 07:59 AM, Rich Megginson wrote:

On 06/26/2014 07:50 AM, Audun Røe wrote:

Hello,

I'm trying to delete some problematic entries from our 389
directory. The entry DNs contain  and  (probably found their
way into the directory years ago). This causes problems with
JNDI where DNs from search results are fed directly back into
more searches because these particular DNs are somehow returned
in in escaped form. E.g.
ou=myproblematicentry,dc=example,dc=com becomes
ou=my\problematic\entry,dc=example,dc=com, causing error 32.
I'm not sure if it's the directory server or JNDI adding the
escaping, as ldapsearch from the command line doesn't seem to
behave this way, but it doesn't really matter: I want to remove
the entries and get rid of the issue. Unfortunately, I'm unable to:

$ ldapdelete -D cn=directory manager -WxH
ldap://example.com:389 http://example.com:389
ou=myproblematicentry,dc=example,dc=com
Enter LDAP Password:
ldap_delete: Invalid DN syntax (34)
additional info: DN value invalid per syntax

I've also tried deleting through Apache Directory Studio, error
34 there as well.

So, any ideas on how to get rid of them? The only thing I can
think of is to db2ldif the entire directory, manually excise the
entries from the LDIF file and then re-import. But I'd rather
not take this step unless there's no other way.


You could try disabling syntax checking - nsslapd-syntaxcheck


Sorry - disable DN syntax checking - I believe that may be
different than regular syntax checking





-Audun


--
389 users mailing list
389-users@lists.fedoraproject.org  
mailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users




--
389 users mailing list
389-users@lists.fedoraproject.org  
mailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
mailto:389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Replication Supplier DN permission denied

[Ludwig Krispenz]

On 05/27/2014 04:46 PM, DuWayne Holsbeck wrote:

I can not seem to get a read-only replica setup, I have tried every setup
for setting up the supplier DN, but I always get

NSMMReplicationPlugin conn=6 op=11 replica=my dnUnable to acquire replica:
error: permission denied

any pointers would be greatly appreciated.

Version 1.3.1.9-0ubuntu2

Supplier DN

dn: cn=replication manager,cn=config
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword:: XXX
passwordExpirationTime: 20380119031407Z

Am I missing attributes, or permisions?
Check the nsds5Replica entry on your consumer if you have configured 
cn=repl ... as bind DN


Cheers
DuWayne


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Multiple Users Same UID

[Ludwig Krispenz]

https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/Using_the_Attribute_Uniqueness_Plug_in.html

On 05/13/2014 09:42 PM, John Trump wrote:
If I create posix users and manually assign uid's 389-ds will allow me 
to assign the same uid to multiple users. If I do not manually assign 
uid's, the uid's will be incremented and not duplicate uid's. Is there 
a check / rule that canbe applied to prevent duplicate uid's when 
assigning uid's manually?



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Replication hell - picking apart info/warning/error messages

[Ludwig Krispenz]

A generation ID is  an id generated when the backend is created or when 
data from an ldif (without generation id) is imported. So when setting 
up an environment all servers have a different generation ID, to make 
replication work you need to choose one server and initialize all 
otheres from this server - either by an online total init or by 
exporting data to an ldif *with* replication meta data and import this 
to the other servers.


Ludwig

On 05/04/2014 04:32 PM, Graham Leggett wrote:

On 04 May 2014, at 3:16 PM, Graham Leggett minf...@sharp.fm wrote:


- Replica has a different generation ID than the local data. - what does this 
mean? Is it simply information to be ignored, a warning to be heeded (if so, how?), or an 
error (if so, what action must be taken?).

Picking apart the source code, I find the following code implementing the above message, 
the code would suggest the message is an error, and that the error is fatal:

   case EXAMINE_RUV_GENERATION_MISMATCH:
   slapi_log_error(SLAPI_LOG_FATAL, repl_plugin_name,
   %s: Replica has a different generation ID than the local 
data.\n,
   agmt_get_long_name(prp-agmt));
   next_state = STATE_BACKOFF_START;
   break;

Does anyone know what a generation ID is in the context of two replicas, what it means, 
what it does? Is the admin in any way involved in the choosing of this generation ID?

Why would this generation ID be significant when nsds5BeginReplicaRefresh has been set 
to start and the expectation is that server C will be blown away anyway?

Regards,
Graham
--

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Serious write-performance problems on RHEL6

[Ludwig Krispenz]

In the phase with high cpu usage, could you run
a) top -H -p pid
to see if there are many threads competing for the cpu or one or two 
occupying the cpu

b) pstack pid
to see what the threads are doing, sometimes pstack for the complete 
process doesn't look meaningful, you can also run pstack tpid where 
tpid is one of the threads consuming the cpu


You are on a VM with 2cpus, what is the real HW, there have been 
problems with RHDS on machines with Numa architecture if the threads of 
teh process have been distributed to different nodes. What was the HW 
for SunDS ?


Ludwig

On 03/31/2014 05:34 PM, Steve Holden wrote:

Hi, folks

I'm hoping to use 389 DS to replace our ancient Sun DS 5.2 service.

I've hit a snag with my 389 development server; it's performance far worse
than the 10 year-old servers it's intended to replace.

Things looked promising: the old directory data has been imported (with
only minor changes), read requests perform reasonably well, and isolated
write requests are ok.

However, even after a small number (typically 6) of consecutive write requests
(basic attribute changes to a single entry, say) the ns-slapd process hits 100%
CPU (of 2 CPUs) and stays there for *at least* 10 seconds per update, and blocks
the client process attempting the update.

I can't see anything obvious in the performance counters or the logs to suggest
a problem. The updates are logged with etime=0 in the access log.

I've tried enabling different log levels in the error log.
Is it normal for the Plugin level to show constant re-scanning of CoS templates?

I'd be very grateful for any suggestions of how I can go about tracing where the
Problem might be and how to resolve it...

Best wishes,
Steve


Details

The RHEL6.5 server is a VMware ESXi VM with 8GB RAM and 2x CPUs,
and is running the latest EPEL package for RHEL6 (v1.2.11.15-32).
(After a package upgrade a few weeks ago, I ran setup-ds-admin.pl -u).

The directory contains in excess of 200,000 entries, and
its databases consume over 3.5GB on disk.

The userRoot database has therefore been configured with a 4GB cache
(and the general LDBM max cache is set at 6GB - though it's quite possible
I haven't understood how to set these correctly - I've tried smaller numbers of 
each).

The directory contains custom attributes, some of which are CoS,
and many of which have been indexed (AFAIK, all attributes have been 
re-indexed).

No replication has been configured so far.

___
This email has been scanned by MessageLabs' Email Security
System on behalf of the University of Brighton.
For more information see http://www.brighton.ac.uk/is/spam/
___
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Serious write-performance problems on RHEL6

[Ludwig Krispenz]

Hi,

looks like the cos plugin is busy with internal searches, maybe these 
are unidexed. Could you turn on logging for internal searches in the cos 
plugin to see what kind of searches are performed: 
http://directory.fedoraproject.org/wiki/Plugin_Logging


Ludwig

On 04/01/2014 12:52 PM, Steve Holden wrote:

Hi, Ludwig

Thanks for taking the time to reply.

I'm using this simple LDIF import file to generate the problem:
http://pastebin.com/NyNY650L
It generally hangs around the 7th record, and the complete import takes 2m32s!


Parent pid from /var/run/dirsrv/slapd-algieba.pid is 10382, and 'top -H' for it 
shows:

# top -H -p 10382

top - 11:45:02 up 5 days, 22:27,  9 users,  load average: 0.87, 0.35, 0.24
Tasks:  41 total,   1 running,  40 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.8%us,  0.2%sy,  0.0%ni, 97.6%id,  0.4%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8060964k total,  7886612k used,   174352k free,   215412k buffers
Swap:  6291448k total,11584k used,  6279864k free,  2588264k cached

   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
10892 dirsrv20   0 11.9g 6.1g 1.9g R 99.7 79.1  46:19.78 ns-slapd
10881 dirsrv20   0 11.9g 6.1g 1.9g S  2.0 79.1  40:58.88 ns-slapd
...


Standard top output:

top - 11:29:09 up 5 days, 22:11,  9 users,  load average: 0.35, 0.14, 0.16
Tasks: 219 total,   1 running, 218 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.8%us,  0.2%sy,  0.0%ni, 97.6%id,  0.4%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8060964k total,  7887052k used,   173912k free,   215412k buffers
Swap:  6291448k total,11584k used,  6279864k free,  2587968k cached

   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
10382 dirsrv20   0 11.9g 6.1g 1.9g S 100.3 79.1  83:23.85 ns-slapd
25216 root  20   0 15168 1184  824 R  2.0  0.0   0:00.01 top


Output from pstack is here: http://pastebin.com/8LpfbdCb

I'm curious about the number of CoS lines, which I've highlighted.
I mention this as enabling Plugins in the error log shows an incredible amount 
of CoS activity - and the LDIF import above doesn't include any CoS attributes.
I'll disable the CoS rules and see whether this helps...


Thanks for the note about hardware. Sounds like it doesn't apply here; details 
are:
VM hardware: Dell PowerEdge R710 2x quad core Xeon.
Production hardware: Sun Fire V240 (Sparc, 8G RAM).

Best wishes,
Steve

-Original Message-
From: 389-users-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of Ludwig Krispenz
Sent: 01 April 2014 08:33
To: 389-users@lists.fedoraproject.org
Subject: Re: [389-users] Serious write-performance problems on RHEL6

In the phase with high cpu usage, could you run
a) top -H -p pid
to see if there are many threads competing for the cpu or one or two
occupying the cpu
b) pstack pid
to see what the threads are doing, sometimes pstack for the complete
process doesn't look meaningful, you can also run pstack tpid where
tpid is one of the threads consuming the cpu

You are on a VM with 2cpus, what is the real HW, there have been
problems with RHDS on machines with Numa architecture if the threads of
teh process have been distributed to different nodes. What was the HW
for SunDS ?

Ludwig

On 03/31/2014 05:34 PM, Steve Holden wrote:

Hi, folks

I'm hoping to use 389 DS to replace our ancient Sun DS 5.2 service.

I've hit a snag with my 389 development server; it's performance far worse
than the 10 year-old servers it's intended to replace.

Things looked promising: the old directory data has been imported (with
only minor changes), read requests perform reasonably well, and isolated
write requests are ok.

However, even after a small number (typically 6) of consecutive write requests
(basic attribute changes to a single entry, say) the ns-slapd process hits 100%
CPU (of 2 CPUs) and stays there for *at least* 10 seconds per update, and blocks
the client process attempting the update.

I can't see anything obvious in the performance counters or the logs to suggest
a problem. The updates are logged with etime=0 in the access log.

I've tried enabling different log levels in the error log.
Is it normal for the Plugin level to show constant re-scanning of CoS templates?

I'd be very grateful for any suggestions of how I can go about tracing where the
Problem might be and how to resolve it...

Best wishes,
Steve


Details

The RHEL6.5 server is a VMware ESXi VM with 8GB RAM and 2x CPUs,
and is running the latest EPEL package for RHEL6 (v1.2.11.15-32).
(After a package upgrade a few weeks ago, I ran setup-ds-admin.pl -u).

The directory contains in excess of 200,000 entries, and
its databases consume over 3.5GB on disk.

The userRoot database has therefore been configured with a 4GB cache
(and the general LDBM max cache is set at 6GB - though it's quite possible
I haven't understood how to set these correctly - I've tried smaller numbers of 
each).

The directory contains custom attributes, some of which

Re: [389-users] Problem when trying to perform dereference searches

[Ludwig Krispenz]

Hi,

if you would specify the control as critical -E '!deref=' you would 
get an error the the deref attr needs to be of dn syntax. In 389 ds 
uniquemember is specified as Name and Optional UID syntax, which is dn 
[#UID], but the deref plugin just checks for dn syntax.


Feel free to open a ticket to get this fixed.

Ludwig

On 03/19/2014 09:10 PM, Jonathan Vaughn wrote:
We've had problems with SSSD being slow sometimes, but not others, and 
there never seemed to be any obvious cause why, but I think I've 
tracked it down to problems with dereferencing. We do see errors about 
dereferencing in the log, but I didn't realize until now what it was 
referring to.


In theory, a search like this should give us the cn and objectclass of 
all members of the group, but I get only the attributes of the group 
itself. Whether I give the -E 'deref=...' or not I get the same 
output. Redacted output below:


ldapsearch [bind username and password stuff, etc] -E 
'deref=uniqueMember:cn,objectclass' 'cn=Global System Administrators'

# extended LDIF
#
# LDAPv3
# base [our base DN] (default) with scope subtree
# filter: cn=Global System Administrators
# requesting: ALL
# with dereference control
#

# Global System Administrators, Groups, [our base DN]
dn: cn=Global System Administrators,ou=Groups,[our base DN]
control: 1.3.6.1.4.1.4203.666.5.16 false MIQA
uniqueMember: uid=user1,ou=Users,ou=[Office1],[our base DN]
uniqueMember: uid=user2,ou=Users,ou=[Office2],[our base DN]
uniqueMember: uid=user3,ou=Users,ou=[Office2],[our base DN]
uniqueMember: uid=user4,ou=Users,ou=[Office1],[our base DN]
objectClass: top
objectClass: groupofuniquenames
objectClass: posixgroup
cn: Global System Administrators
gidNumber: 1001002
description: Global System Administrators

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Some bind DNs sporadically can't search users

[Ludwig Krispenz]

On 03/03/2014 08:08 PM, Morgan Jones wrote:

On Mar 3, 2014, at 11:07 AM, Ludwig Krispenz lkris...@redhat.com wrote:


Hi,

so you say that a search with a specific bind user sometimes succeeds and 
sometimes doesn't ?

Correct.


If so, could you run this withe aci logging enabled ?

Sure though we are still unable to repeat the problem reliably so haven't 
caught it happening with aci debugging turned on.  I'm going to work on various 
scenarios to do so in our dev environment.


Are groups involved in the acis and do these groups during these runs ?

Yes, most of our ACIs use groups to determine access.  I'm not sure I 
understand the second part of your question though.
you can't, it was incomplete. I wanted to know if these groups are 
modified during the runs when you see the failure.

  I do suspect this has something to do with access control though as it's 
behaving exactly like the user is denied by the ACIs.


Could you post your acis ?

Probably.  I'm working on permission to do so.

thanks,

-morgan

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Some bind DNs sporadically can't search users

[Ludwig Krispenz]

Hi,

so you say that a search with a specific bind user sometimes succeeds 
and sometimes doesn't ?

If so, could you run this withe aci logging enabled ?
Are groups involved in the acis and do these groups during these runs ?
Could you post your acis ?

Ludwig

On 03/03/2014 04:56 PM, Morgan Jones wrote:

We're pulling our hair out over this issue and wondering if it rings a bell for 
anyone or perhaps there's a bug fix in a  later version of 389 that might 
resolve it.  I've looked and not found anything but it's also not the easiest 
issue to search for.  We are on CentOS DS now but can move to 389 of course but 
hesitate to put forth the effort if we aren't reasonably sure it will resolve 
our issue.

Certain bind DNs (so far only service accounts) are unable to search for users. 
 For instance:

[20/Feb/2014:10:18:05 -0500] conn=15600927 op=1 BIND 
dn=uid=copier,ou=employees,dc=domain,dc=org method=128 version=3
[20/Feb/2014:10:18:05 -0500] conn=15600927 op=1 RESULT err=0 tag=97 nentries=0 etime=0 
dn=uid=copier,ou=employees,dc=domain,dc=org
[20/Feb/2014:10:18:05 -0500] conn=15600927 op=2 SRCH base=ou=employees,dc=domain,dc=org scope=2 
filter=(uid=user1) attrs=cn mail uid
[20/Feb/2014:10:18:05 -0500] conn=15600927 op=2 RESULT err=0 tag=101 nentries=0 
etime=0

I did a search of the directory at the same time on the same replica as myself 
and other users with the same access level and was able to search uid=user1.

It sometimes only lasts a few minutes though in a few instances it was much 
longer.  In one case we resolved it by adding a service account with a 
different name but the same access level and moved the application to that 
account.  In another case where hundreds of copiers are configured with the 
binddn and thus changing the binddn wasn't practical we were able to resolve it 
by restoring the masters from a db2ldif and re-initializing the consumers. It's 
not isolated to once consumer--we've seen it on at least 2: one partial, one 
full.

Our environment is CentOS DS on CentOS 5.  We have ~35,000 entries in the 
directory, most of them users.  We only have 9 acis, most of which provide 
access via groups.  We have 2 multi-masters, 2 full consumers and until 
recently 2 partial replicas.  We converted the partial replicas to full 
replicas recently as we know there are/were issues with partial replication and 
wanted to rule that out.  We're at the latest version of CentOS DS:

[morgan@ldap01 ~]$ rpm -qa|grep centos-ds
centos-ds-admin-8.2.1-1.el5.centos
centos-ds-console-8.2.0-4.el5.centos
centos-ds-base-8.2.8-2.el5.centos
centos-ds-8.2.0-2.el5.centos
[morgan@ldap01 ~]$

This issue is killing us as it effectively denies access to a service for all 
users that use it.  This could be the VPN for instance which many users depend 
on all day for their work.

We are considering many options, primarily just moving to 389 on CentOS 6.  
That's a fairly big task for a site of our size so we'd like some confidence 
that we won't see a repeat of this issue.  There's talk of considering other 
products which no one wants to do but we're all edgy as this has caused a fair 
amount of downtime and about all I can do at the moment is monitor for it and 
re-initialize when it happens which doesn't inspire confidence.

thank you,

-morgan
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] ACL processing

[Ludwig Krispenz]

On 02/28/2014 01:31 AM, Rich Megginson wrote:

On 02/27/2014 05:06 PM, Russell Beall wrote:

Thanks again for your comments on this.

I tried an alternate approach in which I deleted a number of relevant 
indexes that theoretically should be needed all across the ACIs.  I 
was shocked to find out that the processing time was totally 
unaffected.  Then I took it a step further and deleted all of our 
custom indexes.  Then even further to delete uniquemember and uid 
indexing.  Again, performance was unaffected, and the results of ACI 
filtering still seem to be accurate.


It seems this means that the ACI processing is not correctly using 
the indexes, or I didn't create them properly.
Aci processing is done per entry, so you already have looked up all the 
entries (which could use some indexes) and now perform evaluation on a 
single entry. If you have acis with groupdns and you have very large 
groups the check if the bound user is a member of th egroup can become a 
severe performance problem


It could mean
1) the aci performance is not related to indexing
2) we don't know what indexes it is using

I have run db2index.pl and it successfully reprocessed the entire set 
of indexes.  I also ran dbverify to successful completion.  I can 
tell that the indexes are being used in simple searches (based on the 
fact that I get the Administrative Limit Exceeded error when there 
is no index).


Does this information point to anything that I should look into further?


If the aci processing is doing internal searches that don't show up in 
logconv.pl, then turning on access logging for internal searches 
should show those unindexed internal searches, which should show up 
using logconv.pl




Thanks,
Russ.


On Feb 27, 2014, at 1:19 PM, Rich Megginson rmegg...@redhat.com 
mailto:rmegg...@redhat.com wrote:



On 02/27/2014 12:49 PM, Russell Beall wrote:

Hi Rich,

Thanks for the data.  I've been continuing to experiment and work 
on this and especially making sure that everything that might be 
used in the ACIs is indexed.  All the indexes appear to be in 
order, but I am confused by one thing…  It looks like there is no 
entryDN index and only an entryrdn index.


Correct.

This new format will be fully workable for complicated dn lookups 
in the ACIs, correct?  (We have a lot of groupdn= and userdn= 
restrictions).


Correct.  groupdn= and userdn= do not use the entrydn index.



There is no one single ACI which degrades performance, but I did 
notice that when adding back in certain of the ACIs, performance 
does degrade quicker than should be expected just for the cost of 
processing only one additional ACI.  I believe there may definitely 
be a problem with the indexes as you suggested but It is hiding well...


You could enable access logging of internal operations.
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnconfig-nsslapd_accesslog_level


An additional symptom which may point to a server configuration 
problem is a strange inability to import or reindex quickly.  My 
small dev VM can import several hundred entries at a time, but this 
server will only import or reindex at a rate of 18-30 records per 
second.  I've ensured that there is plenty of import memory as well 
as cachememsize which should enable a very speedy import, but even 
though all 32 cores are burning bright, the import speed seems 
incredibly slow.  (This is of course after all indexes are created 
and it is trying to index while importing.  Import speed with no 
indexes is fairly fast).


Any obvious clues I'm missing?


No, not sure what's going on.



Thanks,
Russ.

On Feb 19, 2014, at 4:08 PM, Rich Megginson rmegg...@redhat.com 
mailto:rmegg...@redhat.com wrote:



On 02/19/2014 04:56 PM, Russell Beall wrote:

Hi all,

We've just set up monster-sized server nodes to run 389 as a 
replacement to Sun DS.  I've been running my tests and I am 
pleased to report that the memory issue seems to be in check with 
growth only up to double the initial memory usage after large 
quantities of ldapmodify calls.  We have plenty of room in these 
boxes to accommodate caching the entire database.


The key blocker on this is still the ACL processing times for 
which I have been unable to find a decent resolution.  We have 
135 ACIs at the root of the suffix.  When I comment out most of 
them but leave one service account active, processing times are 
very nicely fast.  When I leave them all on, that same service 
account takes 2.5 seconds to respond when only one request is 
pending.  A new kink in the puzzle here which is probably going 
to be a deal breaker is that if I run the same request on 
multiple threads, each thread takes proportionately longer to 
respond depending on the number of threads.  If I have 12 threads 
going doing a simple lookup, each thread responds in 45-55 
seconds.  If I have 24 threads going, each 

Re: [389-users] ACI warnings in error log

[Ludwig Krispenz]

On 01/13/2014 03:27 PM, Chris Chatfield wrote:

Hi,

I'm seeing a similar situation as was described in the mailing list message errors 
log - NSACLPlugin - acllas__client_match_URL: from Feb 2013. The final result of 
this was a suggestion to file a ticket. As far as I can see this wasn't done. Should I do 
this (for my scenario)?
yes. Create a ticket and add the full aci and the log messages. I agree 
that it should not be  a fatal message.


On to my case. I'm getting messages like this in my errors log (Centos 6.5, 
389DS 1.2.11.15):
NSACLPlugin - acllas__client_match_URL: url 
[ldap:///gcUID=0001ab51,o=Teamphone.com??sub?(objectclass=gcsubscriber)] scope 
is subtree but dn [gcUID=0001ab51,o=Teamphone.com] is not a suffix of [cn=tp 
manager,ou=configuration,o=teamphone.com]

There are acis at the o=teamphone.com subtree which allow administrators access 
to the whole tree.
There are acis at the gcUID=0001ab51,o=Teamphone.com subtree which allow 
gcsubscriber entries within that tree to have limited access to the subtree. 
Note that we have extended the schema such that gcsubscribers extend person, 
amongst other things. I do not believe this makes any difference to the problem.

The message happens on a connection bound to cn=tp 
manager,ou=configuration,o=teamphone.com (an administrator) when it searches 
within the subtree gcUID=0001ab51,o=Teamphone.com. It seems the acis at 
gcUID=0001ab51,o=Teamphone.com are being evaluated in the context of this 
administrator. In this case the administrator does not match the aci's userdn 
url path. This is deliberate as this aci is concerned with gcsubscriber access, 
not admin access. Other acis higher up give the correct admin access.

So in summary, I think this logging should be downgraded from SLAPI_LOG_FATAL to 
SLAPI_LOG_ACL for the acllas__client_match_URL: url [%s] scope is subtree but dn 
[%s] is not a suffix of [%s]\n  message (and I guess similarly for the 
onelevel/base scopes too). I notice that the git comment suggested that these lines were 
debugging.

Would that be the right approach? We're moving away from the Sun/Oracle 5.2 
directory server, and this aci is behaving quietly there.

Many thanks,

Chris

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Password Failure Lockout doesn't seem to work

[Ludwig Krispenz]

Hi,

did you set:
nsslapd-pwpolicy-local: on

in cn=config ?

Ludwig

On 11/26/2013 02:13 PM, JLPicard wrote:
Yes, I can, after 8 consecutive failed authentications, the account 
can still successfully query the DS with the correct password.


% ldapsearch -x -ZZ -LLL -h my-ldapHost01.my-domain.com -b 
dc=my-domain,dc=com -D 
uid=test-user-account,ou=people,dc=my-domain,dc=com -w badPword 
cn=test-user-account

ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h my-ldapHost01.my-domain.com -b 
dc=my-domain,dc=com -D 
uid=test-user-account,ou=people,dc=my-domain,dc=com -w badPword 
cn=test-user-account

ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h my-ldapHost01.my-domain.com -b 
dc=my-domain,dc=com -D 
uid=test-user-account,ou=people,dc=my-domain,dc=com -w badPword 
cn=test-user-account

ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h my-ldapHost01.my-domain.com -b 
dc=my-domain,dc=com -D 
uid=test-user-account,ou=people,dc=my-domain,dc=com -w badPword 
cn=test-user-account

ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h my-ldapHost01.my-domain.com -b 
dc=my-domain,dc=com -D 
uid=test-user-account,ou=people,dc=my-domain,dc=com -w badPword 
cn=test-user-account

ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h my-ldapHost01.my-domain.com -b 
dc=my-domain,dc=com -D 
uid=test-user-account,ou=people,dc=my-domain,dc=com -w badPword 
cn=test-user-account

ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h my-ldapHost01.my-domain.com -b 
dc=my-domain,dc=com -D 
uid=test-user-account,ou=people,dc=my-domain,dc=com -w badPword 
cn=test-user-account

ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h my-ldapHost01.my-domain.com -b 
dc=my-domain,dc=com -D 
uid=test-user-account,ou=people,dc=my-domain,dc=com -w badPword 
cn=test-user-account

ldap_bind: Invalid credentials (49)
% ldapsearch -x -ZZ -LLL -h my-ldapHost01.my-domain.com -b 
dc=my-domain,dc=com -D 
uid=test-user-account,ou=people,dc=my-domain,dc=com -w goodPwrd 
cn=test-user-account

dn: uid=test-user-account,ou=people,dc=my-domain,dc=com
description: accountHasItsOwnPwdPolicy
objectClass: posixAccount
objectClass: shadowAccount
objectClass: account
objectClass: top
uid: test-user-account
cn: test-user-account
uidNumber: 2853
gidNumber: 2600
gecos: LDAP Test
homeDirectory: /home/test-user-account
loginShell: /bin/tcsh


On 11/25/2013 5:49 PM, 389-users-requ...@lists.fedoraproject.org wrote:
From: Rich Megginson rmegg...@redhat.com To: General discussion 
list for the 389 Directory server project. 
389-users@lists.fedoraproject.org Cc: JLPicard 
jlpicar...@hotmail.com Subject: Re: [389-users] Password Failure 
Lockout doesn't seem to work Message-ID: 
5293d3fc.2090...@redhat.com Content-Type: text/plain; 
charset=utf-8; Format=flowed On 11/25/2013 03:33 PM, JLPicard wrote:

Hi, I am testing out   389_ds_base, version =1.2.11.15,REV=2013.01.31
running on mixed Solaris 10 servers (SPARC and X86) sourced from
http://www.opencsw.org/packages/CSW389-ds-base
in multi-master mode with 4 servers that is primarily used for
authentication and user/group/netgroup management.

Most of the Password policy components seem to work as they should,
but password failure account lockout doesn't appear to engage after
X-failed attempts.  After creating a new account, testing a successful
login, after 5+ failed logins with bad passwords, I can still login
after I would expect to be locked out.  I even created a new password
policy and applied it to this user and it still doesn't lock him out
after 5+ failed logins with bad passwords.

Can you reproduce the issue with ldapsearch?

ldapsearch ... -D uid=myuser, -w badpassword ...
repeat 5 times




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Modification hooks

[Ludwig Krispenz]

Hi,

I think waht you want can be achieved by plugins: 
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Plug-in_Guide/index.html


You can write your own code, register it for specific entry points and 
do what you want


Ludwig

On 10/08/2013 01:14 PM, Mailing Lists wrote:

Hi,

I am discovering the world of LDAPs and disovered 389 Directory Server 
as an interesting alternative. However, I am looking for something 
pretty specific and can't directly find it in the documentation:


Is there any possibility to have hooks in 389DS which allow a 
customizable action to be performed when records are added, modified 
and/or deleted?
An example for this would be to inform some third party that a 
modification of the directory service has occured, so that this party 
can take action on this (the third party could, of course, belong to 
the same organization as well).


The only thing I found so far has been replication session hooks 
(http://directory.fedoraproject.org/wiki/Replication_Session_Hooks) 
but they are obviously meant for replication problems.


Thanks in advance!
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] ACI invalid syntax

[Ludwig Krispenz]

On 09/04/2013 04:11 PM, Mitja Mihelič wrote:

Hi!

We are moving our Directory server from CentOS 5 Directory Server to 
CentOS 6 with 389 Directory Server.


Our DIT looks like this:
dc=example,dc=com
|- dc=guests,dc=example,dc=com

We would like the users in dc=example,dc=com to have full write 
permissions for their own entries. Users in 
dc=guests,dc=example,dc=com must not have that permission.


For that reason we had the following ACI applied to the 
dc=example,dc=com node:

(targetattr = *)
(target = ldap:///*@example.com,dc=example, dc=com)
(version 3.0;
acl Write to example.com - self;
allow (read,compare,search,write)
(userdn = ldap:///self;)
;)

This ACI works on the ol' CentOS 5 and the installed CentOS Directory 
server.

However the very same ACI cannot be applied in the 389DS on CentOS 6.
LDAPException: Invalid syntax (21)

maybe dn parsing is strict, try to remove the space in dc=example, dc=com


How should the ACI be written to work on CentOS 6 389DS?

you could also try
(target != ldap:///dc=guests,dc=example,dc=com;)


Kind regards,
Mitja



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] 389 Deadlock

[Ludwig Krispenz]

could you add the bt for thread 31 ?

On 07/22/2013 03:58 PM, Jeffrey Dunham wrote:

Hello,

Starting a day ago we have been noticing deadlocks on select 389 
servers.  It does not happen on all of them (10% of servers have been 
affected currently, and no repeat offenders).


Just looking for any hints on where to look or what could be causing 
this issue.


Version: 389-Directory/1.2.10.14 http://1.2.10.14

From GDB:
0x2b0df2847654 in __lll_lock_wait () from /lib64/libpthread.so.0
(gdb) info threads
  40 Thread 0x2b0e86c91940 (LWP 10689)  0x2b0df2b24122 in select 
() from /lib64/libc.so.6
  39 Thread 0x2b0e87692940 (LWP 10690)  0x2b0df2b24122 in select 
() from /lib64/libc.so.6
  38 Thread 0x2b0e88093940 (LWP 10691)  0x2b0df2b24122 in select 
() from /lib64/libc.so.6
  37 Thread 0x2b0e88a94940 (LWP 10692)  0x2b0df2b24122 in select 
() from /lib64/libc.so.6
  36 Thread 0x2b0e89495940 (LWP 10734)  0x2b0df2845019 in 
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  35 Thread 0x2b0e89e96940 (LWP 10735)  0x2b0df2845019 in 
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  34 Thread 0x2b0e8a897940 (LWP 10736)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  33 Thread 0x2b0e8b298940 (LWP 10737)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  32 Thread 0x2b0e91f00940 (LWP 10738)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  31 Thread 0x2b0e92901940 (LWP 10739)  0x2b0df2847654 in 
__lll_lock_wait () from /lib64/libpthread.so.0
  30 Thread 0x2b0e93302940 (LWP 10740)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  29 Thread 0x2b0e93d03940 (LWP 10741)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  28 Thread 0x2b0e94704940 (LWP 10742)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  27 Thread 0x2b0e95105940 (LWP 10743)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  26 Thread 0x2b0e95b06940 (LWP 10744)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  25 Thread 0x2b0e96507940 (LWP 10745)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  24 Thread 0x2b0e96f08940 (LWP 10746)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  23 Thread 0x2b0e97909940 (LWP 10747)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  22 Thread 0x2b0e9830a940 (LWP 10748)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  21 Thread 0x2b0e98d0b940 (LWP 10749)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  20 Thread 0x2b0e9970c940 (LWP 10750)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  19 Thread 0x2b0e9a10d940 (LWP 10751)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  18 Thread 0x2b0e9ab0e940 (LWP 10752)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  17 Thread 0x2b0e9b50f940 (LWP 10753)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  16 Thread 0x2b0e9bf10940 (LWP 10754)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  15 Thread 0x2b0e9c911940 (LWP 10755)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  14 Thread 0x2b0e9d312940 (LWP 10756)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  13 Thread 0x2b0e9dd13940 (LWP 10757)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  12 Thread 0x2b0e9e714940 (LWP 10758)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  11 Thread 0x2b0e9f115940 (LWP 10759)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  10 Thread 0x2b0e9fb16940 (LWP 10760)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  9 Thread 0x2b0ea0517940 (LWP 10761)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  8 Thread 0x2b0ea0f18940 (LWP 10762)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  7 Thread 0x2b0ea1919940 (LWP 10763)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  6 Thread 0x2b0ea231a940 (LWP 10764)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  5 Thread 0x2b0ea2d1b940 (LWP 10765)  0x2b0df2845280 in 
pthread_cond_timedwait@@GLIBC_2.3.2 () from 

Re: [389-users] ACL processing

[Ludwig Krispenz]

On 07/09/2013 12:01 AM, Russell Beall wrote:

Hi Ludwig,

Thanks for responding on this.

After further experimentation and re-applying ACI files from earlier times, I 
find that the condition probably has been present the whole time and I just 
didn't notice because I was focusing on performance related to our Directory 
Manager-based scripts.

We have specific ACI rules for each service account we issue.  I found that by 
commenting out 83 of these rules, I was able to cut down the response time from 
~2.5 seconds to ~0.3 seconds.  Even further if I limited the returned 
attributes to a small set.
yes, since access control is evaluated for each attribute returned 
reducing the requested attributes will help (and reducing the number of 
acis of course helped as well)


I think a key problem with this is that our rules apply to most entries, but then it is 
only a very specific userdn which has the allow permission at the end of the 
rule.  Is there any way to turn that around so that the userdn might be looked at first 
rather than processing the whole rule only to then find out that it applies to an 
irrelevant account?

Is there any documentation on how to best optimize a complex set of ACIs?
no, not that I am aware of, but maybe an understanding of how aci 
processing works can help you
- first for an entry all potential acis are collected and since the 
target of an aci can extend to teh subtree where it is placed all acis 
from the entry in question up to the root suffix are copllected
- while collecting the acis, they are placed in two buckets, one for 
acis with deny rules, one for acis with allow rules.
- first the deny acis are processed, as soon as a matching aci is found 
aci processing stops

- next the allow list is processed until a matching aci is found
when an aci is evaluated, first check if the target rule covers then 
entry, then if the targetattrs include the attr evaluated, then if it 
contains the correct permission (read, search,...)
and if the target matches then the bind rule part is evaluated, if it 
matches the bound dn (and other rules like dns or ip or )


So to optimize aci evaluation, you need to try to minimize the above steps
- if you have a directory tree with many nested subtrees and acis 
affecting only subtrees, place them as close as possible to the subtree, 
so no unrelated acis will be collected

- always all deny acis will be processed, maybe minimizing denies can help
-if you have service accounts which will have access to only parts of 
the directory tree, maybe using macro acis can help to reduce the number 
of acis


You suggested the logging would show the processing order.  I tried placing the 
most important rule at the top of the list, but it didn't actually change the 
processing (and I didn't really expect that anyway).  What is it that you are 
referring to that might help me reorder/redesign the processing of the rules?
if you enable aci logging you will get at startup a list of acis and 
their aci index, later when evaluating access, there is always something 
like evaluation xxx deny handles, xxx allow handles and referencing the 
index of the aci evaluated, you could then probably get some insight how 
many and which acis are processed for each request and in which order 
and what finally is the decidng aci.
It will also log if a cached evaluation could be used. Evaluation tries 
to remember if the set of acis is the same for the attributes handled 
and then use the previous evaluation. Caching cannot be used eg if the 
acis contain rules depending on the entry, eg self rules or entry#attr 
rules.


Appreciate any help you can offer.

Regards,
Russ.

On Jul 4, 2013, at 6:11 AM, Ludwig Krispenz lkris...@redhat.com
  wrote:


Hi,

yes, aci processing can become very expensive if you have a lot of acis are used, the 
code tries to do soem optimizations to cache evaluation, but a small change in acis could 
prevent the use of cached results. So if you do not have a full set of acis from the 
better times it will be difficult to tell what led to the changed performance.

The aci code in RHDS and SunDS is very similar, but both have done over the 
time bug fixes and attempts to optimize, so  for a given set of acis 
performance could be different.

ACI logging slows down a lot, but it could help you to investigate the usage of 
your acis and which acis lead to the decision and which otehr acis are 
processed before, so it could help in redesigning your acis, what you probably 
need to do.

Regards,
Ludwig

On 07/04/2013 12:06 AM, Russell Beall wrote:

I did a lot of work experimenting with 389 for use as a replacement to Sun 
SJES.  Worked really well when I focused my efforts on the backend processing 
we do with Directory Manager, except for a few performance issues which are 
being addressed in bug reports.

I thought sure I had done at least some load testing with service accounts.  
The service accounts must go through ACL processing, and we

Re: [389-users] ACL processing

[Ludwig Krispenz]

Hi,

yes, aci processing can become very expensive if you have a lot of acis 
are used, the code tries to do soem optimizations to cache evaluation, 
but a small change in acis could prevent the use of cached results. So 
if you do not have a full set of acis from the better times it will be 
difficult to tell what led to the changed performance.


The aci code in RHDS and SunDS is very similar, but both have done over 
the time bug fixes and attempts to optimize, so  for a given set of acis 
performance could be different.


ACI logging slows down a lot, but it could help you to investigate the 
usage of your acis and which acis lead to the decision and which otehr 
acis are processed before, so it could help in redesigning your acis, 
what you probably need to do.


Regards,
Ludwig

On 07/04/2013 12:06 AM, Russell Beall wrote:

I did a lot of work experimenting with 389 for use as a replacement to Sun 
SJES.  Worked really well when I focused my efforts on the backend processing 
we do with Directory Manager, except for a few performance issues which are 
being addressed in bug reports.

I thought sure I had done at least some load testing with service accounts.  
The service accounts must go through ACL processing, and we have a lot of ACLs. 
 I'm not sure if I changed something, or if I just didn't quite test this 
feature enough, but now that I am doing more development work with service 
accounts, I am showing a huge processing hit taken if a service account is used 
as opposed to Directory Manager.  This is on the order of a second and a half 
to respond to a simple base query, versus instantaneous.  Our old SJES servers 
respond very snappily in comparison for this type of query.

CPU usage for a single thread maxes out during the time spent waiting and I/O 
wait is zero, so I know that probably the bulk of time is being spent 
processing the ACLs.  This is especially true if I turn on logging for ACL 
processing, then it takes a very long time, with one example taking about 9 
minutes.

It seems to be processing and reprocessing the ACLs many many times over.

I think I must have changed something or done something wrong because I'm 
pretty sure I remember much quicker response times when using a service account 
in earlier testing.

This is with 389-ds-base 1.2.10.14 on RedHat 6.2.

This was an experimental version downloaded to check out a memory fragmentation 
option that was coded in, so maybe I just have a version that was mid ACL 
processing changes?

Thanks for any help,
Russ.


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Authentication method not supported

[Ludwig Krispenz]

Hi,

there was recently an other thread about a failure on sparc, now ppc, 
both big endian. Maybe we have a 32 access to a 64 bit var, which has no 
effect on little endian machines.


Ludwig

On 07/01/2013 04:06 PM, Rich Megginson wrote:

On 06/30/2013 12:10 AM, il...@atacom.kz wrote:

Good morning!
Yes. Accesslog level is *772*:

/[30/Jun/2013:12:00:31 +0600] conn=50705 fd=69 slot=69 connection 
from 127.0.0.1 to 127.0.0.1/
/[30/Jun/2013:12:00:31 +0600] conn=50705 op=0 BIND 
dn=uid=kolab-service,ou=Special Users,dc=example,dc=kz method=128 
version=3/
/[30/Jun/2013:12:00:31 +0600] conn=Internal op=-1 SRCH 
base=uid=kolab-service,ou=special users,dc=example,dc=kz scope=0 
filter=(|(objectclass=*)(objectclass=ldapsubentry)) attrs=ALL/
/[30/Jun/2013:12:00:31 +0600] conn=Internal op=-1 ENTRY 
dn=uid=kolab-service,ou=Special Users,dc=example,dc=kz/
/[30/Jun/2013:12:00:31 +0600] conn=Internal op=-1 RESULT err=0 tag=48 
nentries=1 etime=0/
/[30/Jun/2013:12:00:31 +0600] conn=50705 op=0 RESULT err=7 tag=97 
nentries=0 etime=0/

/[30/Jun/2013:12:00:31 +0600] conn=50705 op=1 UNBIND/
/[30/Jun/2013:12:00:31 +0600] conn=50705 op=1 fd=69 closed - U1/

This is part of log which is responsible for /[root@xat noarch]# 
ldapsearch -x -D uid=kolab-service,ou=Special 
Users,dc=example,dc=kz  -w secret -b dc=example,dc=kz -s sub 
(objectclass=*)/*/

/*
If you need full log I can send you but it very heavy.


Hmm - PPC - we don't do any testing on that platform, so it could be 
PPC specific.


What's in the errors log?



Thank you for helping!

--
Ilmir Mulyukov




From: Tim Cambridge tim.cambri...@london.gov.uk
To: '389-users@lists.fedoraproject.org' 
389-users@lists.fedoraproject.org,

Date: 30.06.2013 04:59
Subject: Re: [389-users] Authentication method not supported
Sent by: 389-users-boun...@lists.fedoraproject.org




Would it be any help to look at the access log on the server with 
389-ds installed ?


Maybe in sub directory of /var/log/ ?

Tim

*From*: il...@atacom.kz [mailto:il...@atacom.kz] *
Sent*: Saturday, June 29, 2013 08:58 PM*
To*: 389-users@lists.fedoraproject.org 
389-users@lists.fedoraproject.org *

Subject*: [389-users] Authentication method not supported

Hello!
During the setup the Kolab on system with 389-ds I have found the 
following message:

/
Your new DS instance 'xat' was successfully created.//
Creating the configuration directory server . . .//
Could not authenticate as user 
'uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot' to 
server 'ldap://xat.example.kz:389/o=NetscapeRoot'.  Error: 
*Authentication method not supported*/


I thought that may be this is bug of kolab but new instance have the 
same problem.

/
[root@xat noarch]# ldapsearch -x -D uid=kolab-service,ou=Special 
Users,dc=example,dc=kz  -w secret -b dc=example,dc=kz -s sub 
(objectclass=*)/*/

ldap_bind: Authentication method not supported (7)/**/
   additional info: auth method not supported/*

/
[root@xat noarch]# ldapsearch -x -D cn=directory manager  -w secret 
-s base //

dn://
objectClass: top//
namingContexts: dc=example,dc=kz//
namingContexts: o=netscaperoot//
defaultnamingcontext: dc=example,dc=kz//
supportedExtension: 2.16.840.1.113730.3.5.7//
supportedExtension: 2.16.840.1.113730.3.5.8//
supportedExtension: 2.16.840.1.113730.3.5.3//
supportedExtension: 2.16.840.1.113730.3.5.12//
supportedExtension: 2.16.840.1.113730.3.5.5//
supportedExtension: 2.16.840.1.113730.3.5.6//
supportedExtension: 2.16.840.1.113730.3.5.9//
supportedExtension: 2.16.840.1.113730.3.5.4//
supportedExtension: 2.16.840.1.113730.3.6.5//
supportedExtension: 2.16.840.1.113730.3.6.6//
supportedExtension: 2.16.840.1.113730.3.6.7//
supportedExtension: 2.16.840.1.113730.3.6.8//
supportedExtension: 1.3.6.1.4.1.4203.1.11.1//
supportedControl: 2.16.840.1.113730.3.4.2//
supportedControl: 2.16.840.1.113730.3.4.3//
supportedControl: 2.16.840.1.113730.3.4.4//
supportedControl: 2.16.840.1.113730.3.4.5//
supportedControl: 1.2.840.113556.1.4.473//
supportedControl: 2.16.840.1.113730.3.4.9//
supportedControl: 2.16.840.1.113730.3.4.16//
supportedControl: 2.16.840.1.113730.3.4.15//
supportedControl: 2.16.840.1.113730.3.4.17//
supportedControl: 2.16.840.1.113730.3.4.19//
supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1//
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2//
supportedControl: 1.2.840.113556.1.4.319//
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8//
supportedControl: 1.3.6.1.4.1.4203.666.5.16//
supportedControl: 2.16.840.1.113730.3.4.14//
supportedControl: 2.16.840.1.113730.3.4.20//
supportedControl: 1.3.6.1.4.1.1466.29539.12//
supportedControl: 2.16.840.1.113730.3.4.12//
supportedControl: 2.16.840.1.113730.3.4.18//
supportedControl: 2.16.840.1.113730.3.4.13//
supportedSASLMechanisms: EXTERNAL//
supportedSASLMechanisms: GSSAPI//
supportedSASLMechanisms: CRAM-MD5//
supportedSASLMechanisms: PLAIN//
supportedSASLMechanisms: DIGEST-MD5//
supportedSASLMechanisms: LOGIN//

Re: [389-users] dual change log entry with retro changelog plugin

[Ludwig Krispenz]

What do you mean by two entries - the same change duplicate with 
different change numbers or an additional change logged ?


Ludwig

On 05/23/2013 08:57 AM, Vincent Gerris wrote:

Hi,

We are using Red Hat Enterprise Directory Server (which is a stable 389).
We have been using the retro changelog plugin from the old iPlanet
server for synchronisation to other systems.
Yesterday we noticed that for some reason, when an LDAP modification
is made, 2 entries turn up in de changelog LDAP tree.
It does not seem to happen when the 389-console client is used and a
change is made directly to an account with it,
but when an LDAP modify is done, while the slapd access logs shows 1
modification, the changelog has two entries.
This seems to be a bug.

Does anyone know how to solve this?
I have not found anybody having the issue and nothing in the
configuration either.
These duplicate entries might result in performance issues on the
scripting side.
Any help is greatly appreciated!

Kind regards,
Vincent
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Fwd: default values creating user/groups

[Ludwig Krispenz]

Hi,

you can try Cos, this creates virtual attributes, which are not directly 
stored in the entry but are generated when the entry is read. You can 
also specify if a real attribute shoud have precedence over the cos 
attribute. Take a look at: 
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Advanced_Entry_Management-Assigning_Class_of_Service.html


Ludwig

On 05/08/2013 11:45 PM, Victor Hugo dos Santos wrote:

Hello,

I was trying to find information how I can put a object/value by
default when I create a user/group.

for example, I like to make this values for default to all new user
that I create way DS java console:

===
shadowMin: 1
shadowMax: 45
shadowWarning: 14
===

but I dont found information.

Can I make one or more atributtes by default ??

thanks and attentive.

--
--
Victor Hugo dos Santos
http://www.vhsantos.net
Linux Counter #224399
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users