Full_Name: Dieter Kluenter
Version: REL_ENG_2_4
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (84.142.202.173)
Hi,
the guide *.sdf files are UTF-8 encoded, but the online availeable HTML files
seem to be iso8859-1 encoded, which leeds to display errors, an example is part
9.2.1.
... proxy’s efficiency ...
-Dieter
mills(a)cc.umanitoba.ca wrote:
> Full_Name: Gary Mills
> Version: openldap-2.3.38
> OS: Solaris 9 SPARC
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (24.78.105.29)
back-ldbm is deprecated and has been deleted from OpenLDAP 2.4. It is known to
have many problems. Berkeley DB 3.1.17 is ancient, and also known to have many
bugs. Don't use ldbm, and use a recent version of BerkeleyDB. Nobody is going
to spend any time investigating these broken code bases.
>
>
> Here's how openldap-2.3.38 was built:
>
> PATH=/opt/SUNWspro/bin:/usr/bin:/usr/ccs/bin:/usr/sbin; export PATH
>
> env CC=cc \
> INSTALL=/usr/ucb/install \
> CPPFLAGS="-I/usr/local/src/db/db-3.1.17/build_unix
> -I/usr/local/src/OpenSSL/openssl-0.9.8f/include" \
> LDFLAGS="-R/usr/local/lib -L/usr/local/src/db/db-3.1.17/build_unix
> -L/usr/local/src/OpenSSL/openssl-0.9.8f/lib" \
> ./configure \
> --disable-proctitle \
> --enable-crypt \
> --disable-bdb \
> --disable-hdb \
> --enable-ldbm \
> --enable-perl
>
> In simple tests with an ldbm database, it works correctly. With many clients,
> it
> dump core hundreds of times a day. The dumps vary, but suggest a memory
> management
> problem. Here are two:
--
-- 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/
I neglected to mention that compiling Openldap without threads resulted
in a perfectly stable server. Threads seem to be handled incorrectly,
somehow.
--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
Full_Name: Gary Mills
Version: openldap-2.3.38
OS: Solaris 9 SPARC
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (24.78.105.29)
Here's how Openldap was compiled:
PATH=/opt/SUNWspro/bin:/usr/bin:/usr/ccs/bin:/usr/sbin; export PATH
env CC=cc \
INSTALL=/usr/ucb/install \
CPPFLAGS="-I/usr/local/src/db/db-3.1.17/build_unix
-I/usr/local/src/OpenSSL/openssl-0.9.8f/include" \
LDFLAGS="-R/usr/local/lib -L/usr/local/src/db/db-3.1.17/build_unix
-L/usr/local/src/OpenSSL/openssl-0.9.8f/lib" \
./configure \
--disable-proctitle \
--enable-crypt \
--disable-bdb \
--disable-hdb \
--enable-ldbm \
--without-threads \
--enable-perl
When using an ldbm database, Microsoft Outlook 2003 clients report this error
when
they attempt a search:
The search could not be completed. MAPI_E_CALL_FAILED
The LDAP logs show this message:
critical control unavailable in context
This happens because Openldap advertizes the pagedResults control, even though
the
ldbm backend does not support it. When OL 2003 obtains the list of available
controls, the LDAP server does not know which back end it will use. When OL
2003
does a query, it goes to the ldbm back end which does not support that control.
OL 2003 marks it critical, making the situation impossible.
In this situation, I'm using only the ldbm back end, so I removed the
pagedResults
control in servers/slapd/controls.c to fix the problem. Here's my patch:
*** controls.Oc Tue Jan 2 15:43:55 2007
--- controls.c Thu Nov 29 19:53:12 2007
***************
*** 123,132 ****
--- 123,134 ----
SLAP_CTRL_GLOBAL|SLAP_CTRL_SEARCH, NULL,
parseValuesReturnFilter, LDAP_SLIST_ENTRY_INITIALIZER(next) },
#endif
+ #ifdef VANILLA
{ LDAP_CONTROL_PAGEDRESULTS,
(int)offsetof(struct slap_control_ids, sc_pagedResults),
SLAP_CTRL_SEARCH, NULL,
parsePagedResults, LDAP_SLIST_ENTRY_INITIALIZER(next) },
+ #endif
#ifdef LDAP_DEVEL
{ LDAP_CONTROL_SORTREQUEST,
(int)offsetof(struct slap_control_ids, sc_sortedResults),
Adding an access list to the config file did not work.
h.goebel(a)goebel-consult.de wrote:
> Full_Name:
> Version: 2.3.38
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (79.207.201.247)
>
>
> Debugging marks in sql-statement may lead to wrong results.
>
> The interface I implemented yields statements like this when using Thunderbird
> for searching for 'Klaus'. Thunderbird tries to look up in email, name and given
> name.
> Ans in my setup, search is restricted to "(objectclass=evolutionPerson)".
>
> SELECT DISTINCT
> ldap_entries.id,res_partner_address.id,
> text('evolutionPerson') AS objectClass,ldap_entries.dn AS dn FROM
> ldap_entries,res_partner_address,ldap_entry_objclasses
> WHERE
> res_partner_address.id=ldap_entries.keyval
> AND ldap_entries.oc_map_id=1
> AND 9=9
> AND ((2=2 OR ( ldap_entries.id=ldap_entry_objclasses.entry_id
> AND ldap_entry_objclasses.oc_name='evolutionPerson'))
> AND (( upper(email) LIKE '%KLAUS%')
> OR (upper(name) LIKE '%KLAUS%')
> OR 7=7
> OR (upper(substring(name from '\\S+..$')) LIKE '%KLAUS%')))
>
> 1) "OR 7=7 OR" renders the whole last AND-clause useless: No selection is done
> on email, name or givenname. Thus all records are returned.
>
> 2) "2=2 OR" renders the restriction to a specific objectclass useless.
>
> In Bug 5198 Pierangelo Masarati say, that a good RDBMs is optimizing this
> part away. And exactly this is the problem.
This is required to implement attribute and objectClass inheritance,
which is required by LDAP. So please don't call them "bugs", they're
required hacks. If they're not in place, back-sql would give the wrong
response to queries; if they're in place, back-sql would give the right
response, possibly inefficiently on braindead RDBMSes. Please choose
what you prefer: the wrong answer quickly or the right one maybe slower?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
Full_Name:
Version: 2.3.38
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (79.207.201.247)
Debugging marks in sql-statement may lead to wrong results.
The interface I implemented yields statements like this when using Thunderbird
for searching for 'Klaus'. Thunderbird tries to look up in email, name and given
name.
Ans in my setup, search is restricted to "(objectclass=evolutionPerson)".
SELECT DISTINCT
ldap_entries.id,res_partner_address.id,
text('evolutionPerson') AS objectClass,ldap_entries.dn AS dn FROM
ldap_entries,res_partner_address,ldap_entry_objclasses
WHERE
res_partner_address.id=ldap_entries.keyval
AND ldap_entries.oc_map_id=1
AND 9=9
AND ((2=2 OR ( ldap_entries.id=ldap_entry_objclasses.entry_id
AND ldap_entry_objclasses.oc_name='evolutionPerson'))
AND (( upper(email) LIKE '%KLAUS%')
OR (upper(name) LIKE '%KLAUS%')
OR 7=7
OR (upper(substring(name from '\\S+..$')) LIKE '%KLAUS%')))
1) "OR 7=7 OR" renders the whole last AND-clause useless: No selection is done
on email, name or givenname. Thus all records are returned.
2) "2=2 OR" renders the restriction to a specific objectclass useless.
In Bug 5198 Pierangelo Masarati say, that a good RDBMs is optimizing this
part away. And exactly this is the problem.
Ralf Haferkamp wrote:
> On Donnerstag, 29. November 2007, hyc(a)symas.com wrote:
>> rhafer(a)suse.de wrote:
>>> Full_Name: Ralf Haferkamp
>>> Version: All
>>> OS: Linux, glibc 2.7
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (89.166.161.148)
>>>
>>>
>>> Newer versions of glibc (2.7) in my case might return duplicate addrinfo
>>> structs in the results under certain circumstances. According to the
>>> friendly glibc maintainer ;) this is not a bug:
>>> http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980
>>> Unfortunately he doesn't give a reason for this change in behavior.
>> Interesting. In that bug report the /etc/hosts file has 127.0.0.1 once and
>> ::1 once, so why is 127.0.0.1 being returned twice? That is clearly bogus.
> The glibc code explicitly checks the /etc/hosts entry for IN6_IS_ADDR_LOOPBACK
> and returns the the in_attr_t for INADDR_LOOPBACK in that case. For reasons
> that the glibc author seemingly doesn't want to share with the outer world.
We're calling getaddrinfo with hints.ai_family = AF_UNSPEC, so we should be
getting both IPv4 and IPv6 addresses back. In this case, converting the V6
address to V4 format is obviously not desired.
Also RFC2553 pretty much forbids this: (Page 25)
Also note that the
IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4-
compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST
be returned and a query of the address not performed.
Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return
false for "::" and "::1".
>>> BTW, I didn't find any reference in the related RFCs that state that the
>>> getaddrinfo results need to be unique (nor the opposite).
>>> In my current builds I simply patched slapd to check the getaddrinfo()
>>> results for uniqueness in the slap_get_listner_addresses() function. Has
>>> anybody a better idea how to fix this?
>> I'm sure there's nothing that states that the returned info is required to
>> be unique. The returned data must accurately reflect the host databases
>> being queried though. If you put "127.0.0.1 localhost" twice in /etc/hosts,
>> then it's reasonable to get it returned twice. But if it's only in there
>> once, then returning it twice is a bug.
>
--
-- 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 Donnerstag, 29. November 2007, hyc(a)symas.com wrote:
> rhafer(a)suse.de wrote:
> > Full_Name: Ralf Haferkamp
> > Version: All
> > OS: Linux, glibc 2.7
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (89.166.161.148)
> >
> >
> > Newer versions of glibc (2.7) in my case might return duplicate addrinfo
> > structs in the results under certain circumstances. According to the
> > friendly glibc maintainer ;) this is not a bug:
> > http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980
> > Unfortunately he doesn't give a reason for this change in behavior.
>
> Interesting. In that bug report the /etc/hosts file has 127.0.0.1 once and
> ::1 once, so why is 127.0.0.1 being returned twice? That is clearly bogus.
The glibc code explicitly checks the /etc/hosts entry for IN6_IS_ADDR_LOOPBACK
and returns the the in_attr_t for INADDR_LOOPBACK in that case. For reasons
that the glibc author seemingly doesn't want to share with the outer world.
> > BTW, I didn't find any reference in the related RFCs that state that the
> > getaddrinfo results need to be unique (nor the opposite).
> > In my current builds I simply patched slapd to check the getaddrinfo()
> > results for uniqueness in the slap_get_listner_addresses() function. Has
> > anybody a better idea how to fix this?
>
> I'm sure there's nothing that states that the returned info is required to
> be unique. The returned data must accurately reflect the host databases
> being queried though. If you put "127.0.0.1 localhost" twice in /etc/hosts,
> then it's reasonable to get it returned twice. But if it's only in there
> once, then returning it twice is a bug.
--
Ralf
rhafer(a)suse.de wrote:
> Full_Name: Ralf Haferkamp
> Version: All
> OS: Linux, glibc 2.7
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (89.166.161.148)
>
>
> Newer versions of glibc (2.7) in my case might return duplicate addrinfo structs
> in the results under certain circumstances. According to the friendly glibc
> maintainer ;) this is not a bug:
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980
> Unfortunately he doesn't give a reason for this change in behavior.
Interesting. In that bug report the /etc/hosts file has 127.0.0.1 once and ::1
once, so why is 127.0.0.1 being returned twice? That is clearly bogus.
> BTW, I didn't find any reference in the related RFCs that state that the
> getaddrinfo results need to be unique (nor the opposite).
> In my current builds I simply patched slapd to check the getaddrinfo() results
> for uniqueness in the slap_get_listner_addresses() function. Has anybody a
> better idea how to fix this?
I'm sure there's nothing that states that the returned info is required to be
unique. The returned data must accurately reflect the host databases being
queried though. If you put "127.0.0.1 localhost" twice in /etc/hosts, then
it's reasonable to get it returned twice. But if it's only in there once, then
returning it twice is a bug.
--
-- 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/