Hi Mark,
I took a different approach on the kids problem. Instead of handling that in in back-sql, I created a flat table "ldap_addresses" in postgresql.
A cronjob populates this table with fresh data every hour. The SQL query to assemble the data as a flat table is quite complex, but I found that a lot easier then to do this in back-sql.
So in my case, there are no recursions, just simple WHERE conditions.
Say for example you have users working in different departments. And now you want to list users working in a specific department.
In LDAP notation you'd probably have a filter like (ou=departmentA) with a "subtree" scope. In case of my flat table, I have a dedicated column "department" that is linked to the LDAP attribute in ldap_attr_mappings:
INSERT INTO ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) values (1,1,'ou','department','ldap_addresses',NULL,NULL,NULL,3,0);
A flat table like mine may have it's disadvantages, but for my ~5000 addresses it works pretty well.
And if I ever wanted to allow modifications as well (new, update, delete), all I had to do was to add triggers to that flat table and send the data where it belongs to in my RDBMS.
I don't know if that makes sense to you :)
BR Udo
On 20.10.21 16:30, Mark Murawski wrote:
Hi Udo,
Would you mind sharing your back-sql configuration for read-only? Like I mentioned in the last post I spent time over a period of a few months working on this and I couldn't get children of children to load at all. The queries weren't even asking for the data... not sure why.
On 10/20/21 10:00 AM, Udo Rader wrote:
Hi Mark,
thanks for getting back.
I've since dug out my +10y old configuration and managed to set things up pretty easily.
There are some headaches and pitfalls, yes, but for a r/o address book it still works pretty well.
After adding pcache, performance got a lot better, too. Not perfect of course, but it works well enough.
Will probably only know in a couple of weeks how well it really works, performance and stability wise.
BR Udo
On 19.10.21 19:27, Mark Murawski wrote:
Hi Udo,
After months of troubleshooting. I've determined that back-sql is missing core functionality that prevents its use in terms of implementing a full-service ldap system.
I am a developer, but I don't have the time to deep-dive into this. What I would up doing was storing my data in postgres and then exporting to a read-only standard ldap backend. And re-exporting once a day to address changes to the data in postgres.
Hope this helps.
Thanks.
On 10/15/21 5:00 PM, Udo Rader wrote:
Hi, I need to expose some data stored in a postgres database using OpenLDAP. In the past, I've used back-sql for that purpose and it has worked quite nicely, but that has been a very long time ago. Now, after digging through the archives a little bit, I read that the usage of the backend is discouraged, because it is unmaintained. What I basically need is an LDAP based address book, that users can connect to using their macOS based MUAs. So if we say, that the backend is only used for read-only access, is it still not recommended? And maybe, if the backend happens to be unusable, are there any viable alternatives that come to mind? Thanks Udo