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 <[EMAIL PROTECTED]> or at +work via <[EMAIL PROTECTED]>. + + +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 <[EMAIL PROTECTED]> + + +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/
