To allow for remote, Xvnc-based sessions from the network to a Linux machine using vncserver, we can leverage the xinetd infrastructure to dynamically, and on-demand, spawning Xvnc servers for incoming remote connections. To do so, create a file named /etc/xinetd.d/xvncserver:

  # cat > /etc/xinetd.d/xvncserver
  service vnc
  {
    protocol    = tcp
    socket_type = stream
    wait        = no
    user        = nobody
    server      = /usr/bin/Xvnc
    server_args = -inetd -query localhost -once \
                  -geometry 800x600 -depth 16 \
                  -desktop fab.felipe-alfaro.com \
                  -securitytypes=none
  }

Then, add the following line to file /etc/services:

  vnc             5901/tcp

Port 5901/tcp corresponds to the first display of an VNC server, that is, display :1. Thus, when using the vncviewer client, the :1 parameter must be passed to specify this display.

The last step is to restart the xinetd daemon by running:

  # service xinetd restart

NOTE: For this to work, XDCMP support must be enabled for XDM/GDM/KDM or whatever login manager is being used. This is due to Xvnc using -query localhost in order to present a login screen.

With ASP.NET pages, if code behind is used, a separate .cs file must contain the C# source code. This C# file must be manually compiled into a .DLL and placed in the Mono /lib directory, so that Mono can make use of it.

However, with XSP, it’s possible to tell Mono where the .cs code behind file is placed, so the whole process is automated. For example, instead of specifying the following Page directive in the .aspx file:

< %@ Page language="c#" Inherits="MonoTest.Test" %>

we could have specified the following one:

< %@ Page language="c#" Inherits="MonoTest.Test" Src="codebehind1.cs" %>

The new Page directive tells Mono where to find the codebehind source file and it’s name.