March 2010 - 389-devel - Fedora Mailing-Lists

Please review: Bug 571677 - Busy replica on consumers when directly deleting a replication conflict

by Rich Megginson

https://bugzilla.redhat.com/show_bug.cgi?id=571677 The problem is that a bepreop can attempt to lock an entry in the cache that has already been locked by the caller. I noticed that the modrdn code does not lock the target entries in the cache until after the bepreops have been called. So I did the same for mod and del, and it worked, but I just don't know what else this may effect. Comments? https://bugzilla.redhat.com/attachment.cgi?id=402171&action=diff https://bugzilla.redhat.com/attachment.cgi?id=402171&action=edit

14 years, 1 month

1
0
0 / 0

Please review: Bug 572355 - selinux package does not label files correctly

by Endi Sukma Dewata

Hi, Please review the patch for this bug: https://bugzilla.redhat.com/show_bug.cgi?id=572355 Patch: https://bugzilla.redhat.com/attachment.cgi?id=401899&action=edit https://bugzilla.redhat.com/attachment.cgi?id=401899&action=diff Description: The updateDSInstance() has been modified to invoke updateSelinuxPolicy() to set the SELinux labels on instance files and ports. Thanks! -- Endi S. Dewata

14 years, 1 month

1
0
0 / 0

Please review: [Bug 548533] memory leak in Repl_5_Inc_Protocol_new

by Noriko Hosoi

[Bug 548533] memory leak in Repl_5_Inc_Protocol_new https://bugzilla.redhat.com/show_bug.cgi?id=548533 Proposed Fix: https://bugzilla.redhat.com/attachment.cgi?id=401614&action=diff https://bugzilla.redhat.com/attachment.cgi?id=401614&action=edit Description: repl5_inc_delete and repl5_tot_delete to release the incremental and total update protocol were not implemented. This fix implemented them. Also, it fixed a leak of connection in private_protocol_factory.

14 years, 1 month

1
0
0 / 0

Please review: Bug 480787 - autoconf parameter --with-... --without-...

by Endi Sukma Dewata

Hi, Please review the patch for the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=480787 Patch: https://bugzilla.redhat.com/attachment.cgi?id=401381&action=edit https://bugzilla.redhat.com/attachment.cgi?id=401381&action=diff The configure script has been modified such that the --with-XXX and --without-XXX switches will work as --with-XXX=yes and --with-XXX=no, respectively. If the package is required and none of the switches are specified, it will default to "yes". The code that detects LDAPSDK and OpenLDAP conflicts has been updated. The help messages have been cleaned up. Thanks! -- Endi S. Dewata

14 years, 1 month

1
0
0 / 0

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

1
0
0 / 0

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

2
3
0 / 0

Please review: Bug 573375 - MODRDN operation not logged

by Endi Sukma Dewata

Hi, Please review the patch for this bug: https://bugzilla.redhat.com/show_bug.cgi?id=573375 Patch: https://bugzilla.redhat.com/attachment.cgi?id=400890&action=edit https://bugzilla.redhat.com/attachment.cgi?id=400890&action=diff Fix description: The slapi_log_access() should be invoked using LDAP_DEBUG_STATS, LDAP_DEBUG_STATS2, or LDAP_DEBUG_ARGS level. Thanks. -- Endi S. Dewata

14 years, 1 month

1
0
0 / 0

Please review: [Bug 573896] initializing subtree with invalid syntax crashes ns-slapd

by Noriko Hosoi

Subject: initializing subtree with invalid syntax crashes ns-slapd https://bugzilla.redhat.com/show_bug.cgi?id=573896 Files: ldap/servers/slapd/slap.h ldap/servers/slapd/task.c Description: When an import is executed using a task mechanism, slapi_task_log_notice is called for logging, where task_log field points the memory storing the log messages. If multiple log messages were logged by multiple worker threads simultaneously, there was a chance that the address of the log message was switched by realloc while the other threads were accessing the old address. This patch introduces task_log_lock per task to protect task_log. Note: slapi_ch_malloc and its friends never return NULL. They rather exits. Thus, to avoid the confusion which may look leaking the lock, I eliminated 2 error returns from slapi_task_log_notice. Proposed patch: https://bugzilla.redhat.com/attachment.cgi?id=400601&action=diff https://bugzilla.redhat.com/attachment.cgi?id=400601&action=edit

14 years, 1 month

1
0
0 / 0

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

1
0
0 / 0

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

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel March 2010