Handling bad cn=config updates
by Hallvard B Furuseth
If I modify olcDbDirectory of a BDB database to a broken directory, the
Modify returns success but BDB says "failed to reopen database" and
slapd shuts down. Maybe other modifications can shut down slapd too, I
don't know.
It would be nice if slapd tried to restore the old config value, reopen
the old directory, and return unwillingToPerform or something to the
Modify. However I don't know how hard that would be, or how obscure a
case it is.
For that matter, maybe if the Modify broke something it could return
some diagnosticMessage. Not sure if it should return non-success since
that supposedly means the modify did not happen. Though clients may not
display the diagnosticMessage if it comes with 'success'.
--
Hallvard
15 years, 11 months
Re: commit: ldap/servers/slapd/back-bdb config.c
by Pierangelo Masarati
> Check DB directory validity at config time
Of course, there's no guarantee the directory will exist and be writable
when really needed ;) Just wanted to note it, I understand it should be
considered as likely as someone running rm -rf on the database directory
while slapd is running...
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
---------------------------------------
15 years, 11 months
Move LDAP_DEVEL features into 2.4?
by Pierangelo Masarati
I have few enhancements that could go into 2.4 based on consensus.
- BDB_MONITOR_IDX: monitor missing indices in searches. Let me remember
that this feature allows to monitor (thru cn=Monitor) how many search
candidate selections missed an index, and what index type. It costs a
mutex lock/unlock for each call to bdb_index_param().
- pcache private database access: add a control and an exop that allow
access to the private database for administrative/monitoring purposes,
and consistent cached query removal (namely: removal of a specific query
and related queryID from participating entries; removal of an entry and
invalidation of all related queries, ...)
Please comment.
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
---------------------------------------
15 years, 11 months
Monitoring slapd entities...
by Pierangelo Masarati
What back-monitor does in many cases is monitoring entities living
inside slapd. In those cases, the living entity and back-monitor's
entry should be in touch with each other to account for reciprocal
updating. The flow of information, so far, has been handled in one
direction by providing a neutral interface (actually, two):
- the per-subsystem hooks
- the callbacks
Callbacks are much more general than per-subsystem hooks. I think
per-subsystem stuff should be eliminated, as they basically duplicate
callbacks with less flexibility.
However, I believe bi-directional communication could make many things
much easier.
Let's think what operations may require either direction: back-monitor
needs to be able to ask living entries information when it is asked to
present entries (e.g. in response to a search). For this purpose, the
current callback mechanism should be sufficient.
However, living entities may need to contact back-monitor for many
purposes: to register new callbacks, to add/remove themselves to/from
back-monitor. For this latter purpose, a solution could be to augment
all living entities with a pointer to their entry in back-monitor. This
pointer should be set by back-monitor as soon as that entry is created.
This would ease feature registration by acting as a key (the caller
would finally know the real DN of its entry), rather than figuring out a
mechanism to locate it as it is currently done by the
monitor_back_register_* calls. Basically, BackendInfo, BackendDB,
overlay_info and overlay_inst would need an (Entry * (*)_monitor) to
their entry in back-monitor, to be mostly used as a key when calling
monitor-related functions. Other structures in the future may need it,
but the interface would be general enough to allow extensions. Comments?
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
---------------------------------------
15 years, 11 months
ITS#4787: Download links with version vs. date
by Michael Ströder
Hope it's ok to take this to openldap-devel.
Kurt Zeilenga wrote:
> ITS#4787: requests change in "stable" release naming. More discussion
> needed. (I oppose making this change for various reasons).
What are these "various reasons"?
Ciao, Michael.
15 years, 11 months
New performance numbers
by Howard Chu
Back in May 2006 we posted some authentication rate numbers for Symas CDS
3.3.2 (based on OpenLDAP 2.3.21.) http://connexitor.com/blog/pivot/entry.php?id=49
On a 1 million entry database, we saw about 13K auths/second on a dual
processor 2.8GHz Opteron system.
We've recently re-run the tests using OpenLDAP 2.4.5 on a dual processor
2.8GHz dual-core Opteron system (so, 4 cores now instead of just 2) and gotten
38K auths/second. One interesting thing to note is that we reached this same
rate on back-bdb, with the slapd server at 100% CPU utilization, as well as
with back-null, where slapd was only at 70% CPU. (This implies to me that
there may have been a network bottleneck here, because we ought to have been
able to drive slapd into 100% CPU usage even with back-null. Even gigabit
ethernet has its limits...)
But the other nice point about this result is that while the number of CPU
cores was increased by a factor of 2, the overall auth rates increased by a
factor of 2.7. So we can see that OpenLDAP 2.4 is at least 35% faster than
OpenLDAP 2.3. It also shows that the lightweight dispatcher is still scaling
well with available CPU power.
Another point is the same thing I've harped on before - SLAMD is too
inefficient on clients. We measured the 38K/sec rate using the slapd-auth C
client that I just added to CVS HEAD. Using the SLAMD java client we could
only reach 29K/sec, even with 12 client machines and 10 threads per client.
Someone's going to have to sit down and write a C client that speaks the SLAMD
server protocol and just fires off compiled C clients...
--
-- 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/
15 years, 11 months
Re: #15646 BerkeleyDB hybrid mutexes
by Howard Chu
Keith Bostic wrote:
> On Oct 9, 2007, at 12:02 AM, Howard Chu wrote:
>
>> With a CPU-hog running in the background, the test with BDB 4.2.52
>> takes only 37 seconds, while BDB 4.6.21 takes 1:42. Watching with
>> top you can see that BDB 4.6.21 gets a lot less CPU than BDB
>> 4.2.52. This is the problem with using yield() on an NPTL system -
>> whereas on most POSIX systems yield() only yields control to some
>> other thread in the current process, on NPTL yield() gives up the
>> CPU for the entire process.
>
> Is there a call that would be preferable on NPTL?
>
> What call on NPTL will only yield control from the thread, not the
> entire process?
When we first encountered this problem in the OpenLDAP source we used select()
with a zero timeout. But I recall that that performed poorly as well, and
nowadays we just avoid doing any type of yield at all. I think the real answer
here is that on Linux 2.6 you really just want to use the native mutex
(pthread, futex, whatever it's called) and not do anything else.
--
-- 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/
15 years, 11 months
back-ldap connection caching
by Howard Chu
After running SLAMD against back-ldap I've noticed some problems in the
approach - while a single load generator may send multiple requests over a
single connection, back-ldap always creates new connections for each incoming
Simple Bind, and leaves them available to be shared by other sessions.
Thinking about it, this usage doesn't really make a lot of sense. Any identity
that's explicitly binding to back-ldap is necessarily going to be different
from any other session's ID. The only sessions that it makes sense to share
are those that were implicitly bound because they were authenticated
elsewhere, and fell into this backend (via glue, typically) while processing
some other request.
So I think this means we should separate out the explicitly bound connections
from everything else. They should only live as long as their inbound slapd
connection lives, and should only be used by ops from their inbound slapd
connection.
--
-- 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/
15 years, 11 months
slapo-memberof nested group behavior
by Faraz Khan
Dear all,
i know that nested groups have been discussed in detail before- just
wanted to know what the priority of implementing nested groups through
slapo-memberof or otherwise is. The functionality already discussed is:
If A memberof B and C memberof A then C memberof B
Functionality required would be that the memberof attribute handles
recursion correctly. The administrative importance of this
functionality cannot be emphasized more upon.
I am willing to help out with the slapo-memberof module if the
functionality can be built into the current overlay only. Pointers on
how to accomplish this would be appreciated.
--
Faraz R Khan
Chief Architect
Emergen Consulting Pvt Ltd
+92.21.111.111.320 x200
www.emergen.biz
15 years, 11 months
