Re: RE : Re: Fwd: (ITS#8331) Download mirror list needs updating
by hyc＠symas.com
For tracking:
David Coutadeur wrote:
>
> Hi Howard,
>
> Job done. The repository is available at:
> http://repository.linagora.com/OpenLDAP/
>
>
> Regards,
>
> David
>
> Le 17/02/2016 14:59, Howard Chu a écrit :
>> David Coutadeur wrote:
>>>
>>> Hi Howard,
>>>
>>> I didn't came back on you with that, but the proposition is still opened
>>> if it is ok for you.
>>
>> Sure, sounds great.
>>
>> It turns out to be very simple, just use rsync. The set of available
>> targets can be seen using
>> rsync --list-only rsync://openldap.org
>>
>> The releases are in OpenLDAP-ftp. The CVS repo is also available but
>> that's only of historical interest since we're now on git.
>>
>>>
>>> David
>>>
>>>
>>> Le 10/12/2015 09:08, dcoutadeur a écrit :
>>>> Ok, thank you for the reply.
>>>> Let me know when you have the information.
>>>>
>>>> David
>>>>
>>>>
>>>>
>>>> <br><br>-------- Message d'origine --------<br>De : Howard Chu
>>>> <hyc(a)symas.com> <br>Date : 08/12/2015 17:49 (GMT+01:00) <br>À
>>>> : David Coutadeur <dcoutadeur(a)linagora.com> <br>Objet : Re:
>>>> Fwd: (ITS#8331) Download mirror list needs updating <br><br>
>>>>
>>>>
>>>>
>>>> David Coutadeur wrote:
>>>> >
>>>> > Hi Howard,
>>>>
>>>> Hi David, thanks for the offer. I'm checking with Kurt to see what the
>>>> procedure is for initializing a mirror.
>>>> >
>>>> > Linagora (France) would be very interested to host a new mirror
>>>> for OpenLDAP.
>>>> > Do you have an idea of how many connections we should support ?
>>>> And what
>>>> > bandwidth ? I have made some statistics on an active mirror to
>>>> find out the
>>>> > data volume. For now it is about 1GB, so I assume 10 GB will be
>>>> sufficient for
>>>> > many years ?
>>>> >
>>>> > If you have one, can you also give me a procedure / indications
>>>> for building
>>>> > the platform ?
>>>> >
>>>> > Regards,
>>>> >
>>>> >
>>>> > Le 04/12/2015 16:04, Howard Chu a écrit :
>>>> >> A number of the mirror sites have gone offline over the years.
>>>> Anyone
>>>> >> interested in running a new mirror for us?
>>>> >>
>>>> >> -------- Forwarded Message --------
>>>> >> Subject: (ITS#8331) Download mirror list needs updating
>>>> >> Date: Fri, 04 Dec 2015 10:01:12 +0000
>>>> >> From: andrew.findlay(a)skills-1st.co.uk
>>>> >> To: openldap-its(a)OpenLDAP.org
>>>> >>
>>>> >> Full_Name: Andrew Findlay
>>>> >> Version:
>>>> >> OS:
>>>> >> URL: ftp://ftp.openldap.org/incoming/
>>>> >> Submission from: (NULL) (2001:8b0:8d0:f7e1::94)
>>>> >>
>>>> >>
>>>> >> The Netherlands mirror has vanished: ftp.nl.uu.net does not
>>>> resolve in DNS.
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>>
>>>>
>>>> --
>>>> -- Howard Chu
>>>> CTO, Symas Corp. http://www.symas.com
>>>> Director, Highland Sun http://highlandsun.com/hyc/
>>>> Chief Architect, OpenLDAP http://www.openldap.org/project/
>>>>
>>>>
>>>>
>>>> David Coutadeur wrote:
>>>>>
>>>>> Hi Howard,
>>>>
>>>> Hi David, thanks for the offer. I'm checking with Kurt to see what the
>>>> procedure is for initializing a mirror.
>>>>>
>>>>> Linagora (France) would be very interested to host a new mirror for
>>>>> OpenLDAP.
>>>>> Do you have an idea of how many connections we should support ? And
>>>>> what
>>>>> bandwidth ? I have made some statistics on an active mirror to find
>>>>> out the
>>>>> data volume. For now it is about 1GB, so I assume 10 GB will be
>>>>> sufficient for
>>>>> many years ?
>>>>>
>>>>> If you have one, can you also give me a procedure / indications for
>>>>> building
>>>>> the platform ?
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Le 04/12/2015 16:04, Howard Chu a écrit :
>>>>>> A number of the mirror sites have gone offline over the years. Anyone
>>>>>> interested in running a new mirror for us?
>>>>>>
>>>>>> -------- Forwarded Message --------
>>>>>> Subject: (ITS#8331) Download mirror list needs updating
>>>>>> Date: Fri, 04 Dec 2015 10:01:12 +0000
>>>>>> From: andrew.findlay(a)skills-1st.co.uk
>>>>>> To: openldap-its(a)OpenLDAP.org
>>>>>>
>>>>>> Full_Name: Andrew Findlay
>>>>>> Version:
>>>>>> OS:
>>>>>> URL: ftp://ftp.openldap.org/incoming/
>>>>>> Submission from: (NULL) (2001:8b0:8d0:f7e1::94)
>>>>>>
>>>>>>
>>>>>> The Netherlands mirror has vanished: ftp.nl.uu.net does not resolve
>>>>>> in DNS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years
(ITS#8378) idlcache in back hdb doesn't update existing caches on a subtree rename, causing bad search results
by jonathan＠phillipoux.net
Full_Name: Jonathan Clarke
Version: 2.4.44
OS: GNU/Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (176.182.31.158)
Hi there,
I found a bug in the handling of idl_cache when doing a MODRDN operation on an
entry with children.
The existing code to add an entry in hdb_dn2id_add (dn2id.c) cleverly updates
any existing IDL caches on the new parent and any grand-parents, both for "one"
and "sub" level searches by adding the new entry in those cache lists.
However, if you MODRDN an entry that also has children, this same hdb_dn2id_add
function is called, and will erroneously update the "sub" level search caches on
the new parent and any grand-parents, adding only the new entry, and not it's
children. The result is that a search that hits that IDL cache will return
partial results, including the entry that was moved, but missing it's children.
You can observe this behaviour by compiling a standard OpenLDAP server,
configuring a simple hdb backend, including a non-zero idlcachesize and running
the following commands:
1) ldapadd < tesldldif
2) ldapsearch -b "ou=Accepted
Inventories,ou=Inventories,cn=rudder-configuration" -s sub
objectClass=organizationalUnit
3) ldapmodrdn -s "ou=Accepted
Inventories,ou=Inventories,cn=rudder-configuration" "ou=1234,ou=Pending
Inventories,ou=Inventorie2C2Ccn=rudder-configuration" "ou=1234"
4) ldapsearch -b "ou=Accepted
Inventories,ou=Inventories,cn=rudder-configuration" -s sub
objectClass=organizationalUnit
It is important to run the initial search in step 2, before the MODRDN operation
itself, to ensure an IDL cache entry is created for that search. The final
search in step 4 will not show the sub-entry ou=1234-sub,ou=1234.
The test.ldif file is here: ftp://ftp.openldap.org/incoming/test.ldif
I've created a quick'n'dirty patch to hide this issue, which detects the
situation (if adding an entry that already has children, this is when the bug
occurs) and simply removes the IDL cache to avoid future searches using it. It's
available here: ftp://ftp.openldap.org/incoming/openldap-dn2id-modrdn-idlcache-sub-delete....
A better solution would probably be to write the code to add each child of the
new entry to existing caches, but I couldn't immediately see how to do this.
Hopefully my patch above will easily show where this needs doing.
Regards,
Jonathan
7 years
(ITS#8377) Normalized 'olcDbIndex' values
by michael＠stroeder.com
Full_Name:
Version: master
OS:
URL:
Submission from: (NULL) (213.240.182.49)
A suggestion for 2.5:
Index lines read from slapd.conf should be converted to normalized 'olcDbIndex'
values. With this approach it would be possible to determine index configuration
for a certain attribute type.
Likewise the format of accepted attribute values should be constrained.
Example from slapd.conf:
index foo,bar eq,sub
would be normalized to 4 values:
olcDbIndex: foo eq
olcDbIndex: foo sub
olcDbIndex: bar eq
olcDbIndex: bar sub
7 years
(ITS#8376) Use getaddrinfo to resolve FQDN
by hguo＠suse.com
Full_Name: Howard Guo
Version: 2.4.44
OS: openSUSE
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.135.221.2)
In a pure IPv6 environment, if LDAP is used as the host resolve, the host may
hang when it attempts to resolve its own host name due to usage of
gethostbyname*, in the following sequence of events:
nss_ldap: locks mutex
nss_ldap: calls libldapA-A-> libldap: gethostbyname
-> nss_ldap: lock mutex and hang
See patch file "howard-guo-160222.patch".
7 years
(ITS#8375) paged results control results in full db search?
by geert＠hendrickx.be
Full_Name: Geert Hendrickx
Version: 2.4.44
OS: Linux
URL: http://www.openldap.org/lists/openldap-technical/201602/msg00094.html
Submission from: (NULL) (2a02:1810:4d03:d00:18e9:3ca5:a68f:c7f4)
We found an odd issue when using LDAP Admin (www.ldapadmin.org), which by
defaults uses the paged results control (RFC 2696) to limit search results.
This client initially issues an objectclass=* search with one-level scope
to list the first-level objects/trees on the LDAP DIT, which you can then
browse/expand by clicking on them.
On a large db, we noticed this initial search hits the timelimit, even
though the equivalent command line search is instant. I found the
difference is in using the paged result control:
ldapsearch -s one -E \!pr=100 objectclass=\* objectclass => slow
ldapsearch -s one objectclass=\* objectclass => fast
The slapd stats+trace logging of each is in attachment. Notice the large
number of objects being skipped with "scope not okay" in the first, where
this does not happen in the second. This slows down the search, and on a
very large db, makes it exceed the configured 60 seconds timelimit.
A third variant, setting the sizelimit explicitly, avoids the issue:
ldapsearch -s one -E \!pr=100 -z 100 objectclass=\* objectclass => fast
Is this expected behaviour?
7 years
RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com
Ok, retested with latest code built from source.
I also reconfirmed using a publicly available openldap server, to make sure it isn't something stupid I am doing locally.
So you can reproduce easily, the test pseudo code is:
ldap_initialize (ldaps://ldap.andrew.cmu.edu)
ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT (enumerate options)
ldap_sasl_bind_s
ldap_initialize (ldap://128.2.11.104)
ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT (enumerate options)
ldap_start_tls_s
ldap_sasl_bind_s
The results are:
Server with valid certificate, all values of LDAP_OPT_X_TLS_REQUIRE_CERT for both ldaps and ldap+starttls connect. This is what I would expect.
Server with invalid certificate (IP does not match the cert FQDN), only NEVER and ALLOW values of LDAP_OPT_X_TLS_REQUIRE_CERT succeed for ldaps (this is what I would expect) however all values of LDAP_OPT_X_TLS_REQUIRE_CERT for ldap+starttls succeed, which is not what I would expect: I think that the certificate check should fail the connection, as per the ldaps behaviour.
Martin...
7 years, 1 month
RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com
Hi,
This is a piece of code that I'm working on, rather than any bundled commands. The code works just fine (has for months) however I noticed in unit testing the operations empirically that the LDAP_OPT_X_TLS_REQUIRE_CERT option was handled differently depending on whether the TLS was provided implicitly over an ldaps: URI, or explicitly on an ldap: URI with STARTTLS.
The pseudo sequence of functions is as follows:
ldap_initialize
ldap_set_option (various)
if uri != ldaps: then ldap_start_tls_s
ldap_sasl_bind_s
Martin...
7 years, 1 month
