Summer of Code ============== Name ---- My name is Martin Kühl (or "Kuehl" in ASCII). Contact ------- I can be reached by private mail via or at work via . 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 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/