- openldap-bugs - openldap.org

Re: (ITS#7581) adding meta backend in cn=config with ldapadd / ldapmodify
by hyc＠symas.com 23 May '13

23 May '13

dcoutadeur(a)linagora.com wrote: > Full_Name: dcoutadeur > Version: 2.4.35 / git > OS: openSuse 11.3 x86_64 > URL: > Submission from: (NULL) (80.67.162.201) > > > I apologize in advance if this is not considered as a bug, but I thought this > ticket should help the community anyway... > > The problem is that it seems impossible to add meta backend in cn=config thanks > to ldapadd / ldapmodify clients. I thought the major interest for cn=config was > precisely to let administrators change the configuration in a remote way, but > maybe new database configuration is an exception ? Seems we need some rework here to allow this case. Currently bconfig assumes that the olcDatabaseConfig entry is sufficient by itself, and any child entries underneath are just optional. It doesn't handle the case where the olcDatabaseConfig entry is basically an incomplete config. > > Here are the technical elements : > > Content of meta.ldif : > > dn: olcDatabase={2}meta,cn=config > objectClass: olcDatabaseConfig > objectClass: olcMetaConfig > olcDatabase: {2}meta > olcSuffix: dc=foo,dc=com > > debug information in slapd, after the command : > ldapadd -H "ldap://localhost:389" -D "cn=config" -W -f meta.ldif > > 518220f1 conn=1002 op=1 ADD dn="olcDatabase={2}meta,cn=config" > 518220f1 meta_back_db_open: no targets defined > 518220f1 backend_startup_one (type=meta, suffix="dc=foo,dc=com"): bi_db_open > failed! (1) > 518220f1 olcSuffix: value #0: <olcSuffix> failed startup (dc=foo,dc=com)! > > However, I can add this entry via slapadd : > > dn: olcDatabase={2}meta,cn=config > objectClass: olcDatabaseConfig > objectClass: olcMetaConfig > olcDatabase: {2}meta > olcSuffix: dc=foo,dc=com > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcSyncUseSubentry: FALSE > olcMonitoring: FALSE > olcDbOnErr: continue > olcDbPseudoRootBindDefer: TRUE > olcDbSingleConn: FALSE > olcDbUseTemporaryConn: FALSE > olcDbConnectionPoolMax: 16 > olcDbBindTimeout: 100000 > olcDbCancel: abandon > olcDbChaseReferrals: FALSE > olcDbNoRefs: FALSE > olcDbNoUndefFilter: FALSE > olcDbNretries: 10 > olcDbProtocolVersion: 3 > olcDbRebindAsUser: FALSE > olcDbSessionTrackingRequest: FALSE > olcDbTFSupport: no > structuralObjectClass: olcMetaConfig > entryUUID: cf8afa3a-a284-4ac8-b60e-9431b0807ed4 > creatorsName: cn=config > createTimestamp: 20130430162302Z > entryCSN: 20130430162302.509672Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20130430162302Z > > The fact is I don't have a metatarget configuration, because this is a subentry > of olcDatabase={2}meta,cn=config, thus I must add the latter entry first. > > > Also notice that I can't do a slapadd with just the meta configuration. (the > ldif above). If I do this, I have an error : > slapadd: could not add entry dn="olcDatabase={2}meta,cn=config" (line=1): > autocreation of "olcDatabase={-1}frontend" failed > > I had to make a backup of the full configuration, and then add the meta > configuration and import the resulting file. > > -- -- 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#7605) Configuration entries (under cn=config) does not allow 'objectclass' attribute modification to include full object classes hierarchy
by pa＠marcelot.net 23 May '13

23 May '13

On 23 mai 2013, at 16:31, Howard Chu <hyc(a)symas.com> wrote: > pa(a)marcelot.net wrote: >> Full_Name: Pierre-Arnaud Marcelot >> Version: 2.4.35 >> OS: Linux Mint >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (78.226.4.211) >> >> >> Hi, >> >> It looks like it's not possible to modify the 'objectClass' attribute of >> configuration entries. > > Correct. The config DIT has very rigid schema and layout rules. Indeed. >> I have some code generating entries for OpenLDAP configuration from a UI utility >> and updating existing configuration entries in DIT. >> This code generates entries with the 'objectClass' attribute containing the full >> object class hierarchy (all the way to 'top') and not only the highest >> structural object class (which is the case of default OpenLDAP configuration). >> >> When updating the configuration in the DIT, the code then tries to complete the >> 'objectClass' attribute with the full list of object classes. >> That operations ends with "error code 53- UnwillingToPerform". > > Don't do that. Sure, that's why I have a *bad* workaround to not update the 'objectClass' attribute even if the original and my generated one don't match. Still, looking at LDAP standards, that doesn't seem to be a naughty operation at all and nothing is really wrong with the resulting entry. Regards, Pierre-Arnaud >> Here's an example on the "cn=config" entry: >> #!RESULT ERROR >> #!CONNECTION ldap://10.211.55.13:389 >> #!DATE 2013-05-22T14:56:03.039 >> #!ERROR [LDAP: error code 53 - UnwillingToPerform] >> dn: cn=config >> changetype: modify >> replace: objectClass >> objectClass: olcConfig >> objectClass: olcGlobal >> objectClass: top >> - >> >> > > > -- > -- 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#7605) Configuration entries (under cn=config) does not allow 'objectclass' attribute modification to include full object classes hierarchy
by hyc＠symas.com 23 May '13

23 May '13

pa(a)marcelot.net wrote: > Full_Name: Pierre-Arnaud Marcelot > Version: 2.4.35 > OS: Linux Mint > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (78.226.4.211) > > > Hi, > > It looks like it's not possible to modify the 'objectClass' attribute of > configuration entries. Correct. The config DIT has very rigid schema and layout rules. > I have some code generating entries for OpenLDAP configuration from a UI utility > and updating existing configuration entries in DIT. > This code generates entries with the 'objectClass' attribute containing the full > object class hierarchy (all the way to 'top') and not only the highest > structural object class (which is the case of default OpenLDAP configuration). > > When updating the configuration in the DIT, the code then tries to complete the > 'objectClass' attribute with the full list of object classes. > That operations ends with "error code 53- UnwillingToPerform". Don't do that. > Here's an example on the "cn=config" entry: > #!RESULT ERROR > #!CONNECTION ldap://10.211.55.13:389 > #!DATE 2013-05-22T14:56:03.039 > #!ERROR [LDAP: error code 53 - UnwillingToPerform] > dn: cn=config > changetype: modify > replace: objectClass > objectClass: olcConfig > objectClass: olcGlobal > objectClass: top > - > > -- -- 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#7605) Configuration entries (under cn=config) does not allow 'objectclass' attribute modification to include full object classes hierarchy
by pa＠marcelot.net 23 May '13

23 May '13

Full_Name: Pierre-Arnaud Marcelot Version: 2.4.35 OS: Linux Mint URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.226.4.211) Hi, It looks like it's not possible to modify the 'objectClass' attribute of configuration entries. I have some code generating entries for OpenLDAP configuration from a UI utility and updating existing configuration entries in DIT. This code generates entries with the 'objectClass' attribute containing the full object class hierarchy (all the way to 'top') and not only the highest structural object class (which is the case of default OpenLDAP configuration). When updating the configuration in the DIT, the code then tries to complete the 'objectClass' attribute with the full list of object classes. That operations ends with "error code 53- UnwillingToPerform". Here's an example on the "cn=config" entry: #!RESULT ERROR #!CONNECTION ldap://10.211.55.13:389 #!DATE 2013-05-22T14:56:03.039 #!ERROR [LDAP: error code 53 - UnwillingToPerform] dn: cn=config changetype: modify replace: objectClass objectClass: olcConfig objectClass: olcGlobal objectClass: top -

