389-devel November 2010

389-devel@lists.fedoraproject.org

4 participants
12 discussions

Start a nNew thread

Please Review: (658312) Allow mapped attribute types to be quoted
by Nathan Kinder 01 Dec '10

01 Dec '10

https://bugzilla.redhat.com/show_bug.cgi?id=658312 https://bugzilla.redhat.com/attachment.cgi?id=463847&action=edit

1 0

Please Review: (656515) Allow Name and Optional UID syntax for grouping attributes
by Nathan Kinder 23 Nov '10

23 Nov '10

https://bugzilla.redhat.com/show_bug.cgi?id=656515 https://bugzilla.redhat.com/attachment.cgi?id=462466&action=edit

1 0

Please Review: (656392) Remove calls to ber_err_print()
by Nathan Kinder 23 Nov '10

23 Nov '10

https://bugzilla.redhat.com/show_bug.cgi?id=656392 https://bugzilla.redhat.com/attachment.cgi?id=462441&action=edit

1 0

Please Review: (625950) hash nsslapd-rootpw changes in audit log
by Nathan Kinder 22 Nov '10

22 Nov '10

https://bugzilla.redhat.com/show_bug.cgi?id=625950 https://bugzilla.redhat.com/attachment.cgi?id=462126&action=edit

1 0

Please review: [Bug 651571] When attrcrypt is on, entrydn is stored in the backend db
by Noriko Hosoi 09 Nov '10

09 Nov '10

https://bugzilla.redhat.com/show_bug.cgi?id=651571 https://bugzilla.redhat.com/attachment.cgi?id=459236&action=diff https://bugzilla.redhat.com/attachment.cgi?id=459236&action=edit Description: If an entry contains a to-be-encrypted attribute, id2entry_add_ext handles a copy of the entry in which the attribute is encrypted, then the copy is being stored in the backend db. On the other hand, an entrydn attribute is supposed to remove from the entry before storing the entry in the db. There was a bug there: the removal was done on the original entry, but not on the encrypted copy. This patch correctly removes the entrydn attribute from the encrypted entry to be stored in the db. Thanks, --noriko

1 0

Please review: [Bug 572018] Upgrading from 1.2.5 to 1.2.6.a2 deletes userRoot
by Noriko Hosoi 08 Nov '10

08 Nov '10

https://bugzilla.redhat.com/show_bug.cgi?id=572018 https://bugzilla.redhat.com/attachment.cgi?id=458863&action=diff https://bugzilla.redhat.com/attachment.cgi?id=458863&action=edit Description: The upgrade tool dn2rdn shares the reindex code, in which a cursor is set to each entry in id2entry.db# converting dn to rdn and put it into the btree with db->put one by one. It turned out the strategy does not work for the case the btree structure is modified. In that case, the btree could get corrupted. This patch creates a new id2entry_tmp.db# from the scratch. Once all the entries are successfully converted, the old db is removed and id2entry_tmp.db# is renamed to id2entry.db#.

1 0

One Way AD Sync
by Nathan Kinder 06 Nov '10

06 Nov '10

Please review these design notes for implementing one way AD sync. In particular, I'm concerned about the possible inconsistencies that can arise from directly modifying a synced entry on the DS side. Does using access control seem sufficient for avoiding these inconsistencies? If these notes look OK, I'll get everything posted up on the 389 wiki. Thanks, -NGK One Way Sync Some deployments would prefer that AD sync is only performed in one direction. More specifically, updates will be pulled from AD, but changes to DS will not be pushed back to AD. Ideally, one would restrict direct updates to synchronized entries in DS by configuring access control. To implement one-way sync, we need to add a new configuration attribute to the sync agreement entry. This attribute will be named "oneWaySync" and will default to "false" if it is not specified to maintain backwards compatibility. When this attribute is set to "true", updates will only go in the AD->DS direction. If one way sync is enabled and changes are made to a synced entry on the DS side, a replication session with AD will be started. In this session, we will not send any updates, but we will send the Dirsync control to AD to pull any updates. This will result in an inconsistency in the modified entry between AD and DS. This inconsistency will be resolved the next time any update is made to the entry on the AD side since we compare the entire entry between AD and DS when we receive a change via Dirsync. To avoid these inconsistencies, it is recommended to not allow direct updates to synced attributes in entries on the DS side. Another inconsistency that can occur is if a synced entry is directly deleted from DS. This deletion is not sent to AD. In this case, an update to the entry on the AD side will result in the entry being added back to DS. The direct deletion of synced entries on the DS side should be avoided to prevent these inconsistencies. Inside of the replication plug-in, we simply skip sending updates in both the total and incremental replication protocol sessions when using a one way sync agreement. We don't want to change the RUV implementation for a one way sync agreement, so we will just fast-forward the RUV that we maintain for the AD system as if we had successfully sent the changes.

2 5

Please review: [Bug 643979] Strange byte sequence for attribute with no values (nsslapd-referral)
by Endi Sukma Dewata 05 Nov '10

05 Nov '10

Hi, Please review the patch for the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=643979 https://bugzilla.redhat.com/attachment.cgi?id=458122&action=edit https://bugzilla.redhat.com/attachment.cgi?id=458122&action=diff Thanks! -- Endi S. Dewata

1 0

Please review: put replication config entries in separate file
by Rich Megginson 04 Nov '10

04 Nov '10

2 1

Please review: [Bug 567282] server can not abandon searchRequest of "simple paged results"
by Noriko Hosoi 03 Nov '10

03 Nov '10

https://bugzilla.redhat.com/show_bug.cgi?id=567282 https://bugzilla.redhat.com/attachment.cgi?id=457550&action=edit https://bugzilla.redhat.com/attachment.cgi?id=457550&action=diff Description: Simple Paged Results search keeps the connection per paging, but not an operation. When an abandon request is issued, the operation referred by the request has already finished. This patch introduces pagedresults_cleanup function to check whether the connection is for the simple paged results or not, and if it is, the simple paged results is cleaned up. If it is not, pagedresults_cleanup does nothing. The function is called from do_abandon as well as from connection_cleanup. Files: ldap/servers/slapd/abandon.c ldap/servers/slapd/connection.c ldap/servers/slapd/opshared.c ldap/servers/slapd/pagedresults.c ldap/servers/slapd/proto-slap.h Thanks, --noriko

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel November 2010