- openldap-bugs - openldap.org

Re: (ITS#6731) Scrambled error strings from back-ldif
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Howard Chu writes: > It is not an error in ldif_back_add() since rs->sr_text is only used by > send_ldap_result(). Its value upon return from ldif_back_add is irrelevant. Okay. I wondered if overlays could do something strange, but that does seem wrong. Then this bug only affected modify and modrdn. -- Hallvard

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >> Thanks. Applied a similar patch to cvs HEAD, after fixing a memory leak. >> >> Reproducing the bug: >> >> userPassword can exist without pwdChangedTime if you bypass >> ppolicy: Use slapadd to add an entry with userPassword, or add >> it to a subtree with no policy and then configure a policy. >> >> Then set up ppolicy and use ldapmodify to delete userPassword. > > In that case the correct fix is to skip the pwdChangedTime attribute > completely. Well, that's what this fix does in this particular code chunk: Don't try to delete pwdChangedTime if it isn't there. > The ppolicy spec says that entries without pwdChangedTime are not > subject to password expiration at all. Sounds like a different issue, but I don't see where it says that. What I did find is 8.2.7. Policy State Updates If the value of either pwdMaxAge or pwdMinAge is non-zero, the server updates the pwdChangedTime attribute on the entry to the current time. -- Hallvard

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 02 Dec '10

02 Dec '10

--On December 2, 2010 6:45:45 PM +0000 doug.leavitt(a)oracle.com wrote: > At the end of my test threads 11-14 were not terminated. I > believe this may imply significant thread stack growth not 'leakage'. > > I will provide more info as I get it. I hope this helps in resolving > this ITS. Hi Doug, Thanks for the data point. We've definitely identified that it is not leakage, but problems with having multiple cores (> 2 or 3). In that scenario, the entry cache grows up until the point that every entry is present in the cache. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by doug.leavitt＠oracle.com 02 Dec '10

02 Dec '10

I may have another data point w.r.t this ITS. I tried replicating this ITS by: setting up a slapd based on test003-search config plus 100,000 additional entries similar to the other OpenLDAPperson test entries. running 20+ simultaneous instances of the test003 search tests I see a definite memory growth in the server. After the test run, according to libumem transaction logs there is about 600k lost memory in leaks (in my case). BUT the leaks are not lost cache entries or other obvious malloc/free errors. According to libumem the "leaks" are all 4k - 16k chunks of MMAP memory allocated to thread stacks associated with threads 11 - 14. I plan to investigate further. libumem may be reporting that there are no leaks, but instead that certain threads have significant thread stack growth under heavy activity. Alternately the threads may be terminating, resulting in loss of thread stack memory and later being restarted multiple times resulting in multiple thread stack leaks. (I am not sure yet which situation is the correct one). Either situation may produce an unaccounted for memory growth that may not be exposed via normal debugging malloc techniques because the memory loss does not seem to be heap related. At the end of my test threads 11-14 were not terminated. I believe this may imply significant thread stack growth not 'leakage'. I will provide more info as I get it. I hope this helps in resolving this ITS. Doug.

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by hyc＠symas.com 02 Dec '10

02 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Thanks. Applied a similar patch to cvs HEAD, after fixing a memory leak. > > Reproducing the bug: > > userPassword can exist without pwdChangedTime if you bypass > ppolicy: Use slapadd to add an entry with userPassword, or add > it to a subtree with no policy and then configure a policy. > > Then set up ppolicy and use ldapmodify to delete userPassword. > In that case the correct fix is to skip the pwdChangedTime attribute completely. The ppolicy spec says that entries without pwdChangedTime are not subject to password expiration at all. -- -- 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#6731) Scrambled error strings from back-ldif
by hyc＠symas.com 02 Dec '10

02 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 2.4.23 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.157.203.245) > Submitted by: hallvard > > > apply_modify_to_entry() and ldif_back_add() can return with > rs->sr_text pointing into the stack, at textbuf[]. Fixing. > It is not an error in ldif_back_add() since rs->sr_text is only used by send_ldap_result(). Its value upon return from ldif_back_add is irrelevant. -- -- 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#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by michael＠stroeder.com 02 Dec '10

02 Dec '10

