- openldap-bugs - openldap.org

Re: (ITS#5184) pkg-config file for libraries
by ando＠sys-net.it 13 Oct '07

13 Oct '07

mccann(a)jhu.edu wrote: > Full_Name: William Jon McCann Version: 2.3.34 OS: URL: > ftp://ftp.openldap.org/incoming/ Submission from: (NULL) > (128.220.146.19) > > > It would be really helpful for openldap to ship a pkg-config (.pc) > file for libldap. > > http://en.wikipedia.org/wiki/Pkg-config Quoting from the above link: > When a library is installed (say from an RPM, deb or other binary > packaging system) OpenLDAP only distributes source code > If one installs from source, often there will be no .pc file > generated, and one may need to be manually written to reflect the > install. No comment. Having noted this, I think generating a .pc file from "make install" would probably do no harm and probably bring some benefit to people that want to use pkg-config to configure software dependent on OpenLDAP. But I guess most packagers and distributors would still either provide their alternate means to configure packages, or provide specific .pc files, thus possibly breaking configurations based on OpenLDAP's .pc file. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5185) assertion failure in back-meta when the remote directory does not answer a bind request within the time allotted
by ando＠sys-net.it 13 Oct '07

13 Oct '07

ando(a)sys-net.it wrote: > Does this happen when binding as the rootdn of the back-meta instance, > or as a regular user? If it occurs when binding as the rootdn, then I > think I know where the problem is. In that case, apart from me fixing > the problem (working at it...), you should also use > "pseudoroot-bind-defer yes". I partially take it back: the above recommendation is correct; however, the problem I suspected for the rootdn case is also present for regular binds. I've committed to HEAD a fix for this problem. Please test. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5185) assertion failure in back-meta when the remote directory does not answer a bind request within the time allotted
by ando＠sys-net.it 13 Oct '07

13 Oct '07

mhardin(a)symas.com wrote: > Remote directory servers that do not answer a bind request within the timeout > period will cause an assertion failure in back-meta. > > Analysis: > The meta_back_bind() function calls either meta_back_proxy_authz_bind() if the > bind is taking place with back_meta's rootdn or meta_back_single_bind() if it's > not. > > Once they make the appropriate bind function call, each of these functions calls > meta_back_bind_op_result() to process the result of the bind. Neither > meta_back_proxy_authz_bind() or meta_back_single_bind() set the > LDAP_BACK_CONN_BINDING state. Because it's meta_back_getconn() that's supposed to set that flag when appropriate. > When meta_back_bind_op_result() calls ldap_result(), one of the possible return > codes is 0, and meta_back_bind_op_result() will repeat the ldap_result() call, > provided the timeout hasn't been exceeded or back-meta has been told not to > retry. > > If the wait time has been exceeded the code falls through to an > assert(LDAP_BACK_CONN_BINDING(msc)) statement. This assert is only valid when > meta_back_do_bind() has made the function call, and it will fail if either > meta_back_proxy_authz_bind() or meta_back_single_bind() made the function call. The assert **should** always be valid. Its execution indicates that there's an error somewhere else. Does this happen when binding as the rootdn of the back-meta instance, or as a regular user? If it occurs when binding as the rootdn, then I think I know where the problem is. In that case, apart from me fixing the problem (working at it...), you should also use "pseudoroot-bind-defer yes". 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5185) assertion failure in back-meta when the remote directory does not answer a bind request within the time allotted
by mhardin＠symas.com 12 Oct '07

12 Oct '07

Full_Name: Matthew Hardin Version: 2.3.38 OS: RHEL4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.114.43) Remote directory servers that do not answer a bind request within the timeout period will cause an assertion failure in back-meta. Analysis: The meta_back_bind() function calls either meta_back_proxy_authz_bind() if the bind is taking place with back_meta's rootdn or meta_back_single_bind() if it's not. Once they make the appropriate bind function call, each of these functions calls meta_back_bind_op_result() to process the result of the bind. Neither meta_back_proxy_authz_bind() or meta_back_single_bind() set the LDAP_BACK_CONN_BINDING state. When meta_back_bind_op_result() calls ldap_result(), one of the possible return codes is 0, and meta_back_bind_op_result() will repeat the ldap_result() call, provided the timeout hasn't been exceeded or back-meta has been told not to retry. If the wait time has been exceeded the code falls through to an assert(LDAP_BACK_CONN_BINDING(msc)) statement. This assert is only valid when meta_back_do_bind() has made the function call, and it will fail if either meta_back_proxy_authz_bind() or meta_back_single_bind() made the function call. Possible Fixes: The correct fix would seem to be to remove the assert(), since in two out of three cases the meta_back_bind_op_result() function is being called with the LDAP_BACK_CONN_BINDING state not set. It is also possible to set and clear the LDAP_BACK_CONN_BINDING state as appropriate from the other two funcions that call it, but this seems incorrect, as the LDAP_BACK_CONN_BINDING state is only manipulated in the meta_back_single_dobind() direct bind function.

