When a user reconnects to an existing session, any previous connection gets killed when vsmagent is cleaning up the tunnel ports. The visisble user experience is that you cannot be connected with more than one client at a time. However, if you disable all local resources, there will be no ports to free, so existing connections will be left alone. In other words, you can have multiple terminals controlling the same session simultaneously. This behaviour is very inconsistent and confusing. We should be terminating existing connections even when there are no ports to free.
Maybe we also need to add a bug to make the sharing behaviour always work? E.g. we could code the system to always allow a user to shadow himself. That would also solve the issue of multiple local resource as the shadowing connections wouldn't bring any local resources.
*** Bug 5061 has been marked as a duplicate of this bug. ***
Quoting from bug 5061: > When you log in to a session, any connected native clients are disconnected > from the session. > > When you log in to a session, any connected HTML 5 clients remains connected to > the session.
The current behavior is a side affect for another mechanism (unbindports) which is used for ensuring that no-one is listening on the ports used for a session tunnels. We need to create a new mechanism for detecting connecting clients (not shadowers) which works for both the native and HTML5 client.
Reopening due to: * Autotests not fully working * I'd like a comment in SConnection.cxx about why we are changing the order of setAccessRights and queryConnection. * Awaiting feedback wrt code style / duplicated code.
(In reply to comment #11) > > * Autotests not fully working > Fixed in commit r31139
(In reply to comment #11) > * I'd like a comment in SConnection.cxx about why we are changing the order > of setAccessRights and queryConnection. > This change is now commited upstream and brought into CTC with commit 31143.
(In reply to comment #11) > * Awaiting feedback wrt code style / duplicated code. > - Commit 31145 removes the inline if statement. - Commit 31146 refactors handler_reqsession to reduce code duplication.
I've found a problem: 1. Start a new session using the HTML5 client. 2. Shadow the session with the native client. 3. Reconnect to the session with the HTML5 client. Expected: Connection from step 1 should be disconnected. Observed behavior: Connections from steps 1 and 2 are disconnected. In other words, there are cases where shadowers are disconnected when a user reconnects to their sessions.
(In reply to comment #18) > I've found a problem: > > 1. Start a new session using the HTML5 client. > 2. Shadow the session with the native client. > 3. Reconnect to the session with the HTML5 client. > > Expected: > > Connection from step 1 should be disconnected. > > Observed behavior: > > Connections from steps 1 and 2 are disconnected. > > In other words, there are cases where shadowers are disconnected when a user > reconnects to their sessions. After more investigation, we've found that this is not a new problem. It also affects the native client. I've added bug 5795 for this problem.
I've verified that existing connections (from both HTML5 and native clients) are disconnected when you reconnect to a session, independent of local device exports. Great!
*** Bug 5835 has been marked as a duplicate of this bug. ***
We forgot to audit other users of the vncpasswd file to make sure they only read the first 8 bytes. Local drives are broken as a result, and there might be more issues.
(In reply to comment #22) > We forgot to audit other users of the vncpasswd file to make sure they only > read the first 8 bytes. Local drives are broken as a result, and there might be > more issues. Other users of vncpasswd was fixed but it seems that tl-mount-localdrives was missed. Commit 31375 fixes the read of vncpasswd.
(In reply to comment #24) > Other users of vncpasswd was fixed but it seems that tl-mount-localdrives was > missed. Commit 31375 fixes the read of vncpasswd. Local drives work. Tested exporting/reading/writing against server build 5093.
