Please review: [Bug 515805] Stop "initialize Database" crashes the server
by Noriko Hosoi
https://bugzilla.redhat.com/show_bug.cgi?id=515805
Steps to Reproduce:
1. On the DS Console, Configuration tab | expand Data, choose a backend icon in
a suffix
2. Right click and choose "initialize database", put an LDIF file name and
click OK
3. Once the import started, click Stop on the "initialize Database<backend>"
window, which crashed the server
Bug Description:
Task can be cancelled by sending a modify request on the task entry by
replacing nsTaskCancel value with TRUE as long as the task has the cancel
handling code. Currently, only import does.
Once TRUE is set to nsTaskCacnel, the pre-set callback slapi_task_set_cancel_fn
(import_task_abort in this case) is called and set the ABORT flag, which is
monitored by import_monitor_threads. By returning from import_monitor_threads,
the main import threads calls slapi_task_log_status. This function calls
slapi_task_status_changed, where since the task is cancelled, it sets
destroy_task to the event queue. That is, any time after the first
slapi_task_log_status/slapi_task_status_changed call, the task may be
destroyed. On the other hand, the task application import tries to log after
that.
[..] - import userRoot: Aborting all import threads...<== first log after
cancel
[..] - import userRoot: Import threads aborted.
[..] - import userRoot: Closing files...
!!! slapi_task_finish is called !!!
[..] - import userRoot: Import failed.
In this scenario, any logging or slapi_task_finish after the first log could
crash the server.
We should not go into the task clean up code when the state is just cancelled.
Rather, we should let the task application finish the task which changes the
state to finished, then destroy the task.
Files:
ldap/servers/slapd/back-ldbm/import.c
ldap/servers/slapd/task.c
Fix proposal:
https://bugzilla.redhat.com/attachment.cgi?id=401106&action=diff
https://bugzilla.redhat.com/attachment.cgi?id=401106&action=edit
14 years, 1 month
DN normalisation design document
by Ivanov Andrey (M.)
Hi Noriko,
i've read the design document
http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format
In order to support "Old DN format including DN in the double quotes"
another cn=config switch may be necessary. It seems there was recently a new
switch introduced to make the dn syntax validation a little more "relaxed" -
nsslapd-dn-validate-strict. Maybe this one could be used to allow for DNs
with double-quoted values?
Here is the commit comment for that parameter :
commit 0410819d48795fca4faf986cf8658c34c4d929e3
Author: Nathan Kinder <nkinder(a)redhat.com>
Date: Wed May 13 11:12:11 2009 -0700
Add strict DN syntax enforcement option.
The DN syntax has become more restrictive over time, and the
current rules are quite strict. Strict adherence to the rules
defined in RFC 4514, section 3, would likely cause some pain to
client applications. Things such as spaces between the RDN
components are not allowed, yet many people use them still since
they were allowed in the previous specification outlined in RFC
1779.
To deal with the special circumstances around validation of the DN
syntax, a configuration attribute is provided named
nsslapd-dn-validate-strict. This configuration attribute will
ensure that the value strictly adheres to the rules defined in RFC
4514, section 3 if it is set to on. If it is set to off, the server
will normalize the value before checking it for syntax violations.
Our current normalization function was designed to handle DN values
adhering to RFC 1779 or RFC 2253
Concerning the logic of escaping/unescaping/normalisation we could test how
openldap behaves in each case (as you've made it in "DN HEX HEX" bug).
For upgrades/migrations and double quotes in DNs: the two values may be left
during the upgrade (just in case someone uses them as-is) and then an
optional validation/cleaning script could be provided separately? The
sensitive part here is the whole o-NetscapeRoot tree: console using and
writing this type of values, replication agreement/management etc
As for the "related bugs" section i think another bug should be added (
https://bugzilla.redhat.com/show_bug.cgi?id=199923), it concernes the same
RFC4514 compliance.
14 years, 1 month
Please review: Bug 521108 - Customer is unable to add a new Role within RHDS 8.1.0
by Endi Sukma Dewata
Hi,
Please review the patch for this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=521108
Patch:
https://bugzilla.redhat.com/attachment.cgi?id=400577&action=edit
https://bugzilla.redhat.com/attachment.cgi?id=400577&action=diff
Fix description:
The console uses resource editor extensions which are registered under
cn=ResourceEditorExtension, ou=1.1, ou=admin, ou=Global Preferences,
ou=example.com, o=NetscapeRoot in the admin server. Some extensions are
provided by idm-console-framework, but some others are provided by
389-ds-console.
Currently the console will load all extensions during console initialization.
However, when a user uses the console for the first time it doesn't have the
389-ds-console jar file yet. The jar file will only be downloaded when the user
clicks the server node, but at that point the console will not try to load the
extensions again.
This problem can be reproduced by removing ~/.389-console/jars folder and then
restarting the console.
The patch will change the behaviour such that during initialization the console
will only load the extensions from idm-console-framework (without @ sign). When
the user clicks the server node it will load the extensions from the
389-ds-console jar file (ending with @ + jar file name).
Thanks.
--
Endi S. Dewata
14 years, 1 month
Please review: Bug 521108 - Customer is unable to add a new Role within RHDS 8.1.0
by Endi Sukma Dewata
Hi,
Please review the patch for this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=521108
Patch:
https://bugzilla.redhat.com/attachment.cgi?id=400577&action=edit
https://bugzilla.redhat.com/attachment.cgi?id=400577&action=diff
Fix description:
The console uses resource editor extensions which are registered under
cn=ResourceEditorExtension, ou=1.1, ou=admin, ou=Global Preferences,
ou=example.com, o=NetscapeRoot in the admin server. Some extensions are
provided by idm-console-framework, but some others are provided by
389-ds-console.
Currently the console will load all extensions during console initialization.
However, when a user uses the console for the first time it doesn't have the
389-ds-console jar file yet. The jar file will only be downloaded when the user
clicks the server node, but at that point the console will not try to load the
extensions again.
This problem can be reproduced by removing ~/.389-console/jars folder and then
restarting the console.
The patch will change the behaviour such that during initialization the console
will only load the extensions from idm-console-framework (without @ sign). When
the user clicks the server node it will load the extensions from the
389-ds-console jar file (ending with @ + jar file name).
Thanks.
--
Endi S. Dewata
14 years, 1 month