389ds / 389-ds-base Goto Github PK
View Code? Open in Web Editor NEWThe enterprise-class Open Source LDAP server for Linux
Home Page: https://www.port389.org/
License: Other
The enterprise-class Open Source LDAP server for Linux
Home Page: https://www.port389.org/
License: Other
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/8
https://bugzilla.redhat.com/show_bug.cgi?id=767024
Description of problem:
Steps to reproduce:
1) set up MMR
2) create a subtree in the database
dc=example,dc=com
|
ou=orgunit0
| \
ou=orgunit00 ou=orgunit01
| \
uid=tuser000 uid=tuser010
uid=tuser001 uid=tuser011
Delete ou=orgunit0
3) shutdown the server
4) export the backend:
# /usr/lib[64]/dirsrv/slapd-ID/db2ldif -n userRoot -r
5) import the exported file
# /usr/lib[64]/dirsrv/slapd-ID/ldif2db -n userRoot -i /path/to/ldif/file
[..] - import userRoot: Processing file
"/var/lib/dirsrv/slapd-kiki0/ldif/kiki0-userRoot-2011_12_12_172236.ldif"
[..] - import userRoot: Finished scanning file
"/var/lib/dirsrv/slapd-kiki0/ldif/kiki0-userRoot-2011_12_12_172236.ldif" (18
entries)
[..] - import userRoot: WARNING: Skipping entry "nsuniqueid=ceb8df01-252711e1-8
56cfebb-9066bfc6,ou=orgunit00,ou=orgunit0,dc=example,dc=com" which has no
parent, ending at line 201 of file
"/var/lib/dirsrv/slapd-kiki0/ldif/kiki0-userRoot-2011_12_12_172236.ldif"
[..] - import userRoot: WARNING: Skipping entry "nsuniqueid=ceb8df02-252711e1-8
56cfebb-9066bfc6,ou=orgunit01,ou=orgunit0,dc=example,dc=com" which has no
parent, ending at line 218 of file
"/var/lib/dirsrv/slapd-kiki0/ldif/kiki0-userRoot-2011_12_12_172236.ldif"
[..] - import userRoot: WARNING: Skipping entry "nsuniqueid=ceb8df03-252711e1-8
56cfebb-9066bfc6,uid=tuser000,ou=orgunit00,ou=orgunit0,dc=example,dc=com" which
has no parent, ending at line 240 of file
"/var/lib/dirsrv/slapd-kiki0/ldif/kiki0-userRoot-2011_12_12_172236.ldif"
[..] - import userRoot: WARNING: Skipping entry "nsuniqueid=ceb8df04-252711e1-8
56cfebb-9066bfc6,uid=tuser001,ou=orgunit00,ou=orgunit0,dc=example,dc=com" which
has no parent, ending at line 262 of file
"/var/lib/dirsrv/slapd-kiki0/ldif/kiki0-userRoot-2011_12_12_172236.ldif"
[..] - import userRoot: WARNING: Skipping entry "nsuniqueid=ceb8df05-252711e1-8
56cfebb-9066bfc6,uid=tuser010,ou=orgunit01,ou=orgunit0,dc=example,dc=com" which
has no parent, ending at line 284 of file
"/var/lib/dirsrv/slapd-kiki0/ldif/kiki0-userRoot-2011_12_12_172236.ldif"
[..] - import userRoot: WARNING: Skipping entry "nsuniqueid=ceb8df06-252711e1-8
56cfebb-9066bfc6,uid=tuser011,ou=orgunit01,ou=orgunit0,dc=example,dc=com" which
has no parent, ending at line 306 of file
"/var/lib/dirsrv/slapd-kiki0/ldif/kiki0-userRoot-2011_12_12_172236.ldif"
[..] - import userRoot: WARNING: bad entry: ID 12
[..] - import userRoot: WARNING: bad entry: ID 13
[...]
[..] - import userRoot: WARNING: bad entry: ID 16
[..] - import userRoot: WARNING: bad entry: ID 17
[..] - import userRoot: Workers finished; cleaning up...
[..] - import userRoot: Workers cleaned up.
[..] - import userRoot: Cleaning up producer thread...
[..] - import userRoot: Indexing complete. Post-processing...
[..] - import userRoot: Flushing caches...
[..] - import userRoot: Closing files...
[..] - All database threads now stopped
[..] - import userRoot: Import complete. Processed 18 entries (6 were skipped)
in 5 seconds. (3.60 entries/sec)
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/14
https://bugzilla.redhat.com/show_bug.cgi?id=752536
Description of problem:
I upgraded both my Directory Servers to 8.2.6 and since then I am unable to
connect to the servers using the windows tools
Version-Release number of selected component (if applicable):
Console Framework 1.1.5
How reproducible:
Each time
Steps to Reproduce:
1. Open 389 Console
2. Right click to expand the server
3. Right click to expand the Server Group
Actual results:
Results in a circle continually on the screen
Expected results:
I can open the actual server and administer it
Additional info:
C:\Program Files\389 Management Console>"java" "-Djava.library.path=." -cp
"./js
s4.jar;./ldapjdk.jar;./idm-console-base.jar;./idm-console-mcc.jar;./idm-console
-
mcc_en.jar;./idm-console-nmclf.jar;./idm-console-nmclf_en.jar;./389-console_en.
j
ar" -Djava.util.prefs.systemRoot=/.389-console
-Djava.util.prefs.userRoot=/.389-
console com.netscape.management.client.console.Console
Uncaught error fetching image:
java.lang.NullPointerException
at java.io.FileInputStream.<init>(Unknown Source)
at java.io.FileInputStream.<init>(Unknown Source)
at sun.awt.image.FileImageSource.getDecoder(Unknown Source)
at sun.awt.image.InputStreamImageSource.doFetch(Unknown Source)
at sun.awt.image.ImageFetcher.fetchloop(Unknown Source)
at sun.awt.image.ImageFetcher.run(Unknown Source)
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/16
https://bugzilla.redhat.com/show_bug.cgi?id=750767
Description of problem:
Consider we have a topology like Master replicating to slave.
Master -> Salve
When we promote Slave to become serve the Master role, if we assign the same
replica ID(value of "nsDS5ReplicaId" ) as of the Master during promotion
operation. The dummy entry(the "cn=start iteration" entry) do not get logged in
the changelogdb file. But if we assign the different replicaID, the dummy entry
gets logged in the changelogdb file.
Version-Release number of selected component (if applicable):
How reproducible:
Frequently.
Steps to Reproduce:
1.Create the Master and Salve topology where master replicating to the Slave.
Master -------------------> Slave
nsDS5ReplicaId: 10 nsDS5ReplicaId: 65535 ----> Original
===========================================
Master <No aggrement now> Salve(Now become new master after promotion)
nsDS5ReplicaId: 10( which is same as the master
replica ID)
Note: In this scenario, it doesn't create a changelogdb file along with the
Dummy entry
============================================
Master <No aggrement now> Salve(Now become new master after promotion)
nsDS5ReplicaId: 20( which is same as the master
replica ID)
Note: In this scenario, it creates a changelogdb file along with the Dummy
entry.
===========================================
2.Make sure that both Master and Slave are on sync.
3.Delete the replication agreement.
4. Promote the Slave to serve the Master role. Promotion steps are given below.
- Delete Supplier DN (cn=suppdn,cn=config) from Slave
- Delete ?cn=replica? entry for the suffix ?o=USA? using ldapmodify. As a
result, it will delete the changelog file.
Ex: dn: cn=replica,cn=o=USA,cn=mapping tree,cn=config
changetype: delete
- Modify the cn=o=USA ,cn=mapping tree,cn=config entry as below
EX: dn: cn=o=USA,cn=mapping tree,cn=config
changetype: modify
replace: nsslapd-state
nsslapd-state: backend
dn: cn=o=USA,cn=mapping tree,cn=config
changetype: modify
delete: nsslapd-referral
- Recreate the ?cn=replica? entry for the suffix as below.
EX: dn: cn=replica,cn=o=USA,cn=mapping tree,cn=config
changetype: add
objectClass: nsds5replica
objectClass: top
nsDS5ReplicaRoot: o=USA
nsDS5ReplicaType: 3
nsDS5Flags: 1
nsDS5ReplicaId: 10 ----> <Please assign the same ?nsDS5ReplicaId
value what master was having. In my case, Original master replica ID was 10.>
nsds5ReplicaPurgeDelay: 1
nsds5ReplicaTombstonePurgeInterval: -1
cn: replica
5. Restart slapd process. Now Slave become Master.
Actual results:
It will not create any change log file and also will not create any dummy entry
like below to mark the last change it was received ever. But if we assign a
different replica ID( value of "nsDS5ReplicaId" attribute, for example "20"
instead of "10"), we will see this entry being getting created along with the
changelogdb file.
dbid: 4eb10ac20004000a0000
replgen: 1320225977 Wed Nov 2 14:56:17 2011
csn: 4eb10ac20004000a0000
uniqueid: 00000000-00000000-00000000-00000000
dn: cn=start iteration
operation: delete
Expected results:
It should create a chnagelogdb file along with the dummy entry if we assign the
same replica ID as of it master which it does in case of a new replica ID
assignment.
Additional info:
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/20
https://bugzilla.redhat.com/show_bug.cgi?id=747403
The automember plug-in currently checks ADD operations to see if the entry
matches one of the defined automember rules. Existing entries are not checked
when they are modified to avoid a performance impact to modify operations. We
should provide a way to have the automember plug-in check existing entries to
see if any automember work needs to be done. This is something that the
FreeIPA project would like to see.
A good way of accomplishing this would be to add a task to the automember
plug-in. The creator of the task would provide a search filter and base. All
matching entries would be checked against the defined automember rules to see
if they should be added to any groups. This allows one to add the triggering
attributes/values after the entry was initially added, and then trigger the
task to perform automember updates. The nice thing about this approach is that
we don't cause any negative performance impact on normal modify operations.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/18
https://bugzilla.redhat.com/show_bug.cgi?id=750425
Description of problem:
Data loss during the promotion operation(Slave to Master).
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
Step-1:
Have a topology like Master replicating to Slave and Slave replication to
consumer.
Master -> Slave-> Consumer.
Step-2:
Make sure that all are on sync at this time. Let?s take an example all are the
on sync up to CSN5 (5 records are added to master from CSN1 to CSN5).
Step-3:
Delete the replication agreement from Master to Slave and also from Slave to
consumer.
Step-4:
Promote the Slave to master. Promotion steps are given below.
- Delete Supplier DN (cn=suppdn,cn=config) from Slave
- Delete ?cn=replica? entry for the suffix ?o=USA? using ldapmodify. As a
result, it will delete the changelog file.
Ex: dn: cn=replica,cn=o=USA,cn=mapping tree,cn=config
changetype: delete
- Modify the cn=o=USA ,cn=mapping tree,cn=config entry as below
EX: dn: cn=o=USA,cn=mapping tree,cn=config
changetype: modify
replace: nsslapd-state
nsslapd-state: backend
dn: cn=o=USA,cn=mapping tree,cn=config
changetype: modify
delete: nsslapd-referral
- Recreate the ?cn=replica? entry for the suffix as below.
dn: cn=replica,cn=o=USA,cn=mapping tree,cn=config
changetype: add
objectClass: nsds5replica
objectClass: top
nsDS5ReplicaRoot: o=USA
nsDS5ReplicaType: 3
nsDS5Flags: 1
nsDS5ReplicaId: 10 --? Please assign the same ?nsDS5ReplicaId value what
master was having. In my case, Original master replica ID was 10.
nsds5ReplicaPurgeDelay: 1
nsds5ReplicaTombstonePurgeInterval: -1
cn: replica
- Restart slapd process. Now Slave become Master.
Is there anything am I missing during promotion operation or it?s not the right
way to do the promotion operation?
Step -5:
Add the replication agreement between Slave(newly promoted Master) and Consumer
. At this time both Slave and consumer are on sync up to CSN5. During agreement
creation please do not initialize the consumer.
Slave(newly promoted as master) - > consumer.
Step-6:
Add another 5 more entries to Slave which was promoted above as Master. Let?s
assume CSN numbers for these 5 entries are from CSN6 to CSN10.
Step-7:
Now, you will see, among the last 5 entries only last few will gets replicated
without halting the replication.
Actual results
Expected results:
Additional info:
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/35
https://bugzilla.redhat.com/show_bug.cgi?id=733349
When a schema file has an error, the log file is not clear enough and may give
the impression the error is in dse.ldif
Example:
[25/Aug/2011:09:53:47 -0400] dse - parsing dse entry [attributeTypes]
[25/Aug/2011:09:53:47 -0400] dse - Please edit the file to correct the reported
problems and then restart the server.
Expected behaviour:
The server specifies in which file (and possible line number) the error was
encountered.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/9
https://bugzilla.redhat.com/show_bug.cgi?id=760687
Description of problem:
I created a referral in DS, but had a typo. I attempted to modify the referral
(which requires the use of the manageDsaIT control to edit the referral entry
itself, rather than returning a referral message to the target). 389 did not
allow me to edit the entry, instead returning a referral message.
Version-Release number of selected component (if applicable):
389-ds-base-1.2.9.13-1.el6.x86_64
How reproducible:
Every time
Steps to Reproduce:
1. Create a referral object such as:
dn: uid=keitaro,cn=users,cn=accounts,dc=referrals,dc=sgallagh,dc=bos,dc=redhat
,dc=com
objectClass: top
objectClass: extensibleObject
uid: keitaro
ref: ldap://ipaserver:389/uid=kurashima,cn=users,cn=accounts,dc=referrals,dc=s
gallagh,dc=bos,dc=redhat,dc=com??base?
2. Attempt to modify this referral with an LDIF like:
dn: uid=keitaro,cn=users,cn=accounts,dc=referrals,dc=sgallagh,dc=bos,dc=redhat,
dc=com
changetype: modify
replace: ref
ref: ldap://ipaserver.referrals.sgallagh.bos.redhat.com:389/uid=kurashima,cn=us
ers,cn=accounts,dc=referrals,dc=sgallagh,dc=bos,dc=redhat,dc=com??base?
Actual results:
ldapmodify returns:
modifying entry "uid=keitaro,cn=users,cn=accounts,dc=referrals,dc=sgallagh,dc=b
os,dc=redhat,dc=com"
ldap_modify: Referral (10)
Expected results:
The entry should be updated.
Additional info:
TRACE logs from /var/dirsrv/<slapd>/errors:
[06/Dec/2011:13:53:45 -0500] - => ids_sasl_server_new
(ipaserver.referrals.sgallagh.bos.redhat.com)
[06/Dec/2011:13:53:45 -0500] - ids_sasl_getopt: plugin= option=log_level
[06/Dec/2011:13:53:45 -0500] - ids_sasl_getopt: plugin= option=auto_transition
[06/Dec/2011:13:53:45 -0500] - <= ids_sasl_server_new
[06/Dec/2011:13:53:45 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c950, handle=7
[06/Dec/2011:13:53:45 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:45 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.12)
[06/Dec/2011:13:53:45 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:45 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.18)
[06/Dec/2011:13:53:45 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:45 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=5
[06/Dec/2011:13:53:45 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:45 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=4
[06/Dec/2011:13:53:45 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:45 -0500] - => compute_limits: sizelimit=-1, timelimit=-1
[06/Dec/2011:13:53:45 -0500] - Calling plugin 'ACL preoperation' 1 type 403
[06/Dec/2011:13:53:45 -0500] - Calling plugin 'deref' 3 type 403
[06/Dec/2011:13:53:45 -0500] deref-plugin - --> deref_pre_search
[06/Dec/2011:13:53:45 -0500] deref-plugin - <-- deref_pre_op
[06/Dec/2011:13:53:45 -0500] - Calling plugin 'Legacy replication preoperation
plugin' 13 type 403
[06/Dec/2011:13:53:45 -0500] - Calling plugin 'Multimaster replication
preoperation plugin' 16 type 403
[06/Dec/2011:13:53:45 -0500] - Calling plugin 'schema-compat-plugin-preop' 18
type 403
[06/Dec/2011:13:53:45 -0500] - defbackend_default
[06/Dec/2011:13:53:46 -0500] - => send_ldap_result 32::
[06/Dec/2011:13:53:46 -0500] - <= send_ldap_result
[06/Dec/2011:13:53:46 -0500] - => reslimit_update_from_entry() conn=0x24e0c950,
entry=0x0
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 0 (based on nsLookThroughLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 1 (based on nsIDListScanLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 2 (based on nsPagedLookThroughLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 3 (based on nsPagedIDListScanLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 4 (based on nsSizeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 5 (based on nsTimeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 6 (based on nsPagedSizeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 7 (based on nsIdleTimeout)
[06/Dec/2011:13:53:46 -0500] - <= reslimit_update_from_entry() returning status
0
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c950, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c560, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.12)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.18)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=5
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=4
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => compute_limits: sizelimit=-1, timelimit=-1
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'ACL preoperation' 1 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'deref' 3 type 403
[06/Dec/2011:13:53:46 -0500] deref-plugin - --> deref_pre_search
[06/Dec/2011:13:53:46 -0500] deref-plugin - <-- deref_pre_op
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Legacy replication preoperation
plugin' 13 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Multimaster replication
preoperation plugin' 16 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'schema-compat-plugin-preop' 18
type 403
[06/Dec/2011:13:53:46 -0500] - defbackend_default
[06/Dec/2011:13:53:46 -0500] - => send_ldap_result 32::
[06/Dec/2011:13:53:46 -0500] - <= send_ldap_result
[06/Dec/2011:13:53:46 -0500] - => reslimit_update_from_entry() conn=0x24e0c560,
entry=0x0
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 0 (based on nsLookThroughLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 1 (based on nsIDListScanLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 2 (based on nsPagedLookThroughLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 3 (based on nsPagedIDListScanLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 4 (based on nsSizeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 5 (based on nsTimeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 6 (based on nsPagedSizeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 7 (based on nsIdleTimeout)
[06/Dec/2011:13:53:46 -0500] - <= reslimit_update_from_entry() returning status
0
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c560, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c800, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
SUCCESS, value=0
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c6b0, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c410, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - add_pb
[06/Dec/2011:13:53:46 -0500] - get_pb
[06/Dec/2011:13:53:46 -0500] - do_bind
[06/Dec/2011:13:53:46 -0500] - BIND dn="cn=Directory Manager" method=128
version=3
[06/Dec/2011:13:53:46 -0500] - => get_ldapmessage_controls
[06/Dec/2011:13:53:46 -0500] - <= get_ldapmessage_controls no controls
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.16)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - do_bind: version 3 method 0x80 dn cn=Directory
Manager
[06/Dec/2011:13:53:46 -0500] - => slapi_pw_find value: "redhatredhat"
[06/Dec/2011:13:53:46 -0500] - <= slapi_pw_find matched
"LNtlbynj2F5pZmSjY8QiGWZG8hNCHo+Rfzx7vA==" using scheme "SSHA"
[06/Dec/2011:13:53:46 -0500] - => send_ldap_result 0::
[06/Dec/2011:13:53:46 -0500] - <= send_ldap_result
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c560, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.12)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.18)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=5
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=4
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => compute_limits: sizelimit=-1, timelimit=-1
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'ACL preoperation' 1 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'deref' 3 type 403
[06/Dec/2011:13:53:46 -0500] deref-plugin - --> deref_pre_search
[06/Dec/2011:13:53:46 -0500] deref-plugin - <-- deref_pre_op
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Legacy replication preoperation
plugin' 13 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Multimaster replication
preoperation plugin' 16 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'schema-compat-plugin-preop' 18
type 403
[06/Dec/2011:13:53:46 -0500] - defbackend_default
[06/Dec/2011:13:53:46 -0500] - => send_ldap_result 32::
[06/Dec/2011:13:53:46 -0500] - <= send_ldap_result
[06/Dec/2011:13:53:46 -0500] - => reslimit_update_from_entry() conn=0x24e0c560,
entry=0x0
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 0 (based on nsLookThroughLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 1 (based on nsIDListScanLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 2 (based on nsPagedLookThroughLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 3 (based on nsPagedIDListScanLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 4 (based on nsSizeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 5 (based on nsTimeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 6 (based on nsPagedSizeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 7 (based on nsIdleTimeout)
[06/Dec/2011:13:53:46 -0500] - <= reslimit_update_from_entry() returning status
0
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c560, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c800, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
SUCCESS, value=0
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c6b0, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c410, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - add_pb
[06/Dec/2011:13:53:46 -0500] - get_pb
[06/Dec/2011:13:53:46 -0500] - do_modify
[06/Dec/2011:13:53:46 -0500] - => get_ldapmessage_controls
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.2)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 1 (FOUND)
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
1.3.6.1.4.1.42.2.27.8.5.1)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NOT FOUND)
[06/Dec/2011:13:53:46 -0500] - <= get_ldapmessage_controls 1 controls
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.12)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NOT FOUND)
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.18)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NOT FOUND)
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.12)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.18)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=5
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=4
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => compute_limits: sizelimit=-1, timelimit=-1
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'ACL preoperation' 1 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'deref' 3 type 403
[06/Dec/2011:13:53:46 -0500] deref-plugin - --> deref_pre_search
[06/Dec/2011:13:53:46 -0500] deref-plugin - <-- deref_pre_op
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Legacy replication preoperation
plugin' 13 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Multimaster replication
preoperation plugin' 16 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'schema-compat-plugin-preop' 18
type 403
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=0
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => find_entry_internal (dn=uid=keitaro,cn=users,
cn=accounts,dc=referrals,dc=sgallagh,dc=bos,dc=redhat,dc=com) lock 0
[06/Dec/2011:13:53:46 -0500] - => dn2entry "uid=keitaro,cn=users,cn=accounts,dc
=referrals,dc=sgallagh,dc=bos,dc=redhat,dc=com"
[06/Dec/2011:13:53:46 -0500] - <= dn2entry 7faff4007aa0
[06/Dec/2011:13:53:46 -0500] - => send_ldap_result 10::
[06/Dec/2011:13:53:46 -0500] - <= send_ldap_result
[06/Dec/2011:13:53:46 -0500] - <= find_entry_internal_dn sent referral to (ldap
://ipaserver:389/uid=kurashima,cn=users,cn=accounts,dc=referrals,dc=sgallagh,dc
=bos,dc=redhat,dc=com??base?) for (uid=keitaro,cn=users,cn=accounts,dc=referral
s,dc=sgallagh,dc=bos,dc=redhat,dc=com)
[06/Dec/2011:13:53:46 -0500] - WARNING: 'get_entry' can't find entry 'uid=keita
ro,cn=users,cn=accounts,dc=referrals,dc=sgallagh,dc=bos,dc=redhat,dc=com', err
10
[06/Dec/2011:13:53:46 -0500] - modify_update_last_modified_attr
[06/Dec/2011:13:53:46 -0500] - Calling plugin '7-bit check' 0 type 405
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'ACL preoperation' 1 type 405
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.12)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NOT FOUND)
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.18)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NOT FOUND)
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Auto Membership Plugin' 2 type
405
[06/Dec/2011:13:53:46 -0500] auto-membership-plugin - --> automember_pre_op
[06/Dec/2011:13:53:46 -0500] auto-membership-plugin - --> automember_get_dn
[06/Dec/2011:13:53:46 -0500] auto-membership-plugin - <-- automember_get_dn
[06/Dec/2011:13:53:46 -0500] auto-membership-plugin - -->
automember_dn_is_config
[06/Dec/2011:13:53:46 -0500] auto-membership-plugin - <--
automember_dn_is_config
[06/Dec/2011:13:53:46 -0500] auto-membership-plugin - <-- automember_pre_op
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Distributed Numeric Assignment
Plugin' 4 type 405
[06/Dec/2011:13:53:46 -0500] dna-plugin - --> dna_pre_op
[06/Dec/2011:13:53:46 -0500] dna-plugin - --> dna_get_dn
[06/Dec/2011:13:53:46 -0500] dna-plugin - <-- dna_get_dn
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.12)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.18)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=5
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=4
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => compute_limits: sizelimit=-1, timelimit=-1
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'ACL preoperation' 1 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'deref' 3 type 403
[06/Dec/2011:13:53:46 -0500] deref-plugin - --> deref_pre_search
[06/Dec/2011:13:53:46 -0500] deref-plugin - <-- deref_pre_op
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Legacy replication preoperation
plugin' 13 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Multimaster replication
preoperation plugin' 16 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'schema-compat-plugin-preop' 18
type 403
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=0
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => find_entry_internal (dn=uid=keitaro,cn=users,
cn=accounts,dc=referrals,dc=sgallagh,dc=bos,dc=redhat,dc=com) lock 0
[06/Dec/2011:13:53:46 -0500] - => dn2entry "uid=keitaro,cn=users,cn=accounts,dc
=referrals,dc=sgallagh,dc=bos,dc=redhat,dc=com"
[06/Dec/2011:13:53:46 -0500] - <= dn2entry 7faff4007aa0
[06/Dec/2011:13:53:46 -0500] - => send_ldap_result 10::
[06/Dec/2011:13:53:46 -0500] - <= send_ldap_result
[06/Dec/2011:13:53:46 -0500] - <= find_entry_internal_dn sent referral to (ldap
://ipaserver:389/uid=kurashima,cn=users,cn=accounts,dc=referrals,dc=sgallagh,dc
=bos,dc=redhat,dc=com??base?) for (uid=keitaro,cn=users,cn=accounts,dc=referral
s,dc=sgallagh,dc=bos,dc=redhat,dc=com)
[06/Dec/2011:13:53:46 -0500] dna-plugin - <-- dna_pre_op
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'IPA UUID' 7 type 405
[06/Dec/2011:13:53:46 -0500] ipauuid_pre_op - --in-->
[06/Dec/2011:13:53:46 -0500] ipauuid_get_dn - --in-->
[06/Dec/2011:13:53:46 -0500] ipauuid_get_dn - <--out--
[06/Dec/2011:13:53:46 -0500] ipauuid_dn_is_config - --in-->
[06/Dec/2011:13:53:46 -0500] ipauuid_dn_is_config - <--out--
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.12)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.18)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=5
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=4
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => compute_limits: sizelimit=-1, timelimit=-1
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'ACL preoperation' 1 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'deref' 3 type 403
[06/Dec/2011:13:53:46 -0500] deref-plugin - --> deref_pre_search
[06/Dec/2011:13:53:46 -0500] deref-plugin - <-- deref_pre_op
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Legacy replication preoperation
plugin' 13 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Multimaster replication
preoperation plugin' 16 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'schema-compat-plugin-preop' 18
type 403
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=0
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => find_entry_internal (dn=uid=keitaro,cn=users,
cn=accounts,dc=referrals,dc=sgallagh,dc=bos,dc=redhat,dc=com) lock 0
[06/Dec/2011:13:53:46 -0500] - => dn2entry "uid=keitaro,cn=users,cn=accounts,dc
=referrals,dc=sgallagh,dc=bos,dc=redhat,dc=com"
[06/Dec/2011:13:53:46 -0500] - <= dn2entry 7faff4007aa0
[06/Dec/2011:13:53:46 -0500] - => send_ldap_result 10::
[06/Dec/2011:13:53:46 -0500] - <= send_ldap_result
[06/Dec/2011:13:53:46 -0500] - <= find_entry_internal_dn sent referral to (ldap
://ipaserver:389/uid=kurashima,cn=users,cn=accounts,dc=referrals,dc=sgallagh,dc
=bos,dc=redhat,dc=com??base?) for (uid=keitaro,cn=users,cn=accounts,dc=referral
s,dc=sgallagh,dc=bos,dc=redhat,dc=com)
[06/Dec/2011:13:53:46 -0500] - => send_ldap_result 10::
[06/Dec/2011:13:53:46 -0500] - <= send_ldap_result
[06/Dec/2011:13:53:46 -0500] ipauuid_pre_op - <--out--
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c560, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.12)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.18)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=5
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=4
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => compute_limits: sizelimit=-1, timelimit=-1
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'ACL preoperation' 1 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'deref' 3 type 403
[06/Dec/2011:13:53:46 -0500] deref-plugin - --> deref_pre_search
[06/Dec/2011:13:53:46 -0500] deref-plugin - <-- deref_pre_op
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Legacy replication preoperation
plugin' 13 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Multimaster replication
preoperation plugin' 16 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'schema-compat-plugin-preop' 18
type 403
[06/Dec/2011:13:53:46 -0500] - defbackend_default
[06/Dec/2011:13:53:46 -0500] - => send_ldap_result 32::
[06/Dec/2011:13:53:46 -0500] - <= send_ldap_result
[06/Dec/2011:13:53:46 -0500] - => reslimit_update_from_entry() conn=0x24e0c560,
entry=0x0
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 0 (based on nsLookThroughLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 1 (based on nsIDListScanLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 2 (based on nsPagedLookThroughLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 3 (based on nsPagedIDListScanLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 4 (based on nsSizeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 5 (based on nsTimeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 6 (based on nsPagedSizeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 7 (based on nsIdleTimeout)
[06/Dec/2011:13:53:46 -0500] - <= reslimit_update_from_entry() returning status
0
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c560, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c800, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
SUCCESS, value=0
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c6b0, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c410, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - add_pb
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c560, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.12)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - => slapi_control_present (looking for
2.16.840.1.113730.3.4.18)
[06/Dec/2011:13:53:46 -0500] - <= slapi_control_present 0 (NO CONTROLS)
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=5
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit() conn=0x0,
handle=4
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => compute_limits: sizelimit=-1, timelimit=-1
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'ACL preoperation' 1 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'deref' 3 type 403
[06/Dec/2011:13:53:46 -0500] deref-plugin - --> deref_pre_search
[06/Dec/2011:13:53:46 -0500] deref-plugin - <-- deref_pre_op
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Legacy replication preoperation
plugin' 13 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'Multimaster replication
preoperation plugin' 16 type 403
[06/Dec/2011:13:53:46 -0500] - Calling plugin 'schema-compat-plugin-preop' 18
type 403
[06/Dec/2011:13:53:46 -0500] - defbackend_default
[06/Dec/2011:13:53:46 -0500] - => send_ldap_result 32::
[06/Dec/2011:13:53:46 -0500] - <= send_ldap_result
[06/Dec/2011:13:53:46 -0500] - => reslimit_update_from_entry() conn=0x24e0c560,
entry=0x0
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 0 (based on nsLookThroughLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 1 (based on nsIDListScanLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 2 (based on nsPagedLookThroughLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 3 (based on nsPagedIDListScanLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 4 (based on nsSizeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 5 (based on nsTimeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 6 (based on nsPagedSizeLimit)
[06/Dec/2011:13:53:46 -0500] - reslimit_update_from_entry(): setting limit for
handle 7 (based on nsIdleTimeout)
[06/Dec/2011:13:53:46 -0500] - <= reslimit_update_from_entry() returning status
0
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c560, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c800, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
SUCCESS, value=0
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c6b0, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - => slapi_reslimit_get_integer_limit()
conn=0x24e0c410, handle=7
[06/Dec/2011:13:53:46 -0500] - <= slapi_reslimit_get_integer_limit() returning
NO VALUE
[06/Dec/2011:13:53:46 -0500] - get_pb
[06/Dec/2011:13:53:46 -0500] - do_unbind
[06/Dec/2011:13:53:46 -0500] - => get_ldapmessage_controls
[06/Dec/2011:13:53:46 -0500] - <= get_ldapmessage_controls no controls
[06/Dec/2011:13:53:46 -0500] - defbackend_noop
[06/Dec/2011:13:53:47 -0500] - => reslimit_update_from_entry() conn=0x24e0c950,
entry=0x0
[06/Dec/2011:13:53:47 -0500] - reslimit_update_from_entry(): setting limit for
handle 0 (based on nsLookThroughLimit)
[06/Dec/2011:13:53:47 -0500] - reslimit_update_from_entry(): setting limit for
handle 1 (based on nsIDListScanLimit)
[06/Dec/2011:13:53:47 -0500] - reslimit_update_from_entry(): setting limit for
handle 2 (based on nsPagedLookThroughLimit)
[06/Dec/2011:13:53:47 -0500] - reslimit_update_from_entry(): setting limit for
handle 3 (based on nsPagedIDListScanLimit)
[06/Dec/2011:13:53:47 -0500] - reslimit_update_from_entry(): setting limit for
handle 4 (based on nsSizeLimit)
[06/Dec/2011:13:53:47 -0500] - reslimit_update_from_entry(): setting limit for
handle 5 (based on nsTimeLimit)
[06/Dec/2011:13:53:47 -0500] - reslimit_update_from_entry(): setting limit for
handle 6 (based on nsPagedSizeLimit)
[06/Dec/2011:13:53:47 -0500] - reslimit_update_from_entry(): setting limit for
handle 7 (based on nsIdleTimeout)
[06/Dec/2011:13:53:47 -0500] - <= reslimit_update_from_entry() returning status
0
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/49
https://bugzilla.redhat.com/show_bug.cgi?id=698771
We need to better handle the case where a server is shutdown while a long
running task is active e.g. fixup-memberof.
Tasks should check to see if the server is shutdown and gracefully exit.
For some tasks that will leave the database in a inconsistent state, we could
do one of two things:
1) the server will refuse to shutdown until all tasks are finished
2) the server will print an ugly error message to the log: "hey, you killed me
before I could finish task X - the database will be in an inconsistent state
until you let the task complete"
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/33
https://bugzilla.redhat.com/show_bug.cgi?id=736431
Description of problem:
Anthony Messina 2011-09-05 23:18:59 EDT
Using 389-ds-base-1.2.9.9-1.fc15.x86_64
I see the following when backing up the db:
[05/Sep/2011:03:30:11 -0500] ldif2dbm - _get_and_add_parent_rdns: Failed to
position at ID 29
[05/Sep/2011:03:30:11 -0500] - ldbm2ldif: Failed to get dn of ID 29
[05/Sep/2011:03:30:11 -0500] - export userRoot: Processed 359 entries (100%).
[05/Sep/2011:03:30:11 -0500] - All database threads now stopped
[05/Sep/2011:03:30:11 -0500] - export NetscapeRoot: Processed 109 entries
(100%).
[05/Sep/2011:03:30:11 -0500] - All database threads now stopped
389-Directory/1.2.9.9 B2011.244.2041
And the following later on:
[05/Sep/2011:14:11:59 -0500] _entry_set_tombstone_rdn - Failed to convert DN
uid=aae5b81917538f54cabd7e7d290db106 to RDN
[05/Sep/2011:14:11:59 -0500] id2entry - str2entry returned NULL for id 30,
string="rdn"
[05/Sep/2011:22:13:08 -0500] _entry_set_tombstone_rdn - Failed to convert DN
uid=aae5b81917538f54cabd7e7d290db106 to RDN
[05/Sep/2011:22:13:08 -0500] id2entry - str2entry returned NULL for id 30,
string="rdn"
[05/Sep/2011:22:13:45 -0500] _entry_set_tombstone_rdn - Failed to convert DN
uid=aae5b81917538f54cabd7e7d290db106 to RDN
[05/Sep/2011:22:13:45 -0500] id2entry - str2entry returned NULL for id 30,
string="rdn"
[reply] [-]
Private
Comment 5 Noriko Hosoi 2011-09-06 12:49:13 EDT
Hi Anthony,
Could it be possible to post the output from these command lines?
dbscan -f /path/to/db/userRoot/id2entry.db4 -K 29
dbscan -f /path/to/db/userRoot/id2entry.db4 -K 30
Thanks,
--noriko
[reply] [-]
Private
Comment 6 Anthony Messina 2011-09-06 13:36:10 EDT
Sure, they both come from entries that were deleted. The first one is gone
from the DB. The second doesn't show up during an ldapsearch, but is avaiable
via the command below:
# dbscan -f /var/lib/dirsrv/slapd-ds/db/userRoot/id2entry.db4 -K 29
Can't set cursor to returned item: DB_NOTFOUND: No matching key/data pair found
# dbscan -f /var/lib/dirsrv/slapd-ds/db/userRoot/id2entry.db4 -K 30
id 30
rdn:
nsuniqueid=de6aa638-282011df-a269e3fe-897a001a,uid=aae5b81917538f54cabd7e
7d290db106
nsUniqueId: de6aa638-282011df-a269e3fe-897a001a
<entry snipped>
[reply] [-]
Private
Comment 7 Noriko Hosoi 2011-09-06 18:53:35 EDT
Thanks, Anthony. I tried to duplicate your problem, but so far no luck.
It looks you have some deleted entries which are turned to tombstone entries
once (entry 29 and 30). Then, some of them are reaped (entry 29). I wonder if
entry 29 could have been a parent of entry 30? (I don't think a parent can be
deleted prior to its child, so I'm not sure how it could happen if it is the
case...) But this could be just my imagination. I guess we need more detailed
data to investigate the problem.
Do you happen to have steps to reproduce the problem?
[reply] [-]
Private
Comment 8 Anthony Messina 2011-09-07 05:38:35 EDT
(In reply to comment 7)
> Thanks, Anthony. I tried to duplicate your problem, but so far no luck.
>
> It looks you have some deleted entries which are turned to tombstone entries
> once (entry 29 and 30). Then, some of them are reaped (entry 29). I wonder
if
> entry 29 could have been a parent of entry 30? (I don't think a parent can
be
> deleted prior to its child, so I'm not sure how it could happen if it is the
> case...) But this could be just my imagination. I guess we need more
detailed
> data to investigate the problem.
>
> Do you happen to have steps to reproduce the problem?
I believe you are right when you say that 29 was a parent of 30. In fact, the
30 entry I have was deleted at the same time as its parent (29) via the
389-console.
It would have had the following structure:
uid=aae5b81917538f54cabd7e7d290db106,cn=user1,ou=personal,ou=contacts,ou=messin
et.com,ou=eGW,dc=messinet,dc=com
and cn=user1,ou=personal,ou=contacts,ou=messinet.com,ou=eGW,dc=messinet,dc=com
was the entry I deleted via 389-console.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/19
https://bugzilla.redhat.com/show_bug.cgi?id=749882
The original motivation came from the bug 745259.
This bug just takes care of the conversion part.
+++ This bug was initially created as a clone of Bug 745259 +++
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101
Firefox/7.0.1
The entryusn.db4 index is not maintained correctly when a large number of
replicated operations arrive almost simultaneously. As a result, several
entryusn numbers in the index may correspond to one entryid and the searches on
entryusn return incorrect results.
Manual reindexing on entryusn resolves the problem.
Reproducible: Always
Steps to Reproduce:
I will describe our configuration where it is reproducible every time.
1. Configure three 389ds servers (in our case, it's 1.2.9.8 version with the
additional bugfix patch for the bug 735121).
2. Configure multimaster replication from each server to two others. While
configuring replicas, exclude entryusn and memberOf from replication.
Important: do not disable the replication of modifyTimestamp or modifiersName.
It's thanks to these attributes that a high load may be produced in this
configuration.
3. Create a sufficiently large groups with nested subgroups (~200 entries per
group is usually sufficient).
4. In a single (it is important!) operation make a replace or add/delete of all
or many uniqueMember attribute values of the group. It will generate the
following events :
* an avalanche of changes of the memberOf and entryusn attributes in a lot of
entries. These changes are not replicated, so it's ok.
* each changed entry has its modifyTimestamp and modifiersName attribute
changed at first directly and then by memberOf plugin.
* the changes are replicated to two other replicas. On these replicas memberOf
replaces the corresponding attributes and once again change modifyTimestamp and
modifiersName.
* As a result for each change we have two "returns to the sender" from two
replicas because of modifyTimestamp and modifiersName. Here is the typical ldap
audit log example :
time: 20111011210009
dn: cn=groupe dsi restreint,ou=par entite,ou=groupes
globaux,ou=groupes,dc=id,dc=polytechnique,dc=edu
changetype: modify
add: uniqueMember
uniqueMember: uid=andrey.ivanov,ou=Personnel,ou=Utilisateurs,dc=id,dc=polytech
nique,dc=edu
-
replace: modifiersname
modifiersname: cn=X LDAP Root
-
replace: modifytimestamp
modifytimestamp: 20111011190009Z
-
replace: entryusn
entryusn: 69538
-
time: 20111011210011
dn:
uid=andrey.ivanov,ou=personnel,ou=utilisateurs,dc=id,dc=polytechnique,dc=edu
changetype: modify
replace: modifiersName
modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config
-
replace: modifyTimestamp
modifyTimestamp: 20111011190011Z
-
replace: entryusn
entryusn: 69542
-
time: 20111011210015
dn:
uid=andrey.ivanov,ou=personnel,ou=utilisateurs,dc=id,dc=polytechnique,dc=edu
changetype: modify
replace: modifiersName
modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config
-
replace: modifyTimestamp
modifyTimestamp: 20111011190016Z
-
replace: entryusn
entryusn: 69545
-
So, to resume, one change of the first replica generates two "returned"
replicated operations. With a sufficiently large initial group modification we
have a sufficiently large number of changes arriving at the same moment.
Actual Results:
After this operation the examining of entryusn index shows a large site of
duplicates. Here is an example :
dbscan -r -f entryusn.db4|less
=69294
649
=69357
649
=69387
649
=69490
649
=69511
649
The entry with id 649 (in id2entry.db4) contains 69511 (on two other replicas
entryusn for this entry is 69891 and 69780, so the replication of entryusn is
out of game).
The number of duplicates can easily be found by comparing the number of all
entries and unique entries :
dbscan -r -f entryusn.db4| grep -v ^= | sort |wc
5232 12074 71602
dbscan -r -f entryusn.db4| grep -v ^= | sort |uniq|wc
5109 11951 70820
The searches of entryUSN=smth and entryUSN>=smth, naturally, do not return the
expected results since the index is corrupted.
Expected Results:
I am unable te reproduce the problem without replication or by changing just
one single independent attribute (like 'description').
I think this problem has to do something with heavy internal updates (memberOf
plugin) and a lot of replicated entries arriving simultaneously.
Reindexing recreates the index correctly:
db2index.pl -v -D "cn=Directory Manager" -w - -n userRoot -t entryusn
...
dbscan -r -f entryusn.db4| grep -v ^= | sort |wc
5109 11951 70820
dbscan -r -f entryusn.db4| grep -v ^= | sort |uniq|wc
5109 11951 70820
--- Additional comment from [email protected] on 2011-10-11
16:11:52 EDT ---
The ldap audit log for the entry id 649 producing the index entryusn.db4 file
shown above :
time: 20111011205652
dn:
uid=gilles.delobel,ou=personnel,ou=utilisateurs,dc=id,dc=polytechnique,dc=edu
changetype: modify
replace: modifiersName
modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config
-
replace: modifyTimestamp
modifyTimestamp: 20111011185649Z
-
replace: entryusn
entryusn: 69294
-
<...some other operations...>
time: 20111011205652
dn:
uid=gilles.delobel,ou=personnel,ou=utilisateurs,dc=id,dc=polytechnique,dc=edu
changetype: modify
replace: modifiersName
modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config
-
replace: modifyTimestamp
modifyTimestamp: 20111011185649Z
-
replace: entryusn
entryusn: 69324
-
<...some other operations...>
time: 20111011205655
dn:
uid=gilles.delobel,ou=personnel,ou=utilisateurs,dc=id,dc=polytechnique,dc=edu
changetype: modify
replace: modifiersName
modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config
-
replace: modifyTimestamp
modifyTimestamp: 20111011185648Z
-
replace: entryusn
entryusn: 69357
-
<...some other operations...>
time: 20111011205655
dn:
uid=gilles.delobel,ou=personnel,ou=utilisateurs,dc=id,dc=polytechnique,dc=edu
changetype: modify
replace: modifiersName
modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config
-
replace: modifyTimestamp
modifyTimestamp: 20111011185649Z
-
replace: entryusn
entryusn: 69387
-
<...some other operations...>
time: 20111011205658
dn:
uid=gilles.delobel,ou=personnel,ou=utilisateurs,dc=id,dc=polytechnique,dc=edu
changetype: modify
replace: modifiersName
modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config
-
replace: modifyTimestamp
modifyTimestamp: 20111011185656Z
-
replace: entryusn
entryusn: 69428
-
<...some other operations...>
time: 20111011205701
dn:
uid=gilles.delobel,ou=personnel,ou=utilisateurs,dc=id,dc=polytechnique,dc=edu
changetype: modify
replace: modifiersName
modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config
-
replace: modifyTimestamp
modifyTimestamp: 20111011185655Z
-
replace: entryusn
entryusn: 69490
-
<...some other operations...>
time: 20111011205701
dn:
uid=gilles.delobel,ou=personnel,ou=utilisateurs,dc=id,dc=polytechnique,dc=edu
changetype: modify
replace: modifiersName
modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config
-
replace: modifyTimestamp
modifyTimestamp: 20111011185655Z
-
replace: entryusn
entryusn: 69511
-
--- Additional comment from [email protected] on 2011-10-11
16:15:13 EDT ---
OS - CentOS 5.7 x86_64 with all the latest patches.
--- Additional comment from [email protected] on 2011-10-12
08:07:33 EDT ---
Actually, a high load is not necessary. I've just made another test - a single
uniquemember modify operation in a group causes the cache to be corrupted on
two or three replicas. Here is the ldif for the change :
dn: cn=SomeGroup,ou=Groups,dc=example,dc=com
changetype: modify
add: uniqueMember
uniqueMember: uid=mylogin,ou=Users,dc=example,dc=com
The duplicates in entryusn are produced for the entry referenced in
uniqueMember (the entry memberOf works with). Depending on the replica there
may be up to 5 duplicates (entryid 8217 in this example):
dbscan -r -f entryusn.db4
=70067
10789
=70069
8217
=70070
10895
=70071
8217
=70072
8217
=70074
8217
=70075
8217
=70079
11569
The entryid 11569 corresponds to the nsTombstone with
nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff (RUV vectors). 10895 and 10789
are the entryid of the groups for which the entry membership changes.
--- Additional comment from [email protected] on 2011-10-12 10:02:44 EDT ---
Sounds like the entryusn functionality is a good candidate for conversion to a
betxnpreop/betxnpostop plugin.
--- Additional comment from [email protected] on 2011-10-12 13:02:04 EDT ---
Hi Andrey,
Could you check if you configure the fractional replication on the memberof
attribute? We highly recommend to set it up. Please see "IMPORTANT" in
"11.1.4. Using the memberOf Attribute to Manage Group Membership Information".
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administrat
ion_Guide/Advanced_Entry_Management.html#groups-memberof-configuring
Also, could you check if "conflicts" occurred in the replica?
But still the corruption of the entryusn index is bad... Once it happens, we
have to ask to reindex the entryUSN attribute, which would be very painful.
(In reply to comment 4)
> Sounds like the entryusn functionality is a good candidate for conversion to
a
> betxnpreop/betxnpostop plugin.
May not be that easy... W/o replication, the backend is serialized (by
default), but the backend allows simultaneous updates to the replicated
operations. If 2 updates on the same entry are replicated almost at the same
time, each grabs the same pre-updated entry and do the operations in parallel.
On each thread, entryUSN plugin increments the attribute by one and replaces
the old entryUSN with the new one. For the increments, it uses slapi-counter
which is guaranteed atomic. That's said, 2 entryUSNs would appear in the
entryUSN index pointing the same entry. And the entry contains just one
entryUSN, which would be the one overrides the other. (It even may not be the
largest value... ): This problem may not be solved even if we convert entryUSN
to betxnpreop/betxnpostop since betxnpreop just reads the data from the
not-yet-committed database... But it's worth trying.
--- Additional comment from [email protected] on 2011-10-12
13:35:49 EDT ---
Hi Noriko,
Yes, i have disabled the replication of memberOf and entryUSN (as i described
in my initial description of the problem:
----------------
2. Configure multimaster replication from each server to two others. While
configuring replicas, exclude entryusn and memberOf from replication.
--------------
)
Here is a part of the replicated agreement configuration:
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE entryusn memberOf
You can also see in audit logs that it is the attributes 'modifiersName' and
'modifyTimestamp' that are replicated, not 'memberOf'. I cannot disable the
replication of these attributes, especially 'modifiersName'...
I think your description is pretty close to what i observe and what's going on
in our system. I have also encountered the part "(It even may not be the
largest value... )" - that's actually how i have found this bug. The entry had
entryUSN, say, entryUSN=10 and the ldapsearch returned this entry even with the
filter '(entryUSN>=15)'. The entryusn.db4 index file contained in fact (along
with the correct '10' value) the USNs larger than 10 for the entry.
I've stumbled upon this bug while i was writing an optimisation for one of our
scripts. This optimisation is using entryUSN to work on recently modified sets
of entries instead of making each time a complete directory server search.
--- Additional comment from [email protected] on 2011-10-12 14:02:36 EDT ---
Thanks for the confirmation, Andrey. I see. So, replicating modifiersName and
modifyTimestamp could be one of the causes for this problem. I also double
checked with Nathan that these internal modify attributes are not allowed to
put into the no-replicate list... :(
We have to try the betxn conversion first to see how it improves the
behaviour...
--- Additional comment from [email protected] on 2011-10-12
15:30:55 EDT ---
If the index updates are also integrated into the transactions then betxn
conversion may work (the entryusn index will be updated, maintained and
non-corrupted in each parallel transaction and commited at the end of each
transaction with its integrity conserved, so the last finished transaction will
commit its correct index and entry attribute at the same time).
As for modifiersName and modifyTimestamp, they are generated by memberOf
plugin. Some time ago i have filed a bug to have an option of disabling the
update of internally updated attributes by memberOf
(https://bugzilla.redhat.com/show_bug.cgi?id=453756). It would also resolve our
current entryusn index problem...
--- Additional comment from [email protected] on 2011-10-18 13:30:09 EDT ---
Discussion with the IPA team:
Simo>
we use it in sssd in order to get updates only for new entries
being changed wrt the last time we searched. Returning more entries will
make it inefficient but luckily not cause real issues.
Martin>
I checked the server side. All we do with entryUSN is that we enable the
> USN plugin (cn=USN,cn=plugins,cn=config) when setting up a replication
> agreement. Then we attempt to add entryusn attribute to excludes list to
> the replication agreement on the replicas:
>
> ipaserver/install/replication.py:
> # List of attributes that need to be excluded from replication.
> excludes = ('memberof', 'entryusn',
> 'krblastsuccessfulauth',
> 'krblastfailedauth',
> 'krbloginfailedcount')
> ...
> if master is None:
> entry.setValues('nsds5replicaupdateschedule', '0000-2359
0123456')
> entry.setValues('nsDS5ReplicatedAttributeList',
> '(objectclass=*) $ EXCLUDE %s' % "
".join(excludes))
The bug "[Bug 745259] Incorrect entryUSN index under high load in
replicatedenvironment" could add some inefficiency to IPA if there are some
higher dangling entryUSNs, but the chance would be low.
We are going to set the fix target of the bug to IPA3.0 (by making the entryUSN
plugin transaction aware).
--- Additional comment from [email protected] on 2011-10-24 16:39:36 EDT ---
per bug council today 10/24 - DSIPA30
--- Additional comment from [email protected] on 2011-10-24 16:42:03 EDT ---
per bug council today 10/24 - screened
--- Additional comment from [email protected] on 2011-10-26 20:00:31 EDT ---
Created attachment 530413
git patch file (master)
Description:
. Changed the backend entry lock from PR_Lock to PR_Monitor to
allow the re-entrant locking. In ldbm_back_delete and ldbm_
back_modify, backend entry lock was released before calling
be_preop plugins and re-acquired just after that to avoid
the deadlock by the be_preop plugins called from the same
thread. The short no-lock window was the cause of the entry-
usn corruption. By replacing PR_Lock with the re-entrant
PR_Monitor, we could eliminate the no-lock window.
. USN plugin: made add, modify, and modrdn usn plugins
transaction aware.
Note: delete plugins are intact. USN delete operation converts
an entry to a tombstone entry, which is not suitable to move
to inside of the transaction.
Additional changes
. Introduced SLAPI_PLUGIN_BE_TXNABORT_POST_*_FN.
. In ldbm_back_delete, SLAPI_PLUGIN_BE_TXN_PRE/POST_DELETE_FN are
changed to apply just to the normal entries (not to the tombstone
entries).
. Changed the condition to call dblayer_txn_abort from (retry_count
> 0) to (retry_count >= 0) to cover the error in the first trial.
. Cleaned up compiler warnings.
--- Additional comment from [email protected] on 2011-10-26 20:18:41 EDT ---
Created attachment 530415
scripts to reproduce the problem
Contents of the attachement:
script/
script/memofgrpL.sh
script/memofmod1.sh
script/memofmod0.sh
How to reproduce/verify the problem:
1. Set up 2 masters - 1 replica.
M0 <---> M1
\ /
v v
R0
2. Enable USN and memberof plugins on the 3 servers (M0, M1, R0).
3. Edit memofgrpL.sh to adjust SUFFIX, MAXGRP, and MAXUSR
(currently, "dc=example,dc=com", 20, 200, respectively)
4. Run memofgrpL.sh and add the generated ldif to one of the masters (M0).
$ sh -x memofgrpL.sh > memofgrpL.ldif
$ ldapmodify -x -h localhost -p <portM0> -D 'cn=directory manager' -w <pw>
-af memofgrpL.ldif
5. On 2 windows...
5.1 Edit memofmod[01].sh to adjust PORT, PASSWD, and SUFFIX.
PORT: memofmod0.sh sets port of M0; memofmod1.sh sets port of M1
PASSWD: password of Directory Manager for M0 and M1, respectively
SUFFIX: same suffix in memofgrpL.sh
5.2 Run the scripts.
window1> sh memofmod0.sh
window2> sh memofmod1.sh
6. When the scripts finish, run dbscan against the R0's entryusn.db4
# dbscan -f /var/lib/dirsrv/slapd-R0/db/userRoot/entryusn.db4 -r > out
# tail -8 out
=225
231
=2353
12
=2971
10
=2995
13
Entry 12, 10, 13 are the ones frequently modified.
Scan the output file "out" and check if the 3 entryIDs (12, 10, 13)
do not appear twice or more. If not, the bug was verified.
--- Additional comment from [email protected] on 2011-10-28 13:14:19 EDT ---
Comment on attachment 530413
git patch file (master)
Would prefer to see these changes as multiple commits - first commit would be
to fix the initial problem - that is, convert to PRMonitor, and do not unlock
the entry before calling the bepreop plugins.
Then, convert usn to use transactions.
Ideally, if we were using DB_SEQUENCE inside the transaction, we would not need
a pre-abort function, because the actual transaction abort would make sure the
incremented value was not committed. But I can see the logic in having it,
especially for auto-generated values like uuid, csn that cannot make use of
DB_SEQUENCE because they are not simple sequential integers.
The way transaction support has been currently designed is that it allows
pre/post betxn plugins to call internal operations (e.g. do an internal modify
operation) rather than edit the list of mods for the parent operation (which
necessitates moving all of that schema/syntax/etc. checking code into the
transaction loop). If we have to retry the transaction loop (e.g. due to
DB_DEADLOCK), we have to restore everything back to its initial state, then
reapply the mods again. Is this handled? I didn't see this.
Why is it a problem to handle the delete_tombstone_entry?
--- Additional comment from [email protected] on 2011-10-28 13:44:29 EDT ---
(In reply to comment 14)
> Comment on attachment 530413 [details]
> git patch file (master)
>
> Would prefer to see these changes as multiple commits - first commit would be
> to fix the initial problem - that is, convert to PRMonitor, and do not unlock
> the entry before calling the bepreop plugins.
>
> Then, convert usn to use transactions.
All right. I'm going to create 2 patches.
> Ideally, if we were using DB_SEQUENCE inside the transaction, we would not
need
> a pre-abort function, because the actual transaction abort would make sure
the
> incremented value was not committed. But I can see the logic in having it,
> especially for auto-generated values like uuid, csn that cannot make use of
> DB_SEQUENCE because they are not simple sequential integers.
>
> The way transaction support has been currently designed is that it allows
> pre/post betxn plugins to call internal operations (e.g. do an internal
modify
> operation) rather than edit the list of mods for the parent operation (which
> necessitates moving all of that schema/syntax/etc. checking code into the
> transaction loop). If we have to retry the transaction loop (e.g. due to
> DB_DEADLOCK), we have to restore everything back to its initial state, then
> reapply the mods again. Is this handled? I didn't see this.
For USN, it just "replaces" the entryusn value, repeating it is not efficient,
but no harm. I don't think there is no other plugins do this type of
operations. Do you think entryUSN is not appropriate to make transaction
aware? I haven't tested it yet, but converting PR_Lock with PR_Monitor could
solve the original problem. I can revert the transaction changes and run the
test...
> Why is it a problem to handle the delete_tombstone_entry?
Reading ldbm_back_delete, checking & creating a tombstone entry is too
complicated to move to the inside of transaction, I thought...
--- Additional comment from [email protected] on 2011-10-28 14:02:56 EDT ---
(In reply to comment 15)
> (In reply to comment 14)
> > Comment on attachment 530413 [details]
> > git patch file (master)
> >
> > Would prefer to see these changes as multiple commits - first commit would
be
> > to fix the initial problem - that is, convert to PRMonitor, and do not
unlock
> > the entry before calling the bepreop plugins.
> >
> > Then, convert usn to use transactions.
>
> All right. I'm going to create 2 patches.
Thanks.
>
> > Ideally, if we were using DB_SEQUENCE inside the transaction, we would not
need
> > a pre-abort function, because the actual transaction abort would make sure
the
> > incremented value was not committed. But I can see the logic in having it,
> > especially for auto-generated values like uuid, csn that cannot make use of
> > DB_SEQUENCE because they are not simple sequential integers.
> >
> > The way transaction support has been currently designed is that it allows
> > pre/post betxn plugins to call internal operations (e.g. do an internal
modify
> > operation) rather than edit the list of mods for the parent operation
(which
> > necessitates moving all of that schema/syntax/etc. checking code into the
> > transaction loop). If we have to retry the transaction loop (e.g. due to
> > DB_DEADLOCK), we have to restore everything back to its initial state, then
> > reapply the mods again. Is this handled? I didn't see this.
>
> For USN, it just "replaces" the entryusn value, repeating it is not
efficient,
> but no harm. I don't think there is no other plugins do this type of
> operations.
For now. What you have will work for this specific entryusn case. But for the
general case, we will have to revisit this. The way memberof and referint
work, they just perform internal operations, they do not modify the parent's
mods list or add entry or etc. If we want to allow any betxn pre/post plugin
to make changes to the entry to add, mods list, etc., either those plugins will
have to be aware that they can be called multiple times if the transaction
needs to be retried, or the add/modify/etc. code will need to reset all
entries/mods to the condition prior to calling any of the betxn plugins in the
case where a transaction needs to be retried due to DB_DEADLOCK (or other
reasons). The former will make converting plugins difficult, and the latter
will be very tricky to get right (or involve lots and lots of copying/freeing).
> Do you think entryUSN is not appropriate to make transaction
> aware?
I think it is. Any code that generates some value associated with the
operation (dna, usn, csn, uuid) should work like this:
start operation
start transaction
generate value (e.g. usn)
make value available for other plugins to use inside the transaction
commit transaction <- makes next value available for use
or
abort transaction <- rolls back value
When using DB_SEQUENCE, the "generate value" and side effects associated with
commit and abort are done automatically by the db code. I think we should
think a bit more about how to make entryusn transaction aware, with the goal
being to support all of the dna/usn/csn/uuid code.
> I haven't tested it yet, but converting PR_Lock with PR_Monitor could
> solve the original problem. I can revert the transaction changes and run the
> test...
Yes, please.
>
> > Why is it a problem to handle the delete_tombstone_entry?
>
> Reading ldbm_back_delete, checking & creating a tombstone entry is too
> complicated to move to the inside of transaction, I thought...
Ah, ok, I see. You're just doing the same thing for betxn plugins that is
already done for be plugins with respect to the delete_tombstone_entry case.
--- Additional comment from [email protected] on 2011-10-28 14:46:30 EDT ---
Created attachment 530722
git patch file (master)
This patch only contains the PRLock -> PRMonitor changes.
Rerunning the reproducer in Comment 13 against the servers with this patch
applied, the corrupted entryusn index files were not observed.
I'm going to open a new bug for the transaction aware entryUSN since it is
independent from the original bug...
--- Additional comment from [email protected] on 2011-10-28
14:50:21 EDT ---
Hi Noriko and Rich,
i think it's a good idea to make two separate patches. I will then be able to
test the "PR_Lock -> PR_Monitor" patch in our production environment (if
backporting the patch to 1.2.9.10 is going to be simple) where the bug is
reproducible by a single MOD.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/17
https://bugzilla.redhat.com/show_bug.cgi?id=750666
There are some optimizations we can make around validation of replicated data.
In particular, we could skip syntax checking for replicated operations since
the syntax checking of the new values should have been performed on the master
that initially received the operation from a client. This optimization should
help improve performance of replicated operations.
We should add the ability to configure if syntax checking should be skipped for
replicated operations to allow flexibility for different deployments. We also
may want to think if there are other things we could skip around replicated
operations, such as schema checking.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/48
https://bugzilla.redhat.com/show_bug.cgi?id=700200
Description of problem:
There are a list of reserved UIDs within Active Directory which cannot be
synchronized from RHDS to AD. If a uid within RHDS is equal to one of these
values, the initialization of the AD consumer will fail to complete.
Version-Release number of selected component (if applicable):
RHDS 8.2
How reproducible:
100%
Steps to Reproduce:
1. Create an account in an RHDS with a sync agreement to an AD consumer.
2. Enter one of the prohibited words that Active Directory won't allow to be a
uid.
3. Initiate a full sync.
Actual results:
When the user in question is encountered, the following message appears in
/var/log/dirsrv/slapd-<instance>/errors:
[27/Apr/2011:13:04:42 -0500] NSMMReplicationPlugin - agmt="cn=ADSync"
(huey:389): windows_tot_run: failed to obtain data to send to the consumer;
LDAP error - -1
In our case, we used the uid "service".
Expected results:
I would like to see RHDS log the error however continue on with the
initialization rather than aborting.
Additional info:
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/23
https://bugzilla.redhat.com/show_bug.cgi?id=743970
Tracking bug for 389 Directory Server 1.2.10
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/34
https://bugzilla.redhat.com/show_bug.cgi?id=734477
remove-ds.pl leaves some instance specific files/directories around. There
should be some way to tell remove-ds.pl to remove everything - perhaps a --all
could be added to remove everything, even those things that we usually want to
keep around like the databases, the log files, and the key/cert db.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/1
When processing large search filters which are applied to every entry in the search result set, the filter is normalized anew each time a new entry is tested. For substring filters, a regular expression must be created, compiled, and freed each time the substring filter is tested, in addition to normalizing the values. For example, if the search filter contains 1000 substring sub-filters, for each entry tested with the filter, this will require 1000 filter normalizations followed by 1000 regex creation, compilation, and cleanup. If there are 1000 entries in the search result set, this will require a million such operations.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/11
https://bugzilla.redhat.com/show_bug.cgi?id=759009
Description of problem:
In our directory, we have some users with attributes like cn;lang-en,
sn;lang-en, with the same value than cn or sn, but without tildes (?,
?) or "?". When I try to synchronize these users with Active
Directory, I get this error:
[30/Nov/2011:11:58:32 +0100] - Windows sync entry: Created new remote entry:
dn:: XXXXXXX
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: user
userprincipalname: [email protected]
st: XXXXXXX
postalCode: XXXXXXX
postalAddress:: XXXXXXX
streetAddress:: XXXXXXX
facsimileTelephoneNumber: XXXXXXX
telephoneNumber: XXXXXXX
mail: XXXXXXX
o: XXXXXXX
l: XXXXXXX
ou: XXXXXXX
givenName: XXXXXXX
sn:: XXXXXXX
cn:: XXXXXXX
sAMAccountName: XXXXXXX
accountExpires: 0
codePage: 0
sn;lang-en: XXXXXXX
[30/Nov/2011:11:58:32 +0100] - Attempting to add entry
cn=XXXXXXX,ou=LDAPPeople,dc=pruebas,dc=local to AD for local entry
uid=XXXXXXX,ou=People,o=XXXXXXX,dc=XXXXXXX,dc=XXXXXXX
[30/Nov/2011:11:58:32 +0100] NSMMReplicationPlugin - agmt="cn=ll"
(XXXXXXX:636): Received result code 16 (00000057: LdapErr:
DSID-0C090B38, comment: Error in attribute conversion operation, data
0, vece) for add operation
If I remove the attribute "sn;lang-en", the sync works fine.
Attributes with language subtypes should not be synced with Active Directory,
as they are not supported.
Version-Release number of selected component (if applicable): Tested in 1.2.5
How reproducible/Steps to Reproduce/Actual results/Expected results:
1. Modify/Add a user an attribute with subtype language
2. Initiate a full resynchronization
3. The synchronizations fails due to the previous errors
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/24
https://bugzilla.redhat.com/show_bug.cgi?id=743403
The ssl.c code will use the attribute nsTLS1 if defined, but there is no such
attribute defined by the schema, nor will nsEncryptionConfig allow it. We need
to add this attribute to the schema and to objectclass nsEncryptionConfig.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/30
https://bugzilla.redhat.com/show_bug.cgi?id=740081
Description of problem:
There are "pseudo-user" accounts in AD that have mostly "user" objectclass
schema but are missing required attributes in DS, such as the "sn" attribute.
There may be some cases where we want to allow the user to sync these entries:
"I think it might be clearer if we synchronized all accounts that do not use
built-in SIDs (reserved) and are in the correct cn / ou since there is no such
things as a 'psuedo user' in AD. There may be cases where it is desirable for
application users to sync, for example a user used for monitoring could log in
from an application server to Linux / Windows with the same account. This user
might not have all the attributes that a real person would have."
We could fill in the missing values in several ways:
1) hard coded value ("Missing Surname")
2) set value to use in winsync agreement entry
winsyncMissing: sn Missing Surname
or
winsyncMissing: sn $displayName
or
winsyncMissing: sn (objectclass=ipaWinsyncConfig) sn
the last is similar to what the ipa-winsync plugin does for missing posix
attributes.
The list of well-known SIDs/RIDs is found here - http://git.samba.org/?p=samba.
git;a=blob;f=librpc/idl/security.idl;h=2b6efc5318480606f19f6fe25976fe9514114fbc
;hb=master
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/36
https://bugzilla.redhat.com/show_bug.cgi?id=732127
389 DS should implement "Continuation References in the Search Result" as is
detailed in section 4.5.3 of RFC 4511.
It's useful for example if you are replicating two subtrees with a common
parent and you want to inform the client application that the whole tree is in
another server.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/26
https://bugzilla.redhat.com/show_bug.cgi?id=742317
When multiple naming contexts are available it is hard to find out what a
client should use by default (usually the identity mgmt related tree where to
find users/groups).
It would be really helpful to allow cn=Directory Manager to be able to write
the 'defaultNamingcontext' attribute to the rootdse so that clients do not need
to do strange probings.
AD and also openldap apparently have it so many clients already know how to
handle this attribute.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/46
https://bugzilla.redhat.com/show_bug.cgi?id=700695
Description of problem:
I am attempting to setup Directory 389 in a pure ipv6 environment. I have
added an ldap host (with an AAAA record only) to bind that I will just call
"example.com". During the execution of the setup script, I get to the stage:
Computer name [xxx.com]: example.com
WARNING: There are problems with the hostname.
Could not find an address for hostname 'example.com'.
It looks to me that the script is only searching for ipv4 hosts, and since I'm
in a pure ipv6 environment nothing is found. I can ping6 example.com with no
issues, and dig shows everything is working just fine.
Version-Release number of selected component (if applicable):
1.2.8.2
How reproducible:
Have run the script twice, results are the same. Setup fails at the end when
the host cannot be found. Have only attempted on one machine, since it seems
pretty clear to me what the problem is.
Steps to Reproduce:
1. Setup machine with ipv6 address only
2. Attempt setup with this machine
3. See bug.
Actual results:
N/A
Expected results:
N/A
Additional info:
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/29
https://bugzilla.redhat.com/show_bug.cgi?id=741599
Description of problem:
Samba has added a new objectClass sambaTrustedDomainPassword containing two new
attributes sambaClearTextPassword and sambaTrustedDomainPassword in version 3.2
for storing the domaintrust. The samba3-schema 60samba3.ldif does not include
these, what makes it impossible to establish the domaintrust without adding a
custom ldif.
How reproducible:
net rpc trustdom establish DOMAIN -d10 throws an error about missing
objectClass sambaTrustedDomainPassword
Actual results:
sambaTrustedDomainPassword is not present, net rpc trustdom establish dies with
an error
Expected results:
sambaTrustedDomainPassword is present, net rpc trustdom establish works
Additional info:
Adding following custom schema created from the samba3-schema provided with
samba3 for openldap resolves the problem.
#
###############################################################################
#
#
dn: cn=schema
#
###############################################################################
#
#
attributeTypes: (
1.3.6.1.4.1.7165.2.1.68
NAME 'sambaClearTextPassword'
DESC 'Clear text password (used for trusted domain passwords)'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
SINGLE-VALUE
)
#
###############################################################################
#
#
attributeTypes: (
1.3.6.1.4.1.7165.2.1.69
NAME 'sambaPreviousClearTextPassword'
DESC 'Previous clear text password (used for trusted domain passwords)'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
SINGLE-VALUE
)
#
###############################################################################
#
#
objectClasses: (
1.3.6.1.4.1.7165.2.2.15
NAME 'sambaTrustedDomainPassword'
DESC 'Samba Trusted Domain Password'
SUP top
STRUCTURAL
MUST ( sambaDomainName $ sambaSID $ sambaClearTextPassword $ sambaPwdLastSet
)
MAY ( sambaPreviousClearTextPassword )
)
#
###############################################################################
#
#
Problem also exists on Red Hat Directory Server 8.2, but fixing it upstream in
389 Directory Server will result also in a fix downstream, I hope.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/44
https://bugzilla.redhat.com/show_bug.cgi?id=704295
Description of problem:
Our AD setup has users in ou=$UNIT,ou=Personnel,$BASE and groups in
ou=Groups,ou=Global,$BASE. We have a sync agreement in place for every $UNIT
OU and the Groups OU. The Groups sync can't see any users because they are
outside the scope of itself.
Version-Release number of selected component (if applicable):
1.2.8.3
Actual results:
NSMMReplicationPlugin - received entry from dirsync: CN=Roys\,
Joshua,OU=$UNIT,OU=Personnel,$BASE
NSMMReplicationPlugin - agmt="cn=Org Groups" (dc01:636): map_entry_dn_inbound:
looking for local entry matching AD entry [CN=Roys\,
Joshua,OU=$UNIT,OU=Personnel,$BASE]
NSMMReplicationPlugin - agmt="cn=Org Groups" (dc01:636): map_entry_dn_inbound:
looking for local entry by guid [fd1c....]
NSMMReplicationPlugin - agmt="cn=Org Groups" (dc01:636): map_entry_dn_inbound:
problem looking for guid: -1
NSMMReplicationPlugin - agmt="cn=Org Groups" (dc01:636): map_entry_dn_inbound:
looking for local entry by uid [jroys]
NSMMReplicationPlugin - agmt="cn=Org Groups" (dc01:636): map_entry_dn_inbound:
problem looking for username: -1
dse.ldif snippets:
dn: cn=Org Groups,cn=replica,cn=$BASE,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDSWindowsReplicationAgreement
description: Org Groups
cn: Org Groups
nsds7WindowsReplicaSubtree: ou=Groups,ou=Global,$BASE
nsds7DirectoryReplicaSubtree: ou=Groups,$BASE
nsds7NewWinUserSyncEnabled: off
nsds7NewWinGroupSyncEnabled: on
nsds7WindowsDomain: $DOMAIN
nsDS5ReplicaRoot: $BASE
nsDS5ReplicaHost: dc01.$DOMAIN
nsDS5ReplicaPort: 636
nsDS5ReplicaBindDN: $BINDDN
nsDS5ReplicaTransportInfo: SSL
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaCredentials: $PASS
creatorsName: uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot
modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
createTimestamp: 20110510124714Z
modifyTimestamp: 20110512172057Z
dn: cn=Org $UNIT,cn=replica,$BASE,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDSWindowsReplicationAgreement
description: Org $UNIT
cn: Org $UNIT
nsds7WindowsReplicaSubtree: ou=$UNIT,ou=Personnel,$BASE
nsds7DirectoryReplicaSubtree: ou=$UNIT,ou=People,$BASE
nsds7NewWinUserSyncEnabled: on
nsds7NewWinGroupSyncEnabled: on
nsds7WindowsDomain: $DOMAIN
nsDS5ReplicaRoot: $BASE
nsDS5ReplicaHost: dc01.$DOMAIN
nsDS5ReplicaPort: 636
nsDS5ReplicaBindDN: $BINDDN
nsDS5ReplicaTransportInfo: SSL
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaCredentials: $PASS
creatorsName: uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot
modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
createTimestamp: 20110429190248Z
modifyTimestamp: 20110512172057Z
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/22
https://bugzilla.redhat.com/show_bug.cgi?id=745645
Description of problem:
sendmail supports using ldap routing:
http://www.sendmail.org/m4/ldap_routing.html
This is the schema it expects: http://www.sendmail.org/m4/laser.txt
I'm not sure the draft is complete (it has [[TBD]] in the object class uid
definition.
The 60inetmail.ldif is similar but different. I don't know if they are
compatible or not.
Version-Release number of selected component (if applicable):
389-ds-base-1.2.9.9-1.el5
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/43
https://bugzilla.redhat.com/show_bug.cgi?id=704663
Description of problem:
There is no option to add the subject alternative name to new cert requests
using the gui
Version-Release number of selected component (if applicable):
1.2.5-1
How reproducible:
Steps to Reproduce:
NA
Actual results:
Cannot specify subject alternative name
Expected results:
Additional info:
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/15
https://bugzilla.redhat.com/show_bug.cgi?id=751415
Someone a very long time ago decided it would be a good idea to have rw locks
and implemented them using regular mutexes and condition variables. I suspect
this performs much worse than native pthread rwlocks. Now that we have native
platform support for rwlocks we should use them.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/39
https://bugzilla.redhat.com/show_bug.cgi?id=712294
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101
Firefox/4.0.1
If PAM passthrough plugin is used to process simple binds the account policy
plugin does not update the lastLoginTime attribute. I have not tested the other
aspects of Acoount Policy Plugin (the actions in case of account
inactivity/expiration).
Reproducible: Always
Steps to Reproduce:
1. Configure the account policy plugin to always update the lastLogin:
cn=Account Policy Plugin,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
cn: Account Policy Plugin
nsslapd-pluginPath: libacctpolicy-plugin
nsslapd-pluginInitfunc: acct_policy_init
nsslapd-pluginType: object
nsslapd-pluginEnabled: on
nsslapd-plugin-depends-on-type: database
nsslapd-pluginId: acct-policy
nsslapd-pluginVersion: 1.0
nsslapd-pluginVendor: Hewlett-Packard Company
nsslapd-pluginDescription: Account Policy Plugin
cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: config
alwaysrecordlogin: true
2. Test that the plugin works with a simple or SASL/GSSAPI bind:
ldapsearch -Y GSSAPI -h ldap-server -b "dc=example,dc=com" uid=testuser
lastLoginTime
...
lastLoginTime: 20110610071526Z
...
3. Configure the PAM Passthrough plugin (I tried 2 different values for
pamIDMapMethod: RDN and ENTRY) :
pamMissingSuffix: ALLOW
pamExcludeSuffix: cn=config
pamExcludeSuffix: o=NetscapeRoot
pamIDMapMethod: ENTRY
pamIDAttr: uid
pamFallback: TRUE
pamSecure: TRUE
pamService: ldapserver
pamIncludeSuffix: dc=example,dc=com
4. Try again the SASL/GSSAPI bind. It still updates the lastLoginTime attribute
:
ldapsearch -Y GSSAPI -h ldap-server -b "dc=example,dc=com" uid=testuser
lastLoginTime
...
lastLoginTime: 20110610071827Z
...
5. Now try a simple bind using PAM passthrough (not the userPassword attribute
in the entry!!!) :
ldapsearch -x -H ldap://ldap-server -b "dc=example,dc=com" -D
"uid=testuser,ou=users,dc=example,dc=com" -W uid=testuser lastLoginTime
Enter LDAP Password: <...>
Actual Results:
...
lastLoginTime: 20110610071827Z
...
The lastLoginTime is not updated.
Expected Results:
The lastLoginTime should be updated.
SASL binds and simple binds using the userPassword attribute of the entry
continue to update the lastloginTime attribute but not simple binds using the
PAM Passthrough.
Maybe it is possible to solve the problem by simply changing the plugin
precedences/priorities? Don't know whether this solution may have some other
collateral damage.
If FreeIPA uses the kerberos backend with PAM passthrough in 389DS for simple
LDAP binds, this bug also concerns FreeIPA.
By the way, the wiki is not up to date
(http://directory.fedoraproject.org/wiki/Account_Policy_Design). It uses
loginTimeStamp in all the configuration examples (but shows the correct
lastLoginTime in the schema changes)
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/47
https://bugzilla.redhat.com/show_bug.cgi?id=700627
Description of problem:
The initial port number is hardcoded in the tools. They'd better be
dynamically retrieved from the config file.
# egrep 389 *
bak2db.pl:open(FOO, "| ldapmodify $vstr -h <host> -p 389 -D \"$rootdn\" -w
\"$passwd\" -a" );
db2bak.pl:open(FOO, "| ldapmodify $vstr -h <host> -p 389 -D \"$rootdn\" -w
\"$passwd\" -a" );
db2index.pl: $indexes_list="ldapsearch $vstr -h <host> -p 389 -D
\"$rootdn\" -w \"$passwd\" -s one " .
db2index.pl: $vlvindexes_list="ldapsearch $vstr -h <host> -p 389 -D
\"$rootdn\" -w \"$passwd\" -s sub -b \"cn=\"$instance\", cn=ldbm
database,cn=plugins,cn=config\" \"objectclass=vlvIndex\" cn";
db2index.pl:open(FOO, "| ldapmodify $vstr -h <host> -p 389 -D \"$rootdn\" -w
\"$passwd\" -a" );
db2ldif.pl:open(FOO, "| ldapmodify $vstr -h <host> -p 389 -D \"$rootdn\" -w
\"$passwd\" -a" );
fixup-linkedattrs.pl:open(FOO, "| ldapmodify $vstr -h <host> -p 389 -D
\"$rootdn\" -w \"$passwd\" -a" );
fixup-memberof.pl:open(FOO, "| ldapmodify $vstr -h <host> -p 389 -D
\"$rootdn\" -w \"$passwd\" -a" );
ldif2db.pl:open(FOO, "| ldapmodify $vstr -h <host> -p 389 -D \"$rootdn\" -w
\"$passwd\" -a" );
ldif2ldap:ldapmodify -a -p 389 -D "$1" -w "$2" -f $3
monitor:ldapsearch -p 389 -b "$MDN" -s base "objectClass=*"
ns-accountstatus.pl:$defport= "389";
ns-accountstatus.pl:$port= "389";
ns-activate.pl:$defport= "389";
ns-activate.pl:$port= "389";
ns-inactivate.pl:$defport= "389";
ns-inactivate.pl:$port= "389";
ns-newpwpolicy.pl:$opt_p = "389";
schema-reload.pl:open(FOO, "| ldapmodify $vstr -h <host> -p 389 -D \"$rootdn\"
-w \"$passwd\" -a" );
syntax-validate.pl:open(FOO, "| ldapmodify $vstr -h <host> -p 389 -D
\"$rootdn\" -w \"$passwd\" -a" );
usn-tombstone-cleanup.pl:open(FOO, "| ldapmodify $vstr -h <host> -p 389 -D
\"$rootdn\" -w \"$passwd\" -a" );
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/13
https://bugzilla.redhat.com/show_bug.cgi?id=754474
Description of problem:
slapd process exits when put the database on read only mode while updates are
coming to the server.
Version-Release number of selected component (if applicable):
389 1.2.0
How reproducible:
Sometime
Steps to Reproduce:
1. Put the database on readonly mode while the updates are coming to the
server.
2.
3.
Actual results:
"ns-salpd" process exits.
Expected results:
Additional info:
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/40
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/45
https://bugzilla.redhat.com/show_bug.cgi?id=703311
Description of problem:
Password Policy Entry:
dn: cn="cn=nsPwPolicyEntry,ou=People,dc=example,dc=com",
cn=nsPwPolicyContainer,ou=People,dc=example,dc=com
...
passwordInHistory: 6
passwordHistory: on
...
$ ldapmodify -x -h localhost -p 389 -D 'uid=nd,ou=People,dc=example,dc=com' -w
testpassword
dn: uid=nd, ou=People, dc=example, dc=com
changetype: modify
delete: userPassword
userPassword: testpassword
modifying entry "uid=nd, ou=People, dc=example, dc=com"
ldap_modify: Constraint violation (19)
additional info: password in history
Note: if the value is not given, you can delete the password(s).
$ ldapmodify -x -h localhost -p 389 -D 'uid=nd,ou=People,dc=example,dc=com' -w
testpassword
dn: uid=nd, ou=People, dc=example, dc=com
changetype: modify
delete: userPassword
modifying entry "uid=nd, ou=People, dc=example, dc=com"
Place the Constraint violation is being set:
(gdb) bt
0 check_pw_syntax_ext (pb=0x22b8ac0, sdn=0x7f6750eefbc0,
vals=0x7f671c008590, old_pw=0x7f6750ef1c68, e=0x7f671c001630, mod_op=1,
smods=0x7f6750ef1c70) at ldap/servers/slapd/pw.c:1014
1 0x0000003542689980 in op_shared_allow_pw_change (pb=0x22b8ac0,
mod=0x7f671c0044d0, old_pw=0x7f6750ef1c68, smods=0x7f6750ef1c70)
at ldap/servers/slapd/modify.c:1165
2 0x0000003542687aa6 in do_modify (pb=0x22b8ac0)
at ldap/servers/slapd/modify.c:353
3 0x0000000000413ac4 in connection_dispatch_operation (conn=0x7f67522fd410,
op=0x2658b10, pb=0x22b8ac0) at ldap/servers/slapd/connection.c:583
4 0x00000000004152d4 in connection_threadmain ()
at ldap/servers/slapd/connection.c:2328
5 0x0000003262429633 in _pt_root (arg=0x2652ea0)
at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:187
6 0x0000003252807761 in start_thread (arg=0x7f6750ef2700)
at pthread_create.c:301
7 0x00000032520e098d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) p **va
$3 = {bv = {bv_len = 46,
bv_val = 0x7f671c000a20 "{SSHA}hUBeG9p/rwgLj7WmNZwJcganEQ8eWvLYPsOQ2w=="},
v_csnset = 0x7f671c003880, v_flags = 0}
(gdb) p *vals[0]
$5 = {bv = {bv_len = 12, bv_val = 0x7f671c007160 "testpassword"},
v_csnset = 0x0, v_flags = 0}
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/3
The problem was originally described here: http://lists.fedoraproject.org/pipermail/389-devel/2009-March/001020.html
Shorter description: we noticed that some queries (ldapsearch) to our directory caused a drop in performance, and our log file was filled with the following message:
acl_TestRights - cache overflown
We also noticed that increasing the value ACLPB_MAX_SELECTED_ACLS from 200 to 2000 solved the problem for us. A more permanent solution could be to make this value configurable.
We have made a patch that seems to solve the problem, as far as we have tested. I will upload it as soon as it is ready for review.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/28
https://bugzilla.redhat.com/show_bug.cgi?id=741744
Description of problem:
We are trying to updated safely a few entries in cn=config,cn=ldbm
database,cn=plugins,cn=config in order to change limits.
We are using a modify operation with chained delete/add so that we change these
defaults only if admins haven't set their own.
DS is returning error 53 in this case (Unwilling to Perform).
It should just realize the operation is equivalent to a replace and let the
operation happen.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/37
https://bugzilla.redhat.com/show_bug.cgi?id=726282
Description of actual problem:
When Samba uses ldapsam backend it may be necessary to change "userpassword"
and "sambantpassword" fields synchronously. But password changing in DSGW
changes only "userpassword" field in Directory Server.
To allow this feature I've changed 2 files in the source code of DSGW:
1. I've added this definition to dsgw.h:
#define DSGW_ATTRTYPE_SAMBANTPASSWORD "sambaNTPassword"
2. I've changed domodify.c. Please look at the attachment.
DSGW with these modifications was tested and worked fine for Red Hat Directory
Server 8.1.0-1 and Samba 3.0.33.
If this way of solving the problem is acceptable, it might be better to build
this new feature in DSGW with more flex (allow switch it off and on through the
configuration file).
Additional info:
The modification of domodify.c is based on the code of mkntpwd tool (the work
of Anton Roeckseisen [email protected]) and also contains md4.c source from Samba
source code.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/41
https://bugzilla.redhat.com/show_bug.cgi?id=707028
Description of problem:
When upgrading IPA we shut down dirsrv, reconfigure it to only listen on ldapi,
restart it, apply our updates, then reverse it.
It would be safer if we could pass in the configuration changes on the
command-line rather than changing dse.ldif directly.
It might look something like:
-C cn=config:nsslapd-port=0 -C
cn=config:nsslapd-ldapisocket=/var/run/ipa-update.socket ...
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/27
https://bugzilla.redhat.com/show_bug.cgi?id=741999
I have tried to use a SASL/PLAIN bind in order to do binds with a user id that
is not a DN.
Because SASL mappings can resolve an arbitrary uid into a DN I was hoping to
use that to bind to a directory where anonymous searches are disabled
(therefore the client can't use an anonymous bind to search the DN itself.
Unfortunately it appears the current DS code is not able to perform SASL/PLAIN
authentication. Sasl mapping is incorrectly performed. It happens twice, the
first time it properly maps the provided user name to a DN the second time it
tries to map the found DN again as if it were a user name.
Rich says DS may no be able to properly provide SASL with callback to handle
checking the password.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/25
https://bugzilla.redhat.com/show_bug.cgi?id=742582
The FreeIPA development team reported an issue with ns-slapd hanging when under
load from IPA. (https://fedorahosted.org/freeipa/ticket/1885). I am able to
reproduce this issue on F15 x86_64.
The hang looks to be some sort of deadlock within libdb. When the hang occurs,
the ns-slapd process goes to 100% CPU and doesn't progress. I built a debug
version of 389-ds-base and db4, and was able to get some interesting stack
traces from 3 threads that seem to contribute to this problem. There is one
thread doing a write to the memberOf index db, another thread doing a read from
the memberOf index db, and the checkpoint thread attempting to do a checkpoint.
These threads all seem to be yielding or waiting for a mutex.
The db_stat tool doesn't show anything waiting for locks, so it seems to be
something more internal to libdb.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/5
https://bugzilla.redhat.com/show_bug.cgi?id=770705
Upgrade 389-ds-base from 1.2.2-1.el5 to 1.2.9.9-1.el5.
The server refuses to start, the error log complains:
[28/Dec/2011:06:24:16 -0600] - nsslapd-subtree-rename-switch is on, while the
in
stance userRoot is in the DN format. Please run dn2rdn to convert the database
format.
[28/Dec/2011:06:24:16 -0600] - nsslapd-subtree-rename-switch is on, while the
instance NetscapeRoot is in the DN format. Please run dn2rdn to convert the
databa
se format.[28/Dec/2011:06:24:16 -0600] - start: Failed to start databases,
err=-1 Unknown
error: -1[28/Dec/2011:06:24:16 -0600] - Failed to start database plugin ldbm
database[28/Dec/2011:06:24:16 -0600] - WARNING: ldbm instance userRoot already
exists
[28/Dec/2011:06:24:16 -0600] - WARNING: ldbm instance NetscapeRoot already
exists
Discover that dn2rdn is called from setup-ds.pl, so we run "setup-ds.pl -u". No
idea why the RPM postinstall script doesn't "do the right thing".
We run "setup-ds.pl -u" and it emits thousands of warnings, one for each entry
in the database:
[28/Dec/2011:06:37:16 -0600] - userRoot: WARNING: skipping an entry with a
corrupted dn (syntax value): zzz0107A (id 63863)
[28/Dec/2011:06:37:16 -0600] - userRoot: WARNING: skipping an entry with a
corrupted dn (syntax value): zzz MS E (id 63864)
[28/Dec/2011:06:37:16 -0600] - userRoot: WARNING: skipping an entry with a
corrupted dn (syntax value): zzz0111A (id 63865)
[28/Dec/2011:06:37:16 -0600] - userRoot: WARNING: skipping an entry with a
corrupted dn (syntax value): zzz DR I (id 63866)
At the end up the upgrade process, the database is completely empty, all data
has been destroyed.
The message "skipping an entry with a corrupted dn (syntax value)" is too vague
to be useful - it doesn't say what DN, it doesn't say what syntax value, so I'm
in the dark as what action to take.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/2
Bug 736431 - parent tombstone entry could be reaped even if its child tombstone entries still exist
Bug 737811 - tombstone entries are not deleted completely
Bug 767024 - MMR: when a subtree is deleted and the backend is exported with -r, importing the ldif fails
Bug description:
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/12
https://bugzilla.redhat.com/show_bug.cgi?id=755119
Description of problem:
There appears to be a race failing when the DNA Plugin attempts to make a uid
range replication request backed by gssapi.
Version-Release number of selected component (if applicable):
389-ds-base-libs-1.2.10-0.5.a5.fc15.x86_64
389-ds-base-1.2.10-0.5.a5.fc15.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Install IPA Server (ipa-server-install)
2. Prepare Replica (ipa-replica-prepare replica-hostname)
3. Transfer resulting replica-hostname.gpg
4. Install Replica (ipa-replica-install replica-hostname.gpg)
5. kinit admin
6. Attempt to create new user (ipa user-add test)
Actual results:
ipa: ERROR: Operations error: Allocation of a new value for range cn=posix
ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed!
Unable to proceed.
Expected results:
Expected new user to be added and range to be transferred.
Additional info:
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/42
https://bugzilla.redhat.com/show_bug.cgi?id=705222
The aci on cn=monitor references an attribute named "connection" - the aci code
warns because this attribute is not in the schema. The effect is that the aci
code ignores the aci.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/50
https://bugzilla.redhat.com/show_bug.cgi?id=698770
The directory server crashes if it is shutdown before a long running task can
complete
https://bugzilla.redhat.com/show_bug.cgi?id=698421
the reason is that a plugin postop function is being called after the plugin
close function has been called. Once the server calls the plugin close
function, the plugin should be removed from the list of active plugins, and
plugin_free should be called on that plugin.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/21
https://bugzilla.redhat.com/show_bug.cgi?id=746350
If the access log cannot be opened there is an error reported in errors log.
But it doesn;t give any reason why the access log file couldn't be opened.
The errno should be returned at least.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/4
Reported on http://lists.fedoraproject.org/pipermail/389-users/2012-January/013944.html
In my environment I have a total of 4 directory servers, 2 multi-masters in production (ServerA, ServerB) and 2 multi-masters to test with (ServerC, ServerD). Basically here’s what I did:
Took a backup of one of the production directory servers, ServerA
Copied ServerA’s backup to ServerC (test).
Deleted the replication agreement on ServerC to ServerD (but not the agreement from ServerD to ServerC)
Ran /usr/lib64/dirsrv/slapd-ServerC/bak2db 2011_12_29_15_27_35
The restore started, and never stopped running. I eventually killed it and tried again, this time capturing the output:
[03/Jan/2012:15:06:43 -0700] 389-Directory/1.2.9.9 - debug level: backend (524288)
[03/Jan/2012:15:06:43 -0700] - Deleting log file: (/var/lib/dirsrv/slapd-ServerC/db/log.0000000021)
[03/Jan/2012:15:06:43 -0700] - Restoring file 1 (/var/lib/dirsrv/slapd-ServerC/db/DBVERSION)
[03/Jan/2012:15:06:43 -0700] - Copying /var/lib/dirsrv/slapd-ServerC/bak/2011_12_29_15_27_35/DBVERSION to /var/lib/dirsrv/slapd-ServerC/db/DBVERSION
[03/Jan/2012:15:06:43 -0700] - Restoring file 2 (/var/lib/dirsrv/slapd-ServerC/db/log.0000000021)
[03/Jan/2012:15:06:43 -0700] - Copying /var/lib/dirsrv/slapd-ServerC/bak/2011_12_29_15_27_35/log.0000000021 to /var/lib/dirsrv/slapd-ServerC/db/log.0000000021
[ lines removed to reduce size ]
[03/Jan/2012:15:06:43 -0700] - Restoring file 33 (/var/lib/dirsrv/slapd-ServerC/db/userRoot/uid.db4)
[03/Jan/2012:15:06:43 -0700] - Copying /var/lib/dirsrv/slapd-ServerC/bak/2011_12_29_15_27_35/userRoot/uid.db4 to /var/lib/dirsrv/slapd-ServerC/db/userRoot/uid.db4
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=aci,cn=index,cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=aci,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=entryrdn,cn=index,cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=entryrdn,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=nscpEntryDN,cn=index,cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=nscpEntryDN,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=nsds5ReplConflict,cn=index,cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=nsds5ReplConflict,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=nsuniqueid,cn=index,cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=nsuniqueid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=numsubordinates,cn=index,cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=numsubordinates,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=objectclass,cn=index,cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=objectclass,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=parentid,cn=index,cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=parentid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=aci,cn=index,cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
[03/Jan/2012:15:06:43 -0700] - Del Index Config Entry cn=aci,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
That is, after the message about deleting cn=parentid, it starts over again with cn=aci, skipping the other default indexes cn=seealso and cn=sn and cn=telephoneNumber and cn=uid and cn=uniquemember
389-ds-base-1.2.9.9-1.el5
RedHat EL 5.5
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/31
https://bugzilla.redhat.com/show_bug.cgi?id=739677
Description of problem:
Now that 389 has support for moving an entry in AD when moved between OU's.hat
The entry is moved properly, however the manager attribute is not updated to
reflect the move.
Version-Release number of selected component (if applicable):
1.2.9.9
How reproducible:
100%
Steps to Reproduce:
1. Create sync agreement between 389 and Active Directory, replicating the DS
subtree (ou=People,dc=example,dc=com) and the Windows subtree
(dc=example,dc=local)
2. Create two OU's on the Active Directory side, Finance
(ou=Finance,dc=example,dc=local) and HR (ou=HR,dc=example,dc=local)
3. Create two users on the Active Directory side, User1 under the Finance OU
and User2 under the HR OU, and set User1's manager to User2.
4. Create the Finance OU and HR OU on the 389 side under
ou=People,dc=example,dc=com;
5. On the Active Directory agreement setup in step 1, Initiate Full
Re-syncronization, and the two entries will be created on the 389 side under
their respective OU's. Take note that user1's manager value should be set to
uid=user2,OU=HR,ou=People,dc=example,dc=com.
6. On the Active Directory side, move User2 to the Finance OU. After User2 has
been moved, on 389, run Send and Receive Updates Now under the Active Directory
agreement.
7. On 389, User2 should have been moved from HR to Finance OU, however the
manager attribute under User1 does not reflect this, and has the old value.
Actual results:
Manager value is uid=user2,OU=HR,ou=People,dc=example,dc=com
Expected results:
Manager value should be uid=user2,ou=Finance,ou=People,dc=example,dc=com
Additional info:
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/7
https://bugzilla.redhat.com/show_bug.cgi?id=768933
Description of problem:
After replicating a user from 389DS to AD, if I want the user to be deleted
from AD, to avoid the user log in AD, is not sufficient to remove the
attributes related to replication in the user; I must delete manually from AD.
It would be useful if the user would be deleted from AD when the attributes
related to replication are removed, of even best, if an additional attribute is
set to a given value (ntSync: active, inactive).
This would be wrong, because if the user is deleted from AD, and then
re-enabled the replication in 389DS, the password must be set again to be
replicated. An alternate way of avoiding this, is to disable the user account
in AD if the user is not yet configured to be replicated, although this would
not work with groups.
How reproducible / Steps to Reproduce / Actual results / Expected results:
1. Create a user with attributes to be replicated in AD
2. Wait to the user be replicated to AD
3. Remove the NT attributes related to replication
I would expect the user to be deleted from AD, as the user is not yet
configured to be replicated, but the user still exists in AD.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/38
https://bugzilla.redhat.com/show_bug.cgi?id=720480
Description of problem:
Upgrading from 1.2.6 to 1.2.8 leads to the following errors on service startup:
[08/Jul/2011:15:48:39 -0700] attr_syntax_create - Error: the EQUALITY matching
rule [caseIgnoreMatch] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.26] for the attribute [nisDomain]
[08/Jul/2011:15:48:39 -0700] attr_syntax_create - Error: the SUBSTR matching
rule [caseIgnoreSubstringsMatch] is not compatible with the syntax
[1.3.6.1.4.1.1466.115.121.1.26] for the attribute [nisDomain]
Fix: 60nis.ldif should be updated as follows:
attributeTypes: (
1.3.6.1.4.1.1.1.1.12
NAME 'nisDomain'
DESC 'NIS domain'
SUP name
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
)
I was told to report this bug by richm1 from 389 on freenode.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1. Install 1.2.6
2. Notice that there are no errors on startup
3. Upgrade to 1.2.8
4. Notice that there are errors on startup
Actual results:
Service does not start up without errors.
Expected results:
Service should start up without errors.
Additional info:
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/6
https://bugzilla.redhat.com/show_bug.cgi?id=768934
Description of problem:
I am trying to test the proxied operations in 389 DS. For now, I have
written a small script using UnboundID LDAP SDK [1]:
ModifyRequest modifyRequest = new
ModifyRequest("uid=XXXXXXXX,ou=People,o=XXXXXXXX,dc=XXXXXXXX,dc=XXXXXXXX",
new Modification(ModificationType.REPLACE, "address", "Nueva
direcci?n"));
modifyRequest.addControl(new ProxiedAuthorizationV2RequestControl(
"dn:" + proxiedUserEntry.getDN()) );
try
{
LDAPResult modifyResult =
ldapConnectable.getConnection(session).modify(modifyRequest);
// If we got here, then the modify was successful.
}
catch (LDAPException le)
{
System.out.println(le.getDiagnosticMessage() + " (" +
le.getResultCode() + ")");
}
Although I have not yet assigned any ACIS as described in [2], I
supposed to get a denied response, not a protocol error as I get:
unable to parse proxied authorization control (2 (protocol error))
This error is returned by the LDAP server, although it is not
reported in the error LOG.
[1] http://www.unboundid.com/products/ldapsdk/docs/javadoc/index.html
[2] http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Adminis
tration_Guide/Managing_Access_Control-Access_Control_Usage_Examples.html#Access
_Control_Usage_Examples-Proxied_Authorization_ACI_Example
Version-Release number of selected component (if applicable): Tested in 1.2.5
How reproducible / Steps to Reproduce:
Running the code below.
Actual results:
unable to parse proxied authorization control (2 (protocol error))
Expected results:
An access denied in this case, as not applied any proxying configuration, or
the actual proxied search result if configured.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/10
https://bugzilla.redhat.com/show_bug.cgi?id=759043
Description of problem:
It would be useful if certain attributes could be excluded from a Windows
replication agreement, like a normal replication agreement; this could help to
avoid problems like described in bug 759009, that makes imposible to replicate
users with language subtypes.
Version-Release number of selected component (if applicable): 1.2.5.
How reproducible/Steps to Reproduce/Actual results/Expected results:
Same as bug 759009.
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/32
https://bugzilla.redhat.com/show_bug.cgi?id=739133
./Config fails with "grep: /usr//private/etc/apache2/httpd.conf: No such file
or directory"
The reason is that on OSX:
-D HTTPD_ROOT="/usr"
and...
-D SERVER_CONFIG_FILE="/private/etc/apache2/httpd.conf"
The correct location of httpd.conf is *not* HTTPD_ROOT + SERVER_CONFIG_FILE.
It's just SERVER_CONFIG_FILE.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.