svn commit: samba r15905 - in branches/SOC: . mkhl

mkhl at samba.org mkhl at samba.org
Fri May 26 13:41:33 GMT 2006 

Author: mkhl
Date: 2006-05-26 13:41:33 +0000 (Fri, 26 May 2006)
New Revision: 15905

WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=samba&rev=15905

Log:
- Add my subdir to SOC
- Add my soc proposal

Added:
   branches/SOC/mkhl/
   branches/SOC/mkhl/proposal.txt


Changeset:
Added: branches/SOC/mkhl/proposal.txt
===================================================================
--- branches/SOC/mkhl/proposal.txt	2006-05-26 12:28:55 UTC (rev 15904)
+++ branches/SOC/mkhl/proposal.txt	2006-05-26 13:41:33 UTC (rev 15905)
@@ -0,0 +1,217 @@
+Summer of Code
+==============
+
+Name
+----
+
+My name is Martin Kühl (or "Kuehl" in ASCII).
+
+
+Contact
+-------
+
+I can be reached by private mail via <martin.kuehl at gmail.com> or at
+work via <kuehl at univention.de>.
+
+
+Project Title
+-------------
+
+Samba4 support for an external LDAP server backend
+
+
+Synopsis
+--------
+
+Samba4s LDB is capable of using different backends for storage,
+primarily TDB and LDAP.  The LDAP backend is subject to certain
+assumptions about its semantics however, which precludes use of
+anything other than the LDAP server bundled with Samba4 currently.
+
+This project aims to provide the translation infrastructure and
+translating modules necessary to use an OpenLDAP server as an LDB
+backend.
+
+
+Possible Mentor
+---------------
+
+Andrew Bartlett <abartlett at samba.org>
+
+
+Benefits
+--------
+
+There are excellent free LDAP servers available and in active use, but
+migration to Samba4 would require that either Samba4s internal LDAP
+server becomes mature and full-featured enough to be used as a
+replacement, that Samba4s LDAP server gains the ability to proxy
+requests to another LDAP server, or that both LDAP servers coexist,
+listening on different ports and being available to different tools.
+
+With support for en external LDAP server this problem could be solved
+by just using the active LDAP server as the backend.
+
+The Samba project would benefit from this by being able to postpone
+the internal LDAP server, or certain advanced features of it, thus
+speeding up Samba4 development as a whole.  Upgrades to Samba4 would
+also be easier in situations where an LDAP server is present already,
+speeding up adoption of Samba4.
+
+The infrastructure for translation modules would also be beneficial by
+allowing support for even more different backends, provided someone
+developed translations for them.
+
+The translations of TDB could also be migrated to the infrastructure,
+easing their maintenance and possible further development of them,
+partially because they wouldn't be written in C anymore.
+
+
+Details
+-------
+
+LDB, Samba4s LDAP-like database, is capable of using a range of
+different backends, the most notable ones currently being TDB and
+LDAP.  The LDAP backend is expected to provide certain semantics that
+to this day only Samba4 itself provides, which means that an external
+LDAP server like [OpenLDAP][1] cannot be used to store Samba4s data.
+
+The semantics expected from LDAP aren't provided by the TDB backend
+though, it provides a very simple database that can only be used
+because it's communication is translated by a set of modules.
+
+The goal of this project is to support the use of an external LDAP
+server as a backend to LDB; for this, the translation infrastructure
+that is in place for TDB should be uncoupled from TDB and reused for
+other backends, in this case LDAP.  In general, it should be possible
+to support any backend as long as it provides a mapping of key/value
+pairs and has a complete set of correct translation modules attached.
+
+The mappings for TDB are currently performed by C code.  To ease their
+modularization and the development of new mappings, it should be
+possible to implement these in EJS: the JavaScript language is well
+suited for manipulation of strings and key/value mappings, is
+supposedly easier to read and write than C and probably easier to load
+at runtime, which would ease their development further and allow their
+use for custom attributes in the database.
+
+Translation modules will be written with OpenLDAP as the backend in
+mind, but the design of the module infrastructure should account for
+the needs of TDBs modules as well so it can be independent of specific
+backends.
+
+Initial steps for this project will be incremental support for reading
+untranslated and later translated values from an OpenLDAP server until
+an initial provision (e.g. a version dumped by the TDB backend) can be
+read back from an LDAP backend.  Following steps will be support for
+writing values to an LDAP backend until the complete provision can be
+loaded into an OpenLDAP server, then for modifying increasingly
+complex values until changing passwords stored in an LDAP backend is
+supported.
+
+Development on Samba4 follows a test-driven methodology, so each phase
+of this project should be test-driven as well, i.e. there will be
+test-cases defining the module infrastructure and interface modules
+have to provide (treating the modules as black boxes otherwise),
+test-cases defining the mappings for a certain backend (treating the
+modules as black, the backend as a white box), and test-cases defining
+the semantics expected from a backend with translations in place when
+the provision is loaded into it, possibly modified and then read back
+from it (treating the backend as a black box).
+
+
+Deliverables
+------------
+
+* An infrastructure for translation modules capable of mediating
+  between the semantics expected by LDB and those provided by some
+  backend of it.
+
+* Translation modules capable of performing this mapping between LDB
+  and OpenLDAP.
+
+* A set of test-cases for both the infrastructure and the modules that...
+
+    * define a standard interface modules must provide to be used in
+      the infrastructure (i.e. check that modules can be used at all),
+
+    * define a set of required translations the modules for a given
+      backend must provide (i.e. check that modules can be used for
+      this backend),
+
+    * define the expected semantics of loading a set of provided
+      information (like the provision) into a backend and accessing it
+      afterwards (i.e. check that modules for this backend are
+      "complete and correct").
+
+
+Background
+----------
+
+Martin is currently a student of informatics at the [University of
+Bremen][2], his main interest being formal methods of software development
+and (functional) computer languages, and a student developer at
+[Univention][3], who offer a GNU/Linux distribution focused on migration
+from and interoperability with Windows as well as integration of
+provided services via directory services and a coherent management
+frontend. He is also a developer of [SXEmacs][4], his contributions to
+which are available from the sxemacs-devel and -patches mailing list
+archives.
+
+Martin's experiences include middle-scale mostly-university projects
+in Java (concurrency and route-planning), C# (web services and xml
+processing) and C (BSP-tree generation and OpenGL rendering; SXEmacs
+internals) and large-scale projects in Haskell (overload resolution
+for [Hets][5]) and Python (his current work for Univention) as paid work.
+
+As the Samba LDAP backend project is of interest to his employer, they
+have offered to support Martin's work on it by freeing him of most
+work obligations for the duration of the project, along with access to
+their computing resources and experience with Samba and LDAP.  As a
+result, Martin will be able to allocate about 30-40 hours per week to
+working on LDAP backend support -- not including late-night hacking
+sessions of course.
+
+
+Time line
+---------
+
+* Compare the semantics LDB expects to those TDB provides.
+* Understand how these are mapped to each other.
+* Compare the semantics LDB expects to those OpenLDAP provides.
+* Define a minimal translation required to map between LDB and LDAP.
+* Support simple untranslated read operations from LDAP.
+* Sketch an infrastructure to support implementing translations in EJS.
+* Define the interface translations are needed to provide.
+* Implement simple translation modules in EJS.
+* Support simple translated read operations from LDAP.
+* Support translated reading of the provision as it is stored in TDB
+  from LDAP.
+* Implement translation modules for write operations.
+* Support loading the provision into LDAP.
+* Support simple modifications of values in LDAP.
+* Support complex modifications (passwords, say) in LDAP.
+
+Note that this time line isn't meant to be monolithic:
+
+* Each "Support X" step will probably include the implementation of
+  more translation modules.
+* The "Define X" steps will probably have several accompanying
+  "Refine X" steps; especially the module infrastructure would be hard
+  to get right the first time.
+* The distinction of read/write is somewhat artificial; I'm expecting
+  at least a few modules where the mapping of reading and writing are
+  easily.
+
+
+---
+
+[1]:  http://www.openldap.org/
+
+[2]:  http://www.informatik.uni-bremen.de/cms/detail.php?id=12&language=en
+
+[3]:  http://www.univention.de/english.html
+
+[4]:  http://www.sxemacs.org/
+
+[5]:  http://www.informatik.uni-bremen.de/cofi/hets/

More information about the samba-cvs mailing list