openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#5905) [patch] autoconf should check for uuid functions
by richton＠nbcs.rutgers.edu 25 Jan '09

25 Jan '09

Full_Name: Aaron Richton Version: RE24 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/openldap-uuidunparse.patch Submission from: (NULL) (128.6.68.244) The recent fix for ITS # 5888 unmasked this presumably long-standing issue. uuid_create and uuid_unparse_lower are used without autoconf verifying them first. An up-to-pat ch Solaris 9, in particular, is an example of a platform where uuid_generate exists without uuid_unparse_lower. Google seems to show that older Linux ~2006 has a similar situation.

1 0

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

25 Jan '09

Quanah Gibson-Mount wrote: > --On Saturday, January 24, 2009 3:19 PM +0000 jclarke(a)linagora.com wrote: > >> Currently, each description offers different levels and different >> descriptions. In particular, only the first mentions the keywords (as >> well as integers). None mention the "None" level. > > I disagree. From slapd.conf(5): > > loglevel <integer> [...] > 32768 (0x8000 none) only messages that get logged > whatever log level is set > > > I see "none" documented right there. Yes, absolutely. I was referring only to the admin guide. This man page is indeed where I copied that definition from for the patch to the admin guide :) Jonathan -- Jonathan Clarke -- LinID - Open Source Identity Management --------------------------------------------------------------- Linagora 27 rue de Berri, 75008 Paris Tel: 01 58 18 68 28 / 06 99 60 03 10 --------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org/ ---------------------------------------------------------------

1 0

Re: (ITS#5904) Docs: admin guide describes log levels inconsistently
by quanah＠zimbra.com 24 Jan '09

24 Jan '09

--On Saturday, January 24, 2009 3:19 PM +0000 jclarke(a)linagora.com wrote: > Currently, each description offers different levels and different > descriptions. In particular, only the first mentions the keywords (as > well as integers). None mention the "None" level. I disagree. From slapd.conf(5): loglevel <integer> [...] 32768 (0x8000 none) only messages that get logged whatever log level is set I see "none" documented right there. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5904) Docs: admin guide describes log levels inconsistently
by quanah＠zimbra.com 24 Jan '09

24 Jan '09

--On Saturday, January 24, 2009 10:51 PM +0000 ghenry(a)suretecsystems.com wrote: > The man pages always have the most details, but I think what ever the code > has regarding options is the master source. > > Can anyone clarify? Hm, I was under the impression that -d (debug level) and LOG level were different. I.e., they don't always apply straight across. -d debug-level Turn on debugging as defined by debug-level. If this option is specified, even with a zero argument, slapd will not fork or disassociate from the invoking terminal. Some general operation and status messages are printed for any value of debug-level. debug-level is taken as a bit string, with each bit correspond- ing to a different kind of debugging information. See <ldap_log.h> for details. Comma-separated arrays of friendly names can be specified to select debugging output of the corre- sponding debugging information. All the names recognized by the loglevel directive described in slapd.conf(5) are supported. If debug-level is ?, a list of installed levels is printed, and slapd exits. And the man page for slapd seems to back that up. I.e., any LOG level setting works with -d, but there may be -d options that are beyond what LOG level supports. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5904) Docs: admin guide describes log levels inconsistently
by ghenry＠suretecsystems.com 24 Jan '09

24 Jan '09

----- jclarke(a)linagora.com wrote: > Full_Name: Jonathan Clarke > Version: irrelevant > OS: irrelevant > URL: > ftp://ftp.openldap.org/incoming/jonathan-clarke-guide-20090124-2.patch > Submission from: (NULL) (62.147.206.193) > > > The different log/debug levels available are described in three places > in the > admin guide: for olcLogLevel attribute in cn=config, for loglevel in > slapd.conf > and for -d command line option to slapd. > > Currently, each description offers different levels and different > descriptions. > In particular, only the first mentions the keywords (as well as > integers). None > mention the "None" level. > > I propose the patch below that offers similar information in all three > places, > an example clarifying the difference between loglevels "0" and "None" > and > clarification of the cn=config default. Most text is simply copied > from the man > pages. OK, thanks. Will take a look. > On a side note, the man pages have levels "cache" and "index" (4096 > and 8192) > commented out. The output from slapd -d? include them. Which should > the admin > guide reflect? The man pages always have the most details, but I think what ever the code has regarding options is the master source. Can anyone clarify? -- 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#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 24 Jan '09

24 Jan '09

