openldap-bugs November 2008

openldap-bugs@openldap.org

44 participants
242 discussions

(ITS#5807) build broken for solaris 9
by brett.maxfield＠gmail.com 13 Nov '08

13 Nov '08

Full_Name: Brett Maxfield Version: 2.4.RELENG OS: Solaris 9 (SunOS 2.9) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.18.108.167) Hello, Trying to make tests for RE24 and 2.4.12 on solaris (SunOS 2.9) and getting a failure : (build options - berkeleyDB previously installed with --prefix=/usr/local/openldap24) export PATH=/usr/local/bin:/usr/ccs/bin:/usr/bin:/bin:/usr/sbin:/sbin export LD_LIBRARY_PATH=/usr/local/openldap24/lib:/usr/local/ssl/lib:/usr/local/lib CPPFLAGS="-I/usr/local/openldap24/include -I/usr/local/include" LDFLAGS="-L/usr/local/openldap24/lib -L/usr/local/lib -R/usr/local/openldap24/lib -R/usr/local/lib" ./configure --enable-shared --enable-ssl --disable-ipv6 --with-threads --enable-slapd --enable-backends --enable-overlays --disable-sql --disable-ndb --disable-slapi (result of make test, fails on the first test) # cat tests/testrun/slapd.1.log @(#) $OpenLDAP: slapd 2.4.12 (Nov 13 2008 17:57:10) $ testuser@myhost:/export/home/testuser/openldap24-build/openldap-2.4.12/servers/slapd ldap_pvt_gethostbyname_a: host=myhost, r=0 daemon_init: ldap://localhost:9011/ daemon_init: listen on ldap://localhost:9011/ daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://localhost:9011/) daemon: getaddrinfo() failed: invalid ai_flags slapd stopped. connections_destroy: nothing to destroy. ai_flags has to do with the options to listen/accept, and should be something like NULL, it seemss sol9 does not like the AI_PASSIVE value. I manually changed it to šhints.ai_flags = NULL; // AI_PASSIVE;" (servers/slapd/daemon.c line 1131) and the code compiles, and make test succeeds. For solaris 9, hints.ai_flags should just use NULL. Cheers Brett

1 0

