Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org
On Feb 24, 2009, at 1:01 PM, richm(a)stanfordalumni.org wrote:
> Kurt Zeilenga wrote:
>>
>> On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote:
>>
>>> Kurt(a)OpenLDAP.org wrote:
>>>> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote:
>>>>
>>>>
>>>>> I'm still uncertain about how configure should detect the NSS
>>>>> header
>>>>> files
>>>>> though; they are not in any standardized location yet AFAICS.
>>>>>
>>>>
>>>> Like with other things, I would assume the environment to be
>>>> adjusted
>>>> to find the right NSS prior to running configure.
>>>>
>>> I'm not sure I understand what you mean by "environment to be
>>> adjusted"
>>
>> CPPFLAGS, CFLAGS, ... and PATH environmental variables.
>>
>>>
>>> - How does openldap detect the header files for other components?
>>
>> autoconf is used, which uses the compiler to check if necessary
>> headers are there, with the (additional to those built into the
>> compiler) header path specified via CPPFLAGS.
>>
>> The idea here is to give the builder the freedom over which header
>> directories are searched, and the order in which they are searched.
> What's the usual way that openldap does this for packages installed in
> non-standard locations e.g. if I want to have my own private build of
> cyrus-sasl? Is it up to the user to specify
> CPPFLAGS=-I/path/to/nonstd/sasl/include and
> LDFLAGS=-L/path/to/nonstd/lib ?
Yes.
> Does openldap configure have a
> --with-sasl=/path/to/nonstd/sasl option?
No. Because CPPFLAGS and LDFLAGS mechanism exists and provides more
control to the builder.
>
>
> Perhaps a better question is - how would you like it to work?
I prefer that we leave the builder with as freedom as possible.
> I'm assuming there must be some way specify which crypto you want to
> build
> openldap with - is that a configure option?
Presently there is:
--with-tls=[auto,openssl,gnutls]
I assume we'd just add an 'nss' option to the above. However, Howard
might have other things in mind.
>
>>
>>> Note
>>> that both NSPR and NSS support pkg-config
>>
>> Here would be to ensure that the proper pkg-config is in the PATH.
>>
>> Of course, pkg-config stuff gets stuff into the environment in some
>> fixed order, which does take away some freedom from the builder. I
>> guess the builder can always manually adjust the order (by providing
>> CPPFLAGS, etc., directly) and then provide a pkg_config which does
>> little. So the freedom is there, just harder to take advantage of.
> The original patch -
> ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch -
> assumes the use of pkg-config - I suppose that is not sufficient.
My only concern would be whether or not pkg-config use here is
specific to a particular 3rd party packaging of NSS versus something
available with all installs of NSS.
I'll be leaving the actual technical review of your patch to Howard or
other active committers.
-- Kurt
12 years, 10 months
Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by richm＠stanfordalumni.org
Kurt Zeilenga wrote:
>
> On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote:
>
>> Kurt(a)OpenLDAP.org wrote:
>>> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote:
>>>
>>>
>>>> I'm still uncertain about how configure should detect the NSS header
>>>> files
>>>> though; they are not in any standardized location yet AFAICS.
>>>>
>>>
>>> Like with other things, I would assume the environment to be adjusted
>>> to find the right NSS prior to running configure.
>>>
>> I'm not sure I understand what you mean by "environment to be adjusted"
>
> CPPFLAGS, CFLAGS, ... and PATH environmental variables.
>
>>
>> - How does openldap detect the header files for other components?
>
> autoconf is used, which uses the compiler to check if necessary
> headers are there, with the (additional to those built into the
> compiler) header path specified via CPPFLAGS.
>
> The idea here is to give the builder the freedom over which header
> directories are searched, and the order in which they are searched.
What's the usual way that openldap does this for packages installed in
non-standard locations e.g. if I want to have my own private build of
cyrus-sasl? Is it up to the user to specify
CPPFLAGS=-I/path/to/nonstd/sasl/include and
LDFLAGS=-L/path/to/nonstd/lib ? Does openldap configure have a
--with-sasl=/path/to/nonstd/sasl option?
Perhaps a better question is - how would you like it to work? I'm
assuming there must be some way specify which crypto you want to build
openldap with - is that a configure option?
>
>> Note
>> that both NSPR and NSS support pkg-config
>
> Here would be to ensure that the proper pkg-config is in the PATH.
>
> Of course, pkg-config stuff gets stuff into the environment in some
> fixed order, which does take away some freedom from the builder. I
> guess the builder can always manually adjust the order (by providing
> CPPFLAGS, etc., directly) and then provide a pkg_config which does
> little. So the freedom is there, just harder to take advantage of.
The original patch -
ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch -
assumes the use of pkg-config - I suppose that is not sufficient.
>
> -- Kurt
>
>
12 years, 10 months
Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org
On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote:
> Kurt(a)OpenLDAP.org wrote:
>> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote:
>>
>>
>>> I'm still uncertain about how configure should detect the NSS header
>>> files
>>> though; they are not in any standardized location yet AFAICS.
>>>
>>
>> Like with other things, I would assume the environment to be adjusted
>> to find the right NSS prior to running configure.
>>
> I'm not sure I understand what you mean by "environment to be
> adjusted"
CPPFLAGS, CFLAGS, ... and PATH environmental variables.
>
> - How does openldap detect the header files for other components?
autoconf is used, which uses the compiler to check if necessary
headers are there, with the (additional to those built into the
compiler) header path specified via CPPFLAGS.
The idea here is to give the builder the freedom over which header
directories are searched, and the order in which they are searched.
> Note
> that both NSPR and NSS support pkg-config
Here would be to ensure that the proper pkg-config is in the PATH.
Of course, pkg-config stuff gets stuff into the environment in some
fixed order, which does take away some freedom from the builder. I
guess the builder can always manually adjust the order (by providing
CPPFLAGS, etc., directly) and then provide a pkg_config which does
little. So the freedom is there, just harder to take advantage of.
-- Kurt
12 years, 10 months
Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by richm＠stanfordalumni.org
Kurt(a)OpenLDAP.org wrote:
> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote:
>
>
>> I'm still uncertain about how configure should detect the NSS header
>> files
>> though; they are not in any standardized location yet AFAICS.
>>
>
> Like with other things, I would assume the environment to be adjusted
> to find the right NSS prior to running configure.
>
I'm not sure I understand what you mean by "environment to be adjusted"
- How does openldap detect the header files for other components? Note
that both NSPR and NSS support pkg-config
> -- Kurt
>
>
>
>
>
12 years, 10 months
Re: (ITS#5974) libldap not consistently using namespaces
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> ando(a)sys-net.it writes:
>> Since all those functions are not meant to be exposed, I guess fixing
>> the (mis)use of the ldap namespace should not create issues.
> Wait for 2.5 to break binary compatibility. If a function is there and
> is useful, people will dig it out and use it.
Agreed. But we can probably fix slapd's use of ldap_int APIs.
> Just like back-bdb used
> (uses?) some internal Berkeley DB locking function.
(Not any more...)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 10 months
Re: (ITS#5974) libldap not consistently using namespaces
by ando＠sys-net.it
h.b.furuseth(a)usit.uio.no wrote:
> ando(a)sys-net.it writes:
>> Since all those functions are not meant to be exposed, I guess fixing
>> the (mis)use of the ldap namespace should not create issues.
>
> Wait for 2.5 to break binary compatibility.
Sure, no hurry. I'm just getting a bit confused when digging into very
nested libldap stuff...
> If a function is there and
> is useful, people will dig it out and use it.
That's probably my last concern, 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
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
12 years, 10 months
Re: (ITS#5974) libldap not consistently using namespaces
by h.b.furuseth＠usit.uio.no
ando(a)sys-net.it writes:
> Since all those functions are not meant to be exposed, I guess fixing
> the (mis)use of the ldap namespace should not create issues.
Wait for 2.5 to break binary compatibility. If a function is there and
is useful, people will dig it out and use it. Just like back-bdb used
(uses?) some internal Berkeley DB locking function.
--
Hallvard
12 years, 10 months
(ITS#5974) libldap not consistently using namespaces
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version: any
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando
There are quite a few local functions with no namespace (e.g.
re_encode_request()), but what seems to be mostly incorrect is ldap namespace
pollution (e.g. ldap_chase_v3referrals()). Finally, there are quite a few
occurrences of ldap_int_tls_config() used outside libldap (in slapd).
Since all those functions are not meant to be exposed, I guess fixing the
(mis)use of the ldap namespace should not create issues.
p.
12 years, 10 months
(ITS#5973) Syncrepl can update more than one csn value
by rein＠OpenLDAP.org
Full_Name: Rein Tollevik
Version: CVS HEAD
OS: irrelevant
URL:
Submission from: (NULL) (81.93.160.250)
Submitted by: rein
Syncrepl can update more than one csn value in one operation, but only one can
be passed to syncprov in the csn queue. Syncprov should instead pick the
updated values from the modify operation.
A patch that fixes this is coming. This patch depends on the ITS#5972 patch,
and is required for the new test058 to succeed.
Rein Tollevik
Basefarm AS
12 years, 10 months
(ITS#5972) Send newCookie sync info messages
by rein＠OpenLDAP.org
Full_Name: Rein Tollevik
Version: CVS HEAD
OS: irrelevant
URL:
Submission from: (NULL) (81.93.160.250)
Submitted by: rein
When syncprov updates its local contextCSN value after some modification took
place this update will not be propagated to consumers that doesn't receive the
updated entry (it could fail to match the filter, or access control could
prevent it). In this case, the consumer will have an old contextCSN value
although its content is up to date.
The provider should in this case send a newcookie sync info message to the
consumer with its updated contextCSN value. A patch that implements this is
coming. This patch is required for the new test058 to succeed.
Rein Tollevik
Basefarm AS
12 years, 10 months