I can still reproduce this pretty soon when running this test with several iterations. testrun/slapd.3.log ends with: connection_close: conn=1014 sd=9 =>ldap_back_conn_destroy: fetching conn 1014 =>ldap_back_conn_destroy: fetching conn 1014 =>ldap_back_conn_destroy: fetching conn 1014 conn=1014 fd=9 closed (connection lost) daemon: shutdown requested and initiated. slapd shutdown: waiting for 0 operations/tasks to finish lt-slapd shutdown: initiated lt-slapd destroy: freeing system resources. ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 13 ldap_free_connection: actually freed ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 11 ldap_free_connection: actually freed ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 12 ldap_free_connection: actually freed ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 10 ldap_free_connection: actually freed slapd stopped. lt-slapd: at.c:242: at_delete_names: Assertion `air != ((void *)0)' failed.

1 0

(ITS#6732) ber_errno issues in liblber/memory.c
by h.b.furuseth＠usit.uio.no 02 Dec '10

02 Dec '10

Full_Name: Hallvard B Furuseth Version: 4.2.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard With LDAP_MEMORY_DEBUG, ber_memalloc_x() and ber_memcalloc_x() do not set ber_errno = LBER_ERROR_MEMORY on failure. OTOH a number of memory.c functions set ber_errno = LBER_ERROR_MEMORY when they do not need to, after ber_memalloc & co already set it. Fixing.

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by m.d.t.evans＠qmul.ac.uk 02 Dec '10

02 Dec '10

On Thu, 2010-12-02 at 12:24 +0100, Hallvard B Furuseth wrote: > Thanks. Applied a similar patch to cvs HEAD, after fixing a memory leak. > > Reproducing the bug: > > userPassword can exist without pwdChangedTime if you bypass > ppolicy: Use slapadd to add an entry with userPassword, or add > it to a subtree with no policy and then configure a policy. > > Then set up ppolicy and use ldapmodify to delete userPassword. > Yes. I agree with that. That's precisely how we discovered the problem. Thanks, Martin. -- Dr Martin DT Evans, Computing Services/Central Servers.

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by h.b.furuseth＠usit.uio.no 02 Dec '10

02 Dec '10

Thanks. Applied a similar patch to cvs HEAD, after fixing a memory leak. Reproducing the bug: userPassword can exist without pwdChangedTime if you bypass ppolicy: Use slapadd to add an entry with userPassword, or add it to a subtree with no policy and then configure a policy. Then set up ppolicy and use ldapmodify to delete userPassword. -- Hallvard

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by m.d.t.evans＠qmul.ac.uk 02 Dec '10

02 Dec '10

On Thu, 2010-12-02 at 10:04 +0100, Hallvard B Furuseth wrote: > Thank you. Please also send an IPR notice for the patch, according to > > http://www.openldap.org/devel/contributing.html#n-openldap > Thanks. Done (I think). Kind regards, Martin. -- Dr Martin DT Evans, Computing Services/Central Servers.

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by m.d.t.evans＠qmul.ac.uk 02 Dec '10

02 Dec '10

This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by MDT Evans <m.d.t.evans(a)qmul.ac.uk>. I have not assigned rights and/or interest in this work to any party. I, MDT Evans, 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. -- Dr Martin DT Evans, Computing Services/Central Servers.

1 0

Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by ondrej.kuznik＠acision.com 02 Dec '10

02 Dec '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/09/2010 03:50 PM, ondrej.kuznik(a)acision.com wrote: > I have put a preliminary version of patches that modify the unique > overlay here > ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101109-unique_bypass_v1.tgz > > They add a new configuration attribute olcUniqueAllowManageBypass (it is > prohibitively long for a name, though) that, if set to TRUE, triggers > the uniqueness checks not to be performed if the operation has manage > privilegies on the entry. There are three separate patches, > configuration code regarding the new attribute, the checks in > unique_{add,modify,modrdn} and manpage modifications. > After a conversation with Howard, I have modified the patches so that the overlay check for the ManageDsaIt control instead. That control should be set for each operation coming from replication. The patches are here: ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101202-unique_bypass_v2.tgz Is there anything else that comes to mind? Again the IPR notice: The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz3cLcACgkQ9GWxeeH+cXuKBACfSvRQJvNWpVm16pWhJ3wfAxH2 JBwAn3CDasTgcMONMSFyIaqH0CZpv1MN =YaoF -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

(ITS#6731) Scrambled error strings from back-ldif
by h.b.furuseth＠usit.uio.no 02 Dec '10

02 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.157.203.245) Submitted by: hallvard apply_modify_to_entry() and ldif_back_add() can return with rs->sr_text pointing into the stack, at textbuf[]. Fixing.

1 0

RE : RE : (ITS#6720) back-ldap core dump
by olivier.chirossel＠sfr.com 01 Dec '10

01 Dec '10

Thank's a lot, It's work fine with the new rwm.c Regards, Olivier=

1 0

Re: (ITS#6364) refint needs to have rootdn set
by h.b.furuseth＠usit.uio.no 01 Dec '10

01 Dec '10

Quanah Gibson-Mount wrote: > The refint overlay doesn't necessarily work correctly without a rootd= n > being set on the database it is applying to. This requirement should= > be documented in the man page. Fixed in the manpage, but not in the admin guide. Michael=5FStr=F6der wrote: > I'd argue that slapd should not even start if such a strong > requirement of an overlay is not met by configuration. Leaving that for Howard, but I don't think we can do that now. cn=3Dconfig should then also refuse to delete rootdn, otherwise we'd ha= ve the worse behavior that slapd won't start after a cn=3Dconfig update. Peter Mogensen wrote: > I've veryfied that my refint overlay is not working. > However I have a rootdn defined for the database, but it is set to=20= > cn=3Dconfig. > Could it be that the rootdn has to be in the scope of the database fo= r=20 > refint to work=3F I don't think so. Hopefully it was ITS#6663 or ITS#6730, now fixed. --=20 Hallvard

1 0

Re: (ITS#6663) refint not altering last attribute on delete
by h.b.furuseth＠usit.uio.no 01 Dec '10

01 Dec '10

knewell(a)math.arizona.edu writes: > refint does not alter the value of an attribute to refint_nothing when > the last "member" of a group is deleted. Fixed in CVS HEAD. -- Hallvard

1 0

(ITS#6730) refint with subtrees/subordinates broken
by h.b.furuseth＠usit.uio.no 01 Dec '10

01 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Subtree rename breaks if an attribute contains both the base DN and a subordinate DN: It only handles the base DN if it is in the first attribute value, and (attempts to) produce the wrong new base. Subtree delete is coded but ignored: Refint searches for deleted subordinate DNs, but the test for deleting them is inverted. Also a modification can update modifiersName several times per entry. Fixing.

1 0

Re: (ITS#6684) Patch for autogroup overlay
by ryans＠aweber.com 30 Nov '10

30 Nov '10

I'm not sure if this is still relevant or useful, but included below is a set of steps that will reliably reproduce the issue and a backtrace using autogroup from HEAD and ppolicy, which as noted causes segmentation faults in the slaptools utilities (e.g., slapcat). Note that this backtrace is from a build of 2.4.21, but the issue is present and occurs with 2.4.23 as well, as Norbert has stated. rgs@ldapmaster3:~# ldapmodify -x -h localhost -ZZ -D 'cn=admin,cn=config' -y /etc/ldap.secret dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: ppolicy.la modifying entry "cn=module{0},cn=config" rgs@ldapmaster3:~# ldapadd -x -h localhost -ZZ -D 'cn=admin,cn=config' -y /etc/ldap.secret dn: olcOverlay={3}ppolicy,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {3}ppolicy olcPPolicyHashCleartext: FALSE olcPPolicyForwardUpdates: FALSE olcPPolicyUseLockout: TRUE adding new entry "olcOverlay={3}ppolicy,olcDatabase={1}hdb,cn=config" rgs@ldapmaster3:~# cat /etc/ldap/slapd.d/cn=config/cn=module{0}.ldif dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb.la olcModuleLoad: {1}autogroup.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}smbk5pwd.la olcModuleLoad: {4}ppolicy.la structuralObjectClass: olcModuleList creatorsName: cn=config entryUUID: f83e3413-5ba7-4c85-9bf7-ed8728d9fbce createTimestamp: 20091018205311Z entryCSN: 20101129205850.805900Z#000000#001#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20101129205850Z rgs@ldapmaster3:~/ldap/ldifs/ppolicy# gdb --args slapcat -n1 (gdb) run Starting program: /usr/sbin/slapcat -n1 [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff2228840 in ppolicy_restrict (op=0x7fffffffd700, rs=0x7fffffffd660) at /usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c:1271 1271 /usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c: No such file or directory. in /usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c (gdb) backtrace #0 0x00007ffff2228840 in ppolicy_restrict (op=0x7fffffffd700, rs=0x7fffffffd660) at /usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c:1271 #1 0x00007ffff7f6ed3a in overlay_op_walk (op=0x7fffffffd700, rs=0x7fffffffd660, which=<value optimized out>, oi=0x7ffff83220c0, on=0x7ffff8341e50) at /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:659 #2 0x00007ffff7f6f8ab in over_op_func (op=0x7fffffffd700, rs=0xfffffffffffffff0, which=4294957760) at /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:721 #3 0x00007ffff2846141 in autogroup_db_open (be=<value optimized out>, cr=<value optimized out>) at autogroup.c:1754 #4 0x00007ffff7f6e994 in over_db_open (be=<value optimized out>, cr=0x7fffffffdfb0) at /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:155 #5 0x00007ffff7f1388c in backend_startup_one (be=0x7ffff8315f80, cr=0x7fffffffdfb0) at /usr/src/openldap/openldap-2.4.21/servers/slapd/backend.c:224 #6 0x00007ffff7f13a83 in backend_startup (be=0x7ffff8315f80) at /usr/src/openldap/openldap-2.4.21/servers/slapd/backend.c:278 #7 0x00007ffff7f742cc in slap_tool_init (progname=<value optimized out>, tool=2, argc=2, argv=0x7fffffffe5a8) at /usr/src/openldap/openldap-2.4.21/servers/slapd/slapcommon.c:780 #8 0x00007ffff7f7335a in slapcat (argc=-9536, argv=<value optimized out>) at /usr/src/openldap/openldap-2.4.21/servers/slapd/slapcat.c:51 #9 0x00007ffff7ee84f5 in main (argc=2, argv=0x7fffffffe5a8) at /usr/src/openldap/openldap-2.4.21/servers/slapd/main.c:657 (gdb) x 0x7fffffffd700 0x7fffffffd700: 0xffffd870 (gdb) x 0x7fffffffd660 0x7fffffffd660: 0x00000000 For reference, line 1271, located within the ppolicy_restrict function, looks like so: if ( op->o_conn && !BER_BVISEMPTY( &pwcons[op->o_conn->c_conn_idx].dn )) { -Ryan

1 0

(ITS#6729) slapd segfault caused by ldapsearch -Y OTP
by daniel＠pluta.biz 30 Nov '10

30 Nov '10

Full_Name: Daniel Pluta Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4ca0:0:f000:223:aeff:feac:1f51) For details and a patch please visit: http://www.openldap.org/its/index.cgi/Development?id=6475;selectid=6475#fol…

1 0

(ITS#6728) libldap TCP/SASL problems
by quanah＠zimbra.com 29 Nov '10

29 Nov '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) As reported at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604122 Hello, During some tests for nslcd[1], I found that if the SASL_SECPROPS in /etc/ldap/ldap.conf is incompatible with the SASL_MECH, then the library: - open a useless TCP connection to the server - check the mechanism and fail - close the TCP connection ===== /etc/ldap/ldap.conf BASE dc=baby-gnu,dc=org URI ldap://192.168.122.4 SASL_MECH DIGEST-MD5 SASL_SECPROPS noactive ===== /etc/ldap/ldap.conf ===== Wireshark capture No. Time Source Destination Protocol Info 3 2.728967 192.168.122.3 192.168.122.4 TCP 51521 > ldap [SYN] Seq=0 [...] 4 2.729699 192.168.122.4 192.168.122.3 TCP ldap > 51521 [SYN, ACK] Seq=0 [...] 5 2.729714 192.168.122.3 192.168.122.4 TCP 51521 > ldap [ACK] Seq=1 [...] 6 2.739576 192.168.122.3 192.168.122.4 TCP 51521 > ldap [FIN, ACK] Seq=1 [...] 7 2.740686 192.168.122.4 192.168.122.3 TCP ldap > 51521 [FIN, ACK] Seq=1 [...] 8 2.740702 192.168.122.3 192.168.122.4 TCP 51521 > ldap [ACK] Seq=2 [...] ===== Wireshark capture ===== ldapsearch ldapsearch -U dad -s base -LLL supportedSASLMechanisms ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: No worthy mechs found ===== ldapsearch As the problem is found in a software using the libldap, I conclude the problem is in the lib and not in ldapsearc. Regards.

1 0

Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by ondrej.kuznik＠acision.com 29 Nov '10

29 Nov '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/09/2010 03:50 PM, ondrej.kuznik(a)acision.com wrote: > On 09/07/2010 03:26 PM, andrew.findlay(a)skills-1st.co.uk wrote: >> It would certainly help to keep the apparent promises made by things >> like the uniqueness overlay. Alternatively you could take the view >> that the data will converge eventually and that is all that the LDAP >> standards promise. > > We've hit a similar problem and decided to go this way, i.e. allowing > the replication to bypass the uniqueness constraints. > > [...] > > I have put a preliminary version of patches that modify the unique > overlay here > ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101109-unique_bypass_v1.tgz > > [...] > > Howard and/or others, do you consider this solution valid for this ITS? > If yes, could you help me address the things that should be sorted out? > Hi, I am resurrecting this ITS since there has been no comment on the idea since, nor has it been explicitly rejected by anyone. Does it seem valid to you? If so, could you spare a pointer or two to help me resolve some of the issues with the patch I have pointed out so that I can make it more fit for inclusion? Regards, Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzzx1gACgkQ9GWxeeH+cXuhQACcCQVydbRBhQJqhONrgeqwXLQ8 xwwAnj0NBBBY3xkazS+QfBRKB/GVGFHm =ZYQI -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Re: RE : (ITS#6720) back-ldap core dump
by masarati＠aero.polimi.it 29 Nov '10

29 Nov '10

olivier.chirossel(a)sfr.com wrote: > Thanks for the report. I've reproduced the bug; it appears to be inside=20 > slapo-rwm(5). The core dump is related to a double free, which I'm=20 > trying to track. Please test the latest commit of overlays/rwm.c (should apply fine to 2.4.23) and report. It fixes the double free. With respect to your problem description, "lastmod off" means that the backend will not *generate* modification-related operational attributes; however they are proxied. Moreover, you can't strip them off with mapping unless the remapping is part of a replication process (i.e. the backend contains syncrepl or "updatedn" is set and the operation is performed with that identity). p.

1 0

RE: RE : (ITS#6720) back-ldap core dump
by olivier.chirossel＠sfr.com 29 Nov '10

29 Nov '10

Thank's for your time, the write can't be stop, i have to reinstall all the replica , and my plann= ing, for the second step, take 3 months ... Regards, Olivier -----Message d'origine----- De=A0: Pierangelo Masarati [mailto:masarati@aero.polimi.it]=20 Envoy=E9=A0: lundi 29 novembre 2010 15:21 =C0=A0: CHIROSSEL, Olivier Cc=A0: openldap-its(a)openldap.org Objet=A0: Re: RE : (ITS#6720) back-ldap core dump olivier.chirossel(a)sfr.com wrote: > Thank's for you reply, >=20 > you can get a tar file containing a simple case which reproduce the probl= em=3D > here ( i don't put rewriting rules in proxy conf, just strip of operati= on=3D > nal attribut ) >=20 > wget http://olivier:its6720@84.103.237.12/its6720.tar >=20 >=20 > the lance.sh inititialise the tests=3D20 > (the slapd suppose to be in /usr/local/libexec) >=20 > and you reproduce it with the command : >=20 > ldapmodify -D "cn=3D3Dmanager,dc=3D3Dneuf,dc=3D3Dfr" -H "ldap://127.0.0.1= :489" -=3D > w secret -f mod >=20 > i try to explain you my need=3D20 >=20 > 1) For the moment i have a master in 2.3.x with many replica in 2.3.x wit= h =3D > slurpd replication >=20 > 2) my goal is to migrate to a mirror mode master infrastructure with sync= re=3D > pl replication >=20 > 3) the first step is to install my mirror mode infrastructure and replica= te=3D > with slurpd from my old master. >=20 > 4) second step re install replica one by one with syncrepl replication to= m=3D > y new mirror mode infrastructure >=20 > 5) third step write directly to my mirror mode infrastructure >=20 > For the first step i put a proxy ldap between my old master and my mirror= m=3D > ode infrastructure to do rewrite rules and strip operationnal attribut (i= n=3D > eed, at the end, have a new clean infrastructure with entryCSN contains = th=3D > e ServerId of my new master, for checks the replcation status between my = ma=3D > ster and between my replica and my mirror mode architcture) > =3D20 > The ldapmodify command reproduce the replication operations which highlig= ht=3D > the problem.. >=20 > PS:=3DA0before strip attribute with rwm-map directives i try to put "last= mod =3D > off" in proxy ldap configuration without success ... Thanks for the report. I've reproduced the bug; it appears to be inside=20 slapo-rwm(5). The core dump is related to a double free, which I'm=20 trying to track. In any case, since as far as I understand the only reason you need=20 slapo-rwm(5) is to modify data during the migration, you should probably=20 do it offline, after exporting your data and before importing in the new=20 system. p.

1 0

Re: RE : (ITS#6720) back-ldap core dump
by masarati＠aero.polimi.it 29 Nov '10

29 Nov '10

olivier.chirossel(a)sfr.com wrote: > Thank's for you reply, > > you can get a tar file containing a simple case which reproduce the problem= > here ( i don't put rewriting rules in proxy conf, just strip of operation= > nal attribut ) > > wget http://olivier:its6720@84.103.237.12/its6720.tar > > > the lance.sh inititialise the tests=20 > (the slapd suppose to be in /usr/local/libexec) > > and you reproduce it with the command : > > ldapmodify -D "cn=3Dmanager,dc=3Dneuf,dc=3Dfr" -H "ldap://127.0.0.1:489" -= > w secret -f mod > > i try to explain you my need=20 > > 1) For the moment i have a master in 2.3.x with many replica in 2.3.x with = > slurpd replication > > 2) my goal is to migrate to a mirror mode master infrastructure with syncre= > pl replication > > 3) the first step is to install my mirror mode infrastructure and replicate= > with slurpd from my old master. > > 4) second step re install replica one by one with syncrepl replication to m= > y new mirror mode infrastructure > > 5) third step write directly to my mirror mode infrastructure > > For the first step i put a proxy ldap between my old master and my mirror m= > ode infrastructure to do rewrite rules and strip operationnal attribut (i n= > eed, at the end, have a new clean infrastructure with entryCSN contains th= > e ServerId of my new master, for checks the replcation status between my ma= > ster and between my replica and my mirror mode architcture) > =20 > The ldapmodify command reproduce the replication operations which highlight= > the problem.. > > PS:=A0before strip attribute with rwm-map directives i try to put "lastmod = > off" in proxy ldap configuration without success ... Thanks for the report. I've reproduced the bug; it appears to be inside slapo-rwm(5). The core dump is related to a double free, which I'm trying to track. In any case, since as far as I understand the only reason you need slapo-rwm(5) is to modify data during the migration, you should probably do it offline, after exporting your data and before importing in the new system. p.

1 0

Re: (ITS#6532) Support for common orderingMatching rules in extensible match filters
by h.b.furuseth＠usit.uio.no 28 Nov '10

28 Nov '10

BTW, it occurred to me that it might be an idea to add comments instead of removing yours. slapd/schema_init.c (rev 1.474) now explains how it works, as far as I understand it. -- Hallvard

1 0

Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by michael＠stroeder.com 28 Nov '10

28 Nov '10

Now I got running this test: "WhoAmI failed (34)!" See gdb output below. I could provide content of testrun/ if necessary. $ ./run -b bdb -l 30 test047 Cleaning up test run directory leftover from previous run. Running ./scripts/test047-ldap for bdb... Running 1 of 30 iterations running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9012... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9013... Using ldapsearch to check that slapd is running... Searching base="o=Example,c=US"... Searching base="ou=Meta,o=Example,c=US"... Modifying database "o=Example,c=US"... Searching base="o=Example,c=US"... base="o=Example,c=US"... Searching filter="(seeAlso=cn=all staff,ou=Groups,o=Example,c=US)" attrs="seeAlso" base="o=Example,c=US"... Searching filter="(uid=example)" attrs="uid" base="o=Example,c=US"... Searching filter="(member=cn=Another Added Group,ou=Groups,o=Example,c=US)" attrs="member" base="o=Example,c=US"... Waiting 10 seconds for cached connections to timeout... Searching with a timed out connection... Checking server-enforced size limit... Checking client-requested size limit... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Changing password to database "o=Example,c=US"... Binding with newly changed password to database "o=Example,c=US"... Binding as newly added user to database "o=Example,c=US"... WhoAmI failed (34)! (gdb) info threads * 1 Thread 31230 0x00007f9e739109e5 in raise () from /lib64/libc.so.6 (gdb) thread apply all bt Thread 1 (Thread 31230): #0 0x00007f9e739109e5 in raise () from /lib64/libc.so.6 #1 0x00007f9e73911ee6 in abort () from /lib64/libc.so.6 #2 0x00007f9e73909235 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000475d13 in at_delete_names () at at.c:242 #4 at_destroy () at at.c:323 #5 0x000000000046fef3 in schema_destroy () at schema_init.c:6768 #6 0x000000000040ad0f in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1037

1 0

Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by michael＠stroeder.com 28 Nov '10

28 Nov '10

It seems this only happens occasionally. I'll try to get a stack trace...

1 0

(ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by michael＠stroeder.com 28 Nov '10

28 Nov '10

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux URL: Submission from: (NULL) (84.163.34.72) >>>>> Starting test047-ldap for bdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9012... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9013... Using ldapsearch to check that slapd is running... Searching base="o=Example,c=US"... Searching base="ou=Meta,o=Example,c=US"... Modifying database "o=Example,c=US"... Searching base="o=Example,c=US"... base="o=Example,c=US"... Searching filter="(seeAlso=cn=all staff,ou=Groups,o=Example,c=US)" attrs="seeAlso" base="o=Example,c=US"... Searching filter="(uid=example)" attrs="uid" base="o=Example,c=US"... Searching filter="(member=cn=Another Added Group,ou=Groups,o=Example,c=US)" attrs="member" base="o=Example,c=US"... Waiting 10 seconds for cached connections to timeout... Searching with a timed out connection... Checking server-enforced size limit... Checking client-requested size limit... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Changing password to database "o=Example,c=US"... Binding with newly changed password to database "o=Example,c=US"... Binding as newly added user to database "o=Example,c=US"... ./scripts/test047-ldap: line 599: 26709 Segmentation fault $SLAPD -f $CONF3 -h $URI3 -d $LVL $TIMING > $LOG3 2>&1 WhoAmI failed (255)! ./scripts/test047-ldap: line 614: kill: (26709) - No such process >>>>> ./scripts/test047-ldap failed for bdb (exit 255) make[2]: *** [bdb-yes] Error 255 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2

1 0

RE : (ITS#6720) back-ldap core dump
by olivier.chirossel＠sfr.com 26 Nov '10

26 Nov '10

Hi Thank's for you reply, you can get a tar file containing a simple case which reproduce the problem= here ( i don't put rewriting rules in proxy conf, just strip of operation= nal attribut ) wget http://olivier:its6720@84.103.237.12/its6720.tar the lance.sh inititialise the tests=20 (the slapd suppose to be in /usr/local/libexec) and you reproduce it with the command : ldapmodify -D "cn=3Dmanager,dc=3Dneuf,dc=3Dfr" -H "ldap://127.0.0.1:489" -= w secret -f mod i try to explain you my need=20 1) For the moment i have a master in 2.3.x with many replica in 2.3.x with = slurpd replication 2) my goal is to migrate to a mirror mode master infrastructure with syncre= pl replication 3) the first step is to install my mirror mode infrastructure and replicate= with slurpd from my old master. 4) second step re install replica one by one with syncrepl replication to m= y new mirror mode infrastructure 5) third step write directly to my mirror mode infrastructure For the first step i put a proxy ldap between my old master and my mirror m= ode infrastructure to do rewrite rules and strip operationnal attribut (i n= eed, at the end, have a new clean infrastructure with entryCSN contains th= e ServerId of my new master, for checks the replcation status between my ma= ster and between my replica and my mirror mode architcture) =20 The ldapmodify command reproduce the replication operations which highlight= the problem.. PS:=A0before strip attribute with rwm-map directives i try to put "lastmod = off" in proxy ldap configuration without success ... Regards, Olivier ________________________________________ De : openldap-its(a)OpenLDAP.org [openldap-its(a)OpenLDAP.org] Date d'envoi : lundi 22 novembre 2010 17:43 =C0 : CHIROSSEL, Olivier Objet : Re: (ITS#6720) back-ldap core dump *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#6720. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#6720) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#6720) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D6720 Please remember to retain your issue tracking number (ITS#6720) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

Re: (ITS#6724) Feature request: support for PKCS11 pin input callback in public TLS api
by hyc＠symas.com 26 Nov '10

26 Nov '10

silvan(a)kernelconcepts.de wrote: > Full_Name: Silvan Marco Fin > Version: > OS: Ubuntu Linux 10.04 > URL: > Submission from: (NULL) (217.146.132.69) > > > Support for PKCS #11 devices in TLS via MozNSS in OpenLDAP currently lacks the > possibility to "ask" for a PIN via callback. The methods supplied in tls_m.c are > reading a PIN from a file or alternativly reading a PIN from STDIN. > > To add the needed flexibility to the MozNSS part, an additional callback > argument to the init function or alternatively an additional set function for > the callback would be needed. > > http://www.mozilla.org/projects/security/pki/nss/ref/ssl/pkfnc.html#1023128 > > provides the signature for the callback function. > > Since GnuTLS and OpenSSL provide PKCS #11 support by themselves in some way, I > propose to add an additional set function to OpenLDAPs public TLS API to > register a callback with the corresponding security library. > Probably a good idea. Feel free to submit a patch for review. -- -- 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#6725) How to install multiple instances of openldap on different port(389, 390 391)
by rein＠OpenLDAP.org 26 Nov '10

26 Nov '10

On 11/25/10 17:27 , devman1624(a)yahoo.com wrote: > Can some one tell me how to install multiple instances of openldap on different > port(i.e on 389, 390 391). > > Accroding to me there is only one option, that is multiple installation od > openldap. Please direct usage questions to the openldap-technical list, the ITS system is for bugs. And please RTFM before doing so, the answer to your question is clearly stated there. Rein

1 0

(ITS#6726) How to install multiple instances of openldap on different port(389, 390 391)
by devman1624＠yahoo.com 25 Nov '10

25 Nov '10

Full_Name: DevMan Version: 2.4.16 OS: RHEL54. URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.177.216.157) Hi All, Can some one tell me how to install multiple instances of openldap on different port(i.e on 389, 390 391). Accroding to me there is only one option, that is multiple installation od openldap. Thx DevMan

1 0

(ITS#6725) How to install multiple instances of openldap on different port(389, 390 391)
by devman1624＠yahoo.com 25 Nov '10

25 Nov '10

Full_Name: DevMan Version: 2.4.16 OS: RHEL54. URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.177.216.157) Hi All, Can some one tell me how to install multiple instances of openldap on different port(i.e on 389, 390 391). Accroding to me there is only one option, that is multiple installation od openldap. Thx DevMan

1 0

Re: (ITS#6686) VLV overlay fails to handle multiple search operations per LDAP connection
by raphael.ouazana＠linagora.com 25 Nov '10

25 Nov '10

Hi, Here is a new version of the patch: ftp://ftp.openldap.org/incoming/raphael-ouazana-101125-sssvlv-multiple-requ… It fixes some segfaults that the previous patch introduced if you use pagedResults or sss instead of VLV. It also fixes a segfault in the original sssvlv code when making two successive requests on the same connexion (can be triggered by ldapsearch). Finally here is an update of the copyright notice too: Legal notice: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in this following patch were developed by Raphael Ouazana raphael.ouazana(a)linagora.com and Sebastien Bahloul sbahloul(a)linagora.com. These modifications are not subject to any license of Linagora. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Raphael Ouazana, Linagora Copyright 2010 Sebastien Bahloul, Linagora Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. Regards, Raphaël Ouazana

1 0

Re: (ITS#6720) back-ldap core dump
by masarati＠aero.polimi.it 24 Nov '10

24 Nov '10

olivier.chirossel(a)sfr.com wrote: > I have to migrate from a openldap 2.3.x to openldap 2.4. During this migration > phase i want my openldap 2.3.x master replicate with slurpd to my new openldap > 2.4.x master mirror mode architecture with some rewriting rules for split my big > directory. > > > I configure a proxy ldap using back-ldap with slapo-rwm overlay, but > operational attributes related to entry creation and modification are > proxied, even when i put « lastmod off » in the conf, contrary of the man of > slapd-ldap > > > > So i put rw-map directives in the conf for strip operationnal attributes but > this kind of operation generate a core dump Your configuration contains a load of custom schema items; can you create a simple configuration, based on standard attributes, that reproduces the problem (I mean: the sigsegv), and describe which operation is causing it? Is it a client operation or replication? In your report you mention the intention to use "master mirror mode" (?), it's not clear what back-ldap has to do with it. p.

1 0

Re: (ITS#6603) EAGAIN, EWOULDBLOCK occasionally used without checking #ifdef
by h.b.furuseth＠usit.uio.no 24 Nov '10

24 Nov '10

> Here's a patch, please inspect. > > <ftp://ftp.openldap.org/incoming/pierangelo.masarati.2010-11-23.1.patch> Looks fine to me. -- Hallvard

1 0

Re: (ITS#6532) Support for common orderingMatching rules in extensible match filters
by h.b.furuseth＠usit.uio.no 24 Nov '10

24 Nov '10

Variant applied to HEAD: schema_init.c 1.473. Correct 'match' code is simpler than yours, now that you've pointed me in the right direction. All ordering rules except CSNOrderingMatch and UUIDOrderingMatch now support extensible match. Someone who knows slapd's use of CSNs and UUIDs can (tell me to) do the same there if it's OK to do so. I didn't want to meddle carelessly, also I don't know what UUIDOrderingMatch's SLAP_MR_MUTATION_NORMALIZER flag means and if it would interfere. -- Hallvard

1 0

Re: (ITS#6603) EAGAIN, EWOULDBLOCK occasionally used without checking #ifdef
by masarati＠aero.polimi.it 23 Nov '10

23 Nov '10

>> At least in libldap and liblber EAGAIN and EWOULDBLOCK are >> occasionally used without checking whether they are defined or not. >> Either the checks should be removed, counting on the fact that these >> error codes are always defined, or they should be used consistently. > > I'd say the libldap #ifdefs can safely be removed by now: "cvs annotate" > says os-ip.c has had unconditional EWOULDBLOCK since rev 1.34 (Aug > 1999), and request.c unconditional EAGAIN since rev 1.85 (Aug 2002). > No bug reports since then... > > We need to keep the '#if EWOULDBLOCK != EAGAIN's in switches, though. > > liblber always #ifdefs them, except in a test program. I suppose these > #ifdefs could stay in case someone uses the liblber source stand-alone. Here's a patch, please inspect. <ftp://ftp.openldap.org/incoming/pierangelo.masarati.2010-11-23.1.patch> p.

1 0

(ITS#6724) Feature request: support for PKCS11 pin input callback in public TLS api
by silvan＠kernelconcepts.de 23 Nov '10

23 Nov '10

Full_Name: Silvan Marco Fin Version: OS: Ubuntu Linux 10.04 URL: Submission from: (NULL) (217.146.132.69) Support for PKCS #11 devices in TLS via MozNSS in OpenLDAP currently lacks the possibility to "ask" for a PIN via callback. The methods supplied in tls_m.c are reading a PIN from a file or alternativly reading a PIN from STDIN. To add the needed flexibility to the MozNSS part, an additional callback argument to the init function or alternatively an additional set function for the callback would be needed. http://www.mozilla.org/projects/security/pki/nss/ref/ssl/pkfnc.html#1023128 provides the signature for the callback function. Since GnuTLS and OpenSSL provide PKCS #11 support by themselves in some way, I propose to add an additional set function to OpenLDAPs public TLS API to register a callback with the corresponding security library.

1 0

Re: (ITS#5421) slapd vs LDAP_R_COMPILE
by h.b.furuseth＠usit.uio.no 23 Nov '10

23 Nov '10

Taken to this thread: http://www.openldap.org/lists/openldap-devel/201011/msg00013.html librewrite & co vs. logging & ldap-int.h Since this ITS now depends on the ldap_debug hack in ldap_log.h, I'm removing some unnecessary '#include <ldap_log.h>'s for clarity. -- Hallvard

1 0

(ITS#6603) EAGAIN, EWOULDBLOCK occasionally used without checking #ifdef
by h.b.furuseth＠usit.uio.no 23 Nov '10

23 Nov '10

> At least in libldap and liblber EAGAIN and EWOULDBLOCK are > occasionally used without checking whether they are defined or not. > Either the checks should be removed, counting on the fact that these > error codes are always defined, or they should be used consistently. I'd say the libldap #ifdefs can safely be removed by now: "cvs annotate" says os-ip.c has had unconditional EWOULDBLOCK since rev 1.34 (Aug 1999), and request.c unconditional EAGAIN since rev 1.85 (Aug 2002). No bug reports since then... We need to keep the '#if EWOULDBLOCK != EAGAIN's in switches, though. liblber always #ifdefs them, except in a test program. I suppose these #ifdefs could stay in case someone uses the liblber source stand-alone. -- Hallvard

1 0

(ITS#6723) test programs break on EOF
by h.b.furuseth＠usit.uio.no 23 Nov '10

23 Nov '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.157.206.208) Submitted by: hallvard tests/progs/slapd-tester.c and libraries/libldap/dntest.c use uninitialized buffer data on EOF from stdin. Fixing.

1 0

Re: (ITS#6721) uninitialized timeout in back-ldap
by h.b.furuseth＠usit.uio.no 23 Nov '10

23 Nov '10

Pierangelo Masarati writes: > The way I read the code (at the time of the ITS#6282) if tv_sec < 0 no > timeout was used. In any case, your fix is fine for me. Looking closer, the valgrind complaint was just for Debug() statements. So we can downgrade this ITS description to Fix back-ldap debug output of timeout -- Hallvard

1 0

Re: (ITS#6721) uninitialized timeout in back-ldap
by masarati＠aero.polimi.it 23 Nov '10

23 Nov '10

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 4.2.19 - 4.2.23 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > ITS#6282 introduced > struct timeval tv; > tv.tv_sec = -1; > in back-ldap: extended.c and config.c. This leaves tv_usec uninitialized > and the timeout possibly positive. Fixing to: > struct timeval tv = { -1, 0 }; > The way I read the code (at the time of the ITS#6282) if tv_sec < 0 no timeout was used. In any case, your fix is fine for me. p.

1 0

Re: (ITS#6722) Sortvals broken for some matching rules
by h.b.furuseth＠usit.uio.no 23 Nov '10

23 Nov '10

I wrote: > - The sortvals doc should say it need not sort by ORDERING. Fixing. Never mind that one, I must have looked cross-eyed on the manpage. -- Hallvard

1 0

(ITS#6722) Sortvals broken for some matching rules
by h.b.furuseth＠usit.uio.no 23 Nov '10

23 Nov '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.157.206.208) Submitted by: hallvard slapd.conf:sortvals sorts attribute values by the EQUALITY rule's match result, which can be faster than ORDERING. Or octetStringMatch when no EQUALITY rule, I suppose. Haven't looked closely. However, (1) When an attribute has sortvals set, filtering by the ORDERING rule only tests first/last value. This breaks when the EQUALITY rule gives a different sort order. E.g. string equality sorts by length before contents of the normalized value, for speed. (2) Sortvals should only be settable for attributes whose EQUALITY rule: - imposes an absolute ordering, - always succeeds. At least, this seems cleanest to me. Currently there are no such restrictions: - At least booleanMatch() returns 0 or 1, never -1. Thus (TRUE, FALSE) sort randomly. And we cannot control third-party dynamically loaded EQUALITY rules, nor is it documented they should impose an ordering. - attr_valfind() proceeds with the binary search when value_match() fails so the 'match' to partition by is unknown. This makes little sense, attr_valfind() should fail when this happens. Thus setting sortvals could break previously working functionality, which is why I think it may be better to forbid sortvals for attributes where this can happen. Alternatively, we could allow it if the user sets an "I really mean it" mark for the attribute. (3) Also it makes me nervous to see search.c in back-ldap + back-meta react to SLAP_AT_SORTED_VAL. Are there other backends/overlays which need to do the same? Can some/most of that code be moved into slapd? Fixes for (1)-(2): - Sortvals needs some new flags: One to allow SLAP_AT_SORTED_VAL. SLAP_ATTR_SORT_IS_ORDERING to tell filterentry that ORDERING can use sortvals. And something to help set SLAP_ATTR_SORT_IS_ORDERING. The first would be set for the relevant equality matching rules. Not sure of the last: It could almost be set if (equality rule == ordering rule), but matching rules are passed as parameters so their implementation can act differently for EQUALITY and ORDERING:-( - filterentry.c:test_ava_filter() should ignore SLAP_ATTR_SORTED_VALS if (use == SLAP_MR_ORDERING) && (SLAP_ATTR_SORT_IS_ORDERING is not set). - booleanMatch() needs a fix. Don't know which others, except a marginal case: Rules that can set *matchp = (int) (value->bv_len - asserted->bv_len) need to be more careful when sizeof(ber_len_t) > sizeof(int). I assume we can safely truncate to ber_slen_t, i.e. that OpenLDAP would fail anyway for values with bv_len > max ber_slen_t. I'll fix this where I see it, but I leave the rest to someone else. - attr_valfind() should abort the binary search on failure. Possibly some of its callers must be updated to handle more result codes. In theory it shouldn't happen anyway with my other suggestions, but this looks hairy enough that it seems best to be safe. - The sortvals doc should say it need not sort by ORDERING. Fixing. ################################ Test case: #### sortvals.conf include servers/slapd/schema/core.schema attributetype ( 1.3.6.1.4.1.4203.666.777.1 NAME 'boolTest' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) # dnQualifier has string syntax and an ORDERING rule. sortvals boolTest dnQualifier database hdb directory sortvals.dir suffix st=top # shut up monitor warning database monitor #### sortvals.ldif dn: st=top boolTest: TRUE boolTest: FALSE dnQualifier: bbbb dnQualifier: dd dnQualifier: aaaa objectClass: locality objectClass: extensibleObject st: top dn: st=sub,st=top boolTest: FALSE boolTest: TRUE dnQualifier: aa dnQualifier: dddd objectClass: locality objectClass: extensibleObject st: sub #### sortvals.sh #!/bin/sh -e mkdir sortvals.dir touch sortvals.dir/DB_CONFIG servers/slapd/slapadd -f sortvals.conf -l sortvals.ldif (servers/slapd/slapcat -f sortvals.conf && echo === && servers/slapd/slapcat -f sortvals.conf -a '(dnQualifier<=c)' ) | egrep '^($|[bd=])' #### slapcat output # boolTest sorted differently in the two entries, # 2nd slapcat skips entry #1 since dd <= c even though it has aaaa <= c. dn: st=top boolTest: TRUE boolTest: FALSE dnQualifier: dd dnQualifier: aaaa dnQualifier: bbbb dn: st=sub,st=top boolTest: FALSE boolTest: TRUE dnQualifier: aa dnQualifier: dddd === dn: st=sub,st=top boolTest: FALSE boolTest: TRUE dnQualifier: aa dnQualifier: dddd

1 0

(ITS#6721) uninitialized timeout in back-ldap
by h.b.furuseth＠usit.uio.no 23 Nov '10

23 Nov '10

Full_Name: Hallvard B Furuseth Version: 4.2.19 - 4.2.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ITS#6282 introduced struct timeval tv; tv.tv_sec = -1; in back-ldap: extended.c and config.c. This leaves tv_usec uninitialized and the timeout possibly positive. Fixing to: struct timeval tv = { -1, 0 };

1 0

Re: (ITS#6710) Mods already refreshed on a forwarding server is lost by its consumer
by rein＠OpenLDAP.org 22 Nov '10

22 Nov '10

Just a note that I have switched my reply to -devel. Rein

1 0

(ITS#6720) back-ldap core dump
by olivier.chirossel＠sfr.com 22 Nov '10

22 Nov '10

Full_Name: olivier chirossel Version: 2.4.23 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.39.9.251) Hi I have to migrate from a openldap 2.3.x to openldap 2.4. During this migration phase i want my openldap 2.3.x master replicate with slurpd to my new openldap 2.4.x master mirror mode architecture with some rewriting rules for split my big directory. I configure a proxy ldap using back-ldap with slapo-rwm overlay, but operational attributes related to entry creation and modification are proxied, even when i put « lastmod off » in the conf, contrary of the man of slapd-ldap So i put rw-map directives in the conf for strip operationnal attributes but this kind of operation generate a core dump dn: neufDhcpIP=10.145.250.119,suffix=9,o=auth,dc=neuf,dc=fr changetype: modify delete: neufDhcpOption neufDhcpOption: 1;255.255.255.0 - replace: entryCSN entryCSN: 20100511215647Z#000024#00#000000 - replace: modifiersName modifiersName: cn=manager,dc=neuf,dc=fr - replace: modifyTimestamp modifyTimestamp: 20100511215647Z dn: neufDhcpIP=10.145.250.119,suffix=9,o=auth,dc=neuf,dc=fr changetype: modify add: neufDhcpOption neufDhcpOption: 1;255.255.255.128 - replace: entryCSN entryCSN: 20100511215647Z#000024#00#000000 - replace: modifiersName modifiersName: cn=manager,dc=neuf,dc=fr - replace: modifyTimestamp modifyTimestamp: 20100511215647Z Core was generated by `openldap-2.4.23/servers/slapd/slapd -F /etc/openldap/slapd-ldap.d -h ldap://10.'. Program terminated with signal 6, Aborted. [New process 7995] [New process 7994] [New process 7990] [New process 7989] #0 0x00007f01373f9ed5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00007f01373f9ed5 in raise () from /lib/libc.so.6 #1 0x00007f01373fb3f3 in abort () from /lib/libc.so.6 #2 0x00007f0137436408 in __libc_message () from /lib/libc.so.6 #3 0x00007f013743b9a8 in malloc_printerr () from /lib/libc.so.6 #4 0x00007f013743dab6 in free () from /lib/libc.so.6 #5 0x000000000055b8e2 in ber_bvarray_free_x (a=0x26de840, ctx=0x0) at memory.c:737 #6 0x000000000046e3a1 in slap_mod_free (mod=0x26d07f0, freeit=0) at mods.c:461 #7 0x000000000046e42d in slap_mods_free (ml=0x26d07f0, freevals=1) at mods.c:481 #8 0x0000000000437960 in do_modify (op=0x25d02e0, rs=0x41d24cb0) at modify.c:187 #9 0x000000000041f6ef in connection_operation (ctx=0x41d24e00, arg_v=<value optimized out>) at connection.c:1109 #10 0x00000000004203dd in connection_read_thread (ctx=0x41d24e00, argv=<value optimized out>) at connection.c:1245 #11 0x0000000000534080 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #12 0x00007f0137f21fc7 in start_thread () from /lib/libpthread.so.0 #13 0x00007f013749764d in clone () from /lib/libc.so.6 #14 0x0000000000000000 in ?? () (gdb) My conf : database ldap suffix "dc=neuf,dc=fr" rootdn "cn=manager,dc=neuf,dc=fr" rootpw secret updatedn "cn=manager,dc=neuf,dc=fr" uri "ldap://127.0.0.1/" idassert-bind bindmethod=simple binddn="cn=manager,dc=neuf,dc=fr" credentials=secret overlay rwm rwm-rewriteEngine on rwm-rewriteContext default rwm-rewriteRule "neufDhcpIP=([0-9\\.]+)([0-9]{1}),ou=People,o=auth,dc=neuf,dc=fr$" "neufDhcpIP=$1$2,suffix=$2,o=auth,dc=neuf,dc=fr" rwm-map attribute neufDhcpIP neufDhcpIP rwm-map attribute neufDhcp82 neufDhcp82 rwm-map attribute neufDhcpOption neufDhcpOption rwm-map attribute neufDhcp60 neufDhcp60 rwm-map attribute neufDhcpRelay neufDhcpRelay rwm-map attribute neufDhcpComment neufDhcpComment rwm-map attribute neufDhcpUnique neufDhcpUnique rwm-map attribute neufDhcpProvider neufDhcpProvider rwm-map attribute neufDhcpFQDN neufDhcpFQDN rwm-map attribute neufDhcp82b neufDhcp82b rwm-map attribute neufDhcpMac neufDhcpMac rwm-map attribute neufDhcpSiaddr neufDhcpSiaddr rwm-map attribute neufDhcpBootfilename neufDhcpBootfilename rwm-map attribute neufBTID neufBTID rwm-map attribute neufBTOption neufBTOption rwm-map attribute neufTWINOption neufTWINOption rwm-map attribute neufE28Option neufE28Option rwm-map attribute circuitid circuitid rwm-map attribute clientid clientid rwm-map attribute device device rwm-map attribute clientoffer clientoffer rwm-map attribute ispid ispid rwm-map attribute suspended suspended rwm-map attribute neufDhcpIPb neufDhcpIPb rwm-map attribute neufDhcpOptionb neufDhcpOptionb rwm-map attribute idworkflow idworkflow rwm-map attribute neufDhcpRelayIP neufDhcpRelayIP rwm-map attribute interceptID interceptID rwm-map attribute interceptEndpoint interceptEndpoint rwm-map attribute neufDhcpRadiusOption neufDhcpRadiusOption rwm-map attribute suffix suffix rwm-map attribute dc dc rwm-map attribute o o rwm-map attribute ou ou rwm-map attribute cn cn rwm-map objectclass neufDhcpOption1 neufDhcpOption1 rwm-map objectclass neufDhcpOption5 neufDhcpOption5 rwm-map objectclass neufDhcpOption1R neufDhcpOption1R rwm-map objectclass neufDhcpOption35 neufDhcpOption35 rwm-map objectclass neufBTOption neufBTOption rwm-map objectclass neufDhcpOptionwifi neufDhcpOptionwifi rwm-map objectclass Dhcp82 Dhcp82 rwm-map objectclass ClientDevice ClientDevice rwm-map objectclass DhcpDevice DhcpDevice rwm-map objectclass suffixobj suffixobj rwm-map objectclass OrganizationalUnit OrganizationalUnit rwm-map objectclass Organization Organization rwm-map objectclass dcObject dcObject rwm-map objectclass domain domain rwm-map objectclass device device rwm-map attribute * rwm-map objectclass * Thanks in avance for your help Regards,

