[Fedora-directory-devel] patch to fix ambiguity in imported classes
by William Jon McCann
Hi,
I was trying to "ant package" the console stuff from cvs and ran into
some errors using java 1.6. It seems like using import with a
wildcard in some cases pulls in two classes with the same name.
Here is a patch that replaces some of these problematic wildcards with
explicit imports. I'm not really a java hacker so I'm not sure this
is the best approach but it seems to make sense to me.
Thanks,
Jon
15 years, 8 months
[Fedora-directory-devel] Please review: [Bug 222918] server crash after deleting supposedly deleted attribute
by Noriko Hosoi
Summary: server crash after deleting supposedly deleted attribute
https://bugzilla.redhat.com/show_bug.cgi?id=222918
On some configuration, FDS1.0.2 crashes when handling these modify requests:
dn: cuniPersonalId=99853826,ou=people,dc=cuni,dc=cz
changetype: modify
replace: cuniPrincipalName
-
dn: cuniPersonalId=99853826,ou=people,dc=cuni,dc=cz
changetype: modify
delete: cuniPrincipalName
------- Additional Comments From nhosoi(a)redhat.com 2007-09-28 15:52 EST -------
Created an attachment (id=210881)
--> (https://bugzilla.redhat.com/attachment.cgi?id=210881&action=view)
cvs diffs
Files: servers/plugins/syntaxes/string.c servers/slapd/back-ldbm/index.c
Description: I tried to reproduce the problem, but it failed.
I tried the test under the stress with nsslapd-serial-lock: off, but the
condition was not the key. My test always catches:
ldap_modify: No such attribute
at the second deletion, with which it does not take the crash path.
I tried indexed attribute as well as unindexed, but no luck.
Anyway, although I could not reproduce the crash, but the stacktrace in the original
comment indicates even if there is no attribute to delete, it calls
index_addordel_values_sv with NULL vals, which is not supposed to, I think.
Also, string_values2keys in string.c is not ready to accept NULL bvals.
I changed these two files so that even if the condition is realized, the server
won't crash.
15 years, 8 months
[Fedora-directory-devel] Please Review: (304191) dbscan doesn't handle RUV entries in changelog db
by Nathan Kinder
https://bugzilla.redhat.com/show_bug.cgi?id=304191
Resolves: bug 304191
Bug Description: If you try to run the dbscan tool against a changelog
db on a stopped server, it reports the an error similar to:
dbid: 0000006f000000000000
Invalid changelog db version 1
Works for version 5 only.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The print_changelog function in dbscan.c expects all
entries to
have 0x05 as the first byte, which signifies the changelog version.
This version
check should be done for all change entries in the changelog db, but
there are
three special entries that are in the beginning of the changelog where
this doesn't
apply. These entries are an entry count, the purge RUV, and the max RUV.
It should be noted that these entries are not always present when the
server is
running, so dbscan will often work fine against a running server.
When the
server is stopped gracefully, these entries are flushed out to be used
once the
server is restarted.
The attached diffs make dbscan check for these special entries when
reading
through a changelog. If it encounters one of these entries, it will
print out
the data in a nice usable format.
Platforms tested: FC6 i386
Flag Day: no
Doc impact: no
QA impact: Need to add new tests
New Tests integrated into TET: none
https://bugzilla.redhat.com/attachment.cgi?id=204611&action=diff
15 years, 8 months
[Fedora-directory-devel] Please review: [Bug 171081] ldapsearch hung at browsing index creation
by Noriko Hosoi
Summary: ldapsearch hung at browsing index creation
https://bugzilla.redhat.com/show_bug.cgi?id=171081
This bug was introduced while fixing another bug: deleting a vlv index while it's being created makes the server crash.
------- Additional Comments From nhosoi@redhat.comhttps://bugzilla.redhat.com/attachment.cgi?id=202891&action=view)
cvs diff ldif2ldbm.c vlv.c
Files: ldapserver/ldap/servers/slapd/back-ldbm/ldif2ldbm.c
vlv.c
Fix Description:
1. instead of covering all the reindexing loop, set vlv lock just around
vlv_update_index, where vlv update is executed.
2. actually, lock is not meant to use for excluding the operation against vlv
reconfiguration. This ldbm_back_ldbm2index function first calls
instance_set_busy_and_readonly and protects the backend from the operations done
by other threads. vlv delete call was just ignoring the busy/readonly setting.
Thus, changed the vlv code to respect the setting. Found the backend is busy,
deleting a vlv index fails and returns.
3. cleaned up the instance_set_busy_and_readonly function not to leak memory.
4. fixed minor memory leak.
Thanks,
--noriko
15 years, 8 months
[Fedora-directory-devel] Please Review: (299361) Sync total update doesn't handle initials and streetAddress properly
by Nathan Kinder
https://bugzilla.redhat.com/show_bug.cgi?id=299361
esolves: bug 299361
Bug Description: There are some problems with the sync total update in
regards
to the initials and streetAddress attributes.
The code currently doesn't handle multi-valued streetAddress attributes or
initials attributes longer than 6 characters in the entries on the DS
side.
When you do an initialization with these types of entries, the sync
fails due
to constraints on the AD side. We already handle these values
properly in the
incremental sync protocol.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: This fix trims the initials attribute when sending to
AD. We also
only compare the first 6 characters of an initials value in DS to the
initials
value in AD when determining if we need to send a change. For
streetAddress, we
only sync one value from DS to AD. We check if DS contains the
streetAddress value
present in AD to determine if we need to accept a change from AD.
Platforms tested: FC6 & Windows 2003 Server
Flag Day: no
Doc impact: no
QA impact: Need to add new tests
New Tests integrated into TET: none
https://bugzilla.redhat.com/attachment.cgi?id=201401&action=diff
15 years, 8 months