Google Summer of Code
abartlet at samba.org
Mon Mar 31 23:15:38 GMT 2008
On Sat, 2008-03-29 at 23:25 +0100, Timo Wingender wrote:
> Andrew Bartlett schrieb:
> > On Thu, 2008-03-27 at 20:01 +0100, Timo Wingender wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >> I like to participate in Google Summer of Code this year. I am
> >> especially interested in development of samba4 with LDAP-backend.
> > This is a very interesting, but frustrating and painful area. If you
> > are up for it, then it could be a great contribution, because I'm pretty
> > much burnt out from working on it for so long.
> I know ldap is not an easy area. I have some experiences in setting up
> samba3 with an LDAP. But it is an relative difficult task to set it up
> and to debug it. You need much knowledge of ldap and samba to set it up.
> I think this could be much easier.
> I am willing to put much effort in learning more about ldap and samba. I
> think ldap is the best way to manage users.
I agree, but the mapping of AD's practises to availablen Free LDAP
products is a very difficult matter.
We currently implement a mapping from Samba4 to OpenLDAP, assuming the
use of the memberOf and refint plugins, but due to the lack of
transactions in the OpenLDAP backend, these suffer from races.
Work in this area should be as much about working around the limitations
of the available Free LDAP servers, as well as about the complex mapping
from an traditional LDAP structure to what AD wants.
Given the nature of this work, it would not be about 'being easier than
Samba3 to setup'. Indeed, it will probably be harder, but bring the
benefit of being AD-compatible.
(The internal ldb database should remain 'easier than Samba3 to set up',
but suffers all the failings that go with that.)
> > See my post on the LDAP backend above.
> >> But I
> >> have no overview over the current state of samba4. Reimplementing
> >> something from samba3 is also a possibility. Any recommendations for a
> >> small project which can be done in 3 month?
> > One interesting but difficult project would be to move the DRSUAPI
> > replication protocols from a one-way demo to a full, tested (ie include
> > multi-server testsuite) two-way replication with AD. This would include
> > changes to LDB to cope with the increased requirements of DRSUAPI
> > replication (container objects are represented twice, linked attributes
> > need more metadata).
> > Another similar project might be to implement windows 2008 'read only
> > DC' functionality in Samba4. This might be 'safer' than the two-way
> > replication, but includes a lot of links that we would need to implement
> > to pass off all secrets handling (including RPCs for verifying NTP
> > packets, passwords etc).
> It sounds much like ldap replication trough samba. Especially the first
> one. The second says nothing to me. Should replication be done with
Yes, both of these are about windows-style DRS replication in Samba.
> I thought this is part of the ldap-server. Why doing it in samba too?
> I thought more about the general integration of ldap. I'm not much
> interested in replication. As I said above in my opinion support of ldap
> is way to complicated in samba3. I don't know how this is with samba4.
> But I think there is much to do to make it work out of the box for all
The second option is about 'one way replication'. But if messing around
with deep DRS replication internals is not your thing, then keep away
from both of these options.
> My problem is that the deadline for application is on March 31th. I
> really want to put much work in it. Even before coding will start. But a
> the moment I've no idea what have to be done in the current development
> tree. I have not much time until end of next week. Otherwise I would
> have an look at the source to get the current state.
Sorry I couldn't reply over the weekend.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20080401/8d9d008d/attachment.bin
More information about the samba-technical