openldap-bugs November 2008

openldap-bugs@openldap.org

44 participants
242 discussions

Re: (ITS#5811) slapo-dds documentation
by manu＠netbsd.org 15 Nov '08

15 Nov '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > So, was that the issue? Yes, and I just added it to the man page. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5804) attribute value regex expantion
by manu＠netbsd.org 15 Nov '08

15 Nov '08

Emmanuel Dreyfus <manu(a)netbsd.org> wrote: > I committed the modification: > http://www.openldap.org/lists/openldap-commit/200811/msg00303.html And this: http://www.openldap.org/lists/openldap-commit/200811/msg00302.html -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5804) attribute value regex expantion
by manu＠netbsd.org 15 Nov '08

15 Nov '08

I committed the modification: http://www.openldap.org/lists/openldap-commit/200811/msg00303.html -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5811) slapo-dds documentation
by ando＠sys-net.it 15 Nov '08

15 Nov '08

manu(a)netbsd.org wrote: > Full_Name: Emmanuel Dreyfus > Version: HEAD > OS: NetBSD > URL: > Submission from: (NULL) (213.41.141.172) > > > slapo-dds(5) does not document that rootdn definition is mandatory for proper > function So, was that the issue? 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#5811) slapo-dds documentation
by manu＠netbsd.org 15 Nov '08

15 Nov '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD URL: Submission from: (NULL) (213.41.141.172) slapo-dds(5) does not document that rootdn definition is mandatory for proper function

1 0

Re: (ITS#5807) build broken for solaris 9
by hyc＠symas.com 14 Nov '08

14 Nov '08

brett.maxfield(a)gmail.com wrote: > Full_Name: Brett Maxfield > Version: 2.4.RELENG > OS: Solaris 9 (SunOS 2.9) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.18.108.167) > > > Hello, > > Trying to make tests for RE24 and 2.4.12 on solaris (SunOS 2.9) and getting a > failure : > > (build options - berkeleyDB previously installed with > --prefix=/usr/local/openldap24) > > export PATH=/usr/local/bin:/usr/ccs/bin:/usr/bin:/bin:/usr/sbin:/sbin > export LD_LIBRARY_PATH=/usr/local/openldap24/lib:/usr/local/ssl/lib:/usr/local/lib > CPPFLAGS="-I/usr/local/openldap24/include -I/usr/local/include" > LDFLAGS="-L/usr/local/openldap24/lib -L/usr/local/lib > -R/usr/local/openldap24/lib -R/usr/local/lib" ./configure --enable-shared > --enable-ssl --disable-ipv6 --with-threads --enable-slapd --enable-backends > --enable-overlays --disable-sql --disable-ndb --disable-slapi > > (result of make test, fails on the first test) > > # cat tests/testrun/slapd.1.log > @(#) $OpenLDAP: slapd 2.4.12 (Nov 13 2008 17:57:10) $ > testuser@myhost:/export/home/testuser/openldap24-build/openldap-2.4.12/servers/slapd > ldap_pvt_gethostbyname_a: host=myhost, r=0 > daemon_init: ldap://localhost:9011/ > daemon_init: listen on ldap://localhost:9011/ > daemon_init: 1 listeners to open... > ldap_url_parse_ext(ldap://localhost:9011/) > daemon: getaddrinfo() failed: invalid ai_flags > slapd stopped. > connections_destroy: nothing to destroy. > > ai_flags has to do with the options to listen/accept, and should be something > like NULL, it seemss sol9 does not like the AI_PASSIVE value. > > I manually changed it to šhints.ai_flags = NULL; // AI_PASSIVE;" > (servers/slapd/daemon.c line 1131) and the code compiles, and make test > succeeds. > > For solaris 9, hints.ai_flags should just use NULL. The Solaris 9 docs say otherwise. http://docs.sun.com/app/docs/doc/816-0214/6m6nf1omp?a=view#indexterm-646 >>> If the AI_PASSIVE bit is set in the ai_flags member of the hints structure, the caller plans to use the returned socket address structure in a call to bind(3SOCKET). <<< We are using the flag correctly per the documentation, therefore I don't believe this is an OpenLDAP bug. Take this up with Sun... -- -- 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by hyc＠symas.com 14 Nov '08

14 Nov '08

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> Pierangelo Masarati writes: >>>> I think ITS#5326 is related. Namely, write operations (add, rename) >>>> should always rebuild the (new)DN hierarchically from the tree. >>> I'm not sure what exactly the problem is, if any:-) Syncrepl itself >>> needs to handle databases that are not that nice: We can't require >>> that of back-perl, nor back-ldap which accesses a non-OpenLDAP server >>> (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl >>> is an RFC (4533) so it should handle non-OpenLDAP peers. >> Syncrepl of course *handles* all of those cases. The only issue here is that >> our tests expect the results to be in a specific order, which is obviously an >> invalid requirement in the grand scheme of things. > I'm hitting an issue like this in some of the replication tests I'm > currently performing. For this purpose, I think we could hack > ldapsearch (or add a new prog, or use a script on ldapsearch output) > that sorts entries content attribute-wise and, within each attribute, > value-wise. Something like "sort" applied entry-wise after unwrapping > line folding, optionally case-insensitive would probably suffice. Hm, I already added that, when I was first putting back-ndb thru the test suite. In acfilter.sh, but currently only used for back-ndb too. At any rate, I've tweaked the consumer's rename detection code, so this specific ITS is now fixed. -- -- 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by ando＠sys-net.it 14 Nov '08

14 Nov '08

Quanah Gibson-Mount wrote: >> I'm hitting an issue like this in some of the replication tests I'm >> currently performing. For this purpose, I think we could hack >> ldapsearch (or add a new prog, or use a script on ldapsearch output) >> that sorts entries content attribute-wise and, within each attribute, >> value-wise. Something like "sort" applied entry-wise after unwrapping >> line folding, optionally case-insensitive would probably suffice. > > I have a script somewhere from Matt Backes @ Symas that sorts LDIF > files. It was useful for seeing if it made any difference in slapadd (it > didn't). Well, if it were distributable, and written in a widely supported scripting language, it would be quite useful... 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by quanah＠zimbra.com 14 Nov '08

14 Nov '08

--On Friday, November 14, 2008 9:34 PM +0000 ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> Pierangelo Masarati writes: >>>> I think ITS#5326 is related. Namely, write operations (add, rename) >>>> should always rebuild the (new)DN hierarchically from the tree. >>> I'm not sure what exactly the problem is, if any:-) Syncrepl itself >>> needs to handle databases that are not that nice: We can't require >>> that of back-perl, nor back-ldap which accesses a non-OpenLDAP server >>> (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl >>> is an RFC (4533) so it should handle non-OpenLDAP peers. >> >> Syncrepl of course *handles* all of those cases. The only issue here is >> that our tests expect the results to be in a specific order, which is >> obviously an invalid requirement in the grand scheme of things. > > > I'm hitting an issue like this in some of the replication tests I'm > currently performing. For this purpose, I think we could hack > ldapsearch (or add a new prog, or use a script on ldapsearch output) > that sorts entries content attribute-wise and, within each attribute, > value-wise. Something like "sort" applied entry-wise after unwrapping > line folding, optionally case-insensitive would probably suffice. I have a script somewhere from Matt Backes @ Symas that sorts LDIF files. It was useful for seeing if it made any difference in slapadd (it didn't). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by ando＠sys-net.it 14 Nov '08

14 Nov '08

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Pierangelo Masarati writes: >>> I think ITS#5326 is related. Namely, write operations (add, rename) >>> should always rebuild the (new)DN hierarchically from the tree. >> I'm not sure what exactly the problem is, if any:-) Syncrepl itself >> needs to handle databases that are not that nice: We can't require >> that of back-perl, nor back-ldap which accesses a non-OpenLDAP server >> (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl >> is an RFC (4533) so it should handle non-OpenLDAP peers. > > Syncrepl of course *handles* all of those cases. The only issue here is that > our tests expect the results to be in a specific order, which is obviously an > invalid requirement in the grand scheme of things. I'm hitting an issue like this in some of the replication tests I'm currently performing. For this purpose, I think we could hack ldapsearch (or add a new prog, or use a script on ldapsearch output) that sorts entries content attribute-wise and, within each attribute, value-wise. Something like "sort" applied entry-wise after unwrapping line folding, optionally case-insensitive would probably suffice. 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

← Newer
1
...
11
12
13
14
15
16
17
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2008