-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-think the architecture #71
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At the moment FUM has two databases, LDAP and SQL. Parts of the data are in LDAP, parts in SQL. Some things are probably stored in both. In case of failure it's possible that only one of the databases is modified.
For example when adding new user the user information is first written in LDAP, then to SQL database. If writing SQL database fails, the user entry will stay in LDAP but the user is not visible in FUM web interface. This causes additional failures if admin tries to add the user again.
I propose modifying FUM so that there is a single master SQL database where FUM stores all the information. Then there would be a smaller sync utility that copies the data from SQL to LDAP. In case of failures it would be easy to just delete whole ldap database and resync everything from SQL.
One alternative solution would be to use for example https://jumpcloud.com/ as user directory and just rewrite FUM as an user interface to Jumpcloud. Jumpcloud would then be the master database and offer the LDAP functionality out of the box.
These changes would make FUM a little simpler and especially easier to develop as the requirement for having a ldap database would be eliminated.
The text was updated successfully, but these errors were encountered: