openldap-devel

openldap-devel@openldap.org

1418 discussions

Re: Documentation Roadmap
by Kurt D. Zeilenga 07 Dec '06

07 Dec '06

At 01:09 PM 12/3/2006, Gavin Henry wrote: >> and, more importantly, whether we want to produce and maintain one. > >This has been bugging me. I think we leave all the other projects to >provide integration docs. With LDAP clients, generally, yes. Our documents do however discuss slapd(8) integration with Berkeley DB, OpenSSL, Cyrus SASL, Kerberos, etc.. Of course, it's generally appropriate to assume the reader is familiar with these packages. That is, we do try to avoid duplication of documentation. But discussion of how to configure/use particular non-OpenLDAP LDAP clients is certainly far beyond the scope of the Admin Guide All client examples use OpenLDAP command line tools because a) these are the only clients we can assume the admin has, we need document our command line tools, and it should be relatively straight forward to translate use of OpenLDAP command line tools to other tools. We do have a FAQ section titled "Integration"... where it is considered fine to provide some discuss of other software. >How about a Deployment guide instead, or would >that fall under the Admin guide? The Deployment Guide could have real >world cases etc. in it and the tuning/monitoring section. Deployment of slapd(8), yes. Deployment of some particular non-OpenLDAP software product, no. The information in the admin guide should be generic, something which most everyone can understand and make use of. Discussing slapd(8) administration in terms of "white pages" is good because "white pages" is a directory application that is simple in concept but also teases out numerous directory service issues including authorization, schema administration, tuning/monitoring, etc... and we can generalize LDAP client issues. >Lastly, what are your thoughts on a Wiki based system for rough TOC drafts >etc. for new authors? That's how I treat the FAQ... In fact, one of large documentation TODOs should be adapt various FAQ into Admin Guide chapters. For instance, much of the FAQ authorization answers should be moved into the guide. >Or should it be tracked on Devel FAQ and ITS for >draft submissions? Actual proposed changes to the Admin Guide, manual pages, and other documentation distributed as part of OpenLDAP Software are the same as OpenLDAP Software code. A patch against the source should be submitted to the ITS system. -- Kurt

2 1

Re: [Please Authorise] Permission to use your glossary as a starting point for OpenLDAP docs addition?
by Kurt D. Zeilenga 07 Dec '06

07 Dec '06

At 02:35 PM 12/6/2006, Gavin Henry wrote: >Or do we want t start one from scratch? I rather start from set of terms in preamble.sdf and http://www.openldap.org/faq/index.cgi?file=1390>. The latter I just added (from a list I had created ages ago). Kurt

2 1

Re: Tables in SDF?
by Kurt D. Zeilenga 06 Dec '06

06 Dec '06

At 02:27 PM 12/6/2006, Gavin Henry wrote: >Hi, > >How do you do tables in sdf? Trying to start a glossary.sdf See http://search.cpan.org/src/IANC/sdf-2.001/doc/user/in_tb.html There are a few examples in the Admin Guide. Just grep for "block table". But as there is already a set of terms defined in preamble.sdf, best to use that to generate a glossary of terms. See the newly committed glossary.sdf Same can be done for references and products data sets. -- Kurt >Can't see any in the source. > >Thanks. > >-- >Kind Regards, > >Gavin Henry. >Managing Director. > >T +44 (0) 1224 279484 >M +44 (0) 7930 323266 >F +44 (0) 1224 824887 >E ghenry(a)suretecsystems.com > >Open Source. Open Solutions(tm). > >http://www.suretecsystems.com/

1 0

[Please Authorise] Permission to use your glossary as a starting point for OpenLDAP docs addition?
by Gavin Henry 06 Dec '06

06 Dec '06

Dear all, I'd like to send this for a starter for a new glossary section. Am I allowed on behalf of the OpenLDAP team? Or do we want t start one from scratch? Thanks. --------------------- Hi, I'm heading up a doc team for OpenLDAP, and I was wondering if I could pinch your glossary as a starting point for a new glossary section? http://www.zytrax.com/books/ldap/apd/ Credits due, obviously ;-) Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Tables in SDF?
by Gavin Henry 06 Dec '06

