openldap-bugs January 2008

openldap-bugs@openldap.org

36 participants
144 discussions

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

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: > hyc(a)symas.com writes: >> daveh(a)coreng.com.au wrote: >>> As a followup, I should point out that this behaviour worked in at least >>> 2.2 and 2.3. >> Yes, I recall changing this in the 2.4 code; I guess I didn't update >> the manpage. > > Not sure which of this discussion should go where - I saw it first in > the ldap@umich list. But anyway, I suggest to revert that change. 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 HEAD has been working this way for over a year, and it's clearly more correct in its behavior now than it was before. > 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. > Note that the format which OpenLDAP-2.4 ldapmodify reads is still not > LDIF, since "changetype:" defaults to modify instead of add. That's > incompatible with LDIF. OTOH default operation "replace:" for > changetype "modify" was compatible with LDIF, since LDIF does not > support a missing "add/delete/replace:" for changetype modify. > > Some history: > > - umich ldap-3.3 (1996): There were two LDIF defaults: Whether a missing > "changetype:" would default to "add" or "modify", and whether a > missing attribute operation type would default to "add" or "replace". > These were controlled by different flags: -a (or invoking as ldapadd) > for the first, -r (replace) for the second. > > - RFC 2849 - LDIF (2000): The defaults "changetype:modify" and > "replace:" were dropped, presumably because a file format could not > support command line options. > > - OpenLDAP 2.1 (2002): Removed the -r option and instead made it the > default when changetype was modify (and thus for ldapmodify). -r was > only used with ldapmodify and was usually what one wanted there. > (Note that "replace:" is equivalent to "add:" if the attribute does > not already exist in the entry.) 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. -- -- 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#5315) Crash in ldap_parse_page_control
by rhafer＠suse.de 09 Jan '08

09 Jan '08

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.8.71.175) Applications using ldap_parse_page_control (e.g. nss_ldap) might crash. valgrind reports this: ==21971== Invalid write of size 8 ==21971== at 0x5BDFF04: ldap_parse_page_control (pagectrl.c:263) ==21971== by 0x599F170: do_result (ldap-nss.c:2511) ==21971== by 0x599F289: do_parse (ldap-nss.c:2844) ==21971== by 0x59A0245: _nss_ldap_getent_ex (ldap-nss.c:3413) [..] ==21971== Address 0x51fad38 is 0 bytes after a block of size 8 alloc'd ==21971== at 0x4C2460E: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==21971== by 0x5E0652C: ber_memalloc_x (memory.c:226) ==21971== by 0x5BDFEEB: ldap_parse_page_control (pagectrl.c:259) ==21971== by 0x599F170: do_result (ldap-nss.c:2511) ==21971== by 0x599F289: do_parse (ldap-nss.c:2844) ==21971== by 0x59A0245: _nss_ldap_getent_ex (ldap-nss.c:3413) [..] Fix is on the way to HEAD.

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

hyc(a)symas.com writes: >daveh(a)coreng.com.au wrote: >> As a followup, I should point out that this behaviour worked in at least >> 2.2 and 2.3. > > Yes, I recall changing this in the 2.4 code; I guess I didn't update > the manpage. Not sure which of this discussion should go where - I saw it first in the ldap@umich list. But anyway, I suggest to revert that change. If anything, the LDIF RFC could be revised instead. This format has been supported since umich ldap (before the LDIF RFC was written). Note that the format which OpenLDAP-2.4 ldapmodify reads is still not LDIF, since "changetype:" defaults to modify instead of add. That's incompatible with LDIF. OTOH default operation "replace:" for changetype "modify" was compatible with LDIF, since LDIF does not support a missing "add/delete/replace:" for changetype modify. Some history: - umich ldap-3.3 (1996): There were two LDIF defaults: Whether a missing "changetype:" would default to "add" or "modify", and whether a missing attribute operation type would default to "add" or "replace". These were controlled by different flags: -a (or invoking as ldapadd) for the first, -r (replace) for the second. - RFC 2849 - LDIF (2000): The defaults "changetype:modify" and "replace:" were dropped, presumably because a file format could not support command line options. - OpenLDAP 2.1 (2002): Removed the -r option and instead made it the default when changetype was modify (and thus for ldapmodify). -r was only used with ldapmodify and was usually what one wanted there. (Note that "replace:" is equivalent to "add:" if the attribute does not already exist in the entry.) -- Regards, Hallvard

1 0

Re: (ITS#5313) Referral error
by ando＠sys-net.it 08 Jan '08

08 Jan '08

> Thank you so much. > > slapd or ldapadd should report a warning.. and not inform success: > "adding new entry "ou=domain1,o=Museu Goeldi"" No. What you added is a perfectly legitimate labeledURI, although not what you intended, where the URI is "ldap://<ip>/ou=domain1,o=Museu" and the label is "Goeldi"; there is no way (except a crystal ball) slapd can guess your intentions in this case. 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#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by daveh＠coreng.com.au 08 Jan '08

08 Jan '08

On Tue, 8 Jan 2008, Howard Chu wrote: > Yes, I recall changing this in the 2.4 code; I guess I didn't update the > manpage. So it's officially dead? No worries; I've just finished converting the last of our legacy scripts. (I can see where you changed it in the source; should've checked that first...) -- Dave Horsfall DTM VK2KFU Ph: +61 2 9552-5509 (direct) +61 2 9552-5500 (switch) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

1 0

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

08 Jan '08

daveh(a)coreng.com.au wrote: > As a followup, I should point out that this behaviour worked in at least > 2.2 and 2.3. Yes, I recall changing this in the 2.4 code; I guess I didn't update the manpage. -- -- 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 daveh＠coreng.com.au 08 Jan '08

08 Jan '08

As a followup, I should point out that this behaviour worked in at least 2.2 and 2.3.

1 0

Re: (ITS#5310) ppolicy
by mhardin＠symas.com 08 Jan '08

08 Jan '08

Hi Kevin, The ITS system is for reporting defects in OpenLDAP, and the symptoms you are describing are not indicative of that. The OpenLDAP team will probably close this ITS with a comment to that effect. The 'passwd' command is an OS tool, not part of OpenLDAP. Its interaction with OpenLDAP is through the pam_ldap module, and the conifguration of that module is most likely where your problem lies. I suggest posting this question on the pam_ldap mailing list that is operated by PADL, or requesting support from your OS vendor (RedHat?). Cheers, -Matt -- Matthew Hardin Symas Corporation - The LDAP Guys http://www.symas.com khxie(a)directv.com wrote: > Full_Name: Kevin Xie > Version: 2.3.39 > OS: RHEL 4 update 3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (147.21.16.3) > > > I am testing ppolicy on OpenLDAP 2.3.39 and 2.3.38. > When user password expired, LDAP forced user to change password using "passwd", > it bypassed all the ppolicy settings, like, PwdMinLength, PwdInHistory. > Is there a way to force "passwd" to check LDAP ppolicy like "ldappasswd" does? > Is it because "passwd" and "ldappasswd" using different encryption methods? > > I've uploaded ppolicy and slapd.conf in khxie_ppolicy.txt. > I've google searched the issue and didn't find any anwser. > > Thanks for your help. > > Kevin Xie > > > . > >

1 0

(ITS#5314) slapd crashed in syncrepl and mirror mode when deleting entry
by savithri＠yahoo.com 08 Jan '08

08 Jan '08

Full_Name: Savithri Version: OpenLDAP 2.4.7 OS: SunOS 5.9 Generic_118558-08 sun4u sparc SUNW,Sun-Fire-V210 URL: ftp://ftp.openldap.org/incoming/savithri-pkg-080108.tar.gz Submission from: (NULL) (12.111.90.130) Hi, Im using fresh install of OpenLDAP 2.4.7 and using the mirrormode and syncrepl. My setup has 2 LDAP nodes, one as master and other as slave through a VIP. When the master goes down, the slave will become master and vice-versa. At any point to keep both the LDAP in sync I'm using mirror mode and syncrepl. When one node , say A is up (that is the active node) and the other node B is down, I delete some LDAP entry from node A. Then when i start node B, the slapd on node B crashes and a core file is generated. I have zipped the following files: 1. slapd.conf/s from both nodes (slapd.conf.node_A and slapd.conf.node_B ) 2. sample data ( sample_data.ldif ) 3. compile, run options ( build_run_option.txt) 4. the core file ( core) 5. log files from both the nodes A and B ( node_A_ldap.out and node_B_ldap.out) and have ftp the file "savithri-pkg-080108.tar.gz" to ftp://ftp.openldap.org/incoming/

1 0

← Newer
1
...
8
9
10
11
12
13
14
15
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 January 2008