- openldap-bugs - openldap.org

(ITS#8980) Async mode and TLS Non-Blocking Issue
by vsmith＠interlinknetworks.com 19 Feb '19

19 Feb '19

Full_Name: Vernon Smith Version: 2.4.47 OS: Linux, Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2601:40d:4300:679a:d18c:3060:e826:d35c) I am using libldap library built with -DLDAP_USE_NON_BLOCKING_TLS and configured for Async connection mode. I test making connections using the library to servers that are hung to verify that my application will not hang in those cases. I have found 3 issues. The first is that the ldap_pvt_connect() clears non-blocking socket setup after the connection is made even when Async mode was configured. So here is my patch for that. diff --git a/libraries/libldap/os-ip.c b/libraries/libldap/os-ip.c index a823cc6..d7927e5 100644 --- a/libraries/libldap/os-ip.c +++ b/libraries/libldap/os-ip.c @@ -443,7 +443,7 @@ ldap_pvt_connect(LDAP *ld, ber_socket_t s, if ( connect(s, sin, addrlen) != AC_SOCKET_ERROR ) { osip_debug(ld, "connect success\n", 0, 0, 0); - if ( opt_tv && ldap_pvt_ndelay_off(ld, s) == -1 ) + if ( !async && opt_tv && ldap_pvt_ndelay_off(ld, s) == -1 ) return ( -1 ); return ( 0 ); } The second issue is that the tlso_session_connect() routine does not correctly handle the return code from SSL_connect(), it just returns it to the caller. For LDAP_USE_NON_BLOCKING_TLS, the return code must be checked and an appropriate return used. Here is my patch. diff --git a/libraries/libldap/tls_o.c b/libraries/libldap/tls_o.c index e95a448..7a31b5e 100644 --- a/libraries/libldap/tls_o.c +++ b/libraries/libldap/tls_o.c @@ -531,7 +531,23 @@ tlso_session_connect( LDAP *ld, tls_session *sess ) tlso_session *s = (tlso_session *)sess; /* Caller expects 0 = success, OpenSSL returns 1 = success */ - return SSL_connect( s ) - 1; + int rc = SSL_connect( s ) - 1; + +#ifdef LDAP_USE_NON_BLOCKING_TLS + int sslerr = SSL_get_error(s, rc+1); + int sockerr = sock_errno(); + + if ( rc < 0 ) { + if ( sslerr == SSL_ERROR_WANT_READ || sslerr == SSL_ERROR_WANT_WRITE ) { + rc = 0; + } else if (( sslerr == SSL_ERROR_SYSCALL ) && + ( sockerr == EAGAIN || sockerr == ENOTCONN )) { + rc = 0; + } + } +#endif /* LDAP_USE_NON_BLOCKING_TLS */ + + return rc; } static int The third issue is that ldap_int_tls_start() compiled with -DLDAP_USE_NON_BLOCKING_TLS Plays with the socket non-blocking setting even if Async mode is configured. Here is mt patch to only play with the socket setting if not in Async mode. diff --git a/libraries/libldap/tls2.c b/libraries/libldap/tls2.c index d9b2d27..69b749c 100644 --- a/libraries/libldap/tls2.c +++ b/libraries/libldap/tls2.c @@ -1075,8 +1075,11 @@ ldap_int_tls_start ( LDAP *ld, LDAPConn *conn, LDAPURLDesc *srv ) /* * Use non-blocking io during SSL Handshake when a timeout is configured */ + int async = LDAP_BOOL_GET( &ld->ld_options, LDAP_BOOL_CONNECT_ASYNC ); if ( ld->ld_options.ldo_tm_net.tv_sec >= 0 ) { - ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); + if ( ! async ) { + ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); + } ber_sockbuf_ctrl( sb, LBER_SB_OPT_GET_FD, &sd ); tv = ld->ld_options.ldo_tm_net; tv0 = tv; @@ -1110,8 +1113,10 @@ ldap_int_tls_start ( LDAP *ld, LDAPConn *conn, LDAPURLDesc *srv ) ld->ld_errno = LDAP_TIMEOUT; break; } else { - /* ldap_int_poll called ldap_pvt_ndelay_off */ - ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); + /* ldap_int_poll called ldap_pvt_ndelay_off if not in async mode */ + if ( ! async ) { + ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); + } ret = ldap_int_tls_connect( ld, conn, host ); if ( ret > 0 ) { /* need to call tls_connect once more */ struct timeval curr_time_tv, delta_tv; @@ -1159,7 +1164,9 @@ ldap_int_tls_start ( LDAP *ld, LDAPConn *conn, LDAPURLDesc *srv ) } } if ( ld->ld_options.ldo_tm_net.tv_sec >= 0 ) { - ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, NULL ); + if ( ! async ) { + ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, NULL ); + } } #endif /* LDAP_USE_NON_BLOCKING_TLS */ Thanks, Vern

1 0

Re: (ITS#8979) The -l <timelimit> or -o nettimeout=<timelimit> don't limit DNS lookup time
by hyc＠symas.com 18 Feb '19

18 Feb '19

=C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason wrote: > On Mon, Feb 18, 2019 at 5:18 PM Howard Chu <hyc(a)symas.com> wrote: >> >> avarab(a)gmail.com wrote: >>> Full_Name: .var Arnfj.r. Bjarmason >>> Version: 2.4.44-21 >>> OS: CentOS 7.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (5.57.21.154) >>> >>> >>> On a setup where you have a blackholed DNS server: >>> >>> $ grep ^name /etc/resolv.conf >>> nameserver 1.2.3.4 >>> >>> Running e.g.: >>> >>> $ time ldapsearch -l 2 -o nettimeout=3D1 [...] >>> >>> Will (on my system) eventually return: >>> >>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>> >>> real 0m24.039s >>> user 0m0.004s >>> sys 0m0.007s >>> >>> It'll take around 48 seconds if I have two DNS servers. Running strac= e(1) on it >>> reveals that it's sitting in a socket/connect/poll loop trying to loo= kup the >>> hostname of the LDAP server I'm trying to talk to. >>> >>> Instead one of these options should limit time spent on DNS lookups, = or there >>> should be another option, so that you can run ldapsearch with a combi= nation of >>> these options and be sure that it'll run in at most the <timeout> you= give it. >> >> The current code in libldap uses gethostbyname() and this API doesn't = offer >> any parameters for setting a timeout. You can configure a timeout in y= our >> system's /etc/resolv.conf or using RES_OPTIONS environment variable. R= ead your >> system's resolver(5) manpage. >> >> If you know of any widely available resolver API that allows specifyin= g a timeout >> on individual queries, you're welcome to submit a patch supporting thi= s feature. >> The standard -lresolv doesn't provide such an interface. >=20 > That resolv.conf had "options timeout:2". That it didn't kick in is > probably a bug somewhere else, but it would still be handy if > ldapsearch had this itself, since the timeout you use for general > resolutions might not be what you want for ldapsearch. If all you need is a timeout in the ldapsearch command, wrap it in a scri= pt that sets the RES_OPTIONS environment variable. > But implementing that is a mess. This SO post has a summary: > https://stackoverflow.com/questions/24403435/socket-hostname-lookup-tim= eout-how-to-implement-it >=20 > So e.g. there could be a probe for getaddrinfo_a() on GNU systems. >=20 >> Closing this ITS. >=20 > Fair enough, but is that a "we don't want this ever" or "if someone > submitted a patch for (possibly OS-specific) DNS timeout we'd be > interested". Generally not fond of features that aren't available cross-platform, part= icularly if that means it can only be tested on a particular OS. I guess for GNU e= xtensions that are easily detected and widely supported it may be OK. We already use getaddrinfo() if it's available, so adding getaddrinfo_a()= may not be too messy. --=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

Re: (ITS#8979) The -l <timelimit> or -o nettimeout=<timelimit> don't limit DNS lookup time
by quanah＠symas.com 18 Feb '19

18 Feb '19

--On Monday, February 18, 2019 4:32 PM +0000 avarab(a)gmail.com wrote: >> Closing this ITS. > > Fair enough, but is that a "we don't want this ever" or "if someone > submitted a patch for (possibly OS-specific) DNS timeout we'd be > interested". This was already answered in Howard's reply: > If you know of any widely available resolver API that allows specifying a timeout > on individual queries, you're welcome to submit a patch supporting this feature. > The standard -lresolv doesn't provide such an interface. I.e., the ITS can always be reopened if a working resolver API can be found and a patch is supplied. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8979) The -l <timelimit> or -o nettimeout=<timelimit> don't limit DNS lookup time
by avarab＠gmail.com 18 Feb '19

18 Feb '19

On Mon, Feb 18, 2019 at 5:18 PM Howard Chu <hyc(a)symas.com> wrote: > > avarab(a)gmail.com wrote: > > Full_Name: .var Arnfj.r. Bjarmason > > Version: 2.4.44-21 > > OS: CentOS 7.6 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (5.57.21.154) > > > > > > On a setup where you have a blackholed DNS server: > > > > $ grep ^name /etc/resolv.conf > > nameserver 1.2.3.4 > > > > Running e.g.: > > > > $ time ldapsearch -l 2 -o nettimeout=1 [...] > > > > Will (on my system) eventually return: > > > > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > > > > real 0m24.039s > > user 0m0.004s > > sys 0m0.007s > > > > It'll take around 48 seconds if I have two DNS servers. Running strace(1) on it > > reveals that it's sitting in a socket/connect/poll loop trying to lookup the > > hostname of the LDAP server I'm trying to talk to. > > > > Instead one of these options should limit time spent on DNS lookups, or there > > should be another option, so that you can run ldapsearch with a combination of > > these options and be sure that it'll run in at most the <timeout> you give it. > > The current code in libldap uses gethostbyname() and this API doesn't offer > any parameters for setting a timeout. You can configure a timeout in your > system's /etc/resolv.conf or using RES_OPTIONS environment variable. Read your > system's resolver(5) manpage. > > If you know of any widely available resolver API that allows specifying a timeout > on individual queries, you're welcome to submit a patch supporting this feature. > The standard -lresolv doesn't provide such an interface. That resolv.conf had "options timeout:2". That it didn't kick in is probably a bug somewhere else, but it would still be handy if ldapsearch had this itself, since the timeout you use for general resolutions might not be what you want for ldapsearch. But implementing that is a mess. This SO post has a summary: https://stackoverflow.com/questions/24403435/socket-hostname-lookup-timeout… So e.g. there could be a probe for getaddrinfo_a() on GNU systems. > Closing this ITS. Fair enough, but is that a "we don't want this ever" or "if someone submitted a patch for (possibly OS-specific) DNS timeout we'd be interested". > > As a workaround I'm using ldapsearch with /usr/bin/timeout, but since it kills > > it if it exceeds the timeout I don't get a meaningful error. > > > -- > -- 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#8979) The -l <timelimit> or -o nettimeout=<timelimit> don't limit DNS lookup time
by hyc＠symas.com 18 Feb '19

18 Feb '19

avarab(a)gmail.com wrote: > Full_Name: .var Arnfj.r. Bjarmason > Version: 2.4.44-21 > OS: CentOS 7.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (5.57.21.154) > > > On a setup where you have a blackholed DNS server: > > $ grep ^name /etc/resolv.conf > nameserver 1.2.3.4 > > Running e.g.: > > $ time ldapsearch -l 2 -o nettimeout=1 [...] > > Will (on my system) eventually return: > > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > > real 0m24.039s > user 0m0.004s > sys 0m0.007s > > It'll take around 48 seconds if I have two DNS servers. Running strace(1) on it > reveals that it's sitting in a socket/connect/poll loop trying to lookup the > hostname of the LDAP server I'm trying to talk to. > > Instead one of these options should limit time spent on DNS lookups, or there > should be another option, so that you can run ldapsearch with a combination of > these options and be sure that it'll run in at most the <timeout> you give it. The current code in libldap uses gethostbyname() and this API doesn't offer any parameters for setting a timeout. You can configure a timeout in your system's /etc/resolv.conf or using RES_OPTIONS environment variable. Read your system's resolver(5) manpage. If you know of any widely available resolver API that allows specifying a timeout on individual queries, you're welcome to submit a patch supporting this feature. The standard -lresolv doesn't provide such an interface. Closing this ITS. > As a workaround I'm using ldapsearch with /usr/bin/timeout, but since it kills > it if it exceeds the timeout I don't get a meaningful error. -- -- 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#8979) The -l <timelimit> or -o nettimeout=<timelimit> don't limit DNS lookup time
by avarab＠gmail.com 18 Feb '19

18 Feb '19

Full_Name: .var Arnfj.r. Bjarmason Version: 2.4.44-21 OS: CentOS 7.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (5.57.21.154) On a setup where you have a blackholed DNS server: $ grep ^name /etc/resolv.conf nameserver 1.2.3.4 Running e.g.: $ time ldapsearch -l 2 -o nettimeout=1 [...] Will (on my system) eventually return: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) real 0m24.039s user 0m0.004s sys 0m0.007s It'll take around 48 seconds if I have two DNS servers. Running strace(1) on it reveals that it's sitting in a socket/connect/poll loop trying to lookup the hostname of the LDAP server I'm trying to talk to. Instead one of these options should limit time spent on DNS lookups, or there should be another option, so that you can run ldapsearch with a combination of these options and be sure that it'll run in at most the <timeout> you give it. As a workaround I'm using ldapsearch with /usr/bin/timeout, but since it kills it if it exceeds the timeout I don't get a meaningful error.

1 0

Re: (ITS#8978) Fix mdb_env_open2() failing when getting handle for NTDLL.dll
by hyc＠symas.com 17 Feb '19

17 Feb '19

khng300(a)gmail.com wrote: > Full_Name: Ka Ho Ng > Version: mdb.master > OS: Windows 10 > URL: ftp://ftp.openldap.org/incoming/Ka-Ho-Ng-190218.patch > Submission from: (NULL) (2001:470:fa95:1300::1) Thanks for the patch, committed to mdb.master > > Fix mdb_env_open2() failing when getting handle for NTDLL.dll > > Always call GetModuleHandleW() with Unicode string, as mdb_fopen() is > calling CreateFileW() already. Otherwise GetModuleHandle() will fail with > non-Unicode string. > > I, Ka Ho Ng, 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. > > -- -- 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#8978) Fix mdb_env_open2() failing when getting handle for NTDLL.dll
by khng300＠gmail.com 17 Feb '19

17 Feb '19

Full_Name: Ka Ho Ng Version: mdb.master OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/Ka-Ho-Ng-190218.patch Submission from: (NULL) (2001:470:fa95:1300::1) Fix mdb_env_open2() failing when getting handle for NTDLL.dll Always call GetModuleHandleW() with Unicode string, as mdb_fopen() is calling CreateFileW() already. Otherwise GetModuleHandle() will fail with non-Unicode string. I, Ka Ho Ng, 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#8976) LMDB > use posix_madvise(3) instead of madvise(3) for SmartOS
by matthieu.guegan＠smile-suisse.com 15 Feb '19

15 Feb '19

On Fri, Feb 15, 2019 at 5:16 PM Howard Chu <hyc(a)symas.com> wrote: > > matthieu.guegan(a)smile-suisse.com wrote: > > On Fri, Feb 15, 2019 at 4:33 PM Howard Chu <hyc(a)symas.com> wrote: > >> > >> Matthieu GUEGAN wrote: > >>> On Fri, Feb 15, 2019 at 3:56 PM Howard Chu <hyc(a)symas.com> wrote: > >>>> > >>>> mguegan(a)virtua.ch wrote: > >>>>> Full_Name: Matthieu Guegan > >>>>> Version: current > >>>>> OS: SmartOS > >>>>> URL: > >>>>> Submission from: (NULL) (109.190.148.77) > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> In order to compile knot[1] on SmartOS, I have done a series of little patches. > >>>>> One of them is linked to the LMDB project, which redirects me here. > >>>>> > >>>>> The idea is to tell SmartOS (and I think the SunOS family) to make use of > >>>>> posix_madvise(3), instead of madvise(3) as implementation on this OS[2] is > >>>>> different than, for example, the Linux[3] one. > >>>>> > >>>>> So, I kindly ask you to take a look at the merge request of the knot project[4], > >>>>> in particular the `src/contrib/lmdb/mdb.c` patch (that's just a ifdef > >>>>> modification) : would it be possible to apply this patch directly in this > >>>>> repository ? > >>>> > >>>> I see no functional difference between your references [2] and [3]. > >>>> What is the benefit of this patch? > >>> > >>> Well, the Solaris/SunOS's madvise(3) is defined with an old `caddr_t` > >>> type whereas Linux (and *BSD OSes too) use a more modern approach with > >>> `void *`. > >>> On the `knot` project, which embed the lmdb part of openldap, > >>> compilation failed when using madvise(3) on SmartOS, so I did a > >>> replacement with posix_madvise(3) which uses the `void *` argument > >>> too. > >>> I don't know what's the best way to handle this case, that's why I ask here. > >> > >> A caddr_t is just a typedef of "char *". It should always be legal to > >> pass a void * to such a parameter. What is your compile error message? > >> > > > > ``` > > contrib/lmdb/mdb.c: In function 'mdb_env_map': > > contrib/lmdb/mdb.c:3998:3: error: implicit declaration of function > > 'madvise'; did you mean 'raise'? > > [-Werror=implicit-function-declaration] > > madvise(env->me_map, env->me_mapsize, MADV_RANDOM); > > ^~~~~~~ > > raise > > This has absolutely nothing to do with whether the parameter is a caddr_t or a void *. > Why would you even mention something totally irrelevant to the actual error? Sorry if I mislead you with that, that was not my intention. I was just trying to answer you when asking the difference using posix_madvise() vs madvise() on SmartOS. And that was the only thing I found. Indeed, it seems completely irrelevant to the error I get. > Strange that you have MADV_RANDOM defined but no declaration of madvise(). Indeed, searching in the header file `sys/mman.h` [5], it seems to be possible to have a condition that enable madvise() and not MADV_RANDOM or vice-versa. > Sounds like your system's header files are playing stupid games with definitions. > If you can find out what flags must be used to make the header files properly > declare the madvise function, a patch for that may be acceptable. I should say that I'm using the pkgsrc framework in order to compile the whole thing and found multiple packages on which was applied the same type of patch (excluding __sun when trying to use madvise(), thus using the posix_madvise variant). Flags can be overridden here, so it must be something related with the pkgsrc's Makefile variables. Anyway, maybe this should be done this way, instead of trying to change things upstream. Thanks for your help. [5] https://github.com/illumos/illumos-gate/blob/4e0c5eff9af325c80994e9527b7cb8…

1 0

Re: (ITS#8976) LMDB > use posix_madvise(3) instead of madvise(3) for SmartOS
by hyc＠symas.com 15 Feb '19

15 Feb '19

matthieu.guegan(a)smile-suisse.com wrote: > On Fri, Feb 15, 2019 at 4:33 PM Howard Chu <hyc(a)symas.com> wrote: >> >> Matthieu GUEGAN wrote: >>> On Fri, Feb 15, 2019 at 3:56 PM Howard Chu <hyc(a)symas.com> wrote: >>>> >>>> mguegan(a)virtua.ch wrote: >>>>> Full_Name: Matthieu Guegan >>>>> Version: current >>>>> OS: SmartOS >>>>> URL: >>>>> Submission from: (NULL) (109.190.148.77) >>>>> >>>>> >>>>> Hi, >>>>> >>>>> In order to compile knot[1] on SmartOS, I have done a series of little patches. >>>>> One of them is linked to the LMDB project, which redirects me here. >>>>> >>>>> The idea is to tell SmartOS (and I think the SunOS family) to make use of >>>>> posix_madvise(3), instead of madvise(3) as implementation on this OS[2] is >>>>> different than, for example, the Linux[3] one. >>>>> >>>>> So, I kindly ask you to take a look at the merge request of the knot project[4], >>>>> in particular the `src/contrib/lmdb/mdb.c` patch (that's just a ifdef >>>>> modification) : would it be possible to apply this patch directly in this >>>>> repository ? >>>> >>>> I see no functional difference between your references [2] and [3]. >>>> What is the benefit of this patch? >>> >>> Well, the Solaris/SunOS's madvise(3) is defined with an old `caddr_t` >>> type whereas Linux (and *BSD OSes too) use a more modern approach with >>> `void *`. >>> On the `knot` project, which embed the lmdb part of openldap, >>> compilation failed when using madvise(3) on SmartOS, so I did a >>> replacement with posix_madvise(3) which uses the `void *` argument >>> too. >>> I don't know what's the best way to handle this case, that's why I ask here. >> >> A caddr_t is just a typedef of "char *". It should always be legal to >> pass a void * to such a parameter. What is your compile error message? >> > > ``` > contrib/lmdb/mdb.c: In function 'mdb_env_map': > contrib/lmdb/mdb.c:3998:3: error: implicit declaration of function > 'madvise'; did you mean 'raise'? > [-Werror=implicit-function-declaration] > madvise(env->me_map, env->me_mapsize, MADV_RANDOM); > ^~~~~~~ > raise This has absolutely nothing to do with whether the parameter is a caddr_t or a void *. Why would you even mention something totally irrelevant to the actual error? Strange that you have MADV_RANDOM defined but no declaration of madvise(). Sounds like your system's header files are playing stupid games with definitions. If you can find out what flags must be used to make the header files properly declare the madvise function, a patch for that may be acceptable. -- -- 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#8976) LMDB > use posix_madvise(3) instead of madvise(3) for SmartOS
by matthieu.guegan＠smile-suisse.com 15 Feb '19

15 Feb '19

On Fri, Feb 15, 2019 at 4:33 PM Howard Chu <hyc(a)symas.com> wrote: > > Matthieu GUEGAN wrote: > > On Fri, Feb 15, 2019 at 3:56 PM Howard Chu <hyc(a)symas.com> wrote: > >> > >> mguegan(a)virtua.ch wrote: > >>> Full_Name: Matthieu Guegan > >>> Version: current > >>> OS: SmartOS > >>> URL: > >>> Submission from: (NULL) (109.190.148.77) > >>> > >>> > >>> Hi, > >>> > >>> In order to compile knot[1] on SmartOS, I have done a series of little patches. > >>> One of them is linked to the LMDB project, which redirects me here. > >>> > >>> The idea is to tell SmartOS (and I think the SunOS family) to make use of > >>> posix_madvise(3), instead of madvise(3) as implementation on this OS[2] is > >>> different than, for example, the Linux[3] one. > >>> > >>> So, I kindly ask you to take a look at the merge request of the knot project[4], > >>> in particular the `src/contrib/lmdb/mdb.c` patch (that's just a ifdef > >>> modification) : would it be possible to apply this patch directly in this > >>> repository ? > >> > >> I see no functional difference between your references [2] and [3]. > >> What is the benefit of this patch? > > > > Well, the Solaris/SunOS's madvise(3) is defined with an old `caddr_t` > > type whereas Linux (and *BSD OSes too) use a more modern approach with > > `void *`. > > On the `knot` project, which embed the lmdb part of openldap, > > compilation failed when using madvise(3) on SmartOS, so I did a > > replacement with posix_madvise(3) which uses the `void *` argument > > too. > > I don't know what's the best way to handle this case, that's why I ask here. > > A caddr_t is just a typedef of "char *". It should always be legal to > pass a void * to such a parameter. What is your compile error message? > ``` contrib/lmdb/mdb.c: In function 'mdb_env_map': contrib/lmdb/mdb.c:3998:3: error: implicit declaration of function 'madvise'; did you mean 'raise'? [-Werror=implicit-function-declaration] madvise(env->me_map, env->me_mapsize, MADV_RANDOM); ^~~~~~~ raise ```

1 0

Re: (ITS#8976) LMDB > use posix_madvise(3) instead of madvise(3) for SmartOS
by hyc＠symas.com 15 Feb '19

15 Feb '19

Matthieu GUEGAN wrote: > On Fri, Feb 15, 2019 at 3:56 PM Howard Chu <hyc(a)symas.com> wrote: >> >> mguegan(a)virtua.ch wrote: >>> Full_Name: Matthieu Guegan >>> Version: current >>> OS: SmartOS >>> URL: >>> Submission from: (NULL) (109.190.148.77) >>> >>> >>> Hi, >>> >>> In order to compile knot[1] on SmartOS, I have done a series of little patches. >>> One of them is linked to the LMDB project, which redirects me here. >>> >>> The idea is to tell SmartOS (and I think the SunOS family) to make use of >>> posix_madvise(3), instead of madvise(3) as implementation on this OS[2] is >>> different than, for example, the Linux[3] one. >>> >>> So, I kindly ask you to take a look at the merge request of the knot project[4], >>> in particular the `src/contrib/lmdb/mdb.c` patch (that's just a ifdef >>> modification) : would it be possible to apply this patch directly in this >>> repository ? >> >> I see no functional difference between your references [2] and [3]. >> What is the benefit of this patch? > > Well, the Solaris/SunOS's madvise(3) is defined with an old `caddr_t` > type whereas Linux (and *BSD OSes too) use a more modern approach with > `void *`. > On the `knot` project, which embed the lmdb part of openldap, > compilation failed when using madvise(3) on SmartOS, so I did a > replacement with posix_madvise(3) which uses the `void *` argument > too. > I don't know what's the best way to handle this case, that's why I ask here. A caddr_t is just a typedef of "char *". It should always be legal to pass a void * to such a parameter. What is your compile error message? -- -- 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#8976) LMDB > use posix_madvise(3) instead of madvise(3) for SmartOS
by matthieu.guegan＠smile-suisse.com 15 Feb '19

15 Feb '19

On Fri, Feb 15, 2019 at 3:56 PM Howard Chu <hyc(a)symas.com> wrote: > > mguegan(a)virtua.ch wrote: > > Full_Name: Matthieu Guegan > > Version: current > > OS: SmartOS > > URL: > > Submission from: (NULL) (109.190.148.77) > > > > > > Hi, > > > > In order to compile knot[1] on SmartOS, I have done a series of little patches. > > One of them is linked to the LMDB project, which redirects me here. > > > > The idea is to tell SmartOS (and I think the SunOS family) to make use of > > posix_madvise(3), instead of madvise(3) as implementation on this OS[2] is > > different than, for example, the Linux[3] one. > > > > So, I kindly ask you to take a look at the merge request of the knot project[4], > > in particular the `src/contrib/lmdb/mdb.c` patch (that's just a ifdef > > modification) : would it be possible to apply this patch directly in this > > repository ? > > I see no functional difference between your references [2] and [3]. > What is the benefit of this patch? Well, the Solaris/SunOS's madvise(3) is defined with an old `caddr_t` type whereas Linux (and *BSD OSes too) use a more modern approach with `void *`. On the `knot` project, which embed the lmdb part of openldap, compilation failed when using madvise(3) on SmartOS, so I did a replacement with posix_madvise(3) which uses the `void *` argument too. I don't know what's the best way to handle this case, that's why I ask here. > > > > Thanks > > > > > > [1] https://www.knot-dns.cz/ > > [2] https://docs.oracle.com/cd/E36784_01/html/E36874/madvise-3c.html > > [3] http://man7.org/linux/man-pages/man2/madvise.2.html > > [4] https://gitlab.labs.nic.cz/knot/knot-dns/merge_requests/979/diffs?commit_id… > > > > > > > -- > -- 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#8976) LMDB > use posix_madvise(3) instead of madvise(3) for SmartOS
by hyc＠symas.com 15 Feb '19

15 Feb '19

mguegan(a)virtua.ch wrote: > Full_Name: Matthieu Guegan > Version: current > OS: SmartOS > URL: > Submission from: (NULL) (109.190.148.77) > > > Hi, > > In order to compile knot[1] on SmartOS, I have done a series of little patches. > One of them is linked to the LMDB project, which redirects me here. > > The idea is to tell SmartOS (and I think the SunOS family) to make use of > posix_madvise(3), instead of madvise(3) as implementation on this OS[2] is > different than, for example, the Linux[3] one. > > So, I kindly ask you to take a look at the merge request of the knot project[4], > in particular the `src/contrib/lmdb/mdb.c` patch (that's just a ifdef > modification) : would it be possible to apply this patch directly in this > repository ? I see no functional difference between your references [2] and [3]. What is the benefit of this patch? > > Thanks > > > [1] https://www.knot-dns.cz/ > [2] https://docs.oracle.com/cd/E36784_01/html/E36874/madvise-3c.html > [3] http://man7.org/linux/man-pages/man2/madvise.2.html > [4] https://gitlab.labs.nic.cz/knot/knot-dns/merge_requests/979/diffs?commit_id… > > -- -- 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#8977) Make IDL sizes configurable in back-mdb
by hyc＠openldap.org 15 Feb '19

15 Feb '19

Full_Name: Howard Chu Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.233.42.124) Submitted by: hyc IDLs used for index slots are hardcoded to a max of 65536 elements in the DB and twice that in memory. Sites with larger DBs tend to need larger IDLs; if they're running with sufficient memory it ought to be possible to configure larger IDLs.

1 0

(ITS#8976) LMDB > use posix_madvise(3) instead of madvise(3) for SmartOS
by mguegan＠virtua.ch 15 Feb '19

15 Feb '19

Full_Name: Matthieu Guegan Version: current OS: SmartOS URL: Submission from: (NULL) (109.190.148.77) Hi, In order to compile knot[1] on SmartOS, I have done a series of little patches. One of them is linked to the LMDB project, which redirects me here. The idea is to tell SmartOS (and I think the SunOS family) to make use of posix_madvise(3), instead of madvise(3) as implementation on this OS[2] is different than, for example, the Linux[3] one. So, I kindly ask you to take a look at the merge request of the knot project[4], in particular the `src/contrib/lmdb/mdb.c` patch (that's just a ifdef modification) : would it be possible to apply this patch directly in this repository ? Thanks [1] https://www.knot-dns.cz/ [2] https://docs.oracle.com/cd/E36784_01/html/E36874/madvise-3c.html [3] http://man7.org/linux/man-pages/man2/madvise.2.html [4] https://gitlab.labs.nic.cz/knot/knot-dns/merge_requests/979/diffs?commit_id…

1 0

Re: (ITS#8841) Fix for an assertion error in back-meta
by nivanova＠symas.com 14 Feb '19

14 Feb '19

A new patch with added comments has been added at ftp://ftp.openldap.org/incoming/nadezhda-ivanova-190214.patch More details about this issue: The customer reported that when they simulated a "network unreachable" error, SLAPD exited with the following assertion error: #0 0x00007fa1d19e4885 in raise () from /lib64/libc.so.6 #1 0x00007fa1d19e5e61 in abort () from /lib64/libc.so.6 #2 0x00007fa1d19dd740 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000449c17 in slap_send_ldap_result (op=0x1870000, rs=0x7fa17c742930) at result.c:830 #4 0x00000000004b6a53 in meta_back_search (op=0x1870000, rs=0x7fa17c742930) at search.c:1183 #5 0x000000000043aef1 in fe_op_search (op=0x1870000, rs=0x7fa17c742930) at search.c:402 #6 0x00000000004a1a62 in overlay_op_walk (op=0x1870000, rs=0x7fa17c742930, which=op_search, oi=0x88583c0, on=0x0) at backover.c:677 #7 0x00000000004a24dc in over_op_func (op=0x1870000, rs=0x8, which=op_add) at backover.c:730 #8 0x000000000043b73c in do_search (op=0x1870000, rs=0x7fa17c742930) at search.c:247 #9 0x00000000004382af in connection_operation (ctx=0x7fa17c742b30, arg_v=<optimized out>) at connection.c:1316 #10 0x0000000000438edb in connection_read_thread (ctx=0x7fa17c742b30, argv=<optimized out>) at connection.c:1452 #11 0x00000000004f06a0 in ldap_int_thread_pool_wrapper (xpool=<optimized out>) at tpool.c:696 #12 0x00007fa1d1d35806 in start_thread () from /lib64/libpthread.so.0 #13 0x00007fa1d1a9065d in clone () from /lib64/libc.so.6 #14 0x0000000000000000 in ?? () This happened because meta used to directly return the ldap_sasl_bind return value to the client, and in this case it is not an LDAP error. We fixed the issue by mapping it to an LDAP error. Nadezhda Ivanova Software Engineer Symas Corporation http://www.symas.com

1 0

Re: (ITS#8847) New LDAP URL syntax to support binding to specific IP address at client side
by hyc＠symas.com 13 Feb '19

13 Feb '19

Sharma, Ramakant 2. (Nokia - IN/Bangalore) wrote: > Hi Howard, > > Please provide your valuable inputs for the below patch. It is a little strange that ldap_set_option() takes a string but ldap_get_option() returns a binary structure. get/set should be totally symmetric. It would be simplest to just save a copy of the string given to set and return the string in get. In libldap/os-ip.c, you should not be using ldap_get_option() to retrieve the values. You're operating inside libldap, you can access the structure directly. In particular, it's a waste to use ldap_get_option here and create a dynamically allocated copy of the address struct. Look at how the existing code works. Notice that it just uses ld->ld_options directly. This is rule #1 in software development - when extending existing code, your new code should do things the same way existing code does. Corollaries to this rule are: don't patch code without reading it first, and don't patch code without studying its complete context. > > Also let us know how to proceed further. > > BR, > Ramakant Sharma > > -----Original Message----- > From: Sharma, Ramakant 2. (Nokia - IN/Bangalore) > Sent: Monday, January 28, 2019 10:10 AM > To: Howard Chu <hyc(a)symas.com>; openldap-its(a)OpenLDAP.org > Cc: Singam, Sudhir (Nokia - IN/Bangalore) <sudhir.singam(a)nokia.com> > Subject: RE: (ITS#8847) New LDAP URL syntax to support binding to specific IP address at client side > > Hi Howard, > > I have uploaded the new patch which addresses the previous comments. > > Kindly check and provide your valuable comments . > > ftp://ftp.openldap.org/incoming/ramakant-sharma-190121.patch > > BR, > Ramakant Sharma > -- -- 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#8975) Calling mdb_env_set_mapsize on a shared DB fails sometimes
by hyc＠symas.com 10 Feb '19

10 Feb '19

kriszyp(a)gmail.com wrote: > Full_Name: Kristopher William Zyp > Version: LMDB 0.9.23 > OS: Windows Server 2012 R2, Windows 10 > URL: https://github.com/kriszyp/node-lmdb/commit/6df903907f5516320e9a8afce45bd32… > Submission from: (NULL) (71.199.6.148) > Thanks for the report and patch, added to mdb.RE/0.9 > Calling mdb_env_set_mapsize to increase the map size, when a DB is also in use > by other processes, when MDB_WRITEMAP is enabled (and the db file has been > opened with PAGE_READWRITE access), on Windows, will occasionally (seems like > about 1/100 attempts fails) produce an error "The requested operation cannot be > performed on a file with a user-mapped section open", or segfaults. The error > occurs in the SetFilePointer (or SetEndOfFile) call in mdb_env_map that is > performed to increase the allocated file size to the map size, prior to > CreateFileMapping. > > As it turns out this is pretty easy to solve, because manually expanding the > file size is not necessary when calling CreateFileMapping with PAGE_READWRITE > access, as Windows will automatically expand the file size for us, when opened > with the page write access enabled. Of course, this means all processes must be > consistent in use of MDB_WRITEMAP, but the documentation already makes this > explicit and clear. > > I believe this can be fixed by simply adding a check for MDB_WRITEMAP in the if > statement that calls SetFilePointer: > > if (!(flags & MDB_WRITEMAP) && (SetFilePointer(env->me_fd, sizelo, &sizehi, 0) > != (DWORD)sizelo > || !SetEndOfFile(env->me_fd) > || SetFilePointer(env->me_fd, 0, NULL, 0) != 0)) > return ErrCode(); > > The attached URL has the change as a patch/diff as applied to our node package. > > I am certainly happy to just keep this change on our own branches. There may be > nuances of this that I might not be aware of, but it seems to be working great > for us and I have tested this with MDB_WRITEMAP enabled and disabled. So I > thought I would offer/suggest this change, as it seems like it is > straightforward change to improve stability. Thank you! > > -- -- 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#8975) Calling mdb_env_set_mapsize on a shared DB fails sometimes
by kriszyp＠gmail.com 08 Feb '19

08 Feb '19

Full_Name: Kristopher William Zyp Version: LMDB 0.9.23 OS: Windows Server 2012 R2, Windows 10 URL: https://github.com/kriszyp/node-lmdb/commit/6df903907f5516320e9a8afce45bd32… Submission from: (NULL) (71.199.6.148) Calling mdb_env_set_mapsize to increase the map size, when a DB is also in use by other processes, when MDB_WRITEMAP is enabled (and the db file has been opened with PAGE_READWRITE access), on Windows, will occasionally (seems like about 1/100 attempts fails) produce an error "The requested operation cannot be performed on a file with a user-mapped section open", or segfaults. The error occurs in the SetFilePointer (or SetEndOfFile) call in mdb_env_map that is performed to increase the allocated file size to the map size, prior to CreateFileMapping. As it turns out this is pretty easy to solve, because manually expanding the file size is not necessary when calling CreateFileMapping with PAGE_READWRITE access, as Windows will automatically expand the file size for us, when opened with the page write access enabled. Of course, this means all processes must be consistent in use of MDB_WRITEMAP, but the documentation already makes this explicit and clear. I believe this can be fixed by simply adding a check for MDB_WRITEMAP in the if statement that calls SetFilePointer: if (!(flags & MDB_WRITEMAP) && (SetFilePointer(env->me_fd, sizelo, &sizehi, 0) != (DWORD)sizelo || !SetEndOfFile(env->me_fd) || SetFilePointer(env->me_fd, 0, NULL, 0) != 0)) return ErrCode(); The attached URL has the change as a patch/diff as applied to our node package. I am certainly happy to just keep this change on our own branches. There may be nuances of this that I might not be aware of, but it seems to be working great for us and I have tested this with MDB_WRITEMAP enabled and disabled. So I thought I would offer/suggest this change, as it seems like it is straightforward change to improve stability. Thank you!

1 0

RE: (ITS#8972) Performance/freezing issues using NTDLL onWindowsServer on Azure
by kriszyp＠gmail.com 08 Feb '19

08 Feb '19

--_FEED8D1F-4CE2-4DE8-A6B1-1703AFFCC4FC_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" To follow up to this, after switching to the stable release in node-ldmb, a= nd running on our servers for several days, I can confirm this definitely d= oes fix our issues (and ticket can be closed). I=E2=80=99ve submitted a PR = for getting the correct stable version in node-lmdb, to ensure in this does= n=E2=80=99t happen for other NodeJS users: https://github.com/Venemo/node-l= mdb/pull/141=20 I did find a minor issue with setting up the file mapping in the release ve= rsion, but I will file that separately. And if the NTDLL mapping isn=E2=80= =99t intended to be merged into a release branch, sounds like there shouldn= =E2=80=99t be any issues for Windows users that are using LMDB releases. And to be clear, I am a happy windows user, sorting out versions hardly den= ts my enthusiasm for LMDB. And thank you again for the help. Thanks, Kris --_FEED8D1F-4CE2-4DE8-A6B1-1703AFFCC4FC_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht= tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name= =3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vlink=3D"#954F72"><div cla= ss=3DWordSection1><p class=3DMsoNormal>To follow up to this, after switchin= g to the stable release in node-ldmb, and running on our servers for severa= l days, I can confirm this definitely does fix our issues (and ticket can b= e closed). I=E2=80=99ve submitted a PR for getting the correct stable versi= on in node-lmdb, to ensure in this doesn=E2=80=99t happen for other NodeJS = users: <a href=3D"https://github.com/Venemo/node-lmdb/pull/141">https://git= hub.com/Venemo/node-lmdb/pull/141</a> </p><p class=3DMsoNormal><o:p> <= /o:p></p><p class=3DMsoNormal>I did find a minor issue with setting up the = file mapping in the release version, but I will file that separately. And i= f the NTDLL mapping isn=E2=80=99t intended to be merged into a release bran= ch, sounds like there shouldn=E2=80=99t be any issues for Windows users tha= t are using LMDB releases.</p><p class=3DMsoNormal><o:p> </o:p></p><p = class=3DMsoNormal>And to be clear, I am a happy windows user, sorting out v= ersions hardly dents my enthusiasm for LMDB. And thank you again for the he= lp.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoN= ormal>Thanks,<br>Kris<o:p></o:p></p></div></body></html>= --_FEED8D1F-4CE2-4DE8-A6B1-1703AFFCC4FC_--

1 0

Re: (ITS#8974) olcAttributeOptions cannot be modified once set
by hyc＠symas.com 07 Feb '19

07 Feb '19

skoranda(a)gmail.com wrote: > Full_Name: Scott Koranda > Version: 2.4.47 > OS: Debian Linux 9.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (104.231.255.140) > > > Once the option olcAttributeOptions has been configured it cannot be modified. New options can be added; existing options cannot be deleted. Feel free to submit a patch adding the required support. Note the FIXME comment in slapd/bconfig.c. -- -- 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#8974) olcAttributeOptions cannot be modified once set
by skoranda＠gmail.com 07 Feb '19

07 Feb '19

Full_Name: Scott Koranda Version: 2.4.47 OS: Debian Linux 9.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (104.231.255.140) Once the option olcAttributeOptions has been configured it cannot be modified. To reproduce begin with the following state: #ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config -s base olcAttributeOptions 2>/dev/null dn: cn=config olcAttributeOptions: lang- app- Create an LDIF file to modify the value for olcAttributeOptions: # cat /root/olcAttributeOptions.ldif dn: cn=config changetype: modify replace: olcAttributeOptions olcAttributeOptions: lang- app- internal prior role- scope- time- Use ldapmodify to attempt to modify the configuration: # ldapmodify -Y EXTERNAL -H ldapi:/// -f /root/olcAttributeOptions.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80) The slapd process running with -d -1 emits this output: 5c5c2e01 slapd: line 0: option "lang-" is already defined 5c5c2e01 olcAttributeOptions: value #0: <olcAttributeOptions> handler exited with 1! This behavior happens regardless of whether any directory has records that include options with attributes.

1 0

Re: (ITS#8973) Error with domainScope control when using C# LDAP API
by clement.oudot＠worteks.com 06 Feb '19

06 Feb '19

Le 06/02/2019 à 12:57, hyc(a)symas.com a écrit : > hyc(a)symas.com wrote: >> clement.oudot(a)worteks.com wrote: >>> Full_Name: Clement OUDOT >>> Version: 2.4.47 >>> OS: GNU/Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (81.250.130.213) >>> >>> >>> Hello, >>> >>> after upgrading from 2.4.46 to 2.4.47, this C# code does not work anymore : >> The code in controls.c is correct. The DomainScope control does not take a value, >> so the value is required to be NULL. > Microsoft spec https://msdn.microsoft.com/en-us/library/cc223348.aspx > > "When sending this control to the DC, the controlValue field of the Control structure is omitted." > Thanks a lot for your feedback, I will try to understand with the C# code is sending a value inside the control. -- Clément Oudot | Identity Solutions Manager clement.oudot(a)worteks.com Worteks | https://www.worteks.com

1 0

Re: (ITS#8973) Error with domainScope control when using C# LDAP API
by hyc＠symas.com 06 Feb '19

06 Feb '19

hyc(a)symas.com wrote: > clement.oudot(a)worteks.com wrote: >> Full_Name: Clement OUDOT >> Version: 2.4.47 >> OS: GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (81.250.130.213) >> >> >> Hello, >> >> after upgrading from 2.4.46 to 2.4.47, this C# code does not work anymore : > > The code in controls.c is correct. The DomainScope control does not take a value, > so the value is required to be NULL. Microsoft spec https://msdn.microsoft.com/en-us/library/cc223348.aspx "When sending this control to the DC, the controlValue field of the Control structure is omitted." -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs