openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

Re: (ITS#5872) slapo-cloak
by manu＠netbsd.org 27 Dec '08

27 Dec '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > That's my opinion, of course. I suggest you start from contrib/ and > then we'll vote for moving it to overlays/. How do I book an OID for the config database, for an overlay in contrib? Is it ok to just keep the comment in servers/slapd/bconfig.c? * OLcfgOv{Oc|At}:22 -> cloak -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5872) slapo-cloak
by manu＠netbsd.org 27 Dec '08

27 Dec '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > It is :). However, I think only generally useful things should go into > mainstream. As such, I remember some overlays moving from overlays/ to > slapd-modules/ and others moving the other way, based on their > generality and usefulness. The annoying thing is that the only added value of contrib/ is to make building more difficult. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 27 Dec '08

27 Dec '08

Emmanuel Dreyfus wrote: >> I'd see this overlay more appropriate for contrib/slapd-modules right >> now, until its functionality is considered of general usefulness, which >> doesn't seem to be the case right now. > > Do you think an overlay in the contrib directory could have its --enable > flag in top level configure? > > My feeling about the contrib directory is that it is some kind of evil > swamp where things are much more difficult to automatically build for > inclusion in a package. It is :). However, I think only generally useful things should go into mainstream. As such, I remember some overlays moving from overlays/ to slapd-modules/ and others moving the other way, based on their generality and usefulness. For example, smbk5pwd should be in overlays/, given its usefulness, but it is probably not general enough. Yours is general (i.e. not tied to a specific architecture or interoperation issue), but probably of limited usefulness (how many users would actually need it?). That's my opinion, of course. I suggest you start from contrib/ and then we'll vote for moving it to overlays/. 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#5872) slapo-cloak
by manu＠netbsd.org 27 Dec '08

27 Dec '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > I'd see this overlay more appropriate for contrib/slapd-modules right > now, until its functionality is considered of general usefulness, which > doesn't seem to be the case right now. Do you think an overlay in the contrib directory could have its --enable flag in top level configure? My feeling about the contrib directory is that it is some kind of evil swamp where things are much more difficult to automatically build for inclusion in a package. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

