Managing Local and Network Displays
Figure 1-1 shows a possible login server configuration.
Figure 1–1 Possible login server configuration
Finding the Login Server Process ID
By default, the login server stores its process ID in /var/dt/Xpid.
To change this, you can set the Dtlogin.pidFile resource in the Xconfig file. If changed, the directory specified must exist when the login server is started.
To modify Xconfig, copy Xconfig from /usr/dt/config to /etc/dt/config. After modifying /etc/dt/config/Xconfig, tell the login server to reread Xconfig by typing:
/usr/dt/bin/dtconfig -reset
This issues the command kill -HUP login_server_process_ID.
For example, to store the login server process ID in /var/myservers/Dtpid, set the following in the Xconfig file:
Dtlogin.pidFile: /var/myservers/Dtpid
When the login server is restarted, the login server will store its process ID in /var/myservers/Dtpid. The /var/myservers directory must exist when the login server is started.
Displaying a Login Screen on a Local Display
Upon startup, the login server checks the Xservers file to determine if an X server needs to be started and to determine if and how login screens should be displayed on local or network displays.
To modify Xservers, copy Xservers from /usr/dt/config to /etc/dt/config. After modifying /etc/dt/config/Xservers, tell the login server to reread Xservers by typing:
/usr/dt/bin/dtconfig -reset
This issues the command kill -HUP login_server_process_ID
The format of an Xservers line is:
display_name display_class display_type X_server_command
where
display_name—tells the login server the connection name to use when connecting to the X server (:0 in the following example). A value of * (asterisk) is expanded to host name:0. The number specified must match the number specified in the X_server_command connection number.
display_class—identifies resources specific to this display (Local in the following example).
display_type—tells the login server whether the display is local or a network display, and how to manage the Command Line Login option on the login screen (local@console in the following example).
X_server_command—identifies the command line, connection number, and other options the login server will use to start the X server (/usr/bin/X11/X: 0 in the following example). The connection number specified must match the number specified in the display_name.
The default Xservers line is similar to:
:0 Local local@console /usr/bin/X11/X :0
Running the Login Server without a Local Display
If your login server system has no bitmap display, run the login server without a local display by commenting out the Xservers line for the local display using a # (pound sign). For example,
# :0 Local local@console /usr/bin/X11/X :0
When the login server starts, it runs in the background waiting for requests from network displays.
Accessing Command Line Login on a Local Display
When the user selects Command Line Login on the login screen, the login server temporarily terminates the X server, allowing access to the traditional command-line login running on the bitmap display terminal device. After the user has logged in and then out, or after a specified time-out, the login server will restart the X server.
Note –
The Command Line Login option is unavailable on network displays.
The display_type controls the behavior of Command Line Login. The format of display_type is:
When local@display_terminal_device is specified, the login server assumes that the X server and /dev/display_terminal_device are on the same physical device, and that a command line login (usually getty) is running on the device. When the user selects Command Line Login, the X server is terminated, allowing access to the running command-line login (getty) running on the /dev/display_terminal_device.
To disable the Command Line Login option on a display, specify none as the display_terminal_device. The default display_terminal_device is console. When local is specified, display_terminal_device defaults to console. When foreign is specified, Command Line Login is disabled.
Note –
The Command Line Login option will be disabled on the local display when the login server is started from the command line.
Accommodating a Character Display Console
If your login server system has a directly attached character display serving as a console, you may also want to set display_terminal_device to none to disable Command Line Login on the bitmap display login screen.
Alternatively, if a command-line login (getty) is running on both the character display console and the bitmap display, you can change display_terminal_device to the command line login (getty) device on the bitmap display.
For example, if the bitmap display command-line login (getty) is on device /dev/tty01, change the display_type to local@tty01.
Displaying a Login Screen on a Network Display
The login server can accept requests from network displays to display a login screen on that particular display. The network display is usually an X terminal but can also be a workstation.
To manage requests from network displays, the login server supports the X Display Manager Protocol (XDMCP) 1.0. This protocol enables the login server to negotiate and accept or reject requests from network displays. Most X terminals have XDMCP built in.
XDMCP Direct Requests from Network Displays
When you configure your X terminal to use XDMCP direct (query mode), you tell your X terminal the host name of the login server host. When the X terminal is booted, it automatically contacts the login server, and the login server displays a login screen on the X terminal. See your X terminal documentation for information describing how to configure your X terminal for XDMCP direct mode.
Most X servers also support the -query option. In this mode, your X server behaves as if it were an X terminal, contacting the login server host directly and requesting that it display a login screen on the X server. For example, starting the X server on a bitmap display on workstation bridget will have login server anita display a login screen on the X server:
X -query anita
XDMCP Indirect Requests from Network Display
When you configure your X terminal to use XDMCP indirect mode, you tell your X terminal the host name of the login server host. When the X terminal is booted, it will contact the login server, and the login server will present a list, through a chooser screen, of other login server hosts on the network. From this list, the user can select a host, and that host will display a login screen on the user's X terminal. See your X terminal documentation for information describing how to configure your X terminal for XDMCP indirect mode.
As with direct mode, most X servers support the -indirect option, which causes your X server to contact the login server in XDMCP indirect mode.
Managing Non-XDMCP Network Displays
Older X terminals may not support XDMCP. For the login server to display a login screen on this type of X terminal, list the X terminal name in the Xservers file.
Since the display is on the network, display_name includes the host name as part of the name. The display class can be used to specify resources specific to a particular class of X terminals. (Your X terminal documentation should tell you the display class of your X terminal.) The display_type of foreign tells the login server to connect to an existing X server rather than to start its own. In this case, an X_server_command is not specified.
Example
The following lines in the Xservers file direct the login server to display a login screen on two non-XDMCP X terminals, ruby and wolfie:
ruby.blackdog.com:0 AcmeXsta foreign wolfie:0 PandaCo foreign
Controlling Access to the Login Server
By default, any host on your network that has access to your login server host can request a login screen be displayed. You can limit access to the login server by modifying the Xaccess file.
To modify Xaccess, copy Xaccess from /usr/dt/config to /etc/dt/config. After modifying /etc/dt/config/Xaccess, tell the login server to reread Xaccess by typing:
/usr/dt/bin/dtconfig -reset
This issues the command kill -HUP login server process ID.
XDMCP Direct
When a host attempts to connect to the login server via XDMCP-direct, the host name is compared to the Xaccess entries to determine whether the host is allowed access to the login server. Each Xaccess entry is a host name including the wildcards * (asterisk) and ? (question mark). An * (asterisk) matches zero or more characters and a ? (question mark) matches any one character. An ! (exclamation point) prefacing an entry disallows access, while no preface allows access.
For example, say Xaccess contains the following three entries:
amazon.waterloo.com *.dept5.waterloo.com !*
The first entry allows access to the login server from host amazon.waterloo.com, the second entry allows access from any host whose full domain name ends in dept5.waterloo.com, and the last entry disallows access from any other host.
XDMCP Indirect
When a host attempts to connect to the login server via XDMCP-indirect, the host name is compared to the Xaccess entries to determine whether the host is allowed access to the login server. Each Xaccess entry is similar to the XDMCP-direct entries, including wildcards, except that each entry is marked with a CHOOSER string. For example:
amazon.waterloo.com CHOOSER BROADCAST *.dept5.waterloo.com CHOOSER BROADCAST !* CHOOSER BROADCAST
Again, the first entry allows access to the login server from host amazon.waterloo.com, the second entry allows access from any host whose full domain name ends in dept5.waterloo.com, and the last entry disallows access from any other host.
One of the following can be listed after the CHOOSER.
BROADCAST tells the login server to broadcast to the login server sub-network to generate a list of available login server hosts. A list of host names tells the login server to use that list for the list of available login hosts. For example:
amazon.waterloo.com CHOOSER shoal.waterloo.com alum.waterloo.com *.dept5.waterloo.com CHOOSER BROADCAST !* CHOOSER BROADCAST
If amazon.waterloo.com connects via XDMCP-indirect, it will be presented a list containing shoal and alum. If alice.dept5.waterloo.com connects, it will be presented with a list of all available login server hosts on the login server sub-network. Other XDMCP-indirect requests will be denied.
An alternative to specifying a list of host names is to define one or more macros containing the list of host names. For example:
%list1 shoal.waterloo.com alum.waterloo.com amazon.waterloo.com CHOOSER %list1
- © 2010, Oracle Corporation and/or its affiliates