--On Friday, March 10, 2017 9:43 PM +0000 bwright(a)intacct.com wrote:
> If you plan on retaining --with-threads=no feature, someone might want to
> update the test suite to properly test LDAP when threads are disabled. Or
> alternatively, inform the user that 'make test' doesn't support testing
> LDAP when threads are disabled.
Thanks for the report and great suggestion.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--On Monday, September 12, 2016 3:39 PM +0000 michael(a)stroeder.com wrote:
Thanks for the report. This was fixed as part of the work on ITS#8185.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Full_Name: Christopher Klinge
Version: 2.4.44
OS: Debian
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (93.193.142.51)
As of right now, dynlist can be used to expand one level of nesting:
overlay dynlist
dynlist-attrset parentGroup childGroup
dn: cn=Parent Group,ou=Groups,dc=example,dc=com
objectClass: parentGroup
cn: Parent Group
childGroupURL: ldap:///cn=Child Group,ou=Groups,dc=example,dc=com?member?sub?
dn: cn=Child Group,ou=Groups,dc=example,dc=com
objectClass: childGroup
cn: Child Group
member: cn=User A,ou=People,dc=example,dc=com
member: cn=User B,ou=People,dc=example,dc=com
member: cn=User B,ou=People,dc=example,dc=com
Querying the parent group will return:
dn: cn=Parent Group,ou=Groups,dc=example,dc=com
objectClass: parentGroup
cn: Parent Group
childGroupURL: ldap:///cn=Child Group,ou=Groups,dc=example,dc=com?member?sub?
member: cn=User A,ou=People,dc=example,dc=com
member: cn=User B,ou=People,dc=example,dc=com
member: cn=User C,ou=People,dc=example,dc=com
If cn=Child Group were to be a parent group itself, no further expansion would
take place.
I propose enabling dynlist recursion and adding a new configuration directive:
dynlist-rec-attrset <group-oc> [<URI>] <URL-ad> <rec-ad>
[[<mapped-ad>:]<member-ad>]
Except for rec-ad, all parameters behave exactly like those of dynlist-attrset.
The attribute rec-ad is mandatory. It is a comma separated list of attributes
for which dynlist recursion is enabled.
By adding a new directive, backwards compatibility is guaranteed.
I suggest using a depth counter to prevent infinite loops. A configurable
threshold with a fairly small default value is both light weight and
sufficiently rigorous. Logging a suitable warning message upon reaching the
threshold would inform the administrator about possible loops.
--On Friday, July 15, 2016 4:15 PM +0000 norbert.massa(a)yopmail.com wrote:
> Full_Name: Norbert MASSA
> Version: 2.4.40
> OS: CentOS 7.1
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (62.240.254.57)
Hi Norbert,
There's virtually nothing to go on in this bug report. I.e. no
configuration information, etc. What backend were you using (bdb? hdb?
mdb?) etc.
I'd also note that the ldapsearch you provided would not give a complete
backup (It's missing dumps of the operational attributes).
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--On Thursday, July 28, 2016 12:59 PM +0000 avijeett007(a)gmail.com wrote:
Hello,
This does not sound like a report for a bug in the OpenLDAP Software.
OpenLDAP does not distribute startup scripts. I would suggest following up
with your OS provider, since running slapd manually works as expected.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--On Thursday, August 11, 2016 5:53 AM +0000 demiobenour(a)gmail.com wrote:
> Also, why the self-signed certificate at all? ??Let's Encrypt is
> providing free certificates.
This should now be fixed.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--On Wednesday, March 15, 2017 11:51 PM +0000 jaroslaw.wencel(a)gmail.com
wrote:
> Full_Name: Jaroslaw Wencel
> Version: 2.4.42
> OS: Ubuntu 16.04.1
> URL:
> Submission from: (NULL) (46.227.243.233)
>
>
> Hi
>
> I'm trying to develop configuration which includes Active Directory
> catalogue into main LDAP tree I have in my configuration. Everything
> works well while using slapd-meta as long as I do not try to combine it
> with rwm overlay.
>
> LDAP crashes while invoking modrdn change (refer to attached
> crashme.ldif) with the configuration as in config.ldif.
>
> modrdn change works well until I add dn:
> olcOverlay={0}rwm,olcDatabase={1}meta,cn=config to the configuration.
>
> I'm using OpenLDAP 2.4.42 installed from Ubuntu repositories (latest
> version from 16.04.01).
> I have uploaded
> ftp://ftp.openldap.org/incoming/Jaroslaw-Wencel-170315.tgz to the ftp
> server, archive file contains:
> - config.ldif - dump of ldap configuration from the moment modrdn
> operation crashes the server
> - crashme.ldif - the ldif file I'm using for invoking modrdn operation
> - crash.logs - slapd daemon log
>
> Please let me know if you have any further questions
Hi,
Thanks for the report! There are a number of known existing issues with
slapo-rwm, so the detail provided here is quite useful.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--On Saturday, March 11, 2017 11:55 AM +0000 info(a)gwarband.de wrote:
> Full_Name: Tobias Warband
> Version: 2.4.40+dfsg-1+deb8u2
> OS: Debian 8
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (149.172.171.148)
>
>
> Hello,
>
> I'm trying to configure dovecot with ldapconnection over starttls (Secure
> LDAP).
> I belief the problem is something with the methode ldap_start_tls_s()
> or ldap_int_tls_connect() that's called from the first.
> Other software can connect to the openldapserver e.g. postfix,
> openxchange, apache.
> All logs and configs are in the URL below.
Hi Tobias,
The ITS system is for reporting bugs in OpenLDAP. Nothing in this report
indicates a bug with OpenLDAP. In fact the information you provide about
other processes being able to connect to OpenLDAP without inssue further
indicate no bug with OpenLDAP. Generally, I would advise you seek support
from the Dovecot authors, as it is their product that is having issues, and
they should be able to provide accurate and detailed information on how to
properly configure their software to interface with LDAP. Alternatively,
you may wish to try the openldap-technical list if discussing with the
Dovecot community does not resolve the problem.
This ITS will be closed.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Full_Name: Alexandre Rosenberg
Version: 2.4.44
OS: Linux - CentOS7
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (125.30.6.137)
I found some unexpected behavior when using both '-h' and '-p' option with
ldapserach.
== Reproduce:
- Use the '-h' option with an invalid hostname such as a URI
- Also set a (valid) port using the '-p' option
== Result:
If those condition are met, ldapearch seem to always connect to localhost on
port 389
$ ldapsearch -x -d 255 -h ldap://localhost -p 10389
ldap_create
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP localhost:389
== Expected behavior:
Failure due to invalid hostname
== Note:
This *only* happens when both '-h' and '-p' are used.
When only '-h' is used, following happens which seem fine:
$ ldapsearch -x -d 255 -h ldap://localhost
ldap_create
ldap_url_parse_ext(ldap://ldap:%2F%2Flocalhost)
ldap_err2string
Could not create LDAP session handle for URI=ldap://ldap:
%2F%2Flocalhost (-9): Bad parameter to an ldap routine
== Additional example:
Bellow are some more example - note adding "/" to the hostname is enough to
trigger the issue.
1. $ ldapsearch -x -d 255 -h example.org -p 10636
-> Connects to example.org on port 10636 (as expected)
2. $ ldapsearch -x -d 255 -h /example.org -p 10636
-> Connects to localhost on port 389 (!) - note the added "/"
3. $ ldapsearch -x -d 255 -h /example.org
Running the command will give you the debug output (which I omitted here). Note
I am using openldap 2.4.44.
Full_Name: Jaroslaw Wencel
Version: 2.4.42
OS: Ubuntu 16.04.1
URL:
Submission from: (NULL) (46.227.243.233)
Hi
I'm trying to develop configuration which includes Active Directory catalogue
into main LDAP tree I have in my configuration. Everything works well while
using slapd-meta as long as I do not try to combine it with rwm overlay.
LDAP crashes while invoking modrdn change (refer to attached crashme.ldif) with
the configuration as in config.ldif.
modrdn change works well until I add dn:
olcOverlay={0}rwm,olcDatabase={1}meta,cn=config to the configuration.
I'm using OpenLDAP 2.4.42 installed from Ubuntu repositories (latest version
from 16.04.01).
I have uploaded ftp://ftp.openldap.org/incoming/Jaroslaw-Wencel-170315.tgz to
the ftp server, archive file contains:
- config.ldif - dump of ldap configuration from the moment modrdn operation
crashes the server
- crashme.ldif - the ldif file I'm using for invoking modrdn operation
- crash.logs - slapd daemon log
Please let me know if you have any further questions
Thanks
Jaroslaw Wencel