X-Win32 Knowledge Base

LIVE Server log files

2009-01-06T19:18:05-08:00

When launching a LIVE session sometimes your session may not launch as expected. In these instances you may want to check the log files to see what has occurred.

On the Windows side the messages that appear show the ssh connection status. If you can connect via ssh, then this issue will be located on the server side.

The LIVE server also contains a set of logs in $HOME/.nx-{servername}/ These logs generally contain more pertinent information regarding LIVE session issues.

The following files in the directory contain information regarding your sessions:

rxserver.log

This log file contains the general information about what is occurring. It will show the state of the session (starting, running, suspended, terminated etc).

C-{long hex string} directory

The C-* directory contains the files for the per session options.
There are a logs located in the C-* directory which will help debug your issues:

session

This file contains all the errors that occur after the LIVE Server has launched the Desktop remote command (for example (GNOME or KDE). If it seems that the LIVE server is launching correctly, but nothing appears, check this log. TYpical errors include Command not found at which point you need to specify the full path to your command in the LIVE session in X-Config.

errors

These are the errors that are logged when starting rxserver-bin. Generally they are just warning messages.

index

2009-01-06T19:16:50-08:00

Welcome to StarNet’s X-Win32 Knowledge Base

An excellent place to find X-Win32 answers!

Our X-Win32 Knowledge Base contains answers to frequently asked questions, details on support for particular X11 Client applications, helpful tips, and other information to help you get the most out of X-Win32. A link to each article in the X-Win32 Knowledge Base is below, organized in general categories. For more detailed categories, see our X-Win32 Knowledge Base Categories page.

Hot Questions

Frequently Asked Questions

Errors

Sessions

Installation

Features

Internationalization

Input

Applications

Color and font options for xterm and dtterm

Licensing

Sorry this promotional license has expired

Bugs

Automatically configuring the DISPLAY environment variable

2008-12-03T21:58:11-08:00

With X-Win32 you do not have to set the $DISPLAY environment variable in your login scripts (e.g. .bashrc, .cshrc, or .profile) on your remote UNIX, Linux, or BSD hosts (e.g. Red Hat, SuSE, Debian, Ubuntu, HP-UX, AIX, or Solaris) in order for the program in the command field of your X-Win32 sessions to work. In fact, setting this environment variable in your login scripts will most likely cause your X-Win32 sessions to work only when you connect from one of your Windows machines.

There are two different tactics for avoiding setting the $DISPLAY environment variable, depending on the type of session that you are using.

Avoiding setting $DIPSLAY for rexec and rsh sessions

If your remote host is on the same network (i.e. there are no firewall or network address translation (NAT) devices between your two hosts) as your X-Win32 machine, then simply add the -display DISPLAY command-line parameter to your X-Win32 sessions using X-Config, then remove all traces of setting $DISPLAY from your login scripts.
If there is a firewall or NAT device between the two computers and the remote computer is on the public Internet, then you can use X-Win32’s IPSmart facility to find the address of your NAT device; to do this, simply add the -display IPSMART:@DNUM@ command-line paramter to your X-Win32 sessions using X-Config, then remote all traces of setting $DISPLAY from your login scripts. If all of your sessions function this way, then you can instead change the address in X-Config’s Display tab to IPSmart, which will cause -display DISPLAY to return the IPSmart address.

For newly created sessions, be sure to use the Wizard button in X-Config’s Sessions tab to create each session. The Session Wizard automatically adds the -display DISPLAY command-line parameter to new rsh , rexec and telnet sessions that start xterm or dtterm.
Avoiding setting $DISPLAY for StarNetSSH sessions
If you are not using X11 Forwarding with your SSH sessions (e.g. because it is disabled in sshd_config on the remote host), then you should first and foremost turn this feature on as it will automatically set the $DISPLAY environment variable on the remote host for you, without the need to pass -display [...] on the command-line to your sessions.

If you are using X11 Forwarding with your StarNetSSH sessions but the $DISPLAY environment variable seems to be incorrect (noted by a cannot open display error when starting your StarNetSSH sessions) then you need to double-check your login scripts to be sure that they are not setting the $DISPLAY environment variable and thus overriding the value that sshd is setting it to.
Category:Sessions -> rexec
Category:Sessions -> rsh
Cateogry:Sessions -> SSH

Where can I find Release Notes for X-Win32

2008-12-02T18:03:55-08:00

X-Win32 8 and later include a link in the tray menu to the Release Notes for the installed version of the product. You can open this copy of the Release Notes by selecting Help -> Release Notes from the X-Win32 tray icon menu.

In addition, the Release Notes for the latest build of X-Win32 8 are available online:

Version 9
9.3
9.2
9.1
9.0
8.2

9 Flash – Online Release Notes

Category:FAQ

Sound Support Demo

2008-11-07T23:34:38-08:00

Note Sound Support currently is only available for the GNOME desktop using XDMCP

mpg123 is a command line mp3 player which is available for free. Red Hat machines ship without mp3 players because of licensing restrictions

Download http://www.mpg123.de/download.shtml
Extract the file: tar xzf mpg123*.tar.gz
cd into the file
Type: ./configure
su to root: su
Type: make
Type: make install

Type make clean
Type: esddsp mpg123 filename.mp3 to listen to your file.

See Also
Sound Support

Category:Sessions -> XDMCP
Category:Features

Sound Support

2008-11-07T23:26:49-08:00

Sound Support in XDMCP
X-Win32 now ships with the Enlightenment Sound Daemon (esd.exe) which is launched at startup. You can now pipe remote sounds in your XDMCP sessions. You can configure remote applications to send the sounds to X-Win32 by running the command esddsp in a terminal:

For example: esddsp application_name

Not all applications support esd and some special configuration may need to take place on a per application basis

XDMCP SuSE Linux yast2

2008-10-22T21:11:06-08:00

SuSE Linux and many other distributions which use KDE as the default desktop often have the yast tools installed on the operating system

Open a terminal as root
Launch: yast2
Click on: System > /etc/sysconfig Editor
Desktop > Display manager > DISPLAY_MANAGER_REMOTE_ACCESS > yes
Firewall > SuSEfirewall2 > FW_SERVICES_EXT_UDP > 177
Click Finish

Category:Sessions -> XDMCP

How do I enable XDMCP on my Unix machine

2008-10-22T21:07:23-08:00

On most Unix/Linux distributions XDMCP is disabled by default.

In order to enable your server to accept XDMCP connections you need to modify a few configuration files.

The configuration files are located in different directories depending on the distribution.

Please select the version you are currently using

XDMCP General Instructions
Note also that firewall ports must be opened. For a listing of which ports need to be opened, please see
What ports need to be opened for XDMCP

See Also
Securely tunnel my desktop through SSH

Category:FAQ
Category:Sessions -> Xdmcp

LIVE Starting live sessions on mounted file systems

2008-10-02T20:01:29-08:00

By default, LIVE creates a $HOME/.nx-servername/ directory where all necessary files are placed. However, when the $HOME directory is mounted, the server may not work across all machines. In order to work around this issue, users can choose to place their files on a local directory (usually /tmp).

LIVE server configuration files are stored in the following locations which will need to be created:

per user: $HOME/.config/StarNet/
for all users: /etc/xdg/StarNet/

The LIVE configuration files are:

LIVE sci.conf
LIVE Server.conf

Note: These files are case sensitive ie Capitalization counts!

The server option is

ServerDirectory=/tmp_directory/

where /tmp_directory/ is the location of the temporary directory For example /tmp/nx

There are serveral variables that the config files can interpret:
@USER@—variable which will be replaced with the username
@HOSTNAME@—variable which will be replaced with the hostname

To place each user’s directory in their own location, add the following line in “LIVE Server.conf” and “LIVE sci.conf”

ServerDirectory=/tmp/nx-@USER@-@HOSTNAME@

Category:Sessions -> LIVE

LIVE QtLockedFile lock No locks available

2008-10-02T19:29:00-08:00

The LIVE server has been designed to work with mounted directories. However under certain circumstances the LIVE Server will fail with the following error in the $HOME/.nx-servername/rxserver.log file

QtLockedFile::lock(): fcntl: No locks available 16.04.2008 16:01:04.521: Failed to lock the file

This is generally due to the mounted file system either being an AFS system which does not support NFS fiel locking or a misconfigured NFS lockd daemon.

To resolve these locking issues, the LIVE server’s .nx directory can be configured to be placed anywhere on the local system, such as the /tmp directory.

Create or edit the 2 files “LIVE sci.conf” and “LIVE Server.conf” in $HOME/.config/StarNet/
Add the following line in both files ServerDirectory=/tmp/.nx-@HOSTNAME@-@USER@
Your .nx directory will now be created locally and you will be able to properly create file locks.

Note: the directory can be located anywhere as long as you are not creating it on a networked directory.