Jason Keltz created GUACAMOLE-1079:
--------------------------------------
Summary: allow limit number of concurrent logins for
organizational groups
Key: GUACAMOLE-1079
URL: https://issues.apache.org/jira/browse/GUACAMOLE-1079
Project: Guacamole
Issue Type: New Feature
Components: guacamole
Reporter: Jason Keltz
Concurrency limits apply only to balanced groups. This is the way Guacamole
works right now. I'm using organizational groups for a variety of reasons. I
would still like to limit the number of simultaneous logins in an
organizational group.
My lists of reasons for using organizational group:
1) I've seen cases where-by a student connects to a system that looks to be
available to Guacamole, but there are underlying issues with that system so
it's not *really* available. For example, on one Windows system, it would
accept a username and password, and hang in the login process because there was
some temporary issue with networking (resolved after a reboot). There have
been other similar problems as well. Because that system was "available",
Guacamole doesn't know it's not really available. As a result, a student would
get that system when logging in and would potentially be stuck with that
system. With organizational group, the student could try one system, see it
doesn't work, and then try the next system which likely will be fine. It's not
ideal, but it makes sense to me.
2) This second scenario likely doesn't affect many people. I need to be able
to reserve certain systems for certain classes at certain times. Even though
there are say, 100 systems in one group, maybe I may need to reserve 10, 40, or
50 of them at different times. The rest of the systems are available for
everyone. Since the amount of systems to be reserved differs based on the
students in the class, and course requirements, it's difficult to build a group
specifically for the hosts to be reserved (without playing the game of moving
hosts into different groups for the duration of the reservation - something
that I definitely considered doing, but would rather not do). With a balanced
group, if the user gets a system in the group that they are not allowed to
access at this point in time - a system that is up and available in every other
way - they will be stuck, even though there may be 50 other systems they can
use! I understand that the systems in the balanced group are all supposed to
be available to the user. I can't guarantee that. At least if I use an
organizational group, I can pop up a message that says - "Sorry - you can't use
host 1-50 right now , but host 51-100" are available for your use. With a
balanced group, they would be stuck.
3) Another unique scenario that affects me is one that I mentioned on the Guac
mailing list before. This is the case where I had users in one of my initially
balanced groups logging into guac with their individual AD credentials, but
then guac would login to xrdp with one common user ("user"). This environment
is setup a certain way, and configuration reset between logins. I had an issue
here where-by because the login via xrdp was the same on all systems, if a user
was disconnected from one session, someone else could connect and take over
their session. One way that was recommended to me to solve this problem was by
terminating disconnected sessions. Given the nature of the environment (ie.
that the student will lose their work if the environment resets), I didn't have
the heart to logout disconnected sessions. I fixed the identical user issue
by allowing logins from these AD accounts into the system, but then switching
the "common" user during the login session. Now, if a user was disconnected,
another user couldn't come along and get *their* session, but they *could* come
along and get their *host* (because on another discussion, I understood that
Guacamole allows another user to connect to a host with a disconnected
session). I dealt with this problem by making it so that it only allows the
user who disconnected from the session to reconnect. If a different user
connects to that host, it tells them that the system is presently unavailable
and with a list of other hosts that are available. It gives 10 minutes for the
original user to come back before terminating the session (and keeps their data
which I can restore separately if they come back later). With a balanced
group, if a user tries to connect to a host with a disconnected session, even
if other systems were available, they wouldn't be able to connect to them.
4) With balanced groups, I believe at least the history shows the user as
connecting to the "balanced group" name and not the individual host within the
group. I already have to deal with vague requests like "my machine is not
working properly". It makes it harder for me to debug. By using the
organization group, the history shows me where the user was logged in. It
saves extra back and forth with the user trying to figure out which machine
they were using - a detail they probably forgot anyway.
I understand that all of these scenarios are not necessarily the typical use
case. I am submitting this here as a placeholder. Maybe other people will
have similar requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
