[jira] [Commented] (GUACAMOLE-1079) allow limit number of concurrent logins for organizational groups

["Nick Couchman (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GUACAMOLE-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116340#comment-17116340 ] 

Nick Couchman commented on GUACAMOLE-1079:
------------------------------------------

{quote}Concurrency limits apply only to balanced groups.
 ...
{quote}
Just a clarification, here - concurrency limits apply only to _connections made directly to_ balanced groups - they do not apply to connections made directly to individual connections within balanced groups.

As mentioned on the list[1], implementing the functionality requested, here, would be a relatively fundamental change in the way attributes are applied, basically making those attributes filter down to the underlying connections and connection groups in a way that currently does not happen at all within the Guacamole Client interface. Also, as I mentioned, I'm not opposed, just want to make sure that it's understood that the change being requested here is *not* as simple as saying "just apply the same limits to organizational groups as are already applied to balancing groups."

If we decide to go this route, I wonder if the most sane thing to do would be to introduce a third type of connection group, rather than modifying how either of the existing groups works?

[1] - [http://mail-archives.apache.org/mod_mbox/guacamole-user/202005.mbox/%3Cem90944368-0d96-41aa-a088-fb530bcd18bb%40desktop-n3440sj%3E]

> 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)