Re: slapd as an appliance

[Marcel Wysocki <maci@satgnu.net>]

Sounds like you want to port slapd to OSv ( http://www.osv.io ) ... 
because... who needs linux anyway ? :p

On 10/28/2014 05:14 PM, Howard Chu wrote:
> A couple different random thoughts all collided so I thought I'd jot 
> them down here...
>
> We can have back-mdb/LMDB set the PROT_EXEC permission on the mmap, 
> and then store executable code in LDAP entries and execute them 
> directly. The idea came to me while reading about just-in-time C 
> compilers and remembering my previous plans for liblforth. At first I 
> was thinking only of small plugins (e.g. syntax parsers/normalizers) 
> but really there's no reason that you couldn't handle larger 
> executables the same way.
>
> I.e., we could store all of slapd's dynamically loadable modules in a 
> back-mdb backend, change olcModuleLoad to use a DN, and dynamically 
> insert and delete code on the fly, without needing any filesystem 
> interactions. Once you have a system where all administrative 
> operations can be done through LDAP, without requiring any other admin 
> interface, it becomes pretty trivial to drop it into a sealed black 
> box and deploy an "appliance." This would be a pretty key advantage 
> for a small, self-contained embedded processor.
>
> Of course, it doesn't stop there - if the only system interface needed 
> is the LDAP port, we don't even need a full OS distro any more. We 
> could run slapd as process #1 (who needs systemd?) - a hardened system 
> with zero unexpected attack surfaces, only one network port open to 
> the world.
>
> One of the current in-progress items for LMDB is to enable using it on 
> raw disk partitions. Adding this feature would mean you no longer have 
> to worry about what type of filesystem to choose, or how to format it 
> before setting up a database. Again, it would be ideal for an 
> appliance because you'd just have to plugin a storage device and then 
> create a back-mdb backend pointing to it.
>
> Another item for LMDB, once raw partition support is working, is 
> in-kernel LMDB. Initially my motivation was to reproduce the KBDBFS 
> work - an in-kernel filesystem built on top of BerkeleyDB (see here 
> http://www.fsl.cs.sunysb.edu/docs/kbdbfs-msthesis/ ) but there's no 
> need to stop there. We could port all of slapd into the kernel, and 
> have a turnkey appliance with no user processes at all.
>
> Food for thought...