Full_Name:
Version: HEAD
OS:
URL:
Submission from: (NULL) (79.227.175.236)
It would be handy to have operational attribute 'hasSubordinates'
returned for entries under cn=config.
--DKU6Jbt7q3WqK7+M
Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z"
Content-Disposition: inline
--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I forgot to add the notice to the patch I just submitted. Here's the
notice:
The attached patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following
patch(es) were developed by W. Trevor King wking(a)tremily.us. I have
not assigned rights and/or interest in this work to any party.
I, W. Trevor King, 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.
I've attached the patch again, since that matches the language in the
notice.
Cheers,
Trevor
--=20
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="tool-nocanon.patch"
Content-Transfer-Encoding: quoted-printable
ITS#7271 fix SASL_NOCANON clobbering in tools/common.c.
diff --git a/clients/tools/common.c b/clients/tools/common.c
index 9c98b62..9868658 100644
--- a/clients/tools/common.c
+++ b/clients/tools/common.c
@@ -1214,6 +1214,7 @@ LDAP *
tool_conn_setup( int dont, void (*private_setup)( LDAP * ) )
{
LDAP *ld =3D NULL;
+ int i;
=20
if ( debug ) {
if( ber_set_option( NULL, LBER_OPT_DEBUG_LEVEL, &debug )
@@ -1410,13 +1411,22 @@ dnssrv_free:;
=20
#ifdef HAVE_CYRUS_SASL
/* canon */
- if( ldap_set_option( ld, LDAP_OPT_X_SASL_NOCANON,
- nocanon ? LDAP_OPT_ON : LDAP_OPT_OFF ) !=3D LDAP_OPT_SUCCESS )
+ if( ldap_get_option( ld, LDAP_OPT_X_SASL_NOCANON, &i )
+ !=3D LDAP_OPT_SUCCESS )
{
- fprintf( stderr, "Could not set LDAP_OPT_X_SASL_NOCANON %s\n",
- nocanon ? "on" : "off" );
+ fprintf( stderr, "Could not get LDAP_OPT_X_SASL_NOCANON\n" );
tool_exit( ld, EXIT_FAILURE );
}
+ if (!i) {
+ fprintf( stderr, "Set NOCANON to %s\n", nocanon ? "on" : "off" );
+ if( ldap_set_option( ld, LDAP_OPT_X_SASL_NOCANON,
+ nocanon ? LDAP_OPT_ON : LDAP_OPT_OFF ) !=3D LDAP_OPT_SUCCESS )
+ {
+ fprintf( stderr, "Could not set LDAP_OPT_X_SASL_NOCANON %s\n",
+ nocanon ? "on" : "off" );
+ tool_exit( ld, EXIT_FAILURE );
+ }
+ } /* otherwise SASL_NOCANON already set to true (e.g. via ~/.ldaprc) */
#endif
if( ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol )
!=3D LDAP_OPT_SUCCESS )
--Nq2Wo0NMKNjxTN9z--
--DKU6Jbt7q3WqK7+M
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iQEcBAEBAgAGBQJPrw4RAAoJEPe7CdOcrcTZAiUH/RJN9EcOW0HdIr60/vrHQ01r
et05+CMhoSM9OQST7KxVz0IOA0tzgIu6y7KHFSirUFOmb8KNyS+u0uI2b4OMINoF
0qVHo3Ed4gYYQtc9TsTPOTNw0/HfRwiLxYHh6Xrmeq0Z9o+rL1wsFoEwVBQTXc4W
3xsYtjoyRFK5KbmMw+iA1zsIWOTD9cs+PqQ0EWDXl2ptMHjhrBOs8/Demi495UA7
iCmrPbD8uv8T5NMCiqIB3yOkyrX2+0wLsLVO/B21qTb8swFOrSFjlACZ4SjvVYmy
ZJ6njl7vu0h7vPF12Z+NQW5xMFCYz6wbesrhCNbj0k7eJ5gbD+Zd2tP8VQOS3C4=
=9g7U
-----END PGP SIGNATURE-----
--DKU6Jbt7q3WqK7+M--
Full_Name: W. Trevor King
Version: git commit 22bf5188
OS: Gentoo
URL: http://blog.tremily.us/posts/LDAP/tool-nocanon.patch
Submission from: (NULL) (72.68.88.202)
The ldap.conf SASL_NOCANON configuration option (or LDAPSASL_NOCANON environment
variable) should set the default behaviour for OpenLDAP tools such as
ldapwhoami. This configuration option should allow users to use the tools
without having to use the matching command line option (-N). Unfortunately, the
current code sets the option to true/false after only querying the command line
option.
I'm linking to a patch that looks at the current value of the option first, and
if it's true, skips processing the command line option (which would either be a
redundant -N keeping the option true, or an absence of -N which implies the user
wants to use the configured value (true)).
Another approach would be to set the initial value of nocanon to UNINITIALIZED
(-1?). Command line arguments could set nocanon to 1 (true, -N) or false (0,
--canon?). Then we would only call ldap_set_option if nocanon was not
UNINITIALIZED.
I can work up a patch using this second approach if people prefer. If so, let
me know if you want me to define UNINITIALIZED, or to just use -1.
I didn't check, but I would not be surprised if this same clobbering occurred
for other command line options.
I think it's worth to note that such a setup with this stacking order works
with OpenLDAP 2.4.23 (in a more complex variant done by Manuel). So the big
question is what was changed in 2.4.24+ which leads to the crash?
Ciao, Michael.
Full_Name: Frederik Deweerdt
Version: current HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/Frederik-Deweerdt-120511.patch
Submission from: (NULL) (72.5.239.5)
[PATCH] Protect accesses to ldap_int_hostname with a mutex
Not protecting the accesses to ldap_int_hostname would lead to a double
free with the following trace:
#7 0x0000003aca031d10 in abort () from /lib64/libc.so.6
No symbol table info available.
#8 0x0000003aca06a99b in __libc_message () from /lib64/libc.so.6
No symbol table info available.
#9 0x0000003aca0729d6 in free () from /lib64/libc.so.6
No symbol table info available.
#10 0x000000328902333e in ldap_int_initialize ()
from /usr/lib64/libldap-2.3.so.0
No symbol table info available.
#11 0x000000328900c426 in ldap_create () from /usr/lib64/libldap-2.3.so.0
No symbol table info available.
#12 0x000000328900ca0d in ldap_init () from /usr/lib64/libldap-2.3.so.0
No symbol table info available.
The race in init.c:ldap_int_initialize is as follows:
646 char *name = ldap_int_hostname;
647
648 ldap_int_hostname = ldap_pvt_get_fqdn( name );
649
650 if ( name != NULL && name != ldap_int_hostname ) {
651 LDAP_FREE( name );
652 }
- T1 and T2 enter ldap_int_initialize, both assign to name the current
address of ldap_int_hostname, say 0x1234.
- T1 and T2 call ldap_pvt_get_fqdn(), updating ldap_int_hostname to 0x1235
and 0x1236 respectively.
- T1 and T2 reach the name != ldap_int_hostname check. In both threads
it's false, because 0x1235 != 0x1234 and 0x1236 != 0x1234, respectively.
- T1 and T2 both try to free 0x1234 => Crash.
---
libraries/libldap/init.c | 2 ++
libraries/libldap/ldap-int.h | 1 +
libraries/libldap/util-int.c | 3 +++
3 files changed, 6 insertions(+), 0 deletions(-)
--On Thursday, May 10, 2012 9:41 AM +0000 Nithya.narasimhan(a)hp.com wrote:
> Full_Name: Nithya Narasimhan
> Version: Symas OpenLDAP version 2.4.26
> OS: RHEL 5.5
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (15.219.201.69)
>
>
> We have configured 2 nodes in an n way multimaster configuration.
The ITS system is for reporting bug, not asking usage questions. Please
(a) upgrade to the lastest version of OpenLDAP (2.4.31) and (b) direct your
questions to the openldap-technical(a)openldap.org discussion list.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
Full_Name: SATOH Fumiyasu
Version: master
OS:
URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch
Submission from: (NULL) (125.2.180.244)
In contrib/slapd-modules/passwd/sha2/slapd-sha2.c:sha*_hex_hash(),
a static buffer "static char real_hash[]" is declared and is
used by threads, but it is not TLS (Thread Local Storage) and
no lock.
This patch removes sha*_hex_hash() and replaces chk_sha*() with
libraries/liblutil/passwd.c:chk_sha1() implementation to
fix this problem.
Full_Name: Nithya Narasimhan
Version: Symas OpenLDAP version 2.4.26
OS: RHEL 5.5
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (15.219.201.69)
We have configured 2 nodes in an n way multimaster configuration.
Server Definition is configured as follows -
Slapd.conf entry in first server
serverID 001 ldap://16.181.233.72:1389
serverID 002 ldap://16.181.233.71:1389
Slapd.conf entry in second server
serverID 001 ldap://16.181.233.72:1389
serverID 002 ldap://16.181.233.71:1389
Offline replication does not occur.ie:Bring down node1, add entries to node2
which is up.Then bring up the node1 after sometime.In this case the entries
added in node2 are not available in node1.
However when ServerID is configured as follows in slapd.conf file -
Slapd.conf entry in first server
serverID 1
Slapd.conf entry in second server
serverID 2
offline replication occurs correctly.
My Questions are -
1) What is the correct Server Definition for n way multimaster.
2) Is there any other configuration we need to change to make this work?
3) If we are adding LDAP URL to Server Definition , what is the correct format
we must use ?
4) If N-way multi-master mode for 2 servers (2-way multi-master Mode), should
both nodes information be configured in both servers under syncrepl. Should the
syncrepl ID be different in both servers ? Can you share me a sample 2-way
multi-master mode setup.
5) Offline data load (Node 1 is up and Node 2 is down Now entries are added in
Node 1 and then Node 2 is brought up) How does this synchronization work ?
Will it work in Physical server and Virtual Machine as well ? Scenarios of
addition/deletion/modification of entries/attributes.
6) What happens if I define an interval even if I have it refreshandpersist type
Will it ignore that parameter or does it have any side effects ?
--On Monday, May 07, 2012 6:05 PM +0000 quanah(a)OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.30+patches
> OS: Linux 2.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.108.184.39)
>
>
> With a database maxsize of 1GB, found that when the DB hit 1GB in size,
> slapd stopped. After upping the maxsize, the mdb database was unreadable
> via ldapsearch. Slapcat also failed to pull any data out of the database.
>
Appears related to ITS7266, this ITS can be closed. There was a size
mismatch between data sizes in slapd & libmdb.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration