On Nov 7, 2007, at 6:45 AM, rwiker(a)gmail.com wrote:
> Full_Name: Raymond Wiker
> Version:
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (143.97.2.35)
>
>
> Just tried to download the PDF manual
> (http://www.openldap.org/doc/admin24/guide.pdf) from
> http://www.openldap.org/doc/index.html. This didn't work; the obvious
> explanation is that the file is not there, or that it has a
> different name.
Now fixed. Thanks for the report.
(This was due to a change in the doc/guide/Makefile which caused the
rule to build guide.pdf not to build guide.pdf. I've committed
changes to HEAD to address this issue.)
Full_Name: Dan Oscarsson
Version: 2.3.32
OS: SLES 10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (193.15.240.60)
I have found that using hdb there is a bug that now prevents me from
moving from my old commercial X.500 database to openldap. I need to use
hdb as I move objects using rename.
I am running openldap under SLES 10. The version there is 2.3.32 but I
have compiled 2.3.38 and tried that too. Both have same bug. Also
compiled and tried openldap-2.4.5beta. Same failure there too.
I am using hdb as database.
What I do is to run a job that moves around a lot of leaf nodes to other
branches, sometimes creating new branches before moving the leaf node
there. The job moves about 7000 nodes out of 20000 when the bug occurs.
After having run this, some nodes cannot be found by searching starting
at a subtree under database suffix. I have done a simple test program to
see if the bug appears. It does two searches:
1) Search with search base = database suffix
2) Search with search base = a branch 2 nodes deep below database
suffix.
If everything is correct, same number of objects should be found.
My tests show:
- running test: ok
- running job that moves nodes
- running test: failes, many objects are missing in search
starting at search base that is 2 nodes below database suffix.
- stopping and starting slapd
- running test again: ok
>From this I suspect that it is the cache of which parent node belongs to
that gets corrupted. Or can it be something else?
What more could I do to trace down the bug?
I do not know if the above information is enough for you to find what is
wrong? Cannot include data as it contains company internal information and
a simple test program did not give the same error.
I have looked at the code, but it takes some time to understand it when
doing it for the first time. maybe som debugging code could be added
find the place where the bug is.
We can check that an incoming modification will not leave an entry with more
than one userPassword value. We already have a partial check for this now.
But what can we do for an entry that already had multiple values, e.g.,
created before the overlay was in use? Simply refuse to Bind?
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
h.b.furuseth(a)usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: HEAD, RE23, RE24
> OS:
> URL:
> Submission from: (NULL) (129.240.6.233)
> Submitted by: hallvard
> slapd.conf(5) and slapd-config(5) say MaxDerefDepth defaults to 1, but
> include/ldap_defaults.h says #define SLAPD_DEFAULT_MAXDEREFDEPTH 15.
Seems it was wrong ever since it was checked in for ITS#1749. Oh well. Fixed
in HEAD.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
tonni(a)hetnet.nl wrote:
> > That's all very interesting, but you haven't provided the standard
> > items needed in a crash report - a stack trace from the crash,
>
> Yes I have, but later than your reply on the ITS site.
>
> > and the actual client command that caused the crash. Also, the slapd
> > configuration, plus any relevant schema if you've used any custom
> > schema in relation to this failing command.
>
> Other details:
>
> Command:
>
> ldapsearch2.4 -x -D "cn=admin,dc=billy,dc=demon,dc=nl" -w secret
> 'facsimileTelephoneNumber=+4753491111' facsimile TelephoneNumber
That's all we needed. Fixed now in HEAD.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
emmanuel.duru(a)atosorigin.com wrote:
> Full_Name: Emmanuel Duru
> Version: 2.3.38
> OS: Windows
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (195.68.44.148)
>
>
> configure allows the use of "cp" instead of "ln", but the build/shtool tool uses
> a hardcoded "ln" (line 1266).
> Some makefiles (libraries/liblunicode, libraries/libldap_r and
> servers/slapd/back-hdb) use a hardcoded "-s" option. This is a problem on
> Windows because in cygwin environment "cp -s" behaves the same way as "ln -s".
> The use of "ln" is not welcome here because it creates a Windows shortcut, which
> is not understood by mingw compiler.
We only support the MSYS build environment on Windows.
If you'd like to submit a patch to address this issue that doesn't break the
other platforms, we can look at incorporating it.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--On November 6, 2007 10:21:45 PM +0000 dappleby(a)deakin.edu.au wrote:
> Is anyone able to tell me how/why this occurs?
You made the mistake of using the RH ldap packages, that's why.
As to whether or not this has been fixed, please don't open up bug reports
on obsolete versions of OpenLDAP. Send your question to openldap-software,
and maybe someone can help you there. Personally I'd suggest using Buchan
Milne's builds for RH or Symas's CDS packages. Odds are though, it has
been fixed. 2.2.13 is quite old, with 2.4.6 being the current release.
<http://staff.telkomsa.net/packages/>
<http://www.symas.com/>
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
<quote who="andreas(a)mandriva.com.br">
> Full_Name: Andreas Hasenack
> Version: 2.3.39
> OS: linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (200.140.247.99)
>
>
> Please find at
> http://users.mandriva.com.br/~andreas/ldap-doc/doc-refint-patch/
> a patch and some image files for the admin guide. It adds documentation,
> examples and figures for the referential integrity overlay.
Looks good. Same comments as ITS#5216
I really appreciate your effort for this Andreas. Thanks.
> Disclaimer (let me know if I got it right: I repeated it in the patch
> file, but
> obviously can't add it to the binary image files):
>
> This patch file is derived from OpenLDAP Software. All of the
> modifications to
> OpenLDAP Software represented in the following patch(es) were developed by
> Andreas Hasenack <andreas(a)mandriva.com.br>. These modifications are not
> subject
> to any license of Mandriva.
> I, Andreas Hasenack, hereby place the following modifications to OpenLDAP
> Software (and only these modifications) into the public domain. Hence,
> these
> modifications may be freely used and/or redistributed for any purpose with
> or
> without attribution and/or other notice.
>
>
>
<quote who="andreas(a)mandriva.com.br">
> Full_Name: Andreas Hasenack
> Version: 2.3.39
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (200.140.247.99)
>
>
> Please find at
> http://users.mandriva.com.br/~andreas/ldap-doc/doc-dynlist-patch/
> a patch and some image files for the admin guide. It adds documentation,
> examples and figures for the Dynamic List overlay.
Thanks!
As discussed in #ldap all looks good.
> Disclaimer (let me know if I got it right: I repeated it in the patch
> file, but
> obviously can't add it to the binary image files):
I'll leave Kurt to check this. Once approved I'll commit it and then look
forward to the other patches you've got in your queue ;-)
>
> This patch file is derived from OpenLDAP Software. All of the
> modifications to
> OpenLDAP Software represented in the following patch(es) were developed by
> Andreas Hasenack <andreas(a)mandriva.com.br>. These modifications are not
> subject
> to any license of Mandriva.
> I, Andreas Hasenack, hereby place the following modifications to OpenLDAP
> Software (and only these modifications) into the public domain. Hence,
> these
> modifications may be freely used and/or redistributed for any purpose with
> or
> without attribution and/or other notice.
>
>
>