Paging hyc!

Meh.

Once upon a time Netscape/Mozilla browser shipped with LDAP module callable from javascript. There really wasn't any need to build a separate LDAP frontend. Nowadays Mozilla/Firefox has stripped out pretty much everything that made Netscape useful. So it goes.

People talking about OpenLDAP complexity - that's mostly BS. Complexity of the config is driven by complexity of the demands placed on the installation. If all you want is to store passwords for a handful of users, the config can be done in 10 lines of text.

re: storing config in an LDAP database - no you don't need to know OpenLDAP to be able to manage it. You need to know LDAP - and you need to know that anyway to use it, and your knowledge of LDAP is transferable to any LDAP-based system, not just OpenLDAP. But yes, you have to know the basics of LDAP. That's an unavoidable requirement of working with any LDAP software.

It's a bit daft to write your own LDAP server implementation if your complaint is that there's no modern GUI UI. LDAP is a standard protocol - if you want a shiny new UI, write the shiny new UI. And when you're done you can use it with any LDAP server in existence, assuming you did your job right and followed standards.

Meanwhile, the actual OpenLDAP software has been tuned and battle-tested, it is by far the world's most efficient and most reliable data store.

nitnelave

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

I'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

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.