- openldap-bugs - openldap.org

Re: (ITS#7493) slapo-allowed: allowed* attrs are replicated
by hyc＠symas.com 15 Jan '13

15 Jan '13

On Tue, Jan 15, 2013 at 12:18:59PM +0000, michael(a)stroeder.com wrote: > Full_Name: > Version: RE24 6f33e2c > OS: > URL: > Submission from: (NULL) (2001:8d8:1fe:1:d6be:d9ff:fe06:a14f) > > > It seems that operational attributes generated by slapo-allowed are replicated. Works as designed. These attributes are directoryOperation, not DSA-specific. Closing this ITS. > Syslog shows: > mods check (allowedAttributes: value #0 invalid per syntax) >

1 0

(ITS#7493) slapo-allowed: allowed* attrs are replicated
by michael＠stroeder.com 15 Jan '13

15 Jan '13

Full_Name: Version: RE24 6f33e2c OS: URL: Submission from: (NULL) (2001:8d8:1fe:1:d6be:d9ff:fe06:a14f) It seems that operational attributes generated by slapo-allowed are replicated. Syslog shows: mods check (allowedAttributes: value #0 invalid per syntax)

1 0

(ITS#7492) add "onerr" to back-ldap
by masarati＠aero.polimi.it 12 Jan '13

12 Jan '13

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.21.25) Submitted by: ando back-meta supports "onerr" to determine search behavior when an error is returned by a remote server; a similar behavior may be desirable for back-ldap. Right now, when an error occurs, back-ldap stops sending entries and returns success. The "onerr stop" directive makes back-ldap return the error instead; "onerr continue" produces the current behavior.

1 0

Re: (ITS#7491) mdb write bus error before adding 5 million keys
by clayton.stangeland＠gmail.com 11 Jan '13

11 Jan '13

Thank you. I did not consider the transaction size. On 1/11/13, Howard Chu <hyc(a)symas.com> wrote: > clayton.stangeland(a)gmail.com wrote: >> Full_Name: Clayton Stangeland >> Version: git mdb.master last commit >> fed573cb86ed99f37bd062908ec814ee0ca47053 >> OS: Fedora 17 64 bit >> URL: ftp://ftp.openldap.org/incoming/mtest-big.c >> Submission from: (NULL) (192.94.73.31) >> >> >> Building and running mdb from git branch mdb.master commit >> fed573cb86ed99f37bd062908ec814ee0ca47053 on Fedora 17 64 bit I get a bus >> error. > > Thanks for the report. The bus error is now fixed in git mdb.master. We > assume > that most users will not batch so many operations into a single > transaction. >> >> When running the test below, which is a modification of mtest.c, I get a >> Bus >> error. This happens while trying to write the file. gdb reports line 3936 >> of >> mdb.c as the erroring line inside mdb_page_search_root: while >> (IS_BRANCH(mp)) { >> >> If I set count to 4 million instead of 5 million it works, and adding back >> in >> all the other mtest.c tests works as well then. >> >> Here is the code: >> /* mtest.c - memory-mapped database tester/toy */ >> /* >> * Copyright 2011 Howard Chu, Symas Corp. >> * All rights reserved. >> * >> * Redistribution and use in source and binary forms, with or without >> * modification, are permitted only as authorized by the OpenLDAP >> * Public License. >> * >> * A copy of this license is available in the file LICENSE in the >> * top-level directory of the distribution or, alternatively, at >> * <http://www.OpenLDAP.org/license.html>. >> */ >> #define _XOPEN_SOURCE 500 /* srandom(), random() */ >> #include <stdio.h> >> #include <stdlib.h> >> #include <time.h> >> #include "lmdb.h" >> >> int main(int argc,char * argv[]) >> { >> int i = 0, j = 0, rc; >> MDB_env *env; >> MDB_dbi dbi; >> MDB_val key, data; >> MDB_txn *txn; >> MDB_stat mst; >> MDB_cursor *cursor; >> int count; >> int *values; >> char sval[32]; >> >> srandom(time(NULL)); >> >> count = (5000000) + 64; >> values = (int *)malloc(count*sizeof(int)); >> >> for(i = 0;i<count;i++) { >> values[i] = random()%1000000000; >> } >> >> rc = mdb_env_create(&env); >> rc = mdb_env_set_mapsize(env, 10485760000); >> rc = mdb_env_open(env, "./testdb", MDB_FIXEDMAP >> /*|MDB_NOSYNC*/, >> 0664); >> rc = mdb_txn_begin(env, NULL, 0, &txn); >> rc = mdb_open(txn, NULL, 0, &dbi); >> >> key.mv_size = sizeof(sval); >> key.mv_data = sval; >> data.mv_size = sizeof(sval); >> data.mv_data = sval; >> >> for (i=0;i<count;i++) { >> sprintf(sval, "%08x %d foo bar", values[i], >> values[i]); >> rc = mdb_put(txn, dbi, &key, &data, >> MDB_NOOVERWRITE); >> if (rc) j++; >> } >> if (j) printf("%d duplicates skipped\n", j); >> rc = mdb_txn_commit(txn); >> rc = mdb_env_stat(env, &mst); >> >> free(values); >> mdb_close(env, dbi); >> mdb_env_close(env); >> >> return 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#7491) mdb write bus error before adding 5 million keys
by hyc＠symas.com 11 Jan '13

11 Jan '13

clayton.stangeland(a)gmail.com wrote: > Full_Name: Clayton Stangeland > Version: git mdb.master last commit fed573cb86ed99f37bd062908ec814ee0ca47053 > OS: Fedora 17 64 bit > URL: ftp://ftp.openldap.org/incoming/mtest-big.c > Submission from: (NULL) (192.94.73.31) > > > Building and running mdb from git branch mdb.master commit > fed573cb86ed99f37bd062908ec814ee0ca47053 on Fedora 17 64 bit I get a bus error. Thanks for the report. The bus error is now fixed in git mdb.master. We assume that most users will not batch so many operations into a single transaction. > > When running the test below, which is a modification of mtest.c, I get a Bus > error. This happens while trying to write the file. gdb reports line 3936 of > mdb.c as the erroring line inside mdb_page_search_root: while (IS_BRANCH(mp)) { > > If I set count to 4 million instead of 5 million it works, and adding back in > all the other mtest.c tests works as well then. > > Here is the code: > /* mtest.c - memory-mapped database tester/toy */ > /* > * Copyright 2011 Howard Chu, Symas Corp. > * All rights reserved. > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted only as authorized by the OpenLDAP > * Public License. > * > * A copy of this license is available in the file LICENSE in the > * top-level directory of the distribution or, alternatively, at > * <http://www.OpenLDAP.org/license.html>. > */ > #define _XOPEN_SOURCE 500 /* srandom(), random() */ > #include <stdio.h> > #include <stdlib.h> > #include <time.h> > #include "lmdb.h" > > int main(int argc,char * argv[]) > { > int i = 0, j = 0, rc; > MDB_env *env; > MDB_dbi dbi; > MDB_val key, data; > MDB_txn *txn; > MDB_stat mst; > MDB_cursor *cursor; > int count; > int *values; > char sval[32]; > > srandom(time(NULL)); > > count = (5000000) + 64; > values = (int *)malloc(count*sizeof(int)); > > for(i = 0;i<count;i++) { > values[i] = random()%1000000000; > } > > rc = mdb_env_create(&env); > rc = mdb_env_set_mapsize(env, 10485760000); > rc = mdb_env_open(env, "./testdb", MDB_FIXEDMAP /*|MDB_NOSYNC*/, > 0664); > rc = mdb_txn_begin(env, NULL, 0, &txn); > rc = mdb_open(txn, NULL, 0, &dbi); > > key.mv_size = sizeof(sval); > key.mv_data = sval; > data.mv_size = sizeof(sval); > data.mv_data = sval; > > for (i=0;i<count;i++) { > sprintf(sval, "%08x %d foo bar", values[i], values[i]); > rc = mdb_put(txn, dbi, &key, &data, MDB_NOOVERWRITE); > if (rc) j++; > } > if (j) printf("%d duplicates skipped\n", j); > rc = mdb_txn_commit(txn); > rc = mdb_env_stat(env, &mst); > > free(values); > mdb_close(env, dbi); > mdb_env_close(env); > > return 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

(ITS#7491) mdb write bus error before adding 5 million keys
by clayton.stangeland＠gmail.com 11 Jan '13

11 Jan '13

Full_Name: Clayton Stangeland Version: git mdb.master last commit fed573cb86ed99f37bd062908ec814ee0ca47053 OS: Fedora 17 64 bit URL: ftp://ftp.openldap.org/incoming/mtest-big.c Submission from: (NULL) (192.94.73.31) Building and running mdb from git branch mdb.master commit fed573cb86ed99f37bd062908ec814ee0ca47053 on Fedora 17 64 bit I get a bus error. When running the test below, which is a modification of mtest.c, I get a Bus error. This happens while trying to write the file. gdb reports line 3936 of mdb.c as the erroring line inside mdb_page_search_root: while (IS_BRANCH(mp)) { If I set count to 4 million instead of 5 million it works, and adding back in all the other mtest.c tests works as well then. Here is the code: /* mtest.c - memory-mapped database tester/toy */ /* * Copyright 2011 Howard Chu, Symas Corp. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted only as authorized by the OpenLDAP * Public License. * * A copy of this license is available in the file LICENSE in the * top-level directory of the distribution or, alternatively, at * <http://www.OpenLDAP.org/license.html>. */ #define _XOPEN_SOURCE 500 /* srandom(), random() */ #include <stdio.h> #include <stdlib.h> #include <time.h> #include "lmdb.h" int main(int argc,char * argv[]) { int i = 0, j = 0, rc; MDB_env *env; MDB_dbi dbi; MDB_val key, data; MDB_txn *txn; MDB_stat mst; MDB_cursor *cursor; int count; int *values; char sval[32]; srandom(time(NULL)); count = (5000000) + 64; values = (int *)malloc(count*sizeof(int)); for(i = 0;i<count;i++) { values[i] = random()%1000000000; } rc = mdb_env_create(&env); rc = mdb_env_set_mapsize(env, 10485760000); rc = mdb_env_open(env, "./testdb", MDB_FIXEDMAP /*|MDB_NOSYNC*/, 0664); rc = mdb_txn_begin(env, NULL, 0, &txn); rc = mdb_open(txn, NULL, 0, &dbi); key.mv_size = sizeof(sval); key.mv_data = sval; data.mv_size = sizeof(sval); data.mv_data = sval; for (i=0;i<count;i++) { sprintf(sval, "%08x %d foo bar", values[i], values[i]); rc = mdb_put(txn, dbi, &key, &data, MDB_NOOVERWRITE); if (rc) j++; } if (j) printf("%d duplicates skipped\n", j); rc = mdb_txn_commit(txn); rc = mdb_env_stat(env, &mst); free(values); mdb_close(env, dbi); mdb_env_close(env); return 0; }

1 0

(ITS#7490) Security weakness in sha2 password module
by mhardin＠symas.com 11 Jan '13

11 Jan '13

Full_Name: Matthew Hardin Version: 2.4.33+ OS: All URL: ftp://ftp.openldap.org/incoming/sha2.c-diff.txt Submission from: (NULL) (69.43.206.100) contrib/slapd-modules/passwd/sha2/sha2.c uses a series of context buffers and zeros them out in several places using the following macro: MEMSET_BZERO(context, sizeof(context)) The variable 'context' is a pointer to a context buffer, so sizeof will evaluate to the size of a pointer for the particular platform. As a result, the context buffer is only partially zeroed. The correct invocation is: MEMSET_BZERO(context, sizeof(*context)) which will zero out the complete context buffer. The referenced diff details the changes to sha2.c that are necessary to correct this issue. Note this also cleans up warnings reported by MacOS's clang compiler. I, Matthew Hardin, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

RE: (ITS#7434) idassert-bind fails after restarting slapd
by blance3459＠hotmail.com 11 Jan '13

11 Jan '13

Okay, trying again with Thunderbird since Hotmail is determined only to send in HTML format... Quanah, Trying to post a reply using my Hotmail account. Sorry for the unreadable output previously posted. I'm almost embarrassed to say I've been involved in IT for over 15 years and never used a mailing list before. Anyhow, I did download the source packages and compiled them. However, the semester was winding down and I was under a lot of pressure to have something completed before the end of finals week so my professor could assign me a grade for the work I had done. I revered back to my previous version to to get some stuff written. Not to mention, my algorithms professor was kicking my butt too. Will I ever "really" need an FFT in the real world? lol The more I looked at what I was trying to accomplish, I realized I was attacking the problem all wrong. What I was being asked to do was something more like configuring my two slapd servers to act more like Active Directory global catalog servers. GC's utilize MM instead of single master replication so I scrapped the SM replication design in favor of MM. Once this was done, I no longer needed the chaining overlay or proxy auth. I now have MM replication of both cn=config and my directory data (with delta) working and my Kerberos KDC's are happy. One thing I did find was that configuring MM replication made me learn a little more about how to "properly" name/configure an overlay with the syncprov and accesslog modules by digging into the test scripts. I had some issues with sync state on the consumers , but I found a post you made to someone else a few years back that solved my delta replication issue by configuring an syncprov overlay on the accesslog db. Not sure I remember seeing that in the Admin Guide. Looking back at the original post I noticed the chain overlay I had configured was dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config. knowing what I know now, I'm not 100% sure that was correct. Shouldn't that overlay have been in either config database of my directory or ldap backend database for the chain rather than a "frontend"? Just a thought I've been kicking around in my head. Either way, I have my ldap config working. We can either close this issue if you'd like or leave it open and I'll attempt to confirm my theory on the overlay not being properly located when I get a chance. Completely your choice. But I do have a couple questions on my MM replication of cn=config if you want to take them. First, does it make sense or is it possible to do delta replication on cn=config? The data "on the wire" seems like it would be much smaller and less frequent than directory data so perhaps it's not as beneficial? Secondly, I am using a simple bind with this replication agreement (versus sasl/gssapi and tls for my directory data). When configuring limits and acl's for replication of my dit, I created a groupofnames (cn=replicators, ou=groups, dc=example,dc=net) that has each ldap server as a member. My thought process was that this made the solution a bit more scalable. As ldap servers were added to the topology, they could be added to the group of names and automatically be given the correct permissions an limits. Likewise, as server are decommissioned, they could easily be removed by deleting them from the group and directory. Can I use this same group of names in cn=config replication by creating a similar limit and acl using this group of names? Since I am handling the formatting of the gssapi uid in cn=config (maybe a mistake if I ever wanted to be able to handle multiple directories/domains), can I use the gssapi authentication of hosts in dc=example,dc=net? Seems I should be able to since it appears that when the authorization occurs in the database, the bind id is assumed to be already authenticated and accepted as presented with no further authentication taking place. I'm thinking that so long as that uid is formatted into a db listed in an acl, the matching access is applied? Am I way off base in my thinking? Now that I have a rough workable solution I'm just trying to pretty it up a bit and make the design more efficient and scalable. Thanks Barry

1 0

(ITS#7489) Update slapd.overlays.5 manpage index
by ebackes＠symas.com 11 Jan '13

11 Jan '13

Full_Name: Emily Backes Version: HEAD, RE24 OS: URL: Submission from: (NULL) (98.155.30.248) The slapd.overlays (5) manpage index of overlays is out of date and doesn't list all included documentation. This patch fixes it, and should be applicable against both master and RE24 branches. http://www.symas.com/lucca/Update-slapd.overlays.5-manpage-index.patch.txt This patch is summary of existing OpenLDAP materials and already included under the copyright and licensing terms of the OpenLDAP project.

1 0

ITS#7434
by blance3459＠hotmail.com 10 Jan '13

10 Jan '13

--_2dfc1396-6cab-4ee1-b5cd-ec8dfb5286a7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Quanah=2C Trying to post a reply using my hotmail account. Sorry for the = unreadable output previously posted. I'm almost embarassed to say I've bee= n involved in IT for over 15 years and never used a mailing list before. An= yhow=2C I did download the source packages and compiled them. However=2C t= he semester was winding down and I was under a lot of pressure to have some= thing completed before the end of finals week so my professor could assgn m= e a grade for the work I had done. I revered back to my previous version t= o to get some stuff written. Not to mention=2C my algorithms professor was= kicking my butt too. Wil I ever "really" need an FFT in the real world? l= ol The more I looked at what I was trying to accomplish=2C I realized I was= attaking the problem all wrong. What I was being asked to do was somethin= g more like configuring my two slapd servers to act more like Active Direct= ory global catalog servers. GC's utilitze MM instead of single master repl= ication so I scrapped the SM replication design in favor of MM. Once this = was done=2C I no longer needed the chaining overlay or proxy auth. I now h= ave MM replication of both cn=3Dconfig and my directory data (with delta) w= orking and my Kerberos KDC's are happy. One thing I did find was that confi= guring MM replication made me learn a little more about how to "properly" n= ame/configure an overlay with the syncprov and accesslog modules by digging= into the test scripts. I had some issues with sync state on the consumer= s =2C but I found a post you made to someone else a few years back that sol= ved my delta replication issue by configuring an syncprov overlay on the ac= cesslog db. Not sure I remember seeing that in the Admin Guide. Looking ba= ck at the orignal post I noticed the chain overlay I had configured was dn:= olcDatabase=3Dldap=2ColcOverlay=3D{0}chain=2ColcDatabase=3D{-1}frontend=2C= cn=3Dconfig. knowing what I know now=2C I'm not 100% sure that was correc= t. Shouldn't that overlay have been in either config database of my direct= ory or ldap backend database for the chain rather than a "frontend"? Just= a thought I've been kicking around in my head. Either way=2C I have my lda= p config working. We can either close this issue if you'd like or leave it= open and I'll attempt to confirm my theory on the overlay not being proper= ly located when I get a chance. Completely your choice. But I do have a couple questions on my MM replication of cn=3Dconfig if you= want to take them. First=2C does it make sense or is it possible to do de= lta replication on cn=3Dconfig? The data "on the wire" seems like it would= be much smaller and less frequent than directory data so perhaps it's not = as beneficial? Secondly=2C I am using a simple bind with this replication= agreement (versus sasl/gssapi and tls for my directoiry data). When confi= guring limits and acl's for replication of my dit=2C I created a groupofnam= es (cn=3Dreplicators=2C ou=3Dgroups=2C dc=3Dexample=2Cdc=3Dnet) that has ea= ch ldap server as a member. My thought process was that this made the solu= tion a bit more scalable. As ldap servers were added to the topology=2C th= ey could be added to the group of names and automtically be given the corre= ct permissions an limits. Likewise=2C as server are decomisioned=2C they c= ould easily be removed by deleteing them from the group and directory. Ca= n I use this same group of names in cn=3Dconfig replication by creating a s= imilar limit and acl using this group of names? Since I am handling the fo= rmatting of the gssapi uid in cn=3Dconfig (maybe a mistake if I ever wanted= to be able to handle multiple directories/domains)=2C can I use the gssapi= authtication of hosts in dc=3Dexample=2Cdc=3Dnet? Seems I sould be able t= o since it appears that when the authorization occurs in the database=2C th= e bind id is assumed to be already authenticated and accepted as presented = with no further authentication taking place. I'm thinking that so long as = that uid is formatted into a dn listed in an acl=2C the matching access is = applied? Am I way off base in my thinking? Now that I have a rough workab= le solution I'm just trying to pretty it up a bit and make the design more = efficient and scalable. Thanks Barry = --_2dfc1396-6cab-4ee1-b5cd-ec8dfb5286a7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style></head> <body class=3D'hmmessage'><div dir=3D'ltr'>Quanah=2C <BR>&nbsp=3B<BR>Trying= to post a reply using my hotmail account.&nbsp=3B Sorry for the unreadable= output previously posted.&nbsp=3B I'm almost embarassed to say I've been i= nvolved in IT for over 15 years and never used a mailing list before.<BR>&n= bsp=3B<BR>Anyhow=2C I did download the source packages and compiled them.&n= bsp=3B However=2C the semester was winding down and I was under a lot of pr= essure to have something completed before the end of finals week so my prof= essor could assgn me a grade for the work I had done.&nbsp=3B I revered bac= k to my previous version to to get some stuff written.&nbsp=3B Not to menti= on=2C my algorithms professor was kicking my butt too. Wil I ever "really" = need an FFT in the real world?&nbsp=3B lol<BR>&nbsp=3B<BR>The more I looked= at what I was trying to accomplish=2C I realized I was attaking the proble= m all wrong.&nbsp=3B What I was being asked to do was something more like c= onfiguring my two slapd servers to act more like Active Directory global ca= talog servers. GC's utilitze MM instead of&nbsp=3B single master replicatio= n so I scrapped the SM replication design in favor of MM.&nbsp=3B Once this= was done=2C I no longer needed the chaining overlay or proxy auth.&nbsp=3B= I now have MM replication of both cn=3Dconfig and my directory data (with = delta) working and my Kerberos KDC's are happy.<BR>&nbsp=3B<BR>One thing I = did find was that configuring MM replication made me learn a little more ab= out how to "properly" name/configure an overlay with the syncprov and acces= slog modules by digging into the test scripts.&nbsp=3B&nbsp=3B&nbsp=3BI had= some issues with sync state on the consumers&nbsp=3B=2C but I found a post= you made to someone else a few years back that solved my delta replication= issue by configuring an syncprov overlay on the accesslog db.&nbsp=3B Not = sure I remember seeing that in the Admin Guide.<BR>&nbsp=3B<BR>Looking back= at the orignal post I noticed the chain overlay I had configured was dn: o= lcDatabase=3Dldap=2ColcOverlay=3D{0}chain=2ColcDatabase=3D{-1}frontend=2C c= n=3Dconfig.&nbsp=3B knowing what I know now=2C I'm not 100% sure that was c= orrect.&nbsp=3B Shouldn't that overlay have been in&nbsp=3Beither config da= tabase&nbsp=3Bof my directory&nbsp=3B or ldap backend database for the chai= n rather than a "frontend"?&nbsp=3B Just a thought I've been kicking around= in my head.<BR>&nbsp=3B<BR>Either way=2C I have my ldap config working.&nb= sp=3B We can either close this issue if you'd like or leave it open and I'l= l attempt to confirm my theory on the overlay not being properly located wh= en I get a chance.&nbsp=3B&nbsp=3B&nbsp=3BCompletely your choice.<br><BR>Bu= t I do have a couple questions on my MM replication of cn=3Dconfig if you w= ant to take them.&nbsp=3B First=2C does it make sense or is it possible to = do delta replication on cn=3Dconfig?&nbsp=3B The data "on the wire" seems l= ike it would be much smaller and less frequent than directory data so perha= ps it's&nbsp=3Bnot as beneficial?&nbsp=3B&nbsp=3B Secondly=2C I am using a = simple bind with this replication agreement (versus sasl/gssapi and tls for= my directoiry data).&nbsp=3B When configuring limits and acl's for replica= tion of my dit=2C I created a groupofnames (cn=3Dreplicators=2C ou=3Dgroups= =2C dc=3Dexample=2Cdc=3Dnet) that has each ldap server as a member.&nbsp=3B= My thought process was that this made the solution a bit more scalable.&nb= sp=3B As ldap servers were added to the topology=2C they could be added to = the group of names and automtically be given the correct permissions an lim= its.&nbsp=3B Likewise=2C as server are decomisioned=2C they could easily be= removed&nbsp=3Bby deleteing them from the group and directory.&nbsp=3B&nbs= p=3B Can I use this same group of names in cn=3Dconfig replication by creat= ing a similar limit and acl using this group of names?&nbsp=3B Since I am h= andling the formatting of the gssapi uid in cn=3Dconfig (maybe&nbsp=3Ba mis= take if I ever wanted to be able to handle multiple directories/domains)=2C= can I use the gssapi authtication of hosts in dc=3Dexample=2Cdc=3Dnet?&nbs= p=3B Seems I sould be able to since it appears that when the authorization = occurs in the database=2C the bind id is assumed to be already authenticate= d and accepted as presented with no further authentication taking place.&nb= sp=3B I'm thinking that so long as that uid is formatted into a dn listed i= n an acl=2C the matching access is applied?&nbsp=3B Am I way off base in my= thinking?&nbsp=3B Now that I have a rough workable solution I'm just tryin= g to pretty it up a bit and make the design more efficient and scalable.<BR= >&nbsp=3B<BR>Thanks<BR>&nbsp=3B<BR>Barry<BR>&nbsp=3B<BR> </div><= /body> </html>= --_2dfc1396-6cab-4ee1-b5cd-ec8dfb5286a7_--

1 0

Re: (ITS#7406) Search with scope for newer entries don't work
by quanah＠zimbra.com 09 Jan '13

09 Jan '13

--On Monday, October 01, 2012 10:20 AM +0200 Andrea Stefanello <a.stefanello(a)mclink.eu> wrote: > Thanks, > > my 2 mirror (Master-Master) server say : > > ebuild U ] net-nds/openldap-2.4.30::gentoo [2.4.23-r1::MC-link-NOC] > > upgrading to 2.4.30 doesn't cause problems , its correct ? > > Can i upgrade quietly or i have to do some pre-operations ? You should be able to upgrade in place w/o issue. I would suggest OpenLDAP 2.4.33 instead of 2.4.30 though. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#7434) idassert-bind fails after restarting slapd
by quanah＠zimbra.com 09 Jan '13

09 Jan '13

--On Tuesday, December 04, 2012 4:37 PM +0000 blance3459(a)hotmail.com wrote: > --_e0f270ad-e1a3-48b6-986f-f9f11dfd57c0_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Quanah=2C=20 > =20 > I finally got back around to working on this over the last couple of > days. = Where I'm at with my project is: I have two servers (virtual > machines)=2C = named master and replica=2C with slapd configured with my > directory inform= ation and single-master replication between them. =20 > I created a Kerberos realm and various principals in open ldap. =20 > Replication access is authenticated using sasl/gssapi with the slapd > princ= ipal=2C ldap/replica.example.net. =20 > k5start has been added to system startup to buid the credential cache > for = slapd. Hi Barry, Two things: Please use an email client that can create emails that are readable, instead of whatever it is you're doing now. ;) Second, you never answered about trying a current release of OpenLDAP. I pointed out two bits that may have resulted in your situation being fixed. Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7476) patch for ldap_pvt_connect
by hyc＠symas.com 09 Jan '13

09 Jan '13

codehero(a)gmail.com wrote: > Full_Name: David Bender > Version: 2.4.32 > OS: Linux > URL: > Submission from: (NULL) (96.236.148.85) > > > ldap_pvt_connect() in libldap/os-ip.c fails intermittently when the calling > program also runs child processes. The connect() call fails with EINTR, but no > effort is made to retry the connect(). The following patches add support for > retrying in this case, as well as toggling the behaviour with LDAP_OPT_RESTART. > > > Patches are available and should be applied in this order (applied to current > HEAD): > > https://github.com/benegon/openldap/commit/8e4fee39bfccaa3dd15179fb6451d397… > https://github.com/benegon/openldap/commit/991941e3b51fea44d5f123f24a0f3206… Thanks for the patches, now in master. -- -- 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#7488) back-mdb: corrupt indices with bad toolthreads setting
by quanah＠OpenLDAP.org 09 Jan '13

09 Jan '13

Full_Name: Quanah Gibson-Mount Version: RE24 12/11/2012 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) When running slapadd in quick mode, with a toolthreads setting higher than 2, index generation is broken, breaking the ability to search the resulting database with indexed attributes.

1 0

Re: (ITS#7486) slapo-dynlist.5 enhancement request
by masarati＠aero.polimi.it 08 Jan '13

08 Jan '13

Clarifications added to HEAD, please check. Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

Re: (ITS#7487) memberof & mirrormode with delta-syncrepl crashing when using dynamic configuration
by afrunning＠gmail.com 08 Jan '13

08 Jan '13

> Indeed, sm_op == SLAP_MOD_SOFTDEL, as I inferred from syncrepl code, > thanks for the feedback. Internal special modification types should be > handled now in HEAD code. Could you pull it from git and test, please? > Instructions here <http://www.openldap.org/software/repo.html>. Looks good! I can add and remove users to groups in my setup without issue. Thanks for your quick response. Al

1 0

Re: (ITS#7487) memberof & mirrormode with delta-syncrepl crashing when using dynamic configuration
by masarati＠aero.polimi.it 08 Jan '13

08 Jan '13

>> > slapd: memberof.c:1465: memberof_res_modify: Assertion `0' failed. >> >> If you have the core file handy, or if you can quickly reproduce the >> problem, could you print the value of ml->sml_mod, i.e. from within gdb: >> >> (to see the backtrace) >> $ bt >> (where <x> is the number of the frame of function memberof_res_modify) >> $ f <x> >> (to see the value) >> $ print ml->sml_mod > > (gdb) bt > #0 0x00000032b04328a5 in raise () from /lib64/libc.so.6 > #1 0x00000032b0434085 in abort () from /lib64/libc.so.6 > #2 0x00000032b042ba1e in __assert_fail_base () from /lib64/libc.so.6 > #3 0x00000032b042bae0 in __assert_fail () from /lib64/libc.so.6 > #4 0x00000000004fc989 in memberof_res_modify (op=0x7fffebffe330, > rs=<value optimized out>) at memberof.c:1465 > #5 0x000000000042f91e in slap_response_play (op=0x7fffebffe330, > rs=0x7fffebffd620) at result.c:507 > #6 0x00000000004304a9 in send_ldap_response (op=0x7fffebffe330, > rs=0x7fffebffd620) at result.c:582 > #7 0x000000000043119c in slap_send_ldap_result (op=0x7fffebffe330, > rs=0x7fffebffd620) at result.c:860 > #8 0x00000000004b4035 in mdb_modify (op=0x7fffebffe330, > rs=0x7fffebffd620) at modify.c:656 > #9 0x00000000004845a7 in overlay_op_walk (op=0x7fffebffe330, > rs=0x7fffebffd620, which=op_modify, oi=0x963b20, on=0x0) at > backover.c:671 > #10 0x0000000000484f87 in over_op_func (op=0x7fffebffe330, rs=<value > optimized out>, which=<value optimized out>) at backover.c:723 > #11 0x000000000047738d in syncrepl_message_to_op (si=0x9636f0, > op=0x7fffebffe330, msg=<value optimized out>) at syncrepl.c:2318 > #12 0x000000000047b1bf in do_syncrep2 (op=0x7fffebffe330, si=0x9636f0) > at syncrepl.c:986 > #13 0x00000000004809c2 in do_syncrepl (ctx=<value optimized out>, > arg=0x963ee0) at syncrepl.c:1523 > #14 0x00000000004210e1 in connection_read_thread (ctx=0x7fffebffeab0, > argv=<value optimized out>) at connection.c:1288 > #15 0x00000000005230a0 in ldap_int_thread_pool_wrapper > (xpool=0x8b7640) at tpool.c:688 > #16 0x00000032b0807851 in start_thread () from /lib64/libpthread.so.0 > #17 0x00000032b04e811d in clone () from /lib64/libc.so.6 > (gdb) f 4 > #4 0x00000000004fc989 in memberof_res_modify (op=0x7fffebffe330, > rs=<value optimized out>) at memberof.c:1465 > 1465 assert( 0 ); > (gdb) print ml->sml_mod > $1 = {sm_desc = 0x9640f0, sm_values = 0x7fffe00009b0, sm_nvalues = > 0x7fffe00009d0, sm_numvals = 1, sm_op = 4097, sm_flags = 0, sm_type = > {bv_len = 48, > bv_val = 0x70756f72673d6e63 <Address 0x70756f72673d6e63 out of > bounds>}} > (gdb) Indeed, sm_op == SLAP_MOD_SOFTDEL, as I inferred from syncrepl code, thanks for the feedback. Internal special modification types should be handled now in HEAD code. Could you pull it from git and test, please? Instructions here <http://www.openldap.org/software/repo.html>. Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

Re: (ITS#7487) memberof & mirrormode with delta-syncrepl crashing when using dynamic configuration
by afrunning＠gmail.com 08 Jan '13

08 Jan '13

> > slapd: memberof.c:1465: memberof_res_modify: Assertion `0' failed. > > If you have the core file handy, or if you can quickly reproduce the > problem, could you print the value of ml->sml_mod, i.e. from within gdb: > > (to see the backtrace) > $ bt > (where <x> is the number of the frame of function memberof_res_modify) > $ f <x> > (to see the value) > $ print ml->sml_mod (gdb) bt #0 0x00000032b04328a5 in raise () from /lib64/libc.so.6 #1 0x00000032b0434085 in abort () from /lib64/libc.so.6 #2 0x00000032b042ba1e in __assert_fail_base () from /lib64/libc.so.6 #3 0x00000032b042bae0 in __assert_fail () from /lib64/libc.so.6 #4 0x00000000004fc989 in memberof_res_modify (op=0x7fffebffe330, rs=<value optimized out>) at memberof.c:1465 #5 0x000000000042f91e in slap_response_play (op=0x7fffebffe330, rs=0x7fffebffd620) at result.c:507 #6 0x00000000004304a9 in send_ldap_response (op=0x7fffebffe330, rs=0x7fffebffd620) at result.c:582 #7 0x000000000043119c in slap_send_ldap_result (op=0x7fffebffe330, rs=0x7fffebffd620) at result.c:860 #8 0x00000000004b4035 in mdb_modify (op=0x7fffebffe330, rs=0x7fffebffd620) at modify.c:656 #9 0x00000000004845a7 in overlay_op_walk (op=0x7fffebffe330, rs=0x7fffebffd620, which=op_modify, oi=0x963b20, on=0x0) at backover.c:671 #10 0x0000000000484f87 in over_op_func (op=0x7fffebffe330, rs=<value optimized out>, which=<value optimized out>) at backover.c:723 #11 0x000000000047738d in syncrepl_message_to_op (si=0x9636f0, op=0x7fffebffe330, msg=<value optimized out>) at syncrepl.c:2318 #12 0x000000000047b1bf in do_syncrep2 (op=0x7fffebffe330, si=0x9636f0) at syncrepl.c:986 #13 0x00000000004809c2 in do_syncrepl (ctx=<value optimized out>, arg=0x963ee0) at syncrepl.c:1523 #14 0x00000000004210e1 in connection_read_thread (ctx=0x7fffebffeab0, argv=<value optimized out>) at connection.c:1288 #15 0x00000000005230a0 in ldap_int_thread_pool_wrapper (xpool=0x8b7640) at tpool.c:688 #16 0x00000032b0807851 in start_thread () from /lib64/libpthread.so.0 #17 0x00000032b04e811d in clone () from /lib64/libc.so.6 (gdb) f 4 #4 0x00000000004fc989 in memberof_res_modify (op=0x7fffebffe330, rs=<value optimized out>) at memberof.c:1465 1465 assert( 0 ); (gdb) print ml->sml_mod $1 = {sm_desc = 0x9640f0, sm_values = 0x7fffe00009b0, sm_nvalues = 0x7fffe00009d0, sm_numvals = 1, sm_op = 4097, sm_flags = 0, sm_type = {bv_len = 48, bv_val = 0x70756f72673d6e63 <Address 0x70756f72673d6e63 out of bounds>}} (gdb) Regards, Al

1 0

Re: (ITS#7487) memberof & mirrormode with delta-syncrepl crashing when using dynamic configuration
by masarati＠aero.polimi.it 08 Jan '13

08 Jan '13

> Full_Name: Al F > Version: 2.4.33 > OS: Redhat 6.3 x64 > URL: ftp://ftp.openldap.org/incoming/openldap-af.zip > Submission from: (NULL) (74.123.146.10) > > > I'm having an issue with mirrormode replication (via delta syncrepl) and > the > memberof overlay when using dynamic configuration. When a group member is > deleted on the first instance, slapd on the second instance is crashing > with the > following error (as seen from running slapd with -d-1): > > slapd: memberof.c:1465: memberof_res_modify: Assertion `0' failed. If you have the core file handy, or if you can quickly reproduce the problem, could you print the value of ml->sml_mod, i.e. from within gdb: (to see the backtrace) $ bt (where <x> is the number of the frame of function memberof_res_modify) $ f <x> (to see the value) $ print ml->sml_mod Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7487) memberof & mirrormode with delta-syncrepl crashing when using dynamic configuration
by afrunning＠gmail.com 08 Jan '13

08 Jan '13

Full_Name: Al F Version: 2.4.33 OS: Redhat 6.3 x64 URL: ftp://ftp.openldap.org/incoming/openldap-af.zip Submission from: (NULL) (74.123.146.10) I'm having an issue with mirrormode replication (via delta syncrepl) and the memberof overlay when using dynamic configuration. When a group member is deleted on the first instance, slapd on the second instance is crashing with the following error (as seen from running slapd with -d-1): slapd: memberof.c:1465: memberof_res_modify: Assertion `0' failed. If I disable either memberof or mirrormode, the change replicates correctly. If I use an identical static configuration file instead of a dynamic configuration, the change replicates correctly. This behavior happens on both bdb and mdb backends. I have setup a very basic test and have included the configurations for server1 and server2 in both static and dynamic configuration (both running on the same machine, just different ports), ldif file to populate tree (ldifs/basic.ldif), as well as the ldif file to crash the second node (ldifs/crash.ldif). the zip file contents (ftp://ftp.openldap.org/incoming/openldap-af.zip) are: openldap-af/ openldap-af/bt full.txt (output from gdb bt full) openldap-af/config.txt (output from source compilation) openldap-af/debug level logging.txt (output of the crash while running debug logs) openldap-af/ldifs/basic.ldif (the basic tree) openldap-af/ldifs/crash.ldif (ldif file applied to cause the failure) openldap-af/server1slapd.conf (server1's static configuration) openldap-af/server1slapd.d/* (server1's dynamic configuration - produced directly from static configuration with slaptest) openldap-af/server2slapd.conf (server2's static configuration) openldap-af/server2slapd.d/* (server2's dynamic configuration - produced directly from static configuration with slaptest) openldap-af/thread apply all bt.txt (output from gdb thread apply all bt) version & config information: OL_PACKAGE="OpenLDAP" OL_MAJOR=2 OL_MINOR=4 OL_PATCH=33 OL_API_INC=20433 OL_API_LIB_RELEASE=2.4 OL_API_LIB_VERSION=10:5:8 OL_VERSION=2.4.33 OL_TYPE=Release OL_STRING="OpenLDAP 2.4.33-Release" OL_RELEASE_DATE="2012/10/10" Red Hat Enterprise Linux Server release 6.3 (Santiago) kernel 2.6.32-279.19.1.el6.x86_64 running on a vmware esx host, with a single AMD Opteron(tm) Processor 6134. 4Gig RAM. please let me know if you need any more information. This is my first time using gdb, so I appologize if I missed something critical.

1 0

(ITS#7486) slapo-dynlist.5 enhancement request
by tedcheng＠symas.com 07 Jan '13

07 Jan '13

Full_Name: Ted C. Cheng Version: trunk OS: Linux/Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.174.253.197) This is an enhancement request to the slapo-dynlist.5 man page to call out the fact that searches with filters based on dynamic lists/groups attributes will not produce the desired results: Dynamic lists/groups, as their names suggest, are constructed dynamically when the entries are to be returned. Their attributes and values are not available at the time when searches based on filters are performed. As a result, searches with dynamic lists/groups attributes in filters will not produce the desired results.

1 0

(ITS#7485) libmdb key/data limits not checked/documented.
by h.b.furuseth＠usit.uio.no 06 Jan '13

06 Jan '13

Full_Name: Hallvard B Furuseth Version: mdb.master 057e0686303444d56f29a7bee0536e261fdf0b6a OS: Linux x86_64 URL: Submission from: (NULL) (193.69.163.163) Submitted by: hallvard mdb_put() not check for too big data. mdb_cursor_put() does not check for too big key either. Nor can I see that ldmb.h documents the limits, and there is no way to ask liblmdb what the limits are. This can write an item of size (5000000000 & 0xffffffff) or crash: MDB_val k1 = {3, "foo"}, x = {5000000000, NULL}; mdb_dbi_open(txn, NULL, MDB_CREATE, &dbi); mdb_put(txn, dbi, &k1, &x, MDB_RESERVE); Crash: MDB_val k1 = {3, "foo"}, y = {5, "xyzzy"}, z = {10000, calloc(1,10000)}; mdb_dbi_open(txn, NULL, MDB_CREATE|MDB_DUPSORT, &dbi); mdb_put(txn, dbi, &k1, &y, 0); mdb_put(txn, dbi, &k1, &z, 0); /* segfault */ Crash: MDB_val k2 = {8000, calloc(1, 8000)}, y = {5, "xyzzy"}; mdb_cursor_put(mc, &k2, &y, 0); while this gives a proper EINVAL: mdb_put(txn, dbi, &k2, &y, 0);

1 0

Re: (ITS#7462) olcPcache cannot be modified
by masarati＠aero.polimi.it 06 Jan '13

06 Jan '13

> Full_Name: Tio Teath > Version: 2.4.33 > OS: Debian GNU Linux Wheezy > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (178.172.239.4) > > > I'm getting 'LDAP: error code 80 - cannot delete olcPcache' while I'm > trying to > perform olcPcache modification: > dn: olcOverlay={0}pcache,olcDatabase={1}ldap,cn=config > changetype: modify > replace: olcPcache > olcPcache: hdb 10000 4 500 100 > - > > I have to perform this action in case, I need to extend the number of > pcacheAttrset directives. Although the impossibility to modify olcPcache may be viewed as a bug, I have the impression that a broad class of modifications e.g. to olcPcacheTemplate are likely to invalidate an existing cache. The fix should also consider the opportunity of thrashing the whole cache, unless a clever means to only address entries associated with the olcPcacheTemplate involved in the modification is found. My 2c. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

Re: (ITS#7484) sssvlv-maxpercon(n) configuration option
by masarati＠aero.polimi.it 06 Jan '13

06 Jan '13

> Full_Name: Liam Gretton > Version: 2.4.33 > OS: SLES 11 SP 2 > URL: > Submission from: (NULL) (143.210.13.77) > > > There's a mismatch between the documentation for the sssvlv-maxpercon > option and > the actual configuration option name. > > The man page documentation for slapo-sssvlv states that the maximum number > of > concurrent paged search requests per connection option is > 'sssvlv-maxperconn'. > For an LDAP-based configuration the option is 'olcSssVlvMaxPerConn' but > for a > slapd.conf based configuration the option is 'sssvlv-maxpercon' (note only > one > 'n', not two). Good catch; should be fixed now in HEAD, please test. Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7484) sssvlv-maxpercon(n) configuration option
by liam.gretton＠leicester.ac.uk 04 Jan '13

04 Jan '13

Full_Name: Liam Gretton Version: 2.4.33 OS: SLES 11 SP 2 URL: Submission from: (NULL) (143.210.13.77) There's a mismatch between the documentation for the sssvlv-maxpercon option and the actual configuration option name. The man page documentation for slapo-sssvlv states that the maximum number of concurrent paged search requests per connection option is 'sssvlv-maxperconn'. For an LDAP-based configuration the option is 'olcSssVlvMaxPerConn' but for a slapd.conf based configuration the option is 'sssvlv-maxpercon' (note only one 'n', not two).

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs