Turbovnc 3.0 and session manager problems

[kokoko3k]

To continue this: https://github.com/TurboVNC/turbovnc/issues/210

This is my attempt: went to: https://turbovnc.org/DeveloperInfo/PreReleases.

downloaded: TurboVNC-2.2.80-x64.exe turbovnc-2.2.80-jws.zip turbovnc_2.2.80_amd64.deb

1 Linux side (debian 9) uncompressed .deb archive in the test user home folder started ./opt/TurboVNC/bin/vncserver and set password as requested

2 Windows side: install TurboVNC-2.2.80-x64.exe as domain administrator logged in via test user started turbovnc and connected to the server he asked me abouy rsa key trust, hitted yes got the familiar ssh banner in a Window, hit ok, asked me for a password said me he cannot execute /opt/TurboVNC/vncserver -sessionlist

3 Linux side stopped vncserver execution modified vncserver script to echoing the exedir and it said opt/TurboVNC/vncserver (no leading slash) noticed the hadrcoded: $vncClasses = "/opt/TurboVNC/java" modified to the hardcoded $vncClasses = "/home/BIOLOGIA/iostudente/tvnc/deb/opt/TurboVNC/java"

4 Windows side Tried again as in #2, same error.

I'd rather prefer to not touch what is working now on the server and i think that "/opt/TurboVNC/vncserver -sessionlist" is hardcoded in the viewer (?)

4 Windows side tried to get some help from the documentation, found nothing. searched for "sessionlist" in github repo, found nothing (?) tried to pass -nosessmgrauto to vncviewer.bat, seems to have no effect searched for "nosessmgrauto" in github repo, found nothing again (?) modified the .bat, last line -> -> start /b "" "%JAVAW%" -Dsun.java2d.d3d=false -Djava.library.path="%~d0%~p0java" -jar "%~d0%~p0java\VncViewer.jar" -nosessmgrauto -reqarch amd64 %* tried again: same message.

Where am i supposed to pass args? and where to get a list of supported ones?

5 Linux side root:

mv /opt/TurboVNC /opt/TurboVNC.backup

    # cp /home/BIOLOGIA/iostudente/tvnc/deb/opt/TurboVNC /opt/ -a
test user (iostudente):
    /opt/TurboVNC/bin/vncserver

6 Windows side: Tried again and finally got something new, but not what i expected:

Seems an error in parsing something to me. Apart from the obvious: 1) the request to accept the identity key <-- it would be nice to provide a way to store it and dont' ask it again. 2) the ssh banner <-- it would be nice to offer a way to never show it again too 3) it would be nice to have a way to get a list of supported options for the viewer 4) how to install the server in a place differnt by /opt/ ?

If i start: /opt/TurboVNC/bin/vncserver -sessionlist i get what seems correct, just /opt/TurboVNC/bin/:1

[dcommander]

2 Windows side: install TurboVNC-2.2.80-x64.exe as domain administrator logged in via test user started turbovnc and connected to the server he asked me abouy rsa key trust, hitted yes got the familiar ssh banner in a Window, hit ok, asked me for a password said me he cannot execute /opt/TurboVNC/vncserver -sessionlist

That's the first problem. The session manager works through SSH, so it has to know the location of TurboVNC on the server. If TurboVNC isn't installed in the default location (/opt/TurboVNC) on the server, then you have to inform the viewer where it is installed. You can do that by setting the TVNC_SERVERDIR environment variable on the client machine. In your case, you should set it to /home/BIOLOGIA/iostudente/tvnc/deb. There is a companion system property (turbovnc.serverdir) that can be used instead of the environment variable, if you prefer. System properties can be set on a system-wide basis in the Java Control Panel (add -Dturbovnc.serverdir=/home/BIOLOGIA/iostudente/tvnc/deb under "Runtime Parameters".)

4 Windows side tried to get some help from the documentation, found nothing.

The pre-release page contains a link to the pre-release documentation: https://cdn.rawgit.com/TurboVNC/turbovnc/dev/doc/index.html The relevant environment variables and system properties are documented in Section 11.2. However, that same documentation should have also been installed on the client machine when you installed the pre-release viewer. The documentation does mention -nosessmgrauto in Section 6.1.

searched for "sessionlist" in github repo, found nothing (?)

Confirmed but not sure why. Maybe the GitHub search isn't searching the dev branch. It clearly shows up when doing git grep on that branch.

tried to pass -nosessmgrauto to vncviewer.bat, seems to have no effect

It works for me. If I pass that argument to vncviewer.bat along with -user {my_user_name}, Unix login authentication is used rather than OTP.

searched for "nosessmgrauto" in github repo, found nothing again (?)

See above. Not sure why GitHub searches aren't finding the dev branch.

Where am i supposed to pass args? and where to get a list of supported ones?

Passing -? to the viewer script will list the available args.

6 Windows side: Tried again and finally got something new, but not what i expected:

Yikes. Not sure why that's happening. I'll double check some stuff. Can you try again with the TVNC_SERVERDIR variable set as suggested, and without the modifications you made to the vncserver script?

Seems an error in parsing something to me. Apart from the obvious:

1. the request to accept the identity key <-- it would be nice to provide a way to store it and dont' ask it again.

Oops. The viewer should already do that, but apparently it doesn't. I'll look into it.

2. the ssh banner <-- it would be nice to offer a way to never show it again too

That's good feedback. I'll add a system property for this.

3. it would be nice to have a way to get a list of supported options for the viewer

You can do that by passing -? to vncviewer.bat.

4. how to install the server in a place differnt by /opt/ ?

See above RE: TVNC_SERVERDIR.

Thanks for the valuable feedback. I'll look into the issues you described.

[dcommander]

More notes:

• You don't need to start a TurboVNC Server session on the host when using the Session Manager. The Session Manager will automatically start a new session if none exists. Otherwise, it will display the dialog that lets you choose an existing session or start a new one. The idea behind the TurboVNC Session Manager is two-fold:
  1. Eliminate the need for users to manually log into the server with SSH in order to start a TurboVNC session (and also eliminate the need for a separate SSH client.)
  2. Eliminate the need for users to know which display number a particular TurboVNC session is listening on.
• I attempted to reproduce your procedure above but was unable to reproduce the parsing error. If you are still able to reproduce that error, then please pass -loglevel 100 to vncviewer.bat and send me the output. Enabling debug logging (-loglevel 100) in the viewer will cause the Session Manager to log the actual output from the server commands, which may reveal the source of the parsing error.

[dcommander]

1. the request to accept the identity key <-- it would be nice to provide a way to store it and dont' ask it again.

This has been fixed in both master (2.2.x stable) and dev (3.0 evolving.) It was a legitimate bug.

2. the ssh banner <-- it would be nice to offer a way to never show it again too

Added a new Java system property (turbovnc.sshbannerdlg) that can be used to control this behavior. It defaults to on in master (2.2.x stable), in order to preserve the previous default behavior. It defaults to off in dev (3.0 evolving), which makes the most sense for use with the TurboVNC Session Manager. When the system property is off, the SSH banner is displayed on the command line rather than in a dialog.

[kokoko3k]

• good: i've had to set set TVNC_SERVERDIR=/home/BIOLOGIA/iostudente/tvnc/deb/opt/TurboVNC, not /home/BIOLOGIA/iostudente/tvnc/deb/
• good: it was so kind to ask me to create the needed ssh folders missing on the target machine.
• good: it does not ask for the autenticity of the key on subsequent attempts anymore
• not so good: still the parsing error:

  Log setting: 100
  main: start called
  SessionManager: Opening SSH connection to host infserv64vmpve
  Tunnel: Could not parse SSH config file C:\Users\iostudente\.ssh/config
  SessionManager: Available sessions: 6610 (process ID) old priority 0, new priority 19

  ...but i think i understood why it happened; it depends on the commands every user executes by default in his login script. his bash_profile sources his .bashrc and in his .bashrc several commands does output something. the first that produces output is: renice -n 19 -p $$ && ionice -c3 -p $$ && schedtool -B $$ I think there is the need to find a way to skip executing them or parsing the right line, maybe adding a very complex header and grepping for it? (-edit- or just parsing the last line, not the first one?)

