- openldap-bugs - openldap.org

(ITS#6242) PCache cache corruption
by karavelov＠spnet.net 05 Aug '09

05 Aug '09

Full_Name: Luben Karavelov Version: 2.4.11-CVS-HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.34.104.18) Environment: We are trying to deploy openldap in a e-main and web hosting system for centralized management of authentication and configuration. The architecture is one DB server with all the information exposed to slapd server through views and two or three slapd servers for fail-over and load balancing. Each slapd is configured to cache positive and negative responses in bdb backend in order to speed up the LDAP queries (pcache overlay). The Problem: Sometimes there appears a cache corruption : after some correct responses the server starts to reply like there is no such record. The corrupted record does not expire. Tested versions: openldap 2.4.11 (Debian lenny), 2.4.15 (Debian sid), 2.4.17 (compiled from sources), CVS-HEAD bdb-4.2, bdb-4.6. bdb-4.7 unixodbc-2.2.14 Current configuration and details follow in next posts.

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 04 Aug '09

04 Aug '09

> I am using 2.4.16. The problem is, that caching seems to work for some > entries but not for others. It is not related to the order of the filter > rules. Here is what happens: (lines starting with *** are my comments) > > > > **** slapd is started showing version, query templates and attributes > > bash-2.05# ./slapd -d 4096 > @(#) $OpenLDAP: slapd 2.4.16 (Jun 30 2009 16:56:26) $ > > jim@flits:/net/build.sparc/management/openldap/openldap-2.4.16/servers/slapd > /opt/openldap/openldap-2.4.16/etc/openldap/slapd.conf: line 78: rootdn > is always granted unlimited privileges. > /opt/openldap/openldap-2.4.16/etc/openldap/slapd.conf: line 85: rootdn > is always granted unlimited privileges. This tells us you have some ACLs in place. Could you show them? Actually, could you post your whole slapd.conf, if you're using any, or the contents of your cn=config database? Of course, after removing any sensitive information, like passwords. p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by w.van.keulen＠few.vu.nl 04 Aug '09

04 Aug '09

masarati(a)aero.polimi.it wrote: >> hyc(a)symas.com wrote: >> > The filter behavior you're describing was noted in ITS#5756, fixed in >> January. >> >> If it was fixed in January, why does openldap-2.4.16 (20090411) still >> exhibit the described behaviour? > > Did you actually try to swap the order of the filters, and did it work? > Since Howard fixed ITS#5756, you might be experiencing something > different. > > Also, can you check whether you're actually using 2.4.16? According to > the changelog, the fix to ITS#5756 was released with 2.4.14. > > p. > I am using 2.4.16. The problem is, that caching seems to work for some entries but not for others. It is not related to the order of the filter rules. Here is what happens: (lines starting with *** are my comments) **** slapd is started showing version, query templates and attributes bash-2.05# ./slapd -d 4096 @(#) $OpenLDAP: slapd 2.4.16 (Jun 30 2009 16:56:26) $ jim@flits:/net/build.sparc/management/openldap/openldap-2.4.16/servers/slapd /opt/openldap/openldap-2.4.16/etc/openldap/slapd.conf: line 78: rootdn is always granted unlimited privileges. /opt/openldap/openldap-2.4.16/etc/openldap/slapd.conf: line 85: rootdn is always granted unlimited privileges. Total # of attribute sets to be cached = 10. Template: query template: (&(objectClass=)(uid=)) attributes: uid cn Template: query template: (&(uid=)(objectClass=)) attributes: uid cn slapd starting *** Now I enter a search in another window bash-2.05$ /usr/local/bin/ldapsearch -x -h localhost '(&(objectClass=sambaSamAccount)(uid=wvk))' uid cn # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectClass=sambaSamAccount)(uid=wvk)) # requesting: uid cn # # wvk, People, few.vu.nl dn: uid=wvk,ou=People,dc=few,dc=vu,dc=nl uid: wvk cn: wvk *** requested attributes are returned as expected # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 *** Output of slapd for this search ***** query template of incoming query = (&(objectClass=)(uid=)) Entering QC, querystr = (&(objectClass=sambaSamAccount)(uid=wvk)) Lock QC index = 31e698 Not answerable: Unlock QC index=31e698 QUERY NOT ANSWERABLE QUERY CACHEABLE Added query expires at 1249416628 (POSITIVE) Lock AQ index = 31e698 TEMPLATE 31e698 QUERIES++ 1 Unlock AQ index = 31e698 Base of added query = dc=few,dc=vu,dc=nl UUID for query being added = 68ab725c-157a-102e-87a7-cd469e2cf913 ENTRY ADDED/MERGED, CACHED ENTRIES=0 STORED QUERIES = 1 *** same search is repeated bash-2.05$ /usr/local/bin/ldapsearch -x -h localhost '(&(objectClass=sambaSamAccount)(uid=wvk))' uid cn # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectClass=sambaSamAccount)(uid=wvk)) # requesting: uid cn # *** Note that nothing is returned # search result search: 2 result: 0 Success # numResponses: 1 *** Output of slapd for the second search **** query template of incoming query = (&(objectClass=)(uid=)) Entering QC, querystr = (&(objectClass=sambaSamAccount)(uid=wvk)) Lock QC index = 31e698 QUERY ANSWERABLE *** For another uid it works perfectly. /usr/local/bin/ldapsearch -x -h localhost '(&(objectClass=sambaSamAccount)(uid=jim))' uid cn # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectClass=sambaSamAccount)(uid=jim)) # requesting: uid cn # # jim, People, few.vu.nl dn: uid=jim,ou=People,dc=few,dc=vu,dc=nl uid: jim cn: W. van Keulen # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 bash-2.05$ /usr/local/bin/ldapsearch -x -h localhost '(&(objectClass=sambaSamAccount)(uid=jim))' uid cn # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectClass=sambaSamAccount)(uid=jim)) # requesting: uid cn # # jim, People, few.vu.nl dn: uid=jim,ou=People,dc=few,dc=vu,dc=nl uid: jim cn: W. van Keulen # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 bash-2.05 *** Output of slapd for second case $bash-2.05# ./slapd -d 4096 @(#) $OpenLDAP: slapd 2.4.16 (Jun 30 2009 16:56:26) $ jim@flits:/net/build.sparc/management/openldap/openldap-2.4.16/servers/slapd /opt/openldap/openldap-2.4.16/etc/openldap/slapd.conf: line 78: rootdn is always granted unlimited privileges. /opt/openldap/openldap-2.4.16/etc/openldap/slapd.conf: line 85: rootdn is always granted unlimited privileges. Total # of attribute sets to be cached = 10. Template: query template: (&(objectClass=)(uid=)) attributes: uid cn Template: query template: (&(uid=)(objectClass=)) attributes: uid cn slapd starting query template of incoming query = (&(objectClass=)(uid=)) Entering QC, querystr = (&(objectClass=sambaSamAccount)(uid=jim)) Lock QC index = 31e698 Not answerable: Unlock QC index=31e698 QUERY NOT ANSWERABLE QUERY CACHEABLE Added query expires at 1249417816 (POSITIVE) Lock AQ index = 31e698 TEMPLATE 31e698 QUERIES++ 1 Unlock AQ index = 31e698 Base of added query = dc=few,dc=vu,dc=nl UUID for query being added = 2c8d245c-157d-102e-87c5-e7c795cd8bf5 ENTRY ADDED/MERGED, CACHED ENTRIES=0 STORED QUERIES = 1 query template of incoming query = (&(objectClass=)(uid=)) Entering QC, querystr = (&(objectClass=sambaSamAccount)(uid=jim)) Lock QC index = 31e698 QUERY ANSWERABLE There is no difference if I reverse the filter. It works for some uid's, but not for others. Regards, Jim

