Thanks! I like the idea of using a view given my fairly simple requirements. I'm going to look into doing that.
Cheers,
Craig
-----Original Message----- From: masarati@aero.polimi.it [mailto:masarati@aero.polimi.it] Sent: Tuesday, August 23, 2011 7:04 PM To: Worgan, Craig (Craig) Cc: openldap-technical@openldap.org Subject: 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).
p.