openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#5945) --enable-backends=auto support
by hyc＠symas.com 14 Feb '09

14 Feb '09

Kurt Zeilenga wrote: > I just noting that for testing, it kind of nice to just be able to do > ./configure --enable-backends=auto --enable-overlays=auto > make > make test > > To test everything that available on the box. Note that there's no need for an "auto" for overlays - all of the core overlays are self-contained with no external dependencies, and that should always be the case. I agree that "testing everything available" would be nice, because I frequently forget to --enable-slapi or various other switches. But I don't think --enable-everything will suit either. -- -- 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#5945) --enable-backends=auto support
by Kurt＠OpenLDAP.org 14 Feb '09

14 Feb '09

On Feb 13, 2009, at 5:55 PM, hyc(a)symas.com wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.13 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> It would be handy to allow --enable-backends to have auto support >> so that all >> available backends can be selected. The current behavior is "yes", >> which means >> that if you don't have the requisites for a given backend, >> configure stops. > > Accommodating this request would make other things much more > inconvenient. > > Currently the backends and overlay options toggle between "no | yes > | mod" > where "yes" means "yes+static" and "mod" means "yes+dynamic". An > "auto" option > here doesn't allow you to select static vs dynamic. We could have auto => yes+static and automod => yes+dyanmic. But that might be too cumbersome as well. > Adding "auto" would revert > us back to OpenLDAP 2.0's behavior, where every backend required two > enable > switches "--enable-bdb" and "--enable-bdb-mod=static" (or dynamic) > which IMO > was far too cumbersome. > > > Likewise it would require rewriting most of the backends' detection > tests in > configure.in, which currently use AC_MSG_ERROR when a prereq isn't > found. All > of those would have to be turned into warnings/bailouts in the > "auto" case, > instead of aborting the configure run. There's still a lot of old auto tests in configure.in, even for new things like ndb. :-) > > > IMO, seems like more effort than it's worth. possibly. I just noting that for testing, it kind of nice to just be able to do ./configure --enable-backends=auto --enable-overlays=auto make make test To test everything that available on the box. > > -- > -- 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#5945) --enable-backends=auto support
by hyc＠symas.com 14 Feb '09

14 Feb '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.13 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > It would be handy to allow --enable-backends to have auto support so that all > available backends can be selected. The current behavior is "yes", which means > that if you don't have the requisites for a given backend, configure stops. Accommodating this request would make other things much more inconvenient. Currently the backends and overlay options toggle between "no | yes | mod" where "yes" means "yes+static" and "mod" means "yes+dynamic". An "auto" option here doesn't allow you to select static vs dynamic. Adding "auto" would revert us back to OpenLDAP 2.0's behavior, where every backend required two enable switches "--enable-bdb" and "--enable-bdb-mod=static" (or dynamic) which IMO was far too cumbersome. Likewise it would require rewriting most of the backends' detection tests in configure.in, which currently use AC_MSG_ERROR when a prereq isn't found. All of those would have to be turned into warnings/bailouts in the "auto" case, instead of aborting the configure run. IMO, seems like more effort than it's worth. -- -- 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#5945) --enable-backends=auto support
by quanah＠OpenLDAP.org 14 Feb '09

14 Feb '09

Full_Name: Quanah Gibson-Mount Version: 2.4.13 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) It would be handy to allow --enable-backends to have auto support so that all available backends can be selected. The current behavior is "yes", which means that if you don't have the requisites for a given backend, configure stops.

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 14 Feb '09

14 Feb '09

jclarke(a)linagora.com wrote: > This is a multi-part message in MIME format. Please do not send HTML/MIME emails here. > On 13.02.2009 14:29, jclarke(a)linagora.com wrote: > I am following what test049 does. > Oops, sorry, I've been mixing 049 and 050 in my head. My bad, this isn't > a problem for test049 indeed. > > Although I am curious as to why test049 creates a syncrepl consumer > targeted at itself? Can't quite get my head around it yet, but will keep > thinking, with regard to multimaster. Very simple. Once the real consumer connects to the master and replicates, it will acquire whatever config was on the master. If the master doesn't have a consumer pointed at itself, then once the consumer acquires the master's configuration, the consumer's syncrepl config will disappear, and replication will stop. -- -- 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#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 14 Feb '09

