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)

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)

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:

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.

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:

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.

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

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"

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.

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.

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.

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:

Tracking bug for 389 Directory Server 1.2.10

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.

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

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.

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

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.

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.

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:

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.

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

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

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:

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.

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)

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" );

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:

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}

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.

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.

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

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.

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.

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.

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:

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.

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.

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.

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:

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.

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:

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.

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.

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