VNC stands for Virtual Network Computing. This great tool was developed at AT&T Laboratories in Cambridge,
England. This tool should be in every sysadmins arsenal.
VNC is a network graphics protocol (applications running on one computer but displaying their
windows on another) in the spirit of X, however, unlike X, the viewing-end is very simple and maintains
no state.
It is a remote framebuffer (RFB) protocol. Some VNC links:
For Unix, the traditional VNC implementation includes a "virtual" X11 server Xvnc (usually
launched via the vncserver command) that is not associated with a physical display, but provides
a "fake" one X11 clients (xterm, mozilla, etc.) can attach to. A remote
user then connects to Xvnc via the VNC client vncviewer from anywhere on the network to
view and interact with the whole virtual X11 desktop.
The VNC protocol is in most cases better suited for remote connections with low bandwidth and high
latency than is the X11 protocol because it involves far fewer "roundtrips" (an exception is the
cached pixmap data on the viewing-end provided by X). Also, with no
state maintained the viewing-end can crash, be rebooted, or relocated and the applications and desktop
continue running. Not so with X11.
So the standard Xvnc/vncserver program is very useful for things like:
Desktop conferencing with other users (e.g. codereviews).
Long running apps/tasks I want to be able to view from many places.
Motif, GNOME, and similar applications that would yield very poor performance over a high latency
link.
However, sometimes one wants to connect to a real
X11 display (i.e. one attached to a physical monitor, keyboard, and mouse: a Workstation or a
SunRay session) from far away. Maybe you want to close down an application cleanly rather than using
kill, or want to work a bit in an already running application, or would like to help a
distant colleague solve a problem with their desktop, or would just like to work out on the deck for
a while. This is where x11vnc is useful.
VNC is perfect for those who use Windows desktop to manage Unix servers. It not only allows you to
view other Unix desktop from PC and other architectures that do not have X it also have several additional
benefits. One of the most important is that it preserves state of the session. So if you
left your office and reconnect from home the session will be at the state you left it up to the last
cursor position. That saves a lot of time if you administer multiple servers.
Being able to access a user’s desktop remotely is also very important for network administrators,
as they don’t have to run around all over the place doing troubleshooting. There are various commercial
packages that have been providing this capability for a long time (pcAnywhere was available for DOS,
Hummingbird is 10 years old, etc). Win XP Professional has Remote Desktop Connection and Remote
Assistance that allows you to access the machine remotely, whether over a LAN or even the Internet.
And this is a high quality free product that works for Unix.
It is, in essence, a remote display system which allows you to view a whole computing 'desktop' environment.
VNC is very similar
to Windows Terminal Services. There are, however, some key differences, such as:
Traffic between the client and server is not encrypted; VNC traffic can be tunnelled over
IPsec to make up for its shortcomings.
Although VNC is great, it does not make an efficient use of bandwidth. It seems Windows XP Remote
Desktop makes significantly better job in comparison. Also, when the VNC server is running on Linux/Unix,
I cannot see the current desktop (on the console) remotely. There is a special version of VNC
called TightVNC which helps to overcome this problem. Some Linux distributions like Fedora are working
on integrating VNC as a core technology. There is also NX, the version of VNC that is leaner and meaner
then VNC. NX gives you a free (as in speech and beer) "CITRIX-style" solution. You can download
Knoppix 3.6 and give FreeNX a try.
VNC offers a server for Windows as well and it works reasonably well. The best windows implementation
is TightVNC VNC-Based Free Remote Control Solution
(native port is much weaker). You need to use TightVNC client too (actually this is a better client
for any VNC version, not only for TightVNC).
VNC ports to Windows have an important limitation: when the VNC server is running on Windows, multiple
people cannot have remote independent sessions.
For Solaris vnc package is provided on Software Companion CD and X11vnc prcompiled package from
http://sunfreeware.com
The VNC is launched using vncserver Perl script.
The script vncserver is a wrapper for Xvnc.
vncserver
The example of modified 'vncserver' is shown below.
The first time you run vncserver, it will prompt you for a password (it launches vncpasswd),
then it terminates without creating your desktop. To create your desktop, you have to run vncserver
again. The password file and startup scripts are stored in your ~/.vnc directory. You have
several choices of desktop environments and can either make an envelope scripts or to modify vncpasswd
to launch CDE, Gnome or KDE. You can create several scripts, one for each desktop that you
are using:
vnccde :n - CDE on display number 'n'
vnckde :n - KDE on display number 'n'
Leaving off the ":n" gives you the lowest available number. To connect to your desktop and use it,
you'll need a VNC viewer program on your client machine.
vncserver is a perl script that you can (and probably should) customize
You can start a vncserver from RC scripts or manually by logging on to
the system you want to administer remotely and launching it with the command:
# vncserver hostname:session_number
With VNC, you can run multiple sessions and connect to different servers. By default, the session
numbers start at 1 and go up from there, but you can specify session 3 (for instance) right from the
start by typing vncserver hostname:3. This highlights another benefit of VNC. Until you kill
a VNC session, it retains its current state.
That means you can disconnect from a session, reconnect later, and return right where you left
off. In fact, you can even share a session so multiple users can access it.
When you start the vncserver for the first time, you will be prompted for a password to
access the server. You can always change it later using the vncpasswd command. Once the server
is activated, you can connect to it using the vncviewer command. The format is as follows:
# vncviewer host:session_number
To exit the viewer (or send specific key sequences), use the F8 key. Then click
on "Quit Viewer" to close the session. You can also start a shared session so that others may use the
same X Window session with this version of the command:
# vncviewer -shared host:session_number
When you start the vncserver, it creates a .vnc directory under your home
directory (/root/.vnc). Several files are kept here. You'll find a log file associated with
each server you run and a .pid file to allow for removal of the server. By the way
(since I mentioned it earlier), you kill a vncserver process like this:
# vncserver -kill :1
Remember that the :1 could be a :2 or :3, depending
on the session you are trying to kill. That said, the other file I want you to look at is this one:
-- xstartup. If you do a cat on the
file, you get something that looks like this:
Notice the second-to-last line is commented out, and a "startkde" line is added below. This is because
VNC uses twm (the Tab Window Manager) as its default desktop. If you prefer another window
manager, add the startup here.
We'll be installing TigerVNC. It is an actively maintained high-performance VNC server. Type the following command to install the
package:
sudo apt install tigervnc-standalone-serverCopy
Configuring VNC Access
Once the VNC server is installed, the next step is to create the initial user configuration and set up the password.
Set the user password using the
vncpasswd
command.
Do not use sudo when running the command below:
vncpasswdCopy
You will be prompted to enter and confirm the password and whether to set it as a view-only password. If you choose to set up a
view-only password, the user will not be able to interact with the VNC instance with the mouse and the keyboard.
Password:
Verify:
Would you like to enter a view-only password (y/n)? n
Copy
The password file is stored in the
~/.vnc
directory,
which is created if not present.
Next, we need to configure TigerVNC to use Xfce. To do so, create the following file:
New 'server2.linuxize.com:1 (linuxize)' desktop at :1 on machine server2.linuxize.com
Starting applications specified in /home/linuxize/.vnc/xstartup
Log file is /home/linuxize/.vnc/server2.linuxize.com:1.log
Use xtigervncviewer -SecurityTypes VncAuth -passwd /home/linuxize/.vnc/passwd :1 to connect to the VNC server.
Copy
Note the
:1
after
the
hostname
in
the output above. This indicates the number of the display port on which the vnc server is running. In this example, the server
is running on TCP port
5901
(5900+1).
If you create a second instance with
vncserver
it
will run on the next free port i.e
:2
,
which means that the server is running on port
5902
(5900+2).
What is important to remember is that when working with VNC servers,
:X
is
a display port that refers to
5900+X
.
You can get a list of all the currently running VNC sessions by typing:
vncserver -listCopy
TigerVNC server sessions:
X DISPLAY # RFB PORT # PROCESS ID
:1 5901 5710
Copy
Before continuing with the next step, stop the VNC instance using the
vncserver
command
with a
-kill
option
and the server number as an argument. In this example, the server is running in port 5901 (
:1
),
so we'll stop it with:
The number
1
after
the
@
sign
defines the display port on which the VNC service will run. This means that the VNC server will listen on port
5901
,
as we discussed in the previous section.
● [email protected] - Remote desktop service (VNC)
Loaded: loaded (/etc/systemd/system/[email protected]; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-03-26 20:00:59 UTC; 3s ago
...
Copy
Connecting to VNC server
VNC is not an encrypted protocol and can be subject to packet sniffing. The recommended approach is to create an
SSH
tunnel
and securely forward traffic from your local machine on port 5901 to the server on the same port.
Set Up SSH Tunneling on Linux and macOS
If you run Linux, macOS, or any other Unix-based operating system on your machine, you can easily create an SSH tunnel with the
following command:
Make sure to replace
username
and
server_ip_address
with
your username and the IP address of your server.
Set Up SSH Tunneling on Windows
If you run Windows, you can set up SSH Tunneling using the
PuTTY
SSH client
.
Open Putty and enter your server IP Address in the
Host
name or IP address
field.
Under the
Connection
menu,
box, expand
SSH
,
and select
Tunnels
.
Enter the VNC server port (
5901
)
in the
Source
Port
field and enter
server_ip_address:5901
in
the
Destination
field
and click on the
Add
button
as shown in the image below:
Go back to the
Session
page
to save the settings, so you do not need to enter them each time. To the remote server, select the saved session and click on
the
Open
button.
Connecting using Vncviewer
Now that the SSH tunnel is created, it is time to open your Vncviewer and to connect to the VNC Server at
localhost:5901
.
You can use any VNC viewer such as TigerVNC, TightVNC, RealVNC, UltraVNC, Vinagre, and VNC Viewer for
Google
Chrome
.
We'll be using TigerVNC. Open the viewer, enter
localhost:5901
,
and click on the
Connect
button.
Enter
your
user
password when prompted, and you should see the default Xfce desktop. It will look something like this:
You can start interacting with the remote XFCE desktop from your local machine using your keyboard and mouse.
Conclusion
We've shown you how to install and configure a VNC server up and running, on Ubuntu 20.04.
To configure your VNC server to start a display for more than one user, create the initial configuration and set up the password
using the
vncpasswd
command.
You will also need to create a new service file using a different port.
Feel free to leave a comment if you have any questions.
If you have performed a RHEL 7 Linux Server installation and did not include Graphical User
Interface (GUI) you can do it later directly from command line using yum command
and selecting an appropriate installation group. To list all available installation groups on
Redhat 7 Linux use:
[root@rhel7 ~]# yum group list
Loaded plugins: product-id, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
There is no installed groups file.
Maybe run: yum groups mark convert (see man yum)
Available environment groups:
Minimal Install
Infrastructure Server
File and Print Server
Basic Web Server
Virtualization Host
Server with GUI
Available Groups:
Compatibility Libraries
Console Internet Tools
Development Tools
Graphical Administration Tools
Legacy UNIX Compatibility
Scientific Support
Security Tools
Smart Card Support
System Administration Tools
System Management
Done
Looking for Linux Systems Analyst !
The UAF Geophysical Institute, is looking for an experienced Linux Systems Analyst to
join their team of research cyber infrastructure analysts and engineers. LOCATION:
Fairbanks, Alaska, USA
From the above list select Server with GUI installation group:
[root@rhel7 ~]# yum groupinstall 'Server with GUI'
Transaction Summary
=================
Install 261 Packages (+604 Dependent packages)
Total download size: 527 M
Installed size: 1.7 G
Is this ok [y/d/N]:
Just because gnome desktop environment is a default GUI on RHEL 7 linux system the above
command will install gnome. Alternatively, you can run the below command to only install core GNOME
packages:
Once the installation is finished, you need to change system's runlevel to runlevel 5.
Changing runlevel on RHEL 7 is done by use of systemctl command. The below command
will change runlevel from runlevel 3 to runelevel 5 on RHEL 7:
Depending on your previous installations you may need to accept Redhat License after you
reboot your system. Once you boot to your system you can check GNOME version using:
Download the Nvidia driver package from nvidia.com using search criteria based on
your Nvidia card model and the Linux operating system. Download an appropriate
Nvidia driver for your VGA card. Alternatively, if you know what you are doing you can
download the driver directly from the Nvidia Linux driver list . Once ready you
should end up with a file similar to the one shown below:
$ ls NVIDIA-Linux-x86_64-*
NVIDIA-Linux-x86_64-460.39.run
Next, install package
prerequisites to be able successfully compile and install Nvidia driver on you AlmaLinux
system.
WARNING
Depending on your Nvidia VGA model your system might misbehave. At this stage be ready to
get your hands dirty. After the reboot you may end up without GUI at all. Be sure that
you have the SSH enabled on your system to
be able login remotely or use CTRL+ALT+F2 to switch TTY console and continue
with the installation.
# reboot
The Nvidia drivers must be installed while the Xorg server is stopped. Switch to the text
mode by:
# systemctl isolate multi-user.target
Install the Nvidia driver by executing the following command via TTY console or remote
SSH login:
When prompted answer
YES to installation of NVIDIA's 32-bit compatibility libraries. Allow automatically
update of your X configuration file.
You should see the following message after successful NVIDIA driver installation.
Reboot your system one more time.
All done. Reboot your system. The Nvidia driver should now be installed on your AlamLinux 8
Desktop. Login and run nvidia-settings to further configure your Nvidia
graphic card settings.
# reboot
Troubleshooting GDM on Xorg server does not start after user login and user ends up with
black screen. The Xorg log contains the following or similar error messages:
[ 3515.464] (II) systemd-logind: got pause for 13:68
[ 3515.738] (II) systemd-logind: got resume for 13:64
[ 3515.757] (II) NVIDIA(0): Setting mode "DFP-1:nvidia-auto-select"
[ 3515.793] (II) NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon
[ 3515.793] (II) NVIDIA(0): may not be running or the "AcpidSocketPath" X
[ 3515.793] (II) NVIDIA(0): configuration option may not be set correctly. When the
[ 3515.793] (II) NVIDIA(0): ACPI event daemon is available, the NVIDIA X driver will
[ 3515.793] (II) NVIDIA(0): try to use it to receive ACPI event notifications. For
[ 3515.793] (II) NVIDIA(0): details, please see the "ConnectToAcpid" and
[ 3515.793] (II) NVIDIA(0): "AcpidSocketPath" X configuration options in Appendix B: X
[ 3515.793] (II) NVIDIA(0): Config Options in the README.
[ 3515.793] [dix] couldn't enable device 8
[ 3515.793] (II) systemd-logind: got resume for 13:66
[ 3515.793] [dix] couldn't enable device 6
[ 3515.794] (II) systemd-logind: got resume for 13:65
[ 3515.794] [dix] couldn't enable device 7
[ 3515.794] (II) systemd-logind: got resume for 13:72
[ 3515.794] [dix] couldn't enable device 14
[ 3515.794] [dix] couldn't enable device 17
[ 3515.794] (II) systemd-logind: got resume for 13:71
[ 3515.794] [dix] couldn't enable device 13
[ 3515.794] (II) systemd-logind: got resume for 13:67
[ 3515.794] [dix] couldn't enable device 9
[ 3515.794] (II) systemd-logind: got resume for 13:73
[ 3515.794] [dix] couldn't enable device 15
[ 3515.794] (II) systemd-logind: got resume for 13:69
[ 3515.794] [dix] couldn't enable device 11
[ 3515.794] [dix] couldn't enable device 16
[ 3515.794] (II) systemd-logind: got resume for 13:70
[ 3515.794] [dix] couldn't enable device 12
[ 3515.794] (II) systemd-logind: got resume for 13:68
[ 3515.794] [dix] couldn't enable device 10
Accessing remote desktops Need to see what's happening on someone else's screen? Here's what you need to know about accessing
remote desktops.
Posted June 13, 2019 | by Seth Kenlon (Red Hat)
Anyone who's worked a support desk has had the experience: sometimes, no matter how descriptive your instructions,
and no matter how concise your commands, it's just easier and quicker for everyone involved to share screens. Likewise, anyone who's
ever maintained a server located in a loud and chilly data center -- or across town, or the world -- knows that often a remote viewer
is the easiest method for viewing distant screens.
Linux is famously capable of being managed without seeing a GUI, but that doesn't mean you have to manage your box that
way. If you need to see the desktop of a computer that you're not physically in front of, there are plenty of tools for the job.
Barriers
Half the battle of successfully screen sharing is getting into the target computer. That's by design, of course. It should
be difficult to get into a computer without explicit consent.
Usually, there are up to 3 blockades for accessing a remote machine:
The network firewall
The target computer's firewall
Screen share settings
Specific instruction on how to get past each barrier is impossible. Every network and every computer is configured uniquely, but
here are some possible solutions.
Barrier 1: The network firewall
A network firewall is the target computer's LAN entry point, often a part of the router (whether an appliance from an Internet
Service Provider or a dedicated server in a rack). In order to pass through the firewall and access a computer remotely, your network
firewall must be configured so that the appropriate port for the remote desktop protocol you're using is accessible.
The most common, and most universal, protocol for screen sharing is VNC.
If the network firewall is on a Linux server you can access, you can broadly allow VNC traffic to pass through using firewall-cmd
, first by getting your active zone, and then by allowing VNC traffic in that zone:
If you're not comfortable allowing all VNC traffic into the network, add a rich rule to firewalld in order to let
in VNC traffic from only your IP address. For example, using an example IP address of 93.184.216.34, a rule to allow VNC traffic
is:
To ensure the firewall changes were made, reload the rules:
$ sudo firewall-cmd --reload
If network reconfiguration isn't possible, see the section "Screen sharing through a browser."
Barrier 2: The computer's firewall
Most personal computers have built-in firewalls. Users who are mindful of security may actively manage their firewall. Others,
though, blissfully trust their default settings. This means that when you're trying to access their computer for screen sharing,
their firewall may block incoming remote connection requests without the user even realizing it. Your request to view their screen
may successfully pass through the network firewall only to be silently dropped by the target computer's firewall.
Changing zones in Linux.
To remedy this problem, have the user either lower their firewall or, on Fedora and RHEL, place their computer into the trusted
zone. Do this only for the duration of the screen sharing session. Alternatively, have them add either one of the rules you added
to the network firewall (if your user is on Linux).
A reboot is a simple way to ensure the new firewall setting is instantiated, so that's probably the easiest next step for your
user. Power users can instead reload the firewall rules manually :
$ sudo firewall-cmd --reload
If you have a user override their computer's default firewall, remember to close the session by instructing them to re-enable
the default firewall zone. Don't leave the door open behind you!
Barrier 3: The computer's screen share settings
To share another computer's screen, the target computer must be running remote desktop software (technically, a remote desktop
server , since this software listens to incoming requests). Otherwise, you have nothing to connect to.
Some desktops, like GNOME, provide screen sharing options, which means you don't have to launch a separate screen sharing application.
To activate screen sharing in GNOME, open Settings and select Sharing from the left column. In the Sharing panel, click on Screen
Sharing and toggle it on:
Remote desktop viewers
There are a number of remote desktop viewers out there. Here are some of the best options.
GNOME Remote Desktop Viewer
The GNOME Remote Desktop Viewer application is codenamed Vinagre
. It's a simple application that supports multiple protocols, including VNC, Spice, RDP, and SSH. Vinagre's interface is intuitive,
and yet this application offers many options, including whether you want to control the target computer or only view it.
If Vinagre's not already installed, use your distribution's package manager to add it. On
Red Hat Enterprise Linux and
Fedora , use:
$ sudo dnf install vinagre
In order to open Vinagre, go to the GNOME desktop's Activities menu and launch Remote Desktop Viewer . Once it opens, click the
Connect button in the top left corner. In the Connect window that appears, select the VNC protocol. In the Host field, enter the
IP address of the computer you're connecting to. If you want to use the computer's hostname instead, you must have a valid DNS service
in place, or Avahi , or entries in /etc/hosts . Do not prepend
your entry with a username.
Select any additional options you prefer, and then click Connect .
If you use the GNOME Remote Desktop Viewer as a full-screen application, move your mouse to the screen's top center to reveal
additional controls. Most importantly, the exit fullscreen button.
If you're connecting to a Linux virtual machine, you can use the Spice protocol instead. Spice is robust, lightweight, and transmits
both audio and video, usually with no noticeable lag.
TigerVNC and TightVNC
Sometimes you're not on a Linux machine, so the GNOME Remote Desktop Viewer isn't available. As usual, open source has an answer.
In fact, open source has several answers, but two popular ones are TigerVNC and
TightVNC , which are both cross-platform VNC viewers. TigerVNC
offers separate downloads for each platform, while TightVNC has a universal Java client.
Both of these clients are simple, with additional options included in case you need them. The defaults are generally acceptable.
In order for these particular clients to connect, turn off the encryption setting for GNOME's embedded VNC server (codenamed Vino)
as follows:
$ gsettings set org.gnome.Vino require-encryption false
This modification must be done on the target computer before you attempt to connect, either in person or over SSH.
Red Hat Enterprise Linux 7 remoted to RHEL 8 with TightVNC
Use the option for an SSH tunnel to ensure that your VNC connection is fully encrypted.
Screen sharing through a browser
If network re-configuration is out of the question, sharing over an online meeting or collaboration platform is yet another option.
The best open source platform for this is Nextcloud , which offers screen sharing
over plain old HTTPS. With no firewall exceptions and no additional encryption required,
Nextcloud's Talk app provides video and audio chat, plus whole-screen sharing
using WebRTC technology.
This option requires a Nextcloud installation, but given that it's the best open source groupware package out there, it's probably
worth looking at if you're not already running an instance. You can install Nextcloud yourself, or you can purchase hosting from
Nextcloud.
To install the Talk app, go to Nextcloud's app store. Choose the Social & Communication category and then select the Talk plugin.
Next, add a user for the target computer's owner. Have them log into Nextcloud, and then click on the Talk app in the top left
of the browser window.
When you start a new chat with your user, they'll be prompted by their browser to allow notifications from Nextcloud. Whether
they accept or decline, Nextcloud's interface alerts them of the incoming call in the notification area at the top right corner.
Once you're in the call with your remote user, have them click on the Share screen button at the bottom of their chat window.
Remote screens
Screen sharing can be an easy method of support as long as you plan ahead so your network and clients support it from trusted
sources. Integrate VNC into your support plan early, and use screen sharing to help your users get better at what they do. Topics:
Linux Seth Kenlon Seth Kenlon is a free culture
advocate and UNIX geek.
OUR BEST CONTENT, DELIVERED TO YOUR INBOX
https://www.redhat.com/sysadmin/eloqua-embedded-subscribe.html?offer_id=701f20000012gE7AAI The opinions expressed on this website
are those of each author, not of the author's employer or of Red Hat.
Red Hat and the Red Hat logo are trademarks of Red Hat, Inc., registered in the United States and other countries.
Now there is no need to share the whole desktop if you need to remotely control only one application.
For that, run a server via the command line, specify -shareapp CLI option and pass a process
ID as its argument. In the Viewer window, only the application window will be shown (if any, non-used
space in the Viewer viewport is filled with black).
Now servers run on Windows 8 are ultra fast and there are no desktop update lags when the Viewer
connects to it. This was made possible due to added support for the Desktop Duplication API.
Password Protection for Server-Side Changes
Now access to remote server settings can be additionally secured with a new Administration
-> Ask password for each operation option. If checked, an Administrative password is required
to open settings and alter them (rather than asking for it only once, on the server start-up). Securing
each operation makes it impossible to reconfigure the server during a session without appropriate
rights for that.
The list of supported encoding types is extended with ZRLE and RRE compression. Now TightVNC
Server is fully compliant to the latest RFB protocol specification.
Remote Ripple is our VNC-compatible remote desktop client for Android. Version 2.0 is a complete
redesign of the application.
Install Remote Ripple now!
RFB[1] (Remote FrameBuffer) is the protocol used by VNC. The emphasis
in the design of the protocol was to make very few requirements of the client. The client has no
need to maintain explicit state and clients are able to disconnect and re-connect to the server
while preserving the state of the user interface.
The dislay part of the protocol is based around a single simple graphics primitive "put a rectangle
of pixel data at a given position". Each rectangle may be encoded in any one of a number of encodings
allowing for compression or usage of parts of the client's existing copy of the framebuffer. Updates
are requested by the client rather than pushed out by the server allowing the protcol to adapt to
slower networks and/or clients - i.e. with a slow network or client the rate of updates are greatly
reduced and the client ignores the transient state of the framebuffer.
The protocol is quite extensible. Extra encodings can be advertised by the server and used if
the client supports the encoding. Use of encodings are not only limited to how frame buffer updates
are encoded on the wire, but also extra psuedo-encodings may be added which can do anything from
inform the client of a change in cursor shape, a change in the size of the screen or even things
like extra in-band communication between the server and client.
There seems to be many different implementations of VNC available. Available RFB server implementations
include:
libvncserver[2] a "library" for implementing VNC servers. It basically
just seems to be a hacked up version of an existing VNC server in an archive with some header
files. Not a very nice API, but quite a few projects are using it successfully.
xf4vnc[3]: a controlled fork of XFree86 which allows you to run
an Xserver which doubles as a VNC server or export your local framebuffer through a loadable
module.
realVNC[4]: seems to be a continuation of the original VNC project
which has an Xserver which doubles as a VNC server. Thus, there is no method by which you can
remote the local framebuffer.
x0rfbserver: an X11 client which acts as an RFB server and exports the local display by
polling the display for updates using X and pushing the updates out to clients using RFB.
krfb[5]: a pretty nice looking VNC server for KDE which is based
on the same concept (and indeed uses some of the code of) x0rfbserver. It also uses libvncserver.
I won't list the VNC client's available, there seem to be many, but suffice to say there are
X11, Windows and OS X clients available along with, interestingly, several implementations of a
Java client which can be run embedded in the browser as an applet.
Tim Waugh has written a nice article[6] on VNC and the many projects around the technology.
In summary, the RFB protocol has a number of advantages:
Simple and open protocol.
Rate-limited by the client, pretty low bandwidth/latency requirements.
Extensible.
Several open source implementations available.
Many existing clients available for different platforms.
x0rfbserver, kfrb, and x0rfb from the rfb package (great name, eh?), site http://www.hexonet.de/
is gone - assumed-defunct project
You'll find a number of resources about VNC over SSH in my ssh-clients
file, http://linuxmafia.com/ssh/.
Also worth looking into:
FreeNX: (http://www.kalyxo.org/,
http://developer.berlios.de/projects/freenx/).
This package started out as Kevin Vigor's BSD-licensed DXPC (Differential X11 Protocol Compressor),
http://www.vigor.nu/dxpc/, an open-source
method of sending highly compressed and proxied X11 graphics, an update of the LBX = Low Bandwidth
X idea. Much faster than VNC. This became MLView DXPC (final version Nov. 2002), then NoMachine's
NX aka NX Terminal Server (http://www.nomachine.com/),
which at some point during that transition switched to proprietary licensing.
Late 2004 addendum: Fabian Franz's new project "based on NX technology", called FreeNX, uses
NX's core libraries, which are GPLed, while substituting GPLed server pieces for NX's proprietary
ones. At this date, the project Web site at
http://www.kalyxo.org/ is being rebuilt, but source tarballs are available, and FreeNX is
packaged for numerous Linux distributions, while NX's proprietary server code is currently free
of charge for MS-Windows.
rdesktop: This (http://www.rdesktop.org/)
is an RDP client for Windows Terminal Services. Likewise much faster than VNC; also, fully multiuser,
unlike VNC.
Citrix Metaframe: This is the old-established proprietary remote-Win32-access technology (implementing
ICA = Independent Computing Architecture remote imaging), whose predecessor Citrix Winframe was
licensed by Microsoft Corporation and rebranded as Microsoft Terminal Server. (Microsoft also rebranded
ICA as Microsoft Remote Desktop Protocol = RDP.) http://www.citrix.com/
For completeness:
Sun Secure Global Desktop: This is a proprietary remote-Win32-access technology formerly called
Tarantella, until Sun Microsystems bought Tarantella, Inc., formerly Santa Cruz Operation (dubbed
"old SCO" to distinguish it from the Utah company formerly named Caldera Systems that renamed itself
The SCO Group). Santa Cruz Operation in turn had developed Tarantella from code acquired when it
bought IXI Limited of Cambridge, UK and Visionware Limited of Leeds, UK, in 1993 and 1994, respectively. http://www.sun.com/software/products/sgd
Screenshots have always been invaluable tools for graphical user interfaces. They let programmers
flaunt their wares to prospective users; even with console tools, I usually zoom right in on a screenshot
link to get my first impression of a program. They let the desktop-inclined show off their backgrounds
and theme authors show why you must have their work. And when things go wrong, a screenshot can
often save a thousand words of bug reporting. vnc2swf puts all these benefits in motion.
The Enhanced TightVNC Viewer package is part of the x11vnc VNC server project. It provides a native
VNC viewer that takes advantage of new features in x11vnc, e.g. cursor alpha blending and automatic
SSL tunnelling. Some features apply to any VNC server, e.g. automatic SSH tunnelling. Another goal
is to provide a package that conveniently bundles everything needed for the user to have the enhanced
viewer running quickly. This includes pre-built binaries of the viewer and utility programs for
Windows and many Unix variants, and a GUI to configure and launch the viewer. The short name for
this project is "ssvnc", for SSL/SSH VNC viewer.
Release focus: Minor bugfixes
Changes:
Using port numbers lower than VNC's default port (5900) now works on Windows (for example, myhost.com:443).
While working on a project to create tutorials, I needed a way to watch how a user stepped through
the process of using an application without being on-site.
VNC turned out to be a viable solution.
I could remotely connect and view all the steps, while conversing about the process over the phone.
The trouble was there were firewalls at both ends. It would have been easy to just open the port
normally used for VNC connectivity (5900) in the firewall, but it's definitely not secure.
Using VNC while tunneling over SSH was
a quick and more secure way to accomplish the process/application watching goal.
Several steps are required to make it work.
Ideally, all inbound ports are closed on an Internet facing firewall. That will go a long way
to keeping out the bad guys. Of course, any other remote access is then limited as well.
Opening up port 22 on the distant IPCop firewall
works well for the purpose of tutorial generation and is easily accomplished using the IPCop Web-based
GUI. A similar process is used if the user machine is behind a dedicated firewall appliance. The
idea is to port forward the SSH traffic from the Internet to the VNC-equipped user desktop machine.
Port 22 on the user's Linux desktop also needs to be available for logging in via SSH. When the
session is finished, the firewall's SSH port can then again be closed to inbound traffic.
Specialized remote access techniques should be considered, like
port-knocking or using
hardened firewall devices when a more permanent or bulletproof connection is needed.
TightVNC client has an option sending this key sequence to Windows (left-click mouse of the client
and see "send Ctrl-Alt-Del" option.
Q. How can I send an ALT-CTRL-DEL from a Linux XFree
VNC client to an NT server (running VNC as a service) to login? It seems that the Alt-Ctrl-Del to
gobbled up by Xfree (or maybe something else?) and not sent to the server. My SunOS client sends
the Alt-Ctrl-Del fine. There is no pull-down item to sent it like on a Win95 client.
My VncMonitor program will allow you to connect to a remote system without
the need to type in details (it gets the information from a configuration
file). My VncProxy program allows the number of connections to a proxied VNC
server to be restricted to any number.
They are both Java programs so should run on your machines.
http://www.wilson.co.uk/Software/vnc/VncMonitor.htmhttp://www.wilson.co.uk/Software/vnc/proxy/VncProxy.htm
I'm about to release new versions in the next day or so.
John Wilson
The Wilson Partnership
5 Market Hill, Whitchurch, Aylesbury, Bucks HP22 4JB, UK
+44 1296 641072, +44 976 611010(mobile), +44 1296 641874(fax)
Mailto: tug "at" wilson.co.uk
----- Original Message -----
From: Pavel Satny <pavel.satny "at" alcatel.cz>
To: <vnc-list "at" uk.research.att.com>
Cc: <aarnout.wieers "at" alcatel.cz>
Sent: 22 June 1999 15:19
Subject: VNC Configuration
> Dear all,
>> can somebody help me with configuring VNC? I have an idea to instal it as
> "semi-videoconferencing tool", where two persons can discuss by phone
about
> what they are showing themselves on shared screen.
> What are possibilities to make it very easy startable, without typing
> comands with (for ordinary users) nonunderstandable options.
>
---------------------------------------------------------------------
The VNC mailing list - see http://www.uk.research.att.com/vnc/intouch.html
TightVNC: Manual Page
for Xvnc(1) Constantin Kaplinsky [email protected]
has developed TightVNC, a version of VNC providing better compression for use with slow links than
the standard VNC 3.3.3 release. TightVNC client for Windows is the best client in existence and
can be used with other versions of VNC. Although it includes a number of extensions to the standard
VNC distribution, TightVNC remains compatible with existing versions. It has win32 version that
can also transfer files. The TightVNC homepage is at
http://www.tightvnc.com/
x11vnc-0.7-sol10-sparc-local.gz x11vnc is a vnc server for X displays. It allows remote
viewing and interaction with real X displays via keyboard and mouse - installs in /usr/local.
This package also needs to have the following packages installed - zlib,
jpeg, and /usr/local/lib/libgcc_s.so.1 from either libgcc-3.3
or gcc or later. You will need a vnc viewer on your client machines. I
have tested the tightvnc java
based viewers for Solaris and Mac OSX and will be offering a compiled version of the tightvnc
vncviewer for Solaris here shortly.
x11vnc-0.7-sol10-intel-local.gz x11vnc is a vnc server for X displays. It allows remote
viewing and interaction with real X displays via keyboard and mouse - installs in /usr/local.
This package also needs to have the following packages installed - zlib,
jpeg, and /usr/local/lib/libgcc_s.so.1 from either libgcc-3.3
or gcc or later. You will need a vnc viewer on your client machines. I
have tested the tightvnc java
based viewers for Solaris and Mac OSX and will be offering a compiled version of the tightvnc
vncviewer for Solaris here shortly.
If you haven't done so already, you probably want to
download the latest version,
and read the release
notes. Then you might need some help
getting started.
If you've got problems, try the
FAQ for some of the most common
questions and problems. There are also some pages to help with
troubleshooting. There
is also a list of known
bugs and features for Version 4.0. Another great resource for troubleshooting is the mailing
list archives, which you can
search. It's been
running for several years and there are tens of thousands of items.
TightVNC: Manual Page for Xvnc(1)Const Kaplinsky
[email protected] has developed TightVNC,
a version of VNC providing better compression for use with slow links than the standard VNC 3.3.3 release.
Although it includes a number of extensions to the standard VNC distribution, TightVNC remains compatible
with existing versions. The TightVNC homepage is at
http://www.tightvnc.com/
TightVNC is fully compatible with the standard RFB protocol used in VNC, so you can use TightVNC
viewer with the standard VNC server and vice versa. But note that protocol enhancements implemented
in TightVNC will work only if these enhancements are supported on both sides of the connection.
TightVNC Features
Here is a brief list of TightVNC features absent in the standard VNC.
File transfers in Win32 version. You can updload files from your local machine to the
TightVNC server, and download files from the server to you computer.
Local cursor handling. Cursor movements do not generate screen updates any more, remote
cursor movements are processed locally by the viewer, so you do not see slow remote cursor movements
behind the local cursor.
Efficient compression algorithms. New Tight encoding is optimized for slow and medium-speed
connections and thus generates much less traffic as compared to traditional VNC encodings. At the
same time, TightVNC supports all the standard VNC encodings, so it can operate efficiently over
fast networks, too. Thus, with TightVNC you can work remotely almost in real time in most network
environments.
Configurable compression levels. You can choose any appropriate level of compromise between
compression ratios and coding speed, depending on your connection speed and processor power.
Optional JPEG compression. If you don't care too much about perfect image quality, you
can use JPEG compression which will compress color-rich screen areas much more efficiently (the
image quality level is configurable too).
Enhanced Web browser access. TightVNC includes a greatly improved Java viewer with full
support for Tight encoding, local cursor feature, 24-bit color mode, and more. The Java viewer applet
can be accessed via built-in HTTP server like in the standard VNC.
Support for two passwords (full-control and read-only). The server allows or disallows
remote keyboard and mouse events depending on which password was used for authentication.
Advanced Properties dialog in WinVNC. Unlike the standard VNC, TightVNC gives you the
possibility of setting a number of advanced settings directly from the WinVNC GUI, and to apply
changed settings immediately. There is no need to launch regedit to set query options,
connection priority, to allow loopback connections, disable HTTP server etc.
Flexible configuration options. Unlike the standard VNC, TightVNC allows you to choose
arbitrary port numbers for TCP/IP connections, in addition to display numbers traditionally used
in VNC.
Automatic SSH tunneling on Unix. The Unix version of TightVNC viewer can tunnel connections
via SSH automatically using a local SSH/OpenSSH client installation (provided that an SSH/OpenSSH
server is running on the server as well).
And more. TightVNC features a number of other improvements, performance optimizations
and bugfixes, see change logs
for more information.
... please look at the Xvnc -help output and read the Xserver(1) manual page for ... rfbwait
time Maximum time, in milliseconds, to wait for an RFB client (VNC viewer ...
www.tightvnc.com/Xvnc.1.html - 14k -
Cached -
Similar pages
x0rfbserver - accessing a standard X server with VNC
Jens Wagner has written some VNC-related tools, amongst which is a program called x0rfbserver. This
is a VNC server which serves a standard X server desktop thus behaving more like WinVNC and MacVNC than
does Xvnc. It is available in the rfb-n.n.n.tar.gz package from
http://www.hexonet.de/software.en/
http://ultravnc.sourceforge.net
Want to remote control your computer? If you have Windows XP Professional, you can use
Remote Desktop.
If you don't use Windows XP Professional, you can still get remote control using UltraVNC. UltraVNC
is an excellent fast & free remote control, and file transfer program.
PalmVNC v1.40
User's Guide
... Features and Compatibility. Ultra-thin client uses less than 40Kb of
Palm memory. VNC servers available for a wide variety of platforms. ...
www.btinternet.com/~harakan/PalmVNC/Manual/manual.htm - 13k -
Cached -
Similar pages
[PDF]Using VNC (3
File Format: PDF/Adobe Acrobat - View as HTML
... Tower, 545-2836 C:\My Documents\Word\documentation\vnc\VNCVIEWER_web.doc 06/30/2003
5 Troubleshooting Note: For troubleshooting involving VNC Server, you must ...
www.math.umass.edu/~scc/software/ handouts/VNCVIEWER.pdf - Similar pages
x11vnc allows one to remotely view and interact with real X displays (i.e. a display corresponding
to a physical monitor, keyboard, and mouse) with any VNC viewer. In this way it plays the role for Unix/X11
that WinVNC plays for Windows.
I wrote x11vnc because x0rfbserver was basically impossible to build on Solaris and
had poor performance. The primary x0rfbserver build problems centered around esoteric C++
toolkits. x11vnc is written in plain C and uses only standard libraries. I also
added a few enhancements to improve the interactive response, add esoteric features, etc. The
FAQ contains a lot of information and solutions to problems, but please feel free
to contact me if you have problems or questions.
Background:
VNC (Virtual Network Computing) is a very useful network graphics protocol in the spirit of X, however,
unlike X, the viewing-end is very simple and maintains no state. It is a remote framebuffer (RFB) protocol
For Unix, the VNC implementation includes a virtual X11 server Xvnc (usually launched via
the vncserver command) that is not associated with a real display, but provides a "fake" one
X11 clients (xterm, mozilla, etc.) can attach to. A remote user then
connects to Xvnc via the VNC client vncviewer from anywhere on the network to view and
interact with the whole virtual X11 desktop.
The VNC protocol is in most cases better suited for remote connections with low bandwidth and high
latency than is the X11 protocol. Also, with no state maintained the viewing-end can crash, be rebooted,
or relocated and the applications and desktop continue running. Not so with X11.
So the standard Xvnc program is very useful, I use it for things like:
desktop conferencing with other users (e.g. codereviews).
long running apps/tasks I want to be able to view from many places.
Motif, GNOME, and similar applications that would yield very poor performance over a high latency
link.
However, sometimes one wants to connect to a real X11 display (i.e. one
attached to a physical monitor, keyboard, and mouse: a Workstation or a SunRay session) from far away.
Maybe you want to close down an application cleanly rather than using kill, or want to
work a bit in an already running application, or would like to help a distant colleague solve a problem
with their desktop. This is where x11vnc is useful.
How to use x11vnc:
In this example let's assume the remote machine with the X display you wish to view is "far-away.east:0"
and the workstation you are presently working at is "sitting-here.west".
Step 0. Download x11vnc (see below) and have it available
to run (e.g. via $PATH) on far-away.east. Similarly, have a VNC viewer
(e.g.vncviewer) ready to run on sitting-here.west. We recommend
TightVNC Viewers.
Step 1. By some means log in to far-away.east and get a command shell running
there. You can use ssh, rlogin, telnet, or any other method to
do this. x11vnc needs to be run on the same machine the X server process is running on
(because MIT-SHM shared memory is used to poll the X11 framebuffer).
Step 2. In that far-away.east shell (with command prompt "far-away>"
in this example) run x11vnc directed at the far-away.east X session display:
far-away> x11vnc -display :0
You could have also set the environment variable DISPLAY=:0 instead of using -display.
This step attaches x11vnc to the far-away.east:0 X display (no viewer clients yet).
To get X11 permissions right, you may also need to set the XAUTHORITY environment variable
(or use the -auth option) to point to the correct MIT-MAGIC-COOKIE file (e.g. /home/joe/.Xauthority).
More on this below.
There will then be much chatter printed out from x11vnc, until it finally says something like:
.
.
13/05/2004 14:59:54 Autoprobing selected port 5900
13/05/2004 14:59:54 screen setup finished.
13/05/2004 14:59:54 The VNC desktop is far-away:0
PORT=5900
which means all is OK, and we are ready for the final step.
Step 3. At the place where you are sitting (sitting-here.west in this example)
you now want to run a VNC viewer program. There are VNC viewers for Unix, Windows, MacOS, Java-enabled
web browsers, and even for PDA's like the Palm Pilot! You can use any of them to connect to x11vnc
(see the above VNC links under "Background:" on how to obtain a viewer for your platform or
this FAQ. For Solaris, vncviewer is available in the
Companion CD package
SFWvnc ).
In this example we'll use the Unix vncviewer program on sitting-here by typing
the following command in a second terminal window:
sitting-here> vncviewer far-away.east:0
That should pop up a viewer window on sitting-here.west showing and allowing interaction
with the far-away.east:0 X11 desktop. Pretty nifty! When finished, exit the viewer:
the remote x11vnc process will shutdown automatically (or you can use the -foreveroption to have it wait
for additional viewer connections).
Desktop Sharing: The above more or less assumed nobody was sitting at the workstation
display "far-away.east:0". This is often the case: a user wants to access her workstation
remotely. Another usage pattern has the user sitting at "far-away.east:0" and invites one
or more other people to view and interact with his desktop. Perhaps the user gives a demo or presentation
this way (using the telephone for vocal communication). A "Remote Help Desk" mode would be similar:
a technician remotely connects to the user's desktop to interactively solve a problem the user is having.
For these cases it should be obvious how it is done. The above steps will work, but more easily the
user sitting at far-away.east:0 simply starts up x11vnc from a terminal window,
after which the guests would start their VNC viewers. For this usage mode the -accept popup
option discussed in the FAQ below may be of use to allow the user at far-away.east:0
to accept or reject incoming connections.
Tunnelling x11vnc via ssh:
The above example had no security or privacy at all. When logging into remote machines (certainly
when going over the internet) it is best to use ssh, or use a VPN. For x11vnc one
can tunnel the VNC protocol through the encrypted ssh channel. It would look something
like this:
The -encodings option is very important: vncviewer will default
to "raw" encoding if it thinks the connection is to the local machine, and so vncviewer gets
tricked this way by the ssh redirection. "raw" encoding will be extremely slow over a networked
link, so you need to force the issue with -encodings "copyrect tight ...".
If the machine you SSH into is not the same machine with the X display you wish to view (e.g. your
company provides incoming SSH access to a gateway machine), then you need to change the above to, e.g.:
-L 5900:otherhost:5900. Once logged in, you'll need to do a second login (ssh,
rsh, etc.) to the workstation machine 'otherhost' and then start up x11vnc on it.
Scripts to automate tunneling: As discussed below, there may be some problems with
port 5900 being available. If that happens, the above port and display numbers may change a bit (e.g.
-> 5901 and :1). However, if you "know" port 5900 will be free on the local and remote machines, you
can easily automate the above two steps by using the x11vnc option -bg (forks into
background after connection to the display is set up) or using the -f option of ssh.
A simple example script, assuming no problems with port 5900 being taken on the local or remote sides,
looks like:
#!/bin/sh
# usage: x11vnc_ssh <host>:<xdisplay>
# e.g.: x11vnc_ssh snoopy.peanuts.com:0
host=`echo $1 | awk -F: '{print $1}'`
disp=`echo $1 | awk -F: '{print $2}'`
if [ "x$disp" = "x" ]; then disp=0; fi
cmd="x11vnc -display :$disp -localhost -rfbauth .vnc/passwd"
enc="copyrect tight zrle hextile zlib corre rre raw"
ssh -f -L 5900:localhost:5900 $host "$cmd"
for i in 1 2 3
do
sleep 2
if vncviewer -encodings "$enc" :0; then break; fi
done
See also rx11vnc.pl below.
Another method is to start the VNC viewer in listen mode "vncviewer -listen" and have
x11vnc initiate a reverse connection using the -connect option:
A third way is specific to the TightVNC vncviewer special option -via for
gateways. The only tricky part is we need to start up x11vnc and give it some time to start listening
for connections (so we cannot use the TightVNC default setting for VNC_VIA_CMD):
#!/bin/sh
# usage: x11vnc_ssh <host>:<xdisplay>
# e.g.: x11vnc_ssh snoopy.peanuts.com:0
host=`echo $1 | awk -F: '{print $1}'`
disp=`echo $1 | awk -F: '{print $2}'`
if [ "x$disp" = "x" ]; then disp=0; fi
VNC_VIA_CMD="ssh -f -L %L:%H:%R %G x11vnc -localhost -rfbport 5900 -display :$disp; sleep 5"
export VNC_VIA_CMD
vncviewer -via $host localhost:0 # must be TightVNC vncviewer.
Of course if you already have the x11vnc running waiting for connections (or have it started
out of inetd(1)), you can simply use the TightVNC vncviewer -via gateway host:port
in its default mode to provide secure ssh tunnelling.
VNC password file: Also note in the first example script that the option "-rfbauth
.vnc/passwd" provides additional protection by requiring a VNC password for every VNC viewer
that connects. The vncpasswd or storepasswd programs, or the x11vnc-storepasswd option can be used to create the password file. x11vnc
also has the slightly less secure -passwdfile and "-passwd
XXXXX" options.
Important: It is up to you to tell x11vnc to use password protection,
it will not do it for you automatically. The same goes for encrypting the channel between the viewer
and x11vnc: it is up to you to use ssh, stunnel, VPN, etc. Also look
into the -allow and -localhostoptions and building
x11vnc with tcp_wrappers support to limit host access.
Downloading x11vnc:
x11vnc is a contributed program to the
libvncserver project
at SourceForge.net. I use libvncserver for all of the VNC aspects; I couldn't have done
without it. The full source code may be found and downloaded (either file-release tarball or CVS tree)
from the above link. As of Aug 2004, the
x11vnc-0.6.2.tar.gz source package is released (recommended download) .
The x11vnc package is the subset of the libvncserver package needed to
build the x11vnc program. Please do not use the LibVNCServer-0.6 tarball: it contains
an older, more buggy version of x11vnc (Oct 2003) that you likely want to avoid. Also, you can
get a copy of my latest, bleeding edge
x11vnc.c file to
replace the one in the above packages or the one in the CVS tree and then rebuild.
See the FAQ below for information about where you might obtain a precompiled
x11vnc binary from 3rd parties.
To obtain VNC viewers for the viewing side (Windows, Mac OS, or Unix) try here:
More tools: Here is a rsh/ssh wrapper script rx11vnc that attempts
to automatically do the above Steps 1-3 for you (provided you have rsh/ssh login permission
on the machine x11vnc is to be run on). The above example would be: rx11vnc far-away.east:0
typed into a shell on sitting-here.west. Also included is an experimental script rx11vnc.pl
that attempts to tunnel the vnc traffic through an ssh port redirection (and does not assume port 5900
is free). Have a look at them to see what they do and customize as needed:
The Last but not LeastTechnology is dominated by
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt.
Ph.D
FAIR USE NOTICEThis site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
You can use PayPal to to buy a cup of coffee for authors
of this site
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society.We do not warrant the correctness
of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.
Download an appropriate Nvidia driver for your VGA card. Alternatively, if you know what you are doing you can download the driver directly from the Nvidia Linux driver list . Once ready you should end up with a file similar to the one shown below:
$ ls NVIDIA-Linux-x86_64-* NVIDIA-Linux-x86_64-460.39.runWhen prompted answer
Allow automatically update of your X configuration file.
You should see the following message after successful NVIDIA driver installation.