(ITS#5873) slapd(8) does not mention sid in -c option value
by ando＠sys-net.it 27 Dec '08

27 Dec '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Slapd(8)'s -c option allows to set the replication cookie to start replication with. Currently it states that valid name/value pairs are rid and csn; however, 2.4 allows sid as well, in multi-master/mirror-mode replication agreements. Not sure whether setting any sid in this cookie makes any sense, but the man page should note it for clarity and completeness. p.

1 0

Re: (ITS#5868) failed assertion with back-relay
by ando＠sys-net.it 27 Dec '08

27 Dec '08

Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.4.12 > OS: Mandriva linux > URL: > Submission from: (NULL) (193.55.250.67) Can't reproduce with HEAD or 2.4.12; you need to provide more details: a minimal slapd.conf, a minimal ldif and the exact operation that fails. 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#5872) slapo-cloak
by ando＠sys-net.it 27 Dec '08

27 Dec '08

manu(a)netbsd.org wrote: > The cloak overlay to slapd(8) allows the server to hide specific > attributes, unless explicitely requested by the client. This improve > performance when a client requests all attributes and get a huge binary > attribute that is of no interest for it (think jpegPhoto) I'd see this overlay more appropriate for contrib/slapd-modules right now, until its functionality is considered of general usefulness, which doesn't seem to be the case right now. On a related note, if this can be considered of general usefulness, LDAP specs would need to be changed in order to define a finer grain of attribute request; something like: empty or "*" ; all user, except attrs that need to be explicitly req. "+" ; all operational <all including attrs that need to be explicitly requested> <...> 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#5872) slapo-cloak
by manu＠netbsd.org 24 Dec '08

24 Dec '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD-4.0 URL: ftp://ftp.openldap.org/incoming/manu-cloak-20081225.patch Submission from: (NULL) (213.41.141.172) The cloak overlay to slapd(8) allows the server to hide specific attributes, unless explicitely requested by the client. This improve performance when a client requests all attributes and get a huge binary attribute that is of no interest for it (think jpegPhoto)

1 0

(ITS#5868) failed assertion with back-relay
by Guillaume.Rousse＠inria.fr 22 Dec '08

22 Dec '08

Full_Name: Guillaume Rousse Version: 2.4.12 OS: Mandriva linux URL: Submission from: (NULL) (193.55.250.67) Here's my back-relay configuration: database relay suffix ou=telephony,dc=msr-inria,dc=inria,dc=fr overlay rwm rwm-suffixmassage ou=users,dc=msr-inria,dc=inria,dc=fr rwm-map attribute telephoneNumber homePhone rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute uid * rwm-map attribute * access to dn.subtree="ou=telephony,dc=msr-inria,dc=inria,dc=fr" by * read The server crashes immediatly when attempting a query for given prefix. Here is debug trace: slap_listener_activate(7): >>> slap_listener(ldap:///) connection_get(17): got connid=0 connection_read(17): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 12 contents: ber_get_next conn=0 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 17 do_bind: v3 anonymous bind connection_get(17): got connid=0 connection_read(17): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 77 contents: ber_get_next conn=0 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <ou=telephony,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <ou=telephony,dc=msr-inria,dc=inria,dc=fr>, <ou=telephony,dc=msr-inria,dc=inria,dc=fr> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: ==> limits_get: conn=0 op=1 dn="[anonymous]" ==> rewrite_context_apply [depth=1] string='ou=telephony,dc=msr-inria,dc=inria,dc=fr' ==> rewrite_rule_apply rule='((.+),)?ou=telephony,[ ]?dc=msr-inria,[ ]?dc=inria,[ ]?dc=fr$' string='ou=telephony,dc=msr-inria,dc=inria,dc=fr' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ou=users,dc=msr-inria,dc=inria,dc=fr'} >>> dnPrettyNormal: <ou=users,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <ou=users,dc=msr-inria,dc=inria,dc=fr>, <ou=users,dc=msr-inria,dc=inria,dc=fr> ==> rewrite_context_apply [depth=1] string='(objectClass=*)' ==> rewrite_context_apply [depth=1] res={0,'NULL'} put_filter: "(objectClass=*)" put_filter: simple put_simple_filter: "objectClass=*" ber_scanf fmt (m) ber: => bdb_search bdb_dn2entry("ou=users,dc=msr-inria,dc=inria,dc=fr") => bdb_dn2id("ou=users,dc=msr-inria,dc=inria,dc=fr") <= bdb_dn2id: got id=0x2 entry_decode: "ou=users,dc=msr-inria,dc=inria,dc=fr" <= entry_decode(ou=users,dc=msr-inria,dc=inria,dc=fr) search_candidates: base="ou=users,dc=msr-inria,dc=inria,dc=fr" (0x00000002) scope=2 => bdb_dn2idl("ou=users,dc=msr-inria,dc=inria,dc=fr") <= bdb_dn2idl: id=90 first=2 last=190 => bdb_presence_candidates (objectClass) bdb_search_candidates: id=90 first=2 last=190 ==> rewrite_context_apply [depth=1] string='ou=users,dc=msr-inria,dc=inria,dc=fr' ==> rewrite_rule_apply rule='((.+),)?ou=users,[ ]?dc=msr-inria,[ ]?dc=inria,[ ]?dc=fr$' string='ou=users,dc=msr-inria,dc=inria,dc=fr' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ou=telephony,dc=msr-inria,dc=inria,dc=fr'} >>> dnPrettyNormal: <ou=telephony,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <ou=telephony,dc=msr-inria,dc=inria,dc=fr>, <ou=telephony,dc=msr-inria,dc=inria,dc=fr> => send_search_entry: conn 0 dn="ou=telephony,dc=msr-inria,dc=inria,dc=fr" ber_flush2: 93 bytes to sd 17 <= send_search_entry: conn 0 exit. entry_decode: "uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr" <= entry_decode(uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr) => bdb_dn2id("uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr") <= bdb_dn2id: got id=0x4 ==> rewrite_context_apply [depth=1] string='uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr' ==> rewrite_rule_apply rule='((.+),)?ou=users,[ ]?dc=msr-inria,[ ]?dc=inria,[ ]?dc=fr$' string='uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr'} >>> dnPrettyNormal: <uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr>, <uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr> => send_search_entry: conn 0 dn="uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr" ber_flush2: 229 bytes to sd 17 <= send_search_entry: conn 0 exit. entry_decode: "uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr" <= entry_decode(uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr) => bdb_dn2id("uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr") <= bdb_dn2id: got id=0x6 ==> rewrite_context_apply [depth=1] string='uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr' ==> rewrite_rule_apply rule='((.+),)?ou=users,[ ]?dc=msr-inria,[ ]?dc=inria,[ ]?dc=fr$' string='uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'uid=fmorin,ou=telephony,dc=msr-inria,dc=inria,dc=fr'} >>> dnPrettyNormal: <uid=fmorin,ou=telephony,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <uid=fmorin,ou=telephony,dc=msr-inria,dc=inria,dc=fr>, <uid=fmorin,ou=telephony,dc=msr-inria,dc=inria,dc=fr> => send_search_entry: conn 0 dn="(null)" slapd: entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' failed I'm running openldap 2.4.12 (official mandriva package) under mandriva x86_64.

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 22 Dec '08

22 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-26328-1229943475-0001-2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 'HEAD' I get the following: ./slapd -h "ldap:///" slapo-ppolicy cannot be global Seems like a decent solution Thanks --=20 Mark Janssen Visit HAR2009, the four-yearly Dutch outdoor technology-conference August 13-16, 2009, vierhouten. http://www.har2009.org --=_server11-26328-1229943475-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklPcrIACgkQb6urvDV9IXhs4gCeM0FRAXrZ1NKGZn5V3w9Igs07 STMAn1zn7owuM9xj5K7+YdR3QGUhEWGo =8U9N -----END PGP SIGNATURE----- --=_server11-26328-1229943475-0001-2--

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