openldap-bugs February 2009

openldap-bugs@openldap.org

47 participants
298 discussions

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by ghenry＠OpenLDAP.org 05 Feb '09

05 Feb '09

----- jclarke(a)linagora.com wrote: > Gavin Henry wrote: > > Can you follow the IPR notice details at: > > > > http://www.openldap.org/devel/contributing.html > > > > Since this is a patch, we need the above adhering to. > > Gavin, > > Of course. Thanks Jonathan. > I, Jonathan Clarke, 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. > > URL: > ftp://ftp.openldap.org/incoming/jonathan-clarke-guide-20090124-2.patch > > Since this is not new code (mostly simple copy and paste from the man > > pages), I have not included a notice of origin in the patch file. I > hope > this is correct. Let me know, otherwise. > > > Thanks for your work, it's always appreciated when someone take time > to > > contribute! > > My pleasure, it's always nice to have such a great base to contribute > to :) Awww, aren't we nice! ;-) Patch applied, Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by jclarke＠linagora.com 05 Feb '09

05 Feb '09

Gavin Henry wrote: > Can you follow the IPR notice details at: > > http://www.openldap.org/devel/contributing.html > > Since this is a patch, we need the above adhering to. Gavin, Of course. I, Jonathan Clarke, 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. URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-guide-20090124-2.patch Since this is not new code (mostly simple copy and paste from the man pages), I have not included a notice of origin in the patch file. I hope this is correct. Let me know, otherwise. > Thanks for your work, it's always appreciated when someone take time to > contribute! My pleasure, it's always nice to have such a great base to contribute to :) Jonathan

1 0

