starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-25 16:25:55 +03:00

[GH-ISSUE #1196] [DOCS] Virtualhost support ? #427

New issue

Closed

opened 2026-02-27 08:17:14 +03:00 by kerem · 5 comments

kerem commented

2026-02-27 08:17:14 +03:00

Owner

Originally created by @selfhoster1312 on GitHub (Jul 4, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1196

I don't think it's clear from the docs whether lldap can support multiple vhosts and per-vhost admins. From what i've tested so far, i believe:

it's possible to create users on different domains by using the same key for username and email fields (this way you can have 2 accounts contact@foo.com and contact@foo.net, whereas you could not have two accounts called contact)
it's not possible to create multiple bases on LDAP side (ou=people,dc=foo,dc=net and ou=people,dc=foo,dc=com) unless running multiple instances of lldap
it's not possible to have custom permissions for a group, for example allow a group to add/edit/delete accounts matching a regex (eg. .*@foo.net$)

This is personal belief based on quick testing. Please correct this information with actual knowledge of the way lldap operates 😄 . I understand that lldap tries to stay minimalist and that's what brought me here. I believe however the answer to these questions should be added to the docs/FAQ.

Why it's important to me: as a member of several hosting non-profits, we try to provide reliable service to different collectives, each having their own vhost. We've been investigating replacing different existing stacks based on slapd, moulinette, or PAM (yes, with /etc/passwd integration) with a more modern/maintainable alternative. It's not a problem to run one service per vhost (although having proper vhost support in lldap would be easier) but i could not find documentation about this in the lldap docs.

Originally created by @selfhoster1312 on GitHub (Jul 4, 2025). Original GitHub issue: https://github.com/lldap/lldap/issues/1196 I don't think it's clear from the docs whether lldap can support multiple vhosts and per-vhost admins. From what i've tested so far, i believe: - it's possible to create users on different domains by using the same key for username and email fields (this way you can have 2 accounts contact@foo.com and contact@foo.net, whereas you could not have two accounts called `contact`) - it's not possible to create multiple bases on LDAP side (`ou=people,dc=foo,dc=net` and `ou=people,dc=foo,dc=com`) unless running multiple instances of lldap - it's not possible to have custom permissions for a group, for example allow a group to add/edit/delete accounts matching a regex (eg. `.*@foo.net$`) This is personal belief based on quick testing. Please correct this information with actual knowledge of the way lldap operates 😄 . I understand that lldap tries to stay minimalist and that's what brought me here. I believe however the answer to these questions should be added to the docs/FAQ. Why it's important to me: as a member of several hosting non-profits, we try to provide reliable service to different collectives, each having their own vhost. We've been investigating replacing different existing stacks based on slapd, moulinette, or PAM (yes, with /etc/passwd integration) with a more modern/maintainable alternative. It's not a problem to run one service per vhost (although having proper vhost support in lldap would be easier) but i could not find documentation about this in the lldap docs.

kerem

2026-02-27 08:17:14 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 08:17:15 +03:00

Author

Owner

@nitnelave commented on GitHub (Jul 4, 2025):

Your assessment is correct:

one base DC per instance
- the base DC is only in the config, it's not even stored in the DB
only 2 hardcoded OUs (people and groups)
the permissions are simple: only admin, password manager, or read-only, all at the global scope

Feel free to send a PR with some proposed documentation that you feel was missing!

@nitnelave commented on GitHub (Jul 4, 2025): Your assessment is correct: - one base DC per instance - the base DC is only in the config, it's not even stored in the DB - only 2 hardcoded OUs (people and groups) - the permissions are simple: only admin, password manager, or read-only, all at the global scope Feel free to send a PR with some proposed documentation that you feel was missing!

kerem commented

2026-02-27 08:17:15 +03:00

Author

Owner

@selfhoster1312 commented on GitHub (Jul 4, 2025):

Thanks for the quick answer.

I will definitely send a PR. The README is really long: i personally would be tempted to break it up into smaller pages (or at least smaller collapsible sections), or is it on purpose that it's so long? In the meantime, i could submit it in the "Recommended architecture" section: would this place be appropriate?

About the vhosts support, two questions:

can you see potential problems in using fully-qualified emails as username in the same base DC to mock proper vhosts (minus the fine-grained permissions per-domain)?
would vhosts support be accepted as a contribution, or is it considered out of scope for the project?

@selfhoster1312 commented on GitHub (Jul 4, 2025): Thanks for the quick answer. I will definitely send a PR. The README is really long: i personally would be tempted to break it up into smaller pages (or at least smaller collapsible sections), or is it on purpose that it's so long? In the meantime, i could submit it in the "Recommended architecture" section: would this place be appropriate? About the vhosts support, two questions: - can you see potential problems in using fully-qualified emails as username in the same base DC to mock proper vhosts (minus the fine-grained permissions per-domain)? - would vhosts support be accepted as a contribution, or is it considered out of scope for the project?

kerem commented

2026-02-27 08:17:15 +03:00

Author

Owner

@nitnelave commented on GitHub (Jul 4, 2025):

Vhosts are definitely out of scope.

For email/permission management, I'd refer you to the not-built-yet-but-in-progress plugin system where you'll be able to implement a simple Lua plugin to do what you want, refuse users with the wrong email, implement group permissions and so on

@nitnelave commented on GitHub (Jul 4, 2025): Vhosts are definitely out of scope. For email/permission management, I'd refer you to the not-built-yet-but-in-progress plugin system where you'll be able to implement a simple Lua plugin to do what you want, refuse users with the wrong email, implement group permissions and so on

kerem commented

2026-02-27 08:17:15 +03:00

Author

Owner

@nitnelave commented on GitHub (Jul 4, 2025):

Regarding the long readme, we have a docs folder with more files. I would be open to separating the readme into some files there (installation instructions, example configs, ...)

@nitnelave commented on GitHub (Jul 4, 2025): Regarding the long readme, we have a docs folder with more files. I would be open to separating the readme into some files there (installation instructions, example configs, ...)

kerem commented

2026-02-27 08:17:15 +03:00

Author

Owner

@selfhoster1312 commented on GitHub (Jul 6, 2025):

Addressed in #1201, thanks :)

@selfhoster1312 commented on GitHub (Jul 6, 2025): Addressed in #1201, thanks :)

kerem referenced this issue

2026-02-27 09:09:33 +03:00

[PR #427] [MERGED] build(deps): bump bumpalo from 3.10.0 to 3.12.0 #736