Combine ldap and userdb provisioners

[frafall]

I have a ACCOUNT_PROVISIONER set to ldap (using lldap) and it's working great.

BUT, I only have people in ldap and need some system accounts so I'm lookup into combining the functionality of ACCOUNT_PROVISIONER=file as well.

Reading through the scripts it seems to me they are all based on either-or as ACCOUNT_PROVISIONER only takes one value.
So, looked to add overrides in my user-patches.sh.

But it seems to me this is pretty hard coded, ex in account.sh - _create_accounts there are side effects of checking the value of ACCOUNT_PROVISIONER as well as modifying the 10-auth.conf to use file userdb which makes it hard to call in user-patches.

Am I barking up the wrong tree and not seeing the obvious way to combine file/ldap provisioning?

In general I would like to suggest that the ACCOUNT_PROVISIONER=file functionality should be enabled in ALL configurations, not be disabled on ldap/oauth. If not used it generally does not influence the operations and having the option to add accounts outside of ldap/oauth adds a lot of flexibility.

In my organization we only have 'real' people in the ldap database but there are loads of applications that needs a mail account, these we traditionally have implemented outside of ldap.

[polarathene]

Am I barking up the wrong tree and not seeing the obvious way to combine file/ldap provisioning?

The project is mostly maintained. We respond to bug reports and keep the software updated. Rarely do we get features contributed, nor do the current maintainers have much time to invest in developing DMS, so it's more of a goal just to keep everything working and improve here and there over time.

LDAP was contributed by a user some time ago and had various support issues. I've refactored it, but been lacking the time to get that PR fully resolved so it can be merged. Similarly there's interest in SCIM + OAuth (which is what spurred the ACCOUNT_PROVISIONER ENV, but prior there was similar logic keeping LDAP and FILE provisioners separate).

For the most part you're probably right that it should be possible to support, I've not got the time at the moment to go over everything related to that in DMS but you're welcome to explore it.

The project itself does get the existing code base cleaned up and refactored over time, and I have been pushing the test suite and docs quality to improve when I can, along with addressing long standing issues. Improving the account management situation is one of those.

---

You're welcome to investigate this and I can assist with any minor changes necessary for user-patches.sh support, then in future we can look into supporting more than one provisioner as I'd need to consider the impact of that beyond your own configuration/use-case.

For example I know we presently have check-for-changes.sh service disabled for LDAP, but I'm rather confident we can drop that constraint with some changes. The SPOOF_PROTECTION=1 feature also conditionally handles a setting based on FILE or LDAP provisioners.

modifying the 10-auth.conf to use file userdb which makes it hard to call in user-patches.

I recall something related to this for the OAuth2 support I think. Our docs also have a user contribution example for an alternate Dovecot auth method with Lua, and I wanted to do some refactoring to simplify how we manage/support these. I also want to add support for database provisioner support with Postfix/Dovecot, so it's definitely something I'm wanting to resolve, but it will take a while until I can prioritize it.