This is an old revision of the document!


Exporting Sympa mailing lists to LDAP

Currently Sympa provides many ways to import data from the outside, mainly to include list members or list administrators. External data sources can be SQL databases, LDAP directories, flat files, other mailing lists.

Now lets consider that Sympa is not just a data consumer but also a data producer. The main reason why Sympa is worth being a data producer is because of its ability to manage groups of people. Sympa uses this groups definition for its own needs (sending message to groups, sharing documents among groups) but since these groups are defined in Sympa their might be of interest for other applications (wiki, web conferencing system, survey tool,…).

This has already being addressed by Sympa through some extensions ; its SOAP interface being the most notable example. Using the Sympa SOAP API a third party software can query the Sympa server to either find out if a user is member of a group or to get all the members of a given group.

However using the Sympa SOAP interface means that the third party software needs to be customized to speak SOAP.

On the other hand most software natively implement LDAP connectors to query group definition. Therefore it would be useful to adapt Sympa so that it can export its groups data into an LDAP directory. Then third party application could just use their LDAP connectors.

The LDAP structure should be adapted to allow LDAP clients to perform 3 kinds of searches :

  1. get all members of a given group
  2. get all groups a given user (=email address) is member of
  3. check wether a given user belongs to a given group

The LDAP structure should also allow to store the following information :

  • Sympa virtual hosts
  • list description
  • members/owners/moderators stored separately

Two kind of LDAP structures are considered, each of them having its assets.

Using groupOfNames

Below is the representation of such a DIT :

ou=sympaGroups
  ou=members
    cn=mace-dir@internet2.edu (of type groupOfNames)
    cn=shibboleth-users@internet2.edu
    ...
  ou=owners
    ...
  ou=moderators
    ...

ou=People
  cn=olivier.salaun@cru.fr (of type inetOrgPerson)

This organization has the benefit of using a standard groupOfNames LDAP object that most applications should be familiar with. On the other hand, for an LDAP client to fetch the members of a given group, it requires 2 consecutive search operations.

Using a new mailingList object

Below is the representation of such a DIT :

ou=sympaGroups
  cn=mace-dir@internet2.edu (of type mailingList)
    members (multi-valued, containing email addresses)
    owners
    moderators

This organization allows LDAP clients to query group members within a single search query. On the other hand it does not allow to store member attributes other than the email address.

Questions

Which organization would be appropriate?
If using the first solution, should we use GroupOfNames objects or GroupOfUniqueNames?
Apart from the list address, subject, members, owners and moderators, what other list information should be published in the LDAP directory?
Should we store member informations such as name and reception mode?

The mailing list data in the LDAP directory need to be in sync with Sympa's own database.

Therefore we could have a dedicated process that will periodically update the LDAP structure. However a better option would be to add the synchronization code in every places of the Sympa code where list members are updated. This solution would have 2 advantages :

  1. make the LDAP data always in sync with Sympa's own data,
  2. synchronous update prevents the burden of comparing both LDAP and SYmpa list members,
  3. better integration of the feature in Sympa.

The minimum required informations are those that Sympa needs to connect to the LDAP directory :

  • host, port, suffix, timeout
  • user, password
  • use_ssl, ssl_version, ssl_ciphers

We already have generic code to connect to an LDAP directory given these informations.

Questions

Should the export_ldap parameters should be stored in sympa.conf, or in a dedicated configuration file?
Should the export_ldap configuration should be a per virtual host config?
We need to define if the LDAP branch where Sympa stores list data has a hard-coded structure or if it should be customizeable?

  • Member add, removal, update
  • adding, updating, removing an include data source in Sympa
  • creating, renaming, removing a list

The best approach is to change the lower layers of Sympa code because it lessen the changes and garantee that any Sympa processes will keep the LDAP in sync.

The following pieces of code should be changed :

  • src/Conf.pm : adding the new “export_ldap” parameter
  • src/LDAPSource.pm : adding new subroutines to create/update LDAP entries.
  • src/List.pm :
    • save_config() : when list config changes, also update the LDAP structure (eg: list subject). The list creation case should be treated here
    • delete_user() : remove the corresponding user
    • update_user() : update user entry (could be an email adress change)
    • update_admin_user() : the same for an owner / moderator
    • add_user() : add the user in LDAP
    • add_admin_user : the same for an owner / moderator
    • rename_list_db() : changes the list name
    • sync_include() : synchronize LDAP members with include data sources
    • sync_include_admin() : the same for an owner / moderator
    • close() : closing a list means removing the corresponding entries in LDAP
  • dev/exporting_groups_in_ldap.1192182550.txt.gz
  • Last modified: 2007/10/12 11:51
  • (external edit)