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
