openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

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 05 Feb '09

05 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 05 Feb '09

05 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 05 Feb '09

05 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

Re: (ITS#5921) When structural objectClass is modified, the structuralObjectClass attribute is not
by ando＠sys-net.it 04 Feb '09

04 Feb '09

ando(a)sys-net.it wrote: > This can be solved along with ITS#5792 relatively easily from within > entry_schema_check(), provided the structuralObjectClass attribute is not > indexed. Otherwise, things get a little bit more complicated. Fixed in HEAD, including the (unlikely) case structuralObjectClass is indexed. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5921) When structural objectClass is modified, the structuralObjectClass attribute is not
by ando＠sys-net.it 04 Feb '09

04 Feb '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.100.26) Submitted by: ando When the structural objectClass of an entry is modified, the corresponding structuralObjectClass attr is not modified accordingly. While addressing ITS#5792, I found out that the only other case that allows modification of the structural objectClass of an object, from "glue" to any other class using the manageDSAit control, results in an entry with the objectClass attribute set to the modified values, while the structuralObjectClass attribute remains "glue". This can be solved along with ITS#5792 relatively easily from within entry_schema_check(), provided the structuralObjectClass attribute is not indexed. Otherwise, things get a little bit more complicated. p.

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 04 Feb '09

04 Feb '09

----- "h b furuseth" <h.b.furuseth(a)usit.uio.no> wrote: > I'm not quite sure if it's a good idea to move ldap SRV lookup into > ldap_initialize(), since ldap:/// is also means "this LDAP server" in > referral objects and some slapd backends. Possibly some other syntax > should be used to say "use SRV record", e.g. "ldap://./", or another > function could work like ldap_initialize() but be more clever. Though > a > helper function which copies clients/tools/common.c:tool_conn_setup() > functionality could in any case be useful. Probably the cleanest solution is to use extensions. 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 -----------------------------------

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by michael＠stroeder.com 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: I don't see why. > On a site which has Windows and Active Directory, _ldap._tcp.domain > is normally required to refer to Active Directory. Thus if such > a site uses another LDAP server for their public LDAP data, they > can't _ldap._tcp.domain for that. Off course you should use distinct "domains" (better say dc-style naming contexts for MS AD and other OpenLDAP DSAs). But then it won't collide. Ciao, Michael.

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by h.b.furuseth＠usit.uio.no 04 Feb '09

04 Feb '09

I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard

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