openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#5829) Missing moduleload doc. confusing chain/distproc/slapi.
by hyc＠symas.com 25 Nov '08

25 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > slapd.conf(5)'s moduleload description should say which filename a > module has: foo.so or foo.la. (Or worse - is that different on > different OSes? Windows, anyone?) "foo.la" will work on all platforms. The actual shared object that the .la file points to may have different naming conventions on different platforms. > It should say where the standard installed modules are found. > Also that is a default modulepath which as far as I can tell from > strace includes the standard installation directory and the system > loader's standard load path. And again, is it OS-dependent? It > uses libtool's lt_dlopenext(), I haven't looked for what it does yet. I would expect that of course yes, the system loader's standard path is OS-dependent. > slapd.plugin(5) should mention that slapi itself is a module which > may need to be loaded. And that it's "slapi.la", not "plugin.la". > The chain and distproc overlays are not found in<overlay>.la but in > back_ldap.la. This should be documented. I suggest a "moduleload > back_ldap.la" statement before all the other directives, with > explanation. > > However, even if documented, people will miss that. One does't look > for doc about what one already "knows". > > The simplest and maybe most informative fix would be to add dummy > modules which simply give an error message that the overlays are found > in the back_ldap module. When the software knows exactly what must be done, failing with an error message is just annoying. If we were to do anything here at all, dummy modules would better be replaced by symlinks to the actual module, so that It Just Works. But I think just noting the discrepancy in the documentation is sufficient. > An alternative would be to move them to separate modules which depend on > back-ldap - and document their dependency on back-ldap. More correct I > guess, but personally I don't see how it's an improvement. That might > just be because I have had little to do with maintaining binary > distributions though. I don't think it's an improvement either. > A third would be to store a module registry where module names are > mapped to one or more module filenames to load. Overkill? More > general, but also more complex. Yes, overkill. And there are probably more modules out there than we would ever know about for a registry, so ultimately not useful. -- -- 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#5818) Limits chapter for Admin Guide
by ghenry＠OpenLDAP.org 25 Nov '08

25 Nov '08

----- "andrew findlay" <andrew.findlay(a)skills-1st.co.uk> wrote: > Full_Name: Andrew Findlay > Version: HEAD > OS: Linux > URL: > ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 > Submission from: (NULL) (88.97.25.132) > > > The Admin Guide says very little about size limits and time limits. > I have supplied a chapter to remedy the lack: I suggest putting it in > after the > Access Control chapter: > > ftp://ftp.openldap.org/incoming/andrew-findlay-limits.sdf-20081118 > > Please check the section on limits for paged results extra carefully. > I found the definition in slapd.conf(5) a little ambiguous. > > I have also provided patches to the master sdf file and to the two > config > directive > chapters: > > ftp://ftp.openldap.org/incoming/andrew-findlay-limits-patch-20081118 > > Andrew I've read through and made certain changes to fit our style, but nothing major and committed. Thanks Andrew! Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5829) Missing moduleload doc. confusing chain/distproc/slapi.
by h.b.furuseth＠usit.uio.no 25 Nov '08

25 Nov '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd.conf(5)'s moduleload description should say which filename a module has: foo.so or foo.la. (Or worse - is that different on different OSes? Windows, anyone?) It should say where the standard installed modules are found. Also that is a default modulepath which as far as I can tell from strace includes the standard installation directory and the system loader's standard load path. And again, is it OS-dependent? It uses libtool's lt_dlopenext(), I haven't looked for what it does yet. slapd.plugin(5) should mention that slapi itself is a module which may need to be loaded. And that it's "slapi.la", not "plugin.la". The chain and distproc overlays are not found in <overlay>.la but in back_ldap.la. This should be documented. I suggest a "moduleload back_ldap.la" statement before all the other directives, with explanation. However, even if documented, people will miss that. One does't look for doc about what one already "knows". The simplest and maybe most informative fix would be to add dummy modules which simply give an error message that the overlays are found in the back_ldap module. An alternative would be to move them to separate modules which depend on back-ldap - and document their dependency on back-ldap. More correct I guess, but personally I don't see how it's an improvement. That might just be because I have had little to do with maintaining binary distributions though. A third would be to store a module registry where module names are mapped to one or more module filenames to load. Overkill? More general, but also more complex.

1 0

Re: (ITS#5828) Some slap* man pages only talk about slapd.conf
by ghenry＠OpenLDAP.org 24 Nov '08

24 Nov '08

----- "andrew findlay" <andrew.findlay(a)skills-1st.co.uk> wrote: > On Mon, Nov 24, 2008 at 10:02:56AM +0000, ghenry(a)OpenLDAP.org wrote: > > > The following man pages still talk about only slapd.conf: > > > Will fix. > > When doing so, would it be possible to avoid the duplication that > has started showing up in the Admin Guide? One section for doing a > job with slapd.conf and another one for the same job using cn=config > seems like a sure-fire way to get inconsistent information. It also > means that updates take (at least) twice as long to write. We should maybe just pick on configuration method and stick to it throughout the whole guide. POssibly cn=config, then point to the man pages for normal slapd.conf, or the other way round. slapd.conf is easier for just copying and pasting, but saying that, so is an LDIF. 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#5828) Some slap* man pages only talk about slapd.conf
by andrew.findlay＠skills-1st.co.uk 24 Nov '08

24 Nov '08

On Mon, Nov 24, 2008 at 10:02:56AM +0000, ghenry(a)OpenLDAP.org wrote: > The following man pages still talk about only slapd.conf: > Will fix. When doing so, would it be possible to avoid the duplication that has started showing up in the Admin Guide? One section for doing a job with slapd.conf and another one for the same job using cn=config seems like a sure-fire way to get inconsistent information. It also means that updates take (at least) twice as long to write. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by h.b.furuseth＠usit.uio.no 24 Nov '08

24 Nov '08

ghenry(a)OpenLDAP.org writes: > Cool. I say we rewrite it all in Java, this C stuff is hard to understand ;-) Perhaps we should take this to -devel now... -- Hallvard

1 0

Re: (ITS#5825) syncrepl default is no retry
by h.b.furuseth＠usit.uio.no 24 Nov '08

24 Nov '08

hyc(a)symas.com writes: > Have to ensure that the default setting doesn't persist in cn=config, > so that it will keep warning until an explicit value is set. That's on my wish list for cn=config defaults in general. -- Hallvard

1 0

(ITS#5828) Some slap* man pages only talk about slapd.conf
by ghenry＠OpenLDAP.org 24 Nov '08

24 Nov '08

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry The following man pages still talk about only slapd.conf: slapacl slapauth slapdn slappasswd slaptest Things like: "It opens the slapd.conf(5) configuration file," Will fix. Gavin.

1 0

ITS#5039 Support config for start_tls in ldap.conf
by hyc＠symas.com 23 Nov '08

23 Nov '08

In 2.4.13 you can specify "starttls" as an URL extension for the URI in the config file. This was discussed in this thread http://www.openldap.org/lists/openldap-devel/200810/msg00053.html I think that's sufficient to fulfill this enhancement request. -- -- 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#5827) Syncprov persistent operations info leaking
by hyc＠symas.com 23 Nov '08

23 Nov '08

hyc(a)symas.com wrote: > I don't think the current fix is complete. Due to the Abandon check at 1190, > it's possible (though extremely unlikely) for an Abandon to arrive between the > start and end of a mod op, and cause the final decrement to be skipped still. > Probably need to do some restructuring to catch this, I'll look at this some more. Never mind, syncprov_op_cleanup already catches these cases. -- -- 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

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