06 Dec '06

Hi, How do you do tables in sdf? Trying to start a glossary.sdf Can't see any in the source. Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Thoughts on doxygen for Devel Docs/API?
by Gavin Henry 05 Dec '06

05 Dec '06

Hi All, What are your thoughts on using: http://www.stack.nl/~dimitri/doxygen/ http://www.stack.nl/~dimitri/doxygen/docblocks.html I know a lot of OSS project use it, but not had any experience myself. Thoughts? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: Documentation Roadmap
by Kurt D. Zeilenga 03 Dec '06

03 Dec '06

Gavin, others: You are more then welcomed to "jump on in". A few additional comments below. -- Kurt At 02:28 AM 12/3/2006, Gavin Henry wrote: >Dear All, > >After quite a few irc (#ldap) discussions with Howard and Quanah about the >core docs, faq and man pages, I'd like to offer some thoughts on the way >forward and offer my time to help (somewhat limited, as is everyone's). >And, as I understand it from this years OpenLDAP conference, this is one >of the devel teams goals anyway. > >My end goal for OpenLDAP, is to have documentation that equals or >surpasses the OpenLDAP software and setup a doc team to maintain it. > >Q. So, who am I and why should you allow me to touch your docs? > >A. We've commercially supported OpenLDAP for quite a while now (on your >list since 2003), with lots of deployments (every one of our clients), so >we hope we know the product. We also love documentation (weird, I know), >and most of our contributions to the community (docs and code) can be seen >at: > > http://www.suretecsystems.com/opensource/ > >varing from Amanda docs to sitting on the "Fedora Documentation Steering >Committee (FDSCo)" > >Firstly, I'd like to get a page started on the FAQ system to track what >we've got, from all the man pages to guides etc. Then list whats >missing/needs improving. Also, a section for a wish list, which I see as >finishing/extenfing the Admin Guide, Starting a devel guide, and maybe a >User guide (using the tools with examples?) and a Roadmap to try and set >some dates (nothing like deadlines ;-) ). Feel free to create an answer in the Developer's FAQ for this purpose. >Task Summary to start with (not in order or importance): > >Man Pages: > >* Check what's missing and unfinished >* Check for detail >* Identify what could be pulled into the Admin Guide for more examples > >Admin Guide: > >* Pull in info regarding all the different Overlays, uses and examples >* Pull in info regarding all the different backends, uses and examples >* Finish monitoring section, based on "doc/guide/admin/monitoringslapd.sdf" >* More discussion of Replication Scenarios, with complete examples >* More in depth Quick start, maybe from install to replicated setup etc. >* Extend Schema Section >* Tuning section >* Identify core good parts from FAQ, and bring into guide >* Many more.... > > >Devel Guide: But I do think it would be good to produce a developer's guide, but in doc/guide/devel.. >* Turn doc/devel/* into a guide Most everything in directory should stay as it is (maybe incorporated in the guide as appendices or something. Except utfconv.txt, it, as the todo file says, should be incorporated into manual pages. >* use servers/slapd/overlays/slapover.txt for info about all hooks/flow >control of slapd etc. >* Many more.... > > >User Guide: >* Identify if one is needed s/User/End User/ (e.g., not administrative user of OpenLDAP Software). and, more importantly, whether we want to produce and maintain one. - Kurt

2 2

Documentation Roadmap
by Gavin Henry 03 Dec '06

03 Dec '06

Dear All, After quite a few irc (#ldap) discussions with Howard and Quanah about the core docs, faq and man pages, I'd like to offer some thoughts on the way forward and offer my time to help (somewhat limited, as is everyone's). And, as I understand it from this years OpenLDAP conference, this is one of the devel teams goals anyway. My end goal for OpenLDAP, is to have documentation that equals or surpasses the OpenLDAP software and setup a doc team to maintain it. Q. So, who am I and why should you allow me to touch your docs? A. We've commercially supported OpenLDAP for quite a while now (on your list since 2003), with lots of deployments (every one of our clients), so we hope we know the product. We also love documentation (weird, I know), and most of our contributions to the community (docs and code) can be seen at: http://www.suretecsystems.com/opensource/ varing from Amanda docs to sitting on the "Fedora Documentation Steering Committee (FDSCo)" Firstly, I'd like to get a page started on the FAQ system to track what we've got, from all the man pages to guides etc. Then list whats missing/needs improving. Also, a section for a wish list, which I see as finishing/extenfing the Admin Guide, Starting a devel guide, and maybe a User guide (using the tools with examples?) and a Roadmap to try and set some dates (nothing like deadlines ;-) ). Task Summary to start with (not in order or importance): Man Pages: * Check what's missing and unfinished * Check for detail * Identify what could be pulled into the Admin Guide for more examples Admin Guide: * Pull in info regarding all the different Overlays, uses and examples * Pull in info regarding all the different backends, uses and examples * Finish monitoring section, based on "doc/guide/admin/monitoringslapd.sdf" * More discussion of Replication Scenarios, with complete examples * More in depth Quick start, maybe from install to replicated setup etc. * Extend Schema Section * Tuning section * Identify core good parts from FAQ, and bring into guide * Many more.... Devel Guide: * Turn doc/devel/* into a guide * use servers/slapd/overlays/slapover.txt for info about all hooks/flow control of slapd etc. * Many more.... User Guide: * Identify if one is needed I checked out the *sdfs a few weeks ago, and although most of my work is done in DocBook XML, SDF looks easy, converts well to PDF, which d-xml doesn't (more info about Fedora Tool-chain if needed), so I'm not proposing a conversation. Let's stick with defining and writing content. When we get a good team together and have more docs, maybe OpenLDAP will stop being bashed about quality of docs and people will actually get on to contributing instead of whining. You never know, people might read them before posting to the lists and save us all time in the long run! Thanks for your time and look forward to your responses, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

LDIF parser performance (was: write performance)
by Michael Ströder 27 Nov '06

27 Nov '06

Howard, (Cc:-ed openldap-devel(a)OpenLDAP.org in opposite to our off-line conversation). Howard Chu wrote: > I'm wondering if it's worth the effort > to rewrite the client's LDIF parser as I did for slapadd -q. As I said I cannot test on the machine where I did the original tests. But I tried to test OpenLDAP's LDIF parser with -n. $ time ldapadd -f test.ldif -n [..] real 1m30.402s user 1m29.090s sys 0m0.376s Now I have a small Python script which uses the module 'ldif' from python-ldap for reading in the LDIF file. I've implemented module 'ldif' in pure Python but off course the string module in the underlying Python standard lib is implemented in C. And the Python runtime environment does all the ugly memory management. :-) $ time python count_members.py < test.ldif [..] real 0m19.145s user 0m18.349s sys 0m0.568s I re-ran the tests twice, so test.ldif should have been in the filesystem cache. How does that sound to you? I'm not sure what different actions ldapadd -n does in comparison to my simple script. But at least count_members.py also reads the complete entries into a tuple containing the DN as string and the entry as so-called dictionary. Ciao, Michael.

3 8

Re: commit: ldap/clients/tools ldapmodify.c
by Howard Chu 27 Nov '06

27 Nov '06

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/clients/tools > > Modified Files: > ldapmodify.c 1.190 -> 1.191 > > Log Message: > Reject malformed LDIF - missing modops, or mismatched attributes With this patch test021 fails while adding certificates to the directory, because the provided LDIF uses e.g.: add: usercertificate usercertificate;binary:: xxxxxx Should this really be allowed? There are other ops in the LDIF that actually provide the ";binary" tag in both places so it seems that's the expected behavior. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel