Open sbesson opened 2 years ago
Tested on a local omero server with 61 users in 79 groups.
The script is working without problems, the situation before
The group with ID 79
was used as graveyard
group in the test. The setting of necessary inactive days was 300 (this is a not-often used server and DB). This singled out user-3
(very plausible, the most used user) as active
. The script also omitted root
, Guest
and the logged-in user (user-6
).
See the output of the script below
After the run of the script, the output of group list
and user list
was
which is plausible imho. The login of user-3 and user-6 and root went fine, the login of user-4 was blocked as expected.
In summary, I think this is a very useful script.
Nevertheless, in larger production systems, it must be executed with caution, indeed, it would make a good sense to have a reverse all back to original state
provision in the script - the error (for example putting in too low inactive days number, or having the named users list which should not be inactivated incorrectly) can cause a maintenance problem.
At least there should be a
Proceed:y/N
prompt after the facts were gathered and displayed before the script executes the move.
Definitely good to have the pre-run of the script captured first.
@sbesson : When consulting the workflow with @will-moore , an important consideration came up. If we delete users, and the deleted user is logging in again using LDAP, this will re-create their account and they will have no detrimental user experience. This is not a given for the workflow of the graveyard
group suggested here. The disabled user
graveyard
group (in case we would tailor the script not to disable the users)The test on a local OMERO and OMERO.web clearly shows that
graveyard
group using the script here.The RHP load speed is:
This is an improvement of more than order of magnitude, but mainly, it also completely restores the feeling of responsiveness in webclient for a user using the UI to acceptable levels.
I think this shows that the script would be very useful, except for https://github.com/ome/prod-playbooks/issues/363#issuecomment-1224111856
Note that the slowness is not perceived by an admin which is not a member of the group where the data are located. Unfortunately, unless we adjust the permissions of all the relevant users to be restricted admins on the learning system, we cannot exploit that quirk I guess...
A new idea: the https://github.com/ome/prod-playbooks/issues/363#issuecomment-1224111856 could be solved by forcing the graveyard
user to unhook from LDAP, and changing its loginname. In this way, when the same LDAP user logs in again, the account will be re-created ? What do you think @sbesson ?
Interesting and the approach makes sense to me. I assume we will have to handle the scenario where an archived LDAP user is recreated and archived a second time as it might lead to name conflict.
Note the current maintenance process i.e. the deletion of old users with no associated data via a custom SQL script, meets the minimal requirements in terms of restoring performance of a system with a growing number of temporary users in a single group. The workflow discussed above would have the benefit of keeping the users in the DB which offers advantages mostly in terms of reporting as it allows to introspect historical data while collecting usage metrics.
The UoD SLS learning system is getting heavily used during the academic term with new students logging into the resource using their University credentials and being mapped into the default group containing the course supporting data to allow access - see https://github.com/ome/prod-playbooks/blob/b2e01370ca4d47b95176302cd414fa279b10a5a3/omero/learning.yml#L57-L61.
Eventually, many teaching semesters lead to the creation of several 100s of users in the single group. This causes performance degradation on the OMERO.web deployment as several of the queries start to run more slowly.
At the moment, the OME team runs periodically ad-hoc maintenance scripts on the system to reduce the number of users in the group. On the image.sc forum, a similar problem was discussed with a script being shared which allows to move stale users into a "graveyard" group - see https://forum.image.sc/t/omero-user-scripted-inactivation/70767/3.
For the next maintenance, we might want to evaluate whether this script could be adapted to the requirements of the SLS learning deployment and used to move students from the former year to another group to restore performance.