See issue 13279, for example (this has been flagged a number of other times as well, though). If we can motivate the work somehow, then perhaps we should try to find a solution for this.
Ideally we would like to improve the "vncconfig" protocol to get a better view of connected clients, but we probably do not have time for that now. A quick-and-dirty solution is logging something to xinit.log that our scripts can trigger on.
At the risk of stating the obvious, the problem here is that we monitor for any and all connections to the Xvnc port, not just ThinLinc connections. Distinguishing between these two either requires some fairly fundamental changes, or a hackish workaround.
See also bug #37. Our Xvnc actually supports the QueryConnect flag, however it doesn't work as expected. After launching Xvnc with this flag and attempting to connect as the first client, the connection is closed with the message: "Unable to query the local user to accept the connection." One theory behind this is that the QueryConnect code is an artefact from the VNC server code, which expects there to be a local user available to acknowledge *all* connections. In our case, of course, there is no local user, so this is never going to work. In WinVNC there is an additional flag, QueryOnlyIfLoggedOn. This *sounds* like what we want; i.e. only query if there is currently a user logged on already. However this flag doesn't seem to be available outside of WinVNC, and may not do what we want anyway. Sounds like we are back to a quick and dirty solution - probably using tl-shadow-notify to parse xinit.log.
We think we can do this by monitoring xinit.log for connects and disconnects. Will send time estimate to Hällsberg.
Hällsberg wants us to do this. We will be using the technique mentioned in comment #5 above.
Fixed in r25635/r25636. We should really do this properly one day (bug #37), but this will do for now. Script has been changed to parse xinit.log for Xvnc connect/disconnect strings rather than using netstat. It has also been modified to not tell the user "You are no longer being shadowed!" when someone disconnects, as there may be multiple shadowers. Tester should test handling of multiple shadowers. Closing.
It seems that we're going to need a custom string to parse for, rather than something which is already being logged. Re-opening.
(In reply to comment #8) > It seems that we're going to need a custom string to parse for, rather than > something which is already being logged. Re-opening. Done in r25638.
Tester should also check if there needs to be anything added to the documentation regarding the new functionality (handling of multiple shadowers).
Works fine, even for multiple shadowers. Tried telnet against the VNC port, and a full vncviewer. Neither triggered a false notification. Documentation looks fine.
