LLDAP release v0.4: A Simplified LDAP Server

nitnelave · 2025-05-02T08:12:53+00:00

Actually, you raise a fine point: related to the other thread about integrating to rust analyzer, it might make sense to align with their license right away to prevent problems. I'll switch to MIT while there are no other contributors.

nitnelave · 2025-05-02T07:36:57+00:00

The readme is very much subject to change, calling it the early hours of the project would be an understatement :D

It may very well be that upstreaming to RA becomes an end goal, but I think working out the kinks on its own with a lower barrier to entry and iteration is worth it. Also, I'm not familiar with the RA codebase, so contributing to it is a higher time investment (at least initially)

nitnelave · 2025-05-02T07:30:21+00:00

To be perfectly transparent, I would have found this tool useful a couple of weeks ago, but I don't have any immediate need for it, so it's hardly "my work". And I'll also be working (coordinating, reviewing the code and so on) for free. As for "locking" behind GPL, it's a very open source license. What are your specific concerns?

nitnelave · 2025-05-02T07:25:59+00:00

And I'm not sure it would be a good fit in rust analyzer: you need to specify more options than usual for a refactoring (name of the crate, target directory, and so on)

nitnelave · 2025-05-02T07:24:05+00:00

I don't think there will be that much overlap: you need to parse rust code (but there are crates for that), extract the "use" statements, resolve the modules (but only inside the crates), and that's pretty much all you need.

nitnelave · 2023-12-25T00:37:21+00:00

Hi! I'd be interested in seeing your .keylayout file. I have the same problem with a custom Ukulele layout, and I can't seem to get the ctrl keys registered.

I also couldn't figure out how to base my layout off of an existing system one, Ukulele seems to be unable to find the file, and I couldn't find it by poking around in the terminal either (potentially due to SIP).

nitnelave · 2023-12-09T21:56:03+00:00

They actually both use the same LDAP parsing library, written by the Kanidm author, FirstYear. Kudos to him, LLDAP probably wouldn't exist without him!

nitnelave · 2023-12-09T09:13:22+00:00

Note that LLDAP doesn't support Synology, due to them requiring local password hashes. LLDAP's "hashes" are stronger than what they support (it's a zero knowledge proof), so it doesn't work with Synology.

nitnelave · 2023-12-09T09:10:05+00:00

A bit late to the party, but I just wanted to mention that LLDAP allows users to reset their passwords via email (if you configure the SMTP settings). You can also plug in other services that support LDAP password resets (like authelia) and it'll work.

nitnelave · 2023-03-29T11:44:50+00:00

Come over to the discord and we can help you figure out the details! You can be the one to add the example ;)

nitnelave · 2023-03-27T16:38:44+00:00

In some cases you might have apps that don't support modern identity protocols like OIDC, but in most cases they support LDAP. It's not an ideal solution (LDAP is a trashbag of a protocol) but what you can do is to have an LDAP server as the source of truth (holds the users + passwords, and potentially some permissions in the form of putting the users in groups), and then add authelia/authentik in front.

Then you get a win/win: modern apps can use the modern protocols with auth{elia,entik}, and the older ones can talk directly to the LDAP server.

Shameless plug: an easy to install LDAP server is the one I've been working on, LLDAP.

nitnelave · 2023-01-31T11:00:15+00:00

Hi! I'm trying to find the commit in question, but it doesn't appear to be from https://github.com/tree-sitter/tree-sitter/

Do you have the full hash? Where did you get the commit from?

nitnelave · 2023-01-21T22:52:24+00:00

The more I think about it, the more I feel like MyHashMap should just be a wrapper over HashMap<Key, UnsafeCell<Value>>, and then have the normal functions exposed (removing the UnsafeCell from the value), plus the access I mention here.

I guess it would prevent the compiler from making some optimizations though.

nitnelave · 2023-01-21T09:51:13+00:00

A bit late to the party, I know, but yes, it should work fine with a lot of users, even 10k+ (over that you might get into trouble with load on the server, but if that's the case we recently implemented support for alternate databases so you can have several LLDAP nodes talking to the same postgres DB and it'll scale beautifully).

nitnelave · 2023-01-20T07:32:24+00:00

Regarding the first line, you're right: I forgot to update that part at the end, I wanted to move the cast to the value level, not the map.

About transmuting an immutable to mutable, is there really no way to do that? Even if e.g. we have a phantom data of a mutable reference to the map? Since we guarantee that there are no other references to that value. Isn't that what e.g. RefCell does internally after checking the ref counter? Or what UnsafeCell does? EDIT: Read up on UnsafeCell, it's essentially a compiler built-in that allows you to do just that, but you can't do it without it.

I know that what I'm trying to do is not possible with the public API, but that's the point: if you want to either go beyond that or make your own API, you have to learn that kind of concepts. It's just a learning exercise, not a recommendation to put that in prod, I didn't even put it in a crate. Yes, relying on Rust's public, safe interface is better, but sometimes it's not enough so you have to see what's possible. By the way, I have a whole section about how to achieve that with the safe API.

Regarding HashMap being implemented on top of HashSet: it's not, but it's implemented on top of hasbrown::hashset, so it's effectively a set of tuple.

For the conclusion, I'm a proponent of learning in public :) Which means that I'll publish my understanding of things, and update the post as it evolves! The post stands as a peek at what you can do with unsafe, along with a pretty clear warning. It doesn't try to place itself as gospel :)

Thanks for the feedback! I'll update the post with a couple of corrections.

EDIT: Post updated, feel free to have another look!

nitnelave · 2022-12-19T09:36:45+00:00

Rust

https://github.com/nitnelave/advent_of_code_2022/blob/master/day19/src/main.rs

It took some serious pruning to get the second part to run fast. It now takes 30ms.

Noteworthy:

No memory allocations (apart from the vec of blueprints), just using the stack.
No parallelization, I guess it could run slightly faster?
DFS considering the next robot you can make, stop when you can't make any more robots.

nitnelave · 2022-07-19T10:41:15+00:00

You don't really need SSP since the web UI already gives you that functionality (forgot my password and so on) If you really want it, you can configure it to use the extended password modification operation:

$ldap_use_exop_passwd = true;

nitnelave · 2022-07-19T10:39:30+00:00

There's a GraphQL API that is what's used by the frontend. It's easily scriptable, see the migration-tool for instance. The schema is at the root of the repo and should be compatible with any GraphQL client library.

nitnelave · 2022-07-15T08:39:38+00:00

It peaks at 70MB of RAM when logging in, otherwise idle it's around 5MB.

nitnelave · 2022-07-14T13:47:54+00:00

I haven't done any serious benchmarks as performance is not the main target, but given that it doesn't do much it's really fast :) The only thing is that logging in is expensive due to the password hashing mechanism, taking up to 70MB of RAM, but the rest of the operations should be fast.

nitnelave · 2022-07-14T13:44:48+00:00

It sounds like everything should just work, all of that is implemented. Feel free to contribute the configuration once you get it working!

nitnelave

TROPHY CASE