 |
 |
 |
 |
Supporting a Centralized System
This chapter provides instructions for setting up the necessary operating system support files. The values selected in the remote configuration file dictate the operating system files that must be enabled, created, or modified.
The examples provided in this section assume the use of a DECnet network using MOP and DAP for file transfer.
- Decide which network access method will be set up on the VAX to support the software files. Access of files over the network is required to boot the software. One of the following network access methods must be established. These methods are listed in decreasing security order (Proxy being the most secure).
- A Proxy login, used to permit users access to particular accounts on the VAX. When the remote user is assigned a proxy account on the VAX that maps to a local user account, the product assumes the same access privileges as the owner of the local account. This method validates network access for each individual product. Using Proxys is the most secure method of access between network computer nodes on a VAX network.
A detailed example of verification and creation of Proxy file access appears under Enabling Network Access in this section.- FAL (File Access Listener), used to validate requests from any remote node (XP or host) to allow local files on the VAX to be accessed by all other nodes.
- A default DECnet account, used for allowing access of all nonprivileged network activities.
- Add nodes to the NCP Database:
$ @TEK$TOOLS:TEKXP_ADD
For information about adding nodes to the NCP database, refer to the Adding Nodes to the NCP Database section later in this chapter.- Download and start specified local clients.
- Configure and start the Client Launcher local client.
- Optionally start local Motif Window Manager from within DECwindows.
- Update authorization keys of one or more network computers using the Authorization Key Manager client.
- Use the Touchscreen Calibration client to calibrate the touchscreen.
Enabling Network Access
Start the host-configuration process by verifying the licensed operation of DECnet and the availability of MOP. On DECnet networks, network computers are configured by default to use MOP for file transfers from the host.
- Verify the existence of a registered DECnet license by entering:
$ SHOW LICENSE DVNET*- Verify that DECnet is up and running by entering:
$ SHOW NETWORK- Check that service operations are allowed on the host circuit where the network computers connect for the boot files by entering:
$ MCR NCP SHOW KNOWN CIRCUIT CHARACTERISTICS
- The host responds with the following report:
Known Circuit Volatile Characteristics as of 25-OCT-1999 17:03:17
Circuit = QNA-0
State = on
Service = enabled- Designated router = 57.1 (R61B)
Cost = 4
Maximum routers allowed = 33
Router priority = 64
Hello timer = 15
Type = Ethernet
Adjacent node = 57.1 (R61B)
Listen timer = 45- Check the report to ensure that State = on and that Service = enabled.
If Service is disabled, enable it in both the volatile and permanent databases using the following command sequence.>>> CAUTION: The following command sequence turns off DECnet in order to enable the service state. DECnet connections that are active when the state switches to OFF will probably terminate. Please use this command sequence with caution.
- $ MCR NCP
NCP>SET CIRCUIT circuit-id STATE OFF
NCP>SET CIRCUIT circuit-id SERVICE ENABLED
NCP>DEFINE CIRCUIT circuit-id SERVICE ENABLED
NCP>SET CIRCUIT circuit-id STATE ON
NCP>EXIT
- Verify that DECnet network objects are known by entering:
$ MCR NCP SHOW KNOWN OBJECTS
Look to see that FAL and $MOM are listed.- Set up DECnet file access using one of the following supported types of access control. (See the DEC publication, VMS Authorize Utility Manual, for additional details.)
- Proxy login provides the highest level of system security implemented in the network computer and is the recommended type of access control. To provide network proxy login access for the network computers, you must create proxy entries as described in the DEC publication, Guide to DECnet-VAX Networking. As an example, the following commands create default proxy entries mapping the user on the network computer nodes:
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD/PROXY <XP-node-name>::TEKXPRESS <user account> /DEFAULT
UAF> EXIT
(where <user account> is a valid login account.)
- FAL (File Access Listener) default user access, make sure that the user id and password are set on the FAL object and that they match a valid, active account. Use the command $MCR NCP SHOW OBJECT FAL CHARACTERISTICS to check the user id and password information; use the AUTHORIZE utility to modify the account. (To use this command, you must have Bypass privilege.)
- Node/executor user access ensures that the non privileged user id and password are set for the executor and that they match a valid, active account. Use the command $MCR NCP SHOW EXECUTOR CHARACTERISTICS to check the non-privileged user id and non-privileged password information; use the AUTHORIZE utility to modify the account.
Adding Nodes to the NCP Database
During the VMSINSTAL procedure, you are prompted to enter node information. To add additional nodes, enter the following command:
$ @TEK$TOOLS:TEKXP_ADD.COMThis command procedure is provided on the media as a utility to assist you in adding network computer DECnet node information to your permanent and volatile NCP databases. TEK$TOOLS:TEKXP_ADD.COM adds the DECnet node name, node address, hardware ethernet address, and XP boot file name for your network computer model (XP330_OS.SYS, XP350_OS.SYS, XP500_OS.SYS for NC200 and NC400 units, or NC900_OS.SYS). During the VMSINSTAL phase, this command procedure is executed, giving you the opportunity to add nodes. You can add additional node information at any time using this command. The following prompts are included in the install script:
- Do you want to enter new DECnet nodes now (Y/N)? [Y]
Entering a ^Y at any time will safely exit this command procedure.
...
Enter DECnet name of the NC (1-6 characters) [ ] :
Enter the DECnet address; or ? to list current node entries [ ] :
Enter the NC hardware ethernet address [ ] :
Enter the NC boot filename [ NC900_OS.SYS ] :
- Is this correct? [yes] :
Enter information for another NC [yes]:Connecting to Other Nodes
Once the network computer is booted, you can use the Mirror feature to see what other nodes (hosts or network computers) DECnet can access. The Mirror feature can check the following connections:
- Enter Setup.
- Select the Network Tables and Utilities menu and drag on the Network Utilities option.
- In the Host Name/Host Address field, enter the name or address of the host or network computer for which you want to test for a DECnet connection. Optionally, specify the Test Packet information.
- Click on the TEST button to start the Mirror test. A message specifies whether the connection was successful or not.
- If the Mirror feature is used to test a network computer connection to a host, the network computer's Console can be used to display mirror statistics. The statistics include the test time, total number of packets, how many packets were read, and how many packets were written. (The number of packets read and written should equal the total number of packets.)
Local Clients
This section describes various ways to start local clients. Local clients are those applications that execute on the network computer, rather than on the host, thus reducing network traffic. HostMenu, Telnet, Cterm, and Motif Window Manager are examples of local clients. Local clients can be started with xpsh, the remote configuration file (XP.CNF), with rsh, or with the Client Launcher.
This section also describes the Client Launcher, the Authorization Key Manager, and the Touchscreen Calibration client.
The following local clients are available on the network computer:
Determining Local Client Versions
To see the version of any local client in the boot directory, use the UNIX ident command. For example, to see the version of Setup currently in use, enter ident setup.900 (where 900 is the OS level you booted with). The version and level information displays. You can use this command for any of the local clients.
Starting Local Clients With xpsh
xpsh is a host program used to download local clients to a network computer. It is a two-way communication mechanism between the host program (xpsh) and the local daemon (xpshd). xpsh sends information to the network computer specifying which local clients to download, and xpsh receives local client error messages and exit information from the network computer. xpsh can download and start:
Starting a client using xpsh enables the client to run locally instead of from the host. The host environment, client name, and arguments are sent to the local network computer. For example, using xpsh to download MWM enables access to files in $HOME. This allows you to customize the MWM environment for an individual user.
Clients can also be started with xpsh and access host-based configuration files. To do this, use the -access xpsh parameters when starting a local client with xpsh. For example, to start local Motif Window Manager and access the host-based configuration files, you would enter the following:
- xpsh -display display_name:0 -access xpsh mwm
Note: Local Netscape NC Navigator may not be started with xpsh from a VMS system; however, it may be started in kiosk mode from the System Launcher Menu. To reduce the startup time for a local client started with xpsh, you can access the client through an NFS path. (For information about NFS, refer to the Supporting a Centralized System chapter for your host.) For example, if you mount host_name:/tekxp/boot to /host_name/tekxp/boot on your network computer, you can invoke MWM with the command:
xpsh /host_name/tekxp/boot/mwm
To start a local client using xpsh, enter the appropriate command below:Starting the Audio Mixer
- xpsh -display display_name:0 mixer
Starting the Audio Player
- xpsh -display display_name:0 aplay
- The following options can be set on the xpsh command line:
-h host specifies the host name or address on which the audio file resides. The host must be entered in the network computer's Internet Host Table in Setup. This host displays in the Audio Player's File Information area.
-f filename and path specifies the audio file name and its entire path. This file displays in the Audio Player's File Information area.
-a access method specifies the access method used to access the audio file. Available access methods are tftp, nfs, and dap.
-v volume level specifies the volume level to use when playing the audio file. Specify a number between 0 and 100, with 0 indicating no volume, and 100 indicating the loudest volume setting.
-p when used with the -h, -f, -a, and -v options, the specified file plays without opening the Audio Player. The entire file plays and cannot be interrupted.
Starting the Authorization Key Manager
- xpsh authkey
The network computer reads the authkey.dat file when booting and updates the network computer and authorization key information. (Be sure that SNMP is available and enabled.)
Starting a Cterm session
A Cterm session can be started with a Tek220 or Tek340 emulator.
xpsh -display display_name:0 tek220 -e cterm
xpsh -display display_name:0 tek340 -e cterm
Resource settings can be specified for a Cterm session. Refer to the next section, Specifying Client Resource Settings.Starting the Digital Video Player
Note: This is not available on the NC900 Series.
- xpsh -display display_name:0 vplay
- The following vplay options can be set on the xpsh command line:
-h host specifies the host name or address on which the video file resides. The host must be entered in the network computer's Internet Host Table in Setup. This host displays in the Video Player's File Information area. When Multicasting, -h specifies the IP address. The port number displays in the Video Player's Addr/Port Information area.
-f filename and path specifies the video file name and its entire path. This file displays in the Video Player's File Information area. When Multicasting, -f specifies the port number. The address displays in the Video Player's Addr/Port Information area
-a access method specifies the access method used to access the video file. Available access methods are tftp, nfs, dap, and Multicast. NFS is the preferred file access method for faster and more accurate data transfer rates required by the player. In addition, there is a 16MB limit on files transferred with TFTP.
-v volume level specifies the volume level to use when playing the video file. Specify a number between 0 and 100, with 0 indicating no volume, and 100 indicating the loudest volume setting.
-m (Mute) specifies that the video file plays with no sound.
-c (Color) specifies that the video file displays in color (used only if the video was recorded in color).
-nc (No Color) specifies that the video file displays in greyscale images.
-brightness n sets the brightness level of the video file. Specify a number between -50 and +50.
-contrast n sets the contrast level of the video file. Specify a number between -50 and +50.
-b (Big) specifies that the video file displays in a frame four times the size of the original file.
-p (Playonly) when used with the options above, the specified file plays without showing the Video Player. The entire file plays and cannot be interrupted.
-all (Play All; software player only) plays all frames in a video file. Frame scheduling is ignored and the audio will not be in sync.
-title "string" assigns a title for the vplay windows.
-propcmd creates properties that allow other clients to send command strings to the Video Player. These properties cannot be changed or modified and are used to control the Video Player from another client that you create. For details about the properties, see the vplay man page.
-BUFSIZE n (Hardware Player only) specifies the size of the Video Player's memory buffer (in kilobytes). The value defaults to 1024 and can not be set lower than 1 kilobyte. If the value specified is greater than available memory when trying to play a file, the Video Player reduces its buffer to the available memory.
-CHKSIZE n (Hardware Player only) specifies that the Video Player's memory buffer is divided into "chunks", measured in kilobytes. The network fills the chunks, and the Video Player empties them as they are accessed. The default is 32, which divides the buffer into 32 kilobyte chunks. If the chunk size is set to a number larger than the buffer size, the chunk size will be truncated to one half the buffer size. The chunk size cannot be set less than 1 kilobyte.
-CHKDELAY n (Hardware Player only) specifies the time delay (in milliseconds) that the Video Player waits following each read request that fills a chunk.
-chan n (Multicast only) specifies an index into an array of available Multicast channels. Do not use with the -h, -f, -a, or -text options.
-text "string" (Multicast only) specifies the channel string to be displayed by the Video Player. Do not use with the -chan option.
Starting a LAT session
A LAT session can be started with a Tek220 or Tek340 emulator.
xpsh -display display_name:0 tek220 -e llogin
xpsh -display display_name:0 tek340 -e llogin
Resource settings can be specified for a LAT session. Refer to the next section, Specifying Client Resource Settings.Starting the Local Client Launcher
xpsh -display display_name:0 launcher
The following options can be added to the xpsh command line when starting the Client Launcher:
-auto Configures the Client Launcher with the automatic default settings even if a configuration file exists.
-file filename Configures the Client Launcher using a user-defined configuration file.
Starting local MWM
- xpsh -display display_name:0 mwm
Note: If both MWM version 1.1 and MWM version 2.0 are authorized, the 2.0 version will start. Starting a Serial Session for Port 0 and Port 1
A serial session can be started with a Tek220 or Tek340 emulator for port 0 or port 1.
xpsh -display display_name:0 tek220 -e tip tty0
xpsh -display display_name:0 tek340 -e tip tty1Starting Setup
xpsh -display display_name:0 setup
A network computer's Setup and Console window can also be started and displayed on a remote network computer or host using xpsh. Once started, you can use Setup to configure network computer settings, establish communication connections, and monitor network computer operations.
To access a network computer's Setup from a remote network computer or host using C shell, enter:
setenv TEKSETUP_DISPLAY display_device:0
xpsh -display display:0 setup
If using a different type of shell tool, enter:
xpsh -display display:0 -xpenv "TEKSETUP_DISPLAY=display_device:0" setup
where display is the remote network computer whose Setup and Console window is accessed, and display_device is the network computer or host where Setup is to display. Use IP addresses if the remote network computer does not know the host name of the display device (set up in the Internet Host Table in Setup).
If the network computer user currently has Setup started, it is not accessible remotely via xpsh. Likewise, if a remote network computer or host has Setup open via xpsh, it is not available to the network computer user.
Note: To prevent other users from accessing your network computer's Setup and resetting the server, set enable_access_control to Yes (in either the xp.cnf file or in Setup). Starting a Telnet session
A Telnet session can be started with a Tek220 or Tek340 emulator.
xpsh -display display_name:0 tek220 -e telnet
xpsh -display display_name:0 tek340 -e telnetResource settings can be specified for a Telnet session. Refer to the next section, Specifying Client Resource Settings.
Starting WinDD
xpsh can start the WinDD client as needed. To start WinDD with xpsh, enter the following (where display_name is the name or address of your network computer):
xpsh -display display_name:0 windd [options]
The following options can be set on the xpsh command line:
-display display:0
Specifies the display name or address to display the WinDD local client.-c Auto-connect to the first application server in the application server list. If there are no application servers in the list, this option is ignored and the client window is displayed.
-nc Do not auto-connect to an application server. (Default)
-d Displays the menu bar and the internal borders. (Default)
-nd Does not display the menu bar or the internal borders. For example, this allows a 1280x1024 WinDD window to fully display on a 1280x1024 monitor (minus windows manager decorations).
-e Enables the Application Server edit field window so that users can add application servers to the application server list. (Default)
-ne Disables the Application Server edit field window so that users are not allowed to add application servers to the application server list.
-floppy
Allows supported host versions of WinDD to use its local floppy drive as a network connected drive for the Application Server. Only the first host client to specify this option is allowed to use the floppy device.For host clients (with local floppy drive) only.
-no_floppy_cache
Disables use of local floppy write cache. This is a fail-safe option to ensure the entire file has been updated in the event a user suddenly ejects a disk mechanically (when disks are ejected via the GUI button, that process flushes the cache so no information is lost).-geometry <geometry>
Standard X11 geometry option, <WidthxHeight+X+Y>.-h <application server>
Adds the named application server(s) to the application server list. Multiple application servers can be added to the list by listing them separated by spaces.-help
Displays a brief help list on the available WinDD command line options.-initprog <prog> [-initdir <dir>]
Specifies the application to execute upon application server login. The login session is terminated when the application is terminated.Prog specifies the application and can also specify its path (up to 259 characters) and parameters. The program path and name are written consecutively (and not separated by a space) when they are both specified in prog. A space separates the program name and its parameters. These parameters are program specific and can specify program settings or data files to invoke on execution.
Dir specifies the path of the executable program.-keysym_only
Specifies that all NCD network computer keyboards are supported with keysym translations within WinDD.-local_numlock
Specifies that WinDD manages the state of the Num_Lock independent of any Xserver support.-no_auto_numlock
Specifies that WinDD does not control the Num_Lock setting.-login <username> [pass <passwd>] [-domain <domainname>]
Specifies the application server user account login name, login password, and domain. These values will be used for user account verification.When using a WinDD client and connecting to a WinDD application server, your username, password, domain, initial program, and initial directory are encrypted as they are sent across the network.
Username, password, domainname, dir, and prog are not viewable or changeable from the WinDD configuration window.
-r Reconnect to the application server after log off.
-nr Does not reconnect to the application server after log off. (Default)
-version
Displays the WinDD version in use. (If the license is 8019, this option also prints For evaluation purposes only.)-x Exits the WinDD client upon logging out of, or disconnecting from, the application server.
-nx Does not exit the WinDD client upon logging out of, or disconnecting from, the application server. (Default)
-force_xcursor
Specifies that monochrome pointers within the WinDD desktop are to be implemented using X cursors. Some monochrome pointers are xor'd with the underlying desktop. When this switch is specified, it is no longer xor'd, as X cursors do not support that mode.Starting Xlock
xpsh -display display_name:0 xlock -mode <mode>
where <mode> is an optional setting. If set to 1, Xlock locks the keyboard only. If set to 0, Xlock locks the keyboard and the screen. If a mode setting is not given, Xlock locks the keyboard and the screen by default.
A password is required to use the Xlock client. The same password is used throughout the entire session. If while using Xlock you forget the password, you must reboot the network computer or reset the server (in Setup) to clear the password and unlock the keyboard and screen.
Starting local XP Window Manager
- xpsh -display display_name:0 xpwm
Starting Local Clients In The XP.CNF File
Using the start and/or preload commands in the remote configuration file (XP.CNF), you can determine which local clients are downloaded and/or started at boot time. The specified clients are loaded into the network computer's memory and remain there until started. Even after closing the client, it remains in RAM so that it can be restarted again. For information about starting local clients from the remote configuration file, refer to the start and preload commands in Chapter 2, Remote Configuration, in the NCBridge Reference Manual.
Starting Local Clients with rsh
rsh is a host program used to download local clients to a network computer. rsh sends information to the network computer specifying which local clients to download, however, unlike xpsh, rsh does not receive local client error messages and exit information from the network computer.
Security for rsh is set through the .rhosts file. If user security is not set in the .rhosts file, then users will be able to access all local clients. The rshd_security command in the remote configuration file (xp.cnf) is used to determine whether users can override the security features set by the system administrator.
Enabling rsh
Before starting local clients with rsh, you must first enable it. To do this, use the start command with the parameter RSDH in the remote configuration file (xp.cnf):
Editing the .rhosts File
The .rhosts file is used to authenticate user requests to execute local clients. Entries are either positive or negative, depending on the permissions you want to give users. Positive entries enable user to access the specified local clients; negative entries deny access. The entries should include the hostname, username and client name. The order of entries within the files is important. If the file contains both positive and negative entries, the entry that appears first takes precedence.
Examples
For example, the entry below allows user judyl access to the Setup and Client Launcher clients while logged into the host Sierra:
- sierra judyl +setup +launcher
If you do not list specific clients, then all clients are available to the specified user:
- sierra judyl
A negative entry means that the client is not available to the user, but all other clients are. For example, user judyl cannot access the Digital Video Player or the Audio Player, but can access any of the other available clients:
- sierra judyl -vplay -aplay
You can also use the positive and negative specification for hostname and usernames. In the following example, user paulb can access all clients from any remote host:
- + paulb
In the next example, any user from any host can access the Setup and Launcher clients:
- + + +setup +launcher
In the final example, user davidb is not allowed access to the Setup and Xlock clients from any host:
- + -davidb +setup +xlock
For details about the .rhosts file, refer to the rhosts man page for your host.
Starting Local Clients with rsh
rsh uses the same local client options as xpsh. When using rsh to start clients, you do not enter the -display environment variable, and you must use the network computer name instead of an address. For example, to start Setup with rsh:
- rsh display_name setup
For details about starting local clients using rsh, refer to the Starting Local Clients with xpsh section earlier in this manual and substitute rsh for xpsh and omit the -display environment variable and the :0 in all examples.
Note: rsh can start all the local clients that xpsh can start, except for the Remote Setup client. Client Launcher
The local Client Launcher allows users to start local clients by simply selecting a client from a menu using the mouse. Figure 5-1 shows a sample Client Launcher menu. The Client Launcher can be configured automatically using default options, or with a customized configuration file. It can be downloaded to the network computer using the remote configuration file (XP.CNF) or using xpsh.
Configuring the Client Launcher
There are two ways to configure the Client Launcher: default automatic configuration, or with a specific configuration file. When the Client Launcher is started, if a user-defined configuration file is not specified, it first searches for a SYSTEM.LAUNCHER configuration file. If that file is not found, it configures automatically.
Automatic Configuration
If there is no configuration file present, the Client Launcher will automatically configure and include the following clients by default: Telnet, HostMenu, Lock Screen, Console, Audio Player, Audio Mixer, Digital Video, and Setup. Serial Port 0 and/or 1 are included if the network computer has serial ports. If Motif Window Manager, TDEnet, LAT, Tek340, Tek3270, or Tek3287 are authorized, they are included as well.
Configuration Files
The configuration files are used to customize the Client Launcher to include only specific clients so that you can determine which clients are available to users. There are two different types of configuration files:
- The SYSTEM.LAUNCHER file configures multiple network computers so that the clients available on the Client Launcher are the same for all who use the file. This allows a system administrator to control which clients are available to users.
- A user-defined configuration file customizes the Client Launcher for individual users.
To create a configuration file:
Note: Refer to the sample configuration file as a guideline when creating a configuration file.
- Create a new file, naming it either SYSTEM.LAUNCHER for a system-wide configuration file, or whatever you like for a user-defined file, for example, LAUNCH.
- Move the new file to the site-specific directory referred to by TEK$XP200_CONFIG:, TEK$XP330_CONFIG:, TEK$XP350_CONFIG:, TEK$XP400_CONFIG:, TEK$NC200_CONFIG:, TEK$NC400_CONFIG:, TEK$NC900_CONFIG:.
- In the file, use your favorite text editor to enter the main Client Launcher menu name in uppercase letters.
- On subsequent lines, enter each of the clients and submenu names (if used) in double quotation marks to include on the Client Launcher followed by the f.exec or f.menu option:
f.menu specifies that a submenu is available with additional options. For example, if you use multiple sessions, you could have a submenu named Sessions Menu and include Serial 0, Telnet, and Cterm. You can use any name or description you like with the f.menu option, however it must end with the letters menu.
f.exec specifies a local client to start immediately upon selecting it. Enter the client name exactly as you would on the xpsh command line, usually with all lower case letters and with double quotation marks. For example, "telnet", "console", "setup", and "mwm".
The order in which you enter clients and submenus in the configuration file determines the order they appear on the Client Launcher.- On the last line of the main menu, enter ENDMENU in uppercase letters.
- Create the submenus, if used, by entering the submenu name in all uppercase letters. On subsequent lines, list the clients to include followed by f.exec option in the same manner described in Step 4.
- On the last line of each submenu, enter ENDMENU in uppercase letters.
In the following example, the Client Launcher menu contains the following entries: Sessions (displays another menu of available session clients), Console, HostMenu, MWM, and Setup.
- Example 5-1 Sample Client Launcher Configuration File
- # Configuration file for Client Launcher
- #
- MAINMENU
- "Sessions" f.menu SESSIONS
- "Console" f.exec "console"
- "HostConnections" f.exec "HostMenu"
- "MWM" f.exec "mwm"
- "Setup" f.exec "setup"
- "Exit" f.exec "quit"
- ENDMENU
- SESSIONS
- "Serial 0" f.exec "tip -e tip tty0"
- "Telnet 220" f.exec "xterm -e telnet"
- "Telnet 340" f.exec "tek340 -e telnet"
- ENDMENU
- HOSTMENU
- "Netscape Lite" f.exec "netscape_lite"
- ENDMENU
In the previous example, the f.exec option immediately starts a client or session, and the f.menu option specifies that a submenu is to appear. The word ENDMENU specifies the end of the menu options.
The main Client Launcher menu contains the MAINMENU entries of the configuration file. When Sessions is selected, the submenu listing available session clients displays.
Downloading the Client Launcher
The Client Launcher can be downloaded using the remote configuration file (XP.CNF) or with xpsh.
Downloading Using the XP.CNF File
The start command in the XP.CNF file can be set to automatically download and start the Client Launcher when the network computer boots. For information about the start command and available parameters, refer to Chapter 2, Remote Configuration in the NCBridge Reference Manual.
Downloading With xpsh
When downloading and starting the Client Launcher using xpsh, the following options can be set:
Examples
The following example downloads and starts the Client Launcher with automatic configuration:
- xpsh launcher -auto
The following example downloads and starts the Client Launcher, configuring its contents using a user-defined file named LAUNCH:
- xpsh launcher -file DIA1:[GUEST]LAUNCH
The following example downloads and starts the Client Launcher, configuring its contents using the SYSTEM.LAUNCHER file on the network computer rocky:
- xpsh -display rocky::0 launcher
The following example downloads and starts the Client Launcher with the automatic configuration using the start command located in the XP.CNF file:
- start launcher -auto
Starting the Client Launcher
Once the Client Launcher is downloaded, press the Setup key to display the Client Launcher main menu.
Note: To start the Client Launcher on a Unix keyboard, hold the AltGraph key (three keys to the right of the space bar) down and press the Help/Setup key (at the bottom left of the keyboard). When the Client Launcher is started, it searches for configuration information in the following order:
To open a client listed on the Client Launcher, simply position the mouse pointer on the client name and click the mouse button once. To open a submenu, position the mouse pointer on the menu name. The submenu displays to the right of the Client Launcher main menu (refer to Figure 5-1). Position the mouse pointer an item in the submenu and click the mouse button once.
Starting Local Motif Window Manager
Motif Window Manager (MWM) can be started from within DECwindows and used as the window manager. DECwindows must be running before starting MWM. The following instructions provide information about starting local MWM in ULTRIX DECwindows, DECwindows XUI, (a pre-Motif window manager), and in DECwindows Motif version 1.0.
In Ultrix DECwindows
- From the DECwindows Session Manager window, select the Customize
pull-down menu and select Applications Definitions.- In the Menu Item text area, enter the item name to use for MWM, for example, TekLocalMwm.
- In the Menu Command text area, enter the following command string to start the local MWM: /tekxp/bin/risc_ultrix/xpsh mwm.
- Select the Add button to add the item name into the Menu Items window.
- Select the OK button.
- Select the Customize pull-down menu and select Window.
- In the Window Manager option, select the Other push button. Make sure that no window manager specification appears to the right.
- Select the OK button.
- Select the Customize pull-down menu and then select AutoStart.
Note: The items listed in the window differ depending on the available Menu Items.
- In the left column of menu items, select the item name assigned to MWM in Step 2 (in this example, it is TekLocalMwm). The name is added to the right column listing the automatic startup items.
- Select the OK button.
- Select the Customize pull-down menu then select Save Current Settings.
- Quit the session.
- When DECwindows session restarts, the NC local MWM is invoked automatically.
In VMS DECwindows XUI (pre-Motif)
- From the DECwindows Session Manager window, select the Customize
pull-down menu and select Applications Definitions. The Customize Applications Definitions window displays.- In the Menu Item text area, enter the item name to use for MWM, for example, TekLocalMwm.
- In the Menu Command text area, enter the following command string to use the sample local MWM startup procedure: @tek$tools_root:[xp.bin.coms]local_mwm
Select the Add button to add the item name into the Menu Items window.
- Select the OK button to close the Customize Applications Definition window.
- Select the Customize pull-down menu and select Window.
- In the Window Manager option, select the Other push button. Make sure that no window manager specification appears to the right.
- Select the OK button.
- Select the Customize pull-down menu and then select AutoStart. The Customize Autostart window displays.
Note: The items listed in the window depending on the available Menu Items.
- In the left column of menu items, select the item name assigned to MWM in Step 2 (in this example, it is TekLocalMwm). The name is added to the right column listing the automatic startup items.
- Select the OK button.
- Select the Customize pull-down menu then select Save Current Settings.
- Quit the session.
- When your DECwindows session restarts, the NC local MWM is invoked automatically.
In VMS DECwindows Motif 1.0
- From the DECwindow's Session Manager window, select the Options
pull-down menu and select Menus. The Menus window displays.- In the Menu Item text area, enter the item name to use for MWM, for example, TekLocalMwm.
- In the DCL Command text area, enter the following command string to use the sample local MWM startup procedure: @tek$tools_root:[xp.bin.coms]local_mwm. An up arrow appears below the Item Names list box.
- In the left column of menu items, select the item name assigned to MWM in Step 2 (in this example, it is TekLocalMwm). The name is added to the right column listing the automatic startup items.
- Scroll the right window until the Window Manager item shows. Select it and remove it from the list of automatic startup items. This leaves TekLocalMWM as the window manager.
- Select the OK button to save your new settings.
- Select the Options pull-down menu then select Save Session Manager.
- Quit the session.
When your DECwindows session restarts, the NC local MWM is invoked automatically.Motif Window Manager File Access
Accessing MWM Configuration Files
When MWM is started from your host using the xpsh command, MWM looks for system-level and user-level customization files on your host. These files are accessed using NFS, TFTP, DAP, or SXP. The access method used is determined by the -access argument of the xpsh command. (Refer to the xpsh man page for information about the xpsh command arguments.) The name of each file accessed by MWM is printed in the Console window. Setting up and using NFS file access can reduce MWM startup time.
Note: You can also start local MWM using the remote configuration file or Setup. However, these methods do not allow MWM access to the system-level and user-level customization files on your host. Accessing the MWM Resource Description File
Local MWM searches for a resource description file in the following order:
- If none of the above resource description files is found, MWM defaults to a language-specific resource description file from the boot configuration directory which is specified by the rooted logical TEK$XP_BOOT_CONFIG_ROOT. The language is specified by the Language option in the remote configuration file (XP.CNF) or in Setup. To see the current language setting, enter Setup and look at the Language option.
Accessing the MWM Defaults Files
The local MWM is configured from its resource database. MWM builds its resource database from the following sources, listed in the order that MWM accesses them:
- MWM command line options.
- RESOURCE_MANAGER root window property, if it is set;
otherwise
decw$user_defaults:decw$Xdefaults.dat file
The RESOURCE_MANAGER property is typically set by DECW$SESSION. These values do not override the existing values in the database.- dec$user_defaults:decw$mwm.dat, if it exists;
and
decw$system_defaults:decw$mwm.dat
For a gray scale display, decw$mwm.dat resources are overridden in
decw$user_defaults:decw$mwm_gray.dat, if it exists;
and
decw$system_defaults:decw$mwm_gray.dat
For a monochrome display, decw$mwm.dat resources are overridden in
decw$user_defaults:decw$mwm_bw.dat, if it exists:
and
decw$system_defaults:decw$mwm_bw.dat
These values do not override the existing values in the database.If none of the above application specific app-defaults files are found, MWM defaults to a language-specific defaults file from the boot configuration directory which is specified by the rooted logical TEK$XP_BOOT_CONFIG_ROOT. The language is specified by the Language option in the remote configuration file (XP.CNF) or in Setup. To see the current language setting, enter Setup and look at the Language option.
Creating a Local MWM Resource Description File
You can copy the system.mwmrc file to your home directory and then modify the file to customize your Motif environment. Table 5-1 shows the functions you can add to the file.
Accessing Bitmap Files
The MWM iconImage and bitmapDirectory resources are used to specify paths to bitmap files. The default value for bitmapDirectory is decw$user_defaults.
Accessing the Motif Bindings File
MWM reads the decw$user_defaults:decw$motifbind.dat file, if it exists, to install a virtual key bindings property on the root window. Example motif bindings files are installed in the [TEK.XP.EXAMPLES.MWM] directory by default.
Specifying Virtual Key Bindings
MWM reads the $HOME/.motifbind file, if it exists, to install a virtual key bindings property on the root window. Example motif bindings files are installed in the /tekxp/examples/mwm directory by default.
Setting up Virtual Desktop Panning
The Virtual Desktop Panning feature is available with MWM 2.0. This section provides an example of how you can modify your .Xdefaults and .mwmrc files to activate virtual panning in MWM. The MWM functions f.pan, f.goto, and f.track_pan need to be bound either to keys or to mouse buttons.
Editing .mwmrc for Virtual Desktop Panning
Add the following to your .mwmrc file to use virtual panning. Make sure that the name of the button bindings match the name given for the resource value Mwm*buttonBindings in your .Xdefaults file.
- Buttons MyButtonBindings
{
<Btn2Down> root f.menu GotoMenu
Meta<Btn1Down> root f.track_pan
}- Keys MyKeyBindings
{- Meta<Key>Up window|root f.pan 0,-100
Meta<Key>Down window|root f.pan 0,100
Meta<Key>Left window|root f.pan -100,0
Meta<Key>Right window|root f.pan 100,0
}To set up a menu that lets you quickly switch to different locations on the virtual desktop, code it as follows. You can then restart your MWM application.
- Menu GotoMenu
{
Up-Left f.goto 1500,1100
Up f.goto 0,1100
Up-Right f.goto -1500,1100
Left f.goto 1500,0
Home f.goto 0,0
Right f.goto -1500,0
Down-Left f.goto 1500,-1100
Down f.goto 0,-1100
Down-Right f.goto -1500,-1100
}Editing .Xdefaults for Virtual Desktop Panning
Add the following to your .Xdefaults file to keep MWM from moving all your windows back to the visible part of the screen at startup:
- Mwm*positionOnScreen: False
Note that it is important to set the positionOnScreen resource to False because MWM automatically repositions all off-screen windows back to the display screen on restart.
To set up a menu to go to preset positions on the virtual canvas, add the following lines:
- Mwm*GotoMenu*numColumns: 3
Mwm*GotoMenu*packing: PACK_COLUMN
Mwm*GotoMenu*orientation: HORIZONTAL
Mwm*GotoMenu*alignment: ALIGNMENT_CENTERFor consistency with the .mwmrc file, add the following lines:
- Mwm*buttonBindings: MyButtonBindings
Mwm*keyBindings: MyKeyBindingsTo prevent the client and icon windows from moving, add the following lines:
- Mwm*XBiff*iconPinned: True
Mwm*XBiff*clientPinned: True
Mwm*iconPinned: TrueUnsupported DECwindows MWM Functions
Local MWM does not support the following functions that DECwindows MWM supports:
f.dec_help Starts the DECwindows help widget
f.dec_customize Performs customization functions.
Local MWM interprets these functions as f.nop (no operation) and if either is used in a menu, local MWM stipples the item to indicate that it cannot be selected.
If you must have the customizations that f.dec_customize provides, run the DECwindows MWM, use the customization menu items which appear in the Options menu, and save the results in your resource files. From then on, local MWM acquires the customizations when it reads the various resource files.
Troubleshooting MWM
This section contains some information on possible solutions to correct some common MWM problems:
- If MWM does not come up at all:
- If you customize a file which is read by local MWM but the changes are not reflected when you run MWM:
- Make sure the customized file has read permissions open to the world.
- If the file is being accessed using DAP, make sure you enter your hostname in the TDEnet host table.
- If the file is accessed using TFTP, make sure you are using the version of xpsh included with the software version 6.1 or greater. If you are using an earlier version of xpsh, enter your hostname in the Internet host table. For information about adding hosts to the Internet host table, refer to Chapter 4, Boot Monitor, in the NCBridge Reference Manual.
- If using a 101-key, 102-key, or UNIX keyboard with host-based MWM, you must use the xmodmap utility to assign a Select keysym. Host-based MWM requires a Select key and these keyboards do not have a Select keysym. You can assign the Select keysym to any key you wish. For example, to assign the shifted Delete key to Select:
xmodmap -e "keysym Delete = Delete Select"- If the keyboard does not behave correctly, such as the rubout key deleting from the right instead of from the left, refer to the KEYBOARD.FIXES file located in TEK$TOOLS_ROOT:[XP.HELP] for helpful information.
- If MWM prints a message "mwm: Invalid key specification on line 50 of configuration file" in the Console window:
- DEC-specific enhancements to DECwindows MWM are not supported in local MWM. For example, the following DECwindows MWM window manager functions are interpreted by local MWM as f.nop:
XP Window Manager
XP Window Manager (XPWM) is a local window manager available with the network computer. XPWM provides a basic window manager that uses a minimum amount of network computer memory.
Accessing the XPWM Defaults File
XPWM is configured from its resource database. This database is built from the following sources, listed in the order that XPWM accesses them (the last setting takes precedence over the first).
Starting the XP Window Manager
XPWM can be started with xpsh, from the remote configuration file (xp.cnf), or from the Client Launcher.
Starting XPWM With xpsh
Enter the following command in the user's session start up file. (If using the NCD-supplied X Display Manager (xdm), enter the command in the .xsession file in the user's home directory.)
- xpsh -display terminal address xpwm
Starting XPWM With the xp.cnf File
The start and preload commands in the xp.cnf file can be used to start XPWM. For details about these commands, refer to Chapter 2, Remote Configuration, in the NCBridge Reference Manual.
Starting XPWM With the Client Launcher
The Client Launcher can be customized to include those clients that you use most often. The XPWM is listed on the Client Launcher by default as part of the Window Manager's submenu. To start XPWM, move the mouse pointer to XPWM and click the mouse button. For information about the Client Launcher, refer to the Client Launcher section earlier in this chapter.
Using XPWM
You use XPWM much like any other window manager. The windows have many of the same elements as Motif Window Manager. Figure 5-8 shows a sample XPWM window and its elements.
You can move and resize windows using either the mouse alone, or the commands located on the XPWM menu. Table 5-2 shows the mouse interface.
To access the XPWM menu, position the mouse pointer outside of a window, and click. First select a command, and then move the mouse pointer to the window you want the command to affect. Table 5-3 shows the commands available on the XPWM menu.
Customizing XPWM
You can change the appearance of XPWM using the resource settings listed in Table 5-4. XPWM does not allow user-defined bindings or user-defined menus.
Authorization Key Manager
The Authorization Key Manager enables a system administrator to easily update the authorization keys of several network computers. Authorization keys are used to authorize special options used on the network computer, such as window managers, XIE, TDEnet, and the video player.
Instead of entering each network computer's authorization key one at a time, you can update and maintain them from a central file. The Manager reads the authkey.dat file, which contains the authorization keys for those network computers you want to update with new options. When the file is read, those network computers listed in the authkey.dat file are updated with a new key.
How the Authorization Key Manager Works
The Authorization Key Manager uses SNMP to query specific broadcast addresses and network computers listed in the authkey.dat file, or in the Authorization Key Manager client. Those terminals are then assigned a new authorization key, also listed in the authkey.dat file. Therefore, you must have and enable SNMP.
Setting Up SNMP
In the xp.cnf file, use the snmp_comm_list command to set the community list to public and to allow read and write permissions:
- snmp_comm_list "host" public RW
where "host" is the host that performs the GET and SET operations when querying the subnet, public is the community string, and RW indicates read and write permissions.
The authkey.dat File
The authkey.dat file is located in /tekxp/boot/config by default and is empty. Edit the file to contain the broadcast address to query, the network computers to update, and the new authorization keys. The following parameters are used in the authkey.dat file:
broadcast specify the broadcast address to query using SNMP.
terminal for each network computer you want to update with a new authorization key, enter its hardware address.
authorization key For each network computer, enter the authorization key. Each network computer must have a unique authorization key.
This example shows a sample authkey.dat file:
- broadcast 144.67.33.255
terminal 08:00:34:94:33:EJ JAB(4%>3+[=T;fjqc
terminal 08:46:22:69:47:32 AK)&AMB@.?JTOR&]\
terminal 08:42:90:00:31:69 Jk%3+=]klw\jvv<?!
terminal 08:47:35:69:21:21 Uu$^qvuIi#=/>1GLqStarting the Authorization Key Manager
You can update authorization keys automatically with the xp.cnf file (and the authkey.dat file), or you can open the Authorization Key Manager client. The client provides a user interface where you can enter and delete authorization key and network computer information before updating the authorization keys.
Updating the Authorization Key When Booting
To automatically update authorization keys when booting, edit the xp.cnf file to uncomment the update_authkey command. The network computer reads the authkey.dat file when booting and updates the network computer and authorization key information. (Be sure that SNMP is available and enabled.)
Starting the Authorization Key Manager Client With xpsh
Use xpsh to open the Authorization Key Manager client as shown in Figure 5-9. The client's interface allows you to add and delete information from the authkey.dat file, and to force the authkey.dat file to be read without having to reboot the network computer.
To start the client with xpsh, enter the following:
Using the Authorization Key Manager Client
The Authorization Key Manager client can be started only with xpsh. When it starts, the window shown in Figure 5-9 appears.
The Authorization Key Manager Window shows the ethernet addresses and authorization keys as listed in the authkey.dat file. Before updating authorization keys, you can add and delete information in this window. This information is read in addition to the entries in the authkey.dat file. The following topics are discussed:
Adding and Deleting Network Computer Information
The Authorization Key Manager window contains network computer information necessary for updating authorization keys. If you have information in the authkey.dat file, it displays in this window.
- To delete an entry, select the information to delete with the mouse and it prefills in the Ethernet Address and Authorization Key fields. Then select Delete Entry
- To add an entry, enter its ethernet address in the Ethernet Address field, and its new authorization key in the Authorization Key field and select Add Entry.
To apply your changes to the authkey.dat file, refer to Saving the Authkey File.
Editing the Broadcast List
The Authorization Key Manager searches the specified broadcast address for those network computers that match the ethernet addresses listed in the authkey.dat file. To view and or edit the broadcast list, select the Edit Broadcast List button. The window shown in Figure 5-10 appears.
This window lists the broadcast addresses that the Authorization Key Manager client searches when updating authorization keys. You can add and delete information in this window. Information in this window is read in addition to the entries in the authkey.dat file.
To apply your changes to the authkey.dat file, refer to Saving the Authkey File.
Updating Authorization Keys
When the correct information is in the Authorization Key Manager window, select the Update Authkey button. The authorization keys are updated for those network computers listed.
The update status for each network computer is displayed as either Successful or Unreachable. If the status is Unreachable, check that you entered the correct ethernet and authorization key information. Make sure also that you have SNMP enabled.
Saving the Authkey File
After making changes to the ethernet addresses, authorization key, or broadcast information, you can save those changes to the authkey.dat file. To save changes, select Save Authkey File. The window shown in Figure 5-11 appears.
Note: If you use TFTP as the access method, the file authkey.dat must already exist and have world write permissions.
- Enter the host name on which the authkey.dat file is located.
- Enter the path and file name to which the information is to be saved.
- Select the Save Authkey File button to save the information in the Authorization Key Manager client to the authkey.dat file.
- Select Return to Main Menu to exit the Save Authkey File window.
Touchscreen Calibration Client
The Trident touchscreen calibration client enables you to calibrate the touchscreen. Figure 5-12 shows the calibration client.
To invoke the calibration client, first map it to a keysym using the keysym_action_entry command. For example, to invoke the client with the F1 key, enter the following in the xp.cnf file:
- keysym_action_entry F1 TOUCH_CALIBRATE ALL
Touchscreen jitter can be controlled with the touchSc_Jitter command:
- touchSc_Jitter 4 # touch screen jitter control
In this example, the 4 indicates that a change of less than 5 pixels when touching the screen will not move the cursor. The jitter and SAW touchscreen pressure thresholds are controlled from the calibration client with the Jitter Control slider. The touch thresholds are controlled with the Up Threshold and Down Threshold sliders.
| |
|
|
|
