Can I transfer a user session to another agent?

ThinLinc
, ,
1

Hi there,

is there a way to transfer a user’s session from one agent to another or, alternatively, force specific users to always get a session on a specific agent?

Right now, we have a setup with 2 agents and have to rely on chance (or rather, ThinLinc load-balancing) which agent a user gets assigned to. Some of our users need a specific piece of software which is only available on one of the agents, due to expensive per-machine licensing. Is there a way to ensure that some users always get to agentX vs agentY (or alternatively, have an admin transfer their session if they land on agentY)?

Thanks in advance!

2

Hello @sswirski

Regarding your first question, if sessions can be migrated between agents, the answer is no, they cannot.

But it’s possible to pin specific users, or even groups of users to a specific agent, using the subcluster feature of ThinLinc.

You will define a set of agent servers per subcluster, and for each subcluster you can then assign either groups=bar or users=foo

I hope this will help you move forwad.

Kind regards,
Martin

3

Perfect, that sounds exactly like what I need, thanks! I’ll check this out!

4

I found it in the config! Right now, we only have a default subcluster which contains both agents and only has the “groups” option set (to the LDAP group that contains all our ThinLinc users).

So, I would now split this into a default subcluster (with only agent01) and a “special software” subcluster with agent02. Putting the same group for both subclusters but additionally add three specific users to the “special software” one would work, right? Same group on different subclusters does not appear in the “undefined behaviour” note, but in the config sample from the docs it defines two different groups for each of the subclusters (us.cendio and india.cendio). For our case I would need the “all-thinlinc-users” group from our LDAP on both subclusters and only 3 users additionally on agent02.

5

Almost. Our documentation states:

  1. If a user is a member of two user groups which are used for two different subclusters, it is undefined which subcluster the new session will be created on.

I would try configuring the default subcluster with both agent01 and agent02, and then the “special software” subcluster would only have agent02.

However, it should be noted that having the same agent in multiple subclusters is something we have not fully tested. You will get a warning about this in vsmserver.log, but looking at the code logic indicates that it should be fine in theory.

I added this bug for clarifying things for your use case.

6

Thanks for the bug report!

  1. If a user is a member of two user groups which are used for two different subclusters, it is undefined which subcluster the new session will be created on.

Oh I wouldn’t create a new group for the “special software” users, I would add them just with their usernames since there are only 3 of them, so something like:

[/vsmserver/subclusters/Default]
agents=agent01.domain.de
groups=all-thinlinc-users

[/vsmserver/subclusters/special]
agents=agent02.domain.de
users=user1,user2,user3
groups=all-thinlinc-users

Would that not work if user1, user2 and user3 are also in all-thinlinc-users? My goal is that user1-3 always get agent02 and all other ThinLinc users get load-balanced.

7

I don’t believe that will work since load balancing happens within each subcluster. I would suggest configuring it like this:

[/vsmserver/subclusters/Default]
agents=agent01.domain.de agent02.domain.de
groups=all-thinlinc-users

[/vsmserver/subclusters/special]
agents=agent02.domain.de
users=user1,user2,user3
8

Perfect, I’ll try this out, thanks!