NAME

SYNOPSIS

DESCRIPTION

So Xvnc is really two servers in one. To the applications it is an X server, and to the remote VNC users it is a VNC server. By convention we have arranged that the VNC server display number will be the same as the X server display number, which means you can use eg. snoopy:2 to refer to display 2 on machine "snoopy" in both the X world and the VNC world.

The best way of starting Xvnc is via the vncserver(1) command. This sets up the environment appropriately and runs some X applications to get you going. See the manual page for vncserver(1) for more information.  

OPTIONS

-geometry widthxheight

Specify the size of the desktop to be created. Default is 1024x768.

-depth depth

Specify the pixel depth in bits of the desktop to be created. Default is 16, other possible values are 8, 15, and 24 - anything else is likely to cause strange behaviour by applications.

-pixelformat format

Specify pixel format for server to use (BGRnnn or RGBnnn). The default for depth 8 is BGR233 (meaning the most significant two bits represent blue, the next three green, and the least significant three represent red), the default for depth 16 is RGB565 and for depth 24 is RGB888.

-cc 3

As an alternative to the default TrueColor visual, this allows you to run an Xvnc server with a PseudoColor visual (i.e. one which uses a colour map or palette), which can be useful for running some old X applications which only work on such a display. Values other than 3 (PseudoColor) and 4 (TrueColor) for the -cc option may result in strange behaviour, and PseudoColor desktops must be 8 bits deep (i.e. -depth 8).

-inetd

This significantly changes Xvnc's behaviour so that it can be launched from inetd. See the section below on usage with inetd.

-help

List all the options and parameters

PARAMETERS

Parameters can be turned on with -param or off with -param=0. Parameters which take a value can be specified as -param value. Other valid forms are param=value, -param=value and --param=value. Parameter names are case-insensitive.

For a full list of the parameters and a brief description of what they do, run Xvnc with the -help option. Most of these parameters will never need to be changed from their default values. The following list describes the most common parameters and what they do.

-desktop desktop-name

Each desktop has a name which may be displayed by the viewer. It defaults to "x11".

-rfbport port

Specifies the TCP port on which Xvnc listens for connections from viewers (the protocol used in VNC is called RFB - "remote framebuffer"). The default is 5900 plus the display number.

-rfbwait time, -ClientWaitTimeMillis time

Time in milliseconds to wait for a viewer which is blocking Xvnc. This is necessary because Xvnc is single-threaded and sometimes blocks until the viewer has finished sending or receiving a message - note that this does not mean an update will be aborted after this time. Default is 20000 (20 seconds).

-httpd directory

Run a mini-HTTP server which serves files from the given directory. Normally the directory will contain the classes for the Java viewer. In addition, files with a .vnc extension will have certain substitutions made so that a single installation of the Java VNC viewer can be served by separate instances of Xvnc. If this parameter is set to "<inline>", then the Java viewer and associated files are served directly from the Xvnc executable. Default is empty, meaning that the Java viewer is not served.

-httpPort port

Specifies the port on which the mini-HTTP server runs. Default is 5800 plus the display number.

-rfbauth passwd-file

Specifies the file containing the password used to authenticate viewers if VNC authentication is in use. See also the UserPasswdVerifier and PasswordFile parameters.

-deferUpdate time

Xvnc uses a "deferred update" mechanism which enhances performance in many cases. After any change to the framebuffer, Xvnc waits for this number of milliseconds (default 40) before sending an update to any waiting clients. This means that more changes tend to get coalesced together in a single update. Setting it to 0 results in the same behaviour as earlier versions of Xvnc, where the first change to the framebuffer causes an immediate update to any waiting clients.

-SendCutText

Send clipboard changes to clients (default is on). Note that you must also run vncconfig(1) to get the clipboard to work.

-AcceptCutText

Accept clipboard updates from clients (default is on). Note that you must also run vncconfig(1) to get the clipboard to work.

-AcceptPointerEvents

Accept pointer press and release events from clients (default is on).

-AcceptKeyEvents

Accept key press and release events from clients (default is on).

-ShareFiles

Enable file sharing with clients (default is on).

-DisconnectClients

Disconnect existing clients if an incoming connection is non-shared (default is on). If DisconnectClients is false, then a new non-shared connection will be refused while there is a client active. When combined with NeverShared this means only one client is allowed at a time.

-NeverShared

Never treat incoming connections as shared, regardless of the client-specified setting (default is off).

-AlwaysShared

Always treat incoming connections as shared, regardless of the client-specified setting (default is off).

-Protocol3.3

Always use protocol version 3.3 for backwards compatibility with badly-behaved clients (default is off).

