---------------------------------------------------------------------------
Appendix A Host Access
---------------------------------------------------------------------------
Host Access
-----------
When an X client attempts to open an X display, the server checks to
see if that client is authorized to connect before it allows the
connection. If the client is not authorized, it gives a message such
as:
Xlib: Connection to "server:0.0" refused by server Xlib:
Server is not authorized to connect to host Error: Can't open
display
The X11R3 release gave only one method of authorizing clients to
connect. That method is giving access based on the IP address of the
host on which the client runs, also known as "xhost". The disadvantage
of this method is that when you give access to a host, call it "host1",
everyone who has an account on "host1" can access your display.
X11R4 introduced a new method of authorizing clients, called X
authorization, or MIT-MAGIC-COOKIE-1. When you log in using X11,
revision 4, xdm creates a file named ".Xauthority" in your home
directory. In this file is a 16-byte key, or cookie, that is sent to
the server as part of the connection setup information by X11R4
clients. If your client is running on a host that is not in the
"xhost" list, but the client sends the correct cookie, then it will
still be allowed to connect. Thus, when using an X11R4 xdm, your
"xhost" access list will typically be empty but clients will still be
able to connect.
X-Win32 obtains the "magic cookie" from xdm using XDMCP. The cookie is
generated by a random generator in xdm. If X-Win32 is started this
way, the initial "xhost" access list is empty, and access is
restricted. If it is not started with XDMCP, then access control is
disabled (any client is allowed to connect).
If you use an X11R4 xdm to get your login window, and want to bring up
older (R3) clients on your display, you need to add the hosts on which
those clients run to your access list. To do this, simply add the host
using the xhost command before bringing up the window. You can make a
permanent list of hosts that are in the access list of X-Win32 by
adding those hosts to the Xhost list under the Options selection. You
may want to do this in two cases:
1. You use X-Win32 in the non-XDMCP mode (any client can connect),
and want to limit the access list to "trusted" hosts.
2. You use it in the XDMCP mode (only R4 clients with correct
cookie allowed) and want to allow R3 clients from specific
hosts to connect to your server.
Clients are granted access if:
XDMCP
1. the client passes the correct MIT-MAGIC-COOKIE-1.
or
2. the client resides on a host whose IP address is in
the Host Access list.
Non-XDMCP
1. there are no entries in the Xhost list.
or
2. the client resides on a host whose IP address is in
the Xhost list.
A client can change the Host Access list (residing in local RAM memory)
if its entry in the Xhost list is preceded by a plus sign (+).
---------------------------------------------------------------------------
Page 22
---------------------------------------------------------------------------
Appendix B XDMCP
---------------------------------------------------------------------------
X-Win32 uses the standard protocol specified by the X Consortium for
use with X terminals, the X Display Manager Control Protocol, or
XDMCP. XDMCP is used by X terminals to control the xdm program on a
host on the network, The X terminal sends a request to the xdm host,
the host and the X terminal send a few XDMCP messages between
themselves, and then the xdm program brings up a login window on the X
terminal. XDMCP is a part of revision 4 of X version 11 and is
available from Sun as part of SunOS 4.1 or from DEC as part of Ultrix
4.2. If you have a host on your network with these versions or later,
you should run X-Win32 in one of the XDMCP modes if you want to use xdm
to manage your X server.
xdm goals
---------
A major goal of providing a display manager program is to integrate the
X terminal completely into a networked environment. As nearly as
possible the "log-in window" should automatically appear after the X
server is started.
Once you log in, an automatic initialization procedure should run to
bring up applications and position their windows as specified in your
personal session "profile" script. After you log out of the X session,
all connections should be closed, the terminal should be reset to a
known state, and a new log-in window should appear, ready for the next
user. This scenario can be achieved by having the X server communicate
with a display manager program between user sessions.
If you are running X11R4, you do not need to make any additions to the
host. However, if your are running X11R3, you may need to add a line
to the "Xservers" file on the host in the directory /usr/lib/X11/xdm.
The line you must add is "PC:0 foreign PC" where PC is the name of your
personal computer.
---------------------------------------------------------------------------
Page 23
---------------------------------------------------------------------------
Appendix C Transports
---------------------------------------------------------------------------
The supported winsock transports should already be configured to run
under Microsoft Windows. If it is not running properly, check the
following:
Trumpet.....Trumpet Winsock
---------------------------
For best use the Trumpet MTU setting should be 512.
It comes preset to 1500.
Microsoft.....Win95
-------------------
When using PPP it may be necessary to change the mtu setting to 552.
Hkey_Local_Machine/System/CurrentControlSet/Services/Class/NetTrans/00x
(Where x will be some integer depending on your system.)
1. From the Run menu enter "regedit"
2. Make selections on above path down to 00x.
Select the 00x section for "tcp/ip"
3. Select "New String Value".
Edit string to read "MaxMTU"
4. Under Edit, select Modify.
Enter "552"
5. Exit
000 ab(Default) (value not set)
ab DeviceVxDs
"vtdi.386,vip.386,vtcp.386,vdhcp.386.vnbt.386" ab
DevLoader "*ndis" ab DriverDesc
"TCP/IP" ab InfPath "NETTRANS.INF"
ab IPAddress "0.0.0.0" ab
Mask "0.0.0.0" ab
MaxMTU "552"
Ftp Software.....PC/TCP
----------------------
PC/TCP should be run in the 386 enhanced mode.
The following options should be used with the kernel startup:
[pctcp kernel] tcp-connections =15
The following may need to be added to SYSTEM.INI under [386Enh].
device=C:/ftp/vpctcp.386 UniqueDOSPSP=TRUE
PSPIncrement=5
Sun.....PC-NFS
--------------
The following may need to be added to SYSTEM.INI under [386Enh].
InDOSPolling=on UniqueDOSPSP=true PSPIncrement=5
TimerCriticalSection=1000
---------------------------------------------------------------------------
Page 24
Novell.....LWP4Dos
------------------
The default setting (no entry) in the net.cfg file for "tcp sockets"
is 8. To increase the number of sockets:
Protocol TCIP
tcp_sockets 16
Recommended changes to the net.cfg file
Link Support Buffers 16 3000 MemPool 8096 Max Stacks 16
WinSock.....Various
-------------------
Implementations and revisions of WinSock vary. The X server needs
to know the IP address of the PC. The above "IP Address Error"
may appear. It may be necessary for the user to either have:
1. the domain name server specified
(if the transport does host name resolution)
or
2. put an entry into the local HOSTS table for the PC.
(The entry should have the PC's name and IP address.
This file will usually look like the /etc/hosts file.)
IP Address Error It the error "I don't know my IP Address" appears
while trying to start-up in any mode, then the IP Address and Name of
the PC should be entered into TCPOpen under the DATABASE option into
HOSTS.
---------------------------------------------------------------------------
Page 25
---------------------------------------------------------------------------
Appendix D Troubleshooting
---------------------------------------------------------------------------
No X Window(s)
--------------
The X-Win32 icon was selected, and a session was then selected, but no
X windows appeared. When having trouble getting the connection
started, it is best to not have auto-startup turned on for any
sessions.
1. Check the Messages window for messages.
2. If one of the XDMCP modes was selected, you must make sure that xdm
is running. This can be done by using the Rsh... or Rexec...
function with the following command:
ps -ax | grep xdm
Look in the X-Win32 window for the results. If xdm is not
running, check with you system administrator. If xdm is
running, determine next if it is an X11R4 or later XDMCP
version:
netstat -an | grep 177
If an X11R4 or later xdm deamon running, the following line
will appear in the Messages window:
udp 0 0 *.177
3. A session will have to be started by selecting one of the
entered sessions. If there are not any entered sessions, then one,
or more, will have to be configured. All entries under the Sessions
list are started using either RSH or REXEC. The user should make
sure that the hosts can accept these commands. RSH may require an
entry in
.rhosts in that users home directory.
---------------------------------------------------------------------------
Page 26
Exits after XDMCP login window
------------------------------
After you log in to the XLOGIN window, xdm executes the script
Xsession, which is usually in /usr/lib/X11/xdm. (Sun's may be in
/usr/openwin/lib/xdm).
Note: If the login session is in failsafe mode (invoked by pressing
the F1 key instead of Return after you type your password) Xsession
simply runs an xterm.
If it is in normal mode, Xsession runs the file ".xsession" in your
home directory. In all cases, when Xsession exits, because the xterm
it runs exits or because the .xsession script exits, xdm will kill all
the windows on your display and log you out.
---------------------------------------------------------------------------
Problem:
Setting up a .xsession file with everything running in the
background causes .xsession to exit early.
For instance, if your .xsession file looks like this:
xrdb ~/.Xdefaults twm & sleep 4 xterm &
Then immediately after the xterm starts, .xsession will exit
which will cause you to be logged out. This will almost always
happen before xterm even has time to create a window.
Solution:
To fix this problem, change the last line to:
exec xterm
---------------------------------------------------------------------------
Problem:
Having a .xsession file in which the last program to be
executed fails and exits.
This could be for several reasons:
1. Because the program is not in your search path when
.xsession is run. To solve this problem make sure your path is
set up correctly in .xsession itself. Don't depend on the
program which calls .xsession to set it for you.
2. An X version incompatibility. In version 4 of the X
protocol, two things were added. The first was XDMCP. Thus,
if you are using XDMCP to get your XLOGIN window, you have at
least an X11 R4 version of xdm. The second thing added was the
MIT-MAGIC_COOKIE authorization. Under this scheme, a client,
upon connecting to the X server, sends some authorization
information. This is usually a 128-bit number that the server
has chosen and given to xdm using XDMCP. Xdm stores this
number in a file called ".Xauthority" in your home directory.
3. If X-Win32 is not in the Virtual Root (Single Window Mode)
and the last program is a window manager, then it will fail
because X-Win32-WIN32 uses the Microsoft window manager, which
will not allow an X window manager to run.
4. Virtual Root (Single Window Mode) is selected with the
"Enable Screen :0.1" selected and olwm is running under Open
Windows 3.0.
5. If you are using, for example, xterm from X11 R3 in the
last line of your .xsession file. It will not know how to send
this authorization information to the server. As a result, the
server will refuse the connection, xterm will exit, causing
.xsession to exit and your session will be terminated.
---------------------------------------------------------------------------
Page 27
Solution:
(1 thru 4) To solve the first problems you can start the X
server with XDMCP disabled, then log into your host system from
a different terminal. Set the environment variable "DISPLAY"
to your PC, set your PATH variable to the default (to
trouble-shoot problems with the search path), then run your
.xsession file by typing "./.xsession". If this terminates and
you get the shell prompt again, then something is wrong. Any
error messages should have appeared on your screen to help you
trouble-shoot the problem.
(5) Use the "Xhost" menu to add the IP address of your host to
the list of hosts that can connect without authorization.
---------------------------------------------------------------------------
Cannot open display
-------------------
Usually this error will occur if the display has not been properly defined.
As an example, the form of a display statement in an xterm command is:
-d dispname
Specifies the display screen on which xterm displays its window. If
the display option is not specified, xterm uses the display screen
specified by your DISPLAY environment variable. The display option has
the format hostname:number. Using two colons (::) instead of one (:)
indicates that DECnet is to be used for transport.
-display dispname
This option is the same as the -d option.
xterm -display 192.1.1.23:0 xterm -display davepc:0
Cannot run olwm
---------------
Cannot run OpenLook window manager (olwm)If you are running on a Sun
using Open Windows 3.0 and olwm, then be sure that:
"Enable screen :0.1"
is not selected during Virtual Root (single window) mode operation. If
"Enable screen :0.1" is enabled, then olwm should be started using the
form:
olwm -single &
Cannot read text in xterm
-------------------------
An xterm has come up, but the text is not readable. The cursor changes
as it is moved into and out of the xterm indicating that it is active.
This is usually a color problem. Either the colors selected for the
xterm are not correct or not available. It MS Windows is set to 16
colors and the xterm colors have been selected based on 256 colors, it
is possible to have both foreground and background mapped to the same
color.
This problem can also be caused by using "crystal fonts" on the ATI
video boards. The ATI software locks around 247 palette entries. This
is most noticeable when 256 colors is selected under the MS Windows
video driver setup.
---------------------------------------------------------------------------
Page 28
Client not authorized to connect to server
------------------------------------------
This happens because the client does not have authorization to connect
to this X server (X-Win32). Use of the Xhost table or the Host Access
List will give access to that client. Use the X-Utility to add needed
clients (hosts).
REMEMBER that the Xhost table is an all or none type list. If one host
is in the list, then ALL hosts which wish to have access to X-Win32
will either have to:
1. be in the Xhosts table
or
2. pass the magic cookie
Connection Closed
-----------------
I.P. Address or Hostname: connection closed.You should contact your
system administrator. A connection was made and the host closed the
connection. This may occur if:
1. you are trying to connect using rexec and rexecd or
in.rexec will not allow the connection to continue.
2. your host is running Sun OS and /etc/inetd.conf is not
correct or is trying to run something that does not exist.
3. your host is running a tcp wrapper that closes the
connection for security reasons.
Connection Refused: Host name not known
---------------------------------------
The Winsock compliant TCP/IP stack is responsible for resolving host
names to IP addresses. It may do it by using a DNS or by a local HOSTS
table. It may be necessary to enter the host names and ip addresses
into a local HOSTS table. Check the docs on your TCP/IP software. It
may be necessary to enter the name and ip address of the local pc
also.
Connection Refused: My IP address not known
-------------------------------------------
The TCP/IP stack needs to tell the X server (X-Win32) the IP address of
the PC. This information may need to be added to the local HOSTS
table.
Connection Timed Out
--------------------
You tried to connect to a host that is currently down or otherwise
unreachable.
Hanging of X server
-------------------
The user may encounter cases where the X server hangs. If running
under Windows 3.1 or WFW 3.11, try turning off the Async Interface
option using X-Util.
Hanging of the X server has only been observed using older versions of
Novell's tcp/ip winsock implementation. Report any other occurrances
of hanging to [email protected].
Hostname: No such file or directory
-----------------------------------
You are likely trying to use rsh, but are running the restricted shell
instead of the remote shell. You should change your path to get the
remote rsh.
The remote shell is normally /usr/bin/rsh. The restricted shell is
normally /usr/lib/rsh.
---------------------------------------------------------------------------
Page 29
LD:SO lib Xt.so.4 not found
---------------------------
This is the result of the host (Sun SPARC) system being shipped or
installed with some files being placed in a different directory.
Either the shared library cache is out of date, the shared library is
missing, or the shared library is not in your LD_LIBRARY_PATH. You
should either set the LD_LIBRARY_PATH environment variable ot the
appropriate value, run ldconfig to update the library cache, or install
the missing library. Try placing the following command into your home
directory, into the .cshrc file:
setenv LD_LIBRARY_PATH /usr/lib:/usr/openwin/lib
The directory path and the location of this file should be verified on
the host system prior to inserting the setenv line.
Permission Denied: Rsh
----------------------
A user must have an account on the remote host. A .rhosts file entry
allows a user who has an account on that host to log in from a remote
node without supplying a password. The .rhosts file must be in the
user's home directory. The format of a .rhosts file entry is:
hostname [username]
The hostname is the name of the local node (PC) from which the user
wants to log into the remote host. The username is the user's login
name on the PC. If you do not specify a user name, the user must have
the same login name on both the remote host and PC.
Each remote machine may have a file named /etc/hosts.equiv containing a
list of trusted hostnames with which it shares usernames. Users with
the same username on both the local and remote machine may rsh from the
machines listed in the remote machine's /etc/hosts file.
Permission Denied: File
-----------------------
If a script file is being executed, it must have execution permission.
Use:
chmod 775 script_filename
to allow execution and r/w permissions.
stty: Operation Not Supported
-----------------------------
If you are using rsh, the .cshrc file on the remote host probably has
an interactive command in it, such as stty.
Warning: Cannot convert string "..." to type FontStruct
-------------------------------------------------------
You cannot access the specified font, either because it does not exist
or because X-Win32 does not have access to it.
---------------------------------------------------------------------------
Page 30
Will not start - screen blanks
------------------------------
This can happen when running unders Windows 3.1 or WFW 3.11 and Win32s
has not been installed. Check to see if Win32s is installed. Check
the file /windows/system/win32s.ini. If it does not exist or the
version is 1.15 or less, then the current version of Win32 will need to
be installed.
Win32s is available from Microsoft at ftp.microsoft.com in
/Softlib/MSLFILES. Check the INDEX file in /Softlib for the filename
of the current version of Win32s (usually PW1118.EXE).
X Toolkit Warning: Cannot allocate colormap entry for ...
---------------------------------------------------------
Your color database is corrupted. You need to recreate the color
database. Use the X-Utility to verify and recompile the color
database.
xlock
-----
X-Win32 requires that the IP address of the host running xlock to
be in the XHOST table. Use of the -remote option is also required.
---------------------------------------------------------------------------
Page 31
---------------------------------------------------------------------------
Appendix E Sample Start-up Script
---------------------------------------------------------------------------
The user may wish to use a script start-up file in conjunction with the
RSH or REXEC commands. This start-up script file would reside on the
remote host in the users login directory. This would allow the user to
create his own X environment each time the X session is started. The
following example will set the display and then provide an xterm, an
xclock, and an xlogo each time this file is run.
The session entries may look as follows:
unixhost
dick (not needed for PC-NFS)
Xwin xpc (using the nickname of the PC)
or
Xwin 192.1.1.23 (using the IP address of the PC)
The start-up script file, which resides on the remote host, may be as
follows:
#!/bin/sh if [ "$1" ]; then (Set the display to the value
DISPLAY=$1:0.0 passed from RSH/REXEC)
export DISPLAY
fi
/usr/bin/X11/xterm -n Login -ls &
/usr/bin/X11/twm & (Use only if SW Mode)
/usr/bin/X11/xlogo &
for Sun Sparc's the path may be:
/usr/openwin/bin/xterm
---------------------------------------------------------------------------
Page 32
---------------------------------------------------------------------------
Appendix F XWIN32.INI
---------------------------------------------------------------------------
XWIN32.INI is a text file residing in the appropriate WINDOWS directory
which controls the set-up of X-Win32.
XWIN32.INI
--------------------------------------------------------------------------
[settings]
directory=c:/XWIN/lib
fontpath=c:/XWIN/lib/fonts/misc,c:/XWIN/lib/fonts/75dpi
rootname=X-Win32
mouse=2
debug=0
single=0
width=1016
height=732
screen1enable=0
Alt=2
debug=61440
KBDfile=us.kbd
resources=30
display=0
[sessions]
bart_ultrix=1:bart:demo::Xwin dick:0
esix=2:192.1.1.6:demo::./Xwin dick:0
sparc=1:sparc:demo::/usr/openwin/bin/xterm -ls -n sparc -display
192.1.1.13:0 & sun_360=1:192.1.1.15:dick::Xwin dick:0
[Xhost]
---------------------------------------------------------------------------
Page 33
[settings]
directory=c:/XWIN/lib
This directs X-WIN32 to the subdirectory that contains the keyboard,
rgb, and font files.
fontpath=c:/xwin32/lib/fonts/misc,c:/xwin32/lib/fonts/75dpi
mouse=2
One (1) = on and zero (0) = off.
0 = no 3-button simulation & no panning
1 = 3-button simulation & no panning
2 = no 3-button simulation & panning
3 = 3-button simulation & panning
Panning will move the selected X window on-screen by moving the cursor
to the edge of the window which is off-screen. Panning is not
operational inside the Virtual Root.
debug=0
One (1) = on and zero (0) = off.
Debug gives a list of the X requests being processed by the X server
(X-Win32). These requests are shown in the X-Win32 window. The
X-Win32 window may be resized to view more past requests.
single=0
width=1016
height=732
One (1) = on and zero (0) = off.
Single controls the Virtual Root Mode. If it is turned on, then a
single X window, whose dimensions are described by width and height, is
generated. A remote window manager should be used to manage the
windows created in this Virtual Root Window (single window).
screen1enable=0
One (1) = on and zero (0) = off.
Screen1enable, when turned on, allows the generation of X windows to
xpc:0.1, the second screen. This second screen is managed by the
Microsoft window manager.
KBDfile=us.kbd
This entry tells X-Win32 which keyboard file to use. The available
.kbd files are in /xwin/lib. If this field is not present X-Win32
checks MS Windows to select the proper keyboard. If it cannot
determine the proper .kbd file it will default to the built-in us.kbd
file.
Alt=2
This entry directs the left and right Alt keys. 0 = both to MS,
1 = left to X, 2 = right to X, 3 = both to X.
resources=30
Microsoft Windows 3.1 and WFW 3.11 have limited GDI (graphics)
resources. X-Win32 will try to maintain the selected level of % of GDI
resourses free. Obviously, you must start with greater than the amount
selected for X-Win32 to try to maintain that level. Setting the level
too high will cause X-Win32 to run slower.
---------------------------------------------------------------------------
Page 34
display=0
The X Window system allows more than 1 X server, also called a display,
to run on one machine (IP address). To distinguish between diferent X
servers (displays) on the same IP address, different TCP ports are used
starting with 6000. Display 0 listens on TCP port 6000, display 1
listens on TCP port 6001, display 2 listens on 6002, and so on.
The "DISPLAY" parameter to an X client tells it to which port to
connect. The display number is the first number to the right of the
colon (:).
X-Win32 can be configured to serve as any display number. The display
number is specified in the XWIN32.INI file as "display=n" where n is
the displaynumber, which defaults to 0. X-Win32 can only be run once
per PC serving as only one display at a time.
[sessions]
Named rsh, rexec, or xdmcp sessions.
[Xhosts]
A list of those hosts having access to X-Win32. No entries mean that
all hosts have access to X-Win32. If one entry is made to allow
access, then all hosts that wish to have access to X-Win32 will either
need to pass the magic cookie or be in this list also. It is an all or
none type field.
---------------------------------------------------------------------------
Page 35
