|
6. Working with UNIX or Linux Systems
An important benefit of DoubleVision Pro is the ability to remotely view and control UNIX and Linux workstations as well as Windows computers. This chapter describes special features and considerations that apply to running DoubleVision Pro on UNIX/Linux servers. It also covers use of the DoubleVision Pro TELNET program, which you can use to control the UNIX console from DoubleVision Pro on a Windows computer. Note: For complete information on using the UNIX/Linux version of DoubleVision Pro, see the DoubleVision Pro Reference Guide for UNIX/Linux. 6.1 Running DoubleVision Pro on UNIX/Linux Systems
The DoubleVision Pro UNIX version runs on a UNIX server and enables viewing and remote control of terminal sessions running on that server. To start DoubleVision Pro on the UNIX server: 1. Log in and be at a shell prompt (i.e., %, #, etc.) 2. Type the following after the shell prompt: dv
<Enter> The DoubleVision Pro screen is displayed. It consists of a Main Menu bar and the Terminal Information window, which displays information about the host terminals.
See Sections 6.2 through 6.8 for information on using key Main Menu commands. 6.2 About
Host and
Remote Users
In a UNIX
environment, the host user can be on any terminal on the system, including the
console, dialed in on a modem, or connected via a network. It does not matter.
The only requirement is that the host is connected via a tty device. Like the host
user, the remote user can be on any terminal on the system. Here again, the
only requirement is that the remote user is connected via a tty device. Since
UNIX treats terminals as tty devices, it makes viewing with DoubleVision Pro
possible from anywhere. DoubleVision Pro makes no constraints on what programs can be viewed by the remote user. Therefore, the host user can run any program he or she wishes. The only constraint is a hardware constraint¾specifically, the terminal type. If the terminal type of the remote user does not support similar capabilities of the host user, the remote terminal may not be able to reproduce the screen exactly. Fortunately, DoubleVision Pro performs terminal translation to address this problem. Note: See Section 6.5, Translating Between Terminal Types for information on how terminal translation works. The remote user may be attached to one or more terminals simultaneously. DoubleVision Pro allows the remote user to easily switch between attached terminals using a Terminal Switch Hot Key. This hot key is assigned to each terminal by the remote user. 6.3 Attaching to a Host Terminal
The phrase “attaching to a host terminal” does more than just describe the action performed by the remote user. It embodies an important concept of DoubleVision Pro that should be fully understood. Note: When a remote user is attached to a host user, the TrueScreen and Instant Replay features are automatically activated. Activity occurring on the host’s terminal begins accumulating in the buffer. The remote user does not actually see this activity until he instructs DoubleVision Pro to view the attached terminal. When the remote user selects the View option, he is both attaching (if not already pre-attached) and viewing the host’s terminal. 6.3.1 Preattaching TerminalsAttaching to the host user’s terminal before he logs in assures you that the TrueScreen and Instant Replay options are activated. Note: Only the root user can preattach to an AT LOGIN terminal, unless special permission has been granted to a remote user. There are three ways to preattach to a host user’s terminal before he or she logs in. · The first is to highlight the desired AT LOGIN terminal in the Terminal Information window and issue the Preattach command found under Terminal > Advanced > Preattach. Normally there are multiple terminals on the system that have not logged in. Make certain you are selecting the correct one. The best way is to find the terminal by its tty name (e.g., tty1a). · The second method is to attach when the user logs in by executing the preattach command from the host user’s .profile or .bash_profile file. ·
The third method is to use the /usr/lib/dv/installpre script
to automatically update all .profile, .login, .bash_profile, and/or
.bash_login scripts in user home directories to call preattach. 6.4 The TrueScreenä Feature
DoubleVision Pro’s TrueScreen tracking module tracks and displays all screen attributes upon viewing. This means the remote user’s screen will look exactly like the host’s screen from the first moment of viewing, complete with screen attributes such as bold, reverse screen printing, etc. TrueScreen is not hardware specific and works with any supported terminal type. The TrueScreen feature, along with
Instant Replay, is automatically turned on when a terminal is preattached, and
information starts to accumulate in a buffer as soon as the host user logs in.
If the remote user has not preattached to the host user, these features will be
activated from the point of attachment forward. 6.5 Translating Between Terminal Types
Terminal translation is the process DoubleVision Pro uses to interpret and translate the command language of the host terminal to the command language of the remote terminal. The command language is the series of special character sequences (usually prefixed by the ESC character) that invokes the various features of the terminal. For example, clearing the screen on a Wyse 60 terminal is done by issuing an “ESC +” command sequence to the terminal. The terminal is programmed to recognize this special sequence and, thus, clear the screen. If terminal translation were not done, the remote terminal would receive the commands in the language of the host terminal and would not understand what they meant. The result would be a very incoherent image displayed on the remote user’s screen. To handle this, DoubleVision Pro translates the commands of the host user’s terminal to the commands of the remote user’s terminal. 6.5.1 Translation Quality StatusThe Translation column of the Terminal Information window provides valuable information regarding the translation quality you can expect between the host and remote terminals. There are four levels of translation quality: GOOD, AVERAGE (AVG), POOR, and BAD. If the selected tty has GOOD listed in the Translation column, you can expect the remote screen to look just like the host screen. DoubleVision Pro will designate GOOD as the translation status under the following circumstances: 1. The host and remote terminals are the same type and no translation is needed. 2. The host and remote terminals are not the same type, but a DoubleVision Pro terminal database exists for both the host and remote terminals. A terminal database is a database supplied with DoubleVision Pro that describes in great detail the features of certain terminals. The idea behind the terminal database is to know as much as possible about a terminal, thus increasing the chances of a successful translation. The directory /usr/lib/dv/termdb contains a complete list of all supported terminals. If the terminal you are viewing is a terminal contained in this list, your chances of a successful translation increase dramatically. If AVG is displayed in the Translation column for the selected tty, you can expect the remote screen to look similar to the host, since a DoubleVision Pro terminal database exists for the host user, but not for the remote. POOR displayed in the Translation column indicates that you can expect the remote screen to only approximate the host screen, since no DoubleVision Pro terminal database exists for either, and both terminals are of different types. This forces DoubleVision Pro to rely only on terminfo data to perform translation. A designation of BAD indicates that you can expect very unpredictable results on the remote screen, since no DoubleVision Pro terminal database exists for either terminal and a terminfo database does not exist for the host terminal. 6.5.2 How Terminal Translation WorksThere are several conditions that
determine how well DoubleVision Pro is able to translate terminal commands. One of the main conditions of terminal translation has nothing to do with DoubleVision Pro or any other software. It has to do with the limitations of the hardware¾the terminals themselves. When the remote and host terminals are identical, the remote terminal is capable of performing every task that the host terminal performs. It is when the two terminals are not the same that limitations of the hardware become apparent. If the host terminal can perform operations that the remote terminal cannot, DoubleVision Pro will be unable to completely recreate the host screen on the remote user’s terminal. The more operations that cannot be performed by the remote terminal, the less realistic the screen image will be. This is the first condition: 1. The capabilities of the remote terminal determines how accurately the host terminal’s screen will be recreated on the remote terminal’s screen. A good example of this is the number of lines per terminal screen. If the host terminal supports 25 lines and the remote terminal only supports 24 lines, it is impossible to completely re-create the host terminal’s screen on the remote. One line of the host’s screen will be missing at the bottom of the remote’s screen. This highlights the second condition: 2. If a remote terminal supports all the
capabilities of the host terminal, it will always be able to accurately
recreate the host terminal's screen, as long as these capabilities are fully
defined in the DoubleVision Pro terminal database or terminfo. The second condition brings to light two points: The first basically says that if the remote terminal can do everything the host terminal can do, then terminal translation will be successful. The second point is that the capabilities of each terminal must be fully defined in the DoubleVision Pro terminal database or terminfo. The DoubleVision Pro Terminal Database
Older releases of DoubleVision relied on termcap and terminfo when performing terminal translation. The termcap and terminfo entries provided by the operating system manufacturer can be inaccurate and incomplete, possibly resulting in faulty terminal translations. To help reduce the chance of this occurring, DoubleVision Pro uses its own terminal definitions database. This database is extremely complete and accurate, greatly reducing the chances of faulty terminal translation. Most of the common terminals are included in the database. To see a list of the terminals included, list the files in the directory /usr/lib/dv/termdb. It is important to understand how DoubleVision Pro uses its own terminal database and the terminfo terminal definition files. The general rule is as follows: DoubleVision
Pro will automatically use its own terminal databases first. If its own
terminal databases are available, DoubleVision Pro will merge with terminfo
only if the default parameter is enabled (CHECK_TERMINFO=YES). If you are using
a terminal type that is not contained in DoubleVision Pro’s terminal database,
terminfo will be used. The Importance of the Terminal Databases
Since DoubleVision Pro “learns” how to translate terminal commands by reading the two terminal databases ¾ the DoubleVision Pro terminal database and terminfo files ¾ how well the terminal’s capabilities are defined in these files determine how successful the translation will be. For example, assume that the host terminal and remote terminal are different types, but both have the capability to clear to the end of the current line. Also assume that in the host terminal’s terminal database entry this function is defined, but it is not defined in the remote terminal’s terminal database entry. When the program running on the host issues the clear-to-end-of-line command, it will be performed on the host terminal. However, when DoubleVision Pro attempts to translate this command to the corresponding command of the remote terminal, it will not know how, since there is no entry defining the clear-to-end-of-line command in the remote’s terminal databases. DoubleVision Pro will be unable to translate it and will ignore the command. As a result, the remote screen will not match the host screen. The above example illustrates the third condition: 3. How well DoubleVision Pro is able to
translate terminal commands from the host
terminal to the remote terminal is completely dependent on how complete and accurate the DoubleVision
Pro terminal database and the terminfo definitions are for both terminals. If terminal translation is to be successful, you should first try to use a DoubleVision Pro terminal database, if one exists. If one does not exist for your terminal, you should examine the terminfo/terminfo definitions for both terminals to make certain they are complete. Note: Older terminals can cause problems for terminal translation. Many of these terminals either lack the functions of modern terminals or perform them in an incompatible manner. This will cause inaccuracies. 6.5.3 Changing Terminal TypesYou can manually change terminal types during a DoubleVision Pro session using the Terminal Translation command. To change the terminal type for a specific tty/terminal: 1. Highlight the desired host terminal/tty from the Terminal Information window listing. 2. Select Terminal > Terminal Translation > Host. This will open the Host Terminal Type window.
3. Type the correct terminal type and press [ENTER]. Note: If the terminal type specified for the host terminal is not found in the DoubleVision Pro terminal database or the terminfo file, no translator is loaded. This will result in scrambled screens and generally poor results. 6.5.4 Automatic Terminal Type RecognitionDoubleVision Pro must be told the terminal type of another terminal. This may be done three ways: 1. Before the user views a host, the host terminal type may be specified by the remote user. 2. The system administrator can update the terminal type database of DoubleVision Pro found under /usr/lib/dv/ttytype. 3. The system administrator can use DoubleVision Pro’s terminal type collector system which updates each user’s .profile or .bash_profile with a call to the program /bin/termtype. This ensures that DoubleVision Pro has the most up-to-date information every time the user logs into the system. To take advantage of DoubleVision Pro’s automatic terminal type update system, place the following call in each user’s .profile or .bash_profile: /bin/termtype. This call must be placed after the terminal type has been assigned in the user’s .profile or .bash_profile. For example: TERM=ansi export TERM /bin/termtype OR eval 'tset –m ansi:${TERM:=ansi} –m :\?${TERM:-ansi} –e –r –s –Q' /bin/termtype When DoubleVision Pro runs, it will query the contents of this database and assume that the terminal is defined there for each terminal in the database. The remote user may still override a host’s terminal type value by using the user interface command option Terminal > Terminal Translation > Host. The system administrator can use the program /usr/lib/dv/inst_termtype to automatically update all .profile, .login, .bash_profile and .bash_login scripts and place the proper call to /bin/termtype at the proper location, making a backup of the users’ .profile, .login, .bash_profile and/or .bash_login script. 6.6 DoubleVision Pro
Security
DoubleVision
Pro has very comprehensive security features designed to prevent its misuse in
a UNIX environment: · Strict rules determine who can attach to a user. · An audible beep notifies users that they are being viewed. · The activity log shows who viewed whom, when, and for how long. · Screen blanking allows remote users to temporarily blank out the host’s screen so that work may be done in private. · Passwords restrict access to DoubleVision Pro. 6.6.1 Determining Who Can AttachDoubleVision Pro approaches security the same way every UNIX system does: at the user level. In the UNIX environment, the access you are permitted depends solely on what type of user you are. If you are the root user, you are granted unlimited access to every aspect of the system. If you are not the root user, you are only allowed access where you have been granted permission. The same access rules apply for DoubleVision Pro. You are only allowed to attach to a user if you have been granted permission, and that permission must be granted in advance. The
Root User
The access permissions of the root user in DoubleVision Pro are exactly the same as in the normal UNIX environment. The root user has no security constraints. He or she can attach to any user at any time. The root user
can attach to a terminal either before or after it is logged in. The root user
can also attach to any terminal regardless of which user has logged in (i.e.
root, regular user, sysadm, etc.). The root user has no limit on his access. Privileged Users or Groups
Privileged users have all the privileges of a root user, except that they cannot view a root user. If a privileged user tries to view a root user, the following error message is displayed:
For the systems administrator, the ability to set up privileged users and groups is not only a convenience¾it also protects the root password, since the user does not have to login as the root. Note: If security levels have been set to Low or Off, any user can view any other user, including the root. For more information, see Section 6.6.2, Setting the Security Level. Access Control List
DoubleVision Pro supports a convenient, centralized means of dispensing security privileges throughout the system, called Access Control Lists (ACLs). These ACLs allow the system administrator the flexibility to override individual permission settings and grant specific privileges without having to modify the PrivUsers or PrivGroups databases, or having to set up individual .dvsc files. Access Control Lists may be listings of individual users, groups, or terminals. Used in conjunction with other security options, ACLs allow system administrators to: · Specify which users may view a given host user. · Define which terminals may run DoubleVision Pro. · Grant users permission to connect to a terminal while “at login.” · Define which terminals are available for preattachment. DoubleVision Pro's Access Control Lists, along with PrivUsers/PrivGroups databases and individual host .dvsc files, give system administrators the ability to customize DoubleVision Pro security to fit their unique needs. Rules
Determining Access
Based on the set level of security (High, Medium, Low, and Off), DoubleVision Pro performs a hierarchical series of security checks when a user tries to connect to any terminal or tries to record any given terminal. DoubleVision Pro checks access permissions as follows: 1. Is the requesting user the root user? If so, unlimited access with no restrictions is granted. 2. Is the requesting user found in the required Privileged User or Privileged Group database? If so, access is granted. 3. Is the requesting user/tty found in the required Access Control User or Group List? If so, access is granted. 4. Is the requesting user found in the host user’s .dvsc file? If so, access is granted. If the user does not fall into one of these categories, DoubleVision Pro denies the user’s request and a warning window is displayed. How to Grant Permission
To
allow a remote user to attach to a host user’s terminal, the remote user must be
granted permission in advance of attaching. This may be done through the Access
Control Lists, PrivUsers/Groups databases, or a .dvsc file. Using Access Control ListsTo use the Access Control List mechanism to grant user permissions, simply: 1. Enable the Access Control List feature in the DoubleVision Pro defaults file. 2. Enter the specific user(s)/tty(s) in the desired security option’s default file. Only the root or super user may grant permissions using Access Control Lists. For example, let’s assume that the system administrator (root) wants to grant users John, Tracy, and Brian permission to attach to an AT LOGIN terminal. The system administrator would need to first enable the Access Control List feature. Using vi, the enabled ACL feature defaults file would look like this:
Next, the system administrator would need to add John, Tracy, and Brian to the Access Control List for the defaults file “USERS_WHO_CAN_CONNECT_TO_LOGINS.” Using vi, the entry would look like this:
John, Tracy, and Brian can now attach to any AT LOGIN terminal. Note: DoubleVision Pro’s defaults file /usr/lib/dv/default provides further examples for using ACLs with permission variables. Using PrivUsers/Groups DatabasesThe PrivUsers and PrivGroups databases are maintained in DoubleVision Pro’s /usr/lib/dv directory and are accessible only to the root or super user. These databases are easily edited to grant access permission to specified users. Using a .dvsc FileThe .dvsc file, located in the home directory of the host user, contains the user names that are permitted to attach to the host user. Each user name should be on a separate line. If the first line of this file contains an asterisk (*) at the beginning of the line, all users are granted access. Any blank lines in this file are ignored. This file should only have read/write permissions set for the host user. Assume that a user named John wants to grant access to the users Donna and Brian. To do this, he would create a text file named .dvsc in his home directory (assume it is /u/john). Using vi, .dvsc would look like this:
Issuing the command: ls -l /u/john/.dvsc should show the following permissions:
Note: The host user should not include himself in the .dvsc file. He is always granted permission to himself. Also, the .dvsc file is ignored by the root user, since he can attach to anyone. 6.6.2
Setting the Security Level
DoubleVision Pro provides users with four different levels of security:
By default, security is set to HIGH and appears as follows (as viewed from vi):
The security level may be changed by
logging in as the root and editing the security default parameter located in
the file /usr/lib/dv/default. For example, turning security off would look like this:
The owner of this file is the root, and the permissions are read/write only for the owner. Note: If the /usr/lib/dv/default file does not exist, security is set to HIGH by default. 6.6.3 Trojan Horse ViolationsBecause DoubleVision Pro allows users to view and control remote terminals, there is the possibility that a remote user could exceed their normal permissions. DoubleVision Pro regards all of these conditions as “Trojan Horse” violations and prevents them by shutting down the remote viewing session. Example 1: Assume a host user named John granted permission to a remote user named Mike. Mike attached and was able to view all activity on John’s terminal. If John knows the root user password and becomes the root user while Mike is attached, Mike would be able to issue commands and run programs on John’s terminal as the root user! Example 2: A remote user is viewing a session and the host user logs off. Because the host user’s status has changed, DoubleVision Pro interprets this as a Trojan Horse error. DoubleVision Pro prevents these “Trojan Horse” violations occurring by using the following rules: 1. If a remote user is not the root user and is viewing a host user who becomes the root user, the remote user is immediately returned to the DoubleVision Pro menu and a security breach error is displayed. Any subsequent attempts to view the host user are denied as long as the host user remains the root user. If the host user should return to his normal user status, the remote user would be allowed to view him once again. 2. When a host user becomes the root user while a remote user is viewing, the remote user is not able to see the root user password being typed. 3. When a normal user becomes the root user, his user name does not change to root on the Terminal Information Window. 6.6.4 What the Remote User SeesAs previously discussed, when the remote user attaches and is viewing, his screen looks identical to the host user's screen. Further, he sees everything that is typed from the keyboard of the host user, with one exception: If the remote user is not the super user, he can never see any passwords (or any other non-echoed characters) being typed. If the remote user is the super user, he can enable a capability that will allow him to see passwords and other non-echoed characters. The characters are not echoed on the host user’s screen. Normally this capability is not enabled. 6.6.5 Audible Beep When Someone is WatchingDoubleVision Pro signals the host user when a remote user is viewing his screen. This is done by sounding an audible beep on the host terminal. This beep is sounded every 20 seconds by default. A normal user can change the beep to be sounded in 5- to 30-second intervals. The super user can set this interval to 0 or from 5 to 30 seconds. Note: If the beep interval is set to 0, the beep is never sounded. Thus, the host user does not know that the super user is attached and viewing. The beep is only heard while the remote user is attached and viewing. If the remote user is attached but not viewing, no beep is heard. The beep is heard only at the host terminal, not at the remote terminal. 6.6.6
View Log
DoubleVision Pro creates an activity log of each viewing session. The log tracks the remote user name, host terminal, whether the session was viewed or recorded, start date and time, and end date and time of the DoubleVision Pro session. Only the root user can access the activity log.
The View Log cannot be edited through DoubleVision Pro. This means a viewing entry cannot be selectively deleted from the activity log using DoubleVision Pro, even by the root user. 6.6.7 Screen BlankingThe Screen Blanking feature allows the remote user to blank the host user’s screen. This is useful when the remote user wants to perform functions that he does not want the host user to see. Upon exiting the Screen Blanking mode, the host user’s screen is restored. For more information, see Section 6.8, Screen Blanking Command. 6.6.8 DoubleVision Pro PasswordThe root user is allowed to install a
password to limit access to DoubleVision Pro. All users, including the root
user, must provide this password before running DoubleVision Pro. 6.7 Chat Command
The Chat command opens a Chat window between the remote user and host. This provides an opportunity to converse via the keyboard, in real time on the screen. Once the Chat window is opened, the host user is not able to interact with the running application until the Chat window is closed. 6.7.1 Opening a Chat WindowA Chat window can be opened either through the menu options or by using command keys. To open a Chat window using the menu options, do the following: 1. Select (highlight) the desired host in the Terminal Information window. 2. Select the Chat command (Terminal > Chat).
If the remote user is not already attached to the host, DoubleVision Pro will attach the host terminal before the Chat window is opened. A remote user actively viewing a host may also open a Chat window. by using command keys. While viewing the host terminal, press the Screen Switch Hot Key [CTRL]+[Z], then the Chat Window Hot Key [CTRL]+[C]. The Chat Window will open on both the host’s and remote user’s screen. 6.7.2 Conversing in a Chat WindowOnce the Chat window is open, the remote user may start typing a message to the host. As the remote user begins to type, DoubleVision Pro identifies the remote user by name and tty address. The host user’s response is also identified by the host’s name and tty.
DoubleVision Pro remembers who made the last keystroke. When a keystroke is detected from a different participant, DoubleVision Pro will identify the user by name and tty address. This way, control of the Chat window passes back and forth on a first-come/first-served basis. This allows for the spontaneity of a conventional conversation. Tip: Sometime chat can be confusing. The participants may find it helpful to follow the unwritten rule of typing “o.”, meaning ‘over,” when they have completed their comment. This signals the other party that they may now type without interrupting. When the remote user wishes to close the Chat window, typing “oo,” meaning “over and out,” will alert the host user that the Chat session has ended and the window will be closing. The Chat window has been set up in overtype mode, allowing the participants to simply type over his mistakes. Limited editing is also available as follows:
6.7.3 Closing a Chat WindowThere are two ways to close a Chat window: 1. To close the Chat window and remain viewing the host terminal, press the Screen Switch Hot Key [CTRL]+[Z], then the Chat Window Hot Key [CTRL]+[C]. The Chat window will close and t |
