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 Sebastian,
Can you please follow up to this ITS with an IPR release, as detailed at:
<http://www.openldap.org/devel/contributing.html>
thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Full_Name: Martin Evans
Version: 2.3.37
OS: Linux/fc6
URL: ftp://ftp.openldap.org/incoming/addressbook.c
Submission from: (NULL) (138.37.8.140)
This problem seems similar to the solution suggested for ITS#4038. Id like to
add an attribute to an entry in the result set during a
SLAPI_PLUGIN_PRE_ENTRY_FN callback. According to 4038 the entry should be
dupped. But I cannot free the entry afterwards without problems, and if I dont
do that the server leaks memory at a high rate.
I've left an example plugin in your ftp incoming directory as addressbook.c. The
crucial bit of code is this:
slapi_pblock_get(pb,SLAPI_SEARCH_RESULT_ENTRY,&e0);
cn = slapi_entry_attr_get_charptr(e0, "cn");
DEBUG("found: %s",cn);
/* dup the entry - leaks!! */
e1=slapi_entry_dup(e0);
if (e1==NULL) {
LOG("addressbook_result_entry failed to duplicate entry");
return PLUGIN_STOP;
}
slapi_entry_attr_set_charptr(e1,"telephoneNumber","12345");
/* set the dupped entry as the result */
slapi_pblock_set(pb, SLAPI_SEARCH_RESULT_ENTRY, e1);
/* uncomment this for empty result set, otherwise leaks */
//slapi_entry_free(e1);
/* uncomment this for crash */
//slapi_entry_free(e0);
If I free e1, I get null results via an ldap search (only "dn:" is displayed for
each entry. If I do that there is no leak.
If I free e0 (not sure what handles that after the pblock_set call) the server
crashes.
Kind regards,
Martin.
Full_Name: Howard Chu
Version: 2.1+
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (204.95.127.34)
Submitted by: hyc
The AVA_Sort function hasn't really been touched much since it was written in
December 2001. It appears that it only works for sorting RDNs with two AVAs or
less. With 3 or more, it stops prematurely.
hyc(a)symas.com wrote:
> Dan Cushing wrote:
>> I'd defer to those with more expertise, but my vote is to avoid changing
>> the modifyTimestamp attribute. That attribute should be updated only
>> when an ldapmodify operation is performed.
>>
>> I'm not familiar with the specifications, and perhaps this isn't
>> addressed there. My intuition suggests that it shouldn't be modified by
>> operations that are not directly under the control of the user or
>> administrator.
>
> Already fixed in CVS HEAD and RE23, please test.
I'll note that this change will prevent these operational attributes from being
replicated in many cases. Of course, given that the replication behavior of
these attributes is currently undefined, it may not be a problem right now.
Down the road, I don't know.
--
-- 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/
Dan Cushing wrote:
> I'd defer to those with more expertise, but my vote is to avoid changing
> the modifyTimestamp attribute. That attribute should be updated only
> when an ldapmodify operation is performed.
>
> I'm not familiar with the specifications, and perhaps this isn't
> addressed there. My intuition suggests that it shouldn't be modified by
> operations that are not directly under the control of the user or
> administrator.
Already fixed in CVS HEAD and RE23, 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/
I'd defer to those with more expertise, but my vote is to avoid changing
the modifyTimestamp attribute. That attribute should be updated only
when an ldapmodify operation is performed.
I'm not familiar with the specifications, and perhaps this isn't
addressed there. My intuition suggests that it shouldn't be modified by
operations that are not directly under the control of the user or
administrator.
Dan
Howard Chu wrote:
> dan.cushing(a)netideasinc.com wrote:
>> Full_Name: Dan Cushing
>> Version: 2.3.36
>> OS: Solaris 9
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (71.76.187.82)
>>
>>
>> When running OpenLDAP with the ppolicy overlay, the modifyTimestamp
>> for a user
>> entry is updated if the user attempts to login (bind) with an incorrect
>> password. This is happening because the password lockout feature is
>> enabled and
>> the operational attribute 'pwdFailureTime' is being updated. It
>> seems like this
>> results in a misleading modifyTimestamp. Is it intended that the
>> modifyTimestamp attribute be updated when operational attributes are
>> updated?
>
> Hadn't really thought about it before. We can certainly avoid this
> though.
--
This electronic transmission is strictly confidential to NetIDEAS, Inc.
and intended solely for the addressee. It may contain information, which
is covered by legal, professional, or other privilege. If you are not
the intended addressee, or someone authorized by the intended addressee
to receive transmissions on the behalf of the addressee, you must not
retain, disclose in any form, copy or take any action in reliance on
this transmission. If you have received this transmission in error,
please notify us as soon as possible and destroy this message.
> From: Gavin Henry <openldap-its(a)OpenLDAP.org>
> Date: Fri Jul 13 18:19:25 2007
>
> The same sentance is in slapadd(8)/slapindex(8) too.
That is correct; slapadd/slapindex must never be run while slapd is running.
--
-- 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/
As noted elsewhere, the "-C" option is intentionally undocumented. Since the
command line tools only support anonymous referral chasing, and referral
chasing through untrusted servers is inherently unsafe, it's best not to do it.
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/
dan.cushing(a)netideasinc.com wrote:
> Full_Name: Dan Cushing
> Version: 2.3.36
> OS: Solaris 9
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (71.76.187.82)
>
>
> When running OpenLDAP with the ppolicy overlay, the modifyTimestamp for a user
> entry is updated if the user attempts to login (bind) with an incorrect
> password. This is happening because the password lockout feature is enabled and
> the operational attribute 'pwdFailureTime' is being updated. It seems like this
> results in a misleading modifyTimestamp. Is it intended that the
> modifyTimestamp attribute be updated when operational attributes are updated?
Hadn't really thought about it before. We can certainly avoid this though.
--
-- 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/
<quote who="hyc(a)symas.com">
> ando(a)sys-net.it wrote:
>> ghenry(a)suretecsystems.com wrote:
>>> <quote who="hyc(a)symas.com">
>>>> ghenry(a)OpenLDAP.org wrote:
>>>>> Full_Name: Gavin Henry
>>>>> Version: HEAD
>>>>> OS:
>>>>> URL: ftp://ftp.openldap.org/incoming/
>>>>> Submission from: (NULL) (80.229.93.1)
>>>>> Submitted by: ghenry
>>>>>
>>>>>
>>>>> Dear All,
>>>>>
>>>>> It's not clear or explained what AVA means in slapd-meta(5) and
>>>>> slapo-rwm(5)
>>>> Standard terminology in X.500/LDAP. "Attribute Value Assertion"
>>>>> A user was asking in #ldap
>>>>>
>>>>> I presume it means "Attribute Value"?
>>>>>
>>>>> If so, I will add an explaination in each man page.
>>>> OpenLDAP docs are not intended to explain the basics of LDAP. You're
>>>> expected
>>>> to already know LDAP or refer to the RFCs for basic terminology.
>>> Closing ITS.
>>
>> In any case, expanding acronyms when first used sounds "polite"; any
>> further reference to the most appropriate RFC should allow newbie
>> readers to learn more.
>
> Perhaps, in the Admin Guide.
We have it in preamble.sdf already, so I think this is covered.
> But in the man page? Where do you draw the line?
> Do we have to start every man page with e.g. "the meta backend to slapd
> (the
> Standalone LDAP (Lightweight Directory Access Protocol) Daemon) performs
> basic
> LDAP proxying..." ?
>
> In this case, what good would it do? Would someone who hasn't read any
> RFCs
> know what "Attribute Value Assertion" means? Anyone who doesn't understand
> the
> X.500 information model has no business administering slapd. They need to
> absorb that basic groundwork first, and IMO manpages are not the mechanism
> for
> teaching that.
> --
> -- 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/
>
>
>
ando(a)sys-net.it wrote:
> ghenry(a)suretecsystems.com wrote:
>> <quote who="hyc(a)symas.com">
>>> ghenry(a)OpenLDAP.org wrote:
>>>> Full_Name: Gavin Henry
>>>> Version: HEAD
>>>> OS:
>>>> URL: ftp://ftp.openldap.org/incoming/
>>>> Submission from: (NULL) (80.229.93.1)
>>>> Submitted by: ghenry
>>>>
>>>>
>>>> Dear All,
>>>>
>>>> It's not clear or explained what AVA means in slapd-meta(5) and
>>>> slapo-rwm(5)
>>> Standard terminology in X.500/LDAP. "Attribute Value Assertion"
>>>> A user was asking in #ldap
>>>>
>>>> I presume it means "Attribute Value"?
>>>>
>>>> If so, I will add an explaination in each man page.
>>> OpenLDAP docs are not intended to explain the basics of LDAP. You're
>>> expected
>>> to already know LDAP or refer to the RFCs for basic terminology.
>> Closing ITS.
>
> In any case, expanding acronyms when first used sounds "polite"; any
> further reference to the most appropriate RFC should allow newbie
> readers to learn more.
Perhaps, in the Admin Guide. But in the man page? Where do you draw the line?
Do we have to start every man page with e.g. "the meta backend to slapd (the
Standalone LDAP (Lightweight Directory Access Protocol) Daemon) performs basic
LDAP proxying..." ?
In this case, what good would it do? Would someone who hasn't read any RFCs
know what "Attribute Value Assertion" means? Anyone who doesn't understand the
X.500 information model has no business administering slapd. They need to
absorb that basic groundwork first, and IMO manpages are not the mechanism for
teaching that.
--
-- 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/
ghenry(a)suretecsystems.com wrote:
> <quote who="hyc(a)symas.com">
>> ghenry(a)OpenLDAP.org wrote:
>>> Full_Name: Gavin Henry
>>> Version: HEAD
>>> OS:
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (80.229.93.1)
>>> Submitted by: ghenry
>>>
>>>
>>> Dear All,
>>>
>>> It's not clear or explained what AVA means in slapd-meta(5) and
>>> slapo-rwm(5)
>> Standard terminology in X.500/LDAP. "Attribute Value Assertion"
>>> A user was asking in #ldap
>>>
>>> I presume it means "Attribute Value"?
>>>
>>> If so, I will add an explaination in each man page.
>> OpenLDAP docs are not intended to explain the basics of LDAP. You're
>> expected
>> to already know LDAP or refer to the RFCs for basic terminology.
>
> Closing ITS.
In any case, expanding acronyms when first used sounds "polite"; any
further reference to the most appropriate RFC should allow newbie
readers to learn more.
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
---------------------------------------
igbed(a)wmin.ac.uk wrote:
> Full_Name: Damian Igbe
> Version: 2.3.6
> OS: SLES 10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (161.74.11.24)
>
>
> I have a delta-syncrepl replication working with password policy in place.
> Authentication to the master works fine but when a client tries to authenticate
> to the replica server, the following bug is encountered and the system crashes.
There is not enough information in this bug report. Please include a copy of
your slapd.conf from the replica, and a copy of your password policy. Please
also show the LDAP request that was issued when the crash occurred.
--
-- 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/
ali.pouya(a)free.fr wrote:
> h.b.furuseth(a)usit.uio.no wrote :
>
>> That's from ITS#4975: The code was broken for builds without TLS.
>> It's been fixed in HEAD. Does it work now?
>
> Hi Hallvard,
> Yes I confirm that the problem with TLS compilation is fixed now.
>
> But the main problem of this ITS still remains (replica seg faults if syncrepl
> searchbase ="").
>
> Sorry for this late answer.
> Best regards
> Ali
If the current HEAD still crashes for you, please attach your slapd.conf files
in a followup to this ITS, thanks.
--
-- 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/
ali.pouya(a)free.fr wrote:
> Unfortunately the problem has not been completely fixed in the HEAD.
> With the fix in the head the error message disappears but the contextCSN ins NOT
> ACTUALLY written to the disk. So at the next slapd startup the ContextCSN is
> missing. An the servers hav to resynchronize.
In fact the contextCSN was getting written out, but not getting read back in on
the next startup. This should now be working 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/
dhawes(a)vt.edu wrote:
> On Thursday 19 July 2007 17:18, ghenry(a)suretecsystems.com wrote:
>> <quote who="dhawes(a)vt.edu">
>>
>>> On Thursday 19 July 2007 05:35, Gavin Henry wrote:
>>>>> An updated version of addpartial is available at:
>>>>>
>>>>> ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz
>>>>>
>>>>> This version includes changes to work with OpenLDAP 2.3 as well as
>>>>> ensuring syncrepl works properly.
>>>>>
>>>>> david hawes
>>>> If this hasn't been added to 2.4/HEAD yet, would you consider updating
>>>> it
>>>> for inclusion in 2.4 contrib?
>>> Absolutely, I've been meaning to test with 2.4. I'll bump it to the top
>>> of
>>> the list.
>> Can you make sure that is dynamically configurable via cn=config like
>> everything else in 2.4.
>>
>> Thanks.
>
> I have tested the overlay at
> ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz, and it
> works with 2.4.4alpha, including dynamic loading via cn=config.
>
> Apart from using "overlay addpartial", there is no slapd configuration for
> addpartial. I believe this means it doesn't need its own schema to work
> correctly. Please correct me if I am wrong about this.
That's correct. If there was no config needed under the old mechanism, then
none is needed with the new either.
--
-- 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/
On Thursday 19 July 2007 17:18, ghenry(a)suretecsystems.com wrote:
> <quote who="dhawes(a)vt.edu">
>
> > On Thursday 19 July 2007 05:35, Gavin Henry wrote:
> >> > An updated version of addpartial is available at:
> >> >
> >> > ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz
> >> >
> >> > This version includes changes to work with OpenLDAP 2.3 as well as
> >> > ensuring syncrepl works properly.
> >> >
> >> > david hawes
> >>
> >> If this hasn't been added to 2.4/HEAD yet, would you consider updating
> >> it
> >> for inclusion in 2.4 contrib?
> >
> > Absolutely, I've been meaning to test with 2.4. I'll bump it to the top
> > of
> > the list.
>
> Can you make sure that is dynamically configurable via cn=config like
> everything else in 2.4.
>
> Thanks.
I have tested the overlay at
ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz, and it
works with 2.4.4alpha, including dynamic loading via cn=config.
Apart from using "overlay addpartial", there is no slapd configuration for
addpartial. I believe this means it doesn't need its own schema to work
correctly. Please correct me if I am wrong about this.
Thanks,
dave
On Jul 20, 2007, at 3:31 PM, Howard Chu wrote:
> pturgyan(a)umich.edu wrote:
>> Full_Name: Paul Turgyan
>> Version: 2.3.35
>> OS: linux 2..6.18 from source URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (141.213.231.171)
>> When calling ldap_add_result_entry with an empty list or when
>> starting a new
>> list, ldap_add_result_entry crashes
>> with a SEGFAULT at line 67.
>> Here is a patch:
>
> A different fix is now 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/
Works for me! Thanks.
pturgyan(a)umich.edu wrote:
> Full_Name: Paul Turgyan
> Version: 2.3.35
> OS: linux 2..6.18 from source
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (141.213.231.171)
>
>
> When calling ldap_add_result_entry with an empty list or when starting a new
> list, ldap_add_result_entry crashes
> with a SEGFAULT at line 67.
>
> Here is a patch:
A different fix is now 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/
Full_Name: Paul Turgyan
Version: 2.3.35
OS: linux 2..6.18 from source
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (141.213.231.171)
When calling ldap_add_result_entry with an empty list or when starting a new
list, ldap_add_result_entry crashes
with a SEGFAULT at line 67.
Here is a patch:
*** addentry.c Tue Jan 2 16:43:48 2007
--- addentry.c+ Fri Jul 20 13:48:41 2007
***************
*** 64,69 ****
--- 64,72 ----
assert( e != NULL );
e->lm_chain = *list;
+ if (*list)
e->lm_chain_tail = (*list)->lm_chain_tail;
+ else
+ e->lm_chain_tail = NULL;
*list = e;
}
<quote who="hyc(a)symas.com">
> ghenry(a)OpenLDAP.org wrote:
>> Full_Name: Gavin Henry
>> Version: HEAD
>> OS:
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (80.229.93.1)
>> Submitted by: ghenry
>>
>>
>> Dear All,
>>
>> It's not clear or explained what AVA means in slapd-meta(5) and
>> slapo-rwm(5)
>
> Standard terminology in X.500/LDAP. "Attribute Value Assertion"
>>
>> A user was asking in #ldap
>>
>> I presume it means "Attribute Value"?
>>
>> If so, I will add an explaination in each man page.
>
> OpenLDAP docs are not intended to explain the basics of LDAP. You're
> expected
> to already know LDAP or refer to the RFCs for basic terminology.
Closing ITS.
>
> --
> -- 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/
>
>
>
quanah(a)zimbra.com wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.3.34
> OS: NA
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (71.202.148.128)
>
>
> If a database has a zero-length suffix, the NULL context entry gets an entry ID
> of zero, which is usually an invalid ID number and always omitted from indexing.
> But it looks like with slapadd -q, it is possible for this entry to get
> included in various indices, which will totally confuse them.
>
> (per Howard)
I actually filed this already instead of waiting for you (ITS#5052). A patch is
already in HEAD for testing. 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/