From milun@cs.buffalo.edu Mon Nov 7 11:40:56 EST 1994
Article: 25382 of comp.unix.solaris
Newsgroups: comp.sys.sun.admin,comp.unix.solaris
Path: babbage.ece.uc.edu!news.kei.com!ub!acsu.buffalo.edu!milun
From: milun@cs.buffalo.edu (Davin Milun)
Subject: Re: xdm on Solaris 2.3
Message-ID:
Sender: nntp@acsu.buffalo.edu
Nntp-Posting-Host: obelix.cs.buffalo.edu
Organization: State University of New York at Buffalo/Computer Science
References: <385jpl$nvu@paperboy.gsfc.nasa.gov>
Date: Thu, 20 Oct 1994 15:33:11 GMT
Lines: 597
Xref: babbage.ece.uc.edu comp.sys.sun.admin:42187 comp.unix.solaris:25382
Jim Poland wrote:
>I'm trying to use xdm on a SPARCstation 10 running Solaris 2.3. I've
>encountered two problems so far:
>
>1) There is very little documentation about setting up xdm. I've got the
>man page, but it is just the X11R5 man page, with all the wrong paths. For
>example, the man page says /usr/lib/X11/xdm, and the real site is
>$OPENWINHOME/lib/xdm. There's no mention of starting xdm in Solaris 2.x. I
>have the system administrator and end user answerbooks installed, but
>there's no reference to xdm. Is there another answerbook or other docs that
>ship with 2.3 that I haven't found?
Attached below is a XDM FAQ that richm@netcom.com got from Sun, and posted
to the net a few months back.
>2) I finally got xdm to do its thing by placing a script in /etc/rc3.d, but
>when xdm is running, users can't play audio, i.e., audioplay signals that I
>need to check /dev/audio and /dev/audioctl to make sure that they exist and
>are valid links. They do and they are. When I try to execute audioplay from
>the command line, I get permission denied. (Oops, the first reference to
>audioplay was from opening an audio file in the file manager.)
My guess here is that you have /etc/logindevperm set to chown /dev/audio to
the owner of /dev/console. This is usually a good thing, but might be
messing you up in this case.
Davin.
-------------------------------------------------------------------------------
Davin Milun Internet: milun@cs.Buffalo.EDU
BITNET: milun%cs.buffalo.edu@ubvm
Fax: (716) 645-3464
-------------------------------------------------------------------------------
Sun XDM Frequently Asked Questions
------------------------------------
Question Index
--------------
1. Briefly, what is XDM and what are the benefits of using it ?
2. Under SunOS 4.x, how is a system be set to run xdm automatically
upon reboot ?
3. Under SunOS 5.0, 5.1, 5.2, how is a system be set to run xdm
automatically upon reboot ?
4. Why does it take about 5 minutes for the xdm login widget be
redisplayed after the OpenWindows XDM session is exited ?
5. How is cmdtool prevented from using 100 % of the CPU when it is run
under XDM ?
6. Why are characters not echoed in the cmdtool window when it is run under
xdm ?
7. How is XDM set up to control a remote 3rd party XTerminal ?
8. What is XDMCP, and what it is for ?
9. On the machine that is running XDM to control remote XTerminals, why
does a user fail to login from its console ?
10. On a monochrome system, why is the xdm login widget not displayed and
the screen is all one color ?
11. What files can be modified to customize a XDM login ?
12. Why does the login widget reappear right after a user logs in ?
13. What are the differences between a standard getty login, and an XDM login ?
14. Why does quitting one session from one XTerminal cause all XTerminals
to reset ?
15. Why do console messages display on the root window rather than in the
console window when OpenWindows is run via XDM ?
Questions with Answers
----------------------
1. Briefly, what is XDM and what are the benefits of using it ?
The X Display Manager (XDM) is a process that manages one or
multiple X displays. It provides services similar to that of
init, getty and login on character terminals but tailored for
bitmapped displays.
The biggest two benefits to using XDM are:
* It standardizes the login process among machines,
platforms and other X displays.
* It provides an automated facility for moving the
user from the login to the windowing environment.
Because of these conveniences, differences in machine architecture
becomes transparent to user.
2. Under SunOS 4.x, how is a system be set to run xdm automatically
upon reboot ?
To set up xdm to be started automatically upon reboot, /etc/rc.local
should be modified:
a. Become "root".
b. At the end of the "/etc/rc.local" file, add the following lines:
OPENWINHOME=/usr/openwin; export OPENWINHOME
LD_LIBRARY_PATH=$OPENWINHOME/lib; export LD_LIBRARY_PATH
$OPENWINHOME/bin/xdm -nodaemon -config $OPENWINHOME/lib/xdm/xdm-config &
(Note that the OPENWINHOME environment variable should be
changed accordingly to where the OpenWindows software is
actually installed. In this example, /usr/openwin is assumed
to be the default location for the OpenWindows software.)
c. Reboot the machine.
3. Under SunOS 5.x, how is a system be set to run xdm automatically
upon reboot ?
To set up xdm to be started automatically upon reboot, the following
steps should be performed to accomplish this:
a. Login or switch user to "root".
b. Create a file:
xdm-setup
in the /etc/init.d directory.
The following entries should be in the xdm-setup file:
#! /bin/sh
#
# xdm-setup -- script file to startup and stop xdm.
OPENWINHOME=/usr/openwin; export OPENWINHOME
LD_LIBRARY_PATH=$OPENWINHOME/lib; export LD_LIBRARY_PATH
XDM_PID=`cat /usr/tmp/xdm-pid`
xdm_running () {
ps -p $XDM_PID > /dev/null 2>&1
}
case "$1" in
start)
if xdm_running; then
echo "xdm is already running." >&2
else
echo "starting xdm." >&2
$OPENWINHOME/bin/xdm -config $OPENWINHOME/lib/xdm/xdm-config
fi
;;
stop)
if xdm_running; then
echo "stopping xdm." >&2
kill $XDM_PID
else
echo "xdm is not running." >&2
fi
;;
*)
echo "Usage: /etc/init.d/xdm-setup { start | stop }" >&2
;;
esac
(Note that the OPENWINHOME environment variable should be
changed accordingly to where the OpenWindows software is
actually installed. In this example, /usr/openwin is assumed
to be the default location for the OpenWindows software.)
c. Change the permissions of the xdm-setup file properly:
# chmod 755 /etc/init.d/xdm-setup
d. Create links, S99xdm and K99xdm, to the xdm-setup file in the
/etc/rc3.d directory:
# ln /etc/init.d/xdm-setup /etc/rc3.d/S99xdm
# ln /etc/init.d/xdm-setup /etc/rc3.d/K99xdm
e. Reboot the system. When the system comes back up, xdm
will be started automatically.
4. Why does it take about 5 minutes for the xdm login widget be
redisplayed after the OpenWindows XDM session is exited ?
This is a known bug with XDM (bugid: 1073567). The workaround
for the problem is to add the following resource lines to the
$OPENWINHOME/lib/xdm/xdm-config file.
DisplayManager*startAttempts: 10
DisplayManager*openRepeat: 1
DisplayManager*openTimeout: 15
DisplayManager*openDelay: 5
If the problem persists after the changes to the resources are made,
the value of the resource "DisplayManager*openTimeout" should be increased
until the problem goes away.
5. How is cmdtool prevented from using 100 % of the CPU when it is run
under XDM ?
This is a known bug with XDM (bugid: 1103973). The workaround is as
follows:
a. Compile the attached "cty.c" file with the following command:
cc cty.c -o cty
/*****************************************
* Beginning of "cty.c"
*****************************************/
#include
#include
#include
#include
#include
#include
#include
#include
extern char *sys_errlist[];
void error(msg)
char *msg;
{
int save_errno = errno;
char *err = sys_errlist[save_errno];
char *full_msg = (char *)malloc( strlen(msg) + 1
+ strlen(err) + 1);
strcpy(full_msg, msg);
strcat(full_msg, " ");
strcat(full_msg, err);
syslog( LOG_ERR, full_msg);
exit(save_errno);
}
int main(argc, argv)
int argc;
char *argv[];
{
char cmd[256];
int i;
int fd;
long max_open = sysconf( _SC_OPEN_MAX );
if((fd = open("/dev/tty", O_RDONLY))!=-1) {
ioctl(fd, TIOCNOTTY, 0);
}
setsid();
for( i = 0; i < max_open; i++)
close(i);
fd = open("/dev/console", O_RDWR);
if(ioctl( fd, TIOCSCTTY, 1) < 0)
error("Failed to make controling tty\n");
dup2(fd, 1);
dup2(fd, 2);
tcsetpgrp( fd, getpid());
putenv("SHELL=/bin/sh");
putenv("IFS=\" \"");
sprintf(cmd, "%s %s",
"/usr/bin/stty",
"2526:1805:1ad:8a3b:3:1c:7f:15:4:0:0:0:11:13:1a:19:12:f:17:16:0");
system(cmd);
execv(argv[1], &argv[1]);
return 0;
}
/*****************************************
* End of "cty.c"
*****************************************/
b. Copy the executable to a well-known location. In this example we
will use /etc:
# cp ./cty /etc/cty
c. In the file that starts XDM, add "/etc/cty" to the beginning of the
line that starts XDM. For example,
/etc/cty $OPENWINHOME/bin/xdm -config \
$OPENWINHOME/lib/xdm/xdm-config -nodaemon &
On SunOS 4.x systems, XDM is usually started in the file /etc/rc.local.
On SunOS 5.x systems, XDM is usually started by a file in /etc/init.d.
d. Stop the console getty from starting up by changing the line in the
/etc/ttytab file to:
console "/usr/etc/getty std.9600" sun off local secure
e. Reboot the machine.
6. Why are characters not echoed in the cmdtool window when it is run under
xdm ?
This is a known bug with XDM (bugid: 1073569). The problem is in how
cmdtool interacts with the tty when a controlling tty is not
present.
There are two ways to workaround the problem:
a. In each user's .openwin-menu file and in the system
$OPENWINHOME/lib/openwin-menu file, change the way on how cmdtool
is invoked.
Change the line from:
"Command Tool ..." $OPENWINHOME/bin/cmdtool
to:
"Command Tool ..." /usr/etc/setsid $OPENWINHOME/bin/cmdtool
b. In the user's .login, .cshrc, or .profile files add the following
entry:
stty sane
This will reset the tty settings to more realistic values that
cmdtool can work wit.
7. How is XDM set up to control a remote 3rd party XTerminal ?
Xdm can control remote XTerminals by two methods, a broadcast mode,
and a direct mode.
The broadcast mode is always available. There is no setup required
when adding new XTerminals to the network. The broadcast mode uses
a protocol called the X Display Manager Control Protocol or XDMCP,
which the XTerminal must understand. For more information on XDMCP
refer to question 7.
In direct mode, xdm controls the XTerminal that are specified in a
file. This file is specified by the resource:
DisplayManager.servers
in the xdm-config file. By default, the file is:
$OPENWINHOME/lib/xdm/Xservers
To add a new XTerminal that xdm should control in direct mode, follow
the following procedure:
a. Login or switch user to "root".
b. Edit the file $OPENWINHOME/lib/xdm/Xservers and add an entry
to the file:
foreign
The field specifies the identifier that should
be used so that X clients can connect to it (e.g. "ncd:0").
The field is essentially an identifier that
is used to distinguish different types of XTerminals. This
is useful if you have a large collection of similar XTerminals
and you would like to set resources for them as a group.
Therefore, the can be user defined.
Note that both the and fields
are used in parsing display-specific resources located in the
xdm-config file.
c. Tell xdm to re-read its configuration files by sending it a
HangUP signal:
# kill -HUP `cat /usr/tmp/xdm-pid`
8. What is XDMCP, and what it is for ?
XDMCP stands for X Display Manager Control Protocol which is a
standard protocol established by the X Consortium in 1989.
From the end user's point of view, it maintains the connection
between the XTerminal and its server in regardless of the state
of the XTerminal, namely ON or OFF.
When a XDMCP-compatible XTerminal is powered on, it would
broadcast a request for establishing a connection to a remote
host. A remote host has xdm running would reply and send a login
prompt to the XTerminal.
"xdm" Release 4 supports XDMCP. Therefore, if XDMCP is implemented
both on the XTerminal and xdm on the remote host, an entry for
the XTerminal is not required in the Xservers file.
However, if neither the XTerminal nor xdm on the remote host
supports XDMCP, an entry for the XTerminal should be put into
the Xservers file to force a direct connection between the
remote host and the XTerminal.
9. On the machine that is running XDM to control remote XTerminals, why
does a user fail to login from its console ?
SunOS Unix allows you to redirect the console device to another
location. This can be done when cmdtool, shelltool or xterm is
started with the -C option, and that is where the problem starts.
If a user on a XTerminal starts a cmdtool, shelltool or xterm
with the -C option, it becomes the owner of the console device of the
remote host. This causes the console device on the remote host be
owned by the user that is on the XTerminal. The console on the
remote host becomes inaccessible to user.
Control can be returned to the console screen by locating and
killing the process that has control of the console. Executing a
command like:
ps -auxw | grep "-C"
would locate the offending process. It could then be killed with
kill -TERM
where is the process id of the process that has control of the
console.
Additionally, you can keep this situation from ever occurring by
installing one of the following patches on the system:
100187 for SunOS version 4.0.3
100200 for SunOS version 4.1
100513 for SunOS versions 4.1.1, 4.1.2 and 4.1.3
Theses patches fix a bug which allows the console to be redirected
without any security checking (bugid: 1008324).
10. On a monochrome system, why is the xdm login widget not displayed and
the screen is all one color ?
By default, the foreground and background colors of the login
widget are not set to black on white or white on black. Since
it is a monochrome system, the login widget is displayed as a
greyish mesh.
To correct the problem, change the resources in the Xresources
file to either
xlogin*greetColor: black
xlogin*Foreground: black
xlogin*Background: white
Or
xlogin*greetColor: white
xlogin*Foreground: white
xlogin*Background: black
11. What files can be modified to customize a XDM login ?
The following files can be modified to customize a xdm login. Please
refer to the xdm manual page for additional information on these
files.
Xresources
This file is located in $OPENWINHOME/lib/xdm. The resources
in it specify how the login widget looks. You can specify
attributes such as color, font, greeting, width and height in
this file.
Xsession
This file is located in $OPENWINHOME/lib/xdm. It is a script
file that is run each time users login through xdm. It can be
used to initialize the environment per system or per user. It
should also run the users .xinitrc file or bring up some
"failsafe" clients if this fails.
xdm-config
This file is located in $OPENWINHOME/lib/xdm. There are a
series of resources in this file of the form
DisplayManager..:
These resources allow you to set a resource to a particular
value for a specific XTerminal display or class.
.xinitrc
This file is located in each user's home directory ($HOME).
When it is used in an environment running XDM, it may need
to be customized to set environment variables that would
normally be set in the user's .profile or .login files.
12. Why does the login widget reappear right after a user logs in ?
This problem could be caused by the followings:
a. If you have the DisplayManager*startup resource set
in the $OPENWINHOME/lib/xdm/xdm-config file, the startup
script defined by that resource could be failing in which
case XDM would terminate that session.
b. It is possible that OPENWINHOME environment variable is not
set (and exported if you are using Bourne or Korn shell).
This would cause your session to terminate and the login
widget would be redisplayed, even if none of the configuration
files reference this variable.
c. Make the user has execute permission on the .xinitrc file
under his home directory.
13. What are the differences between a standard getty login, and an XDM login ?
First off, the XDM login does not read the user's shell initialization
files like .login and .profile. Instead, it can be set up to read each
user's .xsession file.
Also, XDM does not read the /etc/fbtab file, does not log entries
to the /etc/utmp file and does not recognize password aging. However,
all these functions are performed in a regular getty login.
14. Why does quitting one session from one XTerminal cause all XTerminals
to reset ?
The most likely reason for the resource:
DisplayManager*reset
in the $OPENWINHOME/lib/xdm/xdm-config file is being set to:
$OPENWINHOME/lib/xdm/Xreset
If the entry does exist in the xdm-config file:
DisplayManager*reset: $OPENWINHOME/lib/xdm/Xreset
it should be changed to:
DisplayManager._0.reset: $OPENWINHOME/lib/xdm/Xreset
The xdm process should be restarted.
15. Why do console messages display on the root window rather than in the
console window when OpenWindows is run via XDM ?
Usually X clients like cmdtool, shelltool or xterm intercepts the
messages output and display the messages to its own window. However,
when the client is run under XDM, this client would not be able to
grab the console device because the user is not the owner of it. In
changing the ownership of /dev/console each time you logged in would
fix the problem. This problem is different from problem (9) that is
discussed earlier. In this case, xdm is monitoring the local display,
not a remote XTerminal.
The procedure below will allow messages from X clients be displayed to
the console window:
a. In $OPENWINHOME/lib/xdm/xdm-config add the following entry:
DisplayManager*startup: $OPENWINHOME/lib/xdm/Xstartup
b. Create $OPENWINHOME/lib/xdm/Xstartup:
#!/bin/sh
#
# Xstartup
chown $USER /dev/console
chown $USER /tmp/.NeWS-unix/N0
chown $USER /tmp/.X11-unix/X0
c. Change the permissions of $OPENWINHOME/lib/xdm/Xstartup appropriately:
chmod +x $OPENWINHOME/lib/xdm/Xstartup
d. Allow ownership of /dev/console to revert to root after OpenWindows
session terminated. This is done by adding the following entry to
the end of the $OPENWINHOME/lib/xdm/Xreset file:
chown root /dev/console
[Revision 12/29/93]