Thanks! I like the idea of using a view given my fairly simple requirements. I'm
going to look into doing that.
From: masarati(a)aero.polimi.it [mailto:email@example.com]
Sent: Tuesday, August 23, 2011 7:04 PM
To: Worgan, Craig (Craig)
Subject: Re: Read-only Back-SQL
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).