openldap-bugs May 2010

openldap-bugs@openldap.org

28 participants
84 discussions

(ITS#6542) Segmentation Fault if config file (ldif) got changed
by felix.schuster＠gmx.at 01 May '10

01 May '10

Full_Name: Felix Version: 2.4.19 OS: Linux/Gentoo URL: Submission from: (NULL) (78.142.131.97) Using the new configuration scheme, I changed /etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif of a running openldap instance. When I tried to restart openldap it gaves me a Segmentation Fault error. Even if I called the changes off, openldap refused to start (furthermore segfaulted). I needed to get a copy of the original configuration file from my backup to successfully start openldap again. I think it's somewhere ok to deny working with a hand-changed configuration, but I think we will need a friendly advise, no unfriendly Segementation Fault error.

1 0

Re: (ITS#6247)
by Kurt＠OpenLDAP.org 01 May '10

01 May '10

On May 1, 2010, at 12:31 PM, daniel(a)pluta.biz wrote: > Hi, >=20 > just some changes and cleanups according the still ongoing discussion = on=20 > ldapext. I recommend consideration of this patch be deferred until the = specification is less of a work-in-a-progress. >=20 > The patch can be downloaded here:=20 > ftp://ftp.openldap.org/incoming/daniel-pluta-100501.patch >=20 > Changes: > - removed extensible matching rules strictly associated with=20 > dedicated syntaxes > - added two universal matching rules instead: > - nowMach (equality matching rule) > - nowOrdering (ordering matching rule) > - these two rules also support extensible match filters Your comments imply these rules could be used as attribute type equality = and ordering rules. I don't believe the met the requirements (see = X.501) to be used in that manner. That is, they only make sense as = extensible matching rules. >=20 > To publish a correct server current time time-stamp value within = Root-DSE: > - apply the bugfix from ITS#6541 > - and use -DCTM_G_DIFFERENTIAL_SERVERTIME #ifdef's should, IMO, be generally avoided. >=20 >=20 > To extend generalizedTime attribute types to also support "NOW" as=20 > assertion value: > - use -DCTM_RFC4517_MR_AV_SYNTAX_VIOLATION The generalized time syntax is not ours to alter. Introduction of such = a change would, it seem, lead to interoperability problems. >=20 >=20 > Beware of patching conflicts in schema_init.c: > This patch contains small redundant parts from my parallel = contribution=20 > in ITS#6532 >=20 > Regards, > Daniel >=20 >=20

1 0

(ITS#6247)
by daniel＠pluta.biz 01 May '10

01 May '10

Hi, just some changes and cleanups according the still ongoing discussion on ldapext. The patch can be downloaded here: ftp://ftp.openldap.org/incoming/daniel-pluta-100501.patch Changes: - removed extensible matching rules strictly associated with dedicated syntaxes - added two universal matching rules instead: - nowMach (equality matching rule) - nowOrdering (ordering matching rule) - these two rules also support extensible match filters To publish a correct server current time time-stamp value within Root-DSE: - apply the bugfix from ITS#6541 - and use -DCTM_G_DIFFERENTIAL_SERVERTIME To extend generalizedTime attribute types to also support "NOW" as assertion value: - use -DCTM_RFC4517_MR_AV_SYNTAX_VIOLATION Beware of patching conflicts in schema_init.c: This patch contains small redundant parts from my parallel contribution in ITS#6532 Regards, Daniel

1 0

(ITS#6541) liblutil/ultils.c: lutil_localtime() <g-differential> timestamp format bug
by daniel＠pluta.biz 01 May '10

01 May '10

Full_Name: Daniel Pluta Version: HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff02:91d5:32:f2b:def0) Hi, for a description and a possible patch (to small for an upload ;-)) please see: http://www.openldap.org/lists/openldap-devel/201003/msg00012.html Cheers

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2010