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