-CompareFB

Perform pixel comparison on framebuffer to reduce unnecessary updates (default is on).

-SecurityTypes sec-types

Specify which security schemes to use separated by commas. At present, "None", "VncAuth", "RA2" and "RA2ne" are supported. The default is "RA2". See also UserPasswdVerifier

-ReverseSecurityTypes sec-types

Specify which security schemes to use for reverse (server-initiated) connections, separated by commas. At present, "None" and "RA2" are supported. The default is "RA2".

-IdleTimeout seconds

The number of seconds after which an idle VNC connection will be dropped (default is 3600 i.e. an hour).

-QueryConnect

Prompts the user of the desktop to explicitly accept or reject incoming connections. This is most useful when using the vnc.so module or x0vncserver(1) program to access an existing X desktop via VNC.

For Xvnc(1) processes, this option can be combined with allowedUsers/Groups settings or VNC Extended Authentication to allow certain users to connect without the desktop user being prompted.

The vncconfig(1) program must be running on the desktop in order for QueryConnect to be supported by the vnc.so(1) module or Xvnc(1) program. If vncconfig(1) is not running then any connection that should be queried is instead rejected. The x0vncserver(1) program does not require vncconfig(1) to be running.

-QueryOnlyIfLoggedOn

If set, Xvnc will not prompt for a connection to be accepted unless there is already at least one connection to the server. At present, this parameter is ignored by x0vncserver and the vnc.so module. Default is off.

-QueryConnectTimeout seconds

Specify the number of seconds for which the query connection dialog is displayed. The default is 10 seconds.

-QueryTimeoutRights rights

Specify the default action if the query connect dialog times out. The default is that no rights should be granted (i.e. the connection is refused). Setting this to an access string of the form described in the AllowedUsers and AllowedGroups parameters means that the connection will be accepted with the specified permissions.

-localhost

Only allow connections from the same machine. Useful if you use SSH and want to stop non-SSH connections from any other hosts. See the guide to using VNC with SSH on the web site.

-log logname:dest:level

Configures the debug log settings. dest can currently be stderr or stdout, both of which send log output to ~/.vnc/<server>:<desktop>.log (but see below for the log file location when running with inetd). Level is between 0 and 100, 100 meaning most verbose output. logname is usually * meaning all, but you can target a specific source file if you know the name of its "LogWriter". Default is *:stderr:30.

-RemapKeys mapping

Sets up a keyboard mapping. mapping is a comma-separated string of character mappings, each of the form char->char, or char<>char, where char is a hexadecimal keysym. For example, to exchange the " and @ symbols you would specify the following:

RemapKeys=0x22<>0x40

-AllowedUsers users and -AllowedGroups groups

Which users/groups are allowed to connect, and what level of access they have. Both users and groups are comma-separated lists of access control specifications, each of the form:

name[:access]

Where access is an optional string consisting of the following characters

v - User can view desktop.
p - User can send mouse input.
k - User can send keyboard input.
c - User can exchange clipboard contents.
q - User can bypass the QueryConnect prompt.
d - Default access (equivalent to vpkc).
f - Full access (equivalent to dq).

If access is not specified, it defaults to d. For example, to specify that the superuser has full access, and that members of the group "staff" have default access, the following options should be used:

-AllowedUsers root:f
-AllowedGroups staff:d

If not specified explicitly in the AllowedUsers parameter, the desktop owner is granted full access. To amend the above example to grant the desktop owner full access, the following could be used in a vncserver(1) configuration file:

-AllowedUsers root:f,$USER:f
-AllowedGroups staff:d

The permissions specified by the AllowedUsers and AllowedGroups are considered only if the corresponding global settings, SendCutText, AcceptCutText, AcceptPointerEvents, AcceptKeyEvents, ShareFiles and QueryConnect are enabled.

-PasswordFile passwd-file, -AdminPasswordFile passwd-file, -ViewOnlyPasswordFile passwd-file and -InputOnlyPasswordFile passwd-file

The files from which the passwords for the "user" (or no user name), "admin", "viewonly" and "inputonly" users should be read. The files are accessed each time a connection comes in, so can be changed on the fly via vncpasswd(1). These usernames and passwords are only used if UserPasswdVerifier is set to "VncAuth". If any of these parameters is not set, then the corresponding user is disabled.

-UserPasswdVerifier verifier

For the RA2 and RA2ne security types, UserPasswdVerifier determines which method to use to verify a user's password. The currently supported values are "None" (do not require a password to access the server), "VncAuth" (use the passwords defined by the PasswordFile, InputOnlyPasswordFile, ViewOnlyPasswordFile and AdminPasswordFile parameters) or "UnixAuth" (use the standard UNIX login password in conjunction with the AllowedUsers and AllowedGroups parameters). The default is "UnixAuth".