1 0

(ITS#5184) pkg-config file for libraries
by mccann＠jhu.edu 12 Oct '07

12 Oct '07

Full_Name: William Jon McCann Version: 2.3.34 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.220.146.19) It would be really helpful for openldap to ship a pkg-config (.pc) file for libldap. http://en.wikipedia.org/wiki/Pkg-config

1 0

Re: (ITS#5183) Index problem with ;x- attributes.
by quanah＠zimbra.com 12 Oct '07

12 Oct '07

--On Thursday, October 11, 2007 12:37 PM +0000 Magnus.Jonsson(a)umdac.umu.se wrote: > Full_Name: Magnus Jonsson > Version: 2.3.38 > OS: Debian GNU/linux ?Etch? > URL: http://foo.fot.nu/reproduce.txt > Submission from: (NULL) (130.239.200.171) > > > We are using ;x- attributes in a specific appliation to group some > attributes. > > When removing a ;x- attrbute all the indexs for that attribute disapears. > > example: > > cn: index > cn;x-f-1: index > cn;x-f-2: index > > If a remove the cn;x-f-1 attribute I can't search for (cn=index) anymore. > > I have tested with bdb and ldbm. > > Berkeley v4.3 is used. Did you fail to note how OpenLDAP's configure specifically is designed to abort when building against BDB 4.3? BDB 4.3 is known to be a bad release. I suggest using 4.2.52+patchs, 4.4+patches, or 4.5+patches. Not that this necessarily will resolve the issue you are reporting. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5183) Index problem with ;x- attributes.
by Magnus.Jonsson＠umdac.umu.se 11 Oct '07

11 Oct '07

Full_Name: Magnus Jonsson Version: 2.3.38 OS: Debian GNU/linux Etch URL: http://foo.fot.nu/reproduce.txt Submission from: (NULL) (130.239.200.171) We are using ;x- attributes in a specific appliation to group some attributes. When removing a ;x- attrbute all the indexs for that attribute disapears. example: cn: index cn;x-f-1: index cn;x-f-2: index If a remove the cn;x-f-1 attribute I can't search for (cn=index) anymore. I have tested with bdb and ldbm. Berkeley v4.3 is used. A small example with all you need to reproduce the symtoms is available in the provided link.

1 0

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ghenry＠suretecsystems.com 10 Oct '07

10 Oct '07

<quote who="ghenry(a)suretecsystems.com"> > <quote who="ghenry(a)OpenLDAP.org"> >> Full_Name: Gavin Henry >> Version: OPENLDAP_REL_ENG_2_4 >> OS: Fedora 7 >> URL: http://www.suretec.org/our_docs/test048.tar.gz >> Submission from: (NULL) (80.229.93.1) >> Submitted by: ghenry >> >> >> I'm getting a fail at: >> >> "master and R1 slave databases differ" >> >> I'd like to learn how to debug this. Any tips? >> >> This is on a 64-Bit AMD machine, 2GB Ram, Berkeley 4.2.52. >> >> Thanks. > > I'll double check this in HEAD now too. Should have done that first. > All tests pass in HEAD. test048 still failing in RE24. Gavin.

1 0

Re: (ITS#5172) slash in dn
by hyc＠symas.com 10 Oct '07

10 Oct '07

reinhold.may(a)gmx.de wrote: > Raphael, > >> My new crystal ball tells me that you are not saying the >> essential part of the problem: you are using back-ldif, isn't >> it ? > > It is! Did I miss a hint which would have told me not to use > back-ldif or use it differently? back-ldif is really not meant for general use. It does no caching or indexing, so it will perform very poorly in general. It was only written to provide a base for cn=config. -- -- Howard Chu Chief Architect, 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#5172) slash in dn
by reinhold.may＠gmx.de 10 Oct '07

10 Oct '07

Pierangelo, > This output is not useful. I'm sorry. > First of all, can you tell what ldapadd you're using? Please > make sure you run the version of ldapadd that comes with > OpenLDAP sources you built. I can confirm that ldapadd was built alongside slapd whose version I stated in my original post (2.3.35). As I'm not at home at the moment, the only thing I can do is extract the syslog of that import in question which admittedly doesn't say much, however, here it goes: Oct 10 02:16:19 mm slapd[9746]: slapd starting Oct 10 02:16:31 mm slapd[9746]: conn=0 fd=8 ACCEPT from IP=192.168.0.3:40394 (IP =0.0.0.0:389) Oct 10 02:16:31 mm slapd[9746]: conn=0 op=0 BIND dn="cn=root,dc=somedomain,dc=or g" method=128 Oct 10 02:16:31 mm slapd[9746]: failed to open file "/var/lib/openldap-data/dc=s omedomain,dc=org/cn=root.ldif": No such file or directory Oct 10 02:16:31 mm slapd[9746]: conn=0 op=0 BIND dn="cn=root,dc=somedomain,dc=or g" mech=SIMPLE ssf=0 Oct 10 02:16:31 mm slapd[9746]: conn=0 op=0 RESULT tag=97 err=0 text= Oct 10 02:16:31 mm slapd[9746]: conn=0 op=1 ADD dn="dc=somedomain,dc=org" Oct 10 02:16:31 mm slapd[9746]: conn=0 op=1 RESULT tag=105 err=0 text= Oct 10 02:16:31 mm slapd[9746]: conn=0 op=2 ADD dn="ou=My address book,dc=somedo main,dc=org" Oct 10 02:16:31 mm slapd[9746]: conn=0 op=2 RESULT tag=105 err=0 text= Oct 10 02:16:31 mm slapd[9746]: conn=0 op=3 ADD dn="cn=With/Slash,ou=My address book,dc=somedomain,dc=org" Oct 10 02:16:31 mm slapd[9746]: conn=0 op=3 RESULT tag=105 err=32 text=Parent do es not exist Oct 10 02:16:31 mm slapd[9746]: conn=0 op=4 UNBIND Oct 10 02:16:31 mm slapd[9746]: conn=0 fd=8 closed Raphael, > My new crystal ball tells me that you are not saying the > essential part of the problem: you are using back-ldif, isn't > it ? It is! Did I miss a hint which would have told me not to use back-ldif or use it differently? Reinhold

1 0

Re: (ITS#5172) slash in dn
by ando＠sys-net.it 10 Oct '07

10 Oct '07

raphael.ouazana(a)linagora.com wrote: > Le Mer 10 octobre 2007 02:31, reinhold.may(a)gmx.de a écrit : >> adding new entry "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" >> ldap_add: No such object (32) >> additional info: Parent does not exist >> >> which is erroneous. > > My new crystal ball tells me that you are not saying the essential part of > the problem: you are using back-ldif, isn't it ? Well, if Raphael's analysis is correct (in that case, can I borrow your crystal ball, occasionally?), the problem is now fixed in HEAD/re24/re23. Please test. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ghenry＠suretecsystems.com 10 Oct '07

10 Oct '07

<quote who="ando(a)sys-net.it"> > ghenry(a)OpenLDAP.org wrote: > >> >> "master and R1 slave databases differ" >> >> I'd like to learn how to debug this. Any tips? >> >> This is on a 64-Bit AMD machine, 2GB Ram, Berkeley 4.2.52. > > Can't look at your tar right now; but: > > - check in scripts/test048* where the "master and R1 slave databases > differ" line is, and see what files are being tested > > - they probably are macros, defined in scripts/defines.sh, something > like testrun/ldif.flt and testrun/ldapsearch.flt yeah, did all that. It's one entry difference. server1.1.flt and server2.1.flt > > - run diff -iu FILE1 FILE2 as resolved above and see where it fails. > > If it points you somewhere (e.g. the difference is trivial, or there's > something very specific to a precise modification) fine, otherwise post > the outcome. Will check again on HEAD and continue. > > 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 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > > >

1 0

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ghenry＠suretecsystems.com 10 Oct '07

10 Oct '07

<quote who="ghenry(a)OpenLDAP.org"> > Full_Name: Gavin Henry > Version: OPENLDAP_REL_ENG_2_4 > OS: Fedora 7 > URL: http://www.suretec.org/our_docs/test048.tar.gz > Submission from: (NULL) (80.229.93.1) > Submitted by: ghenry > > > I'm getting a fail at: > > "master and R1 slave databases differ" > > I'd like to learn how to debug this. Any tips? > > This is on a 64-Bit AMD machine, 2GB Ram, Berkeley 4.2.52. > > Thanks. I'll double check this in HEAD now too. Should have done that first.

1 0

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ando＠sys-net.it 10 Oct '07

10 Oct '07

ghenry(a)OpenLDAP.org wrote: > > "master and R1 slave databases differ" > > I'd like to learn how to debug this. Any tips? > > This is on a 64-Bit AMD machine, 2GB Ram, Berkeley 4.2.52. Can't look at your tar right now; but: - check in scripts/test048* where the "master and R1 slave databases differ" line is, and see what files are being tested - they probably are macros, defined in scripts/defines.sh, something like testrun/ldif.flt and testrun/ldapsearch.flt - run diff -iu FILE1 FILE2 as resolved above and see where it fails. If it points you somewhere (e.g. the difference is trivial, or there's something very specific to a precise modification) fine, otherwise post the outcome. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ghenry＠OpenLDAP.org 10 Oct '07

10 Oct '07

Full_Name: Gavin Henry Version: OPENLDAP_REL_ENG_2_4 OS: Fedora 7 URL: http://www.suretec.org/our_docs/test048.tar.gz Submission from: (NULL) (80.229.93.1) Submitted by: ghenry I'm getting a fail at: "master and R1 slave databases differ" I'd like to learn how to debug this. Any tips? This is on a 64-Bit AMD machine, 2GB Ram, Berkeley 4.2.52. Thanks.

1 0

Re: (ITS#5172) slash in dn
by raphael.ouazana＠linagora.com 10 Oct '07

10 Oct '07

Le Mer 10 octobre 2007 02:31, reinhold.may(a)gmx.de a écrit : > adding new entry "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" > ldap_add: No such object (32) > additional info: Parent does not exist > > which is erroneous. My new crystal ball tells me that you are not saying the essential part of the problem: you are using back-ldif, isn't it ? Regards, Raphael Ouazana.

1 0

Re: (ITS#5180) OpenLDAP Website Home Page
by ghenry＠OpenLDAP.org 10 Oct '07

10 Oct '07

>> >> We need a better title ;-) >> >> <TITLE>OpenLDAP, Title</TITLE> >> >> Gavin. >> >> >> > Oh, I've just checked. That's still not great. How about: <TITLE>OpenLDAP - community developed LDAP software</TITLE> -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5180) OpenLDAP Website Home Page
by ghenry＠OpenLDAP.org 10 Oct '07

10 Oct '07

Kurt Zeilenga wrote: > Fixed. Many thanks. > > On Oct 9, 2007, at 7:41 PM, ghenry(a)OpenLDAP.org wrote: > >> Full_Name: Gavin Henry >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> Submitted by: ghenry >> >> >> We need a better title ;-) >> >> <TITLE>OpenLDAP, Title</TITLE> >> >> Gavin. >> >> >> > -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5172) slash in dn
by ando＠sys-net.it 10 Oct '07

10 Oct '07

reinhold.may(a)gmx.de wrote: > Pierangelo, > > First of all: Sorry, I've left in fact a paragraph in my .ldif example > that should have come out. > > I can reproduce what you've said and using the following code: > > #include <ldap.h> > #include <stdio.h> > > int main() { > char **c = ldap_explode_dn( > "cn=With/Slash,ou=My address book,dc=somedomain,dc=org", > 1); > > int i; > for (i = 0; c[i] != 0; i++) { > printf("%s\n", c[i]); > } > > return 0; > } > > which correctly produces: > > cn=With/Slash > ou=My address book > dc=somedomain > dc=org > > And executing: > > # slapdn "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" > > produces the expected: > > DN: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> check succeeded > normalized: <cn=with/slash,ou=my address book,dc=somedomain,dc=org> > pretty: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> > > However, running the actual example produces the following full output: > > $ ldapadd -x -D 'cn=root,dc=somedomain,dc=org' -W -f test.ldif > Enter LDAP Password: > adding new entry "dc=somedomain,dc=org" > > adding new entry "ou=My address book,dc=somedomain,dc=org" > > adding new entry "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" > ldap_add: No such object (32) > additional info: Parent does not exist > > which is erroneous. > > Just to check that it is the forward slash that must be to blame, here's > the full output of the counter check: > > $ ldapadd -x -D 'cn=root,dc=somedomain,dc=org' -W -f test2.ldif > Enter LDAP Password: > adding new entry "dc=somedomain,dc=org" > > adding new entry "ou=My address book,dc=somedomain,dc=org" > > adding new entry "cn=WithoutSlash,ou=My address book,dc=somedomain,dc=org" > > So, I still suspect a bug... This output is not useful. First of all, can you tell what ldapadd you're using? Please make sure you run the version of ldapadd that comes with OpenLDAP sources you built. Second, please provide an indication of what happens at the server side. Logs at "stats,trace" would be helpful. I can confirm that I can successfully add an entry whose RDN contains a slash "/" to OpenLDAP 2.3. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5172) slash in dn
by reinhold.may＠gmx.de 09 Oct '07

09 Oct '07

Pierangelo, First of all: Sorry, I've left in fact a paragraph in my .ldif example that should have come out. I can reproduce what you've said and using the following code: #include <ldap.h> #include <stdio.h> int main() { char **c = ldap_explode_dn( "cn=With/Slash,ou=My address book,dc=somedomain,dc=org", 1); int i; for (i = 0; c[i] != 0; i++) { printf("%s\n", c[i]); } return 0; } which correctly produces: cn=With/Slash ou=My address book dc=somedomain dc=org And executing: # slapdn "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" produces the expected: DN: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> check succeeded normalized: <cn=with/slash,ou=my address book,dc=somedomain,dc=org> pretty: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> However, running the actual example produces the following full output: $ ldapadd -x -D 'cn=root,dc=somedomain,dc=org' -W -f test.ldif Enter LDAP Password: adding new entry "dc=somedomain,dc=org" adding new entry "ou=My address book,dc=somedomain,dc=org" adding new entry "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ldap_add: No such object (32) additional info: Parent does not exist which is erroneous. Just to check that it is the forward slash that must be to blame, here's the full output of the counter check: $ ldapadd -x -D 'cn=root,dc=somedomain,dc=org' -W -f test2.ldif Enter LDAP Password: adding new entry "dc=somedomain,dc=org" adding new entry "ou=My address book,dc=somedomain,dc=org" adding new entry "cn=WithoutSlash,ou=My address book,dc=somedomain,dc=org" So, I still suspect a bug... Reinhold

1 0

Re: (ITS#5180) OpenLDAP Website Home Page
by kurt＠OpenLDAP.org 09 Oct '07

09 Oct '07

Fixed. On Oct 9, 2007, at 7:41 PM, ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > We need a better title ;-) > > <TITLE>OpenLDAP, Title</TITLE> > > Gavin. > > >

1 0

(ITS#5181) ITS Copyright
by ghenry＠OpenLDAP.org 09 Oct '07

09 Oct '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Copyright on ITS website page and ITS auto-replies is still at 2006: "Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved."

1 0

(ITS#5180) OpenLDAP Website Home Page
by ghenry＠OpenLDAP.org 09 Oct '07

09 Oct '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry We need a better title ;-) <TITLE>OpenLDAP, Title</TITLE> Gavin.

1 0

(ITS#5179) Weekly generation of Admin Guide for Website
by ghenry＠OpenLDAP.org 09 Oct '07

09 Oct '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Dear all, Not sure if I already requested this (can't find the ITS), but can we set up something to do a weekly doc generation for http://www.openldap.org/devel/admin/ Thanks.

1 0

Re: (ITS#4860) Sets' enhancement
by ghenry＠OpenLDAP.org 09 Oct '07

09 Oct '07

ando(a)sys-net.it wrote: >> Howard Chu a écrit : > >> Unfortunately, it's currently heavily dependant on one of our customer's >> specific schema extensions and data tree structure. The ACLs in use >> implement a lot of the logic specific to their environment, therefore I >> can't send them as is. >> >> However, I will see if I can "translate" some of the more complicated >> ACLs (with sets) to perform on a simple data set for inclusion in the >> test suite. >> >> Could some examples such as these also fit your documentation request >> for sets and their applications [1]? Assuming this is the case, I will >> try and provide at least a subset of our test set soon. >> >> Cheers, >> Jon >> >> [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html > > Let me state first that right now I believe sets do not belong to > slapd(8); they should rather move into a module, under the dynacl > umbrella. And, as such, they should be documented separately from > slapd.access(5), mostly because having them in slapd.access(5) would sort > of encourage unexperienced people into (ab-)using them. > > Also, I'd like sets' users to document them (especially in terms of useful > hints, scenarios, case studies and so), as they probably best know what > one can gain from their use. Otherwise, a bare description of the syntax, > although necessary, would hardly be useful to most of the users. > > p. > Agreed. Once decided, we can discuss where they would fit in the Admin guide. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. 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