Re: (ITS#5102) back-perl build issues
by hyc＠symas.com
quanah(a)zimbra.com wrote:
> In the name of getting 2.4.5 released, I've updated to Kurt's suggestion
> until such a time as this can be acted upon otherwise.
That's fine.
But I think renaming config.h to slapconf.h is a good idea anyway.
Another thing that has nagged me ever since we unified the slap tools into
slapd - should have renamed slapadd.c -> tooladd.c etc...
Any objections?
--
-- 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/
16 years
Re: (ITS#5102) back-perl build issues
by quanah＠zimbra.com
--On August 25, 2007 7:34:22 AM +0000 ando(a)sys-net.it wrote:
> Kurt Zeilenga wrote:
>
>>> ConfigReply is declared in slapd/config.h; could it be another,
>>> system-related config.h is present in an earlier include path?
>>>
>>> Even though, I see in the above cc command-line -I .. is present...
>>
>> Personally, I think have -I., -I.., etc. is really bad. This causes
>> # include "config.h"
>> and
>> # include <config.h>
>>
>> to be equivalent. However, there could be both a local config.h and a
>> config.h somewhere in the system include directory.
>>
>> I would be better if slapd/config.h was included here by:
>> # include "../config.h"
>>
>> and -I.. not be added to the include path. It possible -I.. is causing
>> a system header to be eclipsed by the local header.
>
> -I.. is needed to include slap.h, proto-slap.h, ...
>
> I'd rather rename config.h, which is quite generic, into slapconf.h or so.
In the name of getting 2.4.5 released, I've updated to Kurt's suggestion
until such a time as this can be acted upon otherwise.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
16 years
Re: ITS#5112 -> 4
by rhafer＠suse.de
On Thursday 30 August 2007 20:34, Pierangelo Masarati wrote:
> Ralf,
>
> are you working at ITS#5112-4?
Yes. I have a fix for #5112 (the memory leak) mostly ready. As you/Howard
suggested I just moved the cache populating code into the cleanup handler,
seems to work quite well and has the advantage that final result is send to
the client a lot earlier when caching large results (as you already noted).
I am currently looking into fixing #5113. Haven't worked on #5114 yet, but the
basic fix should be fairly easy. Changing the code to handle the limits
inside pcache might be a bit harder though.
> I might work on them during the weekend,
> if you don't. It is my intention to avoid interfering with the release
> of 2.4.5, though.
Yes, that's what I intend as well. That's why I didn't submit anything yet.
--
Ralf
16 years
Re: (ITS#5116) registeredAddress cannot be deleted
by binoy＠cordys.com
Hi,
Please ignore the earlier message. It was a mistake.
>Quanah Gibson-Mount [quanah(a)zimbra.com] wrote
>This isn't a bug. Fix the way you delete the attribute.
I use
LDAPModification mdfn = new LDAPModification(LDAPModification.DELETE,
entry.getAttribute("registeredAddress"));
connection.modify(entry.getDN(), mdfn);
Any suggestion on how should I correct this?
Thanks and Regards,
Binoy Joseph
***********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the
intended recipient, any disclosure, copying, or distribution of the
message, or any action or omission taken by you in reliance on
it is prohibited and may be unlawful. Please immediately contact
the sender if you have received this message in error. This email
does not constitute any commitment from Cordys Holding BV or
any of its subsidiaries except when expressly agreed in a written
agreement between the intended recipient and
Cordys Holding BV or its subsidiaries.
***********************************************************************
16 years
ITS#5112 -> 4
by ando＠sys-net.it
Ralf,
are you working at ITS#5112-4? I might work on them during the weekend,
if you don't. It is my intention to avoid interfering with the release
of 2.4.5, though.
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
---------------------------------------
16 years
Re: (ITS#5116) registeredAddress cannot be deleted
by quanah＠zimbra.com
--On Thursday, August 30, 2007 9:28 AM +0000 binoy(a)cordys.com wrote:
> Full_Name: Binoy
> Version: 2.2.26
> OS: Windows
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (210.210.79.19)
>
>
> The attribute registeredAddress of an authenticationUser, once entered;
> cannot be deleted. The error says, no equality matching rule.
This isn't a bug. Fix the way you delete the attribute.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
16 years
Re: (ITS#5115) SASL authentication for AD
by quanah＠zimbra.com
--On Wednesday, August 29, 2007 6:25 PM +0000 rbeckett(a)exelixis.com wrote:
> Any help would be appreciated.
The ITS system is for bugs, not for issues you have building OpenLDAP. I
suggest reading the OpenLDAP FAQ entries on linking, and becoming generally
familiar with how to build software in non-standard paths.
The FAQ entry can be found at:
<http://www.openldap.org/faq/data/cache/1113.html>
My OpenSSL build looked like:
%configure
env CC=/usr/local/bin/gcc CFLAGS='-g -O2' CXXFLAGS='-g -O2' \
PERL=/usr/bin/perl LD_RUN_PATH=/usr/local/lib \
./Configure --prefix=/usr/local --openssldir=/usr/local/openssl \
shared linux-x86_64 -g -O2
%build
env LD_RUN_PATH="/usr/local/lib" make
%install
env LD_LIBRARY_PATH="/usr/local/lib" \
LD_RUN_PATH="/usr/local/lib" \
make install INSTALL_PREFIX=%package%
Note the use of LD_RUN_PATH. My OpenLDAP build looked like:
%configure
LD_LIBRARY_PATH="/usr/local/lib" CC=/usr/local/bin/gcc
CXX=/usr/local/bin/g++ CFLAGS='-g -O2 -DSLAP_LIGHTWEIGHT_DISPATCHER'
CXXFLAGS='-g -O2' sh configure --datadir='${prefix}/lib'
--libexecdir='${prefix}/lib' --sharedstatedir='${prefix}/lib' \
--prefix=/usr/local \
--disable-ipv6 \
--with-cyrus-sasl \
--with-tls \
--enable-dynamic \
--enable-slapd \
--enable-modules \
--enable-spasswd \
--enable-rewrite \
--enable-rlookups \
--enable-wrappers \
--enable-backends=mod \
--disable-shell \
--disable-sql \
--enable-overlays=mod \
--enable-slurpd=yes \
--enable-slapi=yes
make depend
%build
make -j3
%check
make test
%install
make install DESTDIR=%package% STRIP=""
I'll also note that the error you are receiving from the SASL bind has
nothing to do with SSL specifically. All it notes is that the AD server
has no SASL mechanisms presented that match the SASL mechanisms available
to OpenLDAP. If you are wanting to support SASL/EXTERNAL, you'll
definitely need to fix your build with OpenSSL support.
I've compiled OpenSSL into /usr/local on many occassions without problem,
but I use the correct flags to gcc, too, which I don't see indicated in
your build.
You do not indicate whether or not you link OpenLDAP against cyrus-sasl,
but that will be necessary for support of some of the other SASL
mechanisms. If you plan on doing SASL/GSSAPI binds to AD, you'll also need
to build a Kerberos distribution for its libraries (I suggest Heimdal), and
link cyrus-sasl against that before building OpenLDAP linked against
cyrus-sasl.
You may also want to read:
<http://www.stanford.edu/services/directory/openldap/configuration/>
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
16 years
(ITS#5115) SASL authentication for AD
by rbeckett＠exelixis.com
Full_Name: Richard Beckett
Version: 2.3.38
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (65.209.203.254)
I have posted this before but still have not resolved the problem.
I am building OpenLDAP 2.3.38. on a RHEL ES v4 host
When I make it without having first built TLS/SSL (openssl-0.9.8e) it builds and
runs fine. However I need the SSL and SASL to authenticate to an Active
Directory server.
When I build SSL as follows:
./configure shared --openssldir=/usr/local
make
make install
and then try to make OpenLDAP I ge the following:
cc -g -O2 -o apitest apitest.o ./.libs/libldap.a
/usr/local/src/LDAP/openldap-2.3.38/libraries/liblber/.libs/liblber.a
-L/usr/kerberos/lib -L/lib -L/usr/lib/mysql
../../libraries/liblber/.libs/liblber.a ../../libraries/liblutil/liblutil.a
/usr/lib/libsasl2.so -ldl -lcrypt -lssl -lcrypto -lresolv
./.libs/libldap.a(os-ip.o)(.text+0x606): In function `ldap_connect_to_host':
/usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/os-ip.c:205: warning:
`sys_errlist' is deprecated; use `strerror' or `strerror_r' instead
./.libs/libldap.a(os-ip.o)(.text+0x5fd):/usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/os-ip.c:205:
warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead
./.libs/libldap.a(tls.o)(.text+0x593): In function `sb_tls_bio_read':
/usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/tls.c:676: undefined
reference to `BIO_clear_flags'
./.libs/libldap.a(tls.o)(.text+0x5b8):/usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/tls.c:680:
undefined reference to `BIO_set_flags'
./.libs/libldap.a(tls.o)(.text+0x60b): In function `sb_tls_bio_write':
/usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/tls.c:703: undefined
reference to `BIO_clear_flags'
./.libs/libldap.a(tls.o)(.text+0x630):/usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/tls.c:707:
undefined reference to `BIO_set_flags'
./.libs/libldap.a(tls.o)(.text+0x19f0): In function
`ldap_pvt_tls_init_def_ctx':
/usr/local/src/LDAP/openldap-2.3.38/libraries/libldap/tls.c:374: undefined
reference to `SSL_CTX_set_info_callback'
collect2: ld returned 1 exit status
make[2]: *** [apitest] Error 1
make[2]: Leaving directory
`/usr/local/src/LDAP/openldap-2.3.38/libraries/libldap'
make[1]: *** [all-common] Error 1
make[1]: Leaving directory `/usr/local/src/LDAP/openldap-2.3.38/libraries'
make: *** [all-common] Error 1
My environment is:
HOSTNAME=ldaplx01.exelixis.com
TERM=xterm
SHELL=/bin/bash
HISTSIZE=1000
SSH_CLIENT=::ffff:172.29.4.19 51159 22
OLDPWD=/usr/local/lib
SSH_TTY=/dev/pts/1
USER=root
LD_LIBRARY_PATH=/usr/local/lib
LS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35:*.bmp=00;35:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35:
MAIL=/var/spool/mail/root
PATH=/opt/quest/bin:/opt/quest/sbin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin
INPUTRC=/etc/inputrc
PWD=/usr/local/src/LDAP/openldap-2.3.38
LANG=en_US.UTF-8
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
SHLVL=1
HOME=/root
LOGNAME=root
SSH_CONNECTION=::ffff:172.29.4.19 51159 ::ffff:172.29.24.108 22
LESSOPEN=|/usr/bin/lesspipe.sh %s
G_BROKEN_FILENAMES=1
_=/bin/env
Without SSL I am unable to authenticate to the Active Directory server. I get
the following message:
SASL/EXTERNAL authentication started
ldap_perror
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available:
I have ssl yes set in /etc/ldap.conf and I assume (always dangerous) that the
problem lies with the fact that I am unable to build ldap with SSL.
Any help would be appreciated.
Richard-Beckett-070829
16 years
Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by hyc＠symas.com
ando(a)sys-net.it wrote:
> rhafer(a)suse.de wrote:
>> On Wednesday 29 August 2007 18:48, ando(a)sys-net.it wrote:
>>> rhafer(a)suse.de wrote:
>>>> But a malicous client can then just send requests with sizelimit 1. Those
>>>> query will get cached and the database is of no real use anymore (IMO).
>>> Well, in this case, the proxycache should either change the sizelimit
>>> (and the timelimit) to unlimited, and deal with client-requested limits
>>> locally,
>> This seems like the nicest approach to solve the problem. But seems to be a
>> bit more effort.
>
> I'd go this way, yes.
>
>> My suggest for a quick fix for this issue would be to just not cache queries
>> that return one off the _LIMIT_EXCEEDED error codes. Probably with checking
>> if it was a client-requested limit or a limit of the server side (in which
>> case we could probably cache the results).
>
> Then please make a clear statement in the code that it's a temporary
> workaround, so it is easier to spot and remove, eventually.
>
>>> or consider uncacheable those requests that specify a time or a
>>> size limit.
>> Well that would cause even those queries being uncachable that would not hit
>> the requested limit. If I understand you correctly.
>
> Right. Well, I understand if no limit was hit the request would become
> cacheable. In this case, the approach you suggest would be fine.
Of course the result size has to also fit within the cache's configured size
limit. We may want to add another type of negative caching record here for this
case "we already know the result set is too large, ignore the cache DB"...
--
-- 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/
16 years