1 0

Re: state of pcache overlay enhancement - ITS#6152
by hyc＠symas.com 04 Aug '09

04 Aug '09

mathiaz(a)ubuntu.com wrote: > Hi, > > What is the current state of ITS 6152 (pcache enhancements) that were > discussed during the last Ubuntu Developer Summit? An "offline" configure switch has been added to disable the cache expiration. We assume a hook script can be used in NetworkManager to toggle this switch. The other details are not implemented yet but will be soon. -- -- 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

state of pcache overlay enhancement - ITS#6152
by mathiaz＠ubuntu.com 04 Aug '09

04 Aug '09

Hi, What is the current state of ITS 6152 (pcache enhancements) that were discussed during the last Ubuntu Developer Summit? -- Mathias Gug Ubuntu Developer http://www.ubuntu.com

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 04 Aug '09

04 Aug '09

> hyc(a)symas.com wrote: > > The filter behavior you're describing was noted in ITS#5756, fixed in > January. > > If it was fixed in January, why does openldap-2.4.16 (20090411) still > exhibit the described behaviour? Did you actually try to swap the order of the filters, and did it work? Since Howard fixed ITS#5756, you might be experiencing something different. Also, can you check whether you're actually using 2.4.16? According to the changelog, the fix to ITS#5756 was released with 2.4.14. p.

1 0