1 0

Re: (ITS#6700) memberOf overlay does not handle MODRDN correctly
by masarati＠aero.polimi.it 22 Nov '10

22 Nov '10

raphael.ouazana(a)linagora.com wrote: > When using memberOf overlay, a MODRDN request on a member does not update > correctly the matching group, even if the memberof-refint option is set to > true. > > In my little understanding, memberof_value_modify calls op->o_bd->be_modify > which calls back the overlay code, and finally never reach the backend. Guess what, modrdn is the only operation test052 does not check :( WOrking at it. Thanks, p.

1 0

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by h.b.furuseth＠usit.uio.no 22 Nov '10

22 Nov '10

Some issues with tests/progs/slapd-mtread.c: - snprintf format "%04.4d" is not standard. How about just "%04d"? - However, shouldn't 'me' be 'myidx' in those snprintfs and when computing 'thisconn = (me + j) % noconns;' ? - A thread ID can be a struct, in which case whoami() will fail. OpenLDAP (the TLS code) already fails in that case, but still, no need to add do that. Could pass 'myidx' around, or create a thread-local variable for it with ldap_pvt_thread_key_create(). - It says "initially developed by Kurt Spanier", shouldn't that be Doug Leavitt? - scripts/test060-mt-hot takes a long time and can generate 2G of logs. Maybe it should run with a lesser loglevel by default? Put : ${SLAPD_DEBUG=0x4100} -- by default, avoid 1.-2 gigabytes of logs before sourcing defines.sh. -- Hallvard

1 0

Re: (ITS#6715) Broken 'sortvals' for attr with 1 value
by h.b.furuseth＠usit.uio.no 22 Nov '10

22 Nov '10

Also attr_valfind() breaks with sortvals if #values = 0. Not sure if it can be called that way, but it doesn't hurt to handle it right. -- Hallvard

1 0

(ITS#6719) syncrepl_add_glue_ancestors() uninitialized return
by h.b.furuseth＠usit.uio.no 22 Nov '10

22 Nov '10

Full_Name: Hallvard B Furuseth Version: 2.4.23, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard syncrepl_add_glue_ancestors() returns 'rc' uninitialized if the 'else' branch of 'if ( ndn.bv_len > be->be_nsuffix[0].bv_len )' is taken: Then the loop is not entered. This also means the 'else' branch is useless. Should it be doing something more? Found with gcc -O -Wuninitialized . 'make test' does not seem to enter the 'else'.

1 0

Re: (ITS#6710) Mods already refreshed on a forwarding server is lost by its consumer
by hyc＠symas.com 21 Nov '10

21 Nov '10

rein(a)OpenLDAP.org wrote: > On 11/15/10 16:39 , rein(a)OpenLDAP.org wrote: >> New syncprov consumers connecting to a forwarding server and presenting an >> apperently up-to-date cookie will loose any mods that have already taken place >> on the forwarding server if it itself is refreshing from its provider. This >> should not be a problem if the forwarding server have a sufficiently large >> syncprov log, but a fix for servers without is coming. > The currently committed fix for this its leaves one problem open. If a > forwarding server restarts in the middle of the refresh phase, after > making some changes but before updating the csn, new consumers > connecting with an apparently up to date csn set after the server comes > up again will not know that the context is dirty and will loose these > changes. The same problem arise if the server restarts between the time > a locally initiated delete operation is performed in the database and > the accompanying csn set is saved. > > A fix could be to always assume the context is dirty after start up, and > thereby forcing all clients to undergo the refresh phase even if they > are in sync until some operation that updates the csn set is performed. > An unnecessary refresh is probably better than loosing changes.. I haven't had the opportunity to review these patches yet, but the bug description sounds a little flaky to me. The original design is this: when a consumer requests a refresh from the provider, the provider uses a snapshot of its current contextCSN. All changes from the consumer's cookie to this snapshot (inclusive) are sent to the consumer. Any changes currently in progress that have not yet been committed will be skipped until the next refresh. Nothing is lost, it's simply delayed, and that's in accordance with syncrepl's "eventual convergence" model. Likewise, the provider only updates its contextCSN when a change is fully committed. syncprov should NOT need to defer any consumer while it has outstanding mods. There is no reason that would be needed by the sync protocol. Servers only update their contextCSN after an entire refresh has completed. If a downstream consumer connects while a forwarder is still refreshing, the consumer should receive nothing. (Or, it should only receive the changes between its cookie and the server's committed contextCSN, if any.) You may very well have found bugs in the implementation, but it sounds to me like you've changed the overall behavior to something outside of the original design. -- -- 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#6718) Send new-cookie messages to all consumers
by rein＠OpenLDAP.org 21 Nov '10

21 Nov '10

Full_Name: Rein Tollevik Version: CVS head OS: Irrelevant URL: Submission from: (NULL) (84.215.59.121) Submitted by: rein When syncprov updates its csn as a result of syncrepl updating its, syncprov currently sends NEW_COOKIE messages only to those consumers that replicate the entry where the csn is stored. It should be sent to all consumers. A fix is coming. -- Rein Tollevik Basefarm AS

1 0

Re: (ITS#6710) Mods already refreshed on a forwarding server is lost by its consumer
by rein＠OpenLDAP.org 21 Nov '10

21 Nov '10

On 11/15/10 16:39 , rein(a)OpenLDAP.org wrote: > New syncprov consumers connecting to a forwarding server and presenting an > apperently up-to-date cookie will loose any mods that have already taken place > on the forwarding server if it itself is refreshing from its provider. This > should not be a problem if the forwarding server have a sufficiently large > syncprov log, but a fix for servers without is coming. The currently committed fix for this its leaves one problem open. If a forwarding server restarts in the middle of the refresh phase, after making some changes but before updating the csn, new consumers connecting with an apparently up to date csn set after the server comes up again will not know that the context is dirty and will loose these changes. The same problem arise if the server restarts between the time a locally initiated delete operation is performed in the database and the accompanying csn set is saved. A fix could be to always assume the context is dirty after start up, and thereby forcing all clients to undergo the refresh phase even if they are in sync until some operation that updates the csn set is performed. An unnecessary refresh is probably better than loosing changes.. Rein

1 0

(ITS#6717) syncprov performs unnecessary presentations/refreshes.
by cmikk＠qwest.net 19 Nov '10

19 Nov '10

Full_Name: Chris Mikkelson Version: 2.4.23 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.147.85.37) I have a multimaster setup, and some read-only slaves mirroring the data with syncrepl. In some circumstances, I've noticed that restarting a slave server leads to a full presentation, even though the masters have an adequately sized sessionlog. This makes refreshOnly synchronization prohibitively expensive. It appears that the problem is as follows: The syncprov overlay uses the minimum CSN from the client cookie to decide where to start synchronization, regardless of whether that CSN has changed relative to the same SID's CSN on the provider. For example: Provider state: CSN: <1 second ago>...#001#... CSN: <1 year ago>.....#002#... sessionlog mincsn: <1 hour ago>...#001#... Consumer state: CSN: <1 minute ago>...#001#... CSN: <1 year ago>.....#002#... <-- same as SID 2 CSN on provider The syncprov overly will take the mincsn from the consumer cookie (the <1 year ago> one above) and compare it to the sessionlog mincsn when deciding whether to do a full presentation. Since the SID 2 CSN hasn't changed in the above example, the consumer is up to date on changes recorded on SID 2, so the SID 1 CSN from the cookie should be used. To reproduce: * Set up slapd servers ID 1 and 2 as multimaster nodes, and a third slapd server replicating from server 1. * Insert one entry into server ID 2, and restart servers 1 and 2. * Insert entries into Server ID 1. * Perform enough modifications / deletions on Server ID 1 to cause entries to be purged from the sessionlog (see ITS #6716). * Wait for slave to catch up, then stop the slave. * Do any modification on Server ID 1 (only need to change the SID 1 contextCSN) * Restart slave. Server will present entries to the slave rather than replaying the session log.

1 0

(ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by cmikk＠qwest.net 19 Nov '10

19 Nov '10

Full_Name: Chris Mikkelson Version: 2.4.23 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.147.85.37) On line 2875 of servers/slapd/overlays/syncprov.c (release 2.4.23), the sessionlog mincsn is initialized to a zero-length value. if ( !sl ) { sl = ch_malloc( sizeof( sessionlog ) + LDAP_PVT_CSNSTR_BUFSIZE ); sl->sl_mincsn.bv_val = (char *)(sl+1); sl->sl_mincsn.bv_len = 0; sl->sl_num = 0; sl->sl_head = sl->sl_tail = NULL; ldap_pvt_thread_mutex_init( &sl->sl_mutex ); si->si_logs = sl; } >From there, sl->sl_mincsn isn't touched until log entries are purged from the sessionlog on line 1522: while ( sl->sl_num > sl->sl_size ) { se = sl->sl_head; sl->sl_head = se->se_next; strcpy( sl->sl_mincsn.bv_val, se->se_csn.bv_val ); sl->sl_mincsn.bv_len = se->se_csn.bv_len; ch_free( se ); sl->sl_num--; } So, after the sessionlog has its first entry recorded and before it has its first entry received, sl->sl_mincsn is a zero-length value, which means the following comparison on line 2536: if ( sl->sl_num > 0 && ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 ) { do_present = 0; will evaluate to true in cases where it should not. A quick fix would be to compare directly against the CSN of the sessionlog's head: --- syncprov.c.orig 2010-11-17 14:07:26.000000000 -0600 +++ syncprov.c 2010-11-19 16:50:58.000000000 -0600 @@ -2533,7 +2533,7 @@ /* Are there any log entries, and is the consumer state * present in the session log? */ - if ( sl->sl_num > 0 && ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 ) { + if ( sl->sl_num > 0 && ber_bvcmp( &mincsn, &sl->sl_head->se_csn ) >= 0 ) { do_present = 0; /* mutex is unlocked in playlog */ syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids );

1 0

Re: ITS#6713
by masarati＠aero.polimi.it 19 Nov '10

19 Nov '10

DevMan wrote: > Please let me know the upgradation procedure. <http://www.openldap.org/doc/admin24/install.html> In general, <http://www.openldap.org/doc/admin24/index.html> p.

1 0

Re: ITS#6713
by devman1624＠yahoo.com 19 Nov '10

19 Nov '10

Please let me know the upgradation procedure. Thx DevMan Sent from my iPhone On Nov 18, 2010, at 3:33 PM, Pierangelo Masarati <masarati(a)aero.polimi.it> w= rote: > Please note that the current release is 2.4.23; since 2.4.16 many issues h= ave been fixed. If the problem persists after upgrading, please make sure y= ou provide useful information, as illustrated here <http://www.openldap.org/= faq/data/cache/56.html> and in subordinate links. >=20 > p.

1 0

(ITS#6715) Broken 'sortvals' for attr with 1 value
by h.b.furuseth＠usit.uio.no 19 Nov '10

19 Nov '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd.conf:'sortvals ATTR' sometimes complains attributeType ATTR value #1 provided more than once when ATTR has one value, because slapd/modify.c:slap_sort_vals() then leaves the result value 'rc' uninitialized. Fixing.

1 0

(ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by rmeggins＠redhat.com 18 Nov '10

18 Nov '10

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-use-non-blocking-semantics-… Submission from: (NULL) (76.113.111.209) This patch implements full non-blocking semantics for the MozNSS crypto implementation in the same manner as the openssl and gnutls implementations. SSL_ForceHandshake can be called repeatedly until it gets enough data to complete. One wrinkle is that, when SSL_ForceHandshake returns PR_WOULD_BLOCK_ERROR, we have no way of knowing if it needs data for a read or a write (a la openssl SSL_ERROR_WANT_WRITE and SSL_ERROR_WANT_READ). In order to keep track of that, we use the io_flag in the tls_data object - if the last operation called was a read/recv, we set the io_flag to TLSM_READ, and similar for send/write and TLSM_WRITE. This way, the upflags function knows how to set the sbiod needs_read and needs_write flags appropriately. I also added special handling for the common case where the client uses ldapTOOL -Z and the TLS fails from the client side (e.g. bogus CA cert file). In this case, tlsm_session_accept will get a plain LDAP message beginning with LBER_SEQUENCE instead of a valid SSL header. The code can short circuit the process and return a more meaningful error message. The tlsm_is_io_ready() function is now obsolete - keeping track of the io_flag, plus using the function SSL_DataPending(), removes the need for the former function. I added a convenience function tlsm_get_pvt_tls_data() to get the tls_data associated with the tlsm_session (secure PRFileDesc). This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat 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

ITS#6712
by masarati＠aero.polimi.it 18 Nov '10

18 Nov '10

Thanks for the report. "hasSubordinates" is generated, not stored in the database; this may explain why multiple values appear despite its "single-valuedness". I'm investigating... p.

1 0

ITS#6713
by masarati＠aero.polimi.it 18 Nov '10

18 Nov '10

Please note that the current release is 2.4.23; since 2.4.16 many issues have been fixed. If the problem persists after upgrading, please make sure you provide useful information, as illustrated here <http://www.openldap.org/faq/data/cache/56.html> and in subordinate links. p.

1 0

(ITS#6713) slad crashing automatically in production server
by devman1624＠yahoo.com 18 Nov '10

18 Nov '10

Full_Name: DevMan Version: 2.4.16 OS: RHEL5.4 64 bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.191.136.3) Hi All, I am facing issue in my prod server. PLease find the below details: DS: Openldap2.4.16(2 Multimaster with one slave) Database: BDB4.7.25 OS: RHEL5.4 64 bit Number of databases: 2 Number of entries in one database is 9lakhs and in second database is 2000. RAM: 2GB CPU: 2(Model name: Intel(R) Xeon(R) CPU E5504 @ 2.00GHz) Issue: slapd automatically killed once in a day or some time 3 in a day. I have run the below command and found segfault error 4: [root@MYINSGGNSBILDAP2 openldap]# dmesg |grep slapd slapd[30387]: segfault at 0000000000000017 rip 00000000004dca25 rsp 00007fff61425f80 error 4 slapd[32121]: segfault at 0000000000000048 rip 0000003cd8008950 rsp 0000000042554948 error 4 slapd[1013]: segfault at 0000000000000048 rip 0000003cd8008950 rsp 000000004233c948 error 4 slapd[13060]: segfault at 0000000000000000 rip 0000003cd747997a rsp 00000000422408e8 error 4 slapd[24417]: segfault at 0000000000000008 rip 000000000048d6b2 rsp 0000000046333560 error 4 slapd[694]: segfault at 0000000000000008 rip 000000000048d6b2 rsp 0000000043cfa560 error 4 slapd[1068]: segfault at 0000000000000008 rip 000000000048d6b2 rsp 0000000041446560 error 4 slapd[5557]: segfault at 0000000000000008 rip 000000000048d6b2 rsp 0000000041fd2560 error 4 slapd[15633]: segfault at 0000000000000008 rip 000000000048d6b2 rsp 0000000041a9d560 error 4 slapd[31922]: segfault at 0000000000000008 rip 000000000048d6b2 rsp 0000000043312560 error 4 slapd[13961]: segfault at 0000000000000000 rip 0000003cd747997a rsp 000000004230f4e8 error 4 slapd[14807]: segfault at 0000000000000048 rip 0000003cd8008950 rsp 0000000041523948 error 4 Please help me here to resolve this problem. Thx DevMan

1 0

(ITS#6712) dont-use-copy/syncrepl/chain hasSubordinates extra vals
by david.delaharpe.golden＠ichec.ie 17 Nov '10

17 Nov '10

Full_Name: David De La Harpe Golden (ICHEC) Version: 2.4.23 OS: debian/unstable URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.1.200.66) I was playing with the experimental "dont-use-copy" ldap control in conjunction with a basic test provider-consumer syncrepl setup and chain overlay back to the provider on the consumer. I realise the control is experimental and the issue is not major, but anyway, better to report these things: Seems that when the control is used in a search request to the consumer, hasSubordinates on the returned value is getting extra values. As hasSubordinates is AFAICS defined as a single-value attribute, that's strange. # e.g. Test using python-ldap import ldap from ldap.controls import LDAPControl class _ExpDontUseCopyControl(LDAPControl): controlType = '1.3.6.1.4.1.4203.666.5.15' provider = ldap.open('localhost', 3389) consumer = ldap.open('localhost', 389) provider.bind('cn=something,dc=example,dc=com', 'somepw') consumer.bind('cn=something,dc=example,dc=com', 'somepw') provider.search_ext_s('cn=foo,dc=example,dc=com', ldap.SCOPE_BASE, '(objectClass=*)', ['hasSubordinates'], serverctrls=[]) => [('cn=foo,dc=example,dc=com', {'hasSubordinates': ['FALSE']})] provider.search_ext_s('cn=foo,dc=example,dc=com', ldap.SCOPE_BASE, '(objectClass=*)', ['hasSubordinates'], serverctrls=[_ExpDontUseCopyControl(True)]) => [('cn=foo,dc=example,dc=com', {'hasSubordinates': ['FALSE']})] consumer.search_ext_s('cn=foo,dc=example,dc=com', ldap.SCOPE_BASE, '(objectClass=*)', ['hasSubordinates'], serverctrls=[]) => [('cn=foo,dc=example,dc=com', {'hasSubordinates': ['FALSE']})] consumer.search_ext_s('cn=foo,dc=example,dc=com', ldap.SCOPE_BASE, '(objectClass=*)', ['hasSubordinates'], serverctrls=[_ExpDontUseCopyControl(True)]) => [('cn=foo,dc=example,dc=com', {'hasSubordinates': ['FALSE', 'FALSE']})]

1 0

(ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org 16 Nov '10

16 Nov '10

Full_Name: Kartik Subbarao Version: 2.4.23 OS: Debian Linux 5.0.5 URL: ftp://ftp.openldap.org/incoming/kartik_subbarao.101116.tgz Submission from: (NULL) (76.99.175.5) I'm trying to get a consumer server to forward ppolicy-related updates to its provider server, and to use certificate-based authentication (SASL EXTERNAL) over STARTTLS when authenticating to the provider. I'm running into multiple problems here. The core problem seems to be that enabling ppolicy_forward_updates breaks the chaining overlay such that it binds anonymously instead of with SASL EXTERNAL. Another problem is that bind operations to the consumer server start to return two result messages -- one with the error code of the chained operation, and one with the error code of the bind operation. To simplify reproducing the problem, I've worked with test022-ppolicy in the openldap test framework. Here, I ran into another issue. I can't seem to be able to configure sasl external/starttls chaining properly with the cn=config style configuration that test022-ppolicy applies. The self-signed cert that I'm using works fine with replication, but it doesn't seem to work with chaining. This may or may not be another issue that needs to be resolved. In any case, with the attached files in the ITS, I hope that what I'm trying to do and the results that I'm getting should be as clear as possible.

1 0

Re: (ITS#6703) Patch - Mozilla NSS - reject non-file key and cert files
by rmeggins＠redhat.com 15 Nov '10

15 Nov '10

On 11/15/2010 01:22 PM, Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> On 11/15/2010 12:39 PM, Howard Chu wrote: >>> rmeggins(a)redhat.com wrote: >>>> Full_Name: Rich Megginson >>>> Version: 2.4.23 (current CVS HEAD) >>>> OS: RHEL5 >>>> URL: >>>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-reject_non_file_key_cert_pe… >>>> >>>> Submission from: (NULL) (76.113.111.209) >>>> >>>> >>>> If you specify a directory instead of a file to TLS_CACERT, or if one >>>> of the >>>> items in the TLS_CACERTDIR is a directory, the NSS PEM reader will >>>> crash. This >>>> patch rejects any item which looks like a directory. >>> >>> It sounds like this is a bug that ought to be patched in the NSS PEM >>> reader instead, no? >>> >> Yes, you are correct. I have filed this bug - >> https://bugzilla.redhat.com/show_bug.cgi?id=653619 >> But the patch to openldap will allow it to bypass this problem. > > OK. I've reviewed and committed all of your patches 6703-6706. > Thanks!

1 0

Re: (ITS#6703) Patch - Mozilla NSS - reject non-file key and cert files
by hyc＠symas.com 15 Nov '10

15 Nov '10

rmeggins(a)redhat.com wrote: > On 11/15/2010 12:39 PM, Howard Chu wrote: >> rmeggins(a)redhat.com wrote: >>> Full_Name: Rich Megginson >>> Version: 2.4.23 (current CVS HEAD) >>> OS: RHEL5 >>> URL: >>> ftp://ftp.openldap.org/incoming/openldap-2.4.23-reject_non_file_key_cert_pe… >>> Submission from: (NULL) (76.113.111.209) >>> >>> >>> If you specify a directory instead of a file to TLS_CACERT, or if one >>> of the >>> items in the TLS_CACERTDIR is a directory, the NSS PEM reader will >>> crash. This >>> patch rejects any item which looks like a directory. >> >> It sounds like this is a bug that ought to be patched in the NSS PEM >> reader instead, no? >> > Yes, you are correct. I have filed this bug - > https://bugzilla.redhat.com/show_bug.cgi?id=653619 > But the patch to openldap will allow it to bypass this problem. OK. I've reviewed and committed all of your patches 6703-6706. -- -- 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#6703) Patch - Mozilla NSS - reject non-file key and cert files
by rmeggins＠redhat.com 15 Nov '10

15 Nov '10

On 11/15/2010 12:39 PM, Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: 2.4.23 (current CVS HEAD) >> OS: RHEL5 >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-reject_non_file_key_cert_pe… >> Submission from: (NULL) (76.113.111.209) >> >> >> If you specify a directory instead of a file to TLS_CACERT, or if one >> of the >> items in the TLS_CACERTDIR is a directory, the NSS PEM reader will >> crash. This >> patch rejects any item which looks like a directory. > > It sounds like this is a bug that ought to be patched in the NSS PEM > reader instead, no? > Yes, you are correct. I have filed this bug - https://bugzilla.redhat.com/show_bug.cgi?id=653619 But the patch to openldap will allow it to bypass this problem.

1 0

Re: (ITS#6703) Patch - Mozilla NSS - reject non-file key and cert files
by hyc＠symas.com 15 Nov '10

15 Nov '10

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 (current CVS HEAD) > OS: RHEL5 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-reject_non_file_key_cert_pe… > Submission from: (NULL) (76.113.111.209) > > > If you specify a directory instead of a file to TLS_CACERT, or if one of the > items in the TLS_CACERTDIR is a directory, the NSS PEM reader will crash. This > patch rejects any item which looks like a directory. It sounds like this is a bug that ought to be patched in the NSS PEM reader instead, no? -- -- 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#6710) Mods already refreshed on a forwarding server is lost by its consumer
by rein＠OpenLDAP.org 15 Nov '10

15 Nov '10

Full_Name: Rein Tollevik Version: CVS head OS: Irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.59.121) Submitted by: rein New syncprov consumers connecting to a forwarding server and presenting an apperently up-to-date cookie will loose any mods that have already taken place on the forwarding server if it itself is refreshing from its provider. This should not be a problem if the forwarding server have a sufficiently large syncprov log, but a fix for servers without is coming. -- Rein Tollevik Basefarm AS

1 0

(ITS#6709) Active mods not replicated to new consumers
by rein＠OpenLDAP.org 15 Nov '10

15 Nov '10

Full_Name: Rein Tollevik Version: CVS head OS: Irrelevant URL: Submission from: (NULL) (84.215.59.121) Submitted by: rein New syncprov consumers connecting when there are active mods risk loosing these mods, where an active mod is any mod that have called syncprov_op_mod() but not yet the syncprov_op_response() or syncprov_op_cleanup() callbacks. A fix is coming. -- Rein Tollevik Basefarm AS

1 0

Re: (ITS#6693) Value dependent ACL issues
by rhafer＠suse.de 15 Nov '10

15 Nov '10

I just submitted the fix to HEAD. The changes are in: servers/slapd/acl.c r1.355 servers/slapd/slap.h r1.898 Ralf

1 0

(ITS#6708) Race condition fixing syncprov filter
by rein＠OpenLDAP.org 15 Nov '10

15 Nov '10

Full_Name: Rein Tollevik Version: CVS head OS: Irrelevant URL: Submission from: (NULL) (84.215.59.121) Submitted by: rein In ITS#6555 a fix to skip the and/ge filter stuck in front of the consumers filter was added, but this left a race condition between modifying the filter and noting it in the flags. There is a race both when the filter is stuck in the front and when it gets removed again when the op is detached. A fix is coming. -- Rein Tollevik Basefarm AS

1 0

(ITS#6707) Syncrepl may reuse presentlist
by rein＠OpenLDAP.org 15 Nov '10

15 Nov '10

Full_Name: Rein Tollevik Version: CVS head OS: Irrelevant URL: Submission from: (NULL) (84.215.59.121) Submitted by: rein If syncrepl gets interrupted during the present phase it may reuse the presentlist on the next connection. Any entries in the list that gets deleted on the provider in mean time will not be deleted on the consumer. A fix is coming. -- Rein Tollevik Basefarm AS

1 0

Re: (ITS#6556) test031 core dumps after applying first filter
by ian＠uns.ac.rs 15 Nov '10

15 Nov '10

slap_sl_free dumps core here because it gets passed a bogus bv_val (from the ma_value field of an instance of struct MatchingRuleAssertion). As far as I can see, the original bv_val gets clobbered in get_comp_filter (servers/slapd/component.c), line 350: bv->bv_val = cav.cav_ptr; Commenting that line out fixes the core dump. I suspect that the assignment is there to support nested component filters (see lines 1039 et seq. in the same file). Earlier versions of OpenLDAP had different logic in slap_sl_free, which skipped the offending pointer (and thus probably leaving a memory leak). i.

1 0

(ITS#6706) Patch - Mozilla NSS - improve trace messages
by rmeggins＠redhat.com 12 Nov '10

12 Nov '10

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-improve_trace_messages-2010… Submission from: (NULL) (76.113.111.209) The trace messages from tls_m.c are unhelpful and misleading in many cases. SSL_SecurityStatus() only works after the first handshake is complete, so use a handshake callback to print that information instead. Since tlsm_session_chkhost handles the SSL_ERROR_BAD_CERT_DOMAIN case, we don't need to print out a message for that error. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat 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#6705) Patch - Mozilla NSS - should only use
by rmeggins＠redhat.com 12 Nov '10

12 Nov '10

This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat 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

(ITS#6705) Patch - Mozilla NSS - should only use ".0" files in cacertdir
by rmeggins＠redhat.com 12 Nov '10

12 Nov '10

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-look_only_for_.0_cacertdir_… Submission from: (NULL) (76.113.111.209) When cacertdir is specified, only the files that have openssl c_hash hashed file names ending in ".0" should be used.

1 0

(ITS#6704) Patch - Mozilla NSS - use both cacert and cacertdir
by rmeggins＠redhat.com 12 Nov '10

12 Nov '10

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-use_both_cacert_and_cacertd… Submission from: (NULL) (76.113.111.209) The code should attempt to use both TLS_CACERT and TLS_CACERTDIR if both are specified. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat 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

(ITS#6703) Patch - Mozilla NSS - reject non-file key and cert files
by rmeggins＠redhat.com 12 Nov '10

12 Nov '10

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-reject_non_file_key_cert_pe… Submission from: (NULL) (76.113.111.209) If you specify a directory instead of a file to TLS_CACERT, or if one of the items in the TLS_CACERTDIR is a directory, the NSS PEM reader will crash. This patch rejects any item which looks like a directory. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat 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#6702) slappasswd prompts missing
by d＠delphij.net 12 Nov '10

12 Nov '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/11/10 20:51, David Gessel wrote: > Excellent. > > Xin Li had a partial patch earlier tonight that got the prompts directed properly to console. Thanks. To Howard, I think getpassphrase(3) is Solaris specific interface and not part of standard. On FreeBSD, getpass(3) returns a buffer pointer that contains at most 128 (_PASSWORD_LEN) characters, which should fulfill the need of OpenBSD but shorter than Solaris[1] which have 256, not counting the terminating nul character. Note that FreeBSD do have a readpassphrase(3) extension which provide more flexibility. I am not sure, however, whether we should implement the Solaris behavior for getpassphrase(3), as it's not a standard defined interface? Is there any other operating system that provide getpassphrase(3) and have the same behavior? If it's desirable we could have it implemented on FreeBSD this way: ================= char * getpassrase(const char *prompt) { static char buf[256 + 1]; return(readpassphrase(prompt, buf, sizeof(buf), RPP_ECHO_OFF)); } ================= Please advise, thanks! [1] http://docs.sun.com/app/docs/doc/816-5168/getpassphrase-3c?l=en&n=1&a=view > -------- Original Message -------- > Subject: Re: (ITS#6702) slappasswd prompts missing > From: Howard Chu <hyc(a)symas.com> > To: gessel(a)blackrosetech.com > Date: Thu Nov 11 2010 19:18:29 GMT-0800 (Pacific Standard Time) > >> Apparently FreeBSD doesn't provide a usable getpassphrase() in its libc, so a >> replacement in the OpenLDAP code is used instead. The OpenLDAP code is now >> fixed in HEAD. >> - -- Xin LI <delphij(a)delphij.net> http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM3YW3AAoJEATO+BI/yjfB2jsIANUBBR2Cu/uhd7w8SDmfWJkL UcibY5xL4i1gg2CM2DR/SgVqUYF/SHnGmMECgmu7CVRvXRNPn7Zp7TzhfYJgM7SJ lYqE5+uajyGUt3N3z7bB4BT9GF6PTyXhWUDsdxc1IHcQ2Dvpq/3Ih7vuCQmAimCv NJ9CXQYJPLflRo8RAMmNtiYeiZjMWK9PjrfC7CuAYKPvhKGFMQ5o7NXBZ8T+16WC Igbw7DKALAPBZmV2hXbwMQAYJ8hBUkDlph2U8k7zBTfIkWSqx+DDeY/CaOmUnb9A puUTm3WEYI2MxwlOVLnvy7QRNFsXejFvXkZN5ZTPoDbBT7MZRFrOn9gKQRGF4D8= =9iQc -----END PGP SIGNATURE-----

1 0

Re: (ITS#6702) slappasswd prompts missing
by gessel＠blackrosetech.com 11 Nov '10

11 Nov '10

Excellent. Xin Li had a partial patch earlier tonight that got the prompts directed properly to console. -------- Original Message -------- Subject: Re: (ITS#6702) slappasswd prompts missing From: Howard Chu <hyc(a)symas.com> To: gessel(a)blackrosetech.com Date: Thu Nov 11 2010 19:18:29 GMT-0800 (Pacific Standard Time) > gessel(a)blackrosetech.com wrote: >> Note: on editing slapd.conf, I see that prompt IO is directed to the file, not to the console. That is the file contains the prompts: >> "rootpw New password:" >> "Re-enter new password:" >> >> >> > Apparently FreeBSD doesn't provide a usable getpassphrase() in its libc, so a > replacement in the OpenLDAP code is used instead. The OpenLDAP code is now > fixed in HEAD. >

1 0

Re: (ITS#6702) slappasswd prompts missing
by hyc＠symas.com 11 Nov '10

11 Nov '10

gessel(a)blackrosetech.com wrote: > Note: on editing slapd.conf, I see that prompt IO is directed to the file, not to the console. That is the file contains the prompts: > "rootpw New password:" > "Re-enter new password:" > > > Apparently FreeBSD doesn't provide a usable getpassphrase() in its libc, so a replacement in the OpenLDAP code is used instead. The OpenLDAP code is now fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6701) Update to man8 slappasswd: English usage
by hyc＠symas.com 11 Nov '10

11 Nov '10

diver06(a)gmx.net wrote: > Full_Name: Simon Wright > Version: 2.4.23 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.98.32.54) > > > The man page for slappasswd says that encryption scheme names need to be > protected due to "{". This is wrong usage: scheme names may need to be protected > *by* "{" Wrong. The manpage text is correct. The '{' and '}' are part of the scheme names. Since these are also meta-characters in common command shells, they may need to be protected from expansion. This ITS will be closed. -- -- 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#6702) slappasswd prompts missing
by gessel＠blackrosetech.com 11 Nov '10

11 Nov '10

Note: on editing slapd.conf, I see that prompt IO is directed to the file, not to the console. That is the file contains the prompts: "rootpw New password:" "Re-enter new password:"

1 0

(ITS#6702) slappasswd prompts missing
by gessel＠blackrosetech.com 11 Nov '10

11 Nov '10

Full_Name: David Gessel Version: openldap-sasl-server-2.4.23 OS: FreeBSD 8.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.93.181.141) Attempting to insert a hash of the root pw into slapd.conf with the command: # slappasswd >> slapd.conf yields a blank prompt, that is there is no feedback to prompt the user along the lines of: "Enter root password" and "Verify root password" But entering the root password twice with no feedback (and blank characters for security, so completely blind) gets through the command successfully.

1 0

(ITS#6701) Update to man8 slappasswd: English usage
by diver06＠gmx.net 11 Nov '10

11 Nov '10

Full_Name: Simon Wright Version: 2.4.23 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.98.32.54) The man page for slappasswd says that encryption scheme names need to be protected due to "{". This is wrong usage: scheme names may need to be protected *by* "{" Patch: --- openldap-2.4.23/doc/man/man8/slappasswd.8 2010-04-13 22:22:46.000000000 +0200 +++ slappasswd.8 2010-11-11 16:36:28.000000000 +0100 @@ -100,7 +100,7 @@ The default is .BR {SSHA} . -Note that scheme names may need to be protected, due to +Note that scheme names may need to be protected by .B { and .BR } ,

1 0

Re: (ITS#6698) Please add BDB 5.x support for SLAPD
by hyc＠symas.com 11 Nov '10

11 Nov '10

faessler(a)was.ch wrote: > Full_Name: Dominik Fässler > Version: 2.4.23 > OS: FreeBSD (8.1-RELEASE) > URL: > Submission from: (NULL) (62.2.101.221) > > > We know that for the moment only BDB versions 4.4 - 4.8 are supported as backend > for SLAPD. > We would be happy, if you could include support for BDB versions 5.x as well. > (For now we are using 5.1) > Thanx. > Added to configure script in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6700) memberOf overlay does not handle MODRDN correctly
by raphael.ouazana＠linagora.com 10 Nov '10

10 Nov '10

Full_Name: Raphael Ouazana Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) Hi, When using memberOf overlay, a MODRDN request on a member does not update correctly the matching group, even if the memberof-refint option is set to true. In my little understanding, memberof_value_modify calls op->o_bd->be_modify which calls back the overlay code, and finally never reach the backend. Regards, Raphaël Ouazana.

1 0

RE: (ITS#6683) DDS fails with expired branches
by Petteri.Stenius＠ubisecure.com 10 Nov '10

10 Nov '10

Hi, Thank you for your reply. My knowledge about the bdb internals is limited. I have reproduced this issue and reduced it to a small amount of data (see below). I think I have done everything right with regards to setting up and preparing the database and indexes. I've used both ldapmodify and slapadd/slapindex to prepare the db. If you think my indexes are corrupt then can you please give me pointers how to verify? I don't think there exist test cases for operators LE "<=3D" or GE = ">=3D" in the source codes. Thanks, Petteri -----Original Message----- From: Howard Chu [mailto:hyc@symas.com]=20 Sent: Tuesday, November 09, 2010 10:45 AM To: Petteri Stenius Cc: openldap-its(a)openldap.org Subject: Re: (ITS#6683) DDS fails with expired branches Petteri.Stenius(a)ubisecure.com wrote: > Hello, > > Further investigation shows this issue is caused by operator LE search > failing with indexed attributes. Also this indexed search issue is NOT > limited to DDS.=3D20 > > I have reproduced the issue with integerOrderingMatch and > generalizedTimeOrderingMatch.=3D20 > > The piece of code I find suspicious is in servers/back-bdb/idl.c, > somewhere in the middle it reads > > /* skip presence key on range inequality lookups */ > while (rc =3D3D=3D3D 0&& kptr->size !=3D3D len) { > rc =3D3D cursor->c_get( cursor, kptr,&data, flags | > DB_NEXT_NODUP ); > } > > If I remove this block then LE search works as expected with indexed > attributes. The key here seems to be the DB_NEXT_NODUP flag. This flag > causes the iterator block a few lines below to return partial matches. That implies that there's something else corrupt in the index, because the=20 presence key will never be the same size as an equality key. > > Thanks, > Petteri > > -----Original Message----- > From: openldap-bugs-bounces(a)OpenLDAP.org > [mailto:openldap-bugs-bounces@OpenLDAP.org] On Behalf Of > petteri.stenius(a)ubisecure.com > Sent: Monday, October 25, 2010 1:35 PM > To: openldap-its(a)openldap.org > Subject: (ITS#6683) DDS fails with expired branches > > Full_Name:=3D20 > Version: 2.4.23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.197.205.34) > > > Hello, > > I have a directory with branches of dynamicObject entries. It looks like > if the > entryExpireTimestamp value is the same on objects within a branch then > DDS > search for expired objects will only find the top-most object. This > results in > remove failing with message > > DDS dn=3D3D"cn=3D3Dtop,cn=3D3Droot,dc=3D3Dtest" is non-leaf; = deferring. > > > To reproduce > > OpenLDAP 2.4.23, Berkeley DB 4.6.21 > > Use slapadd to prepare directory with following > > dn: cn=3D3DRoot,dc=3D3Dtest > objectClass: top > objectClass: applicationProcess > cn: Root > > dn: cn=3D3Dtop,cn=3D3DRoot,dc=3D3Dtest > objectClass: top > objectClass: device > objectClass: dynamicObject > entryTTL: 60 > entryExpireTimestamp: 20101024113626Z > cn: top > > dn: cn=3D3Dleaf1,cn=3D3Dtop,cn=3D3DRoot,dc=3D3Dtest > objectClass: top > objectClass: device > objectClass: dynamicObject > entryTTL: 60 > entryExpireTimestamp: 20101024113626Z > cn: leaf1 > > dn: cn=3D3Dleaf2,cn=3D3Dtop,cn=3D3DRoot,dc=3D3Dtest > objectClass: top > objectClass: device > objectClass: dynamicObject > entryTTL: 60 > entryExpireTimestamp: 20101024113626Z > cn: leaf2 > > dn: cn=3D3Dleaf3,cn=3D3Dtop,cn=3D3DRoot,dc=3D3Dtest > objectClass: top > objectClass: device > objectClass: dynamicObject > entryTTL: 60 > entryExpireTimestamp: 20101024113626Z > cn: leaf3 > > > Relevant slapd.conf entries > > database bdb > suffix "cn=3D3DRoot,dc=3D3Dtest" > rootdn "cn=3D3DRoot,dc=3D3Dtest" > rootpw "password" > > overlay dds > dds-default-ttl 3600 > dds-min-ttl 60 > dds-interval 60 > dds-state true > index entryExpireTimestamp eq,pres > > access to dn.subtree=3D3D"cn=3D3DRoot,dc=3D3Dtest" > by users write > by * read > > > Running "slapd -d 1 -d 256" produces following > > put_filter: > "(&(objectClass=3D3DdynamicObject)(entryExpireTimestamp<=3D3D201010250824= 46Z )=3D > )" > put_filter: AND > put_filter_list > "(objectClass=3D3DdynamicObject)(entryExpireTimestamp<=3D3D20101025082446= Z)" > put_filter: "(objectClass=3D3DdynamicObject)" > put_filter: simple > put_simple_filter: "objectClass=3D3DdynamicObject" > put_filter: "(entryExpireTimestamp<=3D3D20101025082446Z)" > put_filter: simple > put_simple_filter: "entryExpireTimestamp<=3D3D20101025082446Z" > ber_scanf fmt ({mm}) ber: > ber_scanf fmt ({mm}) ber: > =3D3D> bdb_search > bdb_dn2entry("cn=3D3Droot,dc=3D3Dtest") > =3D3D> bdb_dn2id("cn=3D3Droot,dc=3D3Dtest") > <=3D3D bdb_dn2id: got id=3D3D0x1 > entry_decode: "cn=3D3DRoot,dc=3D3Dtest" > <=3D3D entry_decode(cn=3D3DRoot,dc=3D3Dtest) > search_candidates: base=3D3D"cn=3D3Droot,dc=3D3Dtest" (0x00000001) = scope=3D3D2 > =3D3D> bdb_dn2idl("cn=3D3Droot,dc=3D3Dtest") > =3D3D> bdb_equality_candidates (objectClass) > =3D3D> key_read > <=3D3D bdb_index_read: failed (-30989) > <=3D3D bdb_equality_candidates: id=3D3D0, first=3D3D0, last=3D3D0 > =3D3D> bdb_equality_candidates (objectClass) > =3D3D> key_read > <=3D3D bdb_index_read 4 candidates > <=3D3D bdb_equality_candidates: id=3D3D4, first=3D3D2, last=3D3D5 > =3D3D> bdb_inequality_candidates (entryExpireTimestamp) > =3D3D> key_read > <=3D3D bdb_index_read 1 candidates > =3D3D> key_read > <=3D3D bdb_index_read: failed (-30989) > <=3D3D bdb_inequality_candidates: id=3D3D1, first=3D3D2, last=3D3D2 > bdb_search_candidates: id=3D3D1 first=3D3D2 last=3D3D2 > entry_decode: "cn=3D3Dtop,cn=3D3DRoot,dc=3D3Dtest" > <=3D3D entry_decode(cn=3D3Dtop,cn=3D3DRoot,dc=3D3Dtest) > =3D3D> bdb_dn2id("cn=3D3Dtop,cn=3D3Droot,dc=3D3Dtest") > <=3D3D bdb_dn2id: got id=3D3D0x2 > send_ldap_result: conn=3D3D-1 op=3D3D0 p=3D3D0 > bdb_dn2entry("cn=3D3Dtop,cn=3D3Droot,dc=3D3Dtest") > =3D3D> bdb_dn2id_children("cn=3D3Dtop,cn=3D3Droot,dc=3D3Dtest") > <=3D3D bdb_dn2id_children("cn=3D3Dtop,cn=3D3Droot,dc=3D3Dtest"): (0) > send_ldap_result: conn=3D3D-1 op=3D3D0 p=3D3D0 > DDS dn=3D3D"cn=3D3Dtop,cn=3D3Droot,dc=3D3Dtest" is non-leaf; = deferring. > DDS expired=3D3D0 > > > ldapsearch "(entryExpireTimestamp=3D3D*)" produces > > dn: cn=3D3Dtop,cn=3D3DRoot,dc=3D3Dtest > entryExpireTimestamp: 20101024113626Z > > dn: cn=3D3Dleaf1,cn=3D3Dtop,cn=3D3DRoot,dc=3D3Dtest > entryExpireTimestamp: 20101024113626Z > > dn: cn=3D3Dleaf2,cn=3D3Dtop,cn=3D3DRoot,dc=3D3Dtest > entryExpireTimestamp: 20101024113626Z > > dn: cn=3D3Dleaf3,cn=3D3Dtop,cn=3D3DRoot,dc=3D3Dtest > entryExpireTimestamp: 20101024113626Z > > > where ldapsearch "(entryExpireTimestamp<=3D3D20101024113626Z)" only finds > > dn: cn=3D3Dtop,cn=3D3DRoot,dc=3D3Dtest > entryExpireTimestamp: 20101024113626Z > > > If I change all timestamps to distinct values then expiration of > complete > branches works as expected. > > > Thanks, > Petteri > > > --=20 -- 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#6698) Please add BDB 5.x support for SLAPD
by faessler＠was.ch 10 Nov '10

10 Nov '10

Full_Name: Dominik Fässler Version: 2.4.23 OS: FreeBSD (8.1-RELEASE) URL: Submission from: (NULL) (62.2.101.221) We know that for the moment only BDB versions 4.4 - 4.8 are supported as backend for SLAPD. We would be happy, if you could include support for BDB versions 5.x as well. (For now we are using 5.1) Thanx.

1 0

Re: (ITS#6696) back-sql and pagedResultsControl can be extremely heavy due to no LIMIT
by masarati＠aero.polimi.it 10 Nov '10

10 Nov '10

Howard Chu wrote: >> Using back-sql on large databases along with pagedResult control is not >> advisable. Limiting the number of entries returned by each query is not >> viable as well, since some entries might not mathc the LDAP filter, or >> ACLs or so, possibly leading to less than pageSize entries returned >> within one page. PagedResults could be removed from back-sql, and dealt >> with by an overlay that simply pages results returned by back-sql in a >> single internal search; probably this is the preferable approach, since >> it would also result in a reduction of the complexity of back-sql. >> However, I have little interest in improving back-sql, so patches are >> welcome, as usual... > > The sssvlv overlay already intercepts pagedResults requests if they > occur in combination with the Sort control. It would be trivial to > extend it to always intercept pagedResults, and then we can rip the > paging support out of each of the backends. (Of course, there's a > marginal efficiency advantage to letting back-bdb/hdb do its own paging. > A configurable option might be best.) That's more or less what I had in mind. I assume you merged the two functionalities in one overlay because pagedResult needs special care when combined with SSSVLV, and this might be true for other functionalities, though (e.g. having efficient pagedResult; life would be much better without it, since clients do not need it while it makes servers' life harder). With respect to conditionally exploiting native pagedResult capabilities of back-bdb/hdb I only fear some issues related to glued databases. Those could be possibly solved by disabling native back-bdb/hdb pagedResult handling when used in glued databases, or even more granularly, when a search spans more than one database in a glued configuration, delegating the handling to the overlay in those cases. p.

1 0

Re: (ITS#6696) back-sql and pagedResultsControl can be extremely heavy due to no LIMIT
by hyc＠symas.com 09 Nov '10

09 Nov '10

masarati(a)aero.polimi.it wrote: > Andrew.Gray(a)unlv.edu wrote: >> Full_Name: Andrew Gray >> Version: 2.4.17 >> OS: Debian 5.0 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (131.216.14.1) >> >> >> On receiving LDAP queries with a pagedResultsControl (in this case with a size >> of 250), back-sql generates an extremely inefficient query for every iteration >> in the form of: >> >> SELECT DISTINCT ldap_entries.id,people.local_id,text('UNLVexpperson') AS >> objectClass,ldap_entries.dn AS dn FROM ldap_entries,people,ldap_entry_objclasses >> WHERE people.local_ >> id=ldap_entries.keyval AND ldap_entries.oc_map_id=1 AND upper(ldap_entries.dn) >> LIKE upper('%'||'%OU=PEOPLE,DC=UNLV,DC=EDU') AND ldap_entries.id>250 AND (2=2 OR >> (ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_ >> name='UNLVexpperson')) >> >> (this repeats for id>250, id>500, id>750, etc. etc.) >> >> Ideally (IMO) there really should be a SQL LIMIT applied here, as in this case >> slapd gets back a few tens of thousands of rows on every iteration, and the >> memory usage explodes and eventually gets killed. > > Using back-sql on large databases along with pagedResult control is not > advisable. Limiting the number of entries returned by each query is not > viable as well, since some entries might not mathc the LDAP filter, or > ACLs or so, possibly leading to less than pageSize entries returned > within one page. PagedResults could be removed from back-sql, and dealt > with by an overlay that simply pages results returned by back-sql in a > single internal search; probably this is the preferable approach, since > it would also result in a reduction of the complexity of back-sql. > However, I have little interest in improving back-sql, so patches are > welcome, as usual... The sssvlv overlay already intercepts pagedResults requests if they occur in combination with the Sort control. It would be trivial to extend it to always intercept pagedResults, and then we can rip the paging support out of each of the backends. (Of course, there's a marginal efficiency advantage to letting back-bdb/hdb do its own paging. A configurable option might 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

Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by ondrej.kuznik＠acision.com 09 Nov '10

09 Nov '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/07/2010 03:26 PM, andrew.findlay(a)skills-1st.co.uk wrote: > On Tue, Sep 07, 2010 at 05:09:07AM -0700, Howard Chu wrote: > >>> We've talked about doing this isolation in the first refresh upon slapd >>> startup. That might still be a good idea. > > It would certainly help to keep the apparent promises made by things > like the uniqueness overlay. Alternatively you could take the view > that the data will converge eventually and that is all that the LDAP > standards promise. We've hit a similar problem and decided to go this way, i.e. allowing the replication to bypass the uniqueness constraints. In RFC 4533, there are only two claims regarding DIT consistency: <quote> 1.2 Intended Usage Upon completion of each synchronization stage of the operation, all information to construct a synchronized client copy of the content has been provided to the client [...]. Except for transient inconsistencies due to concurrent operation (or other) processing at the server, the client copy is an accurate reflection of the content held by the server. Transient inconsistencies will be resolved by subsequent synchronization operations. [...] This protocol is not intended to be used in applications requiring transactional data consistency. </quote> There is no claim that the DIT should stay consistent wrt. any structural restrictions during one synchronization operation. It might be worth noting that trying to replicate the data through as one transaction, like Andrew suggested (quoted below), would still have been impossible without a change in the overlay to allow it to pass through. >>> Doing it on every refresh seems far more problematic, because without some >>> type of multi-version concurrency control, that means making the server >>> non-responsive until the refresh completes. > > That may not be a problem with refresh-and-persist, as in normal > circumstances I would expect updates to arrive at the consumer in the > same order they hit the supplier (so this bug could not trigger). More > difficult for scheduled refresh mode though. Could the consumer server > simply write-lock every entry involved in the refresh while it processes > the list, and then commit the whole lot in one DB transaction? > > Andrew I have put a preliminary version of patches that modify the unique overlay here ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101109-unique_bypass_v1.tgz They add a new configuration attribute olcUniqueAllowManageBypass (it is prohibitively long for a name, though) that, if set to TRUE, triggers the uniqueness checks not to be performed if the operation has manage privilegies on the entry. There are three separate patches, configuration code regarding the new attribute, the checks in unique_{add,modify,modrdn} and manpage modifications. Some things that should be sorted out before this is complete from my point of view: 1. While there might be a way to find out whether an operation comes from replication or is really issued by a rootdn, I have not found any. As a workaround, I used the "manage" privilege to the entry as a trigger, since this privilege already allows to change the structural objectclass of an entry, operation otherwise prohibited by RFC 4512. 2. When performing a modifyDN operation, the privilege is checked against the entry to be changed instead of the new entry. I found this approach more appropriate than modifying the entry returned by overlay_entry_get_ov as I do not yet understand the implications of doing that and do not know whether it is possible and ok to create a phony entry by hand just for the call to access_allowed. This is clearly marked as a "FIXME" comment in the patch. 3. The entry attribute used for acl checking might be too broad. However, deriving the attributes needed for each domain seemed too complex. At least when this is the first version of a patch for which I have no indication whether even the general idea is considered worth pursuing. 4. The code is similar in all three cases so the first attempt was to move it into unique_search, but there is not enough information available there and would have to be provided by each of the three functions anyway. Howard and/or others, do you consider this solution valid for this ITS? If yes, could you help me address the things that should be sorted out? Last, but not least, the IPR stuff: The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. Regards, Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzZX1QACgkQ9GWxeeH+cXuS6gCdEL7txhDF6ukM3jGAcdZNXuQo lkYAoJXgT8T67OAkETtvYsBuehTV2gO5 =t7jk -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Re: (ITS#6696) back-sql and pagedResultsControl can be extremely heavy due to no LIMIT
by masarati＠aero.polimi.it 09 Nov '10

09 Nov '10

Andrew.Gray(a)unlv.edu wrote: > Full_Name: Andrew Gray > Version: 2.4.17 > OS: Debian 5.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.216.14.1) > > > On receiving LDAP queries with a pagedResultsControl (in this case with a size > of 250), back-sql generates an extremely inefficient query for every iteration > in the form of: > > SELECT DISTINCT ldap_entries.id,people.local_id,text('UNLVexpperson') AS > objectClass,ldap_entries.dn AS dn FROM ldap_entries,people,ldap_entry_objclasses > WHERE people.local_ > id=ldap_entries.keyval AND ldap_entries.oc_map_id=1 AND upper(ldap_entries.dn) > LIKE upper('%'||'%OU=PEOPLE,DC=UNLV,DC=EDU') AND ldap_entries.id>250 AND (2=2 OR > (ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_ > name='UNLVexpperson')) > > (this repeats for id>250, id>500, id>750, etc. etc.) > > Ideally (IMO) there really should be a SQL LIMIT applied here, as in this case > slapd gets back a few tens of thousands of rows on every iteration, and the > memory usage explodes and eventually gets killed. Using back-sql on large databases along with pagedResult control is not advisable. Limiting the number of entries returned by each query is not viable as well, since some entries might not mathc the LDAP filter, or ACLs or so, possibly leading to less than pageSize entries returned within one page. PagedResults could be removed from back-sql, and dealt with by an overlay that simply pages results returned by back-sql in a single internal search; probably this is the preferable approach, since it would also result in a reduction of the complexity of back-sql. However, I have little interest in improving back-sql, so patches are welcome, as usual... p.

1 0

Re: (ITS#6697) Could OpenLdap automatically generate SSHA Hashed userPassword?
by masarati＠aero.polimi.it 09 Nov '10

09 Nov '10

changhong_sun(a)yahoo.cn wrote: > Full_Name: Chang Hong Sun > Version: 2.4.23 > OS: SuSe Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (220.248.0.145) > > > Hi All, > > I've installed OpenLdap 2.4.23 in SUSE Linux, and find that: > 1) The OpenLdap supports the SSHA Hash Algorithm by default: could import or > accept the creation of the Users with the {SSHA}/{SHA} Hashed userPassword. > 2) The OpenLdap provides a command "slappasswd" to generate the hashed password, > while it seems that it is not able to generate the password by the OpenLdap > server automatically: after I created a user without Hashed userPassword, I > checked the data and found that the password keep unchanged and hasn't been > Hashed. > > My question is: > Is it possible to make some configuration, so that the OpenLdap server could > automatically transfer the userPassword to Hashed format? Please direct software usage questions to openldap-technical(a)openldap.org; the ITS is intended to track software bugs. This ITS will be closed. p.

1 0

(ITS#6697) Could OpenLdap automatically generate SSHA Hashed userPassword?
by changhong_sun＠yahoo.cn 09 Nov '10

09 Nov '10

Full_Name: Chang Hong Sun Version: 2.4.23 OS: SuSe Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.248.0.145) Hi All, I've installed OpenLdap 2.4.23 in SUSE Linux, and find that: 1) The OpenLdap supports the SSHA Hash Algorithm by default: could import or accept the creation of the Users with the {SSHA}/{SHA} Hashed userPassword. 2) The OpenLdap provides a command "slappasswd" to generate the hashed password, while it seems that it is not able to generate the password by the OpenLdap server automatically: after I created a user without Hashed userPassword, I checked the data and found that the password keep unchanged and hasn't been Hashed. My question is: Is it possible to make some configuration, so that the OpenLdap server could automatically transfer the userPassword to Hashed format? Thanks and Best Regards, Sun Chang Hong

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs