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: [email protected] [mailto:[email protected]] Sent: Tuesday, August 23, 2011 7:04 PM To: Worgan, Craig (Craig) Cc: [email protected] 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.