-EnableGuestLogin

Allow users to connect using the guest user name and password (see below). This option is usually set using the vncconfig program. The default is off.

-GuestUserName name

The user name for the guest login, if enabled. The default is "guest".

-GuestAccess access

The level of access to grant the "guest" user specified as an access control string as described under the AllowedUsers parameter. The default is 0, meaning no access, even if the EnableGuestLogin parameter is set.

-GuestPasswordFile passwd-file

The file from which the password for the "guest" user should be read. Like the VNC authentication password files, this file is accessed each time a connection comes in, so can be changed on the fly via vncpasswd(1). Unlike the other password parameters, if this parameter is not set, then the "guest" user does not require a password.

-RestrictVncConfig

Restrict vncconfig to be useable only by the owner of this desktop.

-AllowRFB, -AllowHTTP

Allow RFB and HTTP connections, respectively. Default is on.

-AuthTimeout seconds

Set the number of seconds to allow for authentication.

-BlacklistThreshold connections and -BlacklistTimeout seconds

Blacklisting is a mechanism designed to protect against brute force password attacks. BlacklistThreshold is the maximum number of consecutive unsucessful connections from any given IP address before that IP address is blacklisted. Connections from a blacklisted IP address will be ignored, initially for a period of BlacklistTimeout seconds, but this period will double for each subsequent unsuccessful connection attempt thereafter until a successful attempt is made.

-Hosts filter

Configure IP-address-based connection filtering. filter should be a comma-separated list of IP-address/subnet-mask pairs, prefixed with +, - or ? to accept, reject or query addresses in the specifed range, respectively. Addresses not included in filter are rejected. For example, the following filter will reject connections from 192.168.1.24 but accept connection from all other IP addresses:

-192.168.1.24/255.255.255.255,+0.0.0.0/0.0.0.0

-InetdLogFile file

Specify where log messages should be saved when Xvnc is running in inetd mode (see below). The default is /tmp/Xvnc-inetd-$DISPLAYNUM-$USER.log

-InTransports transports

Specify a comma-separated list of address families on which to accept connections. Families are specified by number---see platform networking headers for valid values. The special mnemonics IPv4 and IPv6 are also supported.

-Render

Enable the Render extension. Default is on.

USAGE WITH INETD

In the nowait mode, Xvnc uses its standard input and output directly as the connection to a viewer. It never has a listening socket, so cannot accept further connections from viewers (it can however connect out to listening viewers by use of the vncconfig program). Further viewer connections to the same TCP port result in inetd spawning off a new Xvnc to deal with each connection. When the connection to the viewer dies, the Xvnc and any associated X clients die. This behaviour is most useful when combined with the XDMCP options -query and -once. An typical example in inetd.conf might be (all on one line):

5950 stream tcp nowait nobody /usr/local/bin/Xvnc Xvnc -inetd -query localhost -once securitytypes=none

In this example a viewer connection to :50 will result in a new Xvnc for that connection which should display the standard XDM login screen on that machine. Because the user needs to login via XDM, it is usually OK to accept connections without a VNC password in this case.

Note that on Solaris 2.6, 7 and 8 there is a bug in the dtlogin program which provides the login window via XDMCP. To work around this give the option "-nolisten named" to Xvnc as well. Also on Solaris because of a limitation in the number of command-line arguments supported by inetd you will probably need to write a wrapper script to launch Xvnc.

In the wait mode, when the first connection comes in, inetd gives the listening socket to Xvnc. This means that for a given TCP port, there is only ever one Xvnc at a time. Further viewer connections to the same port are accepted by the same Xvnc in the normal way. Even when the original connection is broken, the Xvnc will continue to run. If this is used with the XDMCP options -query and -once, the Xvnc and associated X clients will die when the user logs out of the X session in the normal way. It is important to use a VNC password in this case. A typical entry in inetd.conf might be:

5951 stream tcp wait james /usr/local/bin/Xvnc Xvnc -inetd -query localhost -once passwordFile=/home/james/.vnc/passwd

In fact typically, you would have one entry for each user who uses VNC regularly, each of whom has their own dedicated TCP port which they use. In this example, when user "james" connects to :51, he enters his VNC password, then gets the XDM login screen where he logs in in the normal way. However, unlike the previous example, if he disconnects, the session remains persistent, and when he reconnects he will get the same session back again. When he logs out of the X session, the Xvnc will die, but of course a new one will be created automatically the next time he connects.  

SEE ALSO

AUTHOR