- openldap-bugs - openldap.org

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs