| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the entrydn in id2entry
https://bugzilla.redhat.com/show_bug.cgi?id=592397
Description: If entries created by the 389 v1.2.5 or older,
the primary db (id2entry.db4) contains "entrydn: <normalized dn>".
Upgrading from the old version to v1.2.6 keeps the entrydn
attribute type and its value even though v1.2.6 is not supposed
to store the entrydn in the database.
1) This patch drops the entrydn attribute and value in upgrading
the db.
2) If an ldif file contains entrydn attribute type and value,
import (ldif2db[.pl]) ignores it.
3) A leak was found in the export (db2ldif[.pl]) which is fixed.
4) When nsslapd-subtree-rename-switch configuration attribute has
the value "on", entrydn is not used nor created. But the
server accepted reindexing entrydn request and generated an
entrydn index file. This patch rejects it.
5) Entry and dn cache clear calls (cache_clear) are added to
dblayer_instance_close in "#if defined(_USE_VALGRIND)", which
is not defined. To enable the code, the server needs to be
rebuilt with defining the macro. This is purely for debugging.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=631862
Resolves: bug 631862
Bug Description: crash - delete entries not in cache + referint
Reviewed by: rmeggins and nhosoi
Branch: master
Fix Description: When deleting an entry, the referential integrity (referint)
plugin does an internal search to find references to this entry (e.g. in
group entries) and removes them. The search code wants to ensure that the
entrydn attribute is present in the entry when using entryrdn (subtree
rename). The search code sets a flag to tell the id2entry code to add the
entrydn attribute if it is not present. However, it was doing this to an
entry in the cache, which may be in use by another thread. The solution is
to add the entrydn attribute before adding the entry to the cache. In the
id2entry code, this is after the entry has been read from the id2entry db
successfully, but before the entry is added to the cache. In the LDAP ADD
code, this is done when the other computed operational attributes are added
to the new entry.
In addition to the above fix by rmeggins@redhat.com, following changes are
made:
1) entrydn attribute is always added to the entry in memory before putting
it in the entry cache, and the attribute is removed before writing the
entry to the database.
2) eliminating id2entry_ext, which was introduced to pass flags, but it is
no longer needed since only a flag ID2ENTRY_ADD_ENTRYDN was removed.
Platforms tested: RHEL5 x86_64
Flag Day: no
Doc impact: no
|
|
|
|
|
|
|
|
|
|
|
| |
We need to check the return value of cache_replace() in
id2entry_add_ext(). The only possible error that can be returned
is when the entry we are trying to replace is not found in the
cache. This should not occur since we are told that the entry
already exists by CACHE_ADD() just prior to this call. If we run
into this situation, we will just log an error without adding the
entry to the cache. This shouldn't be a big deal since the entry
will get added to the cache next time it is accessed.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
do not change or change very rarely
https://bugzilla.redhat.com/show_bug.cgi?id=627738
Description:
Change made in this commit: cc36301a7cae6737d9f8a0e53bed653a52130a1d
for the following bug introduced a missing-cache-return bug:
id2entry_add_ext replaces an dn instance in the dn cache even if
the DN value is identical. Replace it only when they don't match.
Thanks to andrey.ivanov@polytechnique.fr for finding it out:
https://bugzilla.redhat.com/show_bug.cgi?id=627738#c5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
change or change very rarely
https://bugzilla.redhat.com/show_bug.cgi?id=627738
Description:
1) id2entry_add_ext replaces an dn instance in the dn cache even if
the DN value is identical. Replace it only when they don't match.
2) Modifying the dn cache related labels:
dnEntrycachehits
dnEntrycachetries
dnEntrycachehitratio
dnCurrententrycachesize
dnMaxentrycachesize
dnCurrententrycachecount
dnMaxentrycachecount
===>
dncachehits
dncachetries
dncachehitratio
currentdncachesize
maxdncachesize
currentdncachecount
maxdncachecount
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
entrydn is not present in search results
https://bugzilla.redhat.com/show_bug.cgi?id=628300
Resolves: 628300
Description: Code for supporting entrydn (added for Bug 578296)
contained a bug. If an entry was found in the entry cache,
id2entry_ext returned it without adding the entrydn attribute
value. This patch fixes the problem.
In addition, if the parent DN in the to-be-added entry is not
identical to the real parent DN (e.g., dc=eXAmple vs. dc=example),
replace the string with the real parent DN. This check & replace
is done only when the parent entry is in the entry cache not to
sacrifice the performance.
|
|
|
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=617630
Resolves: bug 617630
Bug description: fix coverify Defect Type: Resource leaks issues CID 12077
description: id2entry_add_ext() has been modified to release resources properly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rename switch is on
https://bugzilla.redhat.com/show_bug.cgi?id=578296
Change Description:
1) ldbm_back_next_search_entry_ext (ldbm_search.c)
When getting an entry from ID using id2entry_ext, pass a flag
ID2ENTRY_ADD_ENTRYDN to add entrydn to the entry.
2) id2entry_ext (id2entry.c)
Added id2entry_ext to handle the flag ID2ENTRY_ADD_ENTRYDN.
If ID2ENTRY_ADD_ENTRYDN is set in the flags variable and
entryrdn switch is enabled, entrydn is added to the entry.
3) index_read_ext (index.c)
If entryrdn switch is on and the attribute type is entrydn and
the search type is equality, then call entryrdn_index_read
to get the ID directly.
|
|
|
|
|
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=567370
Descriptino: When deleting an entry, if the dn is in the dn cache,
it should be removed. The original code was trying to remove it
regardless of the existence in the dn cache. Fixed it so that
only when the dn is in the cache, it's removed.
|
|
|
|
|
|
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=565664
Description: Special thanks to edewata@redhat.com for fixing the bug.
> See ldap/servers/slapd/back-ldbm/id2entry.c line 196.
> The second parameter should be a pointer to pointer,
> but the current code passes a regular pointer:
> CACHE_RETURN(&inst->inst_dncache, bdn);
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=563365
1) Error handling in ldbm_back_{add,delete,modify,modrdn} functions was
incomplete. When any error occurs after the transaction begins, the
changes made after that should be aborted. There were some cases the
abort was not called.
2) If modrdn failed in ldbm_back_modrdn, new DN in the DN cache was not
removed.
3) config_set_instancedir in libglobs.c was missing the function type.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
valgrind is a very useful tool - however, the directory server produces a lot
of false positives that have to be suppressed in order to get to the useful
information. These patches attempt to reduce some of that noise.
1) aclparse - should calculate the length of the string _after_ trimming the
spaces
2) something about random number generation causes some of the bits to be uninitialized, and valgrind doesn't like it - this patch doesn't eliminate the error, just reduces it
3) use initialized memory when generating hashes - also remove "magic numbers"
4) bin.c - slapi_value_get_string must not be used with unterminated (binary) values
5) we get these odd valgrind reports from deep within bdb about invalid reads and uninitialized memory - I thought perhaps because we were initializing DBT structures with = {0} which the bdb docs says is not sufficient - they recommend memset or bzero
6) There are some small memory leaks during attrcrypt initialization and in error cases
7) error message in ldif2ldbm.c was attempting to print the Slapi_DN structure rather than getting the char *dn
8) After we call NSS_Initialize, we must call the NSS shutdown functions to clean up the caches and other data structures, otherwise NSS will leak memory. This is harmless since it happens at exit, but valgrind reports hundreds of memory leaks. The solution is to make sure we go through a single exit point after NSS_Initialize. This means many places that just called exit() must instead return with a real return value. This mostly affected main.c, detach.c, and a couple of other places called during startup.
9) minor memory leaks in mapping tree initialization
10) sasl_map.c - should not call this in referral mode
11) minor memory leaks during ssl init
Reviewed by: nkinder, nhosoi (Thanks!)
|
|
|
|
|
| |
Summary: Memory usage research: checking in the experimental code
See also: http://directory.fedoraproject.org/wiki/Memory_Usage_Research
|
|
|
|
|
|
|
|
|
|
| |
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
+
|
| |
|
| |
|
|
|
|
| |
warnings on Linux; remove pam_passthru from DS 7.1
|
| |
|
|
(foxworth)
|