[dev.icinga.com #13193] Update group memberships upon deleting/editing a user from the database backend

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/13193

Created by joka66 on 2016-11-15 08:45:16 +00:00

Assignee: (none)
Status: New
Target Version: Backlog
Last Update: 2016-11-15 08:55:27 +00:00 (in Redmine)

---

When changing the user name, the icingaweb_group_membership relation is not updated. after changing the only administrator accout name and logoff/logon all the monitoring items disappeared -> had to set the icingaweb_group_membership manually in db.
Version icinga2 web 2.3.4

---

Relations:

• blocks #13193

[icinga-migration]

Updated by jmeyer on 2016-11-15 08:55:27 +00:00

• Tracker changed from Bug to Feature
• Subject changed from Changing user name don't update icingaweb_group_membership to Update group memberships upon deleting/editing a user from the database backend
• Category changed from UI to Authentication & Authorization
• Target Version set to Backlog

Hi,

thanks for your report. However, this is rather a feature than a bug as this functionality does simply not exist yet.

But it's surely something we'll consider for a future release!

Best regards,
Johannes

[icinga-migration]

Updated by jmeyer on 2016-11-15 08:55:44 +00:00

• Blocked set to 10373

[Thomas-Gelf]

@lippserd: shouldn't we fix this in our schema?

[Al2Klimov]

@Thomas-Gelf Shouldn't we support separate user/group backends?

[Thomas-Gelf]

@Al2Klimov: sure, I understand your point. Main use-case for that feature is SSO combined with LDAP/AD. It is for group memberships not under our "direct" control. I wouldn't go too far with this. Sure, someone might want to manage group membership for external users in the DB. But then I'd strongly opt for teaching our DB to learn and/or import those users. This feels a little bit dirty.

Other opinions?

[Thomas-Gelf]

@Al2Klimov: could also be evaluated in a dedicated issue, shouldn't hinder you from fixing this the way you proposed in your pull request.

[Al2Klimov]

@Thomas-Gelf Yes, it "feels a little bit dirty" to copy users "left-to-right" just to fix this "politically correctly". This brings yet another bunch of race conditions, redundancy and update delays.

[Thomas-Gelf]

This has nothing to do with politics. I've met environments with 600k users in AD. No way to manage membership in a foreign backend without a decent replication in place. Your fix is fine, the whole architecture could be improved - but that's beyond the scope of this issue.

[Al2Klimov]

Aren't all the LDAP directories known to be "fasfast as hell" compared to SQL RDBMSs? Or did I misunderstand something during my professional education?

[Thomas-Gelf]

Whether they are fat or not depends on the amount of data you put in there :D They usually have no problem with being fat, and they have been built focused on other things than RDMBSs have been. LDAP is scalable and has been designed with replication and distributed setups (even over weak/unreliable links) in mind. A distributed LDAP-setup is fail-safe and eventually consistent, optimized for read- and not for write-loads.

An RDMBS while of course being optimized for relations, puts it's focus on atomicity and various degrees of guarantees when it comes to parallel requests and transactions. Things LDAP usually doesn't bother at all. And, last but not least: LDAP is a tree, while an RDMBS is bad at building trees. But now we are more than OT.

[Al2Klimov]

Sorry @Thomas-Gelf, I made a typo (see correction above) which maybe bended my question as whole.

[Thomas-Gelf]

This definitively changes the question 😆 Still, the answer stands. And you're right, LDAP can be fast as hell for read-intensive applications. However, it still strongly depends on how your queries look like. As soon as they're not pointing to DNs or similar, they must have fitting indexes as well. An RDMBS can easily outperform LDAP for many workloads, but will of course have no chance once tree-based lookups come into play.

So, there is no perfect data store out there. Everyone has it's use cases, it's strong sides and it's drawbacks. You have to choose the right tool for the right job. This might leave you with different tools for different jobs - and the task to somehow keep them in sync. That might then lead to compromises on the left or right, as less non-perfect tools together could be faster than more perfect tools with related glue.

So, the statement LDAP being "fast as hell" compared to an RDMBS doesn't stand a closer look, but is of course true for some specific use-cases.