Edit detail for LightLdapd revision 2 of 6

1 2 3 4 5 6
Editor: DonovanBaarda
Time: 2014/01/03 14:34:18 GMT-5
Note:

changed:
-  * OpenLdap
-  * https://github.com/vlm/ldap-server-example
-  * https://github.com/urbanserj/entente
-  * http://www.fefe.de/tinyldap/
-
-entente looks very interesting.
  * OpenLdap - Feels a bit big and clunky. Support for serving /etc/passwd deprecated in favour of database backends. Seems to be targeting enterprise sized setups, not small home networks.
  * https://github.com/vlm/ldap-server-example - OK example. Looks like it's a one-shot server; run it and it answers one query then terminates. Might be useful to pull code from. 
  * https://github.com/urbanserj/entente - uses libpam, libev, and asn1c to compile LDAP ASN definition directly. A single 500 line file gives a server that can be used as an ldap auth backend using pam, but that's it. Should be extendible to support more of the LDAP functionality.  
  * http://www.fefe.de/tinyldap/ - Written in response to OpenLdap being slow. Uses a simple fork-per-connection model and claims to still beat OpenLdap. I think this shows that forking is not the high overhead it once was. Much more code than entente, including it's own ASN parser etc.

Of these entente looks the most interesting. It uses libev already. Its use of asn1c to compile the LDAP ASN appeals to my "as little coding as possible" objective. I think I'll use this as my starting point, and borrow code from the others when/if it turns out to be useful.

added:
There are plenty of libraries, but I don't believe it's worth picking obscure ones unless they provide some really significant advantage over the more popular alternatives. Popular libraries get more use, debugging, support, and are more likely to be already installed. The Debian repository is a good indicator of popularity; if it's not in there, it's probably not popular enough to use. If multiple alternatives are in there, then the list of other packages that depend on it is a good indicator of which one is more popular. Also interesting is its own dependencies; does it depend only on other popular libraries? Something that has no dependencies but which implements large amounts of functionality normally provided by other libraries has probably re-invented lots of stuff badly (or statically linked the other libs in).

I also think code and binary size is a surprisingly good indicator of quality; the smaller the better. Look at the Debian installed package sizes for hints, but be aware that sometimes larger packages include lots of documentation, which is a good thing.


changed:
-    - libevent
-    - libev
    - libevent - the original event loop library.
    - libev - the new event loop library which is faster, with slightly more functionality.

added:

I've decided that the libs to use are libev, glib, gnutls (or stud in the beginning), and gsasl.

Overview

With dnsmasq there is a very small, simple, powerful, and reliable combined dns server, dns cache, dhcp server, and tftp server. It's got everything you need to serve a small home/classroom/school sized network that can include thin clients. It's very easy to configure (dns just serves up the /etc/hosts file with auto-dns support for dhcp clients), and its dhcp server can easily be configured to serve anything like auto-proxy config or different boot options for different thin clients. It's small enough to run on a OpenWRT? router or QNAP NAS.

One of the things a small network like this really needs is an LDAP server for managing users. It needs to be small and efficient, with enough grunt to support at least 100 clients and 1000 users when running on something like a router or NAS. It must be powerful enough to support most commonly used functionality, but familiar and simple to configure. It absolutely must be reliable and secure enough for the home/classroom/school environment. I believe that they should be written in C (widely used and fast) using an event-loop design (threads suck).

Objectives

Primary objectives are;

  1. Support enough LDAP functionality for pam-ldap and nss-ldap to work for clients.
  2. Serve familiar /etc passwd group shadow files directly with no special file formats.
  3. Easily support ~100 clients and 1000 users on router level hardware.
  4. Keep the code small and simple, using existing libraries as much as possible.

Secondary objectives are;

  1. Support TLS and SASL for security in a slightly untrustworthy network.
  2. Support additional nss files like hosts networks netgroup etc.
  3. Support writes enough so that pam-ldap updates using passwd chfn chsh work.
  4. Support samba domain authentication and schemas.
  5. Support arbitrary schemas served from passwd like files.
  6. Support ACLs?.

Alternatives

Existing LDAP servers;

  • OpenLdap? - Feels a bit big and clunky. Support for serving /etc/passwd deprecated in favour of database backends. Seems to be targeting enterprise sized setups, not small home networks.
  • https://github.com/vlm/ldap-server-example - OK example. Looks like it's a one-shot server; run it and it answers one query then terminates. Might be useful to pull code from.
  • https://github.com/urbanserj/entente - uses libpam, libev, and asn1c to compile LDAP ASN definition directly. A single 500 line file gives a server that can be used as an ldap auth backend using pam, but that's it. Should be extendible to support more of the LDAP functionality.
  • http://www.fefe.de/tinyldap/ - Written in response to OpenLdap? being slow. Uses a simple fork-per-connection model and claims to still beat OpenLdap?. I think this shows that forking is not the high overhead it once was. Much more code than entente, including it's own ASN parser etc.

Of these entente looks the most interesting. It uses libev already. Its use of asn1c to compile the LDAP ASN appeals to my "as little coding as possible" objective. I think I'll use this as my starting point, and borrow code from the others when/if it turns out to be useful.

Existing Libraries

There are plenty of libraries, but I don't believe it's worth picking obscure ones unless they provide some really significant advantage over the more popular alternatives. Popular libraries get more use, debugging, support, and are more likely to be already installed. The Debian repository is a good indicator of popularity; if it's not in there, it's probably not popular enough to use. If multiple alternatives are in there, then the list of other packages that depend on it is a good indicator of which one is more popular. Also interesting is its own dependencies; does it depend only on other popular libraries? Something that has no dependencies but which implements large amounts of functionality normally provided by other libraries has probably re-invented lots of stuff badly (or statically linked the other libs in).

I also think code and binary size is a surprisingly good indicator of quality; the smaller the better. Look at the Debian installed package sizes for hints, but be aware that sometimes larger packages include lots of documentation, which is a good thing.

  • async event framework
    • libevent - the original event loop library.
    • libev - the new event loop library which is faster, with slightly more functionality.
  • datastructures
    • glib
  • TLS secure network transport
    • openssl
    • gnutls
    • CyaSSL?
    • stunnel
    • stud
  • SASL secure authentication
    • cyrus-sasl
    • gsasl
    • cyrus saslauthd

I've decided that the libs to use are libev, glib, gnutls (or stud in the beginning), and gsasl.