(ITS#6241) certificate list parsing issues
by masarati＠aero.polimi.it 04 Aug '09

04 Aug '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.250) Submitted by: ando See <http://www.openldap.org/lists/openldap-devel/200908/msg00003.html> for details. A solution that logs issuer, thisUpdate is being implemented.

1 0

Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by masarati＠aero.polimi.it 04 Aug '09

04 Aug '09

Your message was unreadable, you should use text form for messages sent to the ITS. In any case, according to many sources, the default values for TCP buffers can be pretty small. Usually, they can be configured system-wide at the OS level (see tcp(7)), or even auto-tuned. Personally, I have no objections in optionally allowing to hard-set the buffer sizes to values one considers appropriate for the intended use of slapd. Since the optimal size roughly depends on latency and bandwidth, this may probably need to be configured on a per-listener basis, actually. However, in deployments where this problem becomes critical, usually hardware dedicated to slapd is used, so system-wide tuning (and auto-tuning) would be the preferred option anyway. Manual setting should be used only when system-wide or auto-tuning is not available or accessible for some reason. p.

1 0

Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by evaristojosec＠yahoo.es 04 Aug '09

04 Aug '09

Hi,=0A=0AProbably "heavy LDAP" load was a very generic simplified definitio= n.=0AThe traffic model we are testing contains search and modify operations= . The=0Asearch response contains usually a single entry about 3KB in LDIF f= ormat. There=0Ais only a reduce number of LDAP clients (usually one or two)= , that are using=0Aasync LDAP API and sending a lot of operations per secon= d (> 1000 TPS per=0Aclient).=0A=0AUnder these conditions we have tested tha= t increasing the sending buffer of the=0Aserver has improved the performanc= e. That's the reason I am proposing this=0Afeature request.=0A=0ARegards,= =0A=0AEvaristo=0A=0A----- Mensaje original ----=0ADe: Howard Chu <hyc@symas= .com>=0APara: evaristojosec(a)yahoo.es=0ACC: openldap-its(a)openldap.org=0AEnvi= ado: martes, 4 de agosto, 2009 0:43:36=0AAsunto: Re: (ITS#6234) CONFIGURABL= E TCP BUFFERS IN SLAPD FEATURE REQUEST=0A=0Aevaristojosec(a)yahoo.es wrote:= =0A> Full_Name: Evaristo Camarero=0A> Version: 2.4.x=0A> OS: Linux=0A> URL:= ftp://ftp.openldap.org/incoming/=0A> Submission from: (NULL) (194.237.142.= 20)=0A> =0A> =0A> =0A> Hi,=0A> =0A> Working with slapd under heavy load it = could be interesting to have TCP buffers=0A> size configurable at slapd app= lication level instead of getting default OS=0A> values.=0A=0AI don't see t= his having any positive impact on slapd performance. "Heavy LDAP load" gene= rally implies lots of small queries with sets of small result objects; very= rarely do queries return large objects. When a system is under such heavy = load, requesting larger buffers per socket will make the system load worse,= as the kernel will have more memory consumed in these socket buffers and l= ess available for other demands.=0A=0AWhat workload have you tested this wi= th, and what performance impact did you measure as a result?=0A=0A> Some fa= st modifications in daemon.c file to achieve a hardcoded value for the=0A> = sender buffer are:=0A> =0A> int buf_size =3D 1572864; /* 1.5 Mb */= =0A> rc =3Dsetsockopt ( s, SOL_SOCKET, SO_SNDBUF, (int*)&buf_size,= =0A> sizeof(buf_size));=0A> if(rc=3D=3D-1) {=0A> Debug(= LDAP_DEBUG_ANY, "slapd(%ld): "=0A> "setsockopt(SO_SNDBUF) = failed errno=3D%d (%s)\n",=0A> (long) l.sl_sd, err, sock_er= rstr(err) );=0A> } else {=0A> Debug( LDAP_DEBUG_ANY, "s= lapd(%ld): setsockopt(SO_SNDBUF) to %d\n",=0A> (long) l.sl_= sd, buf_size, 0);=0A> }=0A=0A-- -- Howard Chu=0A CTO, Symas Corp= . http://www.symas.com=0A Director, Highland Sun http://highla= ndsun.com/hyc/=0A Chief Architect, OpenLDAP http://www.openldap.org/proje= ct/=0A=0A=0A=0A

1 0

Re: (ITS#6240) cn=config replication failing on repeat olcDbConfig
by hyc＠symas.com 04 Aug '09

04 Aug '09

matt.edlefsen(a)gmail.com wrote: > Full_Name: Matt Edlefsen > Version: 2.4.16 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (98.213.15.129) > > > When trying to setup multi-master replication of a cn=config database I > encountered the following error: > Aug 3 20:21:38 gabbro slapd[81578]: syncrepl_message_to_entry: > rid=001 mods check (olcDbConfig: value #14 provided more than once) Thanks for the report, this is fixed in HEAD. -- -- 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

(ITS#6240) cn=config replication failing on repeat olcDbConfig
by matt.edlefsen＠gmail.com 04 Aug '09

04 Aug '09

Full_Name: Matt Edlefsen Version: 2.4.16 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (98.213.15.129) When trying to setup multi-master replication of a cn=config database I encountered the following error: Aug 3 20:21:38 gabbro slapd[81578]: syncrepl_message_to_entry: rid=001 mods check (olcDbConfig: value #14 provided more than once) Process: The cn=config used was copied to both servers (using ldapsearch -LLL | slapadd -n 0) from a third server, which in turn was originally converted from a basic slapd.conf using slapd -f -F. To turn on replication I added the following entries/attributes to the cn=config tree of both servers following the steps outlined in the Users Guide (only the relevant attributes are listed): dn: cn=config olcServerID: 1 ldap://rock.earlham.edu/ olcServerID: 2 ldap://gabbro.earlham.edu/ dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=001 provider=dap://rock.earlham.edu/ binddn="<snip>" bindmethod=simple credentials=<snip> searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncrepl: {1}rid=002 provider=ldap://gabbro.earlham.edu/ binddn="<snip>" bindmethod=simple credentials=<snip> searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov When I added the above to the second server it started replicating against the first and when it reached the olcDbConfig attributes of the bdb database config it failed with the error message given above. The olcDbConfig attributes are: olcDbConfig: {0}# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/12/18 11:53:27 ghenry Exp $ olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databases. olcDbConfig: {2}# olcDbConfig: {3}# See the Oracle Berkeley DB documentation olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_co…> olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics. olcDbConfig: {6}# olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ olcDbConfig: {8}# <http://www.openldap.org/faq/index.cgi?file=2> olcDbConfig: {9}# in particular: olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075> olcDbConfig: {11} olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon rebuilding olcDbConfig: {13}# the DB environment. olcDbConfig: {14} olcDbConfig: {15}# one 1 GB cache olcDbConfig: {16}set_cachesize 0 1073741824 1 olcDbConfig: {17} olcDbConfig: {18}# Data Directory olcDbConfig: {19}#set_data_dir db olcDbConfig: {20} olcDbConfig: {21}# Transaction Log settings olcDbConfig: {22}set_lg_regionmax 262144 olcDbConfig: {23}set_lg_bsize 104857600 olcDbConfig: {24}set_lk_max_locks 100000 olcDbConfig: {25}#set_lg_dir logs olcDbConfig: {26} olcDbConfig: {27}# Note: special DB_CONFIG flags are no longer needed for "quick" olcDbConfig: {28}# slapadd(8) or slapindex(8) access (see their -q option). Fix: Removing all the duplicate entries (not counting the {#} prefixes) fixed the problem.

1 0

(ITS#6163)
by karavelov＠spnet.net 04 Aug '09

04 Aug '09

I have tested with 2.4.17 with servers/slapd/back-sql/search.c from CVS HEAD and the issue is resolved. Thanks Luben Karavelov

1 0

Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by hyc＠symas.com 04 Aug '09

04 Aug '09

evaristojosec(a)yahoo.es wrote: > Full_Name: Evaristo Camarero > Version: 2.4.x > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.20) > > > > Hi, > > Working with slapd under heavy load it could be interesting to have TCP buffers > size configurable at slapd application level instead of getting default OS > values. I don't see this having any positive impact on slapd performance. "Heavy LDAP load" generally implies lots of small queries with sets of small result objects; very rarely do queries return large objects. When a system is under such heavy load, requesting larger buffers per socket will make the system load worse, as the kernel will have more memory consumed in these socket buffers and less available for other demands. What workload have you tested this with, and what performance impact did you measure as a result? > Some fast modifications in daemon.c file to achieve a hardcoded value for the > sender buffer are: > > int buf_size = 1572864; /* 1.5 Mb */ > rc =setsockopt ( s, SOL_SOCKET, SO_SNDBUF, (int*)&buf_size, > sizeof(buf_size)); > if(rc==-1) { > Debug( LDAP_DEBUG_ANY, "slapd(%ld): " > "setsockopt(SO_SNDBUF) failed errno=%d (%s)\n", > (long) l.sl_sd, err, sock_errstr(err) ); > } else { > Debug( LDAP_DEBUG_ANY, "slapd(%ld): setsockopt(SO_SNDBUF) to %d\n", > (long) l.sl_sd, buf_size, 0); > } -- -- 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#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 04 Aug '09

04 Aug '09

>> But he said that reversing the order of the filters (i.e. no >> objectClass=someclass first) cures the problem. > > Sorry, if he told you that it must have been in a private email. There is > no > such statement recorded in the ITS. He said it would be simple to reverse > the > filters, but that it would not accomplish anything since he wants to cache > searches from Samba. He didn't say that he actually tried reversing the > filters or that it worked. At any rate, the issue in 5756 was confirmed > fixed > so again, I do not believe it's responsible for the current situation. No private message. I probably misunderstood the message in followup 2. My understanding of that message is that he tried swapping the simple filters, but I admit the sentence sound ambiguous to me. p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by hyc＠symas.com 04 Aug '09

04 Aug '09

masarati(a)aero.polimi.it wrote: >> Jim van Keulen wrote: >>> hyc(a)symas.com wrote: >>> > The filter behavior you're describing was noted in ITS#5756, fixed >>> in >>> January. >>> >>> If it was fixed in January, why does openldap-2.4.16 (20090411) still >>> exhibit the described behaviour? >> >> I don't believe what you're seeing now is due to the situation Ando >> described. > > But he said that reversing the order of the filters (i.e. no > objectClass=someclass first) cures the problem. Sorry, if he told you that it must have been in a private email. There is no such statement recorded in the ITS. He said it would be simple to reverse the filters, but that it would not accomplish anything since he wants to cache searches from Samba. He didn't say that he actually tried reversing the filters or that it worked. At any rate, the issue in 5756 was confirmed fixed so again, I do not believe it's responsible for the current situation. -- -- 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#6227) autogroup overlay breaks all searches
by hyc＠symas.com 03 Aug '09

03 Aug '09

mbuschman(a)cashnetusa.com wrote: > Confirmed working. > Also experienced (possibly unrelated?) segfault on slapadd. We can't tell if it's related or not unless you post the stack trace from the segfault. > > hyc(a)symas.com wrote: >> Fixed now in CVS HEAD. >> >> mbuschman(a)cashnetusa.com wrote: >> >>> Full_Name: Marshall Buschman >>> Version: 2.4.17 >>> OS: Debian Etch >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (38.98.177.132) >>> >>> >> >> >>> I'm using OpenLDAP 2.4.17 with bdb 4.7 Debian Lenny. I've enabled the >>> autogroup overlay, and I get the following error when I do an ldapsearch: >>> >>> $ ldapsearch -x -H "ldap://ldapserver" -b dc=cashnetusa,dc=com >>> # extended LDIF >>> ... >>> # search result >>> search: 2 >>> result: 53 Server is unwilling to perform >>> text: operation not supported within namingContext >>> >>> Relevant config: >>> ---------------------------------------------- >>> moduleload autogroup >>> >>> database bdb >>> suffix "dc=cashnetusa,dc=com" >>> >>> overlay autogroup >>> autogroup-attrset groupOfURLs memberURL member >>> ---------------------------------------------- >>> >>> OpenLDAP does start normally without the overlay. >>> >>> >> >> >> > > > -- -- 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#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

> Jim van Keulen wrote: >> hyc(a)symas.com wrote: >> > The filter behavior you're describing was noted in ITS#5756, fixed >> in >> January. >> >> If it was fixed in January, why does openldap-2.4.16 (20090411) still >> exhibit the described behaviour? > > I don't believe what you're seeing now is due to the situation Ando > described. But he said that reversing the order of the filters (i.e. no objectClass=someclass first) cures the problem. p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by hyc＠symas.com 03 Aug '09

03 Aug '09

Jim van Keulen wrote: > hyc(a)symas.com wrote: > > The filter behavior you're describing was noted in ITS#5756, fixed in > January. > > If it was fixed in January, why does openldap-2.4.16 (20090411) still > exhibit the described behaviour? I don't believe what you're seeing now is due to the situation Ando described. -- -- 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#6227) autogroup overlay breaks all searches
by mbuschman＠cashnetusa.com 03 Aug '09

03 Aug '09

Confirmed working. Also experienced (possibly unrelated?) segfault on slapadd. hyc(a)symas.com wrote: > Fixed now in CVS HEAD. > > mbuschman(a)cashnetusa.com wrote: > >> Full_Name: Marshall Buschman >> Version: 2.4.17 >> OS: Debian Etch >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (38.98.177.132) >> >> > > >> I'm using OpenLDAP 2.4.17 with bdb 4.7 Debian Lenny. I've enabled the >> autogroup overlay, and I get the following error when I do an ldapsearch: >> >> $ ldapsearch -x -H "ldap://ldapserver" -b dc=cashnetusa,dc=com >> # extended LDIF >> ... >> # search result >> search: 2 >> result: 53 Server is unwilling to perform >> text: operation not supported within namingContext >> >> Relevant config: >> ---------------------------------------------- >> moduleload autogroup >> >> database bdb >> suffix "dc=cashnetusa,dc=com" >> >> overlay autogroup >> autogroup-attrset groupOfURLs memberURL member >> ---------------------------------------------- >> >> OpenLDAP does start normally without the overlay. >> >> > > >

1 0

Re: (ITS#6217) proxycache not returning cached data
by w.van.keulen＠few.vu.nl 03 Aug '09

03 Aug '09

hyc(a)symas.com wrote: > The filter behavior you're describing was noted in ITS#5756, fixed in January. If it was fixed in January, why does openldap-2.4.16 (20090411) still exhibit the described behaviour? regards, Jim van Keulen

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

> masarati(a)aero.polimi.it wrote: >> As far as I recall, this is a known issue, although I could not locate >> early postings discussing this issue. What happens is that proxy cache >> makes use of the first item in the filter to discriminate between >> responses. In your filter template, the first item is the objectClass >> equality, which means that any filter with that objectClass value, >> regardless of the uid value, is treated as a duplicate of the first one. >> If you reverse the order of the equality filters you'll get the expected >> behavior. There should be another open ITS for this issue, but I can't >> locate it right now. > > The filter behavior you're describing was noted in ITS#5756, fixed in > January. That's exactly the ITS I was looking for. Apparently I didn't use the right keywords, or just overlooked it. p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by hyc＠symas.com 03 Aug '09

03 Aug '09

masarati(a)aero.polimi.it wrote: > As far as I recall, this is a known issue, although I could not locate > early postings discussing this issue. What happens is that proxy cache > makes use of the first item in the filter to discriminate between > responses. In your filter template, the first item is the objectClass > equality, which means that any filter with that objectClass value, > regardless of the uid value, is treated as a duplicate of the first one. > If you reverse the order of the equality filters you'll get the expected > behavior. There should be another open ITS for this issue, but I can't > locate it right now. The filter behavior you're describing was noted in ITS#5756, fixed in January. -- -- 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

(ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

[Resending because I forgot the ITS number in the subject] I have a simple prototype that on add/modrdn populates/maintains an attribute (rdnValue) with the distinguished values of the naming attributes of the RDN. While doing this, it also checks for uniqueness of the rdnValue value within siblings. You can find it here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.c> Please test and comment. I hope it does what intended. p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

Please keep replies to the list, so the issue can be tracked. > Thank you for your help. Reversal of the filters is easily done. > However the searches I try to cache are taken from Samba. I have no > control over the way searches are done in Samba. I understand from the > documentation that the search template must be exact the same as the > search filter to be cachable. So this solution does not solve my > problem, I guess. Clear. I understand this issue needs to be fixed somehow. The reason for just using the first simple filter in composite filters is probably related to the fact it did not require extensive data manipulation, as probably would the definition of a criterion that accounts for the whole filter. The ITS remains open as a software bug. p.

1 0

Re: (ITS#6181) slapo-unique: slaptest fails in case unique_uri is prepended the keywords "strict" or "ignore"
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

The ITS remains open, as the man page clearly needs to be improved to avoid any misunderstanding. An example would probably suffice. p. > masarati(a)aero.polimi.it wrote: >> The "strict" and the "ignore" keywords must be part of a single >> argument. >> In fact, the unique_uri statement only takes one argument, consisting of >> the optional "strict" and "ignore" keywords followed by a list of URIs. >> In order to be recognized as a single argument, the whole thing needs to >> be included in double quotes, like >> >> unique_uri "strict >> ldap:///dc=example,dc=com?uid?sub?(objectClass=account)" >> >> p. > ahh I understand - this in mind the manpage makes sense, too. ;-) > > unique_uri <[strict ][ignore ]URI[URI...]...> > > Thanks a lot for the clarification! > > > >

1 0

Re: (ITS#6181) slapo-unique: slaptest fails in case unique_uri is prepended the keywords "strict" or "ignore"
by daniel＠pluta.biz 03 Aug '09

03 Aug '09

masarati(a)aero.polimi.it wrote: > The "strict" and the "ignore" keywords must be part of a single argument. > In fact, the unique_uri statement only takes one argument, consisting of > the optional "strict" and "ignore" keywords followed by a list of URIs. > In order to be recognized as a single argument, the whole thing needs to > be included in double quotes, like > > unique_uri "strict ldap:///dc=example,dc=com?uid?sub?(objectClass=account)" > > p. ahh I understand - this in mind the manpage makes sense, too. ;-) unique_uri <[strict ][ignore ]URI[URI...]...> Thanks a lot for the clarification!

1 0

Re: (ITS#6172) Crash with baseObject in back-sql
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

> openssl(a)mkarcher.dialup.fu-berlin.de wrote: > >> slapd gets terminated by libc with an "invalid free" error message when >> using >> the baseObject configuration option (whether with or without file) at >> the time >> of the first query. >> >> This is caused by freeing an entry using "free" that has been allocated >> using >> "entry_dup". This does not match (any more?). Essentially what the code >> was >> trying to to is to duplicate the sql_baseObject to bsi_e. The fix I >> suggest adds >> a function "entry_dup_to" to slapd so that backends can do this >> operation >> cleanly without having to create a temporary dynamic object there is no >> obvious >> clean way to get rid of. > > I'd rather have a function that returns the entry struct to the pool > without calling entry_clean(), to avoid as much as possible code > duplication. In any case, good catch. All in all, I favored using your patch as is. It's now in HEAD, please test. Thanks, p.

1 0

Re: (ITS#6163) back-sql DoS when searching for empty attr
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

The bug is in the fact that (cn=) is an invalid filter, because cn's syntax is directoryString, which does not allow the empty string. As such, the filter evaluates to undefined, and this is not properly handled by back-sql. A fix is in HEAD, please test (you only need to patch back-sql/search.c and the patch should apply to almost any OpenLDAP 2.4 version). p.

1 0

Re: (ITS#6181) slapo-unique: slaptest fails in case unique_uri is prepended the keywords "strict" or "ignore"
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

The "strict" and the "ignore" keywords must be part of a single argument. In fact, the unique_uri statement only takes one argument, consisting of the optional "strict" and "ignore" keywords followed by a list of URIs. In order to be recognized as a single argument, the whole thing needs to be included in double quotes, like unique_uri "strict ldap:///dc=example,dc=com?uid?sub?(objectClass=account)" p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

As far as I recall, this is a known issue, although I could not locate early postings discussing this issue. What happens is that proxy cache makes use of the first item in the filter to discriminate between responses. In your filter template, the first item is the objectClass equality, which means that any filter with that objectClass value, regardless of the uid value, is treated as a duplicate of the first one. If you reverse the order of the equality filters you'll get the expected behavior. There should be another open ITS for this issue, but I can't locate it right now. p.

1 0

Re: (ITS#6231) The same problem: sasl realms don't work with digest-md5
by masarati＠aero.polimi.it 03 Aug '09

03 Aug '09

Software usage questions should be directed to the appropriate mailing lists, unless there is clear evidence of a software/documentation bug. This ITS will be closed. p.

1 0

Re: (ITS#6152) proxycache enhancements
by hyc＠symas.com 02 Aug '09

02 Aug '09

masarati(a)aero.polimi.it wrote: > Just in case, before it becomes totally incompatible with HEAD code, I > have a patch I never committed, it's about making pcache admin-friendly if > it makes any sense. > > It adds: > > - a (persistent) counter that reports, for each query, how many times it > evaluated to answerable > > - "proxycache-" prefixed statements are passed to the private database. > This allows to avoid ambiguities when applying general database directives > in slapd.conf. In fact, it is not clear whether they apply to the proxy > database or to the cache database. > > If they make sense, I'd like to commit them before slapo-pcache > enhancement begins. Go ahead! -- -- 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#6239) ldap_pvt_tls_check_hostname() may be vulnerable
by hyc＠symas.com 31 Jul '09

31 Jul '09

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: any > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > Our chkhost implementation for OpenSSL does a simple strcasecmp on the name > obtained from the certificate CN; if the CN has an embedded NUL it is possible > for this check to be spoofed. This is now fixed in HEAD. > > Our chkhost implementation for GnuTLS is not vulnerable. > > We didn't write a chkhost implementation for MozNSS, we just use the default one > they provide. Inspecting their code shows that their default checker is also > vulnerable. I will be writing a replacement for libldap shortly. All fixed in HEAD/RE24. Surprisingly, the GnuTLS API got this one right. So did OpenSSL (we just botched our use of their APIs). But the MozNSS APIs all discard the length info of the data instead of returning it, so we had to reimplement some of their basic name-handling code in libldap. Probably should have just done all of this using DER and liblber too, like the other cert parsing code. -- -- 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

(ITS#6239) ldap_pvt_tls_check_hostname() may be vulnerable
by hyc＠OpenLDAP.org 30 Jul '09

30 Jul '09

Full_Name: Howard Chu Version: any OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Our chkhost implementation for OpenSSL does a simple strcasecmp on the name obtained from the certificate CN; if the CN has an embedded NUL it is possible for this check to be spoofed. This is now fixed in HEAD. Our chkhost implementation for GnuTLS is not vulnerable. We didn't write a chkhost implementation for MozNSS, we just use the default one they provide. Inspecting their code shows that their default checker is also vulnerable. I will be writing a replacement for libldap shortly.

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by michael＠stroeder.com 30 Jul '09

30 Jul '09

jonathan(a)phillipoux.net wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz > Submission from: (NULL) (82.67.204.30) > > Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that > intercepts successful binds and records the current timestamp in an attribute > named "bindTimestamp" in the bound-to entry. It's original use-case is to detect > unused accounts. Detecting unused accounts can also somewhat achieved by using slapo-accesslog with configuration directive "logops session". Still I see some value for such an simple overlay. > A configuration parameter (olcLastBindPrecision) allows to set a minimum > precision for the timestamp (ie, don't update the timestamp unless it's older > than <n> seconds). This avoids a performance hit from many unnecessary writes in > case there are many binds per minute/hour/day/week/etc. Things to consider: Is this attribute supposed to be replicated? How about adding configuration paramters so you can specify 1. the attribute type used and 2. the datetime format. This could be handy in situations where you want to mimique the behaviour of other LDAP servers. Ciao, Michael.

1 0

(ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by jonathan＠phillipoux.net 30 Jul '09

30 Jul '09

Full_Name: Jonathan Clarke Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz Submission from: (NULL) (82.67.204.30) Hi, Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that intercepts successful binds and records the current timestamp in an attribute named "bindTimestamp" in the bound-to entry. It's original use-case is to detect unused accounts. A configuration parameter (olcLastBindPrecision) allows to set a minimum precision for the timestamp (ie, don't update the timestamp unless it's older than <n> seconds). This avoids a performance hit from many unnecessary writes in case there are many binds per minute/hour/day/week/etc. Of course, the behaviour this overlay implements is not described in any RFC, or other. However, it closely resembles some of the functionality from the password policy overlay, and similar functionality already exists in other LDAP servers. I post it here in the hope that it may serve others, and in case the OpenLDAP wishes to include it in one form or another. I would most appreciate any comments or feedback. Regards, Jonathan PS: please note that the OIDs used are not registered, but used temporarily. I do not currently have access to a registered OID to use.

1 0

Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by masarati＠aero.polimi.it 30 Jul '09

30 Jul '09

evaristojosec(a)yahoo.es wrote: > Full_Name: Evaristo Camarero > Version: 2.4.x > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.20) > > > > Hi, > > Working with slapd under heavy load it could be interesting to have TCP buffers > size configurable at slapd application level instead of getting default OS > values. > > Some fast modifications in daemon.c file to achieve a hardcoded value for the > sender buffer are: > > int buf_size = 1572864; /* 1.5 Mb */ > rc =setsockopt ( s, SOL_SOCKET, SO_SNDBUF, (int*)&buf_size, > sizeof(buf_size)); > if(rc==-1) { > Debug( LDAP_DEBUG_ANY, "slapd(%ld): " > "setsockopt(SO_SNDBUF) failed errno=%d (%s)\n", > (long) l.sl_sd, err, sock_errstr(err) ); > } else { > Debug( LDAP_DEBUG_ANY, "slapd(%ld): setsockopt(SO_SNDBUF) to %d\n", > (long) l.sl_sd, buf_size, 0); > } Since you use Linux, you could try the kernel's tcp autotuning capabilities described in tcp(7) (other informative links are <http://fasterdata.es.net/TCP-tuning/linux.html>, <http://www.kernelfaq.com/2007/11/tcp-auto-tuning.html>). Of course, the possibility to manually enforce the size of the buffer may be useful in some cases, so a specific configuration option may deserve consideration. p.

1 0

Re: (ITS#6235) Installing openLDAP on Solaris 10 (Berkeley DB issue)
by mkassawara＠gmail.com 30 Jul '09

30 Jul '09

The configure script can't find the BDB headers/libraries in the typical places. Either install them to a typical place seen by the preprocessor/linker (e.g., /usr/include, /usr/lib, /usr/local/ include, /usr/local/lib ...) or set the CPPFLAGS and LDFLAGS environment variables appropriately before running the configure script. If you plan to install OpenLDAP to a custom location, consider using "crle" to add the necessary library path(s) to the runtime linking environment. Also, to prevent another issue down the road, make sure you apply the Oracle patches to BDB 4.7.25 before building it. This is not an ITS... you should use openldap-technical for future correspondence on this issue. On Jul 29, 2009, at 3:09 PM, mark.liu(a)nyu.edu wrote: > Full_Name: Mark Liu > Version: 2.4.16 > OS: Sun Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.122.149.115) > > > I am trying to install openLDAP on Solaris 10. Whenever I tried to > configure > openLDAP, it would give the following message: > > checking db.h usability... no > checking db.h presence... no > checking for db.h... no > configure: error: BDB/HDB: BerkeleyDB not available > > The install would stop there. I thought it might be require a > different version > of BerkeleyDB, I downloaded both BerkeleyDB 4.7.25 and 4.6.21. > OpenLDAP > produced the same result for both instances of BerkeleyDB. > > What do i need to do to get pass this? Thanks! >

1 0

(ITS#6235) Installing openLDAP on Solaris 10 (Berkeley DB issue)
by mark.liu＠nyu.edu 29 Jul '09

29 Jul '09

Full_Name: Mark Liu Version: 2.4.16 OS: Sun Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.122.149.115) I am trying to install openLDAP on Solaris 10. Whenever I tried to configure openLDAP, it would give the following message: checking db.h usability... no checking db.h presence... no checking for db.h... no configure: error: BDB/HDB: BerkeleyDB not available The install would stop there. I thought it might be require a different version of BerkeleyDB, I downloaded both BerkeleyDB 4.7.25 and 4.6.21. OpenLDAP produced the same result for both instances of BerkeleyDB. What do i need to do to get pass this? Thanks!

1 0

Re: (ITS#6225) GSSAPI support for client library (fixes)
by mikbec＠web.de 29 Jul '09

29 Jul '09

hyc(a)symas.com wrote: > mimir(a)samba.org wrote: >> Full_Name: Rafal Szczesniak >> Version: Stable (2.4.16) >> OS: GNU/Linux >> URL: http://www.samba.org/~mimir/gssapi-bugfix.diff >> Submission from: (NULL) (67.51.54.234) >> >> >> This is a bugfix patch for OpenLDAP's gssapi support. >> > One of these patches appears to duplicate ITS#6092. As the original author of > this code, could you also take a look at #6091 and #6093? > Yes, I think this patch tries to resolve the same problem like #6093 but with a different approach. And after some discussion with Hallvard B Furuseth about the guess_service_principal() string problem (#6223) I have sent a all-in-one-patch which results in #6110. best regards mike

1 0

Re: (ITS#6215) liblber problems
by h.b.furuseth＠usit.uio.no 29 Jul '09

29 Jul '09

Fixing this, and some other problems: - decode.c incorrectly treats length octet 0x80 (indefinite-length) as long length = 0. Fixing to returning an error. - Overly complex and inefficient code, in particular encode.c. Rewriting. Removing struct seqorset and related allocations. - Missing overflow/max-size checks. - ber_scanf() *must* clean up properly on error, as the code notes. Currently it can crash when reading malformed elements. Both encode.c and decode.c mostly access the Ber data "properly" via ber_write()/ber_read() but sometimes accesses the buffer directly. Can clean up and speed up at the same time by collecting that in fewer places. Side effects: - Dropping ber_write(,,,nonzero) support. Any callers likey need to use BerElement.ber_sos_ptr/ber_sos_inner, the struct seqorset replacement. - Dropping ber_log_sos_dump() and ber_sos_dump(), leaving behind stubs. They'd need a new ber parameter to work. Other matters - questions: - decode.c is quite lax about what it accepts. Should we tighten that when feasible, or remain "liberal in what we accept"? E.g. it accepts BER INTEGER length 0 and BOOLEAN length != 1, and wrong CONSTRUCTED/PRIMITIVE encoding bit. - encode.c willingly stores broken identifier octets if passed an invalid tag, e.g. a single octet with low bits 0x1F implying long tag format. I'm inclined to leave that alone, caller's responsibility. -- Hallvard

1 0

Re: (ITS#6232) OpenLDAP 2.4.17 fails to compile with --with-tls=gnutls
by steffen＠hauihau.de 29 Jul '09

29 Jul '09

Dear Howard, please have a look at http://bugs.gentoo.org/show_bug.cgi?id=233633 . The provided patch in the Debian bug tracker does not fix the compiling issue of passwd.c as the defines and typedefs are inserted *after* the first occurrence of "des_key". I've modified this patch, and it's already included in gentoo's ebuild for OpenLDAP 2.4.17. I don't know if I'm authorized to contribute it to the ITS, as I've only modified the original patch. I would do it of course, if 'm allowed to, since there is no employer, who would prevent me to do it, as I'm doing it in my freetime.

1 0

(ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by evaristojosec＠yahoo.es 29 Jul '09

29 Jul '09

Full_Name: Evaristo Camarero Version: 2.4.x OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.20) Hi, Working with slapd under heavy load it could be interesting to have TCP buffers size configurable at slapd application level instead of getting default OS values. Some fast modifications in daemon.c file to achieve a hardcoded value for the sender buffer are: int buf_size = 1572864; /* 1.5 Mb */ rc =setsockopt ( s, SOL_SOCKET, SO_SNDBUF, (int*)&buf_size, sizeof(buf_size)); if(rc==-1) { Debug( LDAP_DEBUG_ANY, "slapd(%ld): " "setsockopt(SO_SNDBUF) failed errno=%d (%s)\n", (long) l.sl_sd, err, sock_errstr(err) ); } else { Debug( LDAP_DEBUG_ANY, "slapd(%ld): setsockopt(SO_SNDBUF) to %d\n", (long) l.sl_sd, buf_size, 0); } Regards, Evaristo

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 29 Jul '09

29 Jul '09

jclarke(a)linagora.com wrote: > On 14.02.2009 01:51, Howard Chu wrote: >> Jonathan Clarke wrote: >>> On 13.02.2009 01:23, Howard Chu wrote: >>>> There are valid reasons to point a syncrepl consumer at the same slapd >>>> (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a >>>> subtree of a main database, etc.). Using the exhaustive matching that >>>> serverID uses would preclude those cases from working. >>> I see. I understand you don't want to break existing functionality. >>> However, I still feel this is a bug, or at least that you need to "hack" >>> the setup to get things working as expected. >> >> The docs state that "syncrepl provider" is the LDAP URI of the master >> server. If you're not putting in the same URI as the master is using, >> that's a config error, not a bug. > > Understood. Nothing is broken, and we have worked around this issue > using explicit listeners to slapd -h. > > This behaviour did surprise me, considering the behaviour of serverID > matching. May I suggest that a note of warning is included in the admin > guide? For example: > http://milopita.phillipoux.net/jonathan-clarke-20090216.patch > >>> Would I be right in assuming that in all the "valid reasons to point a >>> syncrepl consumer at the same slapd" you mention, the syncrepl consumer >>> uses a different base DN than the base DN of the database that the >>> syncrepl consumer is configured on? If so, maybe the exhaustive matching >>> that serverID uses could be used, if and only if those two base DNs are >>> different? Actually, the exhaustive matching is only needed if the two base DNs are the same. This is now patched in HEAD, please test. >> That sounds reasonable. Will think about it a bit more. Certainly if the >> two base DNs are the same, it will cause a loop... > > Indeed. For what it's worth, while testing on cn=config, I noticed this > having various consequences including: > 1) cn=config becoming read-only (shadow) and updates returning a referral. > 2) in a MMR setup, some updates not being replicated to all N servers. -- -- 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#6233) print_deref assertion if no deref attributes returned
by hyc＠symas.com 28 Jul '09

28 Jul '09

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.17+ (current HEAD) > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.113.59.19) > > > I am testing the LDAP Dereference feature specified here - > http://www.openldap.org/devel/cvsweb.cgi/~checkout~/doc/drafts/draft-masara… > > I am getting an assertion in common.c at line 2077: > 2074: ptr = lutil_strncopy( ptr, dr->derefVal.bv_val, dr->derefVal.bv_len ); > 2075: *ptr++ = '\n'; > 2076: *ptr++ = '\0'; > 2077: assert( ptr<= buf + len ); > > tool_write_ldif( LDIF_PUT_COMMENT, NULL, buf, ptr - buf); > > In my test, ptr is one greater than buf + len. It appears that len does not > take into consideration the addition of the trailing \0 at line 2076. My test > is looking for a dereference attribute which does not have any values, so that > the attrVals in the control response is empty. If there are values to return in > attrVals, the assertion is not triggered. > Ah the ever-popular off-by-one. Should be OK now in HEAD, thanks for the report. -- -- 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#6232) OpenLDAP 2.4.17 fails to compile with --with-tls=gnutls
by hyc＠symas.com 28 Jul '09

28 Jul '09

steffen.hau(a)rz.uni-mannheim.de wrote: > Full_Name: Steffen Hau > Version: 2.4.17 > OS: gentoo > URL: > Submission from: (NULL) (134.155.35.13) > > > Gentoo prefers gnutls usage over openssl when compiling openldap. But if > with-tls=gnutls and enable-lmpasswd set, neither HAVE_OPENSSL nor NAVE_MOZNSS is > defined and passwd.c failes to compile with: See ITS #4997. There is a patch for this in the debian bug tracker, but until someone with appropriate authorization (i.e., the patch author) contributes it to the ITS with the requisite Rights statements attached, we cannot incorporate it. > passwd.c:813: error: expected declaration specifiers or ... before des_key > passwd.c: In function lmPasswd_to_key: > passwd.c:828: error: key undeclared (first use in this function) > passwd.c:828: error: (Each undeclared identifier is reported only once > passwd.c:828: error: for each function it appears in.) > passwd.c: In function chk_lanman: > passwd.c:839: error: des_key undeclared (first use in this function) > passwd.c:839: error: expected ; before key > passwd.c:840: error: des_context undeclared (first use in this function) > passwd.c:840: error: expected ; before schedule > passwd.c:841: error: des_data_block undeclared (first use in this function) > passwd.c:841: error: expected ; before StdText > passwd.c:842: error: expected ; before PasswordHash1 > passwd.c:859: error: key undeclared (first use in this function) > passwd.c:859: error: too many arguments to function lmPasswd_to_key > passwd.c:860: error: schedule undeclared (first use in this function) > passwd.c:861: error: StdText undeclared (first use in this function) > passwd.c:861: error: PasswordHash1 undeclared (first use in this function) > passwd.c:861: error: DES_ENCRYPT undeclared (first use in this function) > passwd.c:867: error: too many arguments to function lmPasswd_to_key > passwd.c:869: error: PasswordHash2 undeclared (first use in this function) > passwd.c: In function hash_lanman: > passwd.c:1135: error: des_key undeclared (first use in this function) > passwd.c:1135: error: expected ; before key > passwd.c:1136: error: des_context undeclared (first use in this function) > passwd.c:1136: error: expected ; before schedule > passwd.c:1137: error: des_data_block undeclared (first use in this function) > passwd.c:1137: error: expected ; before StdText > passwd.c:1138: error: expected ; before PasswordHash1 > passwd.c:1155: error: key undeclared (first use in this function) > passwd.c:1155: error: too many arguments to function lmPasswd_to_key > passwd.c:1156: error: schedule undeclared (first use in this function) > passwd.c:1157: error: StdText undeclared (first use in this function) > passwd.c:1157: error: PasswordHash1 undeclared (first use in this function) > passwd.c:1157: error: DES_ENCRYPT undeclared (first use in this function) > passwd.c:1159: error: too many arguments to function lmPasswd_to_key > passwd.c:1161: error: PasswordHash2 undeclared (first use in this function) > make[2]: *** [passwd.o] Error 1 > > I took a look in the passwd.c file, and because of neither HAVE_OPENSSL nor > HAVE_MOZNSS is defined, des_key isn't defined also. There is already a check in > the configure script, if tls is set when lmpasswd is set. The failure message > for it explains, that there has to be openssl installed in order to use lm > passwords. Perhaps this test has to be changed in a manner that it's checked, > what implementation is used for tls, and only activates lm passwords only, if > tls is either openssl or moznss. > > Please let me know if you need further information. > > Best regards, > Steffen Hau > -- -- 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

(ITS#6233) print_deref assertion if no deref attributes returned
by rmeggins＠redhat.com 28 Jul '09

28 Jul '09

Full_Name: Rich Megginson Version: 2.4.17+ (current HEAD) OS: Fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.113.59.19) I am testing the LDAP Dereference feature specified here - http://www.openldap.org/devel/cvsweb.cgi/~checkout~/doc/drafts/draft-masara… I am getting an assertion in common.c at line 2077: 2074: ptr = lutil_strncopy( ptr, dr->derefVal.bv_val, dr->derefVal.bv_len ); 2075: *ptr++ = '\n'; 2076: *ptr++ = '\0'; 2077: assert( ptr <= buf + len ); tool_write_ldif( LDIF_PUT_COMMENT, NULL, buf, ptr - buf); In my test, ptr is one greater than buf + len. It appears that len does not take into consideration the addition of the trailing \0 at line 2076. My test is looking for a dereference attribute which does not have any values, so that the attrVals in the control response is empty. If there are values to return in attrVals, the assertion is not triggered.

1 0

(ITS#6232) OpenLDAP 2.4.17 fails to compile with --with-tls=gnutls
by steffen.hau＠rz.uni-mannheim.de 28 Jul '09

28 Jul '09

Full_Name: Steffen Hau Version: 2.4.17 OS: gentoo URL: Submission from: (NULL) (134.155.35.13) Gentoo prefers gnutls usage over openssl when compiling openldap. But if with-tls=gnutls and enable-lmpasswd set, neither HAVE_OPENSSL nor NAVE_MOZNSS is defined and passwd.c failes to compile with: passwd.c:813: error: expected declaration specifiers or ... before des_key passwd.c: In function lmPasswd_to_key: passwd.c:828: error: key undeclared (first use in this function) passwd.c:828: error: (Each undeclared identifier is reported only once passwd.c:828: error: for each function it appears in.) passwd.c: In function chk_lanman: passwd.c:839: error: des_key undeclared (first use in this function) passwd.c:839: error: expected ; before key passwd.c:840: error: des_context undeclared (first use in this function) passwd.c:840: error: expected ; before schedule passwd.c:841: error: des_data_block undeclared (first use in this function) passwd.c:841: error: expected ; before StdText passwd.c:842: error: expected ; before PasswordHash1 passwd.c:859: error: key undeclared (first use in this function) passwd.c:859: error: too many arguments to function lmPasswd_to_key passwd.c:860: error: schedule undeclared (first use in this function) passwd.c:861: error: StdText undeclared (first use in this function) passwd.c:861: error: PasswordHash1 undeclared (first use in this function) passwd.c:861: error: DES_ENCRYPT undeclared (first use in this function) passwd.c:867: error: too many arguments to function lmPasswd_to_key passwd.c:869: error: PasswordHash2 undeclared (first use in this function) passwd.c: In function hash_lanman: passwd.c:1135: error: des_key undeclared (first use in this function) passwd.c:1135: error: expected ; before key passwd.c:1136: error: des_context undeclared (first use in this function) passwd.c:1136: error: expected ; before schedule passwd.c:1137: error: des_data_block undeclared (first use in this function) passwd.c:1137: error: expected ; before StdText passwd.c:1138: error: expected ; before PasswordHash1 passwd.c:1155: error: key undeclared (first use in this function) passwd.c:1155: error: too many arguments to function lmPasswd_to_key passwd.c:1156: error: schedule undeclared (first use in this function) passwd.c:1157: error: StdText undeclared (first use in this function) passwd.c:1157: error: PasswordHash1 undeclared (first use in this function) passwd.c:1157: error: DES_ENCRYPT undeclared (first use in this function) passwd.c:1159: error: too many arguments to function lmPasswd_to_key passwd.c:1161: error: PasswordHash2 undeclared (first use in this function) make[2]: *** [passwd.o] Error 1 I took a look in the passwd.c file, and because of neither HAVE_OPENSSL nor HAVE_MOZNSS is defined, des_key isn't defined also. There is already a check in the configure script, if tls is set when lmpasswd is set. The failure message for it explains, that there has to be openssl installed in order to use lm passwords. Perhaps this test has to be changed in a manner that it's checked, what implementation is used for tls, and only activates lm passwords only, if tls is either openssl or moznss. Please let me know if you need further information. Best regards, Steffen Hau

1 0

(ITS#6231) The same problem: sasl realms don't work with digest-md5
by jackli7312＠yahoo.com.cn 28 Jul '09

28 Jul '09

Full_Name: jackli Version: 2.4.16 OS: fedora9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (121.41.165.157) I searched this problem from mail list, and there is no response for it. I'm really suffering this for a week. Any help will be greatly appreciated! Please help. Jack hi all, i've got a problem with the sasl authentication using digest-md5 and multiple realms with my openldapServer 2.3.19 (fc5, yum). i want to be able to authenticate against different subtrees of the dit by using different realms and i was reading as many documentation, howtos and so on as i was able to find at the net for at least the last 7 days. i don't get it running...! currently, for testing, i use two different realms: mydomain.net (o=home,dc=mydit,dc=lan) test.mydomain.net (o=test,dc=mydit,dc=lan) in the slapd.conf i added: # sasl-realm mydomain.net authz-regexp uid=(.*),cn=test.mydomain.net,cn=digest-md5,cn=auth uid=$1,ou=users,o=test,dc=ditroot authz-regexp uid=(.*),cn=mydomain.net,cn=digest-md5,cn=auth uid=$1,ou=users,o=home,dc=ditroot authz-regexp uid=(.*),cn=digest-md5,cn=auth uid=$1,ou=users,o=home,dc=ditroot as you can see, the sasl-realm parameter is commented. whether or not i comment or uncomment it, it does not work. (actualy it works, but only either for the default realm or through the last sasl-regexp if i set it, all authentication attemps are of the format: uid=XY,cn=mydomain.net,cn=digest-md5,cn=auth if i do not set it, all authentication is done using: uid=XY,cn=digest-md5,cn=auth i realy tried a lot, e.g.: (things like -h, ... are covered by the ldap.conf) - ldapwhoami -U XY -R test.mydomain.net - ldapwhoami -U XY(a)test.mydomain.net - ldapsearch -U XY -R test.mydomain.net - ldap... of course all of those test where performed with different -R, ... values. i realy do not know what to do anymore, i've got no more ideas... also what i do not understand is whether or not this is a problem with my cyrus-sasl installation, but i cannot imagine that. i guess i'm missing something but i don't know what. can someone help me with this, please? have a nice day... d.a.s.

1 0

Re: (ITS#6230) test056-monitor: comparison failed - database monitor output is not correct
by hyc＠symas.com 27 Jul '09

27 Jul '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.81.222) > > > Please let me know whether testrun/ is needed for examining this issue: Never mind, fixed in HEAD. > >>>>>> Starting test056-monitor for bdb... > running defines.sh > Starting slapd on TCP/IP port ... > Using ldapsearch to check that slapd is running... > Using ldapsearch to read connection monitor entries... > Filtering ldapsearch results... > Filtering expected data... > Comparing filter output... > Using ldapsearch to read database monitor entries... > Filtering ldapsearch results... > Comparing filter output... > comparison failed - database monitor output is not correct >>>>>> ./scripts/test056-monitor failed for bdb (exit 1) > make[2]: *** [bdb-mod] Error 1 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 > > -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs