[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Read-only Back-SQL

> Hi,
> I have a little bit of, mainly experimental, experience configuring
> back-sql to connect to a PostgreSQL database.  I have a requirement in
> front of me to expose a small table of user data in the database to an
> existing LDAP client.  The data in the database is already in the database
> and managed by another application through the database directly.  The
> LDAP API I am being asked to provide will be read-only.  In other words,
> the data will continue to be managed by the existing management app.  I
> foresee two problems with this approach.
> First, since the database table is already populated when the new ldap
> service is turned on, there is no data in the ldap_entries table.  Is
> there a way to populate ldap_entries after the fact so that the records
> can be seen by OpenLDAP?
> Second, since the data is mastered by another application that goes
> through SQL directly, is there a way to update the ldap_entries table on
> the fly to reflect the additions and deletions that occur once the ldap
> service is up and running?
> Right now I am looking at writing a custom procedure to initially populate
> the ldap_entries table and then triggers to manage the additions and
> deletions from that point onward.  I was just wondering if there was
> something in back-sql already that might provide a better solution.
> We are currently using OpenLDAP 2.4.21.

In terms of a trigger, you could use ldapsync (RFC4533).  Another "trick"
that allows to automatically generate the ldap_entries table consists in
using SQL views.  This works relatively well for simple data structure
(e.g. a single type of entries).