It would be interesting to determine how many logged in users are sitting idle (and for how long) on the SSOHub; it's not clear whether the idle column in 'w' command correctly reflects actual non-activity correctly during a GSISSH session from the SSOHub to a remote SP login node, but for other login sessions that are idle in a BASH session, perhaps (a) they should get dropped after a reasonable length of idle time, and (b) they shouldn't get counted as active users on the system in other stats.
- Derek
Delivery Effort Stage:
Hey Derek,
Dropping idle login sessions after a reasonable length of time is a good idea. That is an operational configuration change that will affect the simultaneous sessions this activity proposes to track, but I don't think that making the change is in scope for this activity. You can just recommend it to the administrator(s) and it can happen anytime.
I suspect that login processes are what consume more limited resources and not whether those processes are shuttling keyboard input/output between the client and the target SP login nodes. Our only requirement is to know how many users are using the service and how frequently. Whether those sessions are idle or busy isn't too important.
Thanks,
JP
The login node is not currently under stress with the number of users logged into it. To drop "really idle" login sessions will require some thorough testing to make sure that we don't accidentally drop connections for users doing something useful. We could leave it as is, but it may be worth counting "user sessions currently (gsi)sshing to XSEDE resources from the SSOHub" as a value separate from "number of user (session)s currently logged into the SSOHub."
- Derek
Derek, you appear to be proposing new metrics for this activity of the form "number of user sessions currently..." which is confusing to me, because I think of metrics as counting something over a period of time (monthly, annually), not point-in-time ("currently"). The XCI-185 design includes a metric of "Maximum number of simultaneous SSO Hub sessions during this period (to understand load)". Are you proposing a metric to track people who log in to the SSO Hub and don't actually gsissh anywhere? Does that really happen?
I'm not proposing any new metrics. I have observed (but not measured) over time that a number of user logins on the SSOHub sit idle in a BASH session without a current gsissh going anywhere. As a result, the number of current logins to the SSOHub does not reflect the number of logins from the SSOHub to remote XSEDE resources; If the number of gsissh connections from the SSOHub to XSEDE resources are to be measured, then the actual number of gsissh commands running should be counted.
The number of long-idle BASH sessions on the SSOHub suggests (out of scope for this activity) that perhaps we should investigate how best to drop these long-idle login sessions to reduce security exposure of an unattended login.
The number of gsissh connections over a period of time is covered in the metric:
"Number of users who logged in to each SP system via the SSO Hub during this period".
I will modify the script that generates the above to also display a total of the above. Thanks.