14 Feb '09

This is a multi-part message in MIME format. ------=_NextPart_000_00C2_01C98DEA.AA80EF10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit As I leave one week for a security formation ISO 27001 (and in case it would persuade me to make never more programming ;), here is the current state (not finished) of the patch (only the modified function - cf "Followup 19"). In fact, 2 more options must be validated there : 1/- ... // if (x-dnssrv == ".") then $hostname is (must be) the search SRV-domain (or the default domain, if $hostname=="") ... 2/- // in all cases, if (*port != '\0') then : result = $(grep "$port" $(the result of the SRV search)) ... -- PE ------=_NextPart_000_00C2_01C98DEA.AA80EF10 Content-Type: application/octet-stream; name="open.c.url_expand.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="open.c.url_expand.patch" --- openldap-2.4.13/libraries/libldap/open.c 2008-10-31 = 23:23:58.000000000 +0000=0A= +++ openldap-2.4.13/libraries/libldap/open.c 2009-02-14 = 00:31:27.000000000 +0000=0A= @@ -212,19 +212,164 @@=0A= return( ld );=0A= }=0A= =0A= +int=0A= +url_expand_on_srv_search ( char ***result, LDAP_CONST char *url_in, = char *domain )=0A= +{ int rc =3D 0;=0A= + char *scheme, *hostname, *port, *opt;=0A= +=0A= + // Syntax validation ...=0A= + if ( (scheme =3D (char *)LDAP_STRDUP( url_in )) =3D=3D NULL )=0A= + return -1; // memory error ...=0A= +=0A= + hostname =3D (char *)strchrnul( scheme, '/' ); *hostname++ =3D '\0';=0A= + if ( *hostname++ !=3D '/' )=0A= + return -1; // syntax error ...=0A= + =0A= + opt =3D (char *)strchrnul( hostname, '/' ); if ( *opt ) *opt++ =3D = '\0';=0A= + port =3D (char *)strchrnul( hostname, ':' ); if ( *port ) *port++ =3D = '\0';=0A= +=0A= + if ( *hostname && !strcmp ( domain, "." )=3D=3D0 ) // if (x-dnssrv = =3D=3D ".") then $hostname is the search SRV-domain (or default domain, = if $hostname=3D=3D"") ...=0A= + return -1; // syntax error ...=0A= +=0A= + // So now, we can search the server name(s) of the _ldap._tcp.$domain = service ...=0A= + // if ( *port !=3D '\0') then : grep the result of SRV RR search with = $port ...=0A= +=0A= + // Coming soon ...=0A= +if ( (*result =3D ldap_str2charray( "ldap1.gov.pf ldap2.gov.pf = ldap3.gov.pf", " " )) !=3D NULL ) rc =3D 3; // line to delete ...=0A= +=0A= + // Search is finished : so now, add initial scheme and opt to result = hostport(s) ...=0A= + if ( *result !=3D NULL ) {=0A= + size_t plus =3D strlen( scheme ) + strlen ( opt ) + 4;=0A= + for ( rc=3D0; (char *)((*result)[rc]) !=3D NULL; ) {=0A= + (*result)[rc] =3D (char *)LDAP_REALLOC ( (char *)((*result)[rc]), = strlen ( (char *)((*result)[rc]) ) + plus ); =0A= + { // do a : memcpy ( &((char *)((*result)[rc]))[strlen( scheme ) + = 2], *result[rc], strlen( (char *)((*result)[rc]) ) + 1 );=0A= + char *n =3D &((char *)((*result)[rc]))[strlen( scheme ) + 2];=0A= + char *s =3D (char *)((*result)[rc]);=0A= + char *e =3D s + (strlen( (char *)((*result)[rc]) ) + 1);=0A= + for ( n +=3D e - s; e >=3D s; ) *n-- =3D *e--;=0A= + }=0A= + memcpy ( &((char *)((*result)[rc]))[strlen( scheme )], "//", 2 );=0A= + memcpy ( (char *)((*result)[rc]), scheme, strlen( scheme ) );=0A= + strcat ( (char *)((*result)[rc]), "?" ); strcat ( (char = *)((*result)[rc]), opt );=0A= + rc++;=0A= + }=0A= + } else rc =3D 0;=0A= +=0A= + LDAP_FREE ( scheme );=0A= + return rc;=0A= +}=0A= +=0A= +char *=0A= +expand_dnssrv_definitions ( LDAP_CONST char *url_in )=0A= +{=0A= ...=0A= =0A= ------=_NextPart_000_00C2_01C98DEA.AA80EF10--

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 14 Feb '09

