(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
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
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
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.
https://bugzilla.redhat.com/show_bug.cgi?id=232910
Resolves: bug 232910
Bug Description: ACI targetattr list parser is whitespace sensitive
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: Need to trim trailing whitespace from the targetattr
clause. I noticed that targetattrfilters had the same problem, except
it returned ACL_SYNTAX_ERR in that case, so I changed targetattr to do
the same.
Platforms tested: RHEL5 x86_64
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=231531&action=diff
Summary: Migration/Upgrade fails when it's from 6.21 to 8.0 on the same OS/architecture
https://bugzilla.redhat.com/show_bug.cgi?id=327091
Problem description: Migration/Upgrade fails when it's from 6.21 to 8.0 on the same OS/architecture
------- Additional Comments From nhosoi(a)redhat.com 2007-10-15 19:30 EST -------
Created an attachment (id=228001)
--> (https://bugzilla.redhat.com/attachment.cgi?id=228001&action=view)
cvs diff back-ldbm.h dblayer.c upgrade.c
Files:
ldap/servers/slapd/back-ldbm/back-ldbm.h, dblayer.c, upgrade.c
Description:
merged the proposed fixes from comment #1, #3, and #4.
back-ldbm.h: added LDBM_VERSION_62
dblayer.c: fixed a bug to check the instance dir name
upgrade.c: added LDBM_VERSION_62, with the action DBVERSION_NO_UPGRADE as Ulf
suggested.
https://bugzilla.redhat.com/show_bug.cgi?id=330141
Resolves: bug 330141
Bug Description: uuid generator not initialized by import from command line
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: https://bugzilla.redhat.com/show_bug.cgi?id=330141#c0
What happens is that the uuid values all look like this:
XXXXXXXX-XXXXXXXX-80000000-00000000
So the time based part is generally ok, but the clock seq and node ID
part are never initialized, hence 0's for those fields.
The fix is to initialize the unique id generator in the same manner as
we do for the server when it starts up in regular mode, except that we
tell the generator to use the single threaded (st) mode rather than the
multi threaded (mt) mode.
Platforms tested: RHEL5 x86_64
Flag Day: no
Doc impact: no
QA impact: should be covered by regular nightly and manual testing
New Tests integrated into TET: none
https://bugzilla.redhat.com/attachment.cgi?id=226181&action=diff
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