Is there a method so on a remote vnc connection the screen is not being shown to those where the monitor is located.
If I am remoting in I dont even want the screen that is blank due to screen saver, to even show anything. remote does not need the screen at all in my case.
Is there a way to do that?
Jerry
Is there a method so on a remote vnc connection the screen is not being shown to those where the monitor is located.
If I am remoting in I dont even want the screen that is blank due to screen saver, to even show anything. remote does not need the screen at all in my case.
Is there a way to do that?
Yes, just run the vncserver service, it will create 'virtual' vnc desktops for you. You can create as many as the resources of the system will support. You'll need to read the documentation, I believe their is a configuration file something like: /etc/vncserver.conf.
Brett
On Thu, 2006-11-16 at 16:00 -0500, Brett Serkez wrote:
Is there a method so on a remote vnc connection the screen is not being shown to those where the monitor is located.
If I am remoting in I dont even want the screen that is blank due to screen saver, to even show anything. remote does not need the screen at all in my case.
Is there a way to do that?
Yes, just run the vncserver service, it will create 'virtual' vnc desktops for you. You can create as many as the resources of the system will support. You'll need to read the documentation, I believe their is a configuration file something like: /etc/vncserver.conf.
There are actually 3 different ways to set up vnc servers. One is to add the module to your xorg.conf file to export the console screen. This is handy to reconnect remotely to long-running programs you started at your desktop but I don't think there is any to force the local screen not to display. Another is to run individually started 'vncserver' sessions which have no connection to a real display, permit reconnection from vncviewers and run until you stop them. The 3rd is to set up xinetd to start new connections on demand and kill them when you disconnect.
On 11/16/06, Les Mikesell lesmikesell@gmail.com wrote:
... Another is to run individually started 'vncserver' sessions which have no connection to a real display, permit reconnection from vncviewers and run until you stop them.
We use this at $WORK to provide a stable X desktop for developers with Windows laptops. No matter how much their laptop comes and goes their desktop stays put. Works well for shifting back and forth from work to home too, either coming through the corporate VPN or using SSH tunnelling via PuTTY and an ssh server. This is also nice when you can afford UPS protection for the VNC Server machine, but not for client desktops.
In our case the actual compilations and such are done on still different systems (various OS's and Platforms), so not much "real" work happens on the Linux box doing the VNC servers. This lets us have many more people sharing a system than you would first think possible (as many as 8 on a 1.something Ghz P4 with 1.5G RAM, SCSI disk). As with many things these days, RAM is more important than CPU, faster disk (e.g. SCSI) would be next most important.
One tip: ensure no one runs xscreensaver in their virtual sessions! I copied the binary to xscreensaver.real and copied /bin/true to screensaver to keep all the configuration scripts happy.
On Mon, 2006-11-27 at 16:43 -0500, Dave K wrote:
On 11/16/06, Les Mikesell lesmikesell@gmail.com wrote:
... Another is to run individually started 'vncserver' sessions which have no connection to a real display, permit reconnection from vncviewers and run until you stop them.
We use this at $WORK to provide a stable X desktop for developers with Windows laptops. No matter how much their laptop comes and goes their desktop stays put. Works well for shifting back and forth from work to home too, either coming through the corporate VPN or using SSH tunnelling via PuTTY and an ssh server. This is also nice when you can afford UPS protection for the VNC Server machine, but not for client desktops.
In our case the actual compilations and such are done on still different systems (various OS's and Platforms), so not much "real" work happens on the Linux box doing the VNC servers. This lets us have many more people sharing a system than you would first think possible (as many as 8 on a 1.something Ghz P4 with 1.5G RAM, SCSI disk). As with many things these days, RAM is more important than CPU, faster disk (e.g. SCSI) would be next most important.
One tip: ensure no one runs xscreensaver in their virtual sessions! I copied the binary to xscreensaver.real and copied /bin/true to screensaver to keep all the configuration scripts happy.
freenx / nx might be even better for you, especially for remote connections.
-
Brett Serkez -
Dave K -
Jerry Geis -
Johnny Hughes -
Les Mikesell