14 Feb '09

Jonathan Clarke wrote: > On 13.02.2009 01:23, Howard Chu wrote: >> If you want a setup similar to test049, follow what it does. If you >> want to something else, do otherwise. > I am following what test049 does. Only difference is test049 starts > slapd with "-h $URI1" (with URI1="ldap://localhost:9011/") and I start > slapd with no -h option or a slightly different URI. This is quite > common, I believe. And the slapd(8) manpage clearly states that with no -h option, it defaults to "ldap:///". If the default suits your purpose, use it. If not, then specify the URL you want explicitly. Yes, it's quite common to start slapd with no -h option, because it suits the general case. This discussion is not about the general case. > If you patch the test as follows, it fails: Obviously you should not do that. >> There are valid reasons to point a syncrepl consumer at the same slapd >> (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a >> subtree of a main database, etc.). Using the exhaustive matching that >> serverID uses would preclude those cases from working. > I see. I understand you don't want to break existing functionality. > However, I still feel this is a bug, or at least that you need to "hack" > the setup to get things working as expected. The docs state that "syncrepl provider" is the LDAP URI of the master server. If you're not putting in the same URI as the master is using, that's a config error, not a bug. > Would I be right in assuming that in all the "valid reasons to point a > syncrepl consumer at the same slapd" you mention, the syncrepl consumer > uses a different base DN than the base DN of the database that the > syncrepl consumer is configured on? If so, maybe the exhaustive matching > that serverID uses could be used, if and only if those two base DNs are > different? That sounds reasonable. Will think about it a bit more. Certainly if the two base DNs are the same, it will cause a loop... -- -- 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#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 14 Feb '09

14 Feb '09