--001485f01b2867b84704613d5bd9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Jan 25, 2009 at 12:53 AM, Pierangelo Masarati <ando(a)sys-net.it>wrote: > > If so, i can still see the behaviour here with 2.4.13, i can see >> operational >> attributes, but non non-operational attributes, when mapping both >> objectclass and attribute.. >> >> Bug seems to be focused on using of *, rather than an explicit list of >> non-operational attrs which works, ie : >> >> I can search for attributes with * ( get all non-operational attributes ) >> and don't get any non-operational attributes, whereas explicitly adding >> any >> non-operational attribute will result i a search returning the named >> values, >> which is allowable via the objectclass maps. >> >> seems to work the same (omitting non-oprational attrs), even if i dont >> specufy the objectclass rwm maps. >> > > Not sure I understand. Can you post simple (both working and not working) > examples? > Last time i looked at this after release of 2.4.13 it was not working. Eg: given attribute maps: # these dont work rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute mail * rwm-map attribute c * rwm-map attribute o * rwm-map attribute ou * # these work rwm-map attribute hasSubordinates * rwm-map attribute subschemaSubentry * rwm-map attribute entryUUID * # this enabled rwm-map attribute * I could see operational attributes, in response to having + in the attribute list when querying, and would get all operational attributes without naming them specifically. But i could not similarly use *, to return all non-operational attributes without specifying them individually. As most ldap browsers default to using *,+ in the attribute list, i could only see operational attributes when using an ldap browser with it's default settings. However if i specifically put cn,sn,givenName,etc., in the attribute list instead of using the shortcut *,+ i could get non-operational attributes (cn,sn,givenName,etc.,) showing normally in queries. The specific configs are not around anymore, but the snippit above from the ITS covers the important rwm-map bits. I will try to duplicate my previous results in detail, with debugging, to help diagnose this further... Cheers Brett --001485f01b2867b84704613d5bd9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sun, Jan 25, 2009 at 12:53 AM, Pierangelo= Masarati <<a href=3D"mailto:ando@sys-net.it">ando@sys= -net.it</a>> wrote: <blockquote class=3D"gmail_quote" style=3D= "border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padd= ing-left: 1ex;"> <div class=3D"Ih2E3d"> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> If so, i can still see the behaviour here with 2.4.13, i can see operationa= l attributes, but non non-operational attributes, when mapping both objectclass and attribute.. Bug seems to be focused on using of *, rather than an explicit list of non-operational attrs which works, ie : I can search for attributes with * ( get all non-operational attributes )<b= r> and don't get any non-operational attributes, whereas explicitly adding= any non-operational attribute will result i a search returning the named values= , which is allowable via the objectclass maps. seems to work the same (omitting non-oprational attrs), even if i dont specufy the objectclass rwm maps. </blockquote> </div> Not sure I understand.  Can you post simple (both working and not work= ing) examples?<div> </div></blockquote></div> Last time i looked at this after release of 2.= 4.13 it was not working. Eg: given attribute maps: <pre># these dont wor= k rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute = givenName * rwm-map attribute mail * rwm-map attribute c * rwm-map attribute o *<= br>rwm-map attribute ou * # these work rwm-map attribute hasSubor= dinates * rwm-map attribute subschemaSubentry * rwm-map attribute ent= ryUUID * # this enabled rwm-map attribute * </pre>I could see operational = attributes, in response to having + in the attribute list when querying, an= d would get all operational attributes without naming them specifically. Bu= t i could not similarly use *, to return all non-operational attributes wit= hout specifying them individually. As most ldap browsers default to using *,+ in the attribute list, i cou= ld only see operational attributes when using an ldap browser with it's= default settings. However if i specifically put  cn,sn,givenNa= me,etc., in the attribute list instead of using the shortcut *,+ i could ge= t non-operational attributes (cn,sn,givenName,etc.,) showing normally in qu= eries. The specific configs are not around anymore, but the snippit above from= the ITS covers the important rwm-map bits. I will try to duplicate = my previous results in detail, with debugging, to help diagnose this furthe= r... Cheers Brett --001485f01b2867b84704613d5bd9--

1 0

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

24 Jan '09

Full_Name: Jonathan Clarke Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-guide-20090124-2.patch Submission from: (NULL) (62.147.206.193) The different log/debug levels available are described in three places in the admin guide: for olcLogLevel attribute in cn=config, for loglevel in slapd.conf and for -d command line option to slapd. Currently, each description offers different levels and different descriptions. In particular, only the first mentions the keywords (as well as integers). None mention the "None" level. I propose the patch below that offers similar information in all three places, an example clarifying the difference between loglevels "0" and "None" and clarification of the cn=config default. Most text is simply copied from the man pages. On a side note, the man pages have levels "cache" and "index" (4096 and 8192) commented out. The output from slapd -d? include them. Which should the admin guide reflect?

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 24 Jan '09

24 Jan '09

Andrew Bartlett wrote: > While I'm still confused about the ASN.1, I've coded to match OpenLDAP's > current behaviour. > > The deref overlay seems to be working well. Many thanks! Cool. I'd appreciate some definitive review of the correspondence of the implementation with respect to the draft (draft-masarati-ldap-deref in docs/draft, or from the IETF ID interface). That's the best I could put in place so far. 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#5760) attribute hiding in rwm overlay
by ando＠sys-net.it 24 Jan '09

24 Jan '09

[please reply to the ITS, otherwise issues can't be tracked] Brett @Google wrote: > HI Ando, > > Do you know if the fix for ITS#5760 (says fixed for RE24 and HEAD) make it > into RE24 in time for the 2.4.13 release ? apparently, yes. > If so, i can still see the behaviour here with 2.4.13, i can see operational > attributes, but non non-operational attributes, when mapping both > objectclass and attribute.. > > Bug seems to be focused on using of *, rather than an explicit list of > non-operational attrs which works, ie : > > I can search for attributes with * ( get all non-operational attributes ) > and don't get any non-operational attributes, whereas explicitly adding any > non-operational attribute will result i a search returning the named values, > which is allowable via the objectclass maps. > > seems to work the same (omitting non-oprational attrs), even if i dont > specufy the objectclass rwm maps. Not sure I understand. Can you post simple (both working and not working) examples? 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#5796) back-sql intermittently failing
by ando＠sys-net.it 24 Jan '09

24 Jan '09

Robert Brooks wrote: > any luck with this? Not even in my priority list right now, sorry. A patch would be welcome. 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

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