Version 1 (modified by jgarcia@…, 5 years ago) (diff)

Ldap Backend, planning

Ldap Backend

Working in progress... (probably you won't be able to understand the most of the contents of this page, at least nowadays... in the end the contents could have sense, i hope so...)

So, as i said before, Viewer Discretion is Advised!

The purpose of this work is to replace gconf for Ldap (exactly OpenLdap) as the storage configuration engine.

Planning

  • (1) Generation of Ldap Schemas 4,5d
    • Type of attribute types (Ldap Syntaxes) for Ebox::Types::*
      • Relationship betwen Ldap Type <=> Ebox::Type::xxx.yyy Ldap #1 - 1,5d
        • Ip+netmask in 2 strings or in another type?
        • Is there a type for MacAddress representation?
      • New Types? Automatic or manual generation? /client/XXXX/src/Ebox/YYYY/Types/*.pm Ldap #2 - 0,5d
    • objectclass for each model defined in a TableDescription /client/XXXX/src/Ebox/YYYY/Model/*.pm #3 - 2,5d
      • Auto generation of Ldap schema given a tableDescription (new()->table())
        • objectclass with attributes namespaced
  • (2) Initial Ldap Backend Implementation 9,5d
    • Replace GconfModule for LdapStuff without EBox::Module integration #4 - 3d
      • Try to use the Perl Test::Class and TDD style
    • Modify Types/* #5 - 1,5d
      • Do not know anything about store
        • Remove storeInGconf
      • Give a Hash with the values to store
      • Special case if it's new record
      • Special case if it's the ID (change RDN in LDAP)
    • Modify DataTable #6 - 2,5d
      • Find operation in another file or class
      • Do not know how to store, make Table operations, not object ones
    • Modify Row #7 - 2,5d
      • Store (create/modify) the data
      • Get info from each attribute and create a query with LdapStuff for doing the dirty work
  • More stuff to come...