--0016e65206024a6d9d0462d5c0d0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have re-tested with recent RE24 and this still happens. Assuming the config (database meta, and map instead of rwm-map shows similar problem) : database ldap suffix "c=AU" uri "ldap://127.0.0.1:390/c=AU" overlay rwm rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute * rwm-map objectclass inetOrgPerson * rwm-map objectclass organisationalUnit * rwm-map objectclass organization * rwm-map objectclass country * rwm-map objectclass * I have a standard LDAP with standard inetOrgPerson style schemas on ldap:// 127.0.0.1:390/c=AU with some dummy data, and when i query the source directory i get sensible results: suse:/usr/local/etc/openldap # ldapsearch -H ldap://127.0.0.1:390 -x -b 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' # extended LDIF # # LDAPv3 # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree # filter: (objectclass=*) # requesting: * # # test00496, support, openldap, AU dn: cn=test00496,ou=support,o=openldap,c=AU objectClass: inetOrgPerson cn: test00496 givenName: test00496 uid: test00496 sn: test00496lname displayName: test00496 test00496lname userPassword:: bm92ZWxs # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 When i query the meta directory, i get no attributes (* or + or *,+, in the requested attributes all return no attributes as below) : ldapsearch -H ldap://127.0.0.1:391 -x -b 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' # extended LDIF # # LDAPv3 # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree # filter: (objectclass=*) # requesting: * # # test00496, support, openldap, AU dn: cn=test00496,ou=support,o=openldap,c=AU # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 But if i query the meta directory explicitly for some attributes (no * +), it works, i get : ldapsearch -H ldap://127.0.0.1:391 -x -b 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' cn sn firstName # extended LDIF # # LDAPv3 # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree # filter: (objectclass=*) # requesting: cn sn firstName # # test00496, support, openldap, AU dn: cn=test00496,ou=support,o=openldap,c=AU cn: test00496 sn: test00496lname # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 So i conclude then that the default attribute lists of *, +, or *,+ are somehow being lost by backend meta or overlay rwm ? Probably * and + (or *,+) should be expanded to the list of user or administrative attributes (respectively) by meta/rwm first, specifically those that are allowed by "map attribute" lines, before being handed to the real directory (helpful to performance if the backend directory has many attributes, that the meta directory is not interested in). This is also why attributes don't appear in a GUI browser for me, if i am using a GUI browser, as they commonly use *,+ as their default. Cheers Brett On Sun, Jan 25, 2009 at 12:53 AM, Pierangelo Masarati <ando(a)sys-net.it>wrote: > [please reply to the ITS, otherwise issues can't be tracked] > > Brett @Google wrote: > >> HI Ando, >> >> Do you know if the fix for ITS#5760 (says fixed for RE24 and HEAD) make it >> into RE24 in time for the 2.4.13 release ? >> > > apparently, yes. > > If so, i can still see the behaviour here with 2.4.13, i can see >> operational >> attributes, but non non-operational attributes, when mapping both >> objectclass and attribute.. >> >> Bug seems to be focused on using of *, rather than an explicit list of >> non-operational attrs which works, ie : >> >> I can search for attributes with * ( get all non-operational attributes ) >> and don't get any non-operational attributes, whereas explicitly adding >> any >> non-operational attribute will result i a search returning the named >> values, >> which is allowable via the objectclass maps. >> >> seems to work the same (omitting non-oprational attrs), even if i dont >> specufy the objectclass rwm maps. >> > > Not sure I understand. Can you post simple (both working and not working) > examples? > > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- > > --0016e65206024a6d9d0462d5c0d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have re-tested with recent RE24 and this still happens. Assuming = the config (database meta, and map instead of rwm-map shows similar problem= ) : database        ldap suffi= x          "c=3DAU"<= br>uri           &nb= sp; "ldap://<a href=3D"http://127.0.0.1:390/c=3DAU">127.0.0.1:390/c=3D= AU</a>" overlay rwm rwm-map attribute cn * rwm-map attribute sn * = rwm-map attribute givenName * rwm-map attribute * rwm-map objectc= lass inetOrgPerson * rwm-map objectclass organisationalUnit * rwm-map= objectclass organization * rwm-map objectclass country * rwm-map objectclass * I have a stan= dard LDAP with standard inetOrgPerson style schemas on ldap://<a href=3D"ht= tp://127.0.0.1:390/c=3DAU">127.0.0.1:390/c=3DAU</a> with some dummy data, a= nd when i query the source directory i get sensible results: suse:/usr/local/etc/openldap # ldapsearch -H ldap://<a href=3D"http://1= 27.0.0.1:390">127.0.0.1:390</a> -x -b 'cn=3Dtest00496,ou=3Dsupport,o=3D= openldap,c=3DAU' '(objectclass=3D*)' '*' # extended = LDIF # # LDAPv3 # base <cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU= > with scope subtree # filter: (objectclass=3D*) # requesting: *<b= r># # test00496, support, openldap, AU dn: cn=3Dtest00496,ou=3Dsu= pport,o=3Dopenldap,c=3DAU objectClass: inetOrgPerson cn: test00496 givenName: test00496 uid:= test00496 sn: test00496lname displayName: test00496 test00496lname<b= r>userPassword:: bm92ZWxs # search result search: 2 result: 0 = Success # numResponses: 2 # numEntries: 1 When i query the meta direc= tory, i get no attributes (* or + or *,+, in the requested attributes all r= eturn no attributes as below) : ldapsearch -H ldap://<a href=3D"http= ://127.0.0.1:391">127.0.0.1:391</a> -x -b 'cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU' '(objectclass=3D*)' '*' # extended LDIF # # LDAPv3 # base <cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU> with scope subtree # filter: (objectclass=3D*)<b= r># requesting: * # # test00496, support, openldap, AU dn: cn= =3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU # search result search: 2 result: 0 Success # numResponses= : 2 # numEntries: 1 But if i query the meta directory explicitly = for some attributes (no * +), it works, i get :  ldapsearch -H = ldap://<a href=3D"http://127.0.0.1:391">127.0.0.1:391</a> -x -b 'cn=3Dt= est00496,ou=3Dsupport,o=3Dopenldap,c=3DAU' '(objectclass=3D*)' = cn sn firstName # extended LDIF # # LDAPv3 # base <cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU> with scope subtree # filter: (objectclass=3D*)<b= r># requesting: cn sn firstName # # test00496, support, openldap,= AU dn: cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU cn: test00496 sn:= test00496lname # search result search: 2 result: 0 Success<br= > # numResponses: 2 # numEntries: 1 So i conclude then that th= e default attribute lists of *, +, or *,+ are somehow being lost by backend= meta or overlay rwm ? Probably * and + (or *,+) should be expanded to the list of user or adm= inistrative attributes (respectively) by meta/rwm first, specifically those= that are allowed by "map attribute" lines, before being handed t= o the real directory (helpful to performance if the backend directory has m= any attributes, that the meta directory is not interested in). This is also why attributes don't appear in a GUI browser for me, i= f i am using a GUI browser, as they commonly use *,+ as their default. <= br>Cheers Brett <div class=3D"gmail_quote">On Sun, Jan 25, 2009 a= t 12:53 AM, Pierangelo Masarati <<a href=3D"mailto:and= o(a)sys-net.it">ando(a)sys-net.it</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">[please reply to = the ITS, otherwise issues can't be tracked]<div class=3D"Ih2E3d"> Brett @Google wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> HI Ando, Do you know if the fix for ITS#5760 (says fixed for RE24 and HEAD) make it<= br> into RE24 in time for the 2.4.13 release ? </blockquote> </div> apparently, yes.<div class=3D"Ih2E3d"> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> If so, i can still see the behaviour here with 2.4.13, i can see operationa= l attributes, but non non-operational attributes, when mapping both objectclass and attribute.. Bug seems to be focused on using of *, rather than an explicit list of non-operational attrs which works, ie : I can search for attributes with * ( get all non-operational attributes )<b= r> and don't get any non-operational attributes, whereas explicitly adding= any non-operational attribute will result i a search returning the named values= , which is allowable via the objectclass maps. seems to work the same (omitting non-oprational attrs), even if i dont specufy the objectclass rwm maps. </blockquote> </div> Not sure I understand.  Can you post simple (both working and not work= ing) examples?<div><div></div><div class=3D"Wj3C7c"> p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA <a href=3D"http://www.sys-net.it" target=3D"_blank">http://www.sys-net.it</= a> ----------------------------------- Office:  +39 02 23998309 Mobile:  +39 333 4963172 Fax:     +39 0382 476497 Email:   <a href=3D"mailto:ando@sys-net.it" target=3D"_blank">ando@sys= -net.it</a> ----------------------------------- </div></div></blockquote></div> --0016e65206024a6d9d0462d5c0d0--

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by hyc＠symas.com 13 Feb '09

13 Feb '09

toby(a)inf.ed.ac.uk wrote: > This looks a little strange to me... > > (gdb) p f2->f_choice > Cannot access memory at address 0x39 > (gdb) up > #1 0x08155862 in tavl_insert (root=0x8afe590, data=0x8aefb88, > fcmp=0x81399b0<pcache_query_cmp>, fdup=0x8154700<avl_dup_error>) > at tavl.c:82 > 82 cmp = fcmp( data, p->avl_data ); > (gdb) p p->avl_data > $1 = (void *) 0x8af62e0 > (gdb) It appears you've compiled with debug and optimization, can you please compile without optimization and try to reproduce this? -- -- 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#5944) configure options --program-prefix and --program-suffix do not update servers/slapd/main.c
by Frank.Swasey＠uvm.edu 13 Feb '09

13 Feb '09

Full_Name: Francis Swasey Version: 2.4.13 OS: Red Hat Enterprise Linux 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.198.37.250) When using the configure options --program-prefix or --program-suffix, the binaries are named as exspected. However, slapd's tools array is not updated and so when using the slap* tool binaries, slapd doesn't recognize that it is being executed as a tool and attempts to start up as slapd.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs