- openldap-bugs - openldap.org

RE: (ITS#5320) bug on the filter functionnality =*
by jpgressard＠hotmail.com 11 Jan '08

11 Jan '08

--_5a7f2691-df18-4e09-b6ca-32d395149553_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hallvard, I have followed the advices of Hallvard and it works. So after an upgrade to 2.4.7, you have to rebuild the indexes.1 - Stop the = slapd deamon2 - launch slapindex3 - relaunch the slapd deamon Thanks for your help. Jean-Paul> From: h.b.furuseth(a)usit.uio.no> To: jpgressard(a)hotmail.com> > jp= gressard(a)hotmail.com writes:> > The query (&(sn=3DXXXXXX*)(givenName=3D*))c= an not find the entry below.> > Does it help to stop slapd, run sbin/slapin= dex, and restart slapd?> You need to do that if you edit slapd.conf's index= statements,> and possibly when you upgrade.> > -- > Hallvard _________________________________________________________________ Nouveau ! Cr=E9ez votre profil Messenger ! http://home.services.spaces.live.com/= --_5a7f2691-df18-4e09-b6ca-32d395149553_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } </style> </head> <body class=3D'hmmessage'> Hi Hallvard, I have followed the advices of Hallvard and it works. So after an upgrade to 2.4.7, you have to rebuild the indexes. 1 - Stop = the slapd deamon 2 - launch slapindex 3 - relaunch the slapd deamon<B= R> Thanks for your help. Jean-Paul > From: h.b.furuseth(a)usit.uio.no > To: jpgressard= @hotmail.com > > jpgressard(a)hotmail.com writes: > > T= he query (&(sn=3DXXXXXX*)(givenName=3D*))can not find the entry below.<= BR>> > Does it help to stop slapd, run sbin/slapindex, and restar= t slapd? > You need to do that if you edit slapd.conf's index stateme= nts, > and possibly when you upgrade. > > -- > Ha= llvard <hr />Windows Live Messenger 2008 vient de sortir, enco= re plus de fun ! <a href=3D'http://www.windowslive.fr/majmessenger.asp' ta= rget=3D'_new'>T=E9l=E9chargez gratuitement Messenger 2008</a></body> </html>= --_5a7f2691-df18-4e09-b6ca-32d395149553_--

1 0

(ITS#5324) Access violation on Windows due to %n in format strings
by jeff.lewis＠teradata.com 10 Jan '08

10 Jan '08

Full_Name: Jeff Lewis Version: 2.3.20 OS: Microsoft Windows on IA64 URL: http://msdn2.microsoft.com/en-us/library/ms175782.aspx Submission from: (NULL) (192.127.94.7) We (Teradata, formerly NCR) have encountered a small glitch with the latest Windows SDK and OpenLDAP client tools. We're getting an access violation where we did not get one with the older SDK. Our IA64 builds require the newer SDK because of codegen issues with the older compilers...but soon, we're going to be moving to the newer SDK for i386 and x8664 so the problem will begin to crop up there as well. Here's the problem: In libraries/libldap/url.c, function ldap_url_desc2str, there are a couple of sprintfs that use %n in their format strings to return position information. The latest Windows SDKs have heavily deprecated %n and its use now results in an unfortunate access violation and process crash. We've added a call to "_set_printf_count_output(1)" in libraries/libldap/init.c function ldap_int_initialize() to re-enable %n so we're sufficiently worked around for the moment. We're happy with our own workaround so we're not asking for any kind of quick turnaround on this issue. If you want to fix this, please do so in your own time and in your own way. You can consider this a courtesy report only. If you decide not to fix this, please let me know because we'll need to add a formal test case to our regression suites to make sure we don't resurrect the issue when we upgrade our OpenLDAP clients. The msdn.microsoft.com website has the details of their proprietary function and SDK versions where it's required in case you want to use our approach. I included the URL so that you can get to it directly without going through MSDN's searching. My own opinion is finding a way to do without the %n is probably better and would result in fewer ifdefs in the code (always a plus in my book) and less Microsoft specific code lurking around to bite us later. We did pull down 2.3.39 and our tech that looked at the code tells me the %n's are still there and there's no _set_printf_count_output call so we think the problem still exists in the latest version. Give me a virtual slap if I've got this wrong. If you decide to fix this, I'm at your disposal and can provide some testing support since IA64 platforms are pretty rare. If you want to get in touch with me and my email address doesn't work (we're in a spin-off transition right now so our infrastructure isn't as stable as it should be), you can reach me by phone at 310-616-2384.

1 0

Re: (ITS#5323) dyngroup.c:dgroup_cf() bug
by hyc＠symas.com 10 Jan '08

10 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> To avoid that, start the code with something like >> ap = on->on_bi.bi_private; >> app = ≈ > > Duh.. ignore that one. > Probably should ignore all of this. dynlist totally supersedes dyngroup now. -- -- 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#5323) dyngroup.c:dgroup_cf() bug
by h.b.furuseth＠usit.uio.no 10 Jan '08

10 Jan '08

I wrote: > To avoid that, start the code with something like > ap = on->on_bi.bi_private; > app = ≈ Duh.. ignore that one. -- Hallvard

1 0

(ITS#5323) dyngroup.c:dgroup_cf() bug
by h.b.furuseth＠usit.uio.no 10 Jan '08

10 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard overlays/dyngroup.c:dgroup_cf() has some strange LDAP_MOD_DELETE code: app = (adpair **)&on->on_bi.bi_private; for (...; ...; ..., app = &ap->ap_next) { ap = *app; } *app = ap->ap_next; Last statement is a no-op, since *app == *(&ap->ap_next) == ap->ap_next. I'm not sure what it's intended to do. Also the first statement makes the void* object bi_private be accessed as an adpair* object. Breaks the 'strict aliasing' rules, so I guess it can miscompile. To avoid that, start the code with something like ap = on->on_bi.bi_private; app = ≈

1 0

Re: (ITS#5321) slapindex fails to create cn=config from configuration file
by hyc＠symas.com 10 Jan '08

10 Jan '08

joshua(a)itsecureadmin.com wrote: > Quanah Gibson-Mount wrote: >> --On Thursday, January 10, 2008 9:09 PM +0000 joshua(a)itsecureadmin.com >>> Full_Name: Joshua Miller >>> Version: 2.4.7 >>> OS: CentOS 5 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (198.134.96.10) >> What makes you think you should be using slapindex to do this? > > > The admin guide suggests that any slap* command should do this: > > http://www.openldap.org/doc/admin24/slapdconf2.html#cn=config > > > Also, the slapd-config man page: > > Alternatively, an existing slapd.conf file can be converted to > the new format using slapd or any of the slap tools: > slaptest -f /etc/openldap/slapd.conf -F ETCDIR/slapd.d The docs are incomplete. slapd or slaptest will always work; the other tools (slapadd/slapcat/slapindex) don't actually invoke the config database's startup routine unless you're explicitly operating on the config backend therefore the conversion won't occur in general. -- -- 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

(ITS#5322) slaptest exits on seg fault (SIGSEGV) if id2entry.bdb does not exist
by joshua＠itsecureadmin.com 10 Jan '08

10 Jan '08

Full_Name: Joshua Miller Version: 2.4.7 OS: CentOS 5 URL: http://ditree.com/work/gdb.ol2.4.7.out Submission from: (NULL) (198.134.96.10) When issuing slaptest prior to executing slapd to generate an id2entry.bdb file, slaptest/slapindex exits with a segmentation fault (SIGSEGV). Use case: user installs OpenLDAP, generates a configuration file, slapd.conf. User decides to generate cn=config prior to running slapd. User receives seg fault through running slaptest to perform this operation. Steps to reproduce: * install openldap 2.4.7, using berkley db 4.6 * create suitable slapd.conf * attempt to validate the configuration file using the following command: slaptest -f slapd.conf Expected results: Success Actual results: Segmentation Fault (SIGSEGV). Possibly useless gdb output located at: http://ditree.com/work/gdb.ol2.4.7.out

1 0

Re: (ITS#5321) slapindex fails to create cn=config from configuration file
by joshua＠itsecureadmin.com 10 Jan '08

10 Jan '08

Quanah Gibson-Mount wrote: > --On Thursday, January 10, 2008 9:09 PM +0000 joshua(a)itsecureadmin.com >> Full_Name: Joshua Miller >> Version: 2.4.7 >> OS: CentOS 5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (198.134.96.10) > > What makes you think you should be using slapindex to do this? The admin guide suggests that any slap* command should do this: http://www.openldap.org/doc/admin24/slapdconf2.html#cn=config Also, the slapd-config man page: Alternatively, an existing slapd.conf file can be converted to the new format using slapd or any of the slap tools: slaptest -f /etc/openldap/slapd.conf -F ETCDIR/slapd.d Thanks, -- Joshua M. Miller - RHCE,VCP

1 0

Re: (ITS#5321) slapindex fails to create cn=config from configuration file
by quanah＠zimbra.com 10 Jan '08

10 Jan '08

--On Thursday, January 10, 2008 9:09 PM +0000 joshua(a)itsecureadmin.com wrote: > Full_Name: Joshua Miller > Version: 2.4.7 > OS: CentOS 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.134.96.10) > > > OL Version 2.4.7 > Berkely DB 4.6 > OS CentOS 5 > > Command: slapindex What makes you think you should be using slapindex to do this? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5321) slapindex fails to create cn=config from configuration file
by joshua＠itsecureadmin.com 10 Jan '08

10 Jan '08

Full_Name: Joshua Miller Version: 2.4.7 OS: CentOS 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.134.96.10) OL Version 2.4.7 Berkely DB 4.6 OS CentOS 5 Command: slapindex ISSUE: When attempting to generate cn=config from a configuration file using slapindex, no cn=config is generated: # cd /etc/openldap # mkdir slapd.d # /usr/sbin/slapindex -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d # echo $? 0 Program exits without error. # ls /etc/openldap/slapd.d Subsequently, running this command immediately after generates the appropriate cn=config: # slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d config file testing succeeded # ll slapd.d total 8 drwxr-x--- 4 root root 4096 Jan 10 13:07 cn=config -rw------- 1 root root 1097 Jan 10 13:07 cn=config.ldif #

1 0

Re: (ITS#5320) bug on the filter functionnality =*
by quanah＠zimbra.com 10 Jan '08

10 Jan '08

--On Thursday, January 10, 2008 3:31 PM +0000 jpgressard(a)hotmail.com wrote: > I tested the same query on the version 2.4.6 and it was working. > Furthermore, if I amend the query to (&(sn=XXX*)(givenName=D*)), or > (sn=XXX*) I find the entry. As noted when 2.4.7 was released, you want to regenerate your indices. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5320) bug on the filter functionnality =*
by h.b.furuseth＠usit.uio.no 10 Jan '08

10 Jan '08

jpgressard(a)hotmail.com writes: > The query (&(sn=XXXXXX*)(givenName=*))can not find the entry below. Does it help to stop slapd, run sbin/slapindex, and restart slapd? You need to do that if you edit slapd.conf's index statements, and possibly when you upgrade. -- Hallvard

1 0

(ITS#5320) bug on the filter functionnality =*
by jpgressard＠hotmail.com 10 Jan '08

10 Jan '08

Full_Name: Jean-Paul Gressard Version: 2.4.7 OS: Madrake distribution (v10) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (158.232.2.8) The query (&(sn=XXXXXX*)(givenName=*))can not find the entry below. dn: uid=XXXXXXDDDDD14977,l=Geneva,c=CH,o=who,o=directoryroot sn: XXXXXX objectClass: inetOrgPerson uid: XXXXXXDDDDD14977 telephoneNumber: 14977 o: who givenName: DDDDD cn: XXXXXX, DDDDD I tested the same query on the version 2.4.6 and it was working. Furthermore, if I amend the query to (&(sn=XXX*)(givenName=D*)), or (sn=XXX*) I find the entry.

1 0

Re: (ITS#5316) authzTo unevaluated in 2.4.7
by hyc＠symas.com 10 Jan '08

10 Jan '08

m.erde(a)gmx.net wrote: > First, I actually meant of course "authzid" in ITS > > After some tests, I found out that the filter expression in authzTo- > Attribute of the authentication entity caused the Problems: While > > authzTo: ldap:///ou=users,ou=accounts,dc=dom??one?(uid=*) > > does not work (with uid as rdn), > > authzTo: ldap:///ou=users,ou=accounts,dc=dom??one?(objectClass=*) > > does. Regenerate your presence index on uid. http://www.openldap.org/lists/openldap-software/200712/msg00193.html This ITS will be closed. -- -- 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

(ITS#5319) Rename on same DN failes
by abartlet＠samba.org 09 Jan '08

09 Jan '08

Full_Name: Andrew Bartlett Version: HEAD CVS OS: Fedora 8 URL: Submission from: (NULL) (59.167.251.137) Renaming a DN to itself, whether or not changing case, fails. This should succeed, preferably for all cases, so that it is possible to change the case of an RDN. This would also assist Samba4, as AD supports these renames, and I am working on a mapping layer from OpenLDAP to Samba4. Howard Chu notes on the openldap-technical list that logic to allow this existed in the past, but appears to have been lost.

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by hyc＠symas.com 09 Jan '08

09 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > Howard Chu writes: >>> If anything, the LDIF RFC could be revised instead. This format has >>> been supported since umich ldap (before the LDIF RFC was written). >> That doesn't mean it has any relevance today; there's plenty of stuff >> UMich did that was long since deprecated. > > True, but this was not deprecated that I know of. It is now. ;) The outcome of the original discussion, which Kurt again reminded me of today, was that ldapmodify should quit its guessing games and just accept valid LDIF input. The description of the exceptions in the manpage seemed imply they were there to accommodate slurpd users, who needed a mechanism for applying failed updates to a target server. Now that all slurpd/replog support has been dropped, there really is no more justification for these exceptions. > Snipping a bit from the -devel thread: > Howard Chu wrote: >> (Did I mention that I've always thought the mod-spec definition was >> garbage? The format I use for the logschema has none of these problems >> or inefficiences...) > > As far as I can tell Logschema doesn't support full LDIF modify though. > reqMod is unordered, so one cannot make two modifications to the same > attribute. E.g. "delete: foo" followed by "replace: foo". I suppose reqMod should be made ordered. My point about logschema is that reqMod's syntax doesn't require separators/terminators or as many redundant attribute references. attr:- foo attr:+ bar is a far more efficient representation than delete: attr attr: foo - add: attr attr: bar - The logschema format is also easily grep-able without resorting to grep windowing and other such hassles. > Maybe it's time to take this to the ldapext list and hear what others > do. This is really getting off topic, unless you're suggesting that we spec this for a new version of LDIF. -- -- 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#5316) authzTo unevaluated in 2.4.7
by m.erde＠gmx.net 09 Jan '08

09 Jan '08

First, I actually meant of course "authzid" in ITS After some tests, I found out that the filter expression in authzTo- Attribute of the authentication entity caused the Problems: While authzTo: ldap:///ou=users,ou=accounts,dc=dom??one?(uid=*) does not work (with uid as rdn), authzTo: ldap:///ou=users,ou=accounts,dc=dom??one?(objectClass=*) does. -Mat

1 0

(ITS#5318) response msgid <= 0 mishandled in libldap
by h.b.furuseth＠usit.uio.no 09 Jan '08

09 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard libraries/libldap/result.c:try_read1msg() accesses 'lr' uninitialized if 'id' (message ID) from line 577's 'ber_get_int( ber, &id )' is <= 0. I'm not sure if the client should terminate the connection when it receives message id < 0, or if it should just toss the response like it does with unknown message IDs. With message ID 0, the code reaches this statement with 'lr' uninitialized: Debug( LDAP_DEBUG_TRACE, "read1msg: ld %p msgid %ld message type %s\n", (void *)ld, (long)lr->lr_msgid, ldap_int_msgtype2str( tag ) ); As far as I can tell, normally lr->lr_msgid == id. I haven't tracked what those values are with LDAP_CONNECTIONLESS at the 'nextresp2:' label. A 700-line function with 5 labels, yuck. Anyway, I wonder why taht statement and the statement below: if ( id == 0 ) { doesn't use the same value, either id or lr->lr_msgid for both.

1 0

(ITS#5317) bad result for ldapsearch -f
by h.b.furuseth＠usit.uio.no 09 Jan '08

09 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldapsearch rev 1.241 "allow continuous mode" introduced one bug and one probably-byg: * ldapsearch -f/dev/null returns an uninitialized value 'rc'. Fixing. * last instead of "worst" search return value is returned with continuous mode. I.e error followed by success returns success. I assume it should return failure like ldapmodify (see the code which saves rc in 'ret')?

1 0

(ITS#5316) authzTo unevaluated in 2.4.7
by m.erde＠gmx.net 09 Jan '08

09 Jan '08

Full_Name: Matthias Erde Version: 2.4.7 OS: FreeBSD 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.176.162.227) Hello, after upgrading to 2.4.7 (from 2.4.6) I cannot longer authzTo neither authcid in sasl binds nor proxyauth (e.g. as used by Howard's ldapdb contributed to cyrsu-sasl) were working. -Mat

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by h.b.furuseth＠usit.uio.no 09 Jan '08

09 Jan '08

Thinking a bit more... I wrote: > But I agree those attribute names make things icky. Attributes named "add"/"delete"/"replace" are not the only problem cases. A program which generates LDIF must also take care with attributes named "control" and "changetype". And with OpenLDAP, "increment". Which may be a worse problem since it's not mentioned in the LDIF spec. Still, the new ldapmodify seems to me to add very little value to the ldapadd program. It is ldapadd which accepts LDIF format. ldapmodify does not. Yet the only difference now seems to be that one can omit the "changetype:" line, one must still use the more verbose "add/..." and "_" lines. Another possible approach: Strict LDIF format, a record's attributes shall use "add/replace/...: attribute" if and only if the record has a "changetype:" line. Without them, ldapadd does changetype:add + add:attrs, ldapmodify does changetype:modify + replace:attrs. -- Hallvard

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by h.b.furuseth＠usit.uio.no 09 Jan '08

09 Jan '08

Howard Chu writes: >Hallvard B Furuseth wrote: >> Changing the -devel thread's example a bit, I'd say 2.3 accepted one >> dangerous bug, one unambigious but possibly misleading format (a modify >> record both with and witout "add/delete/replace: attribute" lines), and >> one safe format (changetype: modify but no add/delete/replace"): > > No. If you (foolishly or unluckily) have attributes in your schema named > "add", "delete", or "replace" then in <=2.3 you are completely hosed. There > are no unambiguous or safe cases in these malformed inputs. Well, you'd have to use "add/delete/replace:". ldapmodify only noticed those keywords after "-", "dn:" and "changetype:" lines.to omit it. to omit it. But I agree those attribute names make things icky. And they still do, because "changetype:" is optional. This LDIF: dn: dc=example,dc=com add: foo foo: bar affects attr "foo" with ldapmodify, but "add" and "foo" with ldapadd. The current change seems to me to require either too little or too much RFC 2849 conformance in ldapmodify. (Require the final "-" and it gets stricter.) >> OTOH it would be an LDIF-compatible extension to make the attribute >> description in "attribute: value" optional after "add/replace/delete: >> attribute". Then one could omit the terminating "-" too. > > Likewise, this is unsafe. Why so? Treat a ": value" line followed by a "whatever:" line as if there was a "-" line between. "delete/replace: attr" not followed by attribute value lines might need a "-" after it though. -- Hallvard

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by hyc＠symas.com 09 Jan '08

09 Jan '08

Hallvard B Furuseth wrote: > Changing the -devel thread's example a bit, I'd say 2.3 accepted one > dangerous bug, one unambigious but possibly misleading format (a modify > record both with and witout "add/delete/replace: attribute" lines), and > one safe format (changetype: modify but no add/delete/replace"): No. If you (foolishly or unluckily) have attributes in your schema named "add", "delete", or "replace" then in <=2.3 you are completely hosed. There are no unambiguous or safe cases in these malformed inputs. > OTOH it would be an LDIF-compatible extension to make the attribute > description in "attribute: value" optional after "add/replace/delete: > attribute". Then one could omit the terminating "-" too. Likewise, this is unsafe. > Maybe it's time to take this to the ldapext list and hear what others > do. -- -- 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#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by h.b.furuseth＠usit.uio.no 09 Jan '08

09 Jan '08

I wrote: > As far as I can tell Logschema doesn't support full LDIF modify though. > reqMod is unordered, so one cannot make two modifications to the same > attribute. E.g. "delete: foo" followed by "replace: foo". Sorry, followed by "add: foo" makes more sense. E.g. delete sn: chu add sn: Chu -- Hallvard

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by h.b.furuseth＠usit.uio.no 09 Jan '08

09 Jan '08

Howard Chu writes: > Hm... Where were you when we were originally discussing these changes? > http://www.openldap.org/lists/openldap-devel/200611/msg00013.html > http://www.openldap.org/lists/openldap-devel/200611/msg00022.html Absent. I did look at it though, but I didn't realize how far the changes went. See below. > HEAD has been working this way for over a year, and it's clearly more > correct in its behavior now than it was before. True, the old way was quite broken as that thread shows. >> If anything, the LDIF RFC could be revised instead. This format has >> been supported since umich ldap (before the LDIF RFC was written). > > That doesn't mean it has any relevance today; there's plenty of stuff > UMich did that was long since deprecated. True, but this was not deprecated that I know of. So: > It may be OK to revert this single aspect of the change. If you do so, > just make sure that those other corner cases mentioned in the -devel > thread are still handled correctly. Changing the -devel thread's example a bit, I'd say 2.3 accepted one dangerous bug, one unambigious but possibly misleading format (a modify record both with and witout "add/delete/replace: attribute" lines), and one safe format (changetype: modify but no add/delete/replace"): dn: dc=example,dc=com changetype: modify add: cn cn: foo # bug: implicit "add: sn". Since the "-" was optional, one might even # expect the new attribute type to revert to the default "replace:". sn: bar - # Safe after the "-" but possibly confusing - implicit "replace: # description" and "replace: telephoneNumber" description: xyzzy telephoneNumber: 12345678 # OK: implicit "replace:" for everything dn: dc=example,dc=com changetype: modify cn: foo sn: bar description: xyzzy telephoneNumber: 12345678 Snipping a bit from the -devel thread: Howard Chu wrote: > (Did I mention that I've always thought the mod-spec definition was > garbage? The format I use for the logschema has none of these problems > or inefficiences...) As far as I can tell Logschema doesn't support full LDIF modify though. reqMod is unordered, so one cannot make two modifications to the same attribute. E.g. "delete: foo" followed by "replace: foo". OTOH it would be an LDIF-compatible extension to make the attribute description in "attribute: value" optional after "add/replace/delete: attribute". Then one could omit the terminating "-" too. Maybe it's time to take this to the ldapext list and hear what others do. -- Hallvard

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs