dITStructureRules/nameForms in subschema subentry for informational purpose
by Michael Ströder
HI!
Discussed this very briefly with Howard at LDAPcon 2007 based on an idea
of Steve:
Support for dITStructureRules and nameForms is still in OpenLDAP's TODO.
In the meanwhile slapd could accept definitions for both in slapd.conf
and simply pass them on to a schema-aware LDAP client for informational
purpose without enforcing them. Same function like rootDSE <file> in
slapd.conf.
Opinions?
Ciao, Michael.
--
Michael Ströder
E-Mail: michael(a)stroeder.com
http://www.stroeder.com
14 years, 2 months
Re: thread pools, performance
by Howard Chu
Rick Jones wrote:
> There are definitely interrupt coalescing settings available with tg3-driven
> cards, as well as bnx2 driven ones:
>
> ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt
Yep, that helped. Raising rx-usecs from default 20 to 1000, and rx-frames from
default 5 to 100, I'm getting 43k auths/sec with back-null (in 4 separate
thread pools) and the core fielding the interrupts is only about 80% busy now
instead of 100%. I'm afraid my load generators may be maxed out now, because I
can't seem to drive up the load on the server any higher even though there's
more idle CPU.
The current code in HEAD (with only 1 thread pool) is reaching 36k auths/sec
with back-null, so it's actually not far off from my experimental peak rate.
Considering that HEAD was at 25k/sec last week (and now in 2.4.6) that's
pretty decent.
With back-bdb and 1 million users I'm getting 26.1k/sec with plaintext
passwords (up from 19.3k/sec last week). With {SSHA} passwords that drops to
25.7k/sec (~1.5% difference).
I have to put this tinkering on hold for a bit, to run some authrate tests
against ActiveDirectory on this machine (using W2K3sp2 X64). Later on we'll do
a W2K3 OpenLDAP build for comparison as well. Should be entertaining...
--
-- 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, 3 months
'monitoring disabled' message
by Hallvard B Furuseth
RE24 slapadd complains:
bdb_monitor_db_open: monitoring disabled; configure monitor database to enable
I prefer slapadd to be silent unless there is something wrong.
"database monitor" in slapd.conf shuts it up (which makes the message
misleading, first I thought I had done --disable-monitor).
But is there some reason why one ought to add database monitor to
slapd.conf? Where is it documented?
--
Hallvard
15 years, 5 months
Empty DN ("") String Value?
by Marc Boorshtein
I wanted to get an opinion from the other java ldap projects. Should
the toString() method of a class that represents a DN return null or
an empty string? I would think an empty string but JLDAP returns
null. Anyone have an opinion on the matter?
Thanks
Marc
15 years, 5 months
LDAP/Samba 4 summary
by Andrew Bartlett
(please forgive the cross-posting to subscriber-only lists)
Howard Chu helpfully wrote up this summary of the meeting we held at the
CIFS Workshop on how Samba4 should work with an LDAP backend.
The background is that Samba4 increasingly needs some things that an
LDAP server could provide for us. In the short term, we need to add
subtree renames to ldb_tdb, but OpenLDAP's hdb already provides this for
us.
Likewise, we have a desperate need for replication (because any site in
need of Samba4's features will want multiple DCs) - and Fedora DS's
replication seems like a very good, solid answer. (Sadly it doesn't
give us subtree renames...).
Another feature we don't yet do schema validation in Samba4, beyond
checking that the objectClass list is valid. We need to extend that,
but perhaps the LDAP server could do that validation for us?
Finally, in the long term, we would like to have Samba4 play nice in a
multi-use directory, and this presents a schema mapping problem. We
agreed to get together and try and work out a schema that is compatible
to Microsoft's extensions, without being too painful to see from a
traditional client. I hope to put together a discussion on this in the
near future.
I expect we will continue to use and support ldb_tdb as a backend on
Samba4, but for some features (which they will want), users should be
directed to use LDAP as an important backend.
Andrew Bartlett
-------- Forwarded Message --------
From: Howard Chu <hyc(a)symas.com>
To: OpenLDAP-devel(a)openldap.org
Subject: [Fwd: LDAP/Samba 4 summary]
Date: Fri, 28 Sep 2007 10:42:22 -0700
Yesterday afternoon at the CIFS Workshop we had a meeting to discuss Samba 4's use
of LDAP going forward, and what obstacles remained. Among the attendees that I can
remember were Andrew Bartlett, Andrew Tridgell, Simo Sorce, Stefan Metzmacher, and
(one more, I've forgotten the name) from the Samba team. Nicole Jacque and another
(sorry, don't remember the name) from Apple/OpenDirectory, Pete Rowley from
FedoraDS, and myself and Marty Heyman for OpenLDAP and Symas.
The upshot is that both the Samba and the LDAP sides have work to do, but there
are no major roadblocks. LDAP will be Samba 4's default/recommended data store. As
for OpenLDAP, most of what Samba 4 needs is either already implemented, or in
progress.
Schema design tends to still be a stumbling block; in a separate conversation we
discussed some design issues in MIT's new Kerberos schema as well as missing
features in Heimdal's existing Kerberos schema. That's a bit outside this
openldap-devel scope but I've committed to working with the Samba and Kerberos
communities to draft some changes to unify these two Kerberos schemas.
-------- Forwarded Message --------
From: Howard Chu <hyc(a)symas.com>
To: Andrew Bartlett <abartlet(a)samba.org>
Subject: LDAP/Samba 4 summary
Date: Thu, 27 Sep 2007 22:41:23 -0700
Missing features / wishlist
bitwise ops.
already in OpenLDAP, recently added to FedoraDS(?)
USNs
partially implemented in OpenLDAP, need more complete spec
LDAP Transaction support
draft-zelenga-ldap-txn - partially implemented in OpenLDAP
some concerns because Samba's definition of transaction is
not the
canonical ACID definition. More like ACI, no Durability
guarantee, doesn't
play well with LDAP Multimaster Replication. We all agreed that
if Samba
doesn't care, neither do we. All that matters is that it
provides tidy,
painless rollback in event of intermediate failures.
Access Controls
my suggestion re: OpenLDAP - we support modular ACL
engines, we should
just write a module for native NT ACLs in OpenLDAP
AD schema - we agreed that a new schema is necessary no
matter how you
slice it, we will all collaborate to define a superset of AD
that everyone can
support.
Authentication mechanisms - generally Samba will handle this
itself
validation - Samba4 + LDAP must pass everything under Samba's
"make test"
suite.
Transactions again - we may need things like memberOf and
other linked
attributes to be managed internally in the server. No problem,
both OpenLDAP
and FDS have memberOf plugins already available.
Subtree renames - MS tools assume subtree renames work.
Supported in
OpenLDAP already (back-hdb, back-ldif, will be in back-tdb).
Unfortunately not
supported in FedoraDS, might be able to kludge it, but it will
require
additional mapping layers. And kludging will break base-scope
searches,
referential integrity, etc...
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
15 years, 5 months
ordered indexing for integers
by Howard Chu
I was looking at adding support for ordered indexing for Integer attributes.
This would be an incompatible format change for index databases. In fact I'd
need to change the Presence index key as well, so it would affect all index
databases, not just those for Integer attributes.
Currently the Presence index uses a hardcoded 4 byte key of 0x00000001. I want
to change it to a 2 byte key of 0x0000 instead, to prevent it from colliding
with the Integer key space.
So far, 2.4 and 2.3 have totally identical database formats. Is it worthwhile
to break this compatibility to gain this feature, or better to preserve
compatibility and ignore this feature for now? Any thoughts on going ahead
with it here in RE24?
--
-- 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, 5 months
Re: Please test RE_24
by Gavin Henry
<quote who="Quanah Gibson-Mount">
> I've sync'd it up with everything I'm aware of as being pending in
> preparation for getting 2.4.7 out this week. Please test.
Passes ok on F8 i386.
>
> Thanks!
>
> --Quanah
>
>
>
15 years, 5 months
Re:
by Quanah Gibson-Mount
--On November 28, 2007 2:34:55 PM -0600 "HORSTMAN, MARK A (ATTSI)"
<mh2620(a)att.com> wrote:
> I apologize for mailing your directly, but I didn't think this belonged
> on the openldap-devel(a)openldap.org list. I read the 'Subject: Please
> test RE_24' thread. Is there a place where one might read release notes
> for 2.4.7?
Please don't email me off the list.
There are no release notes currently for OpenLDAP 2.4.7, as it hasn't been
released. That's the point of asking for people to test RE24. If you are
asking about the CHANGES, you can read them out of CVS for the branch,
either via the online CVSWeb at http://www.openldap.org, or by using cvs to
check them out from the repository.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 6 months
Re: ldapsearch on local attributes with slapo-translucent
by Gavin Henry
<quote who="Howard Chu">
> Gavin Henry wrote:
>> Julien Garnier wrote:
>>> Gavin Henry a écrit :
>>>> Yes, as I thought. Translucent doesn't return searches on local
>>>> attributes.
>>>>
>>>> One for the to do list then.
>
> Yes... The original spec for this overlay only required the ability to
> search
> the remote DB. Searching both requires quite a lot more work.
I agree, after poking at the code with my beginner skills.
>
> One sticking point is that search filters need to be munged; if you send a
> filter to the remote server and it mentions attributes that are only known
> on
> the local server, then you may not get any results back at all. (And vice
> versa.)
Right.
>
> E.g., if you have a remote entry containing
> uid=foo
> and the local translucent entry containing
> cn=bar
>
> and you search for (&(uid=foo)(cn=bar)) then the search will return no
> results
> unless you rewrite the filter on both the local side and the remote side.
>
> A solution here would be to add config keywords to control how filters
> should
> be handled. For any attribute used in a filter, it may be remote only,
> local
> only, or both local and remote.
That could work, as long as you have the correct indexes on local and
remote so as not to be a complete hog.
>
> The processing would go something like -
> for the remote search, walk through the filter and nullify any clauses
> that
> aren't in the list of remote attributes. If the filter collapses down to
> nothing, skip the remote search. Otherwise, execute the search and keep a
> list
> of the results.
Right.
> for the local search, process the filter as above; if the filter
> collapses,
> skip the local search. Otherwise, execute the search and keep a list of
> the
> results.
Right.
> for each entry in the remote list, look for a corresponding entry in the
> local list and the local DB. Merge the entries.
> for each entry in the local list, do likewise.
> merge the lists
> reprocess the list using the original filter.
>
> Quite a lot of steps.
Agreed.
My original plan was to merge a remote with a local *and* use rwm to setup
different ou etc. for Asterisk Voip accounts to try and map these users to
any foreign Directory ;-)
Stick rwm in the overlay stack somewhere for a laugh.
Gavin.
15 years, 6 months
Re: ldapsearch on local attributes with slapo-translucent
by Howard Chu
Gavin Henry wrote:
> Julien Garnier wrote:
>> Gavin Henry a écrit :
>>> Yes, as I thought. Translucent doesn't return searches on local
>>> attributes.
>>>
>>> One for the to do list then.
Yes... The original spec for this overlay only required the ability to search
the remote DB. Searching both requires quite a lot more work.
One sticking point is that search filters need to be munged; if you send a
filter to the remote server and it mentions attributes that are only known on
the local server, then you may not get any results back at all. (And vice versa.)
E.g., if you have a remote entry containing
uid=foo
and the local translucent entry containing
cn=bar
and you search for (&(uid=foo)(cn=bar)) then the search will return no results
unless you rewrite the filter on both the local side and the remote side.
A solution here would be to add config keywords to control how filters should
be handled. For any attribute used in a filter, it may be remote only, local
only, or both local and remote.
The processing would go something like -
for the remote search, walk through the filter and nullify any clauses that
aren't in the list of remote attributes. If the filter collapses down to
nothing, skip the remote search. Otherwise, execute the search and keep a list
of the results.
for the local search, process the filter as above; if the filter collapses,
skip the local search. Otherwise, execute the search and keep a list of the
results.
for each entry in the remote list, look for a corresponding entry in the
local list and the local DB. Merge the entries.
for each entry in the local list, do likewise.
merge the lists
reprocess the list using the original filter.
Quite a lot of steps.
--
-- 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, 6 months
