Re: (ITS#6160) slapadd man page doesn't note indexing
by quanah＠zimbra.com
--On Friday, June 05, 2009 9:25 PM +0100 Gavin Henry
<gavin.henry(a)gmail.com> wrote:
> Is there a SEE ALSO?
>
> Will check and amend.
Regardless of SEE ALSO, it should note that it indexes the database while
adding it. ;)
SEE ALSO
ldap(3), ldif(5), slapcat(8), ldapadd(1), slapd(8)
Should probably have slapindex in the SEE ALSO as well.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 6 months
(ITS#6160) slapadd man page doesn't note indexing
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.16
OS: NA
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.29.239)
The man page for slapadd does not note that it also performs indexing while
adding the database. While this is fairly obvious to those of us experienced
with using OpenLDAP, it is non-obvious to new users.
14 years, 6 months
Re: (ITS#6157) unAbandonable operations aren't.
by h.b.furuseth＠usit.uio.no
Caught cancel(cancel) and cancel/abandon(abandon/bind/unbind),
partly fixed cancel(cn=config update) problem, without doing this:
> Suggested partual fix - add this possible value for o_cancel:
> #define SLAP_CANCEL_INVALID 0x04 /* like 0 but prevents Cancel */
Still need something that to fix cancel(cn=config update) completely.
syncrepl/syncprov, starttls not yet addressed.
Also cancel(cancel) still behaves in a non-RFC way. Correct fix
would require resetting o_abandon, which seems unsafe. Who knows
what has already reacted to it.
Will update this patch for the remaining issues later:
> Something like this:
> http://folk.uio.no/hbf/OpenLDAP/cancel-cancel.txt
--
Hallvard
14 years, 6 months
Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by hyc＠symas.com
Howard Chu wrote:
> Andrew Bartlett wrote:
>> I agree, we might be jumping at different shadows here, but your patches
>> did fix something...
>
> I see what you're describing now, with the kvm set with 2 CPUs. It appears to
> be a bug caused by the recent patch for connection_hangup() processing.
> Running slapd with -d15 in your test shows that a connection is closed shortly
> after being established and becoming readable. The bug is (probably) that we
> queued the reader but processed the hangup immediately, thus closing the
> connection before the reader executes. I'm not exactly sure why this is
> causing the problem on your test, since it looks like your client is closing
> the socket before waiting for the reply. But certainly this is the right area.
>
With the connection problem out of the way, the remaining slapd crash appeared
to be due to some type of heap corruption, but the usual suite of tools
(valgrind, efence, LBER_MEMORY_DEBUG, etc.) didn't ever reproduce the problem.
On the assumption that this was related to a stack overwrite I recompiled
libldap_r with a 12MB stack size instead of the default 8MB and that still
didn't change the outcome. On the assumption that there was some other race
condition involved, I set slapd to only 2 threads (from default of 16) to try
and limit the possibilities there. This caused the crash to occur much more
quickly, and using libumem it became obvious that refint was accessing
already-freed memory.
So it turns out that the patch for rev 1.41 (ITS#5428) to make this into a
global overlay was incorrect; it moved the loop that processed its work queue
into a new function so that it could be called multiple times, but it was
still using that code basically as-is, which freed its queue as it operated.
(Because originally the queue was only walked once.) Part of the reason the
bug was so hard to reproduce is because it tended to only show up when the
queue got fairly long, and that only happened if slapd was too busy. (Thus,
forcing only 2 threads made it occur sooner.)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 6 months
Re: (ITS#6152) proxycache enhancements
by mhardin＠symas.com
On Jun 4, 2009, at 9:15 AM, masarati(a)aero.polimi.it wrote:
> Just in case, before it becomes totally incompatible with HEAD code, I
> have a patch I never committed, it's about making pcache admin-
> friendly if
> it makes any sense.
>
> It adds:
>
> - a (persistent) counter that reports, for each query, how many
> times it
> evaluated to answerable
That's very useful. Any thoughts about how to determine pcache's
overall 'hit rate'?
>
>
> - "proxycache-" prefixed statements are passed to the private
> database.
> This allows to avoid ambiguities when applying general database
> directives
> in slapd.conf. In fact, it is not clear whether they apply to the
> proxy
> database or to the cache database.
Also useful.
>
>
> If they make sense, I'd like to commit them before slapo-pcache
> enhancement begins.
I agree.
>
>
> p.
>
>
>
-Matt
14 years, 6 months
Re: (ITS#6152) proxycache enhancements
by masarati＠aero.polimi.it
Just in case, before it becomes totally incompatible with HEAD code, I
have a patch I never committed, it's about making pcache admin-friendly if
it makes any sense.
It adds:
- a (persistent) counter that reports, for each query, how many times it
evaluated to answerable
- "proxycache-" prefixed statements are passed to the private database.
This allows to avoid ambiguities when applying general database directives
in slapd.conf. In fact, it is not clear whether they apply to the proxy
database or to the cache database.
If they make sense, I'd like to commit them before slapo-pcache
enhancement begins.
p.
14 years, 6 months
Re: (ITS#6152) proxycache enhancements
by mhardin＠symas.com
On a related note, any solution using pcache for disconnected
operation should also be able to cache bind operations. This is a
digest of a conversation I had with Howard about that:
Currently pcache always forwards binds to the db beneath it. These
will fail in disconnected cases. One solution is to give the pcache
identity read privs to the userpassword, but for security and design
reasons that won't fly in most installations. Another solution is to
add bind caching to pcache, and that is what is described below.
Bind caching functionality can be integrated with pcache, provided
that we can meet some conditions:
1. Guarantee that the object being bound against is already in pcache
when it passes the bind through.
2. Have an attribute in the cached object where pcache can store a
hashed version (e.g. SSHA) of the password it got from the user and
verified against the underlying database. Remember that we must verify
it against the underlying db before we can write it to cache.
Most applications performing LDAP authentication will first search for
the object to which they're intending to bind. This will cause
condition (1) to be satisfied, but this is not good enough because it
is not guaranteed that all applications will first search for the
object to which they're binding- some applications build the bind DN
'blindly' using string substitution rules or even hard-coded bind DNs.
This is wrong, but it's the way things are. Therefore, pcache itself
should search for the object being being bound to and populate the
cache with the search result. The details of how the object is added
to the cache remain to be determined.
Satisfying (1) provides the opportunity to construct an proxyattrset
that includes a (possibly dummy) attribute in which the hashed
validated password can be stored, thus satisfying condition (2). The
userPassword attribute can probably be used most of the time for this,
since it will either be returned form the server either empty or with
a value of '*'. The "do bind caching directive" might refer to a
proxyattrset constructed for this purpose.
Bind caching will interact with TTR, but the details are as yet
undetermined.
To round out the solution, we should also process pwdModify exops as
follows:
For pwdModify exops, pcache would could operate as a 'write-through'
cache, first making sure the object in the cache is current. If the
write-through to the underlying database succeeds, then the object in
the cache is also updated. Otherwise the exop fails and any cached
copy is left unaltered.
-Matt
Matthew Hardin
Symas Corporation - The LDAP Guys
http://www.symas.com
14 years, 6 months
Re: (ITS#6158) syncprov: assert causing slapd to core dump
by quanah＠zimbra.com
--On Wednesday, June 03, 2009 7:22 AM +0000 jonathan(a)phillipoux.net wrote:
> Will this patch make it into RE23 for a possible maintenance release of
> 2.3?
There will be no further releases of OpenLDAP 2.3. You should at this
point be working on migrating to the OpenLDAP 2.4 release.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 6 months
Re: (ITS#6157) unAbandonable operations aren't.
by h.b.furuseth＠usit.uio.no
Suggested partual fix - add this possible value for o_cancel:
#define SLAP_CANCEL_INVALID 0x04 /* like 0 but prevents Cancel */
Something like this:
http://folk.uio.no/hbf/OpenLDAP/cancel-cancel.txt
Does not reject abandon(Cancel/StartTLS), would need to extend o_cancel
with yet another value. That's ugly enough already, so I let that wait.
connection_abandon() in particular isn't invalid client action, but it
shouldn't be worse than causing a surprising result code or not response
before closing the connection.
Does not address syncprov's Cancel handler.
I don't know if the bconfig.c pathces are correct, but need to reject
cancel before (reacting to) thread pool pauses there and maybe in
syncrepl/syncprov.
--
Hallvard
14 years, 6 months
