- openldap-bugs - openldap.org

Re: (ITS#5078) slapd high cpu usage
by bgmilne＠staff.telkomsa.net 15 Aug '07

15 Aug '07

On Tuesday 14 August 2007 20:43:36 Babu.Suresh(a)pacificlife.com wrote: > Hello, > > Can we index uniquemember in openldap-2.3.32 & BDB 4.5.20? > > index uniquemember eq,pres I think you can in 2.3.x, but if you can't, you could always fix this on the client side, and tell nss_ldap to map uniqueMember to member (which ends up being a bit more useful anyway IMHO). Regards, Buchan

1 0

RE: (ITS#5078) slapd high cpu usage
by ghenry＠suretecsystems.com 14 Aug '07

14 Aug '07

<quote who="Suresh, Babu"> > Iam getting this.. > > conn=7 op=2 SRCH base="ou=xxx,ou=yyyy,o=zzzzz" scope=1 deref=0 > filter="(&(uniqueMember=cn=aaa,ou=bbb,ou=ccc,o=dddd)(objectClass=groupOf > UniqueNames))" > conn=7 op=2 SRCH attr=cn > <= bdb_equality_candidates: (uniqueMember) index_param failed (18) And did you stop slapd, run slapdindex and restart slapd? Thank you > > Thank you > > -----Original Message----- > From: Gavin Henry [mailto:ghenry@suretecsystems.com] > Sent: Tuesday, August 14, 2007 12:37 PM > To: Suresh, Babu > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#5078) slapd high cpu usage > > Babu.Suresh(a)pacificlife.com wrote: >> Hello, >> >> Can we index uniquemember in openldap-2.3.32 & BDB 4.5.20? >> >> index uniquemember eq,pres >> >> Thank you >> > > Try it ;-) > > > ------------------------------------------------------------------------------ > The information in this e-mail and any attachments are for the sole use of > the intended recipient and may contain privileged and confidential > information. If you are not the intended recipient, any use, disclosure, > copying or distribution of this message or attachment is strictly > prohibited. If you believe that you have received this e-mail in error, > please contact the sender immediately and delete the e-mail and all of its > attachments. > ============================================================================== > >

1 0

Re: (ITS#5078) slapd high cpu usage
by ghenry＠suretecsystems.com 14 Aug '07

14 Aug '07

Babu.Suresh(a)pacificlife.com wrote: > Hello, > > Can we index uniquemember in openldap-2.3.32 & BDB 4.5.20? > > index uniquemember eq,pres > > Thank you > Try it ;-)

1 0

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by ghenry＠suretecsystems.com 14 Aug '07

14 Aug '07

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: > >> Backends are quite inconsistent about how Bind treats rootdn/rootpw. >> After a quick browse of the HEAD code, it looks like this - I'll >> investigate closer if needed: >> >> rootpw supported: >> Yes: config, bdb, meta, monitor, ldif, HEAD:null, sql, overlay retcode. >> No: dnssrv, ldap?, RE23:null, perl, relay, shell. > > back-ldap doesn't care about rootdn/rootpw; back-meta does mostly for > historical reasons (could be removed with some work). > >> (Bind not supported: passwd). >> >> Rootpw vs. normal Bind as rootdn (typically when rootdn names an entry): >> config, bdb, null, sql, overlay retcode (I think): >> Try rootpw first, then if failure try normal Bind (even if >> rootpw exists but the Bind password does not match it). >> ldif: >> Do not try rootpw if rootdn names an existing entry. >> meta: >> Fail if rootpw is missing or does not match, more complicated >> otherwise. >> monitor: >> Fine - there are no entries with passwords. > > (yet :) > > I discovered that back-monitor may benefit from having a rootdn because > this provides a means to easily workaround any ACLs. The availability > of rootpw is also important because I ran into few cases where no other > means to authenticate were available, and all in all this feature (I > mean: rootdn w/ rootpw comes for free from the database infrastructure). Don't you do this in test043: "# HACK: use the RootDN of the monitor database as UpdateDN so ACLs apply"

1 0

RE: (ITS#5078) slapd high cpu usage
by Babu.Suresh＠pacificlife.com 14 Aug '07

14 Aug '07

Hello, Can we index uniquemember in openldap-2.3.32 & BDB 4.5.20? index uniquemember eq,pres Thank you -----Original Message----- From: Christian Marg [mailto:marg@rz.tu-clausthal.de] Sent: Wednesday, August 08, 2007 12:15 AM To: Suresh, Babu; openldap-its(a)openldap.org Subject: Re: (ITS#5078) slapd high cpu usage Hello, Babu.Suresh(a)pacificlife.com wrote: > bdb_db_open: Warning - No DB_CONFIG file found in directory=20 Expect > poor performance for suffix o=3Dpacificlife.com. Well, slapd even gives you hints for better performance... > <=3D bdb_equality_candidates: (uid) index_param failed (18) <=3D > bdb_equality_candidates: (cn) index_param failed (18) <=3D > bdb_equality_candidates: (uniqueMember) index_param failed (18) Obviously there are some indices missing in the Database. First add configuration for indices cn, uniquemember then re-index/rebuild database. bye Christian -- Christian Marg mail : mailto:marg@rz.tu-clausthal.de Dezernat 2 TU Clausthal web : http://www.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2107 Germany jabber: ifcma(a)jabber.tu-clausthal.de ------------------------------------------------------------------------------ The information in this e-mail and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. If you believe that you have received this e-mail in error, please contact the sender immediately and delete the e-mail and all of its attachments. ==============================================================================

1 0

Re: (ITS#4627) back-ldif issues
by ando＠sys-net.it 14 Aug '07

14 Aug '07

h.b.furuseth(a)usit.uio.no wrote: > Error handling: > > ldif_tool_entry_first() cannot return NOID. Dunno (untouched) > ldif_back_<add,modify,delete,modrdn> always return success (0). > Maybe some of this is a requirement of back-config? If so I > suggest that back-config sets a ldif_info.li_optimism flag and > that back-ldif otherwise treats errors as errors. Don't think so: now they return rs->sr_err and everything keeps working. > If rmdir() in ldif_back_delete() fails with errno != ENOENT, > rs->sr_err is set to LDAP_NOT_ALLOWED_ON_NONLEAF - but is then > immediately overwritten with LDAP_UNWILLING_TO_PERFORM. Fixed > ldif_tool_entry_put() sets 'res' to various LDAP result codes, but > only uses it as a boolean. Are the codes supposed to be logged? Dunno (untouched) > Files: > > back-ldif overwrites files instead writing to a temp file and > renaming when complete. The current way corrupts entries if a > write fails halfway through, e.g. due to a full disk. Also the > file can be left truncated if internal slapd operations fail. > If the OS supports it, back-ldif should make a new file in the > same directory and rename to the old filename when complete. Fixed; now mkstemp(3) is used, and rename(2) only in case of success. > > Locks: > > The global entry2str_mutex is locked around spew_entry() instead > of inside it, so it spans more file operations than necessary. > Should be held more briefly, I think. Though it does make kind of > sense now: It is locked before the file is truncated so that the > file won't be in truncated state for long while slapd waits for > the mutex. But that's not quite how I'd go about solving that > problem; see above. (I have not checked if the mutex doubles as a > mutex to synchronize internal back-ldif operations. So I don't > know if lock/unlock can just be moved inside spew_entry().) Moved as close as possible to entry2str() whenever not used also to serialize backend-specific operations (like in ldif_back_modrdn) > > struct bvlist quirks: > > .num holds an unnecessarily duplicated string. It only needs to a > bechar, holding the character being overwritten with a '\0'. (And > replace the AC_MEMCPY in r_enum_tree() which restores it.) > > For that matter, .num is not needed at all if the '\0' can replace > the IX_FSL (usually '{') instead of the character following it. > (And decrement .off with 1.) Then r_enum_tree() can just put back > an IS_FSL. It would affect the sort order of values prefixed with > '{num}' compared to unprefixed values of the same type. untouched (too cumbersome for summer holidays...) > .inum should be signed, or should be read with strtoul instead of > strtol. strtoul(3) used > I suppose it and cmp in the function should be ber_int_t, > since LDAP integers are typically 32-bit. Not sure what you mean. > Also, for reading .inum and syntax checking: Maybe you should use > strtol() without first doing strchr(,IX_FSR), and then check that > the character after the integer is IX_FSR. Slower though. I think in this case the code is safe as is, because there's no guarantee of itmp.bv_val being nul-terminated, so better check before using strto[u]l, which expects nul-terminated strings. > Other quirks: > > ldif.c uses "struct ldif_info *ni" = be->be_private. Maybe it > used back-null as a template, where "ni" stands for null_info? s/ni/li/g > Return values from get_entry() and spew_entry() are pointlessly > cast to the same type as the functions already return. Fixed. 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#4962) inconsistent Bind(rootdn) behavior
by ando＠sys-net.it 14 Aug '07

14 Aug '07

h.b.furuseth(a)usit.uio.no wrote: > Backends are quite inconsistent about how Bind treats rootdn/rootpw. > After a quick browse of the HEAD code, it looks like this - I'll > investigate closer if needed: > > rootpw supported: > Yes: config, bdb, meta, monitor, ldif, HEAD:null, sql, overlay retcode. > No: dnssrv, ldap?, RE23:null, perl, relay, shell. back-ldap doesn't care about rootdn/rootpw; back-meta does mostly for historical reasons (could be removed with some work). > (Bind not supported: passwd). > > Rootpw vs. normal Bind as rootdn (typically when rootdn names an entry): > config, bdb, null, sql, overlay retcode (I think): > Try rootpw first, then if failure try normal Bind (even if > rootpw exists but the Bind password does not match it). > ldif: > Do not try rootpw if rootdn names an existing entry. > meta: > Fail if rootpw is missing or does not match, more complicated > otherwise. > monitor: > Fine - there are no entries with passwords. (yet :) I discovered that back-monitor may benefit from having a rootdn because this provides a means to easily workaround any ACLs. The availability of rootpw is also important because I ran into few cases where no other means to authenticate were available, and all in all this feature (I mean: rootdn w/ rootpw comes for free from the database infrastructure). > The manpage is (fortunately:-) unclear on what happens in this case. }-) > Check if op->orb_method == LDAP_AUTH_SIMPLE: > Yes: config, bdb, meta, monitor. > No: ldif, null, sql, overlay retcode. I don't think we can get to calling bi_op_bind() otherwise... could even be an assertion. > Set op->orb_edn (op->oq_bind.rb_edn) from be_root_dn() on success: > config, bdb, monitor, sql. > > Set op->orb_edn on failure: > bdb: Sometimes, from &e->e_name. > sql: Always, from op->o_req_ndn. Not sure what does this mean: op->orb_edn should only be set in case of success, AFAIK. > Set rs->sr_err = LDAP_SUCCESS on success: > ldif, meta For consistency, I presume. The caller will just check the response code. > Reset rs->sr_text: > meta > > Which behavior is right? I'm wondering if Bind should fail if rootpw > exists but the Bind password does not match it. > > In any case, methinks we need a be_rootpw_bind(op, rs) function which > takes care of this consistently, so bi_op_bind in most cases can just do > if (be_rootpw_bind(op, rs)) return rs->sr_err; > If needed it could accept rs==NULL to just check the password - like > be_isroot_pw() but with more return codes to distinguish different > cases. At this point, it might be worth moving this check outside bi_op_bind(). Wait a moment: we need to do something else at least in back-meta if rootdn bind succeeds... but I think that could be changed. 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#5086) back-bdb bug when add is used with snapshot isolation
by hyc＠symas.com 14 Aug '07

14 Aug '07

We tested with snapshot isolation before and found no performance benefit. As such, there's no point in undertaking the effort to fix this issue. It's worth noting that with a properly configured cache, most read operations are satisfied by the slapd entry cache, so the main point of lock contention that snapshot isolation tries to solve never even occurs. stelios.xx.grigoriadis(a)ericsson.com wrote: > Full_Name: Stelios Grigoriadis > Version: 2.3.32 > OS: Linux, (SLES 10) > URL: http://ninikos.freehostia.com/bdb_idl_cache_bug.tar.gz > Submission from: (NULL) (194.237.142.7) > > > When using slapd with the snapshot isolation level in DB (version 4.5.20) > it is possible that added entries don't appear in subsequent searches. > > Scenario: A client is adding new information while at the same time another > is initiating an LDAP search with the same searchbase as the "parent" of > the added information. > If the search is executed after the add operation has cleared the IDL-cache > but before the changes has been committed, the added entries will not appear > in any subsequent searches unless slapd is restarted. > > The problem is that, in the bdb_idl_insert_key-function, the key is deleted > from the IDL-cache but the newly added keys in the database are not yet > committed, so clients that re-read the information will not have those updated > keys. > > The solution would be to clear the relevant IDL-cache entries after the > changes has been committed. > > This behaviour is demonstrated by the program cache_test_fork.c which is > supplied > in bdb_idl_cache_bug.tar.gz along with the slapd configuration. > > I am currently working on the solution but would greatly appreciate any help > from you as I am not nearly as familiar with the code as you are. > > > . > -- -- 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#5091) Odds of attribute mapping in slapo-rwm
by ando＠sys-net.it 14 Aug '07

14 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando If an attribute is mapped onto another, say rwm-map attribute foo bar and both attributes "foo" and "bar" are present in the underlying database, there might be cases (like requesting "*") where both are returned, and "bar" is mapped into "foo" while "foo" remains "foo", but they appear in the result as separate attributes. I guess the cleanest solution would be to merge the two attribute sets into a single occurrence of "foo". I didn't check yet, but I expect a similar issue to be present with respect to objectClass; in this case, the same value might appear twice. p.

1 0

Re: (ITS#5061) client/tools: Password Policy control handling
by ando＠sys-net.it 13 Aug '07

13 Aug '07

quanah(a)zimbra.com wrote: > Pierangelo noted I missed common.c, which has many of the same issues > around it as ldapmodify.c. I can back out the commits I made earlier > today, or the backporting can be done for those two... I think it would be > nice to have the functionality into 2.3. I've already patched ldapmodify.c (keeping as low a profile as possible); most of the work is now in common.c, but I can try to keep the same low profile and see where I get. 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#5061) client/tools: Password Policy control handling
by quanah＠zimbra.com 13 Aug '07

13 Aug '07

--On August 13, 2007 7:13:03 PM +0000 quanah(a)zimbra.com wrote: > > > --On August 13, 2007 7:08:32 PM +0000 kurt(a)OpenLDAP.org wrote: > >> Given the ppolicy change backport for everything else was straight >> forward for >> every other command, and committed, seems reasonable to keep it. >> Ando and/or >> I likely can do a quick backport for ldapmodify.c. > > Sounds good. :) Pierangelo noted I missed common.c, which has many of the same issues around it as ldapmodify.c. I can back out the commits I made earlier today, or the backporting can be done for those two... I think it would be nice to have the functionality into 2.3. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5061) client/tools: Password Policy control handling
by quanah＠zimbra.com 13 Aug '07

13 Aug '07

--On August 13, 2007 7:08:32 PM +0000 kurt(a)OpenLDAP.org wrote: > Given the ppolicy change backport for everything else was straight > forward for > every other command, and committed, seems reasonable to keep it. > Ando and/or > I likely can do a quick backport for ldapmodify.c. Sounds good. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5061) client/tools: Password Policy control handling
by kurt＠OpenLDAP.org 13 Aug '07

13 Aug '07

Given the ppolicy change backport for everything else was straight forward for every other command, and committed, seems reasonable to keep it. Ando and/or I likely can do a quick backport for ldapmodify.c. -- Kurt

1 0

Re: (ITS#5061) client/tools: Password Policy control handling
by kurt＠OpenLDAP.org 13 Aug '07

13 Aug '07

On Aug 13, 2007, at 6:06 PM, quanah(a)zimbra.com wrote: > --On July 23, 2007 6:51:35 PM +0000 kurt(a)OpenLDAP.org wrote: > >> Full_Name: Kurt Zeilenga >> Version: 2.3 >> OS: Mac OS X >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (130.129.101.249) >> Submitted by: kurt >> >> >> 2.3 (and 2.4) client tools only send the password policy control >> with the >> Bind requests. However, the control is not only valid with most >> every >> request, but useful to send with every request. HEAD has been >> updated >> to send, when -e ppolicy is selected, the control with every >> request, and >> to print the control details on return. While this could be >> viewed as a >> new feature by some it could abe viewed as a bug fix by others. >> Given >> this change scope is quite narrow (should only effect -e ppolicy >> users), >> I recommend it inclusion in the next patch release of 2.3. > > Hi Kurt, > > I've been working on this for the 2.3 release, however there is a > problem > when it comes to ldapmodify. Pierangelo made the change around > controls to > the ldapmodify code around revision 1.172. However, when 2.3 was > branched > (after revision 1.175), this new code was excluded by you. So, the > question I have now, is should this code now be pulled into 2.3? > It is > quite a bit of change. > > --Quanah If 2.3 wasn't quite frozen, I'd say just suck in the new tools... But given 2.3 is very much frozen, and the change scope isn't as narrow as I thought it would be, seems more appropriate just to leave this out. Oh well. Another reason to push 2.4beta out, I guess. -- Kurt

1 0

Re: (ITS#5061) client/tools: Password Policy control handling
by quanah＠zimbra.com 13 Aug '07

13 Aug '07

--On July 23, 2007 6:51:35 PM +0000 kurt(a)OpenLDAP.org wrote: > Full_Name: Kurt Zeilenga > Version: 2.3 > OS: Mac OS X > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.129.101.249) > Submitted by: kurt > > > 2.3 (and 2.4) client tools only send the password policy control with the > Bind requests. However, the control is not only valid with most every > request, but useful to send with every request. HEAD has been updated > to send, when -e ppolicy is selected, the control with every request, and > to print the control details on return. While this could be viewed as a > new feature by some it could abe viewed as a bug fix by others. Given > this change scope is quite narrow (should only effect -e ppolicy users), > I recommend it inclusion in the next patch release of 2.3. Hi Kurt, I've been working on this for the 2.3 release, however there is a problem when it comes to ldapmodify. Pierangelo made the change around controls to the ldapmodify code around revision 1.172. However, when 2.3 was branched (after revision 1.175), this new code was excluded by you. So, the question I have now, is should this code now be pulled into 2.3? It is quite a bit of change. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5090) Error with attribute "jpegPhoto"
by ando＠sys-net.it 13 Aug '07

13 Aug '07

nicolas.sandraz(a)gmail.com wrote: Fixed in HEAD & re23; please test. 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#5090) Error with attribute "jpegPhoto"
by ando＠sys-net.it 13 Aug '07

13 Aug '07

Howard Chu wrote: > ando(a)sys-net.it wrote: >> marg(a)rz.tu-clausthal.de wrote: >>> Oh, and that special syntax is a function of ldapadd/ldapmodify, not >>> some standard way of importing images - so using it with slapadd >>> won't work. > > Not true. Both slapadd and ldapadd use the same LDIF reading routines; > they have since 2.3 was first released. All valid LDIF is accepted > identically by both programs. > >> well, that's a SHOULD in RFC2849, so it is indeed a standard way of >> importing values (works with any value) using LDIF. The fact it doesn't >> work with slapadd should be seen as a limitation of that tool, which it >> is not intended for use with arbitrary LDIF but rather with LDIF >> produced by slapcat. Well, I need to take both my claims back; I was writing jpegPhoto: <file///... while the right syntax (still with the missing ":") is jpegPhoto:< file///... and the error is still there in 2.3. I'll fix it in a moment. 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#5090) Error with attribute "jpegPhoto"
by hyc＠symas.com 13 Aug '07

13 Aug '07

ando(a)sys-net.it wrote: > marg(a)rz.tu-clausthal.de wrote: >> Oh, and that special syntax is a function of ldapadd/ldapmodify, not >> some standard way of importing images - so using it with slapadd won't work. Not true. Both slapadd and ldapadd use the same LDIF reading routines; they have since 2.3 was first released. All valid LDIF is accepted identically by both programs. > well, that's a SHOULD in RFC2849, so it is indeed a standard way of > importing values (works with any value) using LDIF. The fact it doesn't > work with slapadd should be seen as a limitation of that tool, which it > is not intended for use with arbitrary LDIF but rather with LDIF > produced by slapcat. -- -- 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#5090) Error with attribute "jpegPhoto"
by ando＠sys-net.it 13 Aug '07

13 Aug '07

marg(a)rz.tu-clausthal.de wrote: >> i use this line (on my ldif file) to add a picture on my LDAP directory: >> >> jpegPhoto: < file///etc/ldap/pictures/test.jpg > > Are you sure that you aren't missing a colon (':')? According to the > manpage of ldapadd the line should look like this: > > jpegPhoto: < file:///etc/ldap/pictures/test.jpg Moreover, this bug appears to have already been fixed. It is recommended to check the latest version before reporting bugs. > Oh, and that special syntax is a function of ldapadd/ldapmodify, not > some standard way of importing images - so using it with slapadd won't work. well, that's a SHOULD in RFC2849, so it is indeed a standard way of importing values (works with any value) using LDIF. The fact it doesn't work with slapadd should be seen as a limitation of that tool, which it is not intended for use with arbitrary LDIF but rather with LDIF produced by slapcat. 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#5090) Error with attribute "jpegPhoto"
by marg＠rz.tu-clausthal.de 13 Aug '07

13 Aug '07

Hello, nicolas.sandraz(a)gmail.com wrote: > when i use a LDIF file with the falowing attribute jpegPhoto associate with the > object class inetOrgPerson i have this error: > > slapadd : /tmp/build/openldap2.3-2.3.30/servers/slapd/schema_check.c:87 : > entry_schema_check: Assertion `a->a_vals[0].bv_val != ((void *)0)' failed. > > i use this line (on my ldif file) to add a picture on my LDAP directory: > > jpegPhoto: < file///etc/ldap/pictures/test.jpg Are you sure that you aren't missing a colon (':')? According to the manpage of ldapadd the line should look like this: jpegPhoto: < file:///etc/ldap/pictures/test.jpg Oh, and that special syntax is a function of ldapadd/ldapmodify, not some standard way of importing images - so using it with slapadd won't work. bye Christian -- Christian Marg mail : mailto:marg@rz.tu-clausthal.de Dezernat 2 TU Clausthal web : http://www.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2107 Germany jabber: ifcma(a)jabber.tu-clausthal.de

1 0

(ITS#5090) Error with attribute "jpegPhoto"
by nicolas.sandraz＠gmail.com 13 Aug '07

13 Aug '07

Full_Name: Sandraz Nicolas Version: 2.3.30 OS: Linux (debian Etch) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.252.72.177) when i use a LDIF file with the falowing attribute jpegPhoto associate with the object class inetOrgPerson i have this error: slapadd : /tmp/build/openldap2.3-2.3.30/servers/slapd/schema_check.c:87 : entry_schema_check: Assertion `a->a_vals[0].bv_val != ((void *)0)' failed. i use this line (on my ldif file) to add a picture on my LDAP directory: jpegPhoto: < file///etc/ldap/pictures/test.jpg note: when i remove this line from my ldif file i can import all information!

1 0

(ITS#5089) test043-delta-syncrepl: test failed - producer and consumer databases differ
by michael＠stroeder.com 11 Aug '07

11 Aug '07

Full_Name: Michael Ströder Version: HEAD OS: openSUSE 10.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.34.52) Running ./scripts/test043-delta-syncrepl... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entries in the producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Waiting 5 seconds for slapd to start... Using ldapadd to populate the producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that producer slapd is running... Using ldapmodify to modify producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the producer... Restarting consumer... Waiting 25 seconds for syncrepl to receive changes... Try updating the consumer slapd... Waiting 15 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer... test failed - producer and consumer databases differ

1 0

Re: (ITS#5051) Translucent overlay and back-monitor
by ghenry＠suretecsystems.com 11 Aug '07

11 Aug '07

<quote who="Pierangelo Masarati"> > Gavin Henry wrote: > >> OK, thanks. Do you have any reference for custom monitoring examples? > > Not sure what you mean. By "custom monitoring" I mean that pieces of > code may register callbacks in back-monitor to enrich the monitor > entries with dynamically generated data. Right now, the only code that > exploits this functionality is back-bdb/back-hdb, but it's something we > use intensively for custom modules we develop (the monitor database can > be proficiently used as an interface for non-persistent interaction with > the DSA). Ah, right. Sorry, I misunderstood custom as something done via configuration in the front end, not via callbacks. > > With reference to code, see servers/slapd/back-bdb/monitor.c (the API is > implemented in servers/slapd-back-monitor/init.c). Will do, sounds very useful indeed. > > What back-bdb/hdb publishes by means of this API is not documented, > AFAIK; it might be worth mentioning somewhere in the docs, as this > monitoring could be quite useful for tuning. Nothing that cannot be > accessed thru db_stat, the advantage is access via LDAP protocol. Exactly, sounds very useful and one that I can investigate and document in the Monitoring section, with implementation examples (not code) in the Tuning and Maintenance sections of our guide. > > A recent addition was the capability to monitor what unindexed > attributes were used in searches. Yeah, I commented on that previously. Nice. Gavin. > > 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#5051) Translucent overlay and back-monitor
by ando＠sys-net.it 11 Aug '07

11 Aug '07

Gavin Henry wrote: > OK, thanks. Do you have any reference for custom monitoring examples? Not sure what you mean. By "custom monitoring" I mean that pieces of code may register callbacks in back-monitor to enrich the monitor entries with dynamically generated data. Right now, the only code that exploits this functionality is back-bdb/back-hdb, but it's something we use intensively for custom modules we develop (the monitor database can be proficiently used as an interface for non-persistent interaction with the DSA). With reference to code, see servers/slapd/back-bdb/monitor.c (the API is implemented in servers/slapd-back-monitor/init.c). What back-bdb/hdb publishes by means of this API is not documented, AFAIK; it might be worth mentioning somewhere in the docs, as this monitoring could be quite useful for tuning. Nothing that cannot be accessed thru db_stat, the advantage is access via LDAP protocol. A recent addition was the capability to monitor what unindexed attributes were used in searches. 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#5051) Translucent overlay and back-monitor
by ghenry＠suretecsystems.com 11 Aug '07

11 Aug '07

<quote who="ando(a)sys-net.it"> > ghenry(a)suretecsystems.com wrote: > >> Ok. What can the rootdn do on the monitor database then? Write to >> anything? >> I can update the "Monitoring" section with this info then ;-) > > As usual, the privilege of the rootdn consists in bypassing ACLs. In > this case, you just need the rootdn, it doesn't need to be able to bind > (i.e. no rootpw and no fancy SASL rules to map someone with that > identity), since it will only be used for internal purposes, namely to > look up where bdb custom monitoring will be placed. OK, thanks. Do you have any reference for custom monitoring examples? Gavin. > > 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#4211
by ando＠sys-net.it 11 Aug '07

11 Aug '07

Quanah, for which is which, HEAD now has back-config support for both slapo-rwm and slapd-relay. You may resume your configuration replication experiments... 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#5051) Translucent overlay and back-monitor
by ando＠sys-net.it 11 Aug '07

11 Aug '07

ghenry(a)suretecsystems.com wrote: > Ok. What can the rootdn do on the monitor database then? Write to anything? > I can update the "Monitoring" section with this info then ;-) As usual, the privilege of the rootdn consists in bypassing ACLs. In this case, you just need the rootdn, it doesn't need to be able to bind (i.e. no rootpw and no fancy SASL rules to map someone with that identity), since it will only be used for internal purposes, namely to look up where bdb custom monitoring will be placed. 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#5088) ObjectClass inheritance check in back-sql
by ando＠sys-net.it 11 Aug '07

11 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando When extra objectClasses for an entry are listed in table ldap_entry_objclasses, if any of them is structural and derived from the objectClass used to map the RDBMS data to LDAP, the entry is now rejected because the computed objectClass does not match the objectClass used to map data, although the entry would be perfectly valid from an LDAP standpoint. This is now fixed in HEAD/re23. p.

1 0

(ITS#5087) slapacl is broken for back-hdb
by hyc＠OpenLDAP.org 11 Aug '07

11 Aug '07

Full_Name: Howard Chu Version: 2.3/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc The tool_id2entry_get function neglects the fix_dn step for hdb, so every retrieved entry has a zero-length DN. A patch to HEAD is coming. Really there should never have been such a function, tool_entry_get should have been used for this purpose.

1 0

Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by donn＠u.washington.edu 11 Aug '07

11 Aug '07

On Aug 10, 2007, at 2:16 PM, Howard Chu wrote: > donn(a)u.washington.edu wrote: >> Full_Name: Donn Cave >> Version: 2.4.4 >> OS: Red Hat Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (128.95.135.150) >> In "while" loop at 2656, I find old->a_vals are like [..., a, >> b, ...] and >> new->a_vals are like [..., b, a, ...]. >> Matches are found at old [i] == new [k = j+1] and old [k = i+1] == >> new [j], but >> this just shows that neither an add nor a delete is called for, >> and the loop end >> is reached without having incremented i or j. >> Actual attribute values I'm looking at right now in the debugger are >> eduPersonAffiliation: old [ member, alum, employee, faculty ], >> new [ member, >> alum, faculty, employee ]. I built the replica from a slapcat >> dump on the idle >> master, started the slapd syncrepl client and applied a lot of normal >> modifications to the master, until it hit the infinite loop. It >> has been a >> recurrent problem. > > Now fixed in HEAD, please test. Aug 10 15:06:55 rufus03 slapd[31488]: null_callback : error code 0x14 Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101 be_modify (20) Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101 be_modify failed (20) I could put some more research into this, but tell me if this doesn't make sense. Suppose this mysteriously swapped order: a,b,... b,a,... Your fix increments the first list's index, so next iteration it's b,... b,a,... which is fine, but next iteration is ... a,... "a" looks new at this point, and I try to add it, but it isn't new - we just forgot that it was in "old" - and I get error 0x14 (LDAP_TYPE_OR_VALUES_EXISTS) Donn Cave, donn(a)u.washington.edu

1 0

Re: (ITS#5065) out of order ctxcsn from old entryCSN
by hyc＠symas.com 10 Aug '07

10 Aug '07

donn(a)u.washington.edu wrote: > On Aug 10, 2007, at 1:53 PM, Howard Chu wrote: >> You didn't mention how your syncrepl is configured but it seems >> that this can only occur for refreshAndPersist mode, with old >> entries being ldapadd'd to the running master. > > It is indeed refreshAndPersist ... > >> In fact, since entryCSN is NO-USER-MODIFICATION it shouldn't even >> be possible to add entries this way to a running server. Before we >> can "catch the problem in the master" we need more information on >> how the problem was caused. > > The master server had updatedn defined to itself. Changes, logged from > another server, were applied with ldapmodify. "Don't do this" ... You're essentially creating the same inconsistency that a naive multimaster setup introduces. Since 2.4.4 has real multimaster support, you should not be doing things this way. Note that a proper configuration works with either refreshOnly or refreshAndPersist mode, and cascaded to an arbitrary depth. Your current setup only works with refreshAndPersist, and cannot be cascaded reliably. I.e. your setup is inherently broken. -- -- 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#5077) syncrepl.add_cmp() infinite loop on swapped values
by hyc＠symas.com 10 Aug '07

10 Aug '07

donn(a)u.washington.edu wrote: > Full_Name: Donn Cave > Version: 2.4.4 > OS: Red Hat Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.95.135.150) > > > In "while" loop at 2656, I find old->a_vals are like [..., a, b, ...] and > new->a_vals are like [..., b, a, ...]. > > Matches are found at old [i] == new [k = j+1] and old [k = i+1] == new [j], but > this just shows that neither an add nor a delete is called for, and the loop end > is reached without having incremented i or j. > > Actual attribute values I'm looking at right now in the debugger are > eduPersonAffiliation: old [ member, alum, employee, faculty ], new [ member, > alum, faculty, employee ]. I built the replica from a slapcat dump on the idle > master, started the slapd syncrepl client and applied a lot of normal > modifications to the master, until it hit the infinite loop. It has been a > recurrent problem. Now fixed in HEAD, please test. -- -- 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#5065) out of order ctxcsn from old entryCSN
by donn＠u.washington.edu 10 Aug '07

10 Aug '07

On Aug 10, 2007, at 1:53 PM, Howard Chu wrote: > > You didn't mention how your syncrepl is configured but it seems > that this can only occur for refreshAndPersist mode, with old > entries being ldapadd'd to the running master. It is indeed refreshAndPersist ... > > In fact, since entryCSN is NO-USER-MODIFICATION it shouldn't even > be possible to add entries this way to a running server. Before we > can "catch the problem in the master" we need more information on > how the problem was caused. The master server had updatedn defined to itself. Changes, logged from another server, were applied with ldapmodify. Donn Cave, donn(a)u.washington.edu

1 0

Re: (ITS#5065) out of order ctxcsn from old entryCSN
by hyc＠symas.com 10 Aug '07

10 Aug '07

donn(a)u.washington.edu wrote: > Full_Name: Donn Cave > Version: 2.4.4 > OS: RH Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.95.135.150) > > > Old entryCSN values imported into the data from another server, can crash > replicas. > > In loop at top of syncrepl_updateCookie, replica encounters a syncCookie whose > value is less than its matching si_cookieState->cs_val. This breaks out of the > inner loop, and the outer loop, without copying anything into `first', so > slap_queue_csn crashes on the null csn. Both are element 0 of their respective > arrays. I assume it is no surprise that syncCookie takes its value from an > entryCSN attribute. > > To duplicate, add an entry with an explicit entryCSN, with value less than the > current contextCSN. In my case, the entryCSN is of the format without the > `decimal fraction' field, but I doubt that matters. > > I don't want to say OpenLDAP needs to support this, but maybe it would be better > to catch the problem in the master, than crash the replicas. You didn't mention how your syncrepl is configured but it seems that this can only occur for refreshAndPersist mode, with old entries being ldapadd'd to the running master. As you say, this is not a supported mode of operation. New data in the server should always have a new entryCSN as well. In fact, since entryCSN is NO-USER-MODIFICATION it shouldn't even be possible to add entries this way to a running server. Before we can "catch the problem in the master" we need more information on how the problem was caused. As for crashing the replicas - the only sure solution is to patch the code in the replicas - "catching the problem in the master" isn't really a proper solution anyway. -- -- 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#5082
by hyc＠symas.com 10 Aug '07

10 Aug '07

ando(a)sys-net.it wrote: > See also discussion in thread > <http://www.openldap.org/lists/openldap-software/200708/msg00063.html> The fix currently in CVS HEAD is to remove the olcPasswordHash attribute from the olcGlobal entry and move it to the frontendDB entry. -- -- 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#5085) slapo-translucent has wrong Debug message
by ghenry＠OpenLDAP.org 10 Aug '07

10 Aug '07

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Inside: > > translucent_db_destroy > > Debug: > > Debug(LDAP_DEBUG_TRACE, "==> translucent_db_close\n", 0, 0, 0); > > Should be: > > Debug(LDAP_DEBUG_TRACE, "==> translucent_db_destroy\n", 0, 0, 0); > > Probably copy and paste error. > > Correcting. > > Gavin. > > This is missing from RE_23, but obviously not going to be added. There is another error in RE_23 though: Debug(LDAP_DEBUG_TRACE, "==> translucent_init\n", 0, 0, 0); should be translucent_db_init. Will change under this ITS. Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5086) back-bdb bug when add is used with snapshot isolation
by stelios.xx.grigoriadis＠ericsson.com 10 Aug '07

10 Aug '07

Full_Name: Stelios Grigoriadis Version: 2.3.32 OS: Linux, (SLES 10) URL: http://ninikos.freehostia.com/bdb_idl_cache_bug.tar.gz Submission from: (NULL) (194.237.142.7) When using slapd with the snapshot isolation level in DB (version 4.5.20) it is possible that added entries don't appear in subsequent searches. Scenario: A client is adding new information while at the same time another is initiating an LDAP search with the same searchbase as the "parent" of the added information. If the search is executed after the add operation has cleared the IDL-cache but before the changes has been committed, the added entries will not appear in any subsequent searches unless slapd is restarted. The problem is that, in the bdb_idl_insert_key-function, the key is deleted from the IDL-cache but the newly added keys in the database are not yet committed, so clients that re-read the information will not have those updated keys. The solution would be to clear the relevant IDL-cache entries after the changes has been committed. This behaviour is demonstrated by the program cache_test_fork.c which is supplied in bdb_idl_cache_bug.tar.gz along with the slapd configuration. I am currently working on the solution but would greatly appreciate any help from you as I am not nearly as familiar with the code as you are.

1 0

(ITS#5085) slapo-translucent has wrong Debug message
by ghenry＠OpenLDAP.org 10 Aug '07

10 Aug '07

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Inside: translucent_db_destroy Debug: Debug(LDAP_DEBUG_TRACE, "==> translucent_db_close\n", 0, 0, 0); Should be: Debug(LDAP_DEBUG_TRACE, "==> translucent_db_destroy\n", 0, 0, 0); Probably copy and paste error. Correcting. Gavin.

1 0

Re: (ITS#5074) slapo-pcache's proxyattrset does not recognize '1.1' to describe an empty attribute set
by ando＠sys-net.it 10 Aug '07

10 Aug '07

> On Aug 6, 2007, at 6:43 AM, Pierangelo Masarati wrote: >> I believe there's something odd in pcache's current behavior. In >> fact, right now "proxyattrset 0" is already a valid directive, but >> it implies "proxyattrset 0 *", which means all attributes. >> Unfortunately, this seems to only work if no attribute is >> requested, while it fails if a "*" is explicitly requested. > > Ah, I was not aware of this behaviour! I've noticed it from the sources, I don't think it was noted anywhere. >> I've modified the propxycache code in HEAD so that a "1.1" can only >> explicitly appear in a list if it's the only string. An empty >> attribute set is no longer valid, to avoid confusion about the >> meaning of non-explicit attribute sets. A "*" or a "+" can >> explicitly appear in a proxyattrset statement, resulting in the >> expected behavior. Use both to indicate that all attributes are in >> the set. > > Let me confirm, that I should specify "proxyattrset 0 1.1" to match > an empty attribute list, and only an empty attribute list. Will a > '*' than match emptiness as well, or does it only match where there > is some attribute specified by the client? No: you need to specify proxyattrset <#idx> "*" in order to have either nothing or "*" return all attributes. In short, an empty attribute set and "*" are now recognized as equivalent. You need to specify proxyattrset <#idx> "1.1" in order to have searches requesting "1.1", namely no attributes, be cached. > I will work on this as soon as I am able to, although it seems this > won't be for a couple of weeks. I will be in touch. Thanks again > for your work and for your very timely response. Right now, I'm not planning to backport this fix to re23 because it seems to be an enhancement rather than a bugfix, and 2.4 __should be__ just 'round the corner. 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#5074) slapo-pcache's proxyattrset does not recognize "1.1" to describe an empty attribute set
by zep＠ni.enate.org 10 Aug '07

10 Aug '07

On Aug 6, 2007, at 6:43 AM, Pierangelo Masarati wrote: > I believe there's something odd in pcache's current behavior. In > fact, right now "proxyattrset 0" is already a valid directive, but > it implies "proxyattrset 0 *", which means all attributes. > Unfortunately, this seems to only work if no attribute is > requested, while it fails if a "*" is explicitly requested. Ah, I was not aware of this behaviour! > I've modified the propxycache code in HEAD so that a "1.1" can only > explicitly appear in a list if it's the only string. An empty > attribute set is no longer valid, to avoid confusion about the > meaning of non-explicit attribute sets. A "*" or a "+" can > explicitly appear in a proxyattrset statement, resulting in the > expected behavior. Use both to indicate that all attributes are in > the set. Let me confirm, that I should specify "proxyattrset 0 1.1" to match an empty attribute list, and only an empty attribute list. Will a '*' than match emptiness as well, or does it only match where there is some attribute specified by the client? > Please test. I will work on this as soon as I am able to, although it seems this won't be for a couple of weeks. I will be in touch. Thanks again for your work and for your very timely response. -Mike

1 0

ITS#4868
by ando＠sys-net.it 09 Aug '07

09 Aug '07

There remains an issue in back-sql: if a ';binary' attr is used in the filter, and the same attribute is requested with the ';binary' option, the latter is treated as a different attribute, and no value is returned because of sort of a malformed attribute inheritance test. For example, a search requesting 'userCertificate;binary' with a filter '(userCertificate=*)' would return no values for the userCertificate attribute, while if no ';binary' were used, userCertificate values would be returned. I'll commit a fix shortly. 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#5083) LDAP configuration problem
by quanah＠zimbra.com 09 Aug '07

09 Aug '07

--On Thursday, August 09, 2007 12:41 PM +0000 ranju(a)isl-bd.com wrote: > Full_Name: Mohammad nurul Huda > Version: 2.2.13-6.4E > OS: RedHat ES 4.0 Update 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.49.33.141) > > > When we run the following command in the LDAP configuration time it shows > the following error in the time of running below command: Please use openldap-software(a)openldap.org for software usage questions (i.e., I see no bug here). I will also note that OpenLDAP 2.2 is extremely old. I advise upgrading to a current, supported release. The current release is OpenLDAP 2.3.37. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5080) LDAP setup
by quanah＠zimbra.com 09 Aug '07

09 Aug '07

--On Thursday, August 09, 2007 4:29 AM +0000 srinibashudayasingh(a)gmail.com wrote: > Full_Name: srinibash udayasingh > Version: 2.3.7 > OS: red heart linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (61.14.7.138) This is not a bug. Please use openldap-software(a)openldap.org for usage questions. Please upgrade to a recent release before doing so (current release is 2.3.37). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5084) back-ldap does not return if remote server is unreachable
by ando＠sys-net.it 09 Aug '07

09 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando This is HEAD only as of today (re23 as of today works as expected). To reproduce: configure slapd with an ldap database pointing nowhere. p.

1 0

(ITS#5083) LDAP configuration problem
by ranju＠isl-bd.com 09 Aug '07

09 Aug '07

Full_Name: Mohammad nurul Huda Version: 2.2.13-6.4E OS: RedHat ES 4.0 Update 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.49.33.141) When we run the following command in the LDAP configuration time it shows the following error in the time of running below command: # ldapadd -x -D "cn=Manager,dc=<Domain>,dc=com" -W -f /etc/openldap/domain.com.ldif #Enter LDAP passwd: After puuting the ldap password it shows the following error message ldap_bind invalid credential (49) Another issue when i am seeing the log messages it shows the following error sql_select option missing auxprobfunce error no mechanisam available.

1 0

ITS#5082
by ando＠sys-net.it 09 Aug '07

09 Aug '07

See also discussion in thread <http://www.openldap.org/lists/openldap-software/200708/msg00063.html> 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#5082) olcPasswordHash: Scheme not available
by mahashmi＠gmail.com 09 Aug '07

09 Aug '07

Full_Name: Mustafa A. Hashmi Version: 2.3.30 OS: Debian Etch (4.0) URL: Submission from: (NULL) (202.5.145.13) When slapd is initialized to read configuration via cn=config (-F /path/to/slapd.d), configuration directives are read before modules are loaded. This can result in slapd exiting when a configuration option, provided by a specific module, is found before the module is loaded. As an example: the directive password-hash {K5KEY} results in slapd existing with the following message: olcPasswordHash: value #0: <olcPasswordHash> scheme not available ({K5KEY}) olcPasswordHash: value #0: <olcPasswordHash> no valid hashes found config error processing cn=config: <olcPasswordHash> no valid hashes found The smbk5pwd module is loaded at a later stage during the initialization process. Please note: If cn=config.ldif is edited and the option removed, slapd will start normally and allow the option to be added at runtime.

1 0

(ITS#5081) [enhancement] hot startup for pcache?
by ando＠sys-net.it 09 Aug '07

09 Aug '07

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando What about a hot startup for pcache? Right now, if a slapd with a fresh pcache is stopped and restarted, the contents of the cache are ignored since the pcache has no notion of the cached queries. They could be saved (routinely, or at shutdown), in an operational attribute attached to the root entry, to allow hot startup. p.

1 0

(ITS#5080) LDAP setup
by srinibashudayasingh＠gmail.com 09 Aug '07

09 Aug '07

Full_Name: srinibash udayasingh Version: 2.3.7 OS: red heart linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.14.7.138) Hi I am new in open LDAP.i am unable to setup.Last 1 month i am trying to setup.I have follow the steps in openldap.org.I find the following error.Can you please help me to setup.I am using version :2.3.7 and softerra Adminstrative 3.4 tool. <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=0 op=3 p=3 send_ldap_result: err=32 matched="" text="" send_ldap_response: msgid=43 tag=101 err=32

1 0

Re: (ITS#5079) Sourious warnings in slapd-bdb/hdb about missing objectClass at add
by ando＠sys-net.it 08 Aug '07

08 Aug '07

quanah(a)zimbra.com wrote: > CVS log for servers/slapd/back-bdb/search.c > 1.221.2.16 Fri Jul 20 22:42:26 2007 UTC; 2 weeks, 4 days ago by hyc > Branch: OPENLDAP_REL_ENG_2_3 > Changed since 1.221.2.15: +2 -1 lines > Diffs to 1.221.2.15 (colored diff) > > Set e_ocflags on dummy context entry That's for search; I'm seeing it during add. I copied the fix from HEAD, mine differs from that of Howard. Maybe we should converge to a common one... 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs