- openldap-bugs - openldap.org

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 10 Jan '08

10 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 10 Jan '08

10 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

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 09 Jan '08

09 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 09 Jan '08

09 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 09 Jan '08

09 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 09 Jan '08

09 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 09 Jan '08

09 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 09 Jan '08

09 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

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

09 Jan '08

reinaldoc(a)gmail.com wrote: > Full_Name: Reinaldo de Carvalho > Version: 2.3.30 > OS: Debian DNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (201.72.201.200) > > > #cat ref.ldif > dn: ou=domain1,o=Museu Goeldi > objectClass: referral > objectClass: extensibleObject > ref: ldap://10.0.0.2/ou=domain1,o=Museu Goeldi > ou: domain1 > > # ldapadd -x -D "cn=admin,o=Museu Goeldi" -w xxxxx -f ref.ldif > adding new entry "ou=domain1,o=Museu Goeldi" > > # ldapsearch -x -b "o=Museu Goeldi" -LLL 'ref=*' > # refldap://10.0.0.2/ou=domain1,o=Museu??sub > > OpenLdap return erroneous referral ou=domain1,o=Museu??sub Please read the specifications of the "ref" attribute. Its value is treated as an LDAP URI, optionally followed by a label; an LDAP URI, like all URIs, does not allow spaces, which must be escaped using "%20". Please fix your data. This ITS will be closed. 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

(ITS#5313) Referral error
by reinaldoc＠gmail.com 08 Jan '08

08 Jan '08

Full_Name: Reinaldo de Carvalho Version: 2.3.30 OS: Debian DNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (201.72.201.200) #cat ref.ldif dn: ou=domain1,o=Museu Goeldi objectClass: referral objectClass: extensibleObject ref: ldap://10.0.0.2/ou=domain1,o=Museu Goeldi ou: domain1 # ldapadd -x -D "cn=admin,o=Museu Goeldi" -w xxxxx -f ref.ldif adding new entry "ou=domain1,o=Museu Goeldi" # ldapsearch -x -b "o=Museu Goeldi" -LLL 'ref=*' # refldap://10.0.0.2/ou=domain1,o=Museu??sub OpenLdap return erroneous referral ou=domain1,o=Museu??sub

1 0

Re: (ITS#5311) Custom client searching cn=Monitor crashes SLAPD
by ando＠sys-net.it 08 Jan '08

08 Jan '08

Howard Chu wrote: > ando(a)sys-net.it wrote: >> I couldn't reproduce with a test (mostly unloaded) slapd. Since >> back-monitor dynamically builds the results based on the activity of >> slapd, the root cause could be related to the type of activity your >> slapd is doing (e.g. active connections, running operations and so). >> >> I don't have a FreeBSD at hand right now, could you post a "thread apply >> all bt" from gdb? I might need to ask for further core inspection >> with gdb. > > The tarball he posted has more information. You can see from the debug > output that the first search succeeds and the second fails. It's failing > while preparing the cn=Tasklist entry for output. In the first search, > it shows that the BDB checkpoint task is running. Very likely it's not > running in the second search, and the cn=Tasklist entry has been > corrupted in the subsequent update. However I haven't gotten far enough > to see how any corruption could happen or reproduce it. If you can pick > it up from these clues, I'll get back to other work... OK, thanks. I'll look at it. 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#5311) Custom client searching cn=Monitor crashes SLAPD
by daveh＠coreng.com.au 08 Jan '08

08 Jan '08

On Tue, 8 Jan 2008, Pierangelo Masarati wrote: > I couldn't reproduce with a test (mostly unloaded) slapd. Since > back-monitor dynamically builds the results based on the activity of > slapd, the root cause could be related to the type of activity your > slapd is doing (e.g. active connections, running operations and so). Howard and I are already looking at this; sorry for not keeping you in the loop... -- 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#5311) Custom client searching cn=Monitor crashes SLAPD
by hyc＠symas.com 08 Jan '08

08 Jan '08

ando(a)sys-net.it wrote: > I couldn't reproduce with a test (mostly unloaded) slapd. Since > back-monitor dynamically builds the results based on the activity of > slapd, the root cause could be related to the type of activity your > slapd is doing (e.g. active connections, running operations and so). > > I don't have a FreeBSD at hand right now, could you post a "thread apply > all bt" from gdb? I might need to ask for further core inspection with gdb. The tarball he posted has more information. You can see from the debug output that the first search succeeds and the second fails. It's failing while preparing the cn=Tasklist entry for output. In the first search, it shows that the BDB checkpoint task is running. Very likely it's not running in the second search, and the cn=Tasklist entry has been corrupted in the subsequent update. However I haven't gotten far enough to see how any corruption could happen or reproduce it. If you can pick it up from these clues, I'll get back to other work... -- -- 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#5311) Custom client searching cn=Monitor crashes SLAPD
by ando＠sys-net.it 08 Jan '08

08 Jan '08

daveh(a)coreng.com.au wrote: > Full_Name: Dave Horsfall > Version: 2.4.7 + ITS #5291 patch > OS: FreeBSD 6.2 > URL: http://www.horsfall.org/slapd-crash/ > Submission from: (NULL) (192.65.182.30) > > > We have a custom client called LGET (which is not much more than a fancy output > formatter based on the example code kicking around somewhere; I can provide the > source, but there's no way that it will compile anywhere but here) that reliably > crashes SLAPD when doing a search on "cn=Monitor". > > Example: > > lget -h localhost -b cn=monitor '(objectClass=*)' '*' > (May need to do this several times; it will crash eventually) > lget: Can't contact LDAP server > > slapd.log: > > Jan 8 10:37:33 mippet slapd[59883]: conn=14 fd=66 ACCEPT from > IP=127.0.0.1:52984 (IP=0.0.0.0:389) > Jan 8 10:37:33 mippet slapd[59883]: conn=14 op=0 SRCH base="cn=monitor" scope=2 > deref=0 filter="(objectClass=*)" > Jan 8 10:37:33 mippet slapd[59883]: conn=14 op=0 SRCH attr=* + Looking at the logs, it appears that it's also requesting '+'. > > This is sometimes followed by e.g.: > > Jan 8 10:39:29 mippet slapd[83101]: ch_malloc of 1195801456 bytes failed > > Although the debug shows traffic on the wire the client only shows a few blank > lines (but that's not really relevant). > > Debug output in "debug.out.gz", and GDB output in "gdb.out". I couldn't reproduce with a test (mostly unloaded) slapd. Since back-monitor dynamically builds the results based on the activity of slapd, the root cause could be related to the type of activity your slapd is doing (e.g. active connections, running operations and so). I don't have a FreeBSD at hand right now, could you post a "thread apply all bt" from gdb? I might need to ask for further core inspection with gdb. 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

(ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by daveh＠coreng.com.au 08 Jan '08

08 Jan '08

Full_Name: Dave Horsfall Version: 2.4.7 + ITS #5291 patch OS: FreeBSD 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.65.182.30) The man page for ldapmodify(1) says that: If no "changetype:" line is present, the default is "add" if the -a flag is set (or if the program was invoked as ldapadd) and "modify" otherwise. If changetype is "modify" and no "add:", "replace:", or "delete:" lines appear, the default is "replace" for ldapmodify(1) and "add" for lda- padd(1). This appears to be incorrect in practice: LDIF: dn: cn=uidpool,dc=coreng,dc=com,dc=au objectClass: ciUID objectClass: top cn: uidpool ciNextUID: 12020 ciLastUID: 12999 Command (abridged): ldapmodify -x -W -H "ldap://ldap.exanple.com" -f LDIF Enter LDAP Password: ldapmodify: modify operation type is missing at line 2, entry "cn=uidpool,dc=example,dc=com"

1 0

(ITS#5311) Custom client searching cn=Monitor crashes SLAPD
by daveh＠coreng.com.au 08 Jan '08

08 Jan '08

Full_Name: Dave Horsfall Version: 2.4.7 + ITS #5291 patch OS: FreeBSD 6.2 URL: http://www.horsfall.org/slapd-crash/ Submission from: (NULL) (192.65.182.30) We have a custom client called LGET (which is not much more than a fancy output formatter based on the example code kicking around somewhere; I can provide the source, but there's no way that it will compile anywhere but here) that reliably crashes SLAPD when doing a search on "cn=Monitor". Example: lget -h localhost -b cn=monitor '(objectClass=*)' '*' (May need to do this several times; it will crash eventually) lget: Can't contact LDAP server slapd.log: Jan 8 10:37:33 mippet slapd[59883]: conn=14 fd=66 ACCEPT from IP=127.0.0.1:52984 (IP=0.0.0.0:389) Jan 8 10:37:33 mippet slapd[59883]: conn=14 op=0 SRCH base="cn=monitor" scope=2 deref=0 filter="(objectClass=*)" Jan 8 10:37:33 mippet slapd[59883]: conn=14 op=0 SRCH attr=* + This is sometimes followed by e.g.: Jan 8 10:39:29 mippet slapd[83101]: ch_malloc of 1195801456 bytes failed Although the debug shows traffic on the wire the client only shows a few blank lines (but that's not really relevant). Debug output in "debug.out.gz", and GDB output in "gdb.out".

1 0

Re: (ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by ando＠sys-net.it 07 Jan '08

07 Jan '08

Hallvard B Furuseth wrote: > I wrote: >> I think setkey() is more readable than setkey_x(). If anything, >> it already has too many arguments to be very readable. > > Er, I meant the old setkey(), with fewer arguments:-) Oh well, > it doesn't matter greatly either way. Unless - do we care about > binary compatibility with 2.4.7 libldap_r? I don't think so. It's not meant to be publicly linked. 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#5309) ldap_pvt_thread_pool_setkey_x() addition
by h.b.furuseth＠usit.uio.no 07 Jan '08

07 Jan '08

I wrote: > I think setkey() is more readable than setkey_x(). If anything, > it already has too many arguments to be very readable. Er, I meant the old setkey(), with fewer arguments:-) Oh well, it doesn't matter greatly either way. Unless - do we care about binary compatibility with 2.4.7 libldap_r? -- Hallvard

1 0

(ITS#5310) ppolicy
by khxie＠directv.com 07 Jan '08

07 Jan '08

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

Re: (ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by h.b.furuseth＠usit.uio.no 07 Jan '08

07 Jan '08

Pierangelo Masarati writes: > Would it make any sense, at this point, to simply change the API of > setkey(), eliminating that spurious setkey_x()? I think setkey() is more readable than setkey_x(). If anything, it already has too many arguments to be very readable. -- Regards, Hallvard

1 0

Re: (ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by ando＠sys-net.it 07 Jan '08

07 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > HEAD has gotten a new function ldap_pvt_thread_pool_setkey_x() replacing > ldap_pvt_thread_pool_setkey() (now a macro), but the change is incomplete. > Fixing thr_stub & thr_debug, they still define ldap_pvt_thread_pool_setkey. > > Related: overlays/memberof.c, pool_<getkey and setkey_x> should receive > a pointer to a void variable, not a (void **) cast of the address of a > non-void pointer variable. Otherwise a void* pointer gets stored in a > non-void* pointer instead of being converted to void. > > I'll combine another of memberof's getkey() followed by setkey() into > setkey_x() while I'm at it. > > Also making passwd.c:slap_passwd_check() and backend.c:be_rootdn_bind() > reentrant: Use setkey_x()/setkey() to push/pop the key=slap_sasl_bind > value instead of setkey()/setkey() to set/reset it. Would it make any sense, at this point, to simply change the API of setkey(), eliminating that spurious setkey_x()? 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

(ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by h.b.furuseth＠usit.uio.no 07 Jan '08

07 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard HEAD has gotten a new function ldap_pvt_thread_pool_setkey_x() replacing ldap_pvt_thread_pool_setkey() (now a macro), but the change is incomplete. Fixing thr_stub & thr_debug, they still define ldap_pvt_thread_pool_setkey. Related: overlays/memberof.c, pool_<getkey and setkey_x> should receive a pointer to a void variable, not a (void **) cast of the address of a non-void pointer variable. Otherwise a void* pointer gets stored in a non-void* pointer instead of being converted to void. I'll combine another of memberof's getkey() followed by setkey() into setkey_x() while I'm at it. Also making passwd.c:slap_passwd_check() and backend.c:be_rootdn_bind() reentrant: Use setkey_x()/setkey() to push/pop the key=slap_sasl_bind value instead of setkey()/setkey() to set/reset it.

1 0

(ITS#5308) test034-translucent crashes with back-ldif
by h.b.furuseth＠usit.uio.no 07 Jan '08

07 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard "./run -b ldif test034-translucent" crashes in str2entry2() at: entry.c:298: if( ad_prev->ad_type->sat_equality && because ad_prev == NULL - which got through due to this statement: entry.c:278: if (( ad_prev && ad != ad_prev ) || ( i == lines )) { (gdb) backtrace full #0 0x080778b9 in str2entry2 (s=0x0, checkvals=1) at entry.c:298 j = 0 k = 0 rc = 0 e = (Entry *) 0x1bca12d4 type = (struct berval *) 0x1bc4af40 vals = (struct berval *) 0x1bc4af50 nvals = (struct berval *) 0x1bc4af60 freeval = 0x1bc4af70 "" ad = (AttributeDescription *) 0x1bc4b100 ad_prev = (AttributeDescription *) 0x0 text = 0x819642b "attribute type undefined" next = 0x1bc4af0d "" attr_cnt = 0 i = 0 lines = 0 ahead = {a_desc = 0x0, a_vals = 0x0, a_nvals = 0x8189305, a_numvals = 465874688, a_flags = 477302072, a_next = 0x1bcabc2c, a_comp_data = 0x0} atail = (Attribute *) 0x1bcabc2c #1 0x08076c28 in str2entry (s=0x1bc4af00 "dn") at entry.c:100 No locals. #2 0x0810084a in get_entry_for_fd (fd=12, pdn=0x1c730de4, pndn=0x1c730ddc) at ldif.c:339 entry = 0x1bc4af00 "dn" ldentry = (Entry *) 0x0 #3 0x08100a99 in get_entry (op=0x1bb0bc30, base_path=0x1bc315b0) at ldif.c:379 path = {bv_len = 100, bv_val = 0x1bc4adc8 "/usit/bombur/site/hbf/scratch/ldap/ol/HEAD/tests/testrun/db.2.a/o=translucent/ou=users/uid=fred.ldif"} pdn = {bv_len = 22, bv_val = 0x1bd2c185 "ou=users,o=translucent"} pndn = {bv_len = 22, bv_val = 0x1bd2c1e5 "ou=users,o=translucent"} fd = 12 #4 0x081018f1 in ldif_back_referrals (op=0x1bb0bc30, rs=0x1c731138) at ldif.c:719 li = (struct ldif_info *) 0x1bc315b0 entry = (Entry *) 0x1c730fc8 rc = 0 #5 0x080e1c31 in overlay_op_walk (op=0x1bb0bc30, rs=0x1c731138, which=op_aux_chk_referrals, oi=0x1bc31e80, on=0x0) at backover.c:653 func = (BI_op_bind **) 0x81dc15c rc = 32768 #6 0x080e1de6 in over_op_func (op=0x1bb0bc30, rs=0x1c731138, which=op_aux_chk_referrals) at backover.c:705 oi = (slap_overinfo *) 0x1bc31e80 on = (slap_overinst *) 0x1bc31fb0 be = (BackendDB *) 0x1bc31470 db = {bd_info = 0x81dc130, be_ctrls = '\0' <repeats 18 times>, "\001", '\0' <repeats 13 times>, "\001", be_flags = 259, be_restrictops = 0, be_requires = 0, be_ssf_set = { sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x1bc31a18, be_nsuffix = 0x1bc31a58, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 13, bv_val = 0x1bc31cf8 "o=translucent"}, be_rootndn = {bv_len = 13, bv_val = 0x1bc31d80 "o=translucent"}, be_rootpw = {bv_len = 6, bv_val = 0x1bc31e00 "secret"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x1bb23530, be_pcl_mutex = { wrapped = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 2, __m_lock = {__status = 0, __spinlock = 0}}, usage = { magic = ldap_debug_magic, self = 3829197487, mem = {ptr = 0x0, num = 0}, state = ldap_debug_state_inited}, owner = 4294967295}, be_pcl_mutexp = 0x1bc31538, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x81deca0, be_private = 0x1bc315b0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x80e10c3 <over_back_response>, sc_cleanup = 0, sc_private = 0x1bc31e80} rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #7 0x080e1fbe in over_aux_chk_referrals (op=0x1bb0bc30, rs=0x1c731138) at backover.c:787 No locals. #8 0x0807c586 in backend_check_referrals (op=0x1bb0bc30, rs=0x1c731138) at backend.c:1301 No locals. #9 0x0808b143 in fe_op_modrdn (op=0x1bb0bc30, rs=0x1c731138) at modrdn.c:274 newSuperior_be = (Backend *) 0x0 pdn = {bv_len = 0, bv_val = 0x0} op_be = (BackendDB *) 0x1bc31470 bd = (BackendDB *) 0x81e3aa0 #10 0x0808acb3 in do_modrdn (op=0x1bb0bc30, rs=0x1c731138) at modrdn.c:186 dn = {bv_len = 31, bv_val = 0x1bc4abe7 "uid=fred,ou=users,o=translucent"} newrdn = {bv_len = 11, bv_val = 0x1bc4ac08 "uid=someguy"} newSuperior = {bv_len = 0, bv_val = 0x0} deloldrdn = 0 pnewSuperior = {bv_len = 0, bv_val = 0x0} nnewSuperior = {bv_len = 0, bv_val = 0x0} length = 0 #11 0x0806b483 in connection_operation (ctx=0x1c731214, arg_v=0x1bb0bc30) at connection.c:1083 rc = 80 op = (Operation *) 0x1bb0bc30 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 108 opidx = SLAP_OP_MODRDN conn = (Connection *) 0x1be539e0 memctx = (void *) 0x1bb0c048 memctx_null = (void *) 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #12 0x0806b943 in connection_read_thread (ctx=0x1c731214, argv=0x9) at connection.c:1210 rc = 0 cri = {op = 0x1bb0bc30, func = 0, arg = 0x0, ctx = 0x1c731214, nullop = 0} s = 9 #13 0x08144a1c in ldap_int_thread_pool_wrapper (xpool=0x1bb50e30) at tpool.c:625 pool = (struct ldap_int_thread_pool_s *) 0x1bb50e30 task = (ldap_int_thread_task_t *) 0x1bb24400 ctx = {ltu_id = 477305760, ltu_key = {{ltk_key = 0x806b05d, ltk_data = 0x1bb778b0, ltk_free = 0x806aefe <conn_counter_destroy>}, { ltk_key = 0x80cb901, ltk_data = 0x1bb0c048, ltk_free = 0x80cb738 <slap_sl_mem_destroy>}, {ltk_key = 0x8082923, ltk_data = 0x0, ltk_free = 0x80828a0 <slap_op_q_destroy>}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 426 hash = 5776810 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #14 0x00a633cc in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #15 0x008cb1ae in clone () from /lib/tls/libc.so.6 No symbol table info available.

1 0

Re: (ITS#5291) Client timeout dumps core
by hyc＠symas.com 07 Jan '08

07 Jan '08

daveh(a)coreng.com.au wrote: > FWIW, I back-ported the fix (1.81 in libraries/libldap/search.c) to 2.4.7, > and it works fine (both the test harness and my application). > > Many thanks. > Thanks for the followup. We'll make sure the fix is in 2.4.8. -- -- 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#5291) Client timeout dumps core
by daveh＠coreng.com.au 07 Jan '08

07 Jan '08

FWIW, I back-ported the fix (1.81 in libraries/libldap/search.c) to 2.4.7, and it works fine (both the test harness and my application). Many thanks. -- 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

Crashing database
by Carlos Parada 06 Jan '08

06 Jan '08

Hi all, (First of all, sorry for this "generic" thread) I'm using the openldap 2.3.34 version (I've already used previous ones). My usage is a bit different than the usual. I have a lot of write operations - tens per second - (adds, deletes) and also a lots of reads. I use to have very often a crash in my database. I'm using the bdb backend. Sometimes it is enough to restart my server to corrupt the database (at least to not be able to restart it). In other occasions, I corrupt my database using the slapcat command, which I know it is nor recommended, but it is also not disallowed by the application (and I think it was in previous versions). That buggy behavior should not be normal. I've already search and it seems it is a common problem using the bdb, many times reported. My question is: what is really happening? Am I configuring wrongly the server, DBD parameters, or anything else? Or there is a systematic bug not solved yet ? How to solve it? Another secondary issue is the recovery. Most of the times, I'm not able to recover my database either using db_recover or slapd_db_recover. Is there any trick for a more efficient recovery. Cumprimentos, Carlos Parada

2 3

Re: (ITS#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by ando＠sys-net.it 05 Jan '08

05 Jan '08

Jose, few preliminary comments: - you coded your contribution for OpenLDAP 2.3; however, since it configures as a new feature, it should be coded for OpenLDAP 2.4 (better for HEAD), as 2.3 is feature-frozen ever since. This comment may appear trivial, but right now your contribution does not compile with HEAD/re24 because of some internal API changes. - the coding style you used does not conform to that of the OpenLDAP project. Although this is usually only loosely enforced, you used things we're a bit picky about, like C++-style comments, and late declarations; if you compile with enough warnings (e.g., with gcc, with -Wall -pedantic) you'll see that in many cases functions are not returning when a return value is expected or vice-versa; incorrect formats are used for (long) integers, pointers and so. Also, I note that besides being a totally new contribution, many of the comments are already no longer aligned with the code. - according to agreed development lines, new contributions should always provide back-config support (this can be added later, if and when the rest works as expected) - with respect to the possible improvements you indicate, I think: 1) permission checking should occur along the lines of, e.g., slapo-dynlist(5), honoring dgIdentity and dgAuthz. 2) avoiding unnecessary expansion would probably be mandatory for production use 3) use back-config rather than naive in-database configuration using an ordinary database - The build instructions you provide are incorrect: you suggest to place the source in servers/slapd/overlays/, and to modify statover.c; this is a generated file, so it should never be modified. You should rather suggest to place the sources in an arbitrary directory (it could be contrib/slapd-modules/nestedAggregateAttr as soon as your contribution enters the official distribution) and build it as a run-time module. - you should rather eliminate duplicate values from result sets (much like slapo-dynlist(5) does) as they are not allowed by the definition of the "member" attribute, which has a distinguishedNameMatch EQUALITY rule. - instead of copying compare_entry(), you should rather ask to make the one in servers/slapd/compare.c non-static - since the "OR" operator in filters allows more than 2 operands, I think your filter combination strategy could be optimized by simply defining a combine_filters() function that counts the number of filter strings in the array and creates a filter like "(|(f1)(f2)(f3)...)" - in check_filter(), you compare strings; you should rather compare pointers to AttributeDescription structures. - in nestedAggregateAttrURL_search() you don't need to run str2filter() on op->ors_filterstr, since an exploded filter is already available in op->ors_filter - strings[] containing "(objectClass=<ocname>)" could be prepared once for all during config; it would save a lot of mallocs (BTW: use the slab for operation-spanning allocation). - I would recommend you do some consistent checking of return values before dereferencing pointers. - I would recommend that you either remove or turn into useful standard debugging the plethora of non-standard messages you added. Use LDAP_DEBUG_ARGS to mark entering/exiting functions (and logging useful args); use LDAP_DEBUG_TRACE to trace operations; use slap_loglevel_get() to register friendly names for specific log subsystems (you'll get back the number to compare with ldap_debug). - with respect to the OID for the test schema items, you'll get an OID arc in the experimental OID namespace of the OpenLDAP project as soon as your contribution is incorporated. 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#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by ando＠sys-net.it 05 Jan '08

05 Jan '08

josemarcodelarosa(a)gmail.com wrote: > Yes, you are completely right. The only reason I can think of using the > DN version is because you are forced by your schema (attribute types for the > expansion source attribute differ). I emphasize that the implementation of > both is quite different. The DN version uses recursivity while the URL > version relies in slapd's search-reply mechanism. I just added the first one > as an example. > > URL version is much more powerful and more elegant. You suggested > subGroupURL: ldap:///<dn>??base, but even subGroupURL: ldap:///<dn> works ok > (if I remember right). According to Section 3 of RFC 4516, if <scope> is omitted, a scope of "base" is assumed. 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#5307) www.openldap.org doesn't respond to Ipv6 requests
by matt＠windu.com 04 Jan '08

04 Jan '08

Sweet, thanks guys for running IPv6. Have a good weekend. -Matt > -----Original Message----- > From: Kurt Zeilenga [mailto:kurt@OpenLDAP.org] > Sent: Friday, January 04, 2008 2:51 PM > To: openldap-its(a)OpenLDAP.org > Cc: matt(a)windu.com > Subject: Re: (ITS#5307) www.openldap.org doesn't respond to Ipv6 > requests > > Try again... (restarted listener).

1 0

Re: (ITS#5307) www.openldap.org doesn't respond to Ipv6 requests
by kurt＠OpenLDAP.org 04 Jan '08

04 Jan '08

Try again... (restarted listener).

1 0

(ITS#5307) www.openldap.org doesn't respond to Ipv6 requests
by matt＠windu.com 04 Jan '08

04 Jan '08

Full_Name: Matt Bradbury Version: n/a OS: n/a URL: Submission from: (NULL) (198.252.182.170) www.openldap.org has a ipv6 dns record, unfortunately the server does not respond on that address. Luckily, or is that unluckily, I can still access your page via Internet Explorer which falls back to IPv4 if the server doesn't respond. I'm running Opera, which doesn't fall back to Ipv4 addresses. While this may not affect many customers, it would be nice to have the native support on the server or remove the entry from DNS if it's not actually responding to the IPv6 address. Thank you for your time. -Matt ps. Here's a couple of command prompt captures of my testing C:\Users\bradbury>ping www.openldap.org Pinging www.openldap.org [2001:4f8:3:ba:2e0:18ff:fe02:efec] from 2610:160:0:1008 :999e:9cad:c29d:5d16 with 32 bytes of data: Reply from 2001:4f8:3:ba:2e0:18ff:fe02:efec: time=58ms Reply from 2001:4f8:3:ba:2e0:18ff:fe02:efec: time=60ms Reply from 2001:4f8:3:ba:2e0:18ff:fe02:efec: time=59ms Reply from 2001:4f8:3:ba:2e0:18ff:fe02:efec: time=62ms Ping statistics for 2001:4f8:3:ba:2e0:18ff:fe02:efec: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 58ms, Maximum = 62ms, Average = 59ms C:\Users\bradbury>telnet 2001:4f8:3:ba:2e0:18ff:fe02:efec 80 Connecting To 2001:4f8:3:ba:2e0:18ff:fe02:efec...Could not open connection to th e host, on port 80: Connect failed C:\Users\bradbury>

1 0

Re: (ITS#5306) install ladp
by ando＠sys-net.it 04 Jan '08

04 Jan '08

aslang(a)ntu.edu.sg wrote: > I keep having this error: please advice > > slapadd -l init.ldif > /etc/ldap/slapd.conf: line 91: rootdn is always granted unlimited privileges. > /etc/ldap/slapd.conf: line 112: rootdn is always granted unlimited privileges. > str2entry: entry -1 has multiple DNs "dc=4g,dc=ntu,dc=edu,dc=sg" and > "ou=people,dc=4g,dc=ntu,dc=edu,dc=sg" > slapadd: could not parse entry (line=52) > > In my init.ldif, I do have line 52, my last line is 51 > This is the content of my init.ldif file > > dn: dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: dcObject > objectClass: organizationalUnit > dc: 4g > ou: NTU 4G Lab > dn: ou=people,dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: organizationalUnit > ou: people > dn: ou=staff,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: organizationalUnit > ou: staff > dn: ou=students,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: organizationalUnit > ou: students > dn: ou=visitors,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: organizationalUnit > ou: visitors > dn: uid=linda,ou=visitors,ou=people,dc=ntu,dc=edu,dc=sg > objectClass: inetOrgPerson > objectClass: posixAccount > objectClass: shadowAccount > uid: linda > sn: Ang > givenName: Linda > cn: Linda Ang > displayName: Linda Ang > uidNumber: 1000 > gidNumber: 10000 > userPassword: password > gecos: Linda Ang > loginShell: /bin/bash > homeDirectory: /home/linda > shadowExpire: -1 > shadowFlag: 0 > shadowWarning: 7 > shadowMin: 8 > shadowMax: 999999 > shadowLastChange: 10877 > mail: linda_yong(a)hotmail.com > postalCode: 31000 > l: Toulouse > o: Example > mobile: +65 (0)6 12345678 > homePhone: +33 (0)5 12345678 > title: System Administrator > postalAddress: > initials: LA > dn: cn=4g,ou=staff,ou=people,dc=ntu,dc=edu,dc=sg > objectClass: posixGroup > cn: 4g > gidNumber: 10000 The error you see represents the expected behavior, since your LDIF file is invalid; please check your syntax. As there appears to be no OpenLDAP software bug, this ITS will be closed. Please direct further discussion to OpenLDAP-software. 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#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by josemarcodelarosa＠gmail.com 04 Jan '08

04 Jan '08

------=_Part_27665_28430263.1199452056921 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes, you are completely right. The only reason I can think of using the DN version is because you are forced by your schema (attribute types for the expansion source attribute differ). I emphasize that the implementation of both is quite different. The DN version uses recursivity while the URL version relies in slapd's search-reply mechanism. I just added the first one as an example. URL version is much more powerful and more elegant. You suggested subGroupURL: ldap:///<dn>??base, but even subGroupURL: ldap:///<dn> works ok (if I remember right). ------=_Part_27665_28430263.1199452056921 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline   Yes, you are completely right.  The only reason I can think of using the DN version is because you are forced by your schema (attribute types for the expansion source attribute differ). I emphasize that the implementation of both is quite different. The DN version uses recursivity while the URL version relies in slapd's search-reply mechanism. I just added the first one as an example.   URL version is much more powerful and more elegant. You suggested subGroupURL: ldap:///<dn>??base, but even subGroupURL: ldap:///<dn> works ok (if I remember right). ------=_Part_27665_28430263.1199452056921--

1 0

(ITS#5306) install ladp
by aslang＠ntu.edu.sg 04 Jan '08

04 Jan '08

Full_Name: Linda Ang Version: OpenLDAP: slapd 2.3.35 OS: Ububtu 1.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (155.69.2.5) I keep having this error: please advice slapadd -l init.ldif /etc/ldap/slapd.conf: line 91: rootdn is always granted unlimited privileges. /etc/ldap/slapd.conf: line 112: rootdn is always granted unlimited privileges. str2entry: entry -1 has multiple DNs "dc=4g,dc=ntu,dc=edu,dc=sg" and "ou=people,dc=4g,dc=ntu,dc=edu,dc=sg" slapadd: could not parse entry (line=52) In my init.ldif, I do have line 52, my last line is 51 This is the content of the /etc/ldap/slapd.conf file ######################### /etc/ldap/slapd.conf ######################### # http://homex.subnet.at/~max/ldap/ # # Basic slapd.conf # # 2005.02.08 ZHANG.Guiyu(a)example.com ######################################################################## # Global Directives: # # Features to permit #allow bind_v2 # Schema and objectClass definitions # not all required, if you get errors about missing schema, comment out the missing schema here # some are provided by other packages such as samba include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/samba.schema # Schema check allows for forcing entries to # match schemas for their objectClasses's schemacheck on # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd.args # Read slapd.conf(5) for possible values loglevel 0 # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_bdb #moduleload back_passwd ####################################################################### # Specific Backend Directives for ldbm: # Backend specific directives apply to this backend until another # backend' directive occurs backend bdb ####################################################################### # Specific Backend Directives for 'other': # Backend specific directives apply to this backend until another # 'backend' directive occurs # backend <other> ####################################################################### # Specific Directives for database #1, of type ldbm: # Database specific directives apply to this databasse until another # 'database' directive occurs # # important: use bdb format, other formats like ldbm can cause data corruption database bdb # The base of your directory in database #1 suffix "dc=4g,dc=ntu,dc=edu,dc=sg" rootdn "cn=root,dc=4g,dc=ntu,dc=edu,dc=sg" password-hash {CRYPT} #rootpw {CRYPT}asdfghjkl # # use "/usr/sbin/slappasswd -h {CRYPT}" to create a rootpw-string below rootpw {CRYPT}1zLLT3DU571FM # Where the database file are physically stored for database #1 directory "/var/lib/ldap" # Indexing options for database #1 index objectClass eq # Save the time that the entry gets modified, for database #1 lastmod on # Where to store the replica logs for database #1 # replogfile /var/lib/ldap/replog # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only # access to attrs=userPassword,sambaLMPassword,sambaNTPassword by dn="cn=root,dc=4g,dc=ntu,dc=edu,dc=sg" write by anonymous auth by self write by * none access to * by dn="cn=nss,dc=ntu,dc=edu,dc=sg" read by * auth # Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. #access to dn.base="" by * read # The admin dn has full write access, everyone else # can read everything. access to * by dn="cn=root,dc=4g,dc=ntu,dc=edu,dc=sg" write by * read # For Netscape Roaming support, each user gets a roaming # profile for which they have write access to #access to dn=".*,ou=Roaming,o=morsnet" # by dn="cn=admin,dc=mail,dc=example,dc=com" write # by dnattr=owner write ####################################################################### # Specific Directives for database #2, of type 'other' (can be bdb too): # Database specific directives apply to this databasse until another # 'database' directive occurs #database <other> # #The base of your directory for database #2 #suffix "dc=debian,dc=org" ####################################################################### This is the content of my init.ldif file dn: dc=4g,dc=ntu,dc=edu,dc=sg objectClass: dcObject objectClass: organizationalUnit dc: 4g ou: NTU 4G Lab dn: ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: people dn: ou=staff,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: staff dn: ou=students,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: students dn: ou=visitors,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: visitors dn: uid=linda,ou=visitors,ou=people,dc=ntu,dc=edu,dc=sg objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount uid: linda sn: Ang givenName: Linda cn: Linda Ang displayName: Linda Ang uidNumber: 1000 gidNumber: 10000 userPassword: password gecos: Linda Ang loginShell: /bin/bash homeDirectory: /home/linda shadowExpire: -1 shadowFlag: 0 shadowWarning: 7 shadowMin: 8 shadowMax: 999999 shadowLastChange: 10877 mail: linda_yong(a)hotmail.com postalCode: 31000 l: Toulouse o: Example mobile: +65 (0)6 12345678 homePhone: +33 (0)5 12345678 title: System Administrator postalAddress: initials: LA dn: cn=4g,ou=staff,ou=people,dc=ntu,dc=edu,dc=sg objectClass: posixGroup cn: 4g gidNumber: 10000

1 0

Re: (ITS#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by hyc＠symas.com 03 Jan '08

03 Jan '08

josemarcodelarosa(a)gmail.com wrote: > Full_Name: Jose Marco de la Rosa > Version: 2.3.39 > OS: Kubuntu 7.10 > URL: ftp://ftp.openldap.org/incoming/Jose-Marco-de-la-Rosa-nestedAggregateAttr-0… > Submission from: (NULL) (80.25.122.131) > > > Two overlays that implement dynamic group classes defined with URL attributes > and allowing nesting. > > - The first one is an extension of th overlay expandURL but allowing nesting > > - The second one changes the way groups are constructed in a more powerful way > * IMPORTANT: this overlay conflicts with nestedAggregateAttrDN. > * if both are active, some searches don't behave as expacted! > * Specifically, if you turn both overlays on and search for > * 'entries with member=<some member value>' won't work properly > * for one of the overlays (the firstly activated one) Seems there's really no need for the nestedAggregateAttrDN overlay, since that is just a proper subset of a URL. I.e., anywhere you would use a simple DN is just a case of subGroupURL: ldap:///<dn>??base -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs