[Fedora-directory-devel] 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
16 years, 5 months
[Fedora-directory-devel] Please review: Bug 340361: build links wrong libdb on 64-bit systems
by Rich Megginson
https://bugzilla.redhat.com/show_bug.cgi?id=340361
Resolves: bug 340361
Bug Description: build links wrong libdb on 64-bit systems
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: Once again, libtool attempts to be helpful but is
instead harmful. If you have both db4-devel.i386 and db4-devel.x86_64
installed, this will install /usr/lib/libdb-4.N.la. If you use libtool
to link with -ldb-4.N, and you do not specify a search path, libtool
will attempt to find this library in it's default search path, which is
something like /usr/lib/gcc/x86_64/blahblahblah/../../../lib. This will
find /usr/lib/libdb-4.N.la and will use the information in that file and
link the object with /usr/lib/libdb-4.N.so, instead of just passing
-ldb-4.N through to the linker which is what it ought to do (darn
libtool). In order to make libtool do the right thing, we must pass in
-L$libdir -ldb-4.N to libtool so that it will use $libdir first in its
search path.
Platforms tested: RHEL5 x86_64, RHEL4 x86_64
Flag Day: yes - autotool file changes
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=233041&action=diff
16 years, 6 months
[Fedora-directory-devel] Please review: [Bug 339031] Solaris: warnings reported by the Solaris compiler
by Noriko Hosoi
Summary: Solaris: warnings reported by the Solaris compiler
https://bugzilla.redhat.com/show_bug.cgi?id=339031
Description of problem:
Warnings from the Solaris compiler (Studio 11)
1. "ldap/servers/slapd/back-ldbm/back-ldbm.h", line 57: warning: macro redefined:
_LARGEFILE64_SOURCE
2. "ldap/servers/slapd/localhost.c", line 158: warning: implicit function
declaration: getdomainname
3. "ldap/servers/slapd/ntuserpin.c", line 214: warning: empty translation unit
4. "ldap/servers/slapd/back-ldbm/haschildren.c", line 45: warning: empty translation
unit
5. "ldap/servers/slapd/back-ldbm/ldbm_attrcrypt.c", line 591: warning: assignment
type mismatch:
pointer to unsigned char "=" pointer to char
6. "ldap/servers/plugins/replication/cl5_api.c", line 2248: warning: implicit
function declaration: unlink
7. "ldap/servers/plugins/replication/cl5_api.c", line 6455: warning: implicit
function declaration: dblayer_strerror
8. "ldap/servers/plugins/replication/windows_protocol_util.c", line 2259: warning:
implicit function declaration: strcasestr
Mostly, benign except (2), (7), and (8).
------- Additional Comments From nhosoi(a)redhat.com 2007-10-18 21:22 EST -------
Created an attachment (id=231761)
--> (https://bugzilla.redhat.com/attachment.cgi?id=231761&action=view)
proposed cvs diffs
16 years, 6 months
[Fedora-directory-devel] Please review: [Bug 329951] MMR: Supplier does not respond anymore after many operations (deletes)
by Noriko Hosoi
Summary: MMR: Supplier does not respond anymore after many operations (deletes)
https://bugzilla.redhat.com/show_bug.cgi?id=329951
Backend thread updating RUV and thread updating VLV index could cause a deadlock on vlvSearchList_lock and the libdb page.
------- Additional Comments From nhosoi(a)redhat.com 2007-10-18 17:29 EST -------
Created an attachment (id=231611)
--> (https://bugzilla.redhat.com/attachment.cgi?id=231611&action=view)
cvs diffs
Files:
plugins/replication/repl5_plugins.c
plugins/replication/repl5_replica.c
slapd/slapi-private.h
slapd/back-ldbm/ldbm_add.c
slapd/back-ldbm/ldbm_delete.c
slapd/back-ldbm/ldbm_modify.c
slapd/back-ldbm/ldbm_modrdn.c
Description: introduce OP_FLAG_REPL_RUV. It's set in repl5_replica.c if the
entry is RUV. The operation should not be blocked at the backend SERIAL
lock (this is achieved by having OP_FLAG_REPL_FIXUP set in the operation flag).
But updating RUV has nothing to do with VLV, thus if the flag is set, it skips
the VLV indexing.
Test case I'm running:
Set up 2-way MMR (Master 1 and 2)
Set purge delay: nsds5ReplicaPurgeDelay: 600
Import an LDIF file on Master 1
Initialize the replica (Master 2) on Master 1
Create browsing indexes on both Master 1 and 2
Then, I started running following test tools:
ldclt -D "cn=Directory manager" -w <passwd> -p <port> -e add -e random -b
ou=Payroll,dc=example,dc=com -f uid=test_XXXX -v -q -n 2 -N 3600 -r 1000 -R
2999 -I 68 -e inetOrgPerson -e imagesdir=<images_dir>
ldclt -D "cn=Directory manager" -w <passwd> -p <port> -e delete -e random -b
ou=payroll,dc=example,dc=com -f uid=test_XXXX -v -q -n 2 -N 3600 -r 1000 -R
2999 -I 32 -e inetOrgPerson -e imagesdir=<images_dir>
ldclt -D "cn=Directory manager" -w <passwd> -p <port> -e
attreplace=sn:a_random_sn_XXXX -e random -b ou=payroll,dc=example,dc=com -f
uid=test_XXXX -v -q -n 2 -N 3600 -r 1000 -R 2999 -I 32
So far, it's been running for 2 hours with occasional checks on the browser
using VLV/brousing index.
16 years, 6 months
[Fedora-directory-devel] Please review: Bug 288291: add an view object inside a view object that has an improper nsviewfilter crashes the server
by Rich Megginson
https://bugzilla.redhat.com/show_bug.cgi?id=288291
Resolves: bug 288291
Bug Description: add an view object inside a view object that has an
improper nsviewfilter crashes the server
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: I could not reproduce the problem by simply adding the
bogus nsviewfilter. The server seemed to run fine, but I didn't stress
it. However, if I restarted the server, the server would core during
startup. The last message in the error log would say something about
recovering the database, which is probably why the bug reporter said
that it will not recover the database. The problem doesn't appear to be
with views specifically, but with any internal search which uses the
search_internal_callback_pb() (as opposed to the non callback internal
search) and there are search base rewriters (such as the views code).
The aci code uses this type of search at startup to find the acis, and
that's where I saw the crash. I could crash the server at startup
regardless of whether the view filter was bogus or not. The problem is
that we are not passing in the address of new_base to slapi_ch_free.
The fix is to use slapi_ch_free_string and pass in the address of the
string. That fixes the crash.
I also cleaned up a few places in the views code which was not checking
to see if slapi_str2filter returned NULL, which would happen in the case
of the bogus search filter. I also added an error message which will
tell the user that filter X in entry Y is bogus.
Platforms tested: RHEL5 x86_64
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=224951&action=diff
16 years, 6 months