disclaimer: i'm a big fan of ldap, especially of the FOSS openldap implementation and i'm using it since ... ever ... (~ 25 years)
i think there is one feature which makes openldap stand out and which in my experience is crucial for any non-trivial directory-implementation someone wants to use:
* easy replication-setups with the possibility to create complex (!) topologies.
what i mean with that is maybe best described by the following "anecdote":
once upon a time i had the use-case of the migration of some mid-sized HPC-clusters - distributed memory - from "good old" NIS to LDAP.
ok ... sounds simple: pam-ldap and be done with it!!
sure, but what happens, if the LDAP main server fails!?
no problem, replicate to a second system as a "fail over" eg. HA ...
sure, but what happens if the network between the HPC-cluster and the LDAP server(s) fails!?
just replicate the directory "read only" to the head-nodes ...
sure, but what happens if the network "in cluster" fails!?
just replicate it to each node ...
now draw out the resulting topology ;))
why? because i wanted to keep the cluster(nodes) utilized even if the "worst case" happens.
last but not least: "openldap is a monster" ... sure, but define monster ... in my experience once you "groked" ldap and delved into the somewhat complex setup of openldap it "just works(tm)" ...
but: great project ... :+1: ... and its written in rust ... yawns ... ;)
As a relatively young person I think openLDAP is ultimately not that hard to use, it just feels very foreign to the modern user.
And that has mostly to do with a lack of good documentation and syntax/system choices that have been made in times where some best practises might not have existed yet.
I must say googling any LDAP issue sucked majorly. But once you get the basic hang of how to do X it is somewhat consistent.
Seconded. Certainly cool to see people working with important protos like LDAP in new ways. For me replication is part of security and resiliency design. Read only replicas act as a buffer that keeps core infrastructure shielded from malicious or poorly configured clients.
as always ... imho (!)
disclaimer: i'm a big fan of ldap, especially of the FOSS openldap implementation and i'm using it since ... ever ... (~ 25 years)
i think there is one feature which makes openldap stand out and which in my experience is crucial for any non-trivial directory-implementation someone wants to use:
* easy replication-setups with the possibility to create complex (!) topologies.
what i mean with that is maybe best described by the following "anecdote":
once upon a time i had the use-case of the migration of some mid-sized HPC-clusters - distributed memory - from "good old" NIS to LDAP.
ok ... sounds simple: pam-ldap and be done with it!!
sure, but what happens, if the LDAP main server fails!?
no problem, replicate to a second system as a "fail over" eg. HA ...
sure, but what happens if the network between the HPC-cluster and the LDAP server(s) fails!?
just replicate the directory "read only" to the head-nodes ...
sure, but what happens if the network "in cluster" fails!?
just replicate it to each node ...
now draw out the resulting topology ;))
why? because i wanted to keep the cluster(nodes) utilized even if the "worst case" happens.
last but not least: "openldap is a monster" ... sure, but define monster ... in my experience once you "groked" ldap and delved into the somewhat complex setup of openldap it "just works(tm)" ...
but: great project ... :+1: ... and its written in rust ... yawns ... ;)
just my 0.02€