4 ms·
I hear you, I initially didn't want to reimplement a whole server for that. And there are arguments for scrapping the API I slapped in front of it and make ever
by nitnelave 4y ago
I hear you, I initially didn't want to reimplement a whole server for that. And there are arguments for scrapping the API I slapped in front of it and make everything go through LDAP.
Eventually, what drove me to create this is that it's targeted at small self-hosted servers that just need <20 users and _don't want to learn LDAP_. People who either don't have the background necessary to learn LDAP or don't have the time to dig into it. That's why an important part of the repository is the list of example configs for many services that provide good defaults for easily setting up the connection with LLDAP. The server admins don't actually need to know LDAP to use LLDAP.
An additional benefit is that the resulting image is small and the software is fast, because it does way less than OpenLDAP. And the API/SQL DB makes it more easy to integrate with scripts or applications that manipulate users directly.
- hyc_symas 4y agoI'm guessing you mean "and the software is fast enough", because OpenLDAP itself has been the world's fastest distributed database for over a decade, and nothing else even comes close. Since you built on top of SQLite, then you're already at least an order of magnitude slower. You could speed it up a bit by using SQLightning, which replaces SQLite's Btree engine with OpenLDAP's. https://github.com/LMDB/sqlightning https://github.com/LMDB/sqlightning But yes, it's obvious your aim is to provide bare minimum LDAP functionality for people who were only taught SQL and have no desire to learn LDAP. A bit of a loss, because the workloads LDAP is used for most often are things RDBMSs suck at.