[Date Prev][Date Next]
RE: Read-only Back-SQL
Thanks! I like the idea of using a view given my fairly simple requirements. I'm going to look into doing that.
From: email@example.com [mailto:firstname.lastname@example.org]
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).