1 0

(ITS#7596)
by nzipsi＠gmail.com 23 May '13

23 May '13

--bcaec53af1e4a1ae7704dd5c4ab8 Content-Type: text/plain; charset=UTF-8 Tested my idea about patching it, and it didn't work. There's something, somewhere, that doesn't like values of 0, and so doesn't include the graceAuthN warning in the returned password control if ngut is 0. I still believe what I have described above is an error, but I don't know enough about C or the internal structure of OpenLDAP to figure out why it's not working, and how (or even if) it can be fixed. --bcaec53af1e4a1ae7704dd5c4ab8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Tested my idea about patching it, and it didn't work. = There's something, somewhere, that doesn't like values of 0, and so= doesn't include the graceAuthN warning in the returned password contro= l if ngut is 0. I still believe what I have described above is an error, bu= t I don't know enough about C or the internal structure of OpenLDAP to = figure out why it's not working, and how (or even if) it can be fixed.<= /div> --bcaec53af1e4a1ae7704dd5c4ab8--

1 0

Re: (ITS#7597) migration of sunone 5.2 to openldap 2.4
by quanah＠zimbra.com 23 May '13

23 May '13

--On Tuesday, May 21, 2013 8:38 AM +0000 univadisitisteam(a)hcl.com wrote: > Full_Name: venkatesh > Version: 2.4 > OS: RH5.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (155.91.28.231) > > > HI Team, > > We have a requirement for migrating existing Sun One 5.2 DS to open ldap > 2.4 Authentication.Please guide me how to do this migration. The ITS system is for reporting bugs with OpenLDAP. For migration help, I would advise you contact a company such as Symas (http://www.symas.com) that specializes in helping people with such migrations. You could also try asking for general help on -technical, but results may vary. This ITS will be closed. --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

(ITS#7604) back-mdb abort after searching modrdn'd enry
by quanah＠OpenLDAP.org 23 May '13

23 May '13

Full_Name: Quanah Gibson-Mount Version: RE24 5/14/2013 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) Searching on an entry that has been renamed via modrdn can trigger an abort. It appears that modrdn periodically fails causing random corruption in the db.

1 0

Re: (ITS#7448) "assertion failed" in MDB
by quanah＠zimbra.com 22 May '13

22 May '13

--On Wednesday, May 22, 2013 9:39 PM +0000 dhawes(a)vt.edu wrote: > On Wed, Nov 21, 2012 at 1:16 PM, <hyc(a)symas.com> wrote: >> More information is needed than this. Your stack traces aren't even >> complete. What was the workload leading up to this? Give us a sample >> configuration that reproduces the assert. > > I came across what looks like this issue today. Let's see if I can > provide more info. > > I noticed one of my test machines (2.4.35) had crashed overnight. > Unfortunately, I had neglected to set ulimit -c, so I had no core dump > to work with. Upon restarting, however, I got the following: > > slapd: ./../../../libraries/liblmdb/mdb.c:4025: mdb_page_search_root: > Assertion `(((mp)->mp_pb.pb.pb_lower - ((unsigned) __builtin_offsetof > (MDB_page, mp_ptrs))) >> 1) > 1' failed. > > A backtrace shows that this occurred during an accesslog_purge(). The > backtrace is at the end of this email. This is ITS#7536. There were more fixes for it in RE24 after 2.4.35 was released. --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#7448) "assertion failed" in MDB
by dhawes＠vt.edu 22 May '13

22 May '13

On Wed, Nov 21, 2012 at 1:16 PM, <hyc(a)symas.com> wrote: > More information is needed than this. Your stack traces aren't even complete. > What was the workload leading up to this? Give us a sample configuration that > reproduces the assert. I came across what looks like this issue today. Let's see if I can provide more info. I noticed one of my test machines (2.4.35) had crashed overnight. Unfortunately, I had neglected to set ulimit -c, so I had no core dump to work with. Upon restarting, however, I got the following: slapd: ./../../../libraries/liblmdb/mdb.c:4025: mdb_page_search_root: Assertion `(((mp)->mp_pb.pb.pb_lower - ((unsigned) __builtin_offsetof (MDB_page, mp_ptrs))) >> 1) > 1' failed. A backtrace shows that this occurred during an accesslog_purge(). The backtrace is at the end of this email. The setup I have is a simple accesslog that records binds: ##### slapd.conf ##### ... database mdb suffix "cn=authstats" directory /apps/local/openldap-2.4.35/var/openldap-data/authstats maxsize 17179869184 dbnosync rootdn cn=manager,dc=vt,dc=edu index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart checkpoint 1024 10 overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE ... # dc=vt,dc=edu overlay accesslog logdb "cn=authstats" logops bind logpurge 01+00:00 0+08:00 ... ##### If I comment out the logpurge line, slapd starts without incident, cn=authstats is queryable, and new entries are logged. If I slapcat cn=authstats, remove the cn=authstats .mdb files, and slapadd everything back, upon startup the logpurge works as expected. If I move the original .mdb files back, the assert fails again. I'm attempting to reproduce this starting with an empty accesslog. I have so far been unsuccessful. I do have the original .mdb files if they may be helpful (though they are around 1G). One thing to note with the following backtrace is that the accesslog_purge() line number will be incorrect, as I have patched it to record connection info (like ITS#7345). None of this affects accesslog_purge(), though I can run these tests without the patch if necessary. ##### backtrace ##### Program received signal SIGABRT, Aborted. [Switching to Thread 0x7ff7f1722700 (LWP 1576)] 0x00007ffff66b28a5 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install db4-4.7.25-17.el6.x86_64 glibc-2.12-1.107.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6_4.2.x86_64 libcom_err-1.41.12-14.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-27.el6_4.2.x86_64 zlib-1.2.3-29.el6.x86_64 #0 0x00007ffff66b28a5 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x00007ffff66b4085 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00007ffff66aba1e in __assert_fail_base () from /lib64/libc.so.6 No symbol table info available. #3 0x00007ffff66abae0 in __assert_fail () from /lib64/libc.so.6 No symbol table info available. #4 0x0000000000511836 in mdb_page_search_root (mc=0x7ff7e01023f8, key=0x0, modify=0) at ./../../../libraries/liblmdb/mdb.c:4025 node = 0x8 i = 0 mp = 0x7ff7e03c9000 rc = 0 __PRETTY_FUNCTION__ = "mdb_page_search_root" #5 0x0000000000517839 in mdb_node_move (csrc=0x7ff7f1720750, cdst=0x7ff7e01023f8) at ./../../../libraries/liblmdb/mdb.c:5988 snum = 3 s2 = 0x7ffff31270c0 bkey = {mv_size = 4294967304, mv_data = 0x0} srcnode = 0x7ff7e03ccc18 key = {mv_size = 80, mv_data = 0x7ff7e03ccc20} data = {mv_size = 111622, mv_data = 0x7ff7e03ccc70} srcpg = 111622 mn = {mc_next = 0x7ff7f1720530, mc_orig = 0x51cb38, mc_xcursor = 0x7ff7f1720740, mc_txn = 0x7ffff31270c0, mc_dbi = 4050782896, mc_db = 0x800000008, mc_dbx = 0x7ff700000063, mc_dbflag = 0x40 <Address 0x40 out of bounds>, mc_snum = 8, mc_top = 0, mc_flags = 0, mc_pg = {0x1030, 0x0, 0x0, 0x1, 0x7000000101, 0x44ab4, 0x7ffff31270c0, 0x7ff7f1720860, 0x800000c12, 0x100000009, 0x0, 0x7ff7f17205d0, 0x51cb38, 0x7ff7f17207e0, 0x7ffff31270c0, 0xc12, 0x900000009, 0x7ff7f17208b0, 0x50ca2c, 0x300000003, 0x7ff7f17208e0, 0x11013f9a8, 0x7ff7f1720a00, 0x7ff7e01025f0, 0x0, 0x7ff7e03c0b48, 0x50cb83, 0x24188, 0x7ff7f1720ab0, 0x7ffc2a2f6000, 0xe03bfd40, 0x1}, mc_ki = {64832, 57403, 32759, 0, 1696, 61810, 32759, 0, 5899, 81, 1, 0, 9648, 57360, 32759, 0, 2736, 61810, 32759, 0, 16776, 2, 0, 0, 57296, 57403, 32759, 0, 64832, 57403, 32759, 0}} rc = 0 flags = 0 __PRETTY_FUNCTION__ = "mdb_node_move" #6 0x00000000005191b9 in mdb_rebalance (mc=0x7ff7e01023f8) at ./../../../libraries/liblmdb/mdb.c:6391 node = 0x7ff7e03c8fe8 rc = 0 minkeys = 2 ptop = 1 mn = {mc_next = 0x7ff7e03bdfd0, mc_orig = 0x7ff7e03ca010, mc_xcursor = 0x0, mc_txn = 0x7ff7e03bdfd0, mc_dbi = 4, mc_db = 0x7ff7e0102580, mc_dbx = 0x7ff7e01025b0, mc_dbflag = 0x7ff7f1720e70 "", mc_snum = 3, mc_top = 2, mc_flags = 5, mc_pg = {0x7ff7e03c6fe0, 0x7ff7e03c7ff0, 0x7ff7e03cc030, 0x7ff7e01025f0, 0x0, 0x7ff7e03cabda, 0x50cb83, 0x0, 0x100000000000, 0x44ab4, 0x7ff7e03cb020, 0x7ff7e03bdfd0, 0x7ff7e03cb020, 0x44ab4, 0x0, 0x7ff7f17208a0, 0x50cc73, 0x7ff7f1720dcc, 0x7ff7e01023f8, 0x7ffc37bf9000, 0x7ff7e03c5fd0, 0x7ff7e03ca010, 0x7ff7e03ca010, 0x7ff7e01025f0, 0xf1720b00, 0x7ff7e03cbc58, 0x50cb83, 0x3f17208b0, 0x100000024188, 0x7ffc34e0d000, 0x7ff7e03cb020, 0x7ff7e03cb884}, mc_ki = {0, 0, 12, 0, 12616, 185, 0, 0, 3090, 0, 0, 0, 2368, 61810, 0, 0, 0, 0, 0, 0, 2400, 61810, 32759, 0, 2416, 61810, 32759, 0, 0, 0, 21, 0}} __PRETTY_FUNCTION__ = "mdb_rebalance" #7 0x000000000051880d in mdb_page_merge (csrc=0x7ff7e01023f8, cdst=0x7ff7f1720a00) at ./../../../libraries/liblmdb/mdb.c:6220 rc = 0 i = 11 j = 22 srcnode = 0x7ff7e03cac8c key = {mv_size = 81, mv_data = 0x7ff7e03cac94} data = {mv_size = 0, mv_data = 0x7ff7e03cace5} nkeys = 11 __PRETTY_FUNCTION__ = "mdb_page_merge" #8 0x000000000051920f in mdb_rebalance (mc=0x7ff7e01023f8) at ./../../../libraries/liblmdb/mdb.c:6396 node = 0x7ff7e03c9c3c rc = 0 minkeys = 1 ptop = 2 mn = {mc_next = 0x7ffc2ff89ff8, mc_orig = 0x5114df, mc_xcursor = 0x0, mc_txn = 0x7ff7e03bdfd0, mc_dbi = 4, mc_db = 0x7ff7e0102580, mc_dbx = 0x7ff7e01025b0, mc_dbflag = 0x7ff7e03bfd40 "\210A\002", mc_snum = 4, mc_top = 3, mc_flags = 5, mc_pg = {0x7ff7e03c6fe0, 0x7ff7e03c7ff0, 0x7ff7e03c9000, 0x7ff7e03cb020, 0x51117c, 0x7ff7f1720c70, 0x511cf4, 0x7ff7f1720ae0, 0x200b5ca30, 0x0, 0x7ff7e01025f0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7ff7e03bdfd0, 0x7ff700000001, 0x7ff7e03be068, 0xb5c9d0, 0x7ff7e03bfca9, 0x1, 0x7ff7e03bfd40, 0x7ff7f1720cb0, 0x0, 0x0, 0x7ff7e03bdfd0, 0x7ff700000001, 0x7ff7e03be068, 0xb5c9d0, 0x7ff7e03bfca9, 0x1}, mc_ki = {0, 1, 0, 10, 3072, 61810, 32759, 0, 44982, 57404, 32759, 0, 45072, 57404, 32759, 0, 44084, 57404, 32759, 0, 988, 0, 0, 0, 15065, 63088, 32767, 0, 3008, 61810, 32759, 0}} __PRETTY_FUNCTION__ = "mdb_rebalance" #9 0x00000000005193cb in mdb_cursor_del0 (mc=0x7ff7e01023f8, leaf=0x7ff7e03cafb6) at ./../../../libraries/liblmdb/mdb.c:6424 rc = 15 #10 0x0000000000515b10 in mdb_cursor_del (mc=0x7ff7e01023f8, flags=0) at ./../../../libraries/liblmdb/mdb.c:5305 leaf = 0x7ff7e03cafb6 rc = 0 #11 0x00000000005159d1 in mdb_cursor_del (mc=0x7ff7e0102270, flags=0) at ./../../../libraries/liblmdb/mdb.c:5278 leaf = 0x7ff7e03c6f24 rc = 0 #12 0x000000000056e5ee in mdb_dn2id_delete (op=0x7ff7f17213c0, mc=0x7ff7e0102270, id=1087351, nsubs=1) at dn2id.c:217 nid = 73 ptr = 0x7ffc37bf9f0a "" rc = 0 #13 0x000000000056d058 in mdb_delete (op=0x7ff7f17213c0, rs=0x7ff7f1721350) at delete.c:335 mdb = 0x7ffff7f2a010 pdn = {bv_len = 12, bv_val = 0x7ff7e010347f "cn=authstats"} e = 0x7ff7e0000be0 p = 0x7ff7e00009b0 manageDSAit = 0 children = 0x935970 entry = 0x9356d0 txn = 0x7ff7e03bdfd0 mc = 0x7ff7e0102270 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x7ffff7f2a010}, moi_txn = 0x7ff7e03bdfd0, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7ff7f1720e70 preread_ctrl = 0x0 ctrls = {0x0, 0x7ff7f172127e, 0x7ff7e0000908, 0x7ff7f1721281, 0x7ff7f172127e, 0x88} num_ctrls = 0 parent_is_glue = 0 parent_is_leaf = 0 __PRETTY_FUNCTION__ = "mdb_delete" #14 0x00000000004d8b1d in overlay_op_walk (op=0x7ff7f17213c0, rs=0x7ff7f1721350, which=op_delete, oi=0x9b7e60, on=0x0) at backover.c:671 func = 0x85d558 rc = 32768 #15 0x00000000004d8d34 in over_op_func (op=0x7ff7f17213c0, rs=0x7ff7f1721350, which=op_delete) at backover.c:723 oi = 0x9b7e60 on = 0x9b8040 be = 0x9b7190 db = {bd_info = 0x85d500, bd_self = 0x9b7190, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 128}, be_suffix = 0x9b79e0, be_nsuffix = 0x9b7a10, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 23, bv_val = 0x9b7c50 "cn=manager,dc=vt,dc=edu"}, be_rootndn = { bv_len = 23, bv_val = 0x9b7ca0 "cn=manager,dc=vt,dc=edu"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x9b7cf0, be_acl = 0x9b84c0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xb5f2d0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x864500, be_private = 0x7ffff7f2a010, be_next = {stqe_next = 0x9b8760}} cb = {sc_next = 0x7ffff35e5fe0, sc_response = 0x4d7afa <over_back_response>, sc_cleanup = 0, sc_private = 0x9b7e60} sc = 0x7ff7f1721354 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #16 0x00000000004d8eee in over_op_delete (op=0x7ff7f17213c0, rs=0x7ff7f1721350) at backover.c:780 No locals. #17 0x00007ffff33dcb46 in accesslog_purge (ctx=0x7ff7f1721aa0, arg=0xa1e4e0) at accesslog.c:707 i = 0 rtask = 0xa1e4e0 li = 0xa1f300 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x5d1370 ""}, c_peer_name = {bv_len = 0, bv_val = 0x5d1370 ""}, c_listener = 0x5d92a0, c_sasl_bind_mech = { bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = { bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x45be00 <slap_send_ldap_result>, c_send_search_entry = 0x45cb08 <slap_send_search_entry>, c_send_search_reference = 0x45ebb8 <slap_send_search_reference>, c_send_ldap_extended = 0x45c667 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x45c8e5 <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7ff7f1721530, o_tag = 74, o_time = 1369246130, o_tincr = 2, o_bd = 0x7ff7f1720fe0, o_req_dn = {bv_len = 44, bv_val = 0x7ff7e0103420 "reqStart=20130520202434.000180Z,cn=authstats"}, o_req_ndn = {bv_len = 43, bv_val = 0x7ff7e0103460 "reqStart=20130520202434.00018Z,cn=authstats"}, o_request = {oq_add = {rs_modlist = 0x1, rs_e = 0xffffffffffffffff}, oq_bind = {rb_method = 1, rb_cred = { bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = { bv_len = 1, bv_val = 0x861740 "\003"}, rb_ssf = 4050785040, rb_mech = {bv_len = 27, bv_val = 0x7ff7e0000908 "\300\017r\361\367\177"}}, oq_compare = {rs_ava = 0x1}, oq_modify = {rs_mods = { rs_modlist = 0x1, rs_no_opattrs = -1 '\377'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 1, bv_val = 0x861740 "\003"}, rs_nnewrdn = {bv_len = 140702884434704, bv_val = 0x1b <Address 0x1b out of bounds>}, rs_newSup = 0x7ff7e0000908, rs_nnewSup = 0x0}, oq_search = { rs_scope = 1, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 1, rs_attrs = 0x861740, rs_filter = 0x7ff7f1721310, rs_filterstr = {bv_len = 27, bv_val = 0x7ff7e0000908 "\300\017r\361\367\177"}}, oq_abandon = {rs_msgid = 1}, oq_cancel = {rs_msgid = 1}, oq_extended = {rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, oq_pwdexop = {rs_extended = { rs_reqoid = {bv_len = 1, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0, rs_reqdata = 0x1}, rs_old = {bv_len = 8787776, bv_val = 0x7ff7f1721310 "\246"}, rs_new = {bv_len = 27, bv_val = 0x7ff7e0000908 "\300\017r\361\367\177"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 1 '\001', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x7ff7f1721678, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 23, bv_val = 0x9b7c50 "cn=manager,dc=vt,dc=edu"}, sai_ndn = { bv_len = 23, bv_val = 0x9b7ca0 "cn=manager,dc=vt,dc=edu"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7ff7e0000908, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7ff7f1721260 "20130521180706.125179Z#000000#000#000000"}, o_private = 0x0, o_extra = {slh_first = 0x7ff7f1720e70}, o_next = { stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 18446744073709551615, oh_conn = 0x7ff7f1721780, oh_msgid = 0, oh_protocol = 0, oh_tid = 140702884439808, oh_threadctx = 0x7ff7f1721aa0, oh_tmpmemctx = 0x7ff7e00008c0, oh_tmpmfuncs = 0x861ce0, oh_counters = 0x8b7d40, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 32 times>}} op = 0x7ff7f17213c0 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = -30798, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x0, sc_response = 0x7ffff33dc4f0 <log_old_lookup>, sc_cleanup = 0, sc_private = 0x7ff7f17212c0} f = {f_choice = 166, f_un = {f_un_result = -244182288, f_un_desc = 0x7ff7f17212f0, f_un_ava = 0x7ff7f17212f0, f_un_ssa = 0x7ff7f17212f0, f_un_mra = 0x7ff7f17212f0, f_un_complex = 0x7ff7f17212f0}, f_next = 0x0} ava = {aa_desc = 0x9ad600, aa_value = {bv_len = 15, bv_val = 0x7ff7f17212a0 "20130521180850Z"}} pd = {slots = 22700, used = 22689, dn = 0x7ff7e04cab30, ndn = 0x7ff7e0523600, csn = {bv_len = 40, bv_val = 0x7ff7f1721260 "20130521180706.125179Z#000000#000#000000"}} timebuf = "20130521180850Z\000\000\000\000\000\000" csnbuf = "20130521180706.125179Z#000000#000#000000", '\000' <repeats 23 times> old = 1369159730 __PRETTY_FUNCTION__ = "accesslog_purge" #18 0x0000000000595639 in ldap_int_thread_pool_wrapper (xpool=0x93a270) at tpool.c:688 pool = 0x93a270 task = 0x7ff7ec000a20 work_list = 0x93a308 ctx = {ltu_id = 140702884439808, ltu_key = {{ltk_key = 0x4b8d8b, ltk_data = 0x7ff7e00008c0, ltk_free = 0x4b8bb0 <slap_sl_mem_destroy>}, { ltk_key = 0x7ffff3127010, ltk_data = 0x7ff7e0100910, ltk_free = 0x5746dc <mdb_reader_free>}, {ltk_key = 0x525df8, ltk_data = 0x7ff7ea7fe010, ltk_free = 0x525dd5 <search_stack_free>}, {ltk_key = 0x52329d, ltk_data = 0x7ff7f0420010, ltk_free = 0x523255 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x80}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 672 hash = 284303008 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #19 0x00007ffff764a851 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #20 0x00007ffff676890d in clone () from /lib64/libc.so.6 No symbol table info available. #####

1 0

Re: (ITS#7595) OpenLDAP lacks a ECDHE key generation callback
by hyc＠symas.com 22 May '13

22 May '13

crest(a)tzi.de wrote: > Full_Name: Jan Bramkamp > Version: 2.4.35 > OS: FreeBSD 9.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.230.127.217) > > > OpenLDAP supports PFS TLS cipher suites using DHE with the > DH *tlso_tmp_dh_cb(SSL*,int,int) callback in libraries/libldap/tls_o.c. > DHE-RSA/DSS cipher suites are very CPU intensive and noticeably increase latency > on low-power hardware. While OpenLDAP supports ECDH-ECDSA cipher suites these > lack the PFS offered by DHE-RSA/DSS cipher suites. > >>From my initial search it looks like the correct API to register such a callback > would be SSL_CTX_set_tmp_ecdh_callback(), but im not familiar the OpenLDAP code > base so patching it my self could have unintended consequences. > > This how the CA was generated: > CURVE=secp384r1 > > openssl ecparam -out private/ca-key.pem -name $CURVE -genkey && > openssl req -new -x509 -days 365 -key private/ca-key.pem -out > certs/ca-cert.pem > > openssl ecparam -out private/auth1-key.pem -name $CURVE -genkey && > openssl req -new -key private/auth1-key.pem -out newcerts/auth1-csr.pem && > openssl ca -config /usr/local/openssl/openssl.cnf -out certs/auth1-cert.pem > -infiles newcerts/auth1-csr.pem > > The (EC)DH paramter file was generated with: > openssl ecparam -name $CURVE > > This was tested with slapd linked against OpenSSL 1.0.1e from ports on FreeBSD > 9.1/amd64. > > Some background info in this thread http://openssl.6102.n7.nabble.com/Problem-with-cipher-suite-ECDHE-ECDSA-AES… -- -- 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#7598) Named MDB database incompatible with some flags
by h.b.furuseth＠usit.uio.no 21 May '13

21 May '13

> mdb_dbi_open(named database) and thus "mdb_stat -a" > crash if the main database has the MDB_DUPSORT flag: > It hits assert(mx != NULL) in mdb_cursor_init(). > > Fixing to reject mdb_dbi_open(named database) in this > case, (...) But then mdb_stat crashes anyway when calling: mdb_cursor_get(cursor, &key, NULL, MDB_NEXT) if a key has several data values. mdb_cursor_get(,,,MDB_NEXT) expects a non-NULL data argument for an MDB_DUPSORT database. It works with MDB_NEXT_NODUP. I think we can drop the doc which says MDB_<NEXT,PREV>_NODUP is only for DUPSORT databases. mdb.c will need no changes that I can see. Or, it works to pass a pointer to an otherwise unused data. But that leaves mdb_stat doing more work than it needs. Another mdb_stat nitpick: It exits with failure after mdb_cursor_get returns an expected MDB_NOTFOUND. Fixing. -- Hallvard

1 0

(ITS#7598) Named MDB database incompatible with some flags
by h.b.furuseth＠usit.uio.no 21 May '13

21 May '13

Full_Name: Hallvard B Furuseth Version: mdb.master, a2ce25482a60e516d1d9b417ed666dac6fdebb93 OS: Linux x86_64 URL: Submission from: (NULL) (193.69.163.163) Submitted by: hallvard mdb_dbi_open(named database) and thus "mdb_stat -a" crash if the main database has the MDB_DUPSORT flag: It hits assert(mx != NULL) in mdb_cursor_init(). Fixing to reject mdb_dbi_open(named database) in this case, and also with MDB_INTEGERKEY which would expect the char* database name to be a binary integer.

1 0

(ITS#7597) migration of sunone 5.2 to openldap 2.4
by univadisitisteam＠hcl.com 21 May '13

21 May '13

Full_Name: venkatesh Version: 2.4 OS: RH5.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (155.91.28.231) HI Team, We have a requirement for migrating existing Sun One 5.2 DS to open ldap 2.4 Authentication.Please guide me how to do this migration. Regards, Venkatesh

1 0

(ITS#7596) OpenLDAP returning incorrect value for "graceAuthNsRemaining"
by nzipsi＠gmail.com 21 May '13

21 May '13

Full_Name: Andrew Thorburn Version: 2.4.35 OS: N/A URL: Submission from: (NULL) (203.97.178.157) The problem is very simple: According to the Behera Password Policy Draft (http://tools.ietf.org/html/draft-behera-ldap-password-policy-10), the attribute graceAuthNsRemaining should be set to the number of grace authentications remaining. However, with the following policy extract: pwdMaxAge: 1 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: TRUE pwdGraceAuthNLimit: 2 Running ldapwhoami results in the following: ldap_bind: Success (0) (Password expired, 2 grace logins remain) dn:uid=ANDREWT,ou=People,dc=example,dc=com That is not correct - there is only a single grace login remaining. I have used up one of the two grace logins provided by binding to OpenLDAP to execute the ldapwhoami command. Executing the same command twice more results in the following: $ ldapwhoami -h remotehost -e ppolicy -D uid=ANDREWT,ou=People,dc=example,dc=com -w andrew10 ldap_bind: Success (0) (Password expired, 1 grace logins remain) dn:uid=ANDREWT,ou=People,dc=example,dc=com $ ldapwhoami -h remotehost -e ppolicy -D uid=ANDREWT,ou=People,dc=example,dc=com -w andrew10 ldap_bind: Invalid credentials (49); Password expired Whereas I would have assumed, both from the message returned and from the language in the draft, that the first invocation would have said "(Password expired, 1 grace logins remain)", followed by then denying access for the next two invocations. Well, actually, what I would *expect* to happen is the first would return "1 remains", the second "0 remain" and the third would deny access, but the draft policy is pretty explicit, IMO, that the former is what should happen (which is daft). Now, according to the spec: "If there are remaining grace authentications as per Section 7.4, the server adds a new value with the current time in pwdGraceUseTime. Then it sends to the client a response with an appropriate successful resultCode (i.e. success (0), compareTrue (6), etc.), and includes the passwordPolicyResponse in the controls field of the response message with the warning: graceAuthNsRemaining choice set to the number of grace authentications left." This suggests, at least to me, that a new value should be added to pwdGraceUseTime *before* calculating the number of remaining grace logins. Admittedly, that wouldn't actually fix the issue, as it would result in the final grace login failing. Oops. This looks a lot like a bug to me, but at the same time, it also seems to be trying to adhere to the letter of the policy while also doing what is expected (e.g. if pwdGraceAuthNLimit is 1, I should be able to login once, while according to the letter of the policy pwdGraceAuthNLimit: 1 == pwdGraceAuthNLimit: 0...) The simplest fix, at least that I can see, would be to add the statement "ngut--;" at some point after the statement if (ngut < 1) { ppb->pErr = PP_passwordExpired; rs->sr_err = LDAP_INVALID_CREDENTIALS; goto done; } e.g. if (ngut < 1) { ppb->pErr = PP_passwordExpired; rs->sr_err = LDAP_INVALID_CREDENTIALS; goto done; } ngut--; Or perhaps after we've created the grace user time attribute modification. This would be done to account for the fact that we are, right now, using up a single one of the pwdGraceUseTime values, and that once we're done, ngut should indeed be one less than it currently is - there will be (ngut - 1) grace logins *remaining* after this method invocation finishes. This may seem like a really small thing, but it's causing problems for me...

1 0

RE: (ITS#7591) back-meta modify operation not sending result to client
by jorge.perez.burgos＠ericsson.com 21 May '13

21 May '13

Hi, At the end, meta_back_op_result() will map inside the error returned by ldap_modify_ext to LDAP_OTHER, since we don't call it with LDAP_BACK_SENDERR, nothing is sent. Since the error is not LDAP_UNAVAILABLE there will be no retries. I think this happens too in add and delete. BR -----Original Message----- From: Pierangelo Masarati [mailto:pierangelo.masarati@polimi.it] Sent: lunes, 20 de mayo de 2013 21:41 To: Jorge Perez Burgos Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7591) back-meta modify operation not sending result to client On 05/15/2013 08:57 AM, jorge.perez.burgos(a)ericsson.com wrote: > kludge fix for the problem > > --- servers/slapd/back-meta/modify.c 2012-07-31 18:39:26.000000000 +0200 > +++ servers/slapd/back-meta/modify.c 2013-05-14 12:45:39.273333000 +0200 > @@ -176,6 +176,7 @@ > } > modv[ i ] = 0; > > + rs->sr_type = -1; > retry:; > ctrls = op->o_ctrls; > rc = meta_back_controls_add( op, rs, mc, candidate, &ctrls ); @@ > -198,6 +200,10 @@ > } > > cleanup:; > + if (rs->sr_type != REP_RESULT) { > + send_ldap_error(op, rs, LDAP_OTHER, "connection problem trying to reach the other node"); > + } > + > (void)mi->mi_ldap_extra->controls_free( op, rs, &ctrls ); > > if ( mdn.bv_val != op->o_req_dn.bv_val ) { Thanks for the feedback; I am under the impression that a result should have been returned by meta_back_op_result(). Before applying the suggested fix, I would like to understand whether that function was called and in case why it did not send a result. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7595) OpenLDAP lacks a ECDHE key generation callback
by crest＠tzi.de 21 May '13

21 May '13

Full_Name: Jan Bramkamp Version: 2.4.35 OS: FreeBSD 9.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.230.127.217) OpenLDAP supports PFS TLS cipher suites using DHE with the DH *tlso_tmp_dh_cb(SSL*,int,int) callback in libraries/libldap/tls_o.c. DHE-RSA/DSS cipher suites are very CPU intensive and noticeably increase latency on low-power hardware. While OpenLDAP supports ECDH-ECDSA cipher suites these lack the PFS offered by DHE-RSA/DSS cipher suites. >From my initial search it looks like the correct API to register such a callback would be SSL_CTX_set_tmp_ecdh_callback(), but im not familiar the OpenLDAP code base so patching it my self could have unintended consequences. This how the CA was generated: CURVE=secp384r1 openssl ecparam -out private/ca-key.pem -name $CURVE -genkey && openssl req -new -x509 -days 365 -key private/ca-key.pem -out certs/ca-cert.pem openssl ecparam -out private/auth1-key.pem -name $CURVE -genkey && openssl req -new -key private/auth1-key.pem -out newcerts/auth1-csr.pem && openssl ca -config /usr/local/openssl/openssl.cnf -out certs/auth1-cert.pem -infiles newcerts/auth1-csr.pem The (EC)DH paramter file was generated with: openssl ecparam -name $CURVE This was tested with slapd linked against OpenSSL 1.0.1e from ports on FreeBSD 9.1/amd64.

1 0

Re: (ITS#7591) back-meta modify operation not sending result to client
by pierangelo.masarati＠polimi.it 20 May '13

20 May '13

On 05/15/2013 08:57 AM, jorge.perez.burgos(a)ericsson.com wrote: > kludge fix for the problem > > --- servers/slapd/back-meta/modify.c 2012-07-31 18:39:26.000000000 +0200 > +++ servers/slapd/back-meta/modify.c 2013-05-14 12:45:39.273333000 +0200 > @@ -176,6 +176,7 @@ > } > modv[ i ] = 0; > > + rs->sr_type = -1; > retry:; > ctrls = op->o_ctrls; > rc = meta_back_controls_add( op, rs, mc, candidate, &ctrls ); > @@ -198,6 +200,10 @@ > } > > cleanup:; > + if (rs->sr_type != REP_RESULT) { > + send_ldap_error(op, rs, LDAP_OTHER, "connection problem trying to reach the other node"); > + } > + > (void)mi->mi_ldap_extra->controls_free( op, rs, &ctrls ); > > if ( mdn.bv_val != op->o_req_dn.bv_val ) { Thanks for the feedback; I am under the impression that a result should have been returned by meta_back_op_result(). Before applying the suggested fix, I would like to understand whether that function was called and in case why it did not send a result. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7594) incomplete MDB subdb cursor cleanup
by h.b.furuseth＠usit.uio.no 18 May '13

18 May '13

Full_Name: Hallvard B Furuseth Version: mdb.master 0cdd9dffddf66c730a35f48db2bb02d8bb3e5731 OS: Linux x86_64 URL: Submission from: (NULL) (193.69.163.163) Submitted by: hallvard If a cursor is at a clean subDB page, and its current item is deleted by another cursor, then MDB_GET_CURRENT returns the deleted item. Test program below, run with no args, the "m2/del" output line. If the page was dirty, I instead got (key = old, data = size 0). I don't know if it should give MDB_NOTFOUND instead. That's the test program run with one arg. I did not check what happens if the other cursor rearranged the pages, e.g. split the item off to another page. #include "lmdb.h" #include <assert.h> #include <stdio.h> #include <stdlib.h> int main(int argc, char **argv) { char *fname = "test.mdb"; MDB_env *env; MDB_txn *txn; MDB_dbi dbi; MDB_cursor *mc, *m2; MDB_val key, data; int rc; # define STR2VAL(s) (&(MDB_val){sizeof(s), s}) /* includes final \0 */ # define SHOW(name) printf("%s:\t%s[%zd] -> %s[%zd]\n", name, \ (char*)key.mv_data, key.mv_size, (char*)data.mv_data, data.mv_size) # define E(e) { rc = (e); if (rc) { fprintf(stderr, "%s:%d: %s: %s\n",\ __FILE__, __LINE__, #e, mdb_strerror(rc)); abort(); } } remove(fname); E(mdb_env_create(&env)); E(mdb_env_open(env, fname, MDB_NOSUBDIR, 0666)); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_dbi_open(txn, NULL, MDB_DUPSORT, &dbi)); E(mdb_cursor_open(txn, dbi, &mc)); E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("x"), 0)); E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("y"), 0)); if (argc < 2) { E(mdb_txn_commit(txn)); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_cursor_open(txn, dbi, &mc)); puts("With clean page:"); } E(mdb_cursor_open(txn, dbi, &m2)); E(mdb_cursor_get(mc, &key, &data, MDB_FIRST)); E(mdb_cursor_get(m2, &key, &data, MDB_FIRST)); SHOW("Name:\tKey -> Data (mv_data[mv_len]):\n" "m2"); E(mdb_cursor_del(mc, 0)); E(mdb_cursor_get(m2, &key, &data, MDB_GET_CURRENT)); SHOW("m2/del"); /* Should output the same as... */ E(mdb_cursor_get(mc, &key, &data, MDB_GET_CURRENT)); SHOW("mc/del"); /* ...this: "a[2] -> [0]". */ mdb_txn_abort(txn); mdb_env_close(env); return 0; }

1 0

Re: (ITS#7589) MDB nodesize issues
by h.b.furuseth＠usit.uio.no 17 May '13

17 May '13

Another issue: This breaks because liblmdb does not change the node size when overwriting an overflow page: mdb_put(txn, dbi, &key, &(MDB_val){9000, val}, 0); mdb_put(txn, dbi, &key, &(MDB_val){1, val}, 0); mdb_get(txn, dbi, &key, &data); assert(data.mv_size != 9000); Fixed by 0cdd9dffddf66c730a35f48db2bb02d8bb3e5731. mdb_cursor_put() said: /* yes, overwrite it. Note in this case we don't * bother to try shrinking the node if the new data * is smaller than the overflow threshold. */ It's number of pages which does not need to shrink. -- Hallvard

1 0

Re: (ITS#7577) hdb and mdb derefere aliases differently
by hyc＠symas.com 17 May '13

17 May '13

Juergen.Sprenger(a)swisscom.com wrote: > tried the fix fb537d747c6fd43e08986e99b1fe7781660feaf3 There was a followup commit also needed. 201ddbe3e4d8eb39830b96eefa559900952bc022 Just get the latest. -- -- 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#7577) hdb and mdb derefere aliases differently
by Juergen.Sprenger＠swisscom.com 17 May '13

17 May '13

tried the fix fb537d747c6fd43e08986e99b1fe7781660feaf3 but behavior did not change. Juergen Sprenger

1 0

(ITS#7593) Openldap - MySQL | Issue with displaying list of users from same domain
by sandeeps＠rediff-inc.com 15 May '13

15 May '13

Full_Name: Sandeep Singh Version: openldap-2.4.35 OS: CentOS Linux release 6.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.137.232.113) Hello, We have configured an openldap server with mysql as the backend. It is working fine as well. We have a scenario where we feel it is not behaving the way it is required. We have multiple domains say:- 1) abc.com 2) xyz.com Have mapped user as:- 1) mail=man1(a)red.com,dc=abc,dc=com with password=man1r 2) mail=man2(a)red.com,dc=abc,dc=com with password=man2r 3) mail=man1(a)sad.com,dc=xyz,dc=com with password=man1s 4) mail=man2(a)sad.com,dc=xyz,dc=com with password=man2s When we search for result using:- ldapsearch -x -D "mail=man1(a)red.com,dc=abc,dc=com" -W -b "dc=abc,dc=com" It gives us output / result shown is of domains abc.com i.e. mail=man1(a)red.com,dc=abc,dc=com & mail=man1@red.com,dc=abc,dc=com Which is correct But when we search for results using:- ldapsearch -x -D "mail=man1(a)red.com,dc=abc,dc=com" -W -b "dc=xyz,dc=com" Then the output / result shown is of domain xyz.com i.e. mail=man1(a)sad.com,dc=xyz,dc=com & mail=man2@sad.com,dc=xyz,dc=com because the base search is dc=xyz,dc=com Which is not correct as mail=man1(a)red.com,dc=abc,dc=com does not belong to xyz.com domain So we want to authenticate and display user along with the list of other users from the same domain and not from the other domain. Please suggest how to overcome / solve the issue.

1 0

Re: (ITS#7591) back-meta modify operation not sending result to client
by jorge.perez.burgos＠ericsson.com 15 May '13

15 May '13

kludge fix for the problem --- servers/slapd/back-meta/modify.c 2012-07-31 18:39:26.000000000 +0200 +++ servers/slapd/back-meta/modify.c 2013-05-14 12:45:39.273333000 +0200 @@ -176,6 +176,7 @@ } modv[ i ] = 0; + rs->sr_type = -1; retry:; ctrls = op->o_ctrls; rc = meta_back_controls_add( op, rs, mc, candidate, &ctrls ); @@ -198,6 +200,10 @@ } cleanup:; + if (rs->sr_type != REP_RESULT) { + send_ldap_error(op, rs, LDAP_OTHER, "connection problem trying to reach the other node"); + } + (void)mi->mi_ldap_extra->controls_free( op, rs, &ctrls ); if ( mdn.bv_val != op->o_req_dn.bv_val ) {

1 0

(ITS#7592) LMDB corruption
by hyc＠OpenLDAP.org 15 May '13

15 May '13

Full_Name: Howard Chu Version: 2.4.33+ OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc Already fixed in mdb.master commit 7233bc295bb3e40b2758158ae2de6f42516962f8 In mdb_page_split, if updating the parent's separator triggers a split in the parent, and the current cursor position happens to point to the split index, the cursor will be left pointing to the old parent page instead of the correct page.

1 0

(ITS#7591) back-meta modify operation not sending result to client
by jorge.perez.burgos＠ericsson.com 14 May '13

14 May '13

Full_Name: Jorge Perez Burgos Version: 2.4.32 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) Right now when sending bulk traffic trough back-meta and killing the slapds receiving the proxy traffic, it can be seen that a very few modify operations are not receiving the result of the operations, looking at the code it seems the same for the add and delete operation. Basically when ldap_modify_ext returns an errno it seems that is not properly handle afterwards.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs