| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=617630
Bug description: CID 12090 was a false positive
description: Undo the commit e23c8bd9994d5592738cb44e1c2b426aba7fbd4a
|
| |
|
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=617630
Resolves: bug 617630
Bug description: fix coverify Defect Type: Resource leaks issues CID 12090.
description: The entry_add_present_values_wsi() has been modified to release valuestoadd before returning.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix Description:
. adding slapi_dn_normalize_ext and its siblings to normalize/validate
invalid DNs; deprecating slapi_dn_normalize and its siblings. (dn.c)
. replacing slapi_dn_normalize with new corresponding functions.
. normalizing hardcoded DNs (e.g., removing spaces around ',')
. setting correct DN syntax to nsslapd-suffix, nsslapd-ldapiautodnsuffix,
costemplatedn, nsslapd-changelogsuffix, nsBaseDN, nsBindDN
. if nsslapd-dn-validate-strict is enabled, incoming DN is examined and
rejected if it is invalid. Once approved, the DN is normalized.
. fixing compiler warnings and typos.
See also:
http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format
Related bugs:
Bug 199923 - subtree search fails to find items under a db containing special
characters
Bug 567968 - subtree/user level password policy created using 389-ds-console
doesn't work.
Bug 570107 - The import of LDIFs with base-64 encoded DNs fails, modrdn with
non-ASCII new rdn incorrect
Bug 570962 - ns-inactivate.pl does not work
Bug 572785 - DN syntax: old style of DN <type>="<DN>",<the_rest> is not
correctly normalized
Bug 573060 - DN normalizer: ESC HEX HEX is not normalized
Bug 574167 - An escaped space at the end of the RDN value is not handled
correctly
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=578167
Resolves: bug 578167
Bug Description: repl. of mod/replace deletes multi-valued attrs
Reviewed by: nkinder (Thanks!)
Branch: HEAD
Fix Description: The server implements a mod/replace operation as a
mod/delete if all values, followed by a mod/add of the new values. The
mod/delete phase, since it removes all of the values, essentially deletes
the attribute, so it must set the attribute deletion_csn. This is even
true in the case when you do a mod/replace on an attribute that doesn't yet
exist. We have to create an empty attribute on the deleted_attrs list with
the deletion_csn set to the csn of the operation. This preserves the
semantics of the mod/replace operation.
When doing the add phase of the mod/replace, we have to be able to
resurrect attributes and values that may have been deleted by the mod/delete
phase. We can tell that we need to resurrect a deleted value in
resolve_attribute_state_multi_valued, in the deleted_values loop, because
the deletioncsn will be the same as the update csn, and the
delete_priority flag will be 0.
Platforms tested: RHEL5 x86_64
Flag Day: no
Doc impact: no
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=516611
Resolves: bug 516611
Bug Description: 389 DS segfaults on libsyntax-plugin.so - part 2
Reviewed by: nkinder (Thanks!)
Branch: HEAD
Fix Description: If there is an empty mod/replace of a non-existent attribute
following a real modify operation, the server will allow it, and the code in
entry_delete_present_values_wsi() would create an empty Slapi_Attr. LDAP
says that an empty mod/replace of a non-existent attribute should be ignored,
as it is in the non-repl case.
Platforms tested: RHEL5 x86_64
Flag Day: no
Doc impact: no
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch includes
- replacing the entrydn index with the entryrdn index
- replacing a full DN in each entry in the DB with an RDN
- extending Slapi_Entry, entry2str, and str2entry to absorb the changes
made on the entry
- adding DN/RDN helper functions
- adding DN cache
- adding a utility and a migration script to convert the DN format database
to the RDN format
- extending a database dump utility dbscan to support the entryrdn
- slapi_dn_syntax_check by nkinder@redhat.com is added to check the dn before
modify operations
- big fix for 171338 - Enhancement: winsync modrdn not synced
In addition to the above, compile warnings and memory leaks found in testing
the new feature are fixed.
For more details, see the feature design document at:
http://directory.fedoraproject.org/wiki/Subtree_Rename
and bugzilla at:
https://bugzilla.redhat.com/show_bug.cgi?id=171338
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When performing operations with multiple mods to the same multi-valued
attribute on a single modify operation, a replica was not resolving
the attribute values correctly. This would lead to an inconsistency
between the master the change was initially performed against and the
replicas. The problem would occur with a modify operation such as
this:
dn: uid=testuser,dc=example,dc=com
changetype: modify
add: cn
cn: 2
-
replace: cn
cn: 3
The problem is that we use the CSNs from the attribute state data
to determine which values should remain after the operation (this is
done to merge with later occuring changes from other masters). The
CSN for all mods within the same modify operation is exactly the same.
The old code was looking for attributes older than the deletion that
occurs as a part of the replace, then deleting those values. This
would cause the value of "2" in the above example to remain. Simply
changing this comparision to look for values with the same or older
CSN to delete would cause the new value of "3" to be removed as well
when we get around to resolving the attribute after the second half
of the replace operation.
The fix is to use a different CSN comparison when we are removing all
values of an attribute during attribute resolution (remove values with
the same or older CSN). This is safe becuse the only present values
at this time are older values or values added in a previous mod in the
same modify operation. When processing other mods that are not
removing all values of an attribute, we only want to remove values
with a CSN older that that of the current modify operation. This
prevents us from removing a newly added value, such as "3" in the
example above. This is safe since we resolve the attribute after
each mod in the modify operation.
|
| |
|
|
|
|
|
|
|
| |
Summary: Directory server is caching string case for attributes with Directorystring syntax even after deletion
Description:
Introduced a new flag SLAPI_VALUE_FLAG_USENEWVALUE for valueset_remove_valuearr
to exchange the value in the deleted value set and the to be added value. With
this change, the newly added value is resurrected instead of the original
value.
|
| |
|
|
|
|
|
|
|
|
| |
Summary: configure needs to support --with-fhs (Comment #6)
Changes: Added the following include next to the end of the copyright block.
+
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
|
| | |
|
| | |
|
| | |
|
|
|
(foxworth)
|