(ITS#5806) slapo-syncprov man page and syncprov-sessionlog
by ghenry＠OpenLDAP.org 12 Nov '08

12 Nov '08

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry It is not clear that the "sessionlog" is actually stored in memory and not a phyiscal file: syncprov-sessionlog <ops> Specify a session log for recording information about write operations made on the database. The <ops> specifies the number of operations that are recorded in the log. All write operations (except Adds) are recorded in the log. When using the session log, it is helpful to set an eq index on the entryUUID attribute in the underlying database. It should be changed to read something like: "Configures an in-memory session log for recording information about write operations made on the database."

1 0

Re: (ITS#5788) Search does not work with nested naming contexts
by ghenry＠OpenLDAP.org 12 Nov '08

12 Nov '08

emmanuel.duru(a)atosorigin.com wrote: > OK, thank you. > I didn't see this configuration directive in the admin guide... All the details are always in the man pages. Cheers. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 12 Nov '08

12 Nov '08

Full_Name: Emmanuel Duru Version: 2.4.11 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.78.0.137) I have a single BDB database directory with root DN as a physical entry. My access control is defined as follows in olcDatabase={-1}frontend: olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no ne olcAccess: {1}to dn=cn=manager,c=fr by self write by * none olcAccess: {2}to * by self write by users read by anonymous read by * none I perform a modify operation as follows: dn: olcDatabase={-1}frontend,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no ne olcAccess: {1}to dn=cn=manager,c=fr by self write by * none olcAccess: {2}to * by self write by users read by anonymous read by * none dn: olcDatabase={0}config,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by * none - replace: olcRootDN olcRootDN: cn=manager,c=fr then I can not bind any more to the directory (invalid credentials). The log says (do notice the line dn: [1]... with non printable characters): do_bind: version=3 dn="cn=manager,c=fr" method=128 ==> bdb_bind: dn: cn=manager,c=fr bdb_dn2entry("cn=manager,c=fr") => access_allowed: auth access to "cn=manager,c=fr" "userPassword" requested => dn: [1] <some non printable characters>anager,c=fr => acl_get: [2] attr userPassword => slap_access_allowed: result not in cache (userPassword) => acl_mask: access to entry "cn=manager,c=fr", attr "userPassword" requested => acl_mask: to value by "", (=0) <= check a_dn_pat: * <= acl_mask: [1] applying none(=0) (stop) <= acl_mask: [1] mask: none(=0) => slap_access_allowed: auth access denied by none(=0) => access_allowed: no more rules When I stop the directory, the log says (filter_free lines may vary): bdb_db_close: database "c=fr": alock_close failed filter_free: unknown filter type=20224 filter_free: unknown filter type=496 slapd stopped. filter_free: unknown filter type=29776 filter_free: unknown filter type=13944 filter_free: unknown filter type=29496 When I restart slapd, all is fine: the access control is OK and I can bind.

1 0

(ITS#5804) attribute value regex expantion
by manu＠netbsd.org 11 Nov '08

11 Nov '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD URL: ftp://ftp.openldap.org/incoming/manu-20081111.patch Submission from: (NULL) (213.41.141.172) The attached patch allow substitution from attribut value regex. For instance: access to attrs=foo val.regex="^(.*)$" by dn.exact,expand="uid=${v1},o=home" write by * read stop ${v1} ${v2} ${v3} ... get the substitutions from attribute value regex ${d1} ${d2} ${d3} ... are aliases for $1 $2 $3 ... and get substitution from DN regex

1 0

ITS 5709
by Burton, Kris - Acision 11 Nov '08

11 Nov '08

All, I apologize if this is sent twice, I noticed I copied the wrong address in the first email sent by accident to openldap-its(a)openldap.org<mailto:openldap-its@openldap.org>. I am currently experiencing the problem that is detailed in ITS 5709. I am running OpenLDAP 2.4.11, from the information in ITS5709 it appears that this problem is resolved in HEAD. What I would like to do is to isolate the code that resolves this problem and put them in the 2.4.11 version of OpenLDAP that I am running. I have been trying to determine exactly what changes were added to resolve the issue. I also wanted to ask if doing this would be a viable solution until the time that another OpenLDAP version is released that resolves this issue. I am not familiar with the code base and would not want to introduce one change to try to resolve this issue and open up several new issues. Can someone familiar with the fix point me in the right direction as to whether the fix that resolves this is isolated and would be safe to back port to an older release (2.4.11), and if so how would I identify exactly what needs to be changed? Also if someone could inform me if the above ITS would be included in part of 2.4.13 and is there any projected date for when 2.4.13 would be released. Kris Burton Software Engineer ________________________________________ Acision. Innovation. Assured. www.acision.com 4870 Sadler Road Suite 200 Glen Allen, VA 23060 USA This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Re: (ITS#5796) back-sql intermittently failing
by robb＠wtg.cw.com 11 Nov '08

11 Nov '08

Pierangelo Masarati wrote: > OK, this makes sense. In fact, back-sql does not seem to specifically > handle broken connections to the odbc. It appears it would need > something similar to idle-timeout as in back-ldap and back-meta. ok, this looks like it... Nov 11 17:01:38 nops slapd[24733]: backsql_dn2id("dc=sql,dc=example,dc=com") : error executing query ("SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn=?", "dc=sql,dc=example,dc=com"): Nov 11 17:01:38 nops slapd[24733]: Return code: -1 Nov 11 17:01:38 nops slapd[24733]: nativeErrCode=2006 SQLengineState=08S01 msg="[unixODBC][MySQL][ODBC 3.51 Driver][mysqld-5.0.67-log]MySQL server has gone away" Nov 11 17:01:38 nops slapd[24733]: <==backsql_dn2id("dc=sql,dc=example,dc=com") : err=80 if you'd like a tarball of full logs + config just say. Regards, Rob

1 0

(ITS#5803) Incorrect filters (e.g. substrings) may trigger "disconnect"
by ando＠sys-net.it 11 Nov '08

11 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando When a malformed filter is encountered, ber decoding may stop before the specific element has been parsed. This results in a decoding error later, that triggers a "disconnect" response. To reproduce: search with "(objectClass=foo*bar)". The correct behavior would consist in parsing the whole filter anyway and identify it as COMPUTED UNDEFINED. p.

1 0

Re: (ITS#5796) back-sql intermittently failing
by ando＠sys-net.it 11 Nov '08

11 Nov '08

Robert Brooks wrote: > Pierangelo Masarati wrote: >> I have no possibility to setup a back-sql with mysql right now. Can >> you post your configuration? Can you post some (verbose) logs of >> operations affecting back-sql (e.g. with BACKSQL_TRACE manually >> #defined in back-sql/back-sql.h)? Can you step thru a search into >> backsql_search() and see if it gets called and why it doesn't get to >> contacting the rdbms? > > I'm compiling with BACKSQL_TRACE defined right now. > > After further prodding I have discovered... > > ejabberd (a jabber daemon) makes connections to ldap, which it keeps > open indefinitely. It appears mysql's odbc connector will time out an > idle mysql connection after 8 hours. Since this is the slave system it's > entirely possible for it not touch mysql connections for at least 8 hours. > > If we restart mysql some ldap queries fail on back-sql portion until we > kill ejabberd (to close it's ldap connections). > > I'll give you logs with tracing enabled asap, but this looks like a big > clue as to what is happening. OK, this makes sense. In fact, back-sql does not seem to specifically handle broken connections to the odbc. It appears it would need something similar to idle-timeout as in back-ldap and back-meta. 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 -----------------------------------

1 0

Re: (ITS#5796) back-sql intermittently failing
by robb＠wtg.cw.com 11 Nov '08

11 Nov '08

Pierangelo Masarati wrote: > I have no possibility to setup a back-sql with mysql right now. Can you > post your configuration? Can you post some (verbose) logs of operations > affecting back-sql (e.g. with BACKSQL_TRACE manually #defined in > back-sql/back-sql.h)? Can you step thru a search into backsql_search() > and see if it gets called and why it doesn't get to contacting the rdbms? I'm compiling with BACKSQL_TRACE defined right now. After further prodding I have discovered... ejabberd (a jabber daemon) makes connections to ldap, which it keeps open indefinitely. It appears mysql's odbc connector will time out an idle mysql connection after 8 hours. Since this is the slave system it's entirely possible for it not touch mysql connections for at least 8 hours. If we restart mysql some ldap queries fail on back-sql portion until we kill ejabberd (to close it's ldap connections). I'll give you logs with tracing enabled asap, but this looks like a big clue as to what is happening.

1 0

← Newer
1
...
14
15
16
17
18
19
20
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2008