[
https://issues.apache.org/jira/browse/GUACAMOLE-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116753#comment-17116753
]
Jason Keltz commented on GUACAMOLE-1079:
----------------------------------------
When you have the time, I'm interested in hearing your thoughts on what this
third type of connection group could potentially be....
> 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
> Priority: Minor
>
> 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)