Re: (ITS#5922) progress bar proposal
by ghenry＠OpenLDAP.org 05 Feb '09

05 Feb '09

----- "Howard Chu" <hyc(a)symas.com> wrote: > Gavin Henry wrote: > > ----- hyc(a)symas.com wrote: > > > >> hyc(a)symas.com wrote: > >>> progress seems a bit too generic; the names probably should be > >> prefixed with > >>> lutil. Also I suggest using "meter" instead of "progress". > >>> > >>> lutil-meter.h, meter.c. > >> Currently it's enabled by default. I have a feeling it should be > >> disabled when > >> various debug flags are set. Any thoughts? Would there ever be a > >> situation > >> where you want debug enabled *and* the progress meter enabled? > > > > How would that work? The debug message would stream down your > console > > and then the meter would have to consistently return to the start of > the > > prompt/window to make any sense? Or would it would it switch to just > showing > > an elapsed time and the end of the run? > > > The messages would all be interleaved; it would be rather ugly. Thought so. So off when debug is on make perfect sense to me. -- 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#5922) progress bar proposal
by hyc＠symas.com 05 Feb '09

05 Feb '09

Gavin Henry wrote: > ----- hyc(a)symas.com wrote: > >> hyc(a)symas.com wrote: >>> progress seems a bit too generic; the names probably should be >> prefixed with >>> lutil. Also I suggest using "meter" instead of "progress". >>> >>> lutil-meter.h, meter.c. >> Currently it's enabled by default. I have a feeling it should be >> disabled when >> various debug flags are set. Any thoughts? Would there ever be a >> situation >> where you want debug enabled *and* the progress meter enabled? > > How would that work? The debug message would stream down your console > and then the meter would have to consistently return to the start of the > prompt/window to make any sense? Or would it would it switch to just showing > an elapsed time and the end of the run? > The messages would all be interleaved; it would be rather ugly. -- -- 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#5922) progress bar proposal
by ghenry＠suretecsystems.com 05 Feb '09

05 Feb '09

----- hyc(a)symas.com wrote: > hyc(a)symas.com wrote: > > progress seems a bit too generic; the names probably should be > prefixed with > > lutil. Also I suggest using "meter" instead of "progress". > > > > lutil-meter.h, meter.c. > > Currently it's enabled by default. I have a feeling it should be > disabled when > various debug flags are set. Any thoughts? Would there ever be a > situation > where you want debug enabled *and* the progress meter enabled? How would that work? The debug message would stream down your console and then the meter would have to consistently return to the start of the prompt/window to make any sense? Or would it would it switch to just showing an elapsed time and the end of the run? -- 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/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: (ITS#5922) progress bar proposal
by hyc＠symas.com 05 Feb '09

05 Feb '09

hyc(a)symas.com wrote: > progress seems a bit too generic; the names probably should be prefixed with > lutil. Also I suggest using "meter" instead of "progress". > > lutil-meter.h, meter.c. Currently it's enabled by default. I have a feeling it should be disabled when various debug flags are set. Any thoughts? Would there ever be a situation where you want debug enabled *and* the progress meter enabled? -- -- 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#5922) progress bar proposal
by hyc＠symas.com 04 Feb '09

04 Feb '09

mbackes(a)symas.com wrote: > Full_Name: Matthew Backes > Version: 2.4, head > OS: any > URL: > Submission from: (NULL) (76.88.99.93) > > > Here is a proposal for a progress bar reporting tool, to appear in > slapadd and other long running tools. A similar version was used > previously in Symas's OpenLDAP 2.3 (CDS3) product. This version is > significantly more modular, so that alternative estimators and display > systems may be added. > > By default, it displays a text bar showing activity, progress, percent > completion, estimated time to completion, elapsed time, and speed in > bytes of ldif per second. > > The display functions are modular so that we could add a running trace > of numbers that a graphical front-end might read and transform into > pretty animated pie charts, or potentially fancier display within > these tools. > > The default (and only) supplied display system currently relies only > on carriage return, with no external libraries needed or dependencies > on terminal features. > > Estimators are modular as well, as the default linear estimator can be > frustratingly poor for very large, poorly tuned databases with > extremely non-linear load times. > > Progress is estimated by fstat()ing the ldif file and ftell()ing to > see the position. As a result, ldif read from stdin automatically > disables the progress bar. > > Files are available at: > > http://lirone.symas.net/lucca/progress-bar/ > > * Apply progress.patch > * Copy progress.c into libraries/liblutil/progress.c > * Copy progress.h into include/progress.h progress seems a bit too generic; the names probably should be prefixed with lutil. Also I suggest using "meter" instead of "progress". lutil-meter.h, meter.c. > We should probably make this configurable via the commandline (on/off, > as well as which display and estimator systems to use), but currently > it is always on provided stderr is a tty and the ldif is a file. -- -- 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#5922) progress bar proposal
by mbackes＠symas.com 04 Feb '09

04 Feb '09

In clarification of software origins, the progress bar code is my own original work (as a Symas employee). Symas retains copyright but licenses it under the OpenLDAP Public License. Patches to makefiles and slapd.c are derivative of work by the OpenLDAP project. "progress.c" and "progress.h" are Copyright 2009 by Symas Corporation and myself. Redistribution and use in source and binary forms, with or without modification, are permitted as authorized by the OpenLDAP Public License. progress.patch is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the patch were developed by myself at Symas Corporation. We have not assigned rights and/or interest in this work to any party. I, Matthew Backes, am authorized by Symas Corporation, my employer, to release this work under the terms of the OpenLDAP Public License, as available from http://www.OpenLDAP.org/license.html . Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

(ITS#5922) progress bar proposal
by mbackes＠symas.com 04 Feb '09

04 Feb '09

Full_Name: Matthew Backes Version: 2.4, head OS: any URL: Submission from: (NULL) (76.88.99.93) Here is a proposal for a progress bar reporting tool, to appear in slapadd and other long running tools. A similar version was used previously in Symas's OpenLDAP 2.3 (CDS3) product. This version is significantly more modular, so that alternative estimators and display systems may be added. By default, it displays a text bar showing activity, progress, percent completion, estimated time to completion, elapsed time, and speed in bytes of ldif per second. The display functions are modular so that we could add a running trace of numbers that a graphical front-end might read and transform into pretty animated pie charts, or potentially fancier display within these tools. The default (and only) supplied display system currently relies only on carriage return, with no external libraries needed or dependencies on terminal features. Estimators are modular as well, as the default linear estimator can be frustratingly poor for very large, poorly tuned databases with extremely non-linear load times. Progress is estimated by fstat()ing the ldif file and ftell()ing to see the position. As a result, ldif read from stdin automatically disables the progress bar. Files are available at: http://lirone.symas.net/lucca/progress-bar/ * Apply progress.patch * Copy progress.c into libraries/liblutil/progress.c * Copy progress.h into include/progress.h We should probably make this configurable via the commandline (on/off, as well as which display and estimator systems to use), but currently it is always on provided stderr is a tty and the ldif is a file. Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 04 Feb '09

04 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > Also note that _ldap._tcp.domain is of limited utility outside > Windows-land, because Microsoft annexed it for Active Directory: Most of system définitions may also be centralized without any used of Active Directory. Redundance notions are nevertheless necessary, also inside Linux-land ... ;-) Used of SRV rr is a good reponse, (in particular in case of large Intranet with many remote sites -islands in pacific- and poor communication ressources - satellite) but require to be performed in all client applications : nssldap, samba, ldap client tools for rsync/mail/DNS/proxy/supervision definitions, ... or openldap.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2009