Thanks Geoff looks like it might have been a geat tip. I uninstalled all of compiz on the main client pc and also set the ssvnc viewer to autoseek the correct display on each connection and now able to succesfully connect to all w/s simultaneously. I assign each one's terminal session and x display to it's own unique workspace and in effect I change actual machine control and monitoring from their own workspace.
Appears to work well so far, although the one screen is pretty large and I will need to find the way to correct the display resolution on it's remote connection. Right now I have created wallpapers that have each local machines' hostnames clearly visible but running a separate instance of RD on each w/s it could be possible to control and monitor multiple studios remotely after hours, say in an unattended midnight hour situation. Right now this was only research as a possible fix to replace outdated busmouse and bus kybd kvm switches when I can't dig up surplus bus mouses any more. Thanks again for your tip On 15/11/12 06:00, Geoff Barkman wrote: > > You might have disable compiz. With that enabled vnc is pretty hopeless. > Cheers > Geoff > > sent by geoff on his android phone > > On Nov 15, 2012 6:14 PM, "VE4PER/ Andy" <ve4...@aim.com > <mailto:ve4...@aim.com>> wrote: > > One thing I have discovered with all this excercise is that when > the 64 > bit vers of studio 12.04LTS locks up and freezes on the local > machine I > can avoid the freeze ups by logging on and running the 64 bit machines > via the remote x sessions; have yet to be able to duplicate the freeze > ups this way. > > when they freeze they lock out CTRL-ALT-Fx so you can't log in to > a term > session and do an init 6 orderly shutdown. I doubt that I would be > able > to log in using a remote session to get out of the lock either, but > might have access still if I was logged in on a remote session when > fault occurred; yet to be confirmed though. > > > On 14/11/12 22:57, Geoff Barkman wrote: > > On Ubuntu there is also GSTM - Gnome ssh tunnel manager that you can > > graphically do the ssh tunneling and save settings so you don't have > > to type in long commands in the terminal. Its available by the > Ubuntu > > package manager or you can download directly from sourceforge > > http://sourceforge.net/projects/gstm/?source=directory > > > > On Thu, Nov 15, 2012 at 11:17 AM, Florent Peyraud > <f...@electronet.org <mailto:f...@electronet.org>> wrote: > >> Hello > >> Le 12/11/12 18:52, Fernando Della Torre a écrit : > >> > >> Hi there! > >> > >> If you're under ubuntu you can enable the remote desktop (VNC > kind) and use > >> it through a SSH tunnel. > >> > >> We in Tryphon are almost using this method, but to avoid having > to tune our > >> customer's internet modem/router in order to open their SSH > port, we usually > >> ask them to SSH toward a special 'box' account on our > infrastructure with a > >> special command line so that all useful ports are 'tunnelled'. > For example > >> from the target rivendellAllbox they could type : > >> > >> ssh -p 2722 -N -R2222:localhost:22 -R8888:localhost:80 > -R5901:localhost:5900 > >> b...@support.tryphon.eu <mailto:b...@support.tryphon.eu> > >> > >> Doing this, we can log on our support server, then connect > locally to ports > >> 2222, 8888 or 5901 to access respectively remote SSH, HTTP or > VNC servers. > >> And for our headless boxes, they can do the same, even from > MacOS X or > >> Windows (with putty) with something like : > >> > >> ssh -p 2722 -N -R2222:streambox.local:22 -R8888:streambox.local:80 > >> b...@support.tryphon.eu <mailto:b...@support.tryphon.eu> > >> > >> The -N option allows to establish the SSH connection even if > the 'box' > >> account has /bin/false as shell in the /etc/passwd file > >> > >> As you may imagine, this method suffers from different problems > : one could > >> try to squat all ports on our server, For the time being, this > has never > >> append, but we already think of something to randomize the > connection port > >> for each connection, or map it to our server only when a remote > support is > >> scheduled... We are not short of ideas ;) > >> > >> Hope this can help > >> Best regards > >> > >> Florent > >> > >> > >> > >> > >> > >> Atenciosamente, > >> > >> > >> > >> Fernando Della Torre > >> > >> Tecnologia da Informação > >> > >> (: +55 16 8137-1240 <tel:%2B55%2016%208137-1240> > >> > >> (: +55 16 9137-2886 <tel:%2B55%2016%209137-2886> > >> > >> *: f...@vdit.com.br <mailto:f...@vdit.com.br> > >> > >> V.D.I.T. Soluções em Virtualização > >> > >> > >> > >> > >> > >> A utilização deste e-mail não implica em autorização ou outorga > de poderes > >> para seu usuário praticar qualquer ato em nome das empresas > citadas, cuja > >> representação considera-se válida se praticada exclusivamente por > >> representante legal ou procurador devidamente constituído, na forma > >> estabelecida em seu respectivo estatuto ou contrato social > >> > >> > >> > >> > >> 2012/11/12 Andy Sayler <a...@wmfo.org <mailto:a...@wmfo.org>> > >>> Hi Andy, > >>> > >>> To the best of my knowledge SSH is not designed for "Screen > Sharing", and > >>> provides no way to do it. > >>> > >>> When you connect to a remote machine via SSH, you are creating > a new user > >>> session, completely separate from any local user sessions (or > other remote > >>> session) already running on the remote machine. When you use > SSH with X > >>> server forwarding (the -X option), the GUIs are actually being > generated on > >>> your local machine, not on the remote machine at all (in fact, > the remote > >>> machine need not even have X installed). The combination of > the fact that > >>> each SSH session is isolated from other user sessions, and the > fact that X > >>> over SSH runs locally means that there is no way to "screen > share" using > >>> SSH. > >>> > >>> Some terminal multiplexers (i.e. GNU Screen) will allow you to > perform > >>> terminal "screen sharing" between multiple users, and you can > use this in > >>> conjunction with SSH to share your shell, but I don't believe > the sharing > >>> capabilities extend to X sessions and GUIs. > >>> > >>> If you want a traditional GUI "screen sharing" experience, > you'll probably > >>> need to seek out a program designed for that purpose like > TeamViewer or > >>> another remote help/desktop app. If you use Google Chrome, it > also offer a > >>> multi-platform remote desktop/sharing app: > >>> > > https://chrome.google.com/webstore/detail/chrome-remote-desktop/gbchcmhmhahfdphkhkmpfmihenigjmpp. > >>> Some versions of VNC may also support this functionality, but > I'm less > >>> familiar with that. > >>> > >>> In short, SSH isn't really designed for sharing your session > or screen > >>> with local users. You'll have to look for another program if > you want to do > >>> that. > >>> > >>> Good luck, > >>> Andy > >>> WMFO > >>> a...@wmfo.org <mailto:a...@wmfo.org> > >>> www.andysayler.com <http://www.andysayler.com> > >>> > >>> > >>> On Mon, Nov 12, 2012 at 10:09 AM, VE4PER/ Andy <ve4...@aim.com > <mailto:ve4...@aim.com>> wrote: > >>>> Has anyone used ssh connection to actually view a remote > desktop as a > >>>> way to see and trblshoot w/s problems? > >>>> > >>>> I use ssh -a -X userid@IPaddress with server running in the > w/s allowing > >>>> login. It gives me terminal access in real time and allows me > to run new > >>>> instances of window/GUI pgms remotely, however I am not able > to actually > >>>> see or share the existing desktop. > >>>> > >>>> Is there something wrong with the syntax I am using to gain > remote > >>>> desktop GUI access and control to be able to be more > assistance to the > >>>> remote operator? > >>>> > >>>> Have used other viewers as well, yet seem only to be able to > run in > >>>> console mode or X displays of specific applications rather > than viewing > >>>> full desktop? > >>>> > >>>> Thanks > >>>> > >>>> Andy > >>>> _______________________________________________ > >>>> Rivendell-dev mailing list > >>>> Rivendell-dev@lists.rivendellaudio.org > <mailto:Rivendell-dev@lists.rivendellaudio.org> > >>>> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > >>> > >>> > >>> _______________________________________________ > >>> Rivendell-dev mailing list > >>> Rivendell-dev@lists.rivendellaudio.org > <mailto:Rivendell-dev@lists.rivendellaudio.org> > >>> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > >>> > >> > >> > >> _______________________________________________ > >> Rivendell-dev mailing list > >> Rivendell-dev@lists.rivendellaudio.org > <mailto:Rivendell-dev@lists.rivendellaudio.org> > >> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > >> > >> > >> > >> _______________________________________________ > >> Rivendell-dev mailing list > >> Rivendell-dev@lists.rivendellaudio.org > <mailto:Rivendell-dev@lists.rivendellaudio.org> > >> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > >> > > _______________________________________________ > > Rivendell-dev mailing list > > Rivendell-dev@lists.rivendellaudio.org > <mailto:Rivendell-dev@lists.rivendellaudio.org> > > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > > > > _______________________________________________ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > <mailto:Rivendell-dev@lists.rivendellaudio.org> > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > > > > _______________________________________________ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev _______________________________________________ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
