Feature: allocation_openldap

[ds-04]

Description

allocation_openldap - represent allocations in OpenLDAP. plugin work not started yet, not scoped out fully yet.

this issue takes over from #661 - since those changes are merged

work has not started on this and may not for some time

name	submitter/lead	code status	review status	dependency
allocation_openldap	DS/SL/CL	not started yet	N/A	project_code + project_openldap

Component

Other

Additional information

[cecilialau6776]

Just saw this - I have some prior art here: https://github.com/cecilialau6776/ldap_allocs and would be happy to migrate features to ColdFront proper

[ds-04]

Hi @cecilialau6776 , this looks good.

What do you think about integrating it with the project_openldap structure - such that a project's allocations sit within a per-project-OU. This would still be its own plugin for allocations. Perhaps the behaviour could be toggled to integrate into that or not - for sites who don't want to use project_openldap.

https://github.com/ubccr/coldfront/tree/main/coldfront/plugins/project_openldap#design

This would mean on project archival, the allocation(s) can also be deleted or archived (moved). Currently the project archival action (based on signal) works like that for project_openldap ... some extra code would be needed to deal with subordinates (allocations) as part of that action.

David

[cecilialau6776]

I'd be happy to consider that! Our center currently wants the only feature to be creating posixGroups without the added features of its own OU or integration with anything else, but if I can find the time, I'll gladly adapt the project to both work with mimic project_openldap's design with toggles for project_openldap integration and it using its own OU, as well as potentially adding that toggle to project_openldap as well.

[ds-04]

I can potentially help ... it might make sense for your code to be the bulk/basis of an allocation_openldap named plugin.

It might also be worth developing a management command to sync membership for allocations, should slapd be offline. There is one in project_openldap ... it isn't perfect and was quite a lot of work, but may be needed in production for sites.

[simonLeary42]

@cecilialau6776 @ds-04 it seems to me that project_openldap and ldap_allocs are not compatible with respect to how they handle ID numbers. project_openldap has a base offset and then blindly creates new entries based on the project index. ldap_allocs has upper and lower bounds and makes best effort to base new entries off of project index but backfills ID numbers in the event of a collision.

If allocation_openldap is to be based off of ldap_allocs, I think it should handle ID numbers the same way as project_openldap, to prevent admin confusion.

I will be hacking onto project_openldap allow an abitrary ID remapping to conform my site's existing LDAP records. I could upstream this feature, and then both project_openldap and allocation_openldap can accept an arbitrary python function for ID remapping, so the best effort / backfill algorithm can be bolted on. @ds-04 would you be open to a PR like that?

Note: I was able to configure openldap to ensure no collisions, but it will just cause the sync script to throw an error.

[cecilialau6776]

I agree - allocation_openldap should handle ID numbers the same way as project_openldap for consistency's sake. However, I think either an update to how project_openldap handles ID numbers or the option to have a custom python function for ID remapping would be great for centers who may need to consider collisions so that the sync doesn't throw an error.

[simonLeary42]

@cecilialau6776 @ds-04 It seems to me that project_openldap and ldap_allocs are not compatible with respect to how they decide when to sync. project_openldap requires you to run a management command as a cron job. ldap_allocs uses signals to apply the user's changes to LDAP as soon as they are made. I think I would prefer signals. If both use management commands, it's going to be complicated and annoying to get the order of operations right: allocation_openldapcan't create entries until project_openldap has created the OU, and project_openldap can't delete the OU until allocation_openldap has deleted the entries.

[cecilialau6776]

We'd like to keep allocation_openldap to not be dependent on project_openldap (i.e. I'd like an option for it to not require the OU created by project_openldap). Also, I think there's value in offering both signals and a management command - if a signal fails for any reason (like if the LDAP server isn't reachable), having a command to manually sync is much easier than finding a way to re-trigger the signal.

I have a little more time now and would be happy to help/migrate ldap_allocs to allocation_openldap.

[ds-04]

@cecilialau6776 @ds-04 it seems to me that project_openldap and ldap_allocs are not compatible with respect to how they handle ID numbers. project_openldap has a base offset and then blindly creates new entries based on the project index. ldap_allocs has upper and lower bounds and makes best effort to base new entries off of project index but backfills ID numbers in the event of a collision.

If allocation_openldap is to be based off of ldap_allocs, I think it should handle ID numbers the same way as project_openldap, to prevent admin confusion.

I will be hacking onto project_openldap allow an abitrary ID remapping to conform my site's existing LDAP records. I could upstream this feature, and then both project_openldap and allocation_openldap can accept an arbitrary python function for ID remapping, so the best effort / backfill algorithm can be bolted on. @ds-04 would you be open to a PR like that?

Note: I was able to configure openldap to ensure no collisions, but it will just cause the sync script to throw an error.

The [current] use of the PKID for the openldap project GID number, means there can never be a clash - as long as you have plenty of contiguous space to grow into.

Perhaps two modes are offered for the project GID numbering:

• the existing method which uses the PKID (this should be default as it is simpler)
• an alternative method that users arbitrary with backfill (new to be developed)

When allocation_openldap is used in conjunction with project_openldap, all openldap allocations would be subordinates of openldap projects - so I think the arbitrary + backfill is fine for this anyway, for allocations. As it should be possible to find an allocation using some ldapsearch from the base of the project.

[ds-04]

I agree - allocation_openldap should handle ID numbers the same way as project_openldap for consistency's sake. However, I think either an update to how project_openldap handles ID numbers or the option to have a custom python function for ID remapping would be great for centers who may need to consider collisions so that the sync doesn't throw an error.

Please see last reply in this thread, I think both PKID based openldap project GID numbering should be used (default) and arbitrary (to be developed for project_openldap).

[ds-04]

@cecilialau6776 @ds-04 It seems to me that project_openldap and ldap_allocs are not compatible with respect to how they decide when to sync. project_openldap requires you to run a management command as a cron job. ldap_allocs uses signals to apply the user's changes to LDAP as soon as they are made. I think I would prefer signals. If both use management commands, it's going to be complicated and annoying to get the order of operations right: allocation_openldapcan't create entries until project_openldap has created the OU, and project_openldap can't delete the OU until allocation_openldap has deleted the entries.

project_openldap does use signals.

The only time project_openldap management commands are used is when:

• you are checking setup - use the setup checker, management command
• you had a slapd outage, therefore you need to ensure Coldfront django and OpenLDAP are synced - so thats when the sync management command comes in

For project OpenLDAP there are multiple signals present to create project, add/remove members, remove project (which means delete or move to archive OU) etc. See the signals.py

[ds-04]

We'd like to keep allocation_openldap to not be dependent on project_openldap (i.e. I'd like an option for it to not require the OU created by project_openldap). Also, I think there's value in offering both signals and a management command - if a signal fails for any reason (like if the LDAP server isn't reachable), having a command to manually sync is much easier than finding a way to re-trigger the signal.

I have a little more time now and would be happy to help/migrate ldap_allocs to allocation_openldap.

Agree with this, allocation_openldap should be written in a way that it can both compliment project_openldap and also be run in a standalone mode, without project_openldap. Though if needed it can use functions from project_openldap.

I think a sync command would be needed for allocation_openldap for the exact same reason it is present in project_openldap, if slapd was unavailable for a period.