openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#4949) olcLogLevel not functioning as expected after conversion via '-f slapd.conf -F slapd.d'
by erici＠motown.cc.utexas.edu 07 May '07

07 May '07

On Fri, 4 May 2007, hyc(a)symas.com wrote: >> Either the conversion should put all of the loglevel masks in the same >> olcLogLevel value or cn=config should AND all of the olcLogLevel values. > > You mean OR of course, not AND. Yes, sorry. OR, +, mask, that's what I mean. It must have been Friday. -- Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342

1 0

Re: (ITS#4950) error LDAP Server
by quanah＠zimbra.com 07 May '07

07 May '07

--On Monday, May 07, 2007 11:03 AM +0000 thuanpvm(a)blitzgrp.com wrote: > Full_Name: Phan Van Minh Thuan > Version: 2.3.35 > OS: Linux Enterprise 4.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (58.186.92.53) > > > Dear Sirs, > > When I submit ldapadd -x -D "cn=Manager, dc=blitzcie,dc=dyndns,dc=org" -W > -f /usr/local/etc/openldap/schema/initial.ldif, the error display: > Enter LDAP password: > ldap_bin: Can't contact LDAP server (-1) > > Looking forward to hearing from you soon The ITS system is for submitting bugs about the software. You appear to be having a configuration/usage problem. Please subscribe to openldap-software(a)openldap.org and describe the problems you are having there. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#4950) error LDAP Server
by thuanpvm＠blitzgrp.com 07 May '07

07 May '07

Full_Name: Phan Van Minh Thuan Version: 2.3.35 OS: Linux Enterprise 4.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (58.186.92.53) Dear Sirs, When I submit ldapadd -x -D "cn=Manager, dc=blitzcie,dc=dyndns,dc=org" -W -f /usr/local/etc/openldap/schema/initial.ldif, the error display: Enter LDAP password: ldap_bin: Can't contact LDAP server (-1) Looking forward to hearing from you soon Many Thanks. Thuan

1 0

Re: (ITS#4933) syncrepl unlimited timeout vs. .ldaprc
by hyc＠symas.com 04 May '07

04 May '07

donn(a)u.washington.edu wrote: > Full_Name: Donn Cave > Version: 2.4.4 > OS: Red Hat RHEL 3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.95.135.150) > > > Appears to me that unless timelimit value passed to ldap_search_ext() is > positive, the ld_timelimit from .ldaprc overrides, so there's no way for > syncrepl ldap_sync_search() to literally specify "unlimited". > > To duplicate: configure syncrepl timelimit=unlimited; edit /.ldaprc -> > "TIMELIMIT 23"; start replica slapd with a sufficiently large replication > backlog; observe timeout at 23 seconds. > > To kludge: use extravagantly large value instead: if (si->si_tlimit > 0) > timeout.tv_sec = si->tlimit; else timeout.tv_sec = 31536000; > > and pass &timeout unconditionally. Hmmm. I guess this is a consequence of changing the timeout representation in the LDAP handle. I suppose we can just make the syncrepl consumer do an explicit ldap_set_option() on its session handles to override any .ldaprc setting. Will have to play with this a bit to see how we can maintain backward compatibility. -- -- 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#4948) #if/#elif argument in .../include/ac/time.h
by h.b.furuseth＠usit.uio.no 04 May '07

04 May '07

lucio(a)proxima.alt.za writes: > Whether the existing format is legitimate or not is a matter for the C > standards, but I believe that the alternative would be both clearer > and more portable. It's legitimate. In #if/#elif statements, an undefined macro (without arguments) has the value 0 in a correct compiler. That said, it's indeed a reasonable cleanup. I'll do that and some others shortly. Allows us to compile with 'gcc -Wundef' without too much noise too. I'll tests I'm not sure about alone (in particular Windows stuff), in case it's supposed to be OK to compile with '-D<macro name>=0' so a change from #if to #ifdef would change OpenLDAP's behavior. Maybe someone else can have a look at that. > The Plan 9 C pre-processor has a definite issue with it and it seems a > reasonable change to implement. There may be other places where a > similar change would be beneficial, I'll identify them as I > encountered and will provide a comprehensive list on demand. Please be specific: Give the exact error/warning message, and make clear whether it _is_ a warning or an error. BTW, will 9 C accept this (when you do not define FOO/BAR)? What error/warning messages, if any? #if defined(FOO) && FOO /* Guard #if FOO with defined(FOO) */ int main() { return 2; } #elif BAR int main() { return 1; } #else int main() { return 0; } #endif -- Regards, Hallvard

1 0

Re: (ITS#4949) olcLogLevel not functioning as expected after conversion via '-f slapd.conf -F slapd.d'
by hyc＠symas.com 04 May '07

04 May '07

erici(a)motown.cc.utexas.edu wrote: > Full_Name: Eric Irrgang > Version: 2.3.35 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.83.93.52) > > > When a slapd.conf file is converted to cn=config with -f and -F the loglevel > parameter gets converted into multiple olcLogLevel=keyword attribute/value > pairs. However, only the last one in the configuration seems to apply. > Manually updating > dn: cn=config > changetype: modify > replace: olcLogLevel > olcLogLevel: keyword1 keyword2 ... > - > > gets the intended logging behavior. > > Either the conversion should put all of the loglevel masks in the same > olcLogLevel value or cn=config should AND all of the olcLogLevel values. You mean OR of course, not AND. Yes, the code only does ORs correctly when multiple levels are set at once. Oops. -- -- 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

(ITS#4949) olcLogLevel not functioning as expected after conversion via '-f slapd.conf -F slapd.d'
by erici＠motown.cc.utexas.edu 04 May '07

04 May '07

Full_Name: Eric Irrgang Version: 2.3.35 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.83.93.52) When a slapd.conf file is converted to cn=config with -f and -F the loglevel parameter gets converted into multiple olcLogLevel=keyword attribute/value pairs. However, only the last one in the configuration seems to apply. Manually updating dn: cn=config changetype: modify replace: olcLogLevel olcLogLevel: keyword1 keyword2 ... - gets the intended logging behavior. Either the conversion should put all of the loglevel masks in the same olcLogLevel value or cn=config should AND all of the olcLogLevel values.

1 0

(ITS#4948) #if/#elif argument in .../include/ac/time.h
by lucio＠proxima.alt.za 04 May '07

04 May '07

Full_Name: Lucio De Re Version: 2.3.35 and earlier OS: Plan 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.25.255.250) The arguments on lines 20 and 23 (#if and #elif, respectively) in .../include/ac/time.h ought to be surrounded with "defined()". Whether the existing format is legitimate or not is a matter for the C standards, but I believe that the alternative would be both clearer and more portable. The Plan 9 C pre-processor has a definite issue with it and it seems a reasonable change to implement. There may be other places where a similar change would be beneficial, I'll identify them as I encountered and will provide a comprehensive list on demand. Naturally, there are many other issues applicable specific to porting OpenLDAP to Plan 9, but these seem trivial enough to warrant addressing in a broader context.

1 0

Re: (ITS#4947) monitor schema should appear under subschema entry
by quanah＠zimbra.com 04 May '07

04 May '07

--On Friday, May 04, 2007 2:39 PM +0000 ahasenack(a)terra.com.br wrote: > Full_Name: Andreas Hasenack > Version: 2.3.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.140.247.99) > > > (enhancement, or minor) > > The monitor backend attributes and object classes, when loaded, should > also be exported in the subschema entries at the server. > > I know of one ldap client that breaks because of this: luma. It says it > can't display the cn=monitor entries because it doesn't know the object > classes or attributes. I guess it uses this info to determine how to show > each entry. Not disagreeing, but making the assumption that cn=subschema is readable is also a broken behavior on the luma side. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#4947) monitor schema should appear under subschema entry
by ahasenack＠terra.com.br 04 May '07

04 May '07

Full_Name: Andreas Hasenack Version: 2.3.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.140.247.99) (enhancement, or minor) The monitor backend attributes and object classes, when loaded, should also be exported in the subschema entries at the server. I know of one ldap client that breaks because of this: luma. It says it can't display the cn=monitor entries because it doesn't know the object classes or attributes. I guess it uses this info to determine how to show each entry.

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