openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 10 Sep '07

10 Sep '07

raphael.ouazana(a)linagora.com wrote: > Do you think this patch has any chance to be accepted for future 2.4? Applied (with minor changes) to HEAD, please test. And, could you document it on the FAQ, please? One improvement that could be applied is to allow numbers larger than 9... 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4860) Sets' enhancement
by raphael.ouazana＠linagora.com 09 Sep '07

09 Sep '07

Hi, I have uploaded a new version of this patch: ftp://ftp.openldap.org/incoming/raphael-ouazana-070906.patch Now /-0 allows to get all the parents of an entry. So to keep the example where user is cn=user,ou=people,dc=example,dc=com: user/-0 : resolves to set { "cn=user,ou=people,dc=example,dc=com" , "ou=people,dc=example,dc=com", "dc=example,dc=com" , "dc=com" , "" } In fact it was already possible to do that with sets with filters using entryDN:dnSuperiorMatch, but it was really slower (in 2.3 as in HEAD). Do you think this patch has any chance to be accepted for future 2.4? Regards, Raphael Ouazana. Legal notice : This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in this following patch were developed by Raphael Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to any license of Linagora. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2007 Raphael Ouazana, Linagora Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#5130) "Reply" oddities
by kurt＠OpenLDAP.org 08 Sep '07

08 Sep '07

On Sep 8, 2007, at 10:02 AM, ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: none > OS: none > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.35) > Submitted by: ando > > > When hitting "reply" from the ITS, messages are not sent to the > mailing list, > even if openldap-its(a)openldap.org is added to the CC field. Kind of by (broken) design. A reply is intended to be used to send a note directly to the submitter. It's broken in that you need to change the from header to openldap-its(a)openldap.org for any follow-up to be returned to openldap-its(a)openldap.org. If you want to reply-all, reply-all to the copy forwarded to openldap-bugs(a)openldap.org.

1 0

Re: (ITS#5130) "Reply" oddities
by ghenry＠suretecsystems.com 08 Sep '07

08 Sep '07

<quote who="ando(a)sys-net.it"> > ghenry(a)suretecsystems.com wrote: > >>> When hitting "reply" from the ITS, messages are not sent to the mailing >>> list, >>> even if openldap-its(a)openldap.org is added to the CC field. >>> >> >> Testing. > > I've received yours (twice, as usual), but I don't receive mine. This is a reply via a normal mail client to openldap-its only, not cc'd to you. > > 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 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > > >

1 0

Re: (ITS#5130) "Reply" oddities
by ando＠sys-net.it 08 Sep '07

08 Sep '07

ghenry(a)suretecsystems.com wrote: >> When hitting "reply" from the ITS, messages are not sent to the mailing >> list, >> even if openldap-its(a)openldap.org is added to the CC field. >> > > Testing. I've received yours (twice, as usual), but I don't receive mine. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5130) "Reply" oddities
by ghenry＠suretecsystems.com 08 Sep '07

08 Sep '07

<quote who="ando(a)sys-net.it"> > Full_Name: Pierangelo Masarati > Version: none > OS: none > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.35) > Submitted by: ando > > > When hitting "reply" from the ITS, messages are not sent to the mailing > list, > even if openldap-its(a)openldap.org is added to the CC field. > Testing.

1 0

(ITS#5130) "Reply" oddities
by ando＠sys-net.it 08 Sep '07

08 Sep '07

Full_Name: Pierangelo Masarati Version: none OS: none URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando When hitting "reply" from the ITS, messages are not sent to the mailing list, even if openldap-its(a)openldap.org is added to the CC field.

1 0

Re: (ITS#5120) slapadd -q makes database logs unusable
by ando＠sys-net.it 08 Sep '07

08 Sep '07

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> hyc(a)symas.com wrote: >>> ando(a)sys-net.it wrote: >>>> When slapadd'ing -q, existing database log files seem to become unusable. If >>>> this is correct, as it seems to be, slapadd could refuse to start with -q if log >>>> files are present, or, for example, remove the logs if -qq. >>> I guess we could add that check. The docs already say that if an error occurs, >>> the entire database will be unusable. As such, you should only use it for >>> initially populating a database, not for adding to an existing one. >> The story is that I placed logs in a separate directory and I forgot to >> clean them up when regenerating the DB after removing the database files :) > > Ugh. I don't see how we can reliably detect this case. > > In what way do the logs become unusable? I've tried to reproduce this situation > and see no errors of any kind. > > E.g., sh run test001 > rm testrun/db.1.a/{alock,*db*} > ../servers/slapd/slapadd -q -f testrun/slapd.1.conf -l testdata/test-ordered.ldif > (the above works fine) > ../servers/slapd/slapd -f testrun/slapd.1.conf ... > (works fine) > > db_stat -h testrun/db.1.a -l > > (no complaints there either) Initially, I thought your check was not much representative, since test001 doesn't do any writes. In my original case, I forgot to mention that DB_LOG_AUTOREMOVE was set. So I tried that configuration and manually ran the load of test008, resulting in creating multiple logs, part of which were removed. Then I ran the commands you suggested above, but nothing happened, so I'm at a loss. In fact, old log files were immediately removed by slapd itself, and log files numbering correctly restarted from where it left. Probably I was chasing a red herring. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5120) slapadd -q makes database logs unusable
by hyc＠symas.com 08 Sep '07

08 Sep '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> ando(a)sys-net.it wrote: >>> When slapadd'ing -q, existing database log files seem to become unusable. If >>> this is correct, as it seems to be, slapadd could refuse to start with -q if log >>> files are present, or, for example, remove the logs if -qq. >> I guess we could add that check. The docs already say that if an error occurs, >> the entire database will be unusable. As such, you should only use it for >> initially populating a database, not for adding to an existing one. > > The story is that I placed logs in a separate directory and I forgot to > clean them up when regenerating the DB after removing the database files :) Ugh. I don't see how we can reliably detect this case. In what way do the logs become unusable? I've tried to reproduce this situation and see no errors of any kind. E.g., sh run test001 rm testrun/db.1.a/{alock,*db*} ../servers/slapd/slapadd -q -f testrun/slapd.1.conf -l testdata/test-ordered.ldif (the above works fine) ../servers/slapd/slapd -f testrun/slapd.1.conf ... (works fine) db_stat -h testrun/db.1.a -l (no complaints there either) -- -- 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#5129) slapindex -q corrupts database if the DB_CONFIG file has changed
by hyc＠symas.com 08 Sep '07

08 Sep '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.37 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.202.148.128) > > > After getting repeat DB corruptions, I finally tracked down the issue to this: > > If DB_CONFIG has changed since the last time slapd was started, and slapindex -q > is run, the database ends up corrupt. Don't do that. HEAD has been fixed to exit in this situation. -- -- 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

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