~~Anyway i was thinking that even if all of the bugs were sorted out, as it stands now, it does not help me with my use case, because if any user has to start his own vnc server, then i would still need to know what port to connect to (or what port is free to use to spawn another server), in order to resume (start and connect to) my session. (as a side note, i don't need to open multiple session per user, quite the opposite indeed; i want that an user can have no more than 1 single session) I think that there is the need for another process running on the server, on a pre-known port, that would list the sessions, or maybe i'm missing something about the logic of the session manager here.~~

-EDIT2- Wow, i've missed that the viewer can actually start sessions remotely, sorry :) So another thing that comes to mind, if not implemented, would be the ability to limit the maximum allowed concurrent sessions per user, i think this may be tricky. The only way i can think of is that the user's vnc server could read a configuration file on the server placed in /etc with settings the user cannot override.

[dcommander]

...but i think i understood why it happened; it depends on the commands every user executes by default in his login script. his bash_profile sources his .bashrc and in his .bashrc several commands does output something. the first that produces output is: renice -n 19 -p $$ && ionice -c3 -p $$ && schedtool -B $$ I think there is the need to find a way to skip executing them or parsing the right line, maybe adding a very complex header and grepping for it? (-edit- or just parsing the last line, not the first one?)

I'll look into that, now that I have a way to reproduce the issue.

Wow, i've missed that the viewer can actually start sessions remotely, sorry :) So another thing that comes to mind, if not implemented, would be the ability to limit the maximum allowed concurrent sessions per user, i think this may be tricky. The only way i can think of is that the user's vnc server could read a configuration file on the server placed in /etc with settings the user cannot override.

We already have such a configuration file-- /etc/turbovncserver-security.conf (the TurboVNC Security Configuration File.) It should be possible to implement your suggestion by using the proc API on Linux, which would allow Xvnc to determine how many instances of itself are already running under the current user account. The only hitch is that it may not be possible to distinguish between a TurboVNC session and other VNC sessions (TigerVNC, RealVNC, etc.) I've added a new feature request for this (#213), which is marked "funding needed".

[dcommander]

I tried several things in order to work around the parsing error:

• Piping the TurboVNC command lines through sed in order to prepend all of the command lines with [TURBOVNC], thus allowing the parser to ignore the output of other commands. The problem with this approach, however, is that the return status from the sed command takes precedence, so there is no way (at least no straightforward and shell-agnostic way) to detect a failure in the TurboVNC command (set -o pipefail works, but only if the remote user is running Bash, Ksh, or Zsh.)
• Modifying the vncserver script so that it prepends a string to the output of -sessionlist and -sessionstart, thus allowing the parser to ignore the output of other commands. The problem with this approach, however, is that it is impossible for the parser to tell the difference between an error message, which would be returned as the first output line on stdout or stderr, and the output of commands that might be executed in the various shell startup scripts.
• Modifying the parser so that it uses the existing -list and session startup modes in vncserver, which provide specific text patterns that the parser can search for. However, this approach suffers from the same problem as above, i.e. there is no way to tell the difference between an error message and the output of shell startup commands.
• Prepending all of the remotely-executed commands with bash --norc -c. However, it appears that Bash doesn't honor --norc except for interactive shells.
• Modifying the vncserver script so that it prepends all output, including from subprocesses (i.e. Xvnc) with a specific string. The problem with this approach, however, is that the Session Manager parser needs to sometimes parse error messages from prior versions of TurboVNC (for instance, in order to detect whether the server has a version of TurboVNC installed that supports -sessionlist and -sessionstart.)

I am at a loss for how to proceed. It does appear as if the final solution will require either:

1. a method of invoking commands via SSH without executing the shell startup commands on the remote system, or
2. a method of reliably filtering the output of the VNC commands while still capturing their return status.

[dcommander]

I think I found a way to do it, by remotely invoking Bash with -O pipefail and using the sed trick above. It's not pretty, but it seems to work. I'll do some further testing and let you know when I push the commit.

[dcommander]

As far as I can tell, all issues described in this bug report have been fixed. Unfortunately, Travis seems to have eaten my synced repositories, so there is no pre-release build with these changes yet, but they have been checked into the dev branch. I'll post up here when a PR build is available.

When it is feasible to do so, please re-test and let me know if something is still broken. I also welcome any further feedback regarding the intuitiveness of the interface, as well as any further ideas regarding how to filter the output of .bashrc when invoking commands via SSH.

[dcommander]

Pre-release build is up

[kokoko3k]

All seems to work flawlessly. You asked about usability; what comes to mind is that, once you open more than one, there is no way to identify the session you want to resume. (It is not useful for my particular use case, because i want just one session (max) per user, and so i will use my dumb script and not the session manager feature, even if it is super cool, but may come handy to other users/use cases.) For that, you could "stat" the process directory created under /proc and access the creation time, so that you could print the process start date under the session name. Now that i think of it, you were wondering in how to identify turbovnc server processes and discard other Xvnc processes. It would be not only useful to limit the number of allowed TurboVNC servers, but also to filter sessions presented by the session manager. Well, what about putting something into the process environment so that you can parse /proc/$pid/environ? Or maybe access /proc/$pid/cmdline... Another one, but maybe is tricky -and probably less important- is to display what sessions are already opened by a viewer.

[dcommander]

The Session Manager, in its current form, is intended to automate the existing TurboVNC workflow, and the existing workflow provides no way to distinguish sessions other than by their display numbers. Thus, your ideas are all very useful, and I've added them to #148, but they probably won't make it into the initial release of the Session Manager. However, you bring up a good point, which is that the -sessionlist feature in the server and the Session Manager parser need to be extensible in order to accommodate future expansion, and they currently aren't.