openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#8176) the olcRootDSE attributeType should be Single Value
by michael＠stroeder.com 22 Jun '15

22 Jun '15

elecharny(a)gmail.com wrote: > What's the rational for having the RootDSE spread in many files though ? If you have several packages which want to add something to the rootDSE you can spread this across several files. The same rationale like for /etc/cron.d, /etc/sudoers.d, ... Ciao, Michael.

1 0

Re: (ITS#8176) the olcRootDSE attributeType should be Single Value
by elecharny＠gmail.com 22 Jun '15

22 Jun '15

Ah, my bad then. What's the rational for having the RootDSE spread in many files though ?

1 0

Re: (ITS#8176) the olcRootDSE attributeType should be Single Value
by hyc＠symas.com 22 Jun '15

22 Jun '15

elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.40 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.195.127.200) > > > The olcRootDSE AttributeType is currently a Multiple Value AttributeType, which > is not necessary : it stores a file name which contains the RootDSE entry. It's > unlikely that we store more than one value in it, and the code currently reads > only one value anyway. Not true, the code will read multiple values. Multiple files' contents will be concatenated. -- -- 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#8176) the olcRootDSE attributeType should be Single Value
by elecharny＠apache.org 22 Jun '15

22 Jun '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.195.127.200) The olcRootDSE AttributeType is currently a Multiple Value AttributeType, which is not necessary : it stores a file name which contains the RootDSE entry. It's unlikely that we store more than one value in it, and the code currently reads only one value anyway.

1 0

(ITS#8175) Some more missing parameter in the Configuration man page
by elecharny＠apache.org 19 Jun '15

19 Jun '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.195.127.200) The following options are not listed for the olcDisallows configuration parameter in the slapd-config man page : * proxy_authz_non_critical * dontusecopy_non_critical

1 0

Re: (ITS#8173) back-ldap slapd crash segfault
by hyc＠symas.com 18 Jun '15

18 Jun '15

adrian.raemy(a)vtg.admin.ch wrote: > Full_Name: Adrian Raemy > Version: 2.4.40 > OS: SLES 11 SP3 > URL: > Submission from: (NULL) (193.5.216.100) > > > Hi, > > The Openldap backend "ldap" slapd crashing under heavy load. > Tested with 2.4.26 and also 2.4.40. > We get an segfault: > Jun 18 00:00:36 serverxx1 kernel: [9079587.309374] slapd[6193]: segfault at 40 > ip 00007f184cf6b2c6 sp 00007f1838ff85c0 error 4 in slapd[7f184cdda000+26c000] > Jun 18 09:40:12 serverxx1 kernel: [9114294.985888] slapd[10309]: segfault at 40 > ip 00007f3b31f492c6 sp 00007f3b1f7f55c0 error 4 in slapd[7f3b31db8000+26c000] > Jun 18 12:38:29 serverxx1 kernel: [9124971.271300] slapd[15868]: segfault 4 40 > ip 00007fc1555512c6 sp 00007fc141ffa5c0 error 4 in slapd[7fc1553c0000+26c000] > We can't provide a core dump of the slapd due to confidentially restrictions. Then we cannot help you. I suggest you test with the 2.4.41 release candidate and see if the same crash still occurs. -- -- 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#8174) mdb_drop(,MAIN_DBI,) leaks pages of named DBs
by hyc＠symas.com 18 Jun '15

18 Jun '15

h.b.furuseth(a)usit.uio.no wrote: > What to do with open DBIs of named databases: > > (A) Fail if there are any. This would be best. -- -- 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#8174) mdb_drop(,MAIN_DBI,) leaks pages of named DBs
by h.b.furuseth＠usit.uio.no 18 Jun '15

18 Jun '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.14 OS: URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard mdb_drop(,MAIN_DBI,) leaks pages of named DBs It does not drop the pages of named DBs, but it does drop the mainDB pages which refer to these DBs. 3 possible fixes + 1 hybrid (from old IRC chats): (1) Fail if there are named DBs. The minimal fix. (2) Reset both metapages. Reject new write txns while old readers remain. Needs MDB_DATA_{VERSION/FORMAT} > 1. (3) Recursive: Drop named DBs too. (4) Try (3), but fail when that gets complicated. What to do with open DBIs of named databases: (A) Fail if there are any. (B) Close them, like a recursive mdb_drop() would do. The user must likely "stop the world" first. (C) Keep them open but useless, as when another process dropped the DB. All the user can do is close them. API: I think all variants but "fail" can be dangerous and/or possibly surprising, and should all be options - even if we only implement one choice. I.e. fail if there are named DBs/DBIs and no options say what to do about it. Would that be a new mdb_drop2() function? It's unfortunate to change the meaning of mdb_drop() param 'del' > 1. OTOH 'del' > 1 has been an error since 0.9.7, so I'm OK with it. Details: (2) Reset both metapages: mdb_drop() merely sets a txn flag so mdb_txn_commit() will reset the metapages. The flag also prevents most operations, like MDB_TXN_ERROR does. We can include it in MDB_TXN_BLOCKED from my "mdb/safer" branch. An MDB_meta flag then tells mdb_txn_renew0() to re-commit the metapage if Commit failed to write the 2nd metapage, and to reject writers when too old readers exist. mdb_txn_renew0() needs a flags parameter, so it can react to the new txn flags MDB_NO[META]SYNC. The caller cannot set them before mdb_txn_renew0(), since txn == me_txn0. (3) Recursive drop: mdb_drop0() must locate and use the up-to-date mt_dbs[] record when it sees a named DB record in the mainDB. Either: - Search mt_dbxs[]. Then drop is O(n*n) unless we make mt_dbxs[] a tree/hash first. OK for most users, but a few people have said they use lots of DBs. - Or mdb_drop() can first save dirty named DBs, like Commit does. Wasteful, but less new code. To make mdb_drop0() recursive: Factor out the DB-walking code in mdb_env_cwalk(), at least for non-stale DBIs? If searching mdb_dbxs[] for DBIs, it can also call mdb_drop(). Except it should not close any DBIs until everything succeeds. (4) Recursive or fail: Fail if there are dirty named DB (so mdb_drop0 need not searchA0Amt_dbxs), or maybe non-DB_STALE ones (so it need not reset DB records), or if called in a nested txn with DB_NEW DBIs or stuff like that (because it makes my head hurt to try to figure it out). Well, it looks much safer now than before we had mt_dbiseqs[]. Maybe dirty DBs are the only problem. (B) Close DBIs: Simple, but makes drop(MAIN DBI) a "stop the world" operation. (C) Keep DBIs open: Reset mt_dbs[] contents and mark the DBIs as DB_STALE, then attempts to use them will fail. Probably just a TODO item until there is a general "drop DB without closing it" option. Related issues: There is no way to fully reset the main DB (including flags) and close it. I think that should be an option too - someday. Would need the main DBI to not be so special. E.g. currently DB_NEW doesn't apply to it. Until then, that's just something to think about with the API for the rest of this stuff. The cleanest API would be if the main DBI is just like other DBIs, instead of the default "do not close it" being different. IIRC it's possible for the user to overwrite/delete a named DB as plain data and maybe use plain data as a named DB. I have an old branch to catch that, which we were a bit nervious about but should be fine.

1 0

(ITS#8173) back-ldap slapd crash segfault
by adrian.raemy＠vtg.admin.ch 18 Jun '15

18 Jun '15

Full_Name: Adrian Raemy Version: 2.4.40 OS: SLES 11 SP3 URL: Submission from: (NULL) (193.5.216.100) Hi, The Openldap backend "ldap" slapd crashing under heavy load. Tested with 2.4.26 and also 2.4.40. We get an segfault: Jun 18 00:00:36 serverxx1 kernel: [9079587.309374] slapd[6193]: segfault at 40 ip 00007f184cf6b2c6 sp 00007f1838ff85c0 error 4 in slapd[7f184cdda000+26c000] Jun 18 09:40:12 serverxx1 kernel: [9114294.985888] slapd[10309]: segfault at 40 ip 00007f3b31f492c6 sp 00007f3b1f7f55c0 error 4 in slapd[7f3b31db8000+26c000] Jun 18 12:38:29 serverxx1 kernel: [9124971.271300] slapd[15868]: segfault 4 40 ip 00007fc1555512c6 sp 00007fc141ffa5c0 error 4 in slapd[7fc1553c0000+26c000] OpenLdap Proxy Server has: Type = VM Guest mem = 4GB CPU = 2 Cores = 2 We don't get any other errors or warning before, CPU load and MEM etc all is green and OK. Also files open etc is set unlimited. Scenario: Linux/ Unix Clients and Applications via ssl start_tls and ssl over Openldap Proxy using on the Proxy the backend "ldap" to proxing to Openldap Master. When the Proxy gets heavy load due to activity from clients and Applications, the slapd crashes unexpected with the above slapd segfault. This is only happen with the backend-ldap. The Openldap Master doesn't crash and is stable at all. So it must be the backend ldap which has the problem. We perform Search-, Modify and add/remove Operations. So the entire funtionality will be used. Only with lot of searches sent over proxy to master we couldn't reproduce the segfault. It needs realy a heavy load generated (read/itite- modify operations at all) i guess to reproduce this. We don't have this possibility in our very restricted environment. We can't provide a core dump of the slapd due to confidentially restrictions. We would test with the backend "meta" but this backend doesn't support the "extended operations" like "LDAP Password Modify Extended Operation". So we have only two possibilities, the one that ldap backend will be fixed or the extended operations at meta backend will be added. Please, we need help/ a fix asap, e e authentication at all is compromised and the slapd crashes often on the Openldap Proxy. Thanks for your help

1 0

Re: (ITS#8172) RFE: back-sock CONTINUE to get modified parameters
by michael＠stroeder.com 14 Jun '15

14 Jun '15

Another important use-case is rewriting the bind-DN of a simple bind request without using slapo-rwm (because slapo-rwm often seg faults).

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs