openldap-bugs

openldap-bugs@openldap.org

1 participants
21106 discussions

Re: (ITS#6586) PASSMOD operations are not getting chained correctly
by masarati＠aero.polimi.it 30 Jul '10

30 Jul '10

> Every other write gets chained just fine when a slave is in this > condition. It's only the PASSMOD operations that are stuck. One quick question: can you tell the parameters of the offending PASSMOD operations? I mean: old/new password, password generated automatically or provided, operation performed for self or by a privileged identity, and so? Thanks, p.

1 0

ITS#6611
by masarati＠aero.polimi.it 30 Jul '10

30 Jul '10

Likely your ACL is exceeding ACLBUF_MAXLEN (8192, defined in servers/slapd/aclparse.c); you can workaround this issue by increasing that value to something *very* large, while the code is fixed. However, you should fix your configuration by assigning those DNs to a group, and using a group ACL instead. p.

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by masarati＠aero.polimi.it 30 Jul '10

30 Jul '10

> Hey Pierangelo, > > I just noticed http://www.openldap.org/its/index.cgi?findid=6574 - this > looks like it fixes the issue I mentioned in > http://www.openldap.org/its/index.cgi?findid=6540? Is that assertion > correct? I couldn't specifically look at your issue (apart from the simple fix to allow cn=config to work). ITS#6574 should have nothing to do with your issue, as it affects back-meta in a part that has no code commonality with back-ldap, and slapo-chain is built on top of back-ldap. I'm sorry I went back through this thread and got somehow lost; what's the exact topic now? I infer (from followup #14) that there seems to be an issue about chaining because slapo-chain seems not to rebind as expected. Could you isolate the problem in a minimal setup (slapd.conf or the corresponding back-config's LDIF, a database and a simple operation that can be performed with ldapmodify/ldappasswd or so) to clearly reproduce the issue? Thanks, p.

1 0

(ITS#6611) slapd: segmentation fault caused by large ACL
by leonardo＠ngdn.org 30 Jul '10

30 Jul '10

Full_Name: Leonardo Chiquitto Version: 2.4.23 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (189.101.104.29) Setting up a large ACL entry (as the example below) in slapd.conf will make slapd crash with a segmentation fault when starting up. access to dn.subtree="ou=autofs,ou=l,dc=ngdn,dc=org" by dn.base="cn=1,ou=autofs,ou=l,dc=ngdn,dc=org" read by dn.base="cn=2,ou=autofs,ou=l,dc=ngdn,dc=org" read (...) by dn.base="cn=149,ou=autofs,ou=l,dc=ngdn,dc=org" read by dn.base="cn=150,ou=autofs,ou=l,dc=ngdn,dc=org" read Here's the back trace: Program terminated with signal 11, Segmentation fault. #0 0x00007fd98e223b68 in avl_find (root=0x3d63642c6c3d756f, data=0x7fffa163d0c0, fcmp=0x7fd98e1400e0 <attr_index_name_cmp>) at avl.c:545 545 while ( root != 0 && (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { (gdb) bt #0 0x00007fd98e223b68 in avl_find (root=0x3d63642c6c3d756f, data=0x7fffa163d0c0, fcmp=0x7fd98e1400e0 <attr_index_name_cmp>) at avl.c:545 #1 0x00007fd98e13ef9f in at_bvfind (name=0x7fffa163d0c0) at at.c:126 #2 0x00007fd98e13d61d in slap_bv2ad (bv=0x7fd98e5b7880, ad=0x7fffa163d5a8, text=0x7fffa163d5a0) at ad.c:201 #3 0x00007fd98e10c81b in LDAPRDN_rewrite (rdn=0x7fd98e5b78c0, flags=<value optimized out>, ctx=0x0) at dn.c:285 #4 0x00007fd98e10c970 in LDAPDN_rewrite (dn=<value optimized out>, flags=0, ctx=0x0) at dn.c:406 #5 0x00007fd98e10e495 in dnNormalize (use=<value optimized out>, syntax=<value optimized out>, mr=<value optimized out>, val=0x7fd98e4bc1e8, out=0x7fd98e4bc1f8, ctx=0x0) at dn.c:446 #6 0x00007fd98e0ea70d in read_config ( fname=0x7fd98e535030 "/etc/openldap/slapd.conf", dir=0x0) at bconfig.c:4101 #7 0x00007fd98e0dbbf9 in main (argc=13, argv=0x7fffa163d8c8) at main.c:767

1 0

Re: (ITS#6532) Support for common orderingMatching rules in extensible match filters
by daniel＠pluta.biz 30 Jul '10

30 Jul '10

The patch can be downloaded from here: ftp://ftp.openldap.org/incoming/servers-slapd-schema_init.patch.2 passive ftp rules - sorry for the confusion

1 0

Re: (ITS#6610) Client receives SIGPIPE when connected via ldapi with TLS
by hyc＠symas.com 29 Jul '10

29 Jul '10

jzeleny(a)redhat.com wrote: > Full_Name: Jan Zeleny > Version: 2.4.23 > OS: Linux > URL: http://jzeleny.fedorapeople.org/debug/openldap/sigpipe-traces.tar.bz2 > Submission from: (NULL) (209.132.186.34) > > > When running slapd listening on local socket (ldapi:///), clients connecting to > it will sometimes SIGPIPE when using TLS. This happens in about 70% times. > > How to reproduce: > generate a pem certificate > slapd -h ldapi:/// > ldapsearch -H ldapi:/// -ZZ -x -d -1 > > I'm attaching straces from both slapd and ldapsearch. What seems to be happening > is that slapd receives EAGAIN during the read from socket, marks it for another > read, but then terminates a reading thread and closes the connection, while > client still wants to write some data. When doing ldapsearch, it does this after > result was returned, that's why it can be seen probably only in debugging mode. > > The issue was originally reported on 2.3.43, but I successfully reproduced it on > newer versions, including 2.4.23. The only exception was Fedora rawhide version > (currently 2.4.22), which is built with NSS instead of OpenSSL. NSS (and NSPR) > doesn't seem to support local sockets at all, so it is not possible to use ldapi > with -ZZ any more. Not sure this is worth investigating, since there's no reason to use TLS on ldapi://, and as you already said, it won't even be possible with the upcoming (rawhide) packages. > I'm attaching straces from both successful and unsuccessful run. For complete > information here is URL of relevant redhat bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=564108 In regards to the original report, just leave ssl off in the nss_ldap config. Use the starttls URL extension instead. ldap://host/????starttls -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6532) Support for common orderingMatching rules in extensible match filters
by daniel＠pluta.biz 29 Jul '10

29 Jul '10

Howard Chu schrieb: > The patch in the URL you specified appears to be empty. Although I'm pretty sure I've successfully uploaded the patch as I (think I) always check the URLs twice right after posting I just tried to upload it again some minutes ago using the filename: servers-slapd-schema_init_2.patch The ftp-server let me successfully log in but does not allow me to upload anything into /incoming: "425 Can't build data connection: Connection refused." Possibly this is also the cause the patch file currently seems to be empty after your download? I've tried the upload from different hosts and networks (IPv6 with IPv4 fallback) without success. Have not investigated in deep but I think it does not seem to be a problem of my/our firewalls. daniel@tingletangle:~$ ftp ftp.openldap.org Connected to www.openldap.org. 220- OpenLDAP FTP Service 220 boole.openldap.org FTP server (Version 6.00LS) ready. Name (ftp.openldap.org:daniel): anonymous 331 Guest login ok, send your email address as password. Password: 230- Copyright 1998-2010, The OpenLDAP Foundation, All Rights Reserved. 230- COPYING RESTRICTIONS APPLY, see: 230- ftp://ftp.openldap.org/COPYRIGHT 230- ftp://ftp.openldap.org/LICENSE 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd incoming 250 CWD command successful. ftp> ascii 200 Type set to A. ftp> put servers-slapd-schema_init_2.patch local: servers-slapd-schema_init_2.patch remote: servers-slapd-schema_init_2.patch 200 PORT command successful. 425 Can't build data connection: Connection refused. ftp> quit

1 0

(ITS#6610) Client receives SIGPIPE when connected via ldapi with TLS
by jzeleny＠redhat.com 28 Jul '10

28 Jul '10

Full_Name: Jan Zeleny Version: 2.4.23 OS: Linux URL: http://jzeleny.fedorapeople.org/debug/openldap/sigpipe-traces.tar.bz2 Submission from: (NULL) (209.132.186.34) When running slapd listening on local socket (ldapi:///), clients connecting to it will sometimes SIGPIPE when using TLS. This happens in about 70% times. How to reproduce: generate a pem certificate slapd -h ldapi:/// ldapsearch -H ldapi:/// -ZZ -x -d -1 I'm attaching straces from both slapd and ldapsearch. What seems to be happening is that slapd receives EAGAIN during the read from socket, marks it for another read, but then terminates a reading thread and closes the connection, while client still wants to write some data. When doing ldapsearch, it does this after result was returned, that's why it can be seen probably only in debugging mode. The issue was originally reported on 2.3.43, but I successfully reproduced it on newer versions, including 2.4.23. The only exception was Fedora rawhide version (currently 2.4.22), which is built with NSS instead of OpenSSL. NSS (and NSPR) doesn't seem to support local sockets at all, so it is not possible to use ldapi with -ZZ any more. I'm attaching straces from both successful and unsuccessful run. For complete information here is URL of relevant redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=564108

1 0

(ITS#6609) Admin Guide Documentation typo's
by paul＠mawsonlakes.org 28 Jul '10

28 Jul '10

Full_Name: Paul Schulz Version: CVS OS: Linux/Ubuntu URL: Submission from: (NULL) (116.212.217.6) Patch.. diff --git a/admin/access-control.sdf b/admin/access-control.sdf index f18dba3..1ff6815 100644 --- a/admin/access-control.sdf +++ b/admin/access-control.sdf @@ -826,7 +826,7 @@ This ACL grants read permissions to authenticated users while denying others H3: Controlling rootdn access -You could specify the {{rootdn}} in {{slapd.conf}}(5) or {[slapd.d}} without +You could specify the {{rootdn}} in {{slapd.conf}}(5) or {{slapd.d}} without specifying a {{rootpw}}. Then you have to add an actual directory entry with the same dn, e.g.: @@ -876,7 +876,7 @@ One can then grant access to the members of this this group by adding appropriat > by group.exact="cn=Administrators,dc=example,dc=com" write > by * auth -Like by {[dn}} clauses, one can also use {{expand}} to expand the group name +Like by {{dn}} clauses, one can also use {{expand}} to expand the group name based upon the regular expression matching of the target, that is, the to {{dn.regex}}). For instance, diff --git a/admin/appendix-common-errors.sdf b/admin/appendix-common-errors.sdf index b285cd2..be901f1 100644 --- a/admin/appendix-common-errors.sdf +++ b/admin/appendix-common-errors.sdf @@ -11,7 +11,7 @@ H2: Common causes of LDAP errors H3: ldap_*: Can't contact LDAP server -The {[B:Can't contact LDAP server}} error is usually returned when the LDAP +The {{B:Can't contact LDAP server}} error is usually returned when the LDAP server cannot be contacted. This may occur for many reasons: * the LDAP server is not running; this can be checked by running, for example,

1 0

Re: (ITS#6531) Modify updateref to generate referrals on the backend
by hyc＠symas.com 28 Jul '10

28 Jul '10

Rein Tollevik wrote: > On 04/25/2010 12:49 AM, hyc(a)symas.com wrote: > >> Also in terms of logical abstraction the current behavior is wrong; the >> frontend should of course generate the default_referral responses but >> updateref is a per-backend item and should be generated at the backend layer. >> Ideally this would all have been fixed to behave correctly by moving all >> replication support into an overlay, where it properly belongs. As an interim >> step it would be trivial to write an updateref overlay that supersedes the >> current updateref behavior. > > Updateref processing should imo be kept out of any replication modules, > it is needed in databases where syncrepl isn't configured too. I'm > using it on my subordinate databases (with an artificial updatedn so > that slapd accepts it..) when syncrepl is configured on the superior > glue database without managing all of the subordinate databases. I.e, > the infamous test058... > > I was having the same "chain only on some of the databases" requirement > and is using a patch that allows it. I consider this patch more of a > hack than a correct solution, which is why I haven't contributed it. A > separate updateref overlay apear to me as the best solution. But for > what it's worth, my patch is now in: > > ftp://ftp.openldap.org/incoming/rein-ITS6531.patch > > An advantage with this patch over a new overlay is that it should be > usable without any configuration changes (provided the chain overlay > have already been configured in the databases and found to not work as > expected there that is ... ;-). I didn't quite follow the intended usage for this patch. Are other overlays expected to override the default over_mod_ref() handler? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs