______________________________________________ MUXserver Software Installation Guide (OSF/1) Order Number: AA-PYUCA-TE Update Information: This is a new manual __________________________________________________________ First Edition, October 1993 © Digital Equipment Corporation 1993. All Rights Reserved. DIGITAL Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Digital or an authorized sublicensor. This document was prepared using VAX DOCUMENT Version 2.1. ________________________________________________________________ Contents Preface.................................................. vii 1 Introduction 1.1 The MUXserver Network........................ 1-1 1.2 Software Installation Activities............. 1-2 1.2.1 Overview................................. 1-2 1.2.2 Coordination with Hardware Installation............................. 1-4 1.2.3 Load Host Requirements................... 1-4 1.2.3.1 MOP Load Host Requirements............. 1-5 1.2.3.2 BOOTP Load Host Requirements........... 1-6 1.2.4 Installing Distribution Software......... 1-7 1.2.5 Configuring the Load Host Database(s).... 1-8 1.2.5.1 Configuring the Load Host MOP Database............................... 1-8 1.2.5.2 Configuring the Load Host BOOTP Database............................... 1-10 1.2.6 Verifying Installation................... 1-11 1.2.6.1 Verifying the Load Host Installation... 1-11 1.2.6.2 Verifying the MUXserver System Installation........................... 1-11 2 Installing Distribution Software 2.1 Preparing to Run the Installation Procedure.................................... 2-1 2.2 Installing the Software...................... 2-3 2.2.1 Installing the Software with the setld Command.................................. 2-4 iii 2.2.2 Installing the Software with the tar Command.................................. 2-10 2.2.2.1 Installing the Software with the tar Command from CDROM..................... 2-11 2.2.2.2 Installing the Software with the tar Command from Tape...................... 2-13 2.3 Verifying Installed Software................. 2-14 2.4 Installing onto Alternate Load Hosts......... 2-15 2.4.1 Installing onto Alternate OSF/1 Systems.................................. 2-16 2.4.2 Installing onto Other Operating Systems.................................. 2-16 3 Configuring the Load Host MOP Database 3.1 Configuration Procedure Prerequisites........ 3-1 3.2 Introduction to MOP Configuration............ 3-2 3.3 dsvconfig Conventions and Requirements....... 3-4 3.4 Running dsvconfig............................ 3-5 3.4.1 List Known DECservers and MUXservers (Option 1)............................... 3-7 3.4.2 Add a DECserver or MUXserver (Option 2)....................................... 3-8 3.4.3 Swap an Existing DECserver or MUXserver (Option 3)............................... 3-10 3.4.4 Delete an Existing DECserver or MUXserver (Option 4)............................... 3-11 3.4.5 Restore Existing DECserver or MUXserver (Option 5)............................... 3-12 3.4.6 Restoring from a Command Procedure....... 3-12 3.5 Down-line Loading the Server Image........... 3-13 4 Configuring the Load Host BOOTP Database 4.1 Configuration Procedure Prerequisites........ 4-1 4.2 Checking the BOOTP Server.................... 4-2 4.2.1 Configuring the BOOTP Server............. 4-3 4.3 Configuring the Load Host.................... 4-5 4.3.1 Configuring the Image Load Capability.... 4-6 4.3.2 Configuring the Image Dump Capability.... 4-7 4.4 Configuring the MUXserver.................... 4-9 iv 5 Verifying the Installation 5.1 Verifying the Load Host Installation......... 5-2 5.1.1 Loading a New MUXserver.................. 5-3 5.1.2 Network Access to a MUXserver............ 5-5 5.1.2.1 ccr Access to a MUXserver.............. 5-6 5.1.2.2 LAT Access to a MUXserver.............. 5-6 5.1.2.3 Telnet Access to a MUXserver........... 5-7 5.1.2.4 SNMP Access to a MUXserver............. 5-8 5.1.3 Loading an Existing MUXserver............ 5-8 5.2 Verifying the MUXserver Network Installation................................. 5-10 5.2.1 Establishing an Interactive Connection... 5-11 5.2.2 Verifying Server Operation............... 5-12 5.3 Verifying the Load Host Dump Capabilities.... 5-15 A MUXserver Software Distribution Files B Using the Remote Console Carrier C Installation, Configuration & Verification Examples C.1 Introduction................................. C-1 C.2 Installation Example......................... C-1 C.3 dsvconfig Configuration Examples............. C-3 C.3.1 The dsvconfig Menu....................... C-4 C.3.2 Listing Known DECservers/MUXservers...... C-5 C.3.3 Adding a DECserver or MUXserver.......... C-5 C.3.4 Swapping a DECserver/MUXserver for a New Unit..................................... C-6 C.3.5 Deleting a DECserver/MUXserver from the Database................................. C-7 C.3.6 Restoring Existing Servers to the Database................................. C-8 C.3.7 Exiting the dsvconfig Procedure.......... C-8 C.4 Verification Examples........................ C-8 C.4.1 Using ccr and Warning Server Users....... C-9 C.4.2 Checking Server Names.................... C-9 C.4.3 Down-line Loading with the load Command.................................. C-9 C.4.4 Verifying the Server System Installation............................. C-10 v Glossary Index Figures 1-1 Flowchart of Software Installation Activities............................... 1-3 1-2 Load Host Database Configuration......... 1-9 Tables 1-1 Internet Boot Protocol Suite............. 1-6 2-1 Software Installation Disk Space Requirements............................. 2-2 A-1 MUXserver Distribution Kit Files......... A-1 vi ________________________________________________________________ Preface Purpose of the Guide This document describes: o Installing MUXserver distribution software onto an OSF/1 system running MOP Phase V or the Internet Boot Protocol (BOOTP) suites. o Configuring the system databases so the system can act as a MOP Phase V or BOOTP load host. o Configuring the MUXserver so that it will request the load host for its server image via either MOP Phase V or BOOTP protocol suite. o Verifying the installation by: * Down-line loading the server image to the MUXserver, * Testing several representative server commands, and * Configuring parameters for the MUXserver to let it interact with Internet nodes on the network. o Configuring the Network database to enable management of the MUXserver via the Internet Simple Network Management Protocol (SNMP) suite. This guide is applicable to Version 2.0 of the MUXserver and all subsequent maintenance releases up to the next major product release. This Guide is intended for a system or network manager who is responsible for making server products available on the Ethernet. A system manager is responsible for the OSF/1 system that is about to be established as a load host. A vii network manager is responsible for the Local Area Network (LAN). Readers should be familiar with both MOP Phase V network management concepts and the OSF/1 Operating System. The Guide is organized as follows: Chapter 1 Briefly introduces the MUXserver Network and summarizes the installation, configuration and verification procedures. Chapter 2 Describes preparation for installation and the actual installation of distribution software. Chapter 3 Describes configuration of the load host MOP database to support the MUXserver product. Chapter 4 Describes configuration of the load host BOOTP database to support the MUXserver product. Chapter 5 Describes verification of the MUXserver software installation by: o Down-line loading the server image, o Configuring the Internet parameters on the MUXserver to enable its inclusion in an operational Internet network, o Testing several representative commands via the MUXserver console port, and o Forcing the MUXserver to dump its memory image. Appendix ALists the files provided in the MUXserver Distribution Kit. Appendix BDescribes remote system operation using the Remote Console Carrier (ccr) under OSF/1. Appendix CContains an example of: o Installation and configuration, and o Verification by down-line loading the server image. viii Glossary Defines abbreviations and special terms used in this Guide. Index Provides a page reference to important topics discussed in this Guide. Other MUXserver Publications The following is a list of related MUXserver publications: o MUXserver Network Reference Manual AA-PESEB-TE Describes procedures for setting-up, managing, monitoring, and trouble-shooting the MUXserver network. o MUXserver 90 Hardware Installation Manual EK-DSRZF-IM Describes installation and maintenance of the MUXserver 90 hardware. o MUXserver 320 Hardware Installation Manual EK-DSRZE-IM Describes installation and maintenance of the MUXserver 320 hardware. o MUXserver 380 Hardware Installation Manual EK-DSRZD-IM Describes installation and maintenance of the MUXserver 380 hardware. o MUXserver Network Identification Card EK-DSRZD-IC A means of recording individual MUXserver information. o MUXserver Software Product Description AE-PESGB-TE Describes the MUXserver's software and its operation. o MUXserver System Support Addendum AE-PESHB-TE An addendum to the MUXserver Software Product Description which describes the various systems supported by the MUXserver 90, 320 and 380. Other Relevant Publications Reference to the following Digital publications may be required during installation of the MUXserver software: o On-line Manual Pages (Sections 1 - 8) o DECnet/OSI Network Management ix Conventions Throughout this Guide, the following conventions apply. Numbers o All numbers are in decimal unless otherwise noted. o All Ethernet addresses are in hexadecimal. Graphics Normal Normal type indicates an example of system output. Bold Bold type indicates an example of user input. Italics Indicates a variable, a file, application or subset name, or a document title. < key > Indicates a specific key to be pressed. < CTRL/x Indicates that the < CTRL > key should be held down while the key specified by x is also pressed. [ ] In a command line, indicates that the enclosed values are optional. Do not type the brackets. { } In a command line, indicates that one (and only one) of the enclosed values must be specified. Do not type the braces. / Indicates related alternative commands or options. For example, SET/DEFINE PORT refers to the SET PORT and DEFINE PORT commands. x 1 ________________________________________________________________ Introduction 1.1 The MUXserver Network The MUXserver Remote Terminal Server Network connects remote terminals (or other asynchronous port devices) to a Local Area Network (LAN). The network consists of one or more DECmux 300 Remote Terminal Multiplexer units and one MUXserver 90, 320, or 380 unit. The MUXserver is connected to a LAN, and each DECmux connects the remote asynchronous devices to the MUXserver via one or more synchronous links. The MUXserver 90, MUXserver 320 and MUXserver 380 are separate products which support different numbers of remote asynchronous devices as detailed below. MUXserver 90 A MUXserver 90 Network supports up to 96 remote asynchronous devices as follows: o One synchronous link on the MUXserver may be connected, via modem, to DECmux 300s. o Up to three DECmux 300s may be connected, in a daisy-chain fashion, to the MUXserver 90 synchronous link. o Depending on its particular model and configuration, each DECmux 300 may connect 8, 16, 24 or 32 asynchronous devices. However, the maximum number of active devices supportable at any one time is 96. MUXserver 320 Introduction 1-1 Introduction 1.1 The MUXserver Network A MUXserver 320 Network supports up to 32 remote asynchronous devices as follows: o Up to two synchronous links may be connected, via modems, to DECmux 300s. o Up to three DECmux 300s may be be connected, in a daisy-chain fashion, to each MUXserver 320 synchronous link. o Depending on its particular model and configuration, each DECmux 300 may connect 8, 16, 24 or 32 asynchronous devices. However, the maximum number of active devices which can be supported by a MUXserver 320 Network at any one time is 32. MUXserver 380 A MUXserver 380 Network supports up to 128 remote asynchronous devices as follows: o Up to eight synchronous links may be connected, via modems, to the DECmux 300s. o Up to three DECmux 300s may then be connected in a daisy-chain fashion, to each MUXserver 380 synchronous link. However, each MUXserver 380 Network is limited to sixteen DECmux 300s. o Depending on its particular model and configuration, each DECmux 300 may connect 8, 16, 24 or 32 asynchronous devices. A MUXserver 380 Network is limited to 128 active asynchronous devices at any one time. The network connects each remote asynchronous device to the LAN, providing it with access to LAT services and INTERNET hosts. 1.2 Software Installation Activities 1.2.1 Overview MUXserver software includes the files in the MUXserver Distribution Kit listed in Appendix A. Software installation involves: 1. Installing the MUXserver distribution software, 1-2 Introduction Introduction 1.2 Software Installation Activities 2. Configuring the load host database(s), 3. Verifying the load host installation by down-line loading the MUXserver software image, 4. Verifying the server system installation by testing a selection of MUXserver commands, and 5. Configuring the Internet parameters on the MUXserver system. Figure 1-1 is a flow chart of the software installation process. The steps in the flow chart serve as an overview of the processes involved in installing the distribution software and configuring the load host database. Figure 1-1 Flowchart of Software Installation Activities Software installation establishes an OSF/1 system as a load host for one or more MUXserver Networks. A load host is a system that contains the server image and whose database has entries for specific servers, so that it can down-line load the server image to servers on the LAN. A load host also performs maintenance activities such as receiving up-line dumps from a server. To act as a load host, an OSF/1 system must have a network connection to one or more MUXservers, and either: o A MOP Phase V server installed and available within its operational characteristics, or o An Internet Boot Protocol (BOOTP ) server installed and available within its operational characteristics. Digital Equipment Corporation suggests that: o At least two load hosts be assigned for each MUXserver (or other server), and Introduction 1-3 Introduction 1.2 Software Installation Activities o At least one load host be assigned for every ten servers-although the preferred ratio of host to servers may vary considerably with faster systems. Providing alternate load hosts reduces the dependence of a MUXserver Network on one particular load host. If the primary load host is unavailable, another system can down-line load the server and receive up-line dumps from it. The MUXserver should have these load-host functions continuously available. Assigning more than one load host for each group of servers reduces the demand on the resources of any single load host. Any Digital system that has a MUXserver Distribution Kit available can be used as an alternate load host. MUXserver Software Distribution Kits are available for the following systems: o OSF/1 (installation is described in this guide), o ULTRIX (refer to the MUXserver Software Installation Guide (ULTRIX)), and o OpenVMS (refer to the MUXserver Software Installation Guide (OpenVMS)). 1.2.2 Coordination with Hardware Installation MUXserver software installation should be coordinated with the installation of the local and remote hardware. Chapter 3 and Chapter 4 describe the coordination required between hardware and software installation when the OSF/1 system acts as a MOP load host and a BOOTP load host, respectively. 1.2.3 Load Host Requirements The ability of the OSF/1 system to act as a load host for a MUXserver Network depends upon the protocol suite which is to be used to transfer the server software image across the LAN. The choices available to the system manager of the OSF/1 system are Digital's Maintenance Operation Protocol (MOP) and the Internet Boot Protocol (BOOTP) protocols. 1-4 Introduction Introduction 1.2 Software Installation Activities When an OSF/1 system uses MOP as the load mechanism, it is acting as a MOP load host; when it uses BOOTP as the load mechanism, it is acting as a BOOTP load host. In order for the OSF/1 system to act as a load host, it needs the following common subsets to be installed, configured and running: o The base system (OSFBASEnnn for DEC OSF/1 AXP), and o The Reference Pages for System Administrators and Users (OSFMANOSnnn for DEC OSF/1 AXP). The additional requirements for the OSF/1 system to act as a MOP load host are given in Section 1.2.3.1; the additional requirements for it to act as a BOOTP load host are given in Section 1.2.3.2. For information on down-line loading a MUXserver, refer to the MUXserver Network Reference Manual. 1.2.3.1 MOP Load Host Requirements For an OSF/1 system to act as a MOP load host to a MUXserver, it must have MOP installed and configured into the operational system. Without this capability, the OSF/1 system will not be able to utilise the software installed by this procedure. To automatically down-line load a MUXserver, and to receive up-line dumps from a MUXserver, the OSF/1 system needs the following subsets to be installed, configured and running: o The DECnet/OSI Reference Pages (DNAMANnnn for DEC OSF/1 AXP), o The DECnet/OSI MOP Utilities (DNAMOPnnn for DEC OSF/1 AXP), o The DECnet/OSI Base Components (DNABASEnnn for DEC OSF/1 AXP), and o The DECnet/OSI Datalink Components (DNADLInnn for DEC OSF/1 AXP). Introduction 1-5 Introduction 1.2 Software Installation Activities The mop_mom command sets up the OSF/1 system for performing down-line load and up-line dump requests. This is achieved by: 1. Creating the enabling the MOP protocol, and 2. Creating and enabling the appropriate MOP circuits. Normally, /usr/sbin/mop_mom is included in the /sbin/rc3.d directory as a background task. For more information on the mop_mom command, refer to the DECnet/OSI Network Management document. 1.2.3.2 BOOTP Load Host Requirements For an OSF/1 system to act as a BOOTP load host for a MUXserver, it must have BOOTP installed and configured into the operational system. The BOOTP protocol suite includes the specific protocols given in Table 1-1. ________________________Note ________________________ If the system proposed as a load host does not have the BOOTP utility installed, refer to the system supplier to acquire it. If you don't have this utility, you will still be able to install the MUXserver software, but you will not be able to use it. _____________________________________________________ Table_1-1_Internet_Boot_Protocol_Suite____________________ Mnemonic____Description___________Reference(s)____________ BOOTP Boot Protocol RFC906, RFC951, RFC1395 TFTP Trivial File RFC906, RFC1350 Transfer Protocol UDP User Datagram RFC768 Protocol IP__________Internet_Protocol_____RFC791,_RFC1340_________ To automatically down-line load a MUXserver, and to receive up-line dumps from a MUXserver, the OSF/1 system needs the following subset to be installed, configured and running: 1-6 Introduction Introduction 1.2 Software Installation Activities o The Additional Networking Services (OSFINETnnn for DEC OSF/1 AXP). The command that starts Internet is managed by the /etc/rc.config script command file. 1.2.4 Installing Distribution Software MUXserver distribution software is installed onto an OSF/1 system by using the setld command which loads the MUXserver subsets. When run, the setld command: o Creates the appropriate directories, o Populates these directories with the subset files, o Emphasises the need to review the MUXserver release notes before configuring the load host database, and o Maintains a database of the subsets which have been installed onto the OSF/1 system. Installation of the distribution software is described in Chapter 2. For those OSF/1 systems which do not have the setld command, Chapter 2 provides a method of manually unpacking the software installation kit using the tar command. This method may also be useful for any system whose implementation of the setld command is incompatible with the Digital subset format. The difference between the two methods of installing the software is that the setld command is an automated process which, unlike tar, maintains a register of all product subsets installed on your system. setld provides a simple mechanism for the removal of a subset from the OSF/1 system and an automated mechanism for verifying the installation procedure-features which are also beyond the scope of tar. Introduction 1-7 Introduction 1.2 Software Installation Activities 1.2.5 Configuring the Load Host Database(s) When distribution software has been installed onto an OSF/1 system, any database used to down-line load a MUXserver needs to be configured to support the new MUXserver Network. There are two methods by which the OSF/1 system can be configured to act as a load host for a MUXserver Network. Both methods must identify the specific database which needs to be configured. o If MOP is to be used as the mechanism for transferring the software image to the MUXserver, the MOP database needs to be configured. o If BOOTP/TFTP is to be used as the mechanism for transferring the software image to the MUXserver, the BOOTP database needs to be configured. When configuration is completed, the OSF/1 system will have been established as a load host for each server that has an entry in the appropriate database (see Figure 1-2). 1.2.5.1 Configuring the Load Host MOP Database The MOP Phase V database is configured using a config- uration shell script dsvconfig. This script is included in the MUXserver Software Distribution Kit. It is not involved in the installation procedure, but is executed separately. ________________________Note ________________________ Installing a DECserver 100, DECserver 200, MUXserver 100 or MUXserver 300 kit will cause the dsvconfig file to be overwritten by a file which does not support a MUXserver 90, a MUXserver 320 or a MUXserver 380 Network. _____________________________________________________ The load host MOP database is made up of two individual databases. Configuring it involves establishing (or amending) an entry for each MUXserver in: o The dsvconfig.dat data file. 1-8 Introduction Introduction 1.2 Software Installation Activities The dsvconfig.dat file is the DECserver/MUXserver net- work configuration database. This file is automatically created, and maintained, by the dsvconfig utility. o The node operational (volatile) database. Figure 1-2 Load Host Database Configuration When dsvconfig is used to configure a new server, it automatically adds an entry in the three places mentioned above. The entry identifies the following characteristics of each DECserver or MUXserver: o Server type, o Server node name, o Service circuit-ID, o Ethernet address, o Load file (server software image), and o Dump file. Configuration may also involve modifying or deleting entries for existing DECservers or MUXservers. With dsvconfig the load host database can be configured to: o Add a new unit, o Swap an old unit with a new one, o Remove a unit, or o Restore the previous configuration from the local database. Introduction 1-9 Introduction 1.2 Software Installation Activities Besides allowing you to configure a new server in the load host MOP database, dsvconfig allows you to list all servers currently defined in the dsvconfig.dat file. It can also restore to the load host node database all server configurations defined in dsvconfig.dat. Refer to Chapter 3 for instructions on configuring the load host MOP database to support DECservers/MUXservers. 1.2.5.2 Configuring the Load Host BOOTP Database For the OSF/1 system to be used as a BOOTP load host for a MUXserver Network, the Internet characteristics of each MUXserver must be present in: o An Address Resolution Protocol (ARP) server which is available on the network, and o The BOOTP database on the OSF/1 system which will act as the load host. When the distribution software has been installed onto an OSF/1 system, the BOOTP database needs to be configured to support the new MUXserver Network. The database used by the BOOTP daemon is invariably located in the file /etc/bootptab. You can configure this database by simply amending it with a text editor. Changes to it have common effect across all OSF/1 systems. For detailed information the reader should refer to the on-line manual pages for the BOOTP daemon supplied on the OSF/1 system with the command: # man [-] bootpd < Return > If the OSF/1 system has not been used as a BOOTP load host in the past, the /etc/bootptab file may not exist. In any such case, the configuration of the BOOTP database involves the creation of this file and the inclusion of the BOOTP base definitions for a MUXserver. These definitions are located by the software installation procedure into the file /usr/opt/MUXserver/MUXserver.bootptab. An entry in the /etc/bootptab file identifies the following characteristics of one client serviced by the BOOTP load host: o Internet node name, 1-10 Introduction Introduction 1.2 Software Installation Activities o Hardware Type (must be 1 for a MUXserver), o Hardware Ethernet address, o Internet protocol address, and o The default boot filename (not used for a MUXserver). The extensive variety of ARP server types available on OSF/1 systems makes it impractical to detail in this document the ways in which MUXserver characteristics can be installed on each ARP server. It is sufficient to say that the ARP server should contain the same Internet node name and Internet protocol address as configured in the BOOTP database. Refer to Chapter 4 for instructions on configuring the BOOTP load host database to support MUXservers. 1.2.6 Verifying Installation 1.2.6.1 Verifying the Load Host Installation Verifying a load host installation involves down-line loading the server image to a MUXserver. Verifying a load host installation ensures that the host: o Has the appropriate files in the correct directories, o Has a correct entry in its load host database for the MUXserver, and o Can successfully down-line load the MUXserver software image. 1.2.6.2 Verifying the MUXserver System Installation Verifying a complete MUXserver system installation involves the establishment of communications with the MUXserver and the testing of some MUXserver commands. This ensures that: o The correct version of the software is in the MUXserver, o The MUXserver hardware operates with the new software, and o The new software is running correctly. Introduction 1-11 Introduction 1.2 Software Installation Activities This procedure also permits you to configure the MUXserver to the Network Manager's requirements, and to define the Internet characteristics which are required for the MUXserver to interact with other Internet nodes on the network. These Internet characteristics are: o The Internet Address, o The Subnet Mask, o The Internet Domain Name Server (DNS) database, o The Internet Host database, o The system contact and location characteristics, and o The Simple Network Management Protocol (SNMP) agent and community characteristics. ________________________Note ________________________ The Internet Address and Subnet Mask parameters are mandatory, in that they enable the Internet protocol suite within the MUXserver to interact with other Internet nodes on the network. Once these parameters are defined in the MUXserver, all other parameters can be manipulated by Telnet access across the network. _____________________________________________________ Verification procedures are described in Chapter 5. 1-12 Introduction 2 ________________________________________________________________ Installing Distribution Software This chapter describes the installation of the MUXserver distribution software onto an OSF/1 system which is to act as a load host for a MUXserver Network. The recommended method for the installation of the MUXserver distribution software is by use of the setld command. setld is an automated procedure that: o Creates relevant directories on the appropriate disk partition if they do not already exist, o Establishes the files on the distribution media in appropriate directories, and o Maintains a database of subsets installed on the OSF/1 system. The tar command is a procedure which can duplicate almost all the actions of the setld command, but which does not include a facility to maintain your installed subsets. Installation will take about five minutes. 2.1 Preparing to Run the Installation Procedure Before running the installation procedure: 1. Decide which systems are to be load hosts for the MUXserver Network. You must install the distribution software onto all load hosts. 2. Check that each load host has sufficient disk space to contain the files to be installed by this procedure. Table 2-1 identifies the required disk space requirements for each subset that can be installed. Installing Distribution Software 2-1 Installing Distribution Software 2.1 Preparing to Run the Installation Procedure If you are installing multiple MUXserver subsets, adding the disk space requirements for each subset to be installed will identify the total disk space requirements for the installation. Note that the installation of any MUXserver subset will require the installation of the MS8UNIX subset with its mandatory disk space requirements. Table_2-1_Software_Installation_Disk_Space_Requirements___ Disk Space Installing..Subset______Directory__________Required_++____ Any MS8UNIX + /usr/opt/MUXserver 280 kilobytes MUXserver (mandatory) Overhead /usr/lib/dnet 42 kilobytes (mandatory) Overhead /usr/man/man8 2 kilobytes (mandatory) Overhead /usr/tftpboot 0 kilobytes (mandatory) Overhead MUXserver MS8MUX90 /usr/lib/dnet Overhead (see 90 above) plus 3,200 kilobytes MUXserver MS8MUX320 /usr/lib/dnet Overhead plus 320 1,750 kilobytes MUXserver MS8MUX380 /usr/lib/dnet Overhead plus 380 2,830 kilobytes +The_total_disk_space_requirements_for_the_MS8UNIX_subset_ is 324 kilobytes. ++If all subsets are to be installed, 8,100 kilobytes of disk space will be required. __________________________________________________________ The installation of any subset has a temporary disk space requirement of 50 kilobytes in the root (/) partition. This disk space will be returned at the 2-2 Installing Distribution Software Installing Distribution Software 2.1 Preparing to Run the Installation Procedure completion of the installation process and is not dependent upon the choice of subsets to be installed. Appendix A lists the files included in the MUXserver distribution software. To determine how much disk space is available on the partition which contains the /usr/lib/dnet, /usr/man/man8, /usr/opt/MUXserver and /tftpboot directories, use the following commands: # df /usr/opt # df /usr/lib # df /usr/man # df / If the disk partition of the OSF/1 system does not have sufficient disk space for the storage of a subset, the software installation can still proceed if a symbolic link is made between that partition and another partition which does have sufficient disk space. The following example illustrates the steps involved in creating a symbolic link between the directory /tftpboot and the /usr/tftpboot directory, where /usr is not mounted as part of the root partition. # mkdir /usr/tftpboot < Return > # ln -s /usr/tftpboot /tftpboot < Return > 3. Back-up the System disk. 2.2 Installing the Software The recommended method for the installation of the MUXserver distribution software is use of the setld command, which is detailed in Section 2.2.1. If the OSF/1 system which is to act as a load host for a MUXserver Network: o Does not contain the setld command, or o Involves an implementation of the setld command which is incompatible with the Digital subset format you should use the procedure given in Section 2.2.2 to install the MUXserver software using the tar command. Installing Distribution Software 2-3 Installing Distribution Software 2.2 Installing the Software 2.2.1 Installing the Software with the setld Command To install the MUXserver software: 1. Log in to the system as superuser. 2. Change directory to the file system root by entering: # cd / < Return > 3. Find out if you have a previous version of the MUXserver software already installed on the OSF/1 system. If so, these subsets must be removed before the new MUXserver software can be installed. # setld -i [ | grep MS8 ] < Return > If the system responds to the above command with the following display, the MUXserver version 1.1 software has already been installed on the OSF/1 system. MS8MUX320110 installed MUXserver 320 V1.1 for OSF/1 MS8MUX380110 installed MUXserver 380 V1.1 for OSF/1 MS8MUX90110 installed MUXserver 90 V1.1 for OSF/1 MS8UNIX110 installed MUXserver Support V1.1 for OSF/1 2-4 Installing Distribution Software Installing Distribution Software 2.2 Installing the Software ________________________Note ________________________ The last three digits of the subset name identify the revision level of the software contained within that subset. For the version 1.1 kit the revision level will be 110. For the version 2.0 kit the revision level will be 200, etc. Ensure that the revision levels for all subsets of the MUXserver products installed on the OSF/1 system, are the same. _____________________________________________________ When removing a subset, use the setld command, but make sure that the MS8MS8UNIXnnn subset is the last one to be removed. # setld -d MS8MUX380110 < Return > Deleting "MUXserver 380 V1.1 for OSF/1" (MS8MUX380110). MUXserver 380 V1.1 Software (MS8MUX380110) deleted successfully # setld -d MS8MUX320110 < Return > Deleting "MUXserver 320 V1.1 for OSF/1" (MS8MUX320110). MUXserver 320 V1.1 Software (MS8MUX320110) deleted successfully # setld -d MS8MUX90110 < Return > Deleting "MUXserver 90 V1.1 for OSF/1" (MS8MUX90110). MUXserver 90 V1.1 Software (MS8MUX90110) deleted successfully # setld -d MS8UNIX110 < Return > Deleting "MUXserver Support V1.1 for OSF/1" (MS8UNIX110). MUXserver Support V1.1 Software (MS8UNIX110) deleted successfully 4. Place the distribution media on the appropriate device drive, and execute the setld command. a. If the software is on a CDROM Optical Disc, the Compact Disc device must first be mounted onto the file system. Enter: # /usr/sbin/mount -rd /dev/rznc /mnt < Return > where rznc identifies the Compact Disc device (n is the unit number). Installing Distribution Software 2-5 Installing Distribution Software 2.2 Installing the Software Once the CDROM is mounted on the file system, enter the command: # setld -l /mnt/MS38nnn/bin < Return > where MS38nnn is the MUXserver Software Installation directory specification obtained from the Consolidated Software Distribution Master Index. This is supplied with the CDROM Distribution kit. The nnn suffix is the kit version number. b. If the software is on either a magnetic tape (9- track 1600 bpi) or a TK50 cartridge, enter the command: # setld -l /dev/rmtnh < Return > where rmtnh identifies the tape device (n is the unit number). The procedure prompts you, as software installer, to check whether the tape is mounted and on-line. When this has been verified, press < y > at the following prompt: Please make sure your installation tape is mounted and on-line. Are you ready (y/n)? y < Return > The procedure informs you that the tape is being positioned and the procedure continues when the tape is positioned correctly: Positioning tape 5. The procedure prompts you to select the subsets to be installed. With the installation of the MUXserver software, the MUXserver Support for OSF/1 is a mandatory installation, in that it must be selected as a subset to be installed, if not already installed. The MUXserver 90, MUXserver 320 and MUXserver 380 software subsets are optional installations. The exam- ple given below installs all these MUXserver software subsets from a version 2.0 software installation kit. 2-6 Installing Distribution Software Installing Distribution Software 2.2 Installing the Software The subsets listed below are optional: There may be more optional subsets than can be presented on a single screen. If this is the case, you can choose subsets screen by screen or all at once on the last screen. All of the choices you make will be collected for your confirmation before any subsets are installed. 1) MUXserver 320 V2.0 for OSF/1 2) MUXserver 380 V2.0 for OSF/1 3) MUXserver 90 V2.0 for OSF/1 4) MUXserver Support V2.0 for OSF/1 Or you may choose from the following options: 5) ALL of the above 6) CANCEL selections and redisplay menus 7) EXIT without installing any subsets Enter your choices or press RETURN to redisplay menus. Choices (for example, 1 2 4-6): 5 < Return > 6. The procedure then displays the name of the subsets that are to be installed, and asks for confirmation: You are installing the following optional subsets:) MUXserver 320 V2.0 for OSF/1 MUXserver 380 V2.0 for OSF/1 MUXserver 90 V2.0 for OSF/1 MUXserver Support V2.0 for OSF/1 Is this correct? (y/n): y < Return > 7. Before continuing, the procedure will ensure that sufficient disk space is available for the selected subsets. Checking file system space required to install selected subsets: File system space checked OK. 8. The procedure displays the Digital copyright notice for the software to be installed and an estimate of the time required to complete the procedure. (c) Copyright 1988-1993, Digital Equipment Corporation - All Rights Reserved The installation will take one to two minutes. Installing Distribution Software 2-7 Installing Distribution Software 2.2 Installing the Software 9. The procedure attempts to verify certain prerequisite conditions necessary for the correct utilisation of the software. If either the MOP, DECnet, Datalink Components, or Internet Network Services are not found in the setld subset database, the following warning messages are generated: MOP is not installed on this system. DECnet is not installed on this system. Datalink Components are not installed on this system. Internet Network Services are not installed on this system. In any case of this kind, one of the following further messages is generated to identify the possible load host database configuration, based on the subsets found to be installed: The installation will proceed based on the assumption that the system administrator intends to install and configure the system with either a BOOTP daemon or a DECnet/MOP loader. The installation will proceed based on the assumption that the system administrator has configured, or intends to configure, the system with a DECnet/MOP loader. The installation will proceed based on the assumption that the system administrator has configured, or intends to configure, the system with a BOOTP daemon. Finally, the software installer is given the oppor- tunity to end the installation if any of the stated assumptions are incorrect. Answering the prompt with < n > will stop the installation. If this is not the case, answer NO to the following question. Do you wish to continue with the installation? [Yes] < Return > 10. If you press on, the procedure will install and verify the files for the selected subsets. 2-8 Installing Distribution Software Installing Distribution Software 2.2 Installing the Software MUXserver Support V2.0 for OSF/1) Copying from /mnt/MS38nnn/bin (disk) Verifying MUXserver 90 V2.0 for OSF/1 Copying from /mnt/MS38nnn/bin (disk) Verifying MUXserver 320 V2.0 for OSF/1 Copying from /mnt/MS38nnn/bin (disk) Verifying MUXserver 380 V2.0 for OSF/1 Copying from /mnt/MS38nnn/bin (disk) Verifying 11. The procedure reports any action taken as part of configuring the installation files into the OSF/1 system. The configuration shell script, dsvconfig, supplied as part of the MUXserver Distribution Kit, provides for terminal servers other than the MUXserver. Use the shell script supplied on this kit for all configuration. However, when installing any terminal server other than the MUXserver, check the terminal server's release notes for information about supported versions of the dsvconfig shell script. a. If the dsvconfig script file supplied in the kit is a later version than the existing version, the procedure will ask whether the original version should be deleted. Previous version of dsvconfig has been superseded. Delete old version? y < Return > Previous version of dsvconfig has been removed. b. If the dsvconfig script file supplied in the kit is at the same revision as the existing version, the procedure will create a back-up copy of the existing script. Superseded version of dsvconfig exists; copied to /usr/lib/dnet/dsvconfig.savn Installing Distribution Software 2-9 Installing Distribution Software 2.2 Installing the Software c. If the dsvconfig script file supplied in the kit is an older version than the existing version, the procedure provides the following warning: The previously installed copy of dsvconfig contains the most recently released version of the DECserver configuration program. The file dsvconfig.savn contains the version of dsvconfig supplied with this kit. You may save it if you wish, but you should only run the program in /usr/lib/dnet/dsvconfig. 12. The procedure will verify the placement of the files within the selected subsets. MUXserver Support V2.0 Software (MS8UNIX200) installed successfully Review the release notes in /usr/lib/dnet before configuring the database Configuring MUXserver Support V2.0 for OSF/1 (MS8UNIX200) MUXserver 90 V2.0 Software (MS8MUX90200) installed successfully Configuring MUXserver 90 V2.0 for OSF/1 (MS8MUX90200) MUXserver 320 V2.0 Software (MS8MUX320200) installed successfully Configuring MUXserver 320 V2.0 for OSF/1 (MS8MUX320200) MUXserver 380 V2.0 Software (MS8MUX380200) installed successfully Configuring MUXserver 380 V2.0 for OSF/1 (MS8MUX380200) 13. Before you configure the load host database, as described in Chapter 3 or Chapter 4, you should read the release notes to check for any changes that affect this installation. These notes are in /usr/lib/dnet/ms8_relnotes.mem. 2.2.2 Installing the Software with the tar Command There are two distinct procedures when using the tar command to install the MUXserver software. The applicability of each procedure depends on the media on which the software is distributed. Use the procedure detailed in Section 2.2.2.1 when the MUXserver software is distributed on a CDROM, and the procedure detailed in Section 2.2.2.2 when the MUXserver software is distributed on magnetic tape. 2-10 Installing Distribution Software Installing Distribution Software 2.2 Installing the Software 2.2.2.1 Installing the Software with the tar Command from CDROM To install the MUXserver software: 1. Log in to the system as superuser. 2. Change directory to the file system root by entering: # cd / < Return > 3. Place the distribution media in a CDROM optical disc drive, and mount it onto the file system by entering: # /usr/sbin/mount -rd /dev/rznc /mnt < Return > where rznc identifies the Compact Disc device (n is the unit number). 4. Once the CDROM is mounted on the file system, enter the command: # ls /mnt/MS38nnn/bin < Return > where MS38nnn is the MUXserver Software Installation directory specification obtained from the Consolidated Software Distribution Master Index, which is supplied with the CDROM. The nnn suffix is the kit version number. For version 2.0 of the software, with the kit version number of 200, the command and resulting display looks like this: # ls /mnt/MS38200/bin < Return > INSTCTRL MS8MUX320200 MS8MUX90200 SPACE MS8.image MS8MUX380200 MS8UNIX200 instctrl 5. Install the MUXserver Support utilities by entering a command in the form: tar xvf /mnt/MS38nnn/bin/MS8UNIXnnn A command of this form draws a response like this: Installing Distribution Software 2-11 Installing Distribution Software 2.2 Installing the Software # tar xvf /mnt/MS38200/bin/MS8UNIX200 < Return > tar: blocksize = 128 x ./usr/opt/MUXserver/rfc1381.txt, 71252 bytes, 140 tape blocks x ./usr/opt/MUXserver/rfc1317.txt, 30443 bytes, 60 tape blocks x ./usr/opt/MUXserver/rfc1316.txt, 35144 bytes, 69 tape blocks x ./usr/opt/MUXserver/decmux_mib.txt, 3117 bytes, 7 tape blocks x ./usr/opt/MUXserver/MUXserver.bootptab, 118 bytes, 1 tape blocks x ./usr/man/man8/dsvconfig.8, 864 bytes, 2 tape blocks x ./usr/lib/dnet/ms8_relnotes.mem, 10841 bytes, 22 tape blocks x ./usr/lib/dnet/dsvconfig, 1947 bytes, 4 tape blocks x ./tftpboot/.DUMP, 1 bytes, 1 tape blocks x ./usr/opt/MUXserver/rfc1213.txt, 142159 bytes, 278 tape blocks x ./usr/lib/dnet/dsvconfig.sh5, 29342 bytes, 58 tape blocks 6. If the MUXserver 90 product installation is required, enter a command in the following format to install and configure the software (assuming V2.0 of the software): # tar xvf /mnt/MS38200/bin/MS8MUX90200 < Return > tar: blocksize = 128 x ./usr/lib/dnet/ms3901eng.sys, 2910208 bytes, 5684 tape blocks # ln -s /usr/lib/dnet/ms3901eng.sys /tftpboot/MS3901ENG < Return > 7. If the MUXserver 320 product installation is required, the file for the tar command to work on will have a filename in the form: MS8MUX320nnn, where nnn is the kit version number. Enter the following commands to install and configure the software for, say, version 2.0 of the MUXserver 320: # tar xvf /mnt/MS38200/bin/MS8MUX320200 < Return > tar: blocksize = 128 x ./usr/lib/dnet/ms3201eng.sys, 1747456 bytes, 3413 tape blocks # ln -s /usr/lib/dnet/ms3201eng.sys /tftpboot/MS3201ENG < Return > 8. If the MUXserver 380 product installation is required, with, say, version 2.0 (kit number 200), enter the following commands to install and configure the software: # tar vxf /mnt/MS38200/bin/MS8MUX380200 < Return > tar: blocksize = 128 x ./usr/lib/dnet/ms3801eng.sys, 2833920 bytes, 5535 tape blocks # ln -s /usr/lib/dnet/ms3801eng.sys /tftpboot/MS3801ENG < Return > 2-12 Installing Distribution Software Installing Distribution Software 2.2 Installing the Software 2.2.2.2 Installing the Software with the tar Command from Tape When installing the MUXserver software from magnetic tape using the setld command, the software installer has no choice as to which MUXserver product is to be installed. All MUXserver software products presented on the tape must be installed. To install the MUXserver software: 1. Log in to the system as superuser. 2. Change directory to the file system root by entering: # cd / < Return > 3. Place the distribution media in a tape drive, and mount it by entering: # mt -f /dev/rmtnh fsf 4 < Return > where rmtnh identifies the tape device (n is the unit number). 4. For example, if the unit number is 2, you install the MUXserver Support utilities by entering the command: # tar xvf /dev/rmt2h < Return > tar: blocksize = 128 x ./usr/opt/MUXserver/rfc1381.txt, 71252 bytes, 140 tape blocks x ./usr/opt/MUXserver/rfc1317.txt, 30443 bytes, 60 tape blocks x ./usr/opt/MUXserver/rfc1316.txt, 35144 bytes, 69 tape blocks x ./usr/opt/MUXserver/decmux_mib.txt, 3117 bytes, 7 tape blocks x ./usr/opt/MUXserver/MUXserver.bootptab, 118 bytes, 1 tape blocks x ./usr/man/man8/dsvconfig.8, 864 bytes, 2 tape blocks x ./usr/lib/dnet/ms8_relnotes.mem, 10841 bytes, 22 tape blocks x ./usr/lib/dnet/dsvconfig, 1947 bytes, 4 tape blocks x ./tftpboot/.DUMP, 1 bytes, 1 tape blocks x ./usr/opt/MUXserver/rfc1213.txt, 142159 bytes, 278 tape blocks x ./usr/lib/dnet/dsvconfig.sh5, 29342 bytes, 58 tape blocks 5. With the same unit number of 2, you can install the first MUXserver software product subset presented on the tape by entering the command: # tar xvf /dev/rmt2h < Return > tar: blocksize = 128 x ./usr/lib/dnet/ms3x01eng.sys, yyyyyyy bytes, zzzz tape blocks Installing Distribution Software 2-13 Installing Distribution Software 2.2 Installing the Software 6. Install the second MUXserver software product subset presented on the tape by entering a command in the form: # tar xvf /dev/rmtnh < Return > where once again, the n in rmtnh is the unit number. Thus: # tar xvf /dev/rmt2h < Return > tar: blocksize = 128 x ./usr/lib/dnet/ms3x01eng.sys, yyyyyyy bytes, zzzz tape blocks 7. Install the third MUXserver software product subset presented on the tape and the same unit (that is, unit 2) by entering the command: # tar xvf /dev/rmt2h < Return > tar: blocksize = 128 x ./usr/lib/dnet/ms3x01eng.sys, yyyyyyy bytes, zzzz tape blocks 8. Enter the following commands to configure the software: # ln -s /usr/lib/dnet/ms3201eng.sys /tftpboot/MS3201ENG < Return > # ln -s /usr/lib/dnet/ms3801eng.sys /tftpboot/MS3801ENG < Return > # ln -s /usr/lib/dnet/ms3901eng.sys /tftpboot/MS3901ENG < Return > 2.3 Verifying Installed Software The recommended method for verifying the installation of the MUXserver distribution software is by use of the setld command. To verify the MUXserver software installation with the setld command: 1. Log in to the system as superuser. 2. Change directory to the file system root by entering: # cd / < Return > 3. Find which version of the MUXserver software is installed on the OSF/1 system. # setld -i [ | grep MS8 ] < Return > 2-14 Installing Distribution Software Installing Distribution Software 2.3 Verifying Installed Software If the system responds to the above command with the following display, the MUXserver version 2.0 software has been installed on the OSF/1 system. MS8MUX320200 installed MUXserver 320 V2.0 for OSF/1 MS8MUX380200 installed MUXserver 380 V2.0 for OSF/1 MS8MUX90200 installed MUXserver 90 V2.0 for OSF/1 MS8UNIX200 installed MUXserver Support V2.0 for OSF/1 4. For each subset listed, enter the setld command with the verify option: # setld -v MS8UNIX200 < Return > MUXserver Support V2.0 for OSF/1 (MS8UNIX200) (c) Copyright 1988-1993, Digital Equipment Corporation - All Rights Reserved 0 verification errors encountered. 0 corrections performed. # setld -v MS8MUX90200 < Return > MUXserver 90 V2.0 for OSF/1 (MS8MUX90200) 0 verification errors encountered. 0 corrections performed. # setld -v MS8MUX380200 < Return > MUXserver 380 V2.0 for OSF/1 (MS8MUX380200) 0 verification errors encountered. 0 corrections performed. # setld -v MS8MUX320200 < Return > MUXserver 320 V2.0 for OSF/1 (MS8MUX320200) 0 verification errors encountered. 0 corrections performed. 2.4 Installing onto Alternate Load Hosts It is recommended that alternate load hosts are estab- lished for a MUXserver Network. To serve as an alternate load host, a system must also have the distribution software installed and it must have entries for one or more MUXservers in its load host database. Installing Distribution Software 2-15 Installing Distribution Software 2.4 Installing onto Alternate Load Hosts If the original load host is unavailable for down-line loading the server image, any alternate load host can load the server. Alternate load hosts can also receive up- line dumps from servers and can perform other maintenance functions. 2.4.1 Installing onto Alternate OSF/1 Systems To install the server distribution software on to an alternate OSF/1 load host, repeat the installation procedure detailed in Section 2.2 for each load host. 2.4.2 Installing onto Other Operating Systems To install the server distribution software on to another operating system, follow the instructions in the MUXserver Software Installation Guide for that system (refer to Section 1.2.1). 2-16 Installing Distribution Software 3 ________________________________________________________________ Configuring the Load Host MOP Database This chapter describes the procedures for configuring a load host MOP database to support a specific DECserver or MUXserver network. 3.1 Configuration Procedure Prerequisites Before starting the configuration procedure, obtain the MUXserver Network Identification Card for each MUXserver planned for inclusion in the MOP database. It is recommended that this card should be completed with each installation of MUXserver hardware, but if information on the card is not complete, you should update it as part of the software installation process. The information on the card should contain all the data required during the MOP configuration procedure. Ensure that the following information is recorded on the MUXserver Network Identification Card: o Type of MUXserver (that is, MUXserver 90/320/380), o Ethernet address of the MUXserver, o Serial Number of the MUXserver, o Location of the MUXserver, o A contact person, and o The date of hardware installation. Some further information will also be required to complete the MOP database configuration and the initial MUXserver Network configuration, but which may not necessarily have been entered on the card at the time of hardware installation. Configuring the Load Host MOP Database 3-1 Configuring the Load Host MOP Database 3.1 Configuration Procedure Prerequisites If it is not already recorded on the card, the following information should be obtained from the Network Manager to complete the required details, and to be used during the MOP configuration: o Server node name, o Internet address, o Server name, and o Server number. 3.2 Introduction to MOP Configuration The configuration procedure (dsvconfig) is an automated, menu-driven procedure which is used to define servers in the load host MOP database. dsvconfig allows entries for any server in the DECserver or MUXserver family to be defined, deleted, and modified. The installation procedure copies this procedure file to the /usr/lib/dnet directory. ________________________Note ________________________ dsvconfig, supplied with the software distribution kit, provides for various terminal servers, including DECservers as well as MUXservers. The help facility available during configuration and outlined in Section 3.4.2 below can give details of all classes of server supported by the current version of the software. _____________________________________________________ dsvconfig allows: o Listing servers that are currently defined in the load host MOP database. o Adding an entry for a new server in the load host MOP database. o Swapping an existing server for a new one or redefining an existing server identification in the load host MOP database. 3-2 Configuring the Load Host MOP Database Configuring the Load Host MOP Database 3.2 Introduction to MOP Configuration o Deleting an entry for an existing server from the load host MOP database. o Restoring existing servers to a load host MOP database. Configuring a load host MOP database involves adding, swapping and deleting entries in the dsvconfig.dat file. Restoring reconfigures the MOP load database. Configuring the Load Host MOP Database 3-3 Configuring the Load Host MOP Database 3.2 Introduction to MOP Configuration dsvconfig operates on two distinct databases: o The MOP database. This database is also the server database. It contains the information displayed when you selection Option 1, List, from the dsvconfig menu. o The (volatile) operational database. When dsvconfig is run, data is sometimes transferred from the load host MOP database to the node database. The dsvconfig procedure automatically keeps these databases synchronised. dsvconfig also prepares a node as a load host by enabling SERVICE on the service circuit. SERVICE must be enabled before a down-line load can occur. 3.3 dsvconfig Conventions and Requirements The configuration procedure dsvconfig is built on several conventions: 1. When dsvconfig is run, it displays a menu of options. Type the menu number and press < Return > to select and activate an option. 2. If you need assistance with a question, enter a question mark (?) and then press < Return > as a response. dsvconfig displays explanatory text about the question and then returns to the dsvconfig menu. 3. Several queries have default answers which appear immediately after the question, enclosed in square brackets ([ ]). To select a default value, press < Return > after the question. 4. To exit from an option without making changes and return to the dsvconfig menu, type < 6 >. dsvconfig automatically returns to its main menu. 5. To exit from the script within an option, without making changes, and return to the OSF/1 superuser prompt (#), press < Ctrl/C >. 6. To return from the menu level to the OSF/1 superuser prompt (#), press < 6 >. 3-4 Configuring the Load Host MOP Database Configuring the Load Host MOP Database 3.3 dsvconfig Conventions and Requirements 7. The dsvconfig menu returns automatically when any option other than the list option is completed. 8. If a fatal error occurs, a warning message is displayed and the the script is aborted, returning to the OSF/1 superuser prompt (#). The warning message may appear as: # ./dsvconfig: fatal error The DECserver node was NOT added to the file 3.4 Running dsvconfig 1. Log in as superuser. 2. Invoke the dsvconfig script: # /usr/lib/dnet/dsvconfig < Return > The dsvconfig script then displays: DECserver/MUXserver Configuration Procedure - Version 3.0 ------------------------------------------------------------------ Procedure started day date time ------------------------------------------------------------------ You must assign a unique node name for each DECserver/MUXserver you are going to configure. Please be sure to read/print your release notes. The release notes can be found in /usr/lib/dnet. Press to continue 3. Press < Return > to continue with the configuration. dsvconfig will display: DECserver/MUXserver Configuration Procedure - Version 3.0 Menu of Options 1 - List known DECservers/MUXservers 2 - Add a DECserver/MUXserver 3 - Swap an existing DECserver/MUXserver 4 - Delete an existing DECserver/MUXserver 5 - Restore existing DECservers/MUXservers 6 - Exit from this procedure Configuring the Load Host MOP Database 3-5 Configuring the Load Host MOP Database 3.4 Running dsvconfig Your selection ? 4. Enter the number corresponding to the required option and press < Return >. 3-6 Configuring the Load Host MOP Database Configuring the Load Host MOP Database 3.4 Running dsvconfig 3.4.1 List Known DECservers and MUXservers (Option 1) Select option 1 to list the servers in the load host MOP database. If there are any DECservers or MUXservers defined in the load host MOP database, the contents of file dsvconfig.dat are displayed in six columns. A typical listing appears as: Your selection ? 1 < Return > Node Svr Svc Ethernet Load Dump Id Type Ckt Addr Image File ============================================================================== clmon4 MS380 circuit-1 08-00-2B-15-6F-9A ms3801eng.sys ms8clmon4.dmp darlin MS320 circuit-1 08-00-2B-25-A6-CD ms3201eng.sys ms2darlin.dmp emulat MS300 circuit-1 08-00-2B-24-F5-06 ms3401eng.sys ms3emulat.dmp lintla MS90 circuit-1 08-00-2B-A1-18-2A ms3901eng.sys ms9lintla.dmp Total of 4 DECservers/MUXservers defined Press to continue 1. The Node Id uniquely identifies the server within the MOP database with up to six alphanumeric characters. This should correlate with the MOP node name on the appropriate Network Identification Card for that server. 2. The Svr Type identifies the product which is repre- sented by the server. 3. The Svc Ckt identifies the circuit which is used to service the load and dump requests originating from the server. 4. The Ethernet Addr is obtained from the hardware and should be recorded on the appropriate Network Identification Card for the server. 5. The Load Image is defined by the product type of the server (see Svr Type). If the server does not request a specific filename in the load request, the identified filename is used as a default. Configuring the Load Host MOP Database 3-7 Configuring the Load Host MOP Database 3.4 Running dsvconfig 6. The Dump File is created by a combination of the product type and the Node Id. If the server does not request a specific filename in the dump request, the identified filename is used as a default. When a server up-line dumps its memory, which it does upon unexpected failure or upon request by the network manager, the data is dumped into the server dump file. This file can then be used for diagnostics. If a fatal bug check generates an up-line dump, you should copy the dump file to magnetic tape and send it with a Software Performance Report (SPR) to Digital. The network manager may also ask you for a copy of the dump file. 3.4.2 Add a DECserver or MUXserver (Option 2) Select option 2 to add a server to the load host MOP database. The information from the Network Identification Card that is required when adding a server to the MOP database is: o The server type. o A unique node name for the server. o The Ethernet address of the server. o The service circuit identifier. To add a server to the MOP database, select option 2 and respond with the appropriate information when prompted: Your selection ? 2 < Return > At any time you may type a ? for help. Type < 6 > to return to menu. Type to accept the default DECserver/MUXserver type ? MS90 < Return > DECserver/MUXserver node name for unit ? server < Return > DECserver/MUXserver Ethernet address for this unit ? 08-00-2b-2d-8c-53 < Return > Service circuit for this unit [ circuit-2 ]? < Return > Please wait ... 3-8 Configuring the Load Host MOP Database Configuring the Load Host MOP Database 3.4 Running dsvconfig Help is available at each level by responding to the prompt with < ? >. Thus: 1. To obtain details of available DECserver types: DECserver type ? ? < Return > This query prompts the suggestion from the procedure that you should enter the code for the type of server you are adding (for example, "DS100" for a DECserver 100, "MS90" for a MUXserver 90, etc.). A list is provided of all server types currently supported, and their relevant codes. 2. To find the syntax for the DECserver node name: DECserver node name for unit ? ? < Return > The DECserver/MUXserver node name for your DECserver unit must be from 1 to 6 alphanumeric characters, the first being alphabetic. This name identifies the unit on the network. 3. To get the syntax for the Ethernet address of the unit: DECserver Ethernet address for this unit ? ? < Return > The Ethernet address is the address located on the DECserver/ MUXserver unit. It must be in the form of 6 Hex digits, separated with minus (-) characters. ( Example: 08-00-01-00-AB-CD ) This address is used to establish communication between your host and the DECserver/MUXserver unit, and must be entered in the exact format shown, and be correct for the unit you are adding. 4. To list available types of circuit-ID available on the system: Service circuit for this unit []? ? < Return > Specify the service circuit-ID associated with the appropriate network controller device. The system has the service circuit(s): circuit-2 circuit-1 ________________________Note ________________________ If you receive an error from MOP while you are Configuring the Load Host MOP Database 3-9 Configuring the Load Host MOP Database 3.4 Running dsvconfig adding a server, the entry is added to the dsvcon- fig.dat file (the load host MOP database), although it is not entered in the MOP load database. You should immediately: 1. Use Option 4 to delete the entry. 2. Fix the condition causing the MOP error, and 3. return to Option 2 to add the server again. If you specify a node address that is already defined in the server database (the load host MOP database), you get a dsvconfig error, nothing is added and the Add option is cancelled. _____________________________________________________ 3.4.3 Swap an Existing DECserver or MUXserver (Option 3) Select option 3 to swap a server in the load host MOP database. Swapping retains the MOP node address of the original unit. It is useful if an existing unit malfunctions and you need to replace it. It is also helpful for renaming servers. dsvconfig allows the following characteristics for the new unit to be specified: __________________________________________________________ Characteristic__Default___________________________________ DECserver The type of the old DECserver you are type replacing. Server node The name of the old DECserver you are name replacing. Ethernet There is no default. You must specify the address Ethernet address of the new unit. Server The service circuit. service circuit___________________________________________________ To swap a server in the MOP database, select option 3 and respond with the appropriate information when prompted: 3-10 Configuring the Load Host MOP Database Configuring the Load Host MOP Database 3.4 Running dsvconfig Your selection ? 3 < Return > At any time you may type a ? for help. Type < 6 > to return to menu. Type to accept the default Node name of DECserver/MUXserver you want to swap ? server < Return > DECserver/MUXserver at Ethernet address 08-00-2B-2D-8C-53 is being swapped. DECserver/MUXserver type [ MS90 ] ? ms320 < Return > DECserver/MUXserver node name for unit [ server ] ? < Return > DECserver/MUXserver Ethernet address for this unit ? 08-00-2B-2D-8C-35 < Return > Service circuit for this unit [] ? circuit-2 <> ( Return ) Please wait ... Help is available at each level by responding to the prompt with < ? >. Thus: 1. To get an explanation of the DECserver details required for a swap: Node name of DECserver you want to swap ? ? < Return > For the SWAP option, a DECserver/MUXserver unit is being replaced with a new one. Please enter the DECserver/MUXserver node name you have entered for the unit to replace. You will then be asked the Ethernet address for the new unit. 2. The options available for the DECserver type, DECserver node name, Ethernet address and Service circuit are the same as Section 3.4.2. 3.4.4 Delete an Existing DECserver or MUXserver (Option 4) Select option 4 to delete a server from the load host MOP database. Deleting is useful if you are reconfiguring the network or changing load hosts for a server. To delete a server from the MOP database, select option 4 and respond with the MOP node name of the DECserver to be removed when prompted: Configuring the Load Host MOP Database 3-11 Configuring the Load Host MOP Database 3.4 Running dsvconfig Your selection ? 4 < Return > At any time you may type a ? for help. Type < 6 > to return to menu. Node name of DECserver/MUXserver to be deleted ? node_name < Return > Node node_name deleted 3.4.5 Restore Existing DECserver or MUXserver (Option 5) If your MOP network contains many nodes, you may store your MOP database on a central, remote node and copy this database upon each system start-up. However, if many servers exist on the network, Digital advises that you do not define these servers in that central MOP database. Where servers are not defined in the central database, you must reconfigure them whenever you copy your local MOP database from this central MOP database. Each time you copy the central MOP database, use Option 5 to restore existing server configurations. The Restore option restores a load host MOP database to include the servers in its node database. To delete a server from the MOP database, select option 5: Your selection ? 5 < Return > Restoring existing DECservers/MUXservers from local database... Local database successfully restored. 3.4.6 Restoring from a Command Procedure Instead of using menu option 5, you can also restore a local MOP database using dsvconfig's r (restore) parameter. This by-passes the menu and allows a config- uration procedure to be included in the system start-up procedures. To use the r (restore) parameter, use the command: # /usr/lib/dnet/dsvconfig r < Return > 3-12 Configuring the Load Host MOP Database Configuring the Load Host MOP Database 3.4 Running dsvconfig To cause a local MOP database to be restored automatically during system start-up, edit the system start-up file to include the following statement: /usr/lib/dnet/dsvconfig r 3.5 Down-line Loading the Server Image When configuration has been completed, verify the Load Host Installation by down-line loading the new server image from the load host to the server using the procedure described in Chapter 5. Configuring the Load Host MOP Database 3-13 4 ________________________________________________________________ Configuring the Load Host BOOTP Database This chapter describes the procedures for configuring o the Internet Boot Protocol server on the load host, o the load host BOOTP database to support a MUXserver network, and o the MUXserver hardware to utilise the Internet Boot Protocol as the mechanism for loading its software image. 4.1 Configuration Procedure Prerequisites Before starting the configuration procedure, obtain the MUXserver Network Identification Card for each MUXserver planned for inclusion in the BOOTP database. The information on each card contains all the data required during the BOOTP configuration procedure. Ensure that the following information is recorded on the MUXserver Network Identification Card: o Type of MUXserver (that is, MUXserver 90/320/380), o Ethernet address of the MUXserver, o Serial Number of the MUXserver, o Location of the MUXserver, o A contact person, and o The date of hardware installation. Configuring the Load Host BOOTP Database 4-1 Configuring the Load Host BOOTP Database 4.1 Configuration Procedure Prerequisites The following information should be acquired from the Network Manager and recorded on the MUXserver Network Identification Card. This additional information will be required to complete the BOOTP database configuration and the initial MUXserver network configuration. o Internet address, o Server name, and o Server number. 4.2 Checking the BOOTP Server The application of the MUXserver software installed by this procedure is dependent on whether the Internet Boot Protocol (BOOTP) server is configured into the OSF/1 operational system. To verify that the BOOTP server is running, execute the netstat command. There should be an entry in the udp protocol for the bootp server and the tftp server. # netstat -a < Return > Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) . . . udp 0 0 *.bootps *.* . . . udp 0 0 *.tftp *.* . . . If no such entry can be found, it is likely that the BOOTP server has not been configured into the operational OSF/1 system. Section 4.3 contains the procedure necessary to configure the BOOTP server into the operational OSF/1 system. 4-2 Configuring the Load Host BOOTP Database Configuring the Load Host BOOTP Database 4.2 Checking the BOOTP Server 4.2.1 Configuring the BOOTP Server This section provides the generic instructions for configuring a BOOTP server into an operational OSF/1 system. ________________________Note ________________________ The installer should refer to the on-line documen- tation for the Internet Boot Protocol daemon on the OSF/1 system, before proceeding. # man [-] bootpd < Return > _____________________________________________________ 1. Ensure that both the Trivial File Transfer Protocol (TFTP) and the Internet Boot Protocol (BOOTP) servers are enabled in the configuration file /etc/inetd.conf. These protocols are enabled when the following [uncommented] lines appear in the nominated file: tftp dgram udp wait root /usr/sbin/tftpd tftpd /tftpboot bootps dgram udp wait root /usr/sbin/bootpd bootpd If these lines are not in the file, use a text editor to add them. If they are present but commented out, remove the comment prefix (#). ________________________Note ________________________ For security reasons, it is recommended that a restricted TFTP server is implemented. The explicit inclusion of the /tftpboot path in the above example restricts access by the TFTP server to files contained within this path. The installer should refer to the online documentation for the Trivial File Transfer Protocol daemon on the OSF/1 system. # man [-] tftpd < Return > _____________________________________________________ 2. Ensure that the BOOTP server listening port (bootps), the BOOTP client destination port (bootpc), and the TFTP server listening port (tftp) are configured into the configuration file /etc/services. Configuring the Load Host BOOTP Database 4-3 Configuring the Load Host BOOTP Database 4.2 Checking the BOOTP Server bootps 67/udp # BOOTP server listening port bootpc 68/udp # BOOTP client destination port tftp 69/udp # TFTP listening port Use a text editor to add these lines to the file, or to remove the comment prefix (#) from existing lines. 3. Ensure that the User Datagram Protocol (UDP) and the Internet Protocol (IP) is configured in the /etc/protocols file. ip 0 IP # internet protocol, pseudo protocol number udp 17 UDP # user datagram protocol Use a text editor to add these lines to the file, or to remove the comment prefix (#) from existing lines. 4-4 Configuring the Load Host BOOTP Database Configuring the Load Host BOOTP Database 4.2 Checking the BOOTP Server 4. Make sure the Internet Service daemon (inetd) has re- read its revised configuration file (inetd.conf) to give effect to the modifications listed above. Do this by either: a. Sending a hang-up signal to the Internet Service daemon: # ps -e [ | grep inetd ] < Return > PID TT STAT TIME COMMAND . . . pid ?? I 0:00.18 /usr/sbin/inetd . . . # kill -HUP pid < Return > or, b. Rebooting the OSF/1 system. # /usr/sbin/shutdown -r time [ message ] < Return > 4.3 Configuring the Load Host The software installed onto an OSF/1 system by following the procedure given in Chapter 2 allows that system to act as a load host for one or more MUXserver Networks. This section outlines the procedures required to configure the load host BOOTP database so that it will comply with the MUXserver load request, and will meet the requirements for an OSF/1 system to accept a MUXserver dump request. ________________________Note ________________________ The installer should refer to the on-line documen- tation for the Internet Boot Protocol daemon on the OSF/1 system, before proceeding. # man [-] bootpd < Return > _____________________________________________________ In order for the MUXserver client to complete the image load from the load host, an Address Resolution Protocol (ARP) server must be available which can translate the Internet address of the load host to its equivalent hardware Ethernet address. Configuring the Load Host BOOTP Database 4-5 Configuring the Load Host BOOTP Database 4.3 Configuring the Load Host 4.3.1 Configuring the Image Load Capability The database used to define the load host BOOTP capabili- ties is contained in the file /etc/bootptab. Generally, the structure of the /etc/bootptab file permits the use of a Table Continuation which contains the generic database definitions for a particular type of loadable client. The MUXserver Utilities subset supplies the file /tftpboot/MUXserver.bootptab which contains the generic database definitions for the MUXserver products. This file should be included into the /etc/bootptab database file to simplify the configuration task. The following information is required for each MUXserver client that is to be configured into the load host BOOTP database: o The Subnet Mask for the Internet sub-network. This parameter is usually common across all MUXserver Networks being served by the load host. As such, it is usually specified within the Table Continuation. It is obtained from the Network Manager. o The hardware Ethernet address of the MUXserver client. The Hardware Ethernet address of the MUXserver client should be obtained from the MUXserver Network Identification Card used during hardware installation. o A name for the MUXserver client. o An Internet address for the MUXserver client. The MUXserver client name and Internet address should be obtained from the Network Manager who is responsible for ensuring the unique assignment of these parameters within the Internet network. The booptab file is made up of a series of declarations: one for each loadable client. The syntax for the declaration of each MUXserver client is: client_name:ht=1:ha=hardware_address:ip=internet_address:tc=MUXserver: where client_name is a name of the MUXserver as defined by the Network Manager, 4-6 Configuring the Load Host BOOTP Database Configuring the Load Host BOOTP Database 4.3 Configuring the Load Host hardware_address is obtained from the MUXserver Network Identification Card, and internet_address is the unique Internet address obtained from the Network Manager. An example of a load host BOOTP database file is given below. This example illustrates o An Internet sub-network mask of 255.255.255.0; o A database entry for a MUXserver 90 whose name is mux90, Ethernet address is 08-00-2B-A1-2D-18, and Internet address is 16.153.64.9; o A database entry for a MUXserver 320 whose name is mux320, Ethernet address is 08-00-2B-25-CD-A6, and Internet address is 16.153.64.32; and o A database entry for a MUXserver 380 whose name is mux380, Ethernet address is 08-00-2B-24-06-F5, and Internet address is 16.153.64.38. # # Generic MUXserver BOOTP database definitions # MUXserver:hd=/tftpboot:bf=null:sm=255.255.255.0:hn:vm=auto:bs=auto # # Specific MUXserver BOOTP database definitions # mux90:ht=1:ha=08002BA12D18:ip=16.153.64.9:tc=MUXserver: mux320:ht=1:ha=08002B25CDA6:ip=16.153.64.32:tc=MUXserver: mux380:ht=1:ha=08002B2406F5:ip=16.153.64.38:tc=MUXserver: It would be advisable for the information about each BOOTP client to be replicated in the database for the Address Resolution Protocol (ARP) server. 4.3.2 Configuring the Image Dump Capability A feature of the MUXserver is that it can dump its memory image for analysis by Digital Equipment Corporation. The MUXserver will perform this dump under the following conditions: o When a privileged user enters the CRASH command. Configuring the Load Host BOOTP Database 4-7 Configuring the Load Host BOOTP Database 4.3 Configuring the Load Host o When a technician presses the DUMP button on the MUXserver. o When the software detects an unrecoverable system error. o When certain unrecoverable hardware faults occur. The dump operation by the MUXserver can be prevented by: o A privileged MUXserver user disabling the DUMP function, Local >CHANGE SERVER DUMP DISABLED < Return > or o The absence of a load host which will accept the dump image from the MUXserver. The default condition is that the load host will not accept the dump image from a MUXserver. The ability of the load host to accept a dump image must be configured for each MUXserver on the network. A load host will accept a dump image from a MUXserver when: 1. A base dump image file is created on the load host, thus: # cp /tftpboot/.DUMP dump_image_filename < Return > and 2. The permission mode for the dump image file provides global write access. # chmod a+w dump_image_filename < Return > The construction of the dump_image_filename is critical to the successful completion of the image dump process. The construction rules to be followed which will ensure correct operation are: o The file must reside on a directory path to which the Trivial File Transfer Protocol (TFTP) daemon has access (see Section 4.3). o The filename must be in UPPERCASE. o The syntax for the filename is 4-8 Configuring the Load Host BOOTP Database Configuring the Load Host BOOTP Database 4.3 Configuring the Load Host {MS90 } {MS320 } _hardware_address.DUMP {MS380 } { } The filename prefix defines the type of MUXserver to which the dump image refers. This translates to dump images for either the MUXserver 90 (MS90), the MUXserver 320 (MS320), or the MUXserver 380 (MS380). The hardware_address is the same value used in Section 4.3.1. ________________________Note ________________________ The ability of the MUXserver to dump its image via the BOOTP/TFTP protocol is dependent upon the firmware revision level (see Section 2.2.1). The minimum MUXserver firmware revision levels which support this function are: o Version V2.0-0 for the MUXserver 90, o Version V1.0-2 for the MUXserver 320, and o Version V1.1-6 for the MUXserver 380. _____________________________________________________ 4.4 Configuring the MUXserver The MUXserver should be delivered with its characteristics set to the factory default conditions, ready for down- line loading by a host executing the Maintenance Operation Protocol (MOP). The factory default conditions can be re-established by holding the DUMP button while power is applied to the MUXserver. Refer to the appropriate MUXserver Hardware Installation Manual for more details. To make use of the OSF/1 system as a load host for a MUXserver Network, each MUXserver has to be re-configured so that it attempts to load its software image via the BOOTP/TFTP protocols. This is done by making use of the in-built MUXserver Boot-Line Configuration Program. Configuring the Load Host BOOTP Database 4-9 Configuring the Load Host BOOTP Database 4.4 Configuring the MUXserver To achieve this: 1. Attach an asynchronous terminal to the MUXserver Local Console. (The factory default line speed for the MUXserver Local Console is 9600 bps.) 2. Execute the following procedure, using the Locale Console to monitor progress and enter commands: 1. Cycle the power to the MUXserver, and wait for the MUXserver to request the loading of its software image via the Maintenance Operation Protocol (MOP). This condition is flagged by the following display on the Local Console terminal: Init -1000- Initialising MUXserver hardware_address FW V1.0-1 HW 0.0 MEM 0000 Init -1101- Attempting to locate load host [ISO8802] 2. Invoke the MUXserver Boot-Line Configuration Program by entering the < CTRL/B > keystroke. The utility will be entered immediately and confirmed by the display of the following message on the Local Console terminal: Digital Equipment Corporation MUXserver Boot-Line Configuration Program BCP> 3. Configure the load protocol by using the CONFIGURE command, and responding to the prompts as follows: BCP> CONFIGURE < Return > (LINE , NODE , LOAD_PROTOCOL) [LINE] : LOAD_PROTOCOL <> ( Return ) (MOP , BOOTP/TFTP) [MOP] : BOOTP/TFTP < Return > 4. Exit from the MUXserver Boot-Line Configuration Program. The MUXserver will repeat the software image load request by use of the Internet Boot Protocol. BCP> CONTINUE Init -1300- [IP] Attempting to locate load host [ETHERNET] . . . 4-10 Configuring the Load Host BOOTP Database Configuring the Load Host BOOTP Database 4.4 Configuring the MUXserver When configuration has been completed, verify the Load Host Installation by down-line loading the software image from the load host to the MUXserver using the procedure described in Chapter 5. Configuring the Load Host BOOTP Database 4-11 5 ________________________________________________________________ Verifying the Installation This chapter describes the verification of a MUXserver software installation. Verification includes: o Verifying the load host installation by down-line loading the server image, o Verifying the MUXserver as an operational system after it is loaded, by testing several representative server commands at an interactive terminal attached to the console port of the MUXserver, and o Configuring the MUXserver for network access from hosts on the LAN which have implementations for either the LAT, Telnet or SNMP protocols. Verifying the load host installation involves down-line loading the server image to a MUXserver and then reading the event logging messages. This confirms that the new load host: o Has the appropriate files in the correct directory, o Has a correct entry in its node database for the server, and o Can successfully down-line load the server image to the MUXserver. Verifying the total MUXserver Network installation involves the execution of some representative server commands at an interactive terminal attached to the console port of the MUXserver. This confirms that: o The correct version of the software has been loaded, o The MUXserver hardware operates with the new software, and Verifying the Installation 5-1 Verifying the Installation o The new software is running successfully. Configuring the MUXserver for network access permits interactive terminal communication across the LAN from a host which supports either the Telnet protocol or the LAT protocol. o Configuring a LAT command service on the MUXserver per- mits access from a host which supports an interactive LAT session. o Configuring the Internet address of the MUXserver permits access from a host which supports an inter- active Telnet session. Enabling SNMP then permits the MUXserver to act as an SNMP agent for an SNMP management station. 5.1 Verifying the Load Host Installation An interactive terminal attached to the console port of the MUXserver is needed to verify the MUXserver image load and dump events which in turn verify load host installation. For those MUXserver Networks which are to operate in an Internet environment, the console terminal can also be used to initially configure the Internet address of the MUXserver, thereby allowing further configuration across the LAN. Alternatively, the configuration of the MUXserver can be achieved by use of the ccr command. This command uses the MOP protocol to communicate with the MUXserver across the LAN without the need for any manipulation of MUXserver parameters. ________________________Note ________________________ The use of the ccr command requires that the MUXserver details are configured into the MOP database of the load host (refer to Chapter 3). _____________________________________________________ 5-2 Verifying the Installation Verifying the Installation 5.1 Verifying the Load Host Installation 5.1.1 Loading a New MUXserver When a MUXserver is new, it has no operating software in it until the initial down-line load. This load occurs automatically when the MUXserver is powered on. When power is applied to the MUXserver, it first executes self-test sequences. It then automatically requests a load of its image from any available load host. An established load host recognises the request and down-line loads the server image. The self-test sequence and the image load request sequences on the MUXserver can be verified: o By viewing the diagnostic light emitting diodes (LEDs) on the MUXserver, and o By checking messages sent to the console port on the MUXserver. Refer to the appropriate MUXserver Hardware Installation Manual for more detail. If the server image cannot be down-line loaded, it must be verified that no hardware or network problem is preventing the image load request from being sent. Therefore, coordination between software and hardware installation is important. Note that this automatic down-line load verifies the hardware but does not verify the load host installation. An interactive terminal attached to the console port of the MUXserver will display the events leading up to the loading of the server image. o For MUXservers configured to load via the MOP protocol, the following messages should appear on the local console: Init -1000- Initializing DEC MUXserver HH-HH-HH-HH-HH-HH FW Vn.n-nnn HW h.h Init -1101- Attempting to locate load host [ISO8802] Init -1105- Host xx-xx-xx-xx-xx-xx located [ISO8802] Init -1100- Requesting load from host xx-xx-xx-xx-xx-xx Init -1106- Loading from host xx-xx-xx-xx-xx-xx Init -1104- Image load complete Verifying the Installation 5-3 Verifying the Installation 5.1 Verifying the Load Host Installation where HH-HH-HH-HH-HH-HH is the Ethernet address of the MUXserver, in hexidecimal, xx-xx-xx-xx-xx-xx is the Ethernet address of the load host, in hexidecimal, nn.nnn is the firmware revision number, and h.h is the hardware revision number. o For MUXservers configured to load via the BOOTP protocol, the messages should appear on the local console in the following format: Init -1000- Initialising MUXserver HH-HH-HH-HH-HH-HH FW Vnn.n-nnn HW h.h Init -1300- [IP] Attempting to locate load host [ETHERNET] Init -1301- [IP] Host xx-xx-xx-xx-xx-xx located [ETHERNET] Init -1304- [IP] Loading from host xx-xx-xx-xx-xx-xx [ETHERNET] Init -1305- [IP] Image load complete If the MUXserver is unable to locate an appropriate load host, console messages will say that the MUXserver will retry at a later time. If either of the message sequences in the following screen display examples are displayed on the local console, you should verify the load host database details information and check the load host system log files for any indication of problems on the LAN. o For MUXservers which configured to load via the MOP protocol, the following messages on the local console show that a load host cannot be located: Init -1101- Attempting to locate load host [ISO8802] Init -1101- Attempting to locate load host [ETHERNET] Init -1103- Server will retry operation in n seconds o For MUXservers configured to load via the BOOTP protocol, the following messages on the local console show that a load host cannot be located: 5-4 Verifying the Installation Verifying the Installation 5.1 Verifying the Load Host Installation Init -1300- [IP] Attempting to locate load host [ETHERNET] Init -1314- Server will retry operation in n seconds ________________________Note ________________________ The retry time specified in the above displays will increase with each generation of the message, up to a limit of 300 seconds. _____________________________________________________ 5.1.2 Network Access to a MUXserver The details of a MUXserver Network can be configured by the Network Manager, once the MUXserver software is executing on the hardware. For details of interpretation of the LED displays which signal the status of operational software in the MUXserver, refer to the MUXserver Hardware Installation Manual relevant to the MUXserver involved. The Network Manager should refer to the same MUXserver Network Reference Manual for details on how to configure the MUXserver Network. ________________________Note ________________________ Whenever the MUXserver is reset to the factory default conditions (see the MUXserver Hardware Installation Manual), the load protocol will default to MOP and the Internet address will be forgotten. Any services defined on the MUXserver will also be forgotten. Use the procedure given in Section 4.4 to reconfigure the MUXserver to load via BOOTP. Use the procedure given in Section 5.1.2 to reconfigure the MUXserver for network access. _____________________________________________________ Verifying the Installation 5-5 Verifying the Installation 5.1 Verifying the Load Host Installation 5.1.2.1 ccr Access to a MUXserver The ccr command allows access to the MUXserver via the network immediately after the server image load has completed and the software commences execution. However, the ccr command requires that the MUXserver details are configured into the MOP database of the load host (refer to Chapter 3). If the load host has been configured to act solely as a BOOTP load host, the ccr command cannot be used by the Network Manager to access the MUXserver. The ccr command is invoked when the Network Manager enters: # /usr/sbin/ccr [options] node_name < Return > The options available to the Network Manager on the ccr command are detailed in the OSF/1 Online Manual Pages. These can be accessed by entering the command # man [-] ccr < Return > 5.1.2.2 LAT Access to a MUXserver Network access to the MUXserver is achieved via the LAT protocol when the Network Manager configures a LAT command service on the MUXserver. The privileged command used to configure a LAT command service is: Local> CHANGE SERVICE s_name COMMAND... [PASSWORD/IDENTIFICATION/CONNECTIONS] < Return> The characteristics of the LAT command service which are available are detailed in both the online help and the MUXserver Network Reference Manual. For instance: o The command service can be password-protected by specifying: . . . PASSWORD "service_password" where this command is included as a command tail for a "CHANGE SERVICE service_name COMMAND" sequence. o The command service can have a textual description string by similarly specifying a command tail in the form: . . . IDENTIFICATION "service_description" 5-6 Verifying the Installation Verifying the Installation 5.1 Verifying the Load Host Installation o The command service can be enabled or disabled by specifying a command tail of: . . . CONNECTIONS ENABLED/DISABLED The LAT command service can be created during the procedure given in Section 5.2. 5.1.2.3 Telnet Access to a MUXserver Network access to the MUXserver is achieved via the Telnet protocol when the Network Manager configures the Internet address for the MUXserver. Configuring the Internet address for the MUXserver is achieved by issuing the privileged commands: Local> CHANGE INTERNET ADDRESS internet_address < Return> Local> CHANGE INTERNET SUBNET [MASK] subnet_mask < Return> By default, the Telnet Listener port 23 will direct incoming connection requests to the MUXserver interactive management protocol. The characteristics of this Telnet Listener port can be displayed by entering the command: Local> SHOW TELNET [LISTENER] 23 [CHARACTERISTICS] < Return> The characteristics of this Telnet listener port can be modified by using the privileged command: Local> CHANGE TELNET [LISTENER] 23 . . . < Return>) The characteristics of the Telnet Listener port are detailed in both the online help and the MUXserver Network Reference Manual. For instance: o The Telnet Listener port can use the same LAT command service, as identified in Section 5.1.2.2, by specifying a command tail in the form: . . . SERVICE service_name If this option is used, the Telnet Listener port will inherit any password-protection configured on the command service. o Access to the Telnet Listener port can be password- protected by specifying a command tail in the form: . . . PASSWORD ENABLED/DISABLED Verifying the Installation 5-7 Verifying the Installation 5.1 Verifying the Load Host Installation o The Telnet Listener port can have a textual description string by specifying a command tail option like: . . . IDENTIFICATION "listener_description" o The Telnet Listener port can be enabled or disabled by specifying one of two command tail options: . . . CONNECTIONS ENABLED or: . . . CONNECTIONS DISABLED The configuration of the Internet address, and the Telnet Listener port, can be implemented during the procedure given in Section 5.2. 5.1.2.4 SNMP Access to a MUXserver Network access to the MUXserver is achieved via the SNMP protocol, when the Network Manager configures the Internet address for the MUXserver and enables the SNMP state. To configure the Internet address and enable the SNMP state, issue the privileged commands: Local> CHANGE INTERNET ADDRESS internet_address < Return> Local> CHANGE INTERNET SUBNET [MASK] subnet_mask < Return> Local> CHANGE SNMP STATE ENABLED < Return> Details of the SNMP implementation for the MUXserver are given in the MUXserver Network Reference Manual. The configuration of the Internet address and the SNMP state can be implemented during the procedure given in Section 5.2.2. 5.1.3 Loading an Existing MUXserver When an operating MUXserver is re-loaded, all users and all LAN connections are disconnected. If an existing MUXserver is about to be loaded with a new image, coordination with the Network Manager is important. Depending on users' requirements, it may be best to delay installation verification and to perform down-line load outside of normal working hours. 5-8 Verifying the Installation Verifying the Installation 5.1 Verifying the Load Host Installation Ask the Network Manager of an existing MUXserver Network to alert the interactive users on that server of the planned shutdown for reloading. The Network Manager should be given at least 30 minutes notice to disable connections and queuing to local services of the server if necessary. The MUXserver Network Reference Manual describes the issues involved in shutting down the server. The privileged commands used to re-load the MUXserver are Local> ATTACH ALL < Return> Local> BROADCAST PORT ALL "shutdown_message" < Return> Local> INITIALIZE [SERVER] DELAY n < Return> Details of the use of these commands are given in the MUXserver Network Reference Manual. For MUXservers which are configured into the load host MOP database, either the load command or the trigger command can be used as an alternative to the privileged INITIALIZE command. o The load command is available to the superuser, on the OSF/1 system, and requests the server to reload its software. The software will be reloaded using the MOP protocol, irrespective of the configured boot protocol. It will be loaded from the host which issues the load request to the server. (See the On-line Manual Pages for the load command for more information on this command.) # man [-] load < Return > To load a server, enter # load node_name [-p maintenance_password] < Return> The load command will wait for the completion of the server software image load before returning the superuser prompt. o The trigger command is available to the superuser, on the OSF/1 system, and requests the server to reload its software. The software will be reloaded using the MOP protocol, irrespective of the configured boot protocol. The software will be loaded from any load host on the Verifying the Installation 5-9 Verifying the Installation 5.1 Verifying the Load Host Installation network. (See the On-line Manual Pages for the trigger command for more information on this command.) # man [-] trigger < Return > To trigger a server, enter # trigger node_name [-p maintenance_password] < Return> The trigger command will not wait for the completion of the server software image load before returning the superuser prompt. ________________________Note ________________________ The maintenance_password option given in both the load command and the trigger command must be supplied if the server is configured to expect this password (see the MUXserver Network Reference Manual). If the maintenance_password is incorrect, the server will ignore the request to reload its software. _____________________________________________________ The load and trigger commands are useful to verify the MOP database for each alternate load host on the network. The load and trigger commands do not aid in the verification of the load host BOOTP capabilities. 5.2 Verifying the MUXserver Network Installation To complete the verification of the MUXserver system installation: 1. An interactive connection is established with the MUXserver (see Section 5.2.1), and 2. Representative server commands are executed to verify the correct operation of the software with the MUXserver Network (see Section 5.2.2). In the procedure given in Section 5.2.2, the Network Manager may include any MUXserver Network access con- figuration commands from Section 5.1.2.2, Section 5.1.2.3 or Section 5.1.2.4 . 5-10 Verifying the Installation Verifying the Installation 5.2 Verifying the MUXserver Network Installation 5.2.1 Establishing an Interactive Connection The available methods of establishing an interactive connection with the MUXserver interactive management protocol are by using: o The ccr command (see Section 5.1.2.1), # ccr . . . node_name < Return > < Return > o An asynchronous terminal connected to a port on the MUXserver network, < Return > < Return > o The telnet command available on the OSF/1 system, and # telnet client_name < Return > < Return > o The OpenVMS LATMaster command $ SET HOST/LAT command_service < Return > < Return > The telnet command and the SET HOST/LAT command are only available if the MUXserver has already been configured for network access (see Section 5.1.2). If the initial connection to the MUXserver is directed towards a password-protected service, the user will be prompted for the service password: Password> service_password (not echoed) < Return > < Return > If the initial connection to the MUXserver is protected by an access password, the user will be prompted for the access password: < BEL > # access_password (not echoed) < Return > ________________________Note ________________________ The default access_password for the MUXserver is ACCESS. _____________________________________________________ Verifying the Installation 5-11 Verifying the Installation 5.2 Verifying the MUXserver Network Installation 5.2.2 Verifying Server Operation Once a connection is established with the MUXserver interactive management protocol, 1. The following message and prompt should appear: MUXserver nnn Terminal Server Vm.n (BLnx) - LAT V5.2 (c) Copyright - Digital Equipment Corporation, 1991 server_identification_string Please type HELP if you need assistance Enter username> 2. Read the identification message to check that the correct version of the MUXserver image was successfully down-line loaded. If the message is not displayed, the problem could be with: o The load host, o The terminal, or o Incorrect software down-line loaded to the MUXserver. 3. Enter your user name (any string of up to 16 characters in length that identifies you) and press < Return >. The port should now enter local mode, and the Local> prompt should appear: Enter username> username < Return > Local> 4. Issue the SHOW SERVER command to display the character- istics of the MUXserver and their values: Local> SHOW SERVER < Return > A server characteristics display, similar to the example shown in Section C.4.4, should appear. Ensure that the server characteristics contains an appropriate Name, and that the Gateway Session Limit parameter is at least 2 (for the purposes of this verification). Modifying these parameters involves 5-12 Verifying the Installation Verifying the Installation 5.2 Verifying the MUXserver Network Installation entering privileged mode, and modifying the server characteristics. Local> SET PRIVILEGED < Return > Password> privileged_password (not echoed) < Return > Local> CHANGE SERVER NAME server_name < Return > Local> SET SERVER GATEWAY [SESSION LIMIT] n < Return > ________________________Note ________________________ The default privileged_password for the MUXserver is SYSTEM. _____________________________________________________ If the Network Manager requires Network Access to be configured for the MUXserver, enter privileged mode, execute the appropriate commands from Section 5.1.2.2, Section 5.1.2.3 or Section 5.1.2.4, and then exit the privileged mode. Local> . . . Local> SET NOPRIVILEGED < Return > 5. If the connection is via an asynchronous terminal connected to a MUXserver network port, use the TEST PORT command to check that the terminal is receiving valid character data. On the command line, specify the number of lines and the number of columns you would like displayed. For example, the following command will display five lines of 80 characters each: Local> TEST PORT COUNT 5 WIDTH 80 < Return > You can interrupt this test by pressing any key. 6. Issue the SHOW PORT command to display the characteris- tics of the terminal port and their values: Local> SHOW PORT < Return > A port characteristics display, similar to the example shown in Section C.4.4, should appear. Ensure that the port characteristics contains a Local Switch parameter other than None. If there is no Local Switch character defined, enter: Local> SET PORT LOCAL [SWITCH] ~ < Return > Verifying the Installation 5-13 Verifying the Installation 5.2 Verifying the MUXserver Network Installation 7. Use the SHOW SERVICES command to show what services are available to you. The following server command produces a list of services and service announcements Local> SHOW SERVICES < Return > Appendix C shows an example of a SHOW SERVICES display. 8. Select an available service that you are authorised to use and use the CONNECT command to verify that the MUXserver can logically connect your terminal to that service. On the command line, give the name of the service to which you want to connect as part of the CONNECT command Local> CONNECT service_name < Return > When the MUXserver successfully connects to the specified service, the response displayed on the terminal should be the same as if the terminal were directly connected to that service. 9. Enter several commands to verify the ability of the MUXserver to exchange data with the service. 10. Press < BREAK >, the Local Switch character, or log out from the service to return to local mode. 11. Establish a session to the load host with the TELNET command to verify that the MUXserver can logically connect your terminal via the Telnet protocol. On the command line, specify the Internet address of the load host if no Domain Name server or ARP entries have been configured in the MUXserver. The following example establishes a Telnet connection to the load host Local> TELNET load_host < Return > When the MUXserver successfully connects to the load host, the response displayed on the terminal should be the same as if the terminal were directly connected to the load host. 12. Enter several commands to verify the ability of the MUXserver to exchange data with the load host. 5-14 Verifying the Installation Verifying the Installation 5.2 Verifying the MUXserver Network Installation 13. Press < BREAK >, the Local Switch character, or log out from the load host to return to local mode. 14. Log out the terminal from the MUXserver. Local> LOGOUT < Return > Refer any difficulties with MUXserver system verification to the Network Manager. If verification has been completed successfully, the MUXserver is operating correctly and you should report the successful load host installation and MUXserver system installation to the Network Manager. If this installation was a software upgrade, either the software installer or the Network Manager must now reload all existing servers. 5.3 Verifying the Load Host Dump Capabilities An interactive terminal attached to the console port of the MUXserver is needed to verify MUXserver image load and dump events and the dump configuration of a new MUXserver. It is also necessary to have the MUXserver software loaded and operating. Press the Dump Request switch on the MUXserver (see the MUXserver Hardware Installation Manual). o For MUXservers configured to load via the MOP protocol, the following messages should appear on the local console: Init -1002- Fatal Bugcheck, PC=00000000 SR=0000 M=00000000 C=0102 Init -1109- Requesting dump to host xx-xx-xx-xx-xx-xx Init -1112- Dumping to host xx-xx-xx-xx-xx-xx Init -1111- Image dump complete where xx-xx-xx-xx-xx-xx is the load host Internet address (in hexidecimal). o For MUXservers which have been configured to load via the BOOTP protocol, the following messages should appear on the local console: Verifying the Installation 5-15 Verifying the Installation 5.3 Verifying the Load Host Dump Capabilities Init -1002- Fatal Bugcheck, PC=00000000 SR=0000 M=00000000 C=0102 Init -1308- [IP] Attempting to locate dump host xx_xx_xx_xx [ETHERNET] Init -1301- [IP] Host xx_xx_xx_xx located [ETHERNET] Init -1309- [IP] Dumping to host xx_xx_xx_xx [ETHERNET] Init -1310- [IP] Image dump complete If the MUXserver is unable to locate an appropriate dump host, the console messages will indicate that the dump failed. If any of the following message sequences are displayed on the local console, verify the load host dump configuration and check the load host system log files for any indication of problems on the LAN. o For MUXservers which have been configured to load via the MOP protocol, the following messages on the local console show that a load host cannot be located: Init -1002- Fatal Bugcheck, PC=00000000 SR=0000 M=00000000 C=0102 Init -1109- Requesting dump to host xx-xx-xx-xx-xx-xx Init -1110- Dump failure, timeout Init -1109- Requesting dump to host xx-xx-xx-xx-xx-xx Init -1110- Dump failure, timeout Init -1109- Requesting dump to host xx-xx-xx-xx-xx-xx Init -1110- Dump failure, timeout Init -1109- Requesting dump to host xx-xx-xx-xx-xx-xx Init -1110- Dump failure, timeout Init -1108- Attempting to locate dump host [ISO8802] Init -1108- Attempting to locate dump host [ETHERNET] o For MUXserver units which have been configured to load via the BOOTP protocol, the following messages on the local console show that a dump host cannot be located: Init -1002- Fatal Bugcheck, PC=00000000 SR=0000 M=00000000 C=0102 Init -1308- [IP] Attempting to locate dump host xx-xx-xx-xx-xx-xx [ETHERNET] Init -1308- [IP] Attempting to locate dump host 255.255.255.255 [ETHERNET] Init -1313- [IP] Dump failed o For MUXserver units which have been configured to load via the BOOTP protocol, the following messages on the local console show that a dump host can be located, but the tftpd daemon does not have write-access to that file (see Section 4.3.2): 5-16 Verifying the Installation Verifying the Installation 5.3 Verifying the Load Host Dump Capabilities Init -1002- Fatal Bugcheck, PC=00000000 SR=0000 M=00000000 C=0102 Init -1308- [IP] Attempting to locate dump host xx-xx-xx-xx-xx-xx [ETHERNET] Init -1301- [IP] Host xx-xx-xx-xx-xx-xx located [ETHERNET] Init -1309- [IP] Dumping to host xx-xx-xx-xx-xx-xx [ETHERNET] Init -1303- [IP] TFTP Error message received, code: 02 Access violation Init -1313- [IP] Dump failed At the termination of the dump sequence, the MUXserver will re-load the server image from a load host (see Section 5.1). If the dump sequence was successfully completed, the dump host has a file with the image dump of the MUXserver. o For MUXserver units which have been configured to load via the MOP protocol, the file will be located in /usr/lib/mop and will have the filename identified in Section 3.4.1. o For MUXserver units which have been configured to load via the BOOTP protocol, the file will be located in /tftpboot and will have the filename identified in Section 4.3.2. For a MUXserver 90 or a MUXserver 380, the file will be 4194304 bytes in size. For a MUXserver 320, the file will be 2097152 bytes in size. Verifying the Installation 5-17 A ________________________________________________________________ MUXserver Software Distribution Files Table A-1 lists the files included in the MUXserver Software distribution kit: Table_A-1_MUXserver_Distribution_Kit_Files______________________ Subset___Directory_______File_Name_______Description____________ MS8UNIX /tftpboot .DUMP A file used to configure a dump host /usr/lib/dnet ms8_ MUXserver release notes relnotes.mem dsvconfig Load Host MOP database management script dsvconfig.sh5 Load Host MOP database management commands /usr/man/man8 dsvconfig.8 Load Host MOP database management manual /usr/opt/MUXservMUXserver.bootptabe generic BOOTP definitions for a MUXserver decmux_ MIB definitions for a mib.txt MUXserver network rfc1213.txt Management Information Base for Network Management of TCP/IP- based Internets: MIB-II (continued on next page) MUXserver Software Distribution Files A-1 MUXserver Software Distribution Files Table_A-1_(Cont.)_MUXserver_Distribution_Kit_Files______________ Subset___Directory_______File_Name_______Description____________ rfc1316.txt Definitions of Managed Objects for Character Stream Devices rfc1317.txt Definitions of Managed Objects for RS-232-like Hardware Devices rfc1381.txt SNMP MIB Extensions for X.25 LAPB MS8MUX90 /usr/lib/dnet ms3901eng.sys MUXserver 90 software image MS8MUX320/usr/lib/dnet ms3201eng.sys MUXserver 320 software image MS8MUX380/usr/lib/dnet ms3801eng.sys MUXserver 380 software _________________________________________image__________________ A-2 MUXserver Software Distribution Files B ________________________________________________________________ Using the Remote Console Carrier The MUXserver Network supports the OSF/1 remote console carrier requester (ccr). This appendix describes the use of ccr from an OSF/1 host. ccr may be used to issue the BROADCAST command to warn users of an impending down-line load. To connect to the MUXserver with ccr, use the ccr command as follows: 1. On the command line, specify the node name of the MUXserver. Specify the service password if the MUXserver has a maintenance password. The following example command connects to a MUXserver named "drumcorps": # /usr/sbin/ccr drumcorps < Return > ccr: Remote console reserved In the following example, the MUXserver has a maintenance password "ff23" which is specified in the ccr command: # /usr/sbin/ccr -n drumcorps -p ff23 < Return > ccr: Remote console reserved 2. Press < Return > to activate the MUXserver, then enter the log-in password ("ACCESS" is the default password): < Return > # access < Return > (not echoed) You need not specify the Ethernet address with the ccr command. The ccr command automatically obtains this information from the load host's node database. Using the Remote Console Carrier B-1 Using the Remote Console Carrier 3. To exit from ccr, press : Local> ccr: Remote console released # ________________________Note ________________________ If you log out from the MUXserver with a LOGOUT command, the port is logged out but the ccr session remains active. Press to exit ccr. _____________________________________________________ Refer to the OSF/1 Programmers Manual and the MUXserver Network Reference Manual for information on using a remote console. The following example includes a series of commands to issue the MUXserver's BROADCAST command using ccr. # /usr/sbin/ccr -n drumcorps -p ff23 < Return > ccr: Remote console reserved < Return > # access < Return > (not echoed) MUXserver 380 Terminal Server V1.0 (BL7) - LAT V5.2 Please type HELP if you need assistance Enter username> JOYCE < Return > Password> CORPS < Return > (not echoed) Local> BROADCAST ALL "The MUXserver 380 will be reloaded in 3 minutes." < Return > local> ccr: Remote console released # B-2 Using the Remote Console Carrier C ________________________________________________________________ Installation, Configuration & Verification Examples C.1 Introduction This Appendix provides examples of installation and configuration procedures. It also illustrates the verification of a load host installation by down- line loading MUXserver software. Finally, it shows the verification of a MUXserver installation by testing representative server commands. C.2 Installation Example In the following example, the MUXserver software is installed successfully onto an OSF/1 system. The OSF/1 system is then configured to be a load host for the MUXserver network. The example assumes that the distribution kit medium is a magnetic tape, that the default tape device is used and that the release notes are sent to the default printer. It reflects the recommended procedure for installing a new MUXserver product: 1. Installing the MUXserver distribution software with the setld command. 2. Printing the release notes. 3. Starting the dsvconfig shell script to configure the load host node database so that it supports the new MUXserver. # cd / < Return > # /usr/sbin/mount -rd /dev/rz0c /mnt < Return > # setld -l /mnt/MS38200/bin < Return > Installation, Configuration & Verification Examples C-1 Installation, Configuration & Verification Examples C.2 Installation Example The following messages appear in response to this command sequence: The subsets listed below are optional: There may be more optional subsets than can be presented on a single screen. If this is the case, you can choose subsets screen by screen or all at once on the last screen. All of the choices you make will be collected for your confirmation before any subsets are installed. 1) MUXserver 320 V2.0 for OSF/1 2) MUXserver 380 V2.0 for OSF/1 3) MUXserver 90 V2.0 for OSF/1 4) MUXserver Support V2.0 for OSF/1 Or you may choose one of the following options: 5) ALL of the above 6) CANCEL selections and redisplay menus 7) EXIT without installing any subsets Enter your choices or press RETURN to redisplay menus. Choices (for example, 1 2 4-6): 5 < Return > You are installing the following optional subsets: MUXserver 320 V2.0 for OSF/1 MUXserver 380 V2.0 for OSF/1 MUXserver 90 V2.0 for OSF/1 MUXserver Support V2.0 for OSF/1 Is this correct? (y/n): y < Return > Checking file system space required to install selected subsets: File system space checked OK. (c) Copyright 1988-1993, Digital Equipment Corporation - All Rights Reserved The installation will take one to two minutes. MUXserver Support V2.0 for OSF/1 Copying from /mnt/MS38200/bin (disk) Verifying MUXserver 90 V2.0 for OSF/1 Copying from /mnt/MS38200/bin (disk) Verifying C-2 Installation, Configuration & Verification Examples Installation, Configuration & Verification Examples C.2 Installation Example MUXserver 320 V2.0 for OSF/1 Copying from /mnt/MS38200/bin (disk) Verifying MUXserver 380 V2.0 for OSF/1 Copying from /mnt/MS38200/bin (disk) Verifying MUXserver Support V2.0 Software (MS8UNIX200) installed successfully Review the release notes in /usr/lib/dnet before configuring the database Configuring MUXserver Support V2.0 for OSF/1 (MS8UNIX200) MUXserver 90 V2.0 Software (MS8MUX90200) installed successfully Configuring MUXserver 90 V2.0 for OSF/1 (MS8MUX90200) MUXserver 320 V2.0 Software (MS8MUX320200) installed successfully Configuring MUXserver 320 V2.0 for OSF/1 (MS8MUX320200) MUXserver 380 V2.0 Software (MS8MUX380200) installed successfully Configuring MUXserver 380 V2.0 for OSF/1 (MS8MUX380200) # lpr /usr/lib/dnet/ms8_relnotes.mem < Return > C.3 dsvconfig Configuration Examples The dsvconfig command is invoked by entering # /usr/lib/dnet/dsvconfig < Return > DECserver/MUXserver Configuration Procedure - Version 3.0 ------------------------------------------------------------------ Procedure started Mon Oct 11 12:16:12 EST 1993 ------------------------------------------------------------------ You must assign a unique node name for each DECserver/MUXserver you are going to configure. Please be sure to read/print your release notes. The release notes can be found in /usr/lib/dnet. Press to continue < Return > Installation, Configuration & Verification Examples C-3 Installation, Configuration & Verification Examples C.3 dsvconfig Configuration Examples C.3.1 The dsvconfig Menu The following example illustrates the dsvconfig menu. DECserver/MUXserver Configuration Procedure - Version 3.0 Menu of Options 1 - List known DECservers/MUXservers 2 - Add a DECserver/MUXserver 3 - Swap an existing DECserver/MUXserver 4 - Delete an existing DECserver/MUXserver 5 - Restore existing DECservers/MUXservers 6 - Exit from this procedure Your selection ? C-4 Installation, Configuration & Verification Examples Installation, Configuration & Verification Examples C.3 dsvconfig Configuration Examples Sections below show how the configuration procedure continues for each option. Except for LIST, all options return to the menu. C.3.2 Listing Known DECservers/MUXservers To list servers which are in the load host's database: Your selection ? 1 < Return > Node Svr Svc Ethernet Load Dump Id Type Ckt Addr Image File ============================================================================== clmon4 MS380 circuit-1 08-00-2B-15-6F-9A ms3801eng.sys ms8clmon4.dmp darlin MS320 circuit-1 08-00-2B-25-A6-CD ms3201eng.sys ms2darlin.dmp emulat MS300 circuit-1 08-00-2B-24-F5-06 ms4801eng.sys ms3emulat.dmp lintla MS90 circuit-1 08-00-2B-A1-18-2A ms3901eng.sys ms9lintla.dmp Total of 4 DECservers/MUXservers defined Press to continue < Return > C.3.3 Adding a DECserver or MUXserver The following example adds a new MUXserver 90 named server. Your selection ? 2 < Return > At any time you may type a ? for help. Type < 6 > to return to menu. Type to accept the default DECserver/MUXserver type ? MS90 < Return > DECserver/MUXserver node name for unit ? server < Return > DECserver/MUXserver Ethernet address for this unit ? 08-00-2b-2d-8c-53 < Return > Service circuit for this unit [circuit-2]? circuit-1 < Return > Please wait ... Installation, Configuration & Verification Examples C-5 Installation, Configuration & Verification Examples C.3 dsvconfig Configuration Examples Use LIST option to check that server is now in the list: Your selection ? 1 < Return > Node Svr Svc Ethernet Load Dump Id Type Ckt Addr Image File ============================================================================== clmon4 MS380 circuit-1 08-00-2B-15-6F-9A ms3801eng.sys ms8clmon4.dmp darlin MS320 circuit-1 08-00-2B-25-A6-CD ms3201eng.sys ms2darlin.dmp emulat MS300 circuit-1 08-00-2B-24-F5-06 ms4801eng.sys ms3emulat.dmp lintla MS90 circuit-1 08-00-2B-A1-18-2A ms3901eng.sys ms9lintla.dmp server MS90 circuit-1 08-00-2B-2D-8C-53 ms3901eng.sys ms9server.dmp Total of 5 DECservers/MUXservers defined Press to continue < Return > C.3.4 Swapping a DECserver/MUXserver for a New Unit In the following example, an existing MUXserver 90 named server is swapped for a new MUXserver 320, and is given the new node name of revers. The new server also has the same service circuit-ID as the old server. ________________________Note ________________________ To SWAP the identifiers of the same server, you must specify the Ethernet address although it will not change. _____________________________________________________ Your selection ? 3 < Return > At any time you may type a ? for help. Type < 6 > to return to menu. Type to accept the default Node name of DECserver/MUXserver you want to swap ? server < Return > DECserver/MUXserver at Ethernet address 08-00-2B-2D-8C-53 is being swapped. DECserver/MUXserver type [ MS90 ] ? ms320 < Return > DECserver/MUXserver node name for unit [ server ] ? revers < Return > DECserver/MUXserver Ethernet address for this unit ? 08-00-2B-2D-8C-35 < Return > Service circuit for this unit [ circuit-1 ] ? < Return > C-6 Installation, Configuration & Verification Examples Installation, Configuration & Verification Examples C.3 dsvconfig Configuration Examples Please wait ... Use the LIST option to display a listing of servers and check that revers appears on the listing instead of server. Your selection ? 1 < Return > Node Svr Svc Ethernet Load Dump Id Type Ckt Addr Image File ============================================================================== clmon4 MS380 circuit-1 08-00-2B-15-6F-9A ms3801eng.sys ms8clmon4.dmp darlin MS320 circuit-1 08-00-2B-25-A6-CD ms3201eng.sys ms2darlin.dmp emulat MS300 circuit-1 08-00-2B-24-F5-06 ms4801eng.sys ms3emulat.dmp lintla MS90 circuit-1 08-00-2B-A1-18-2A ms3901eng.sys ms9lintla.dmp revers MS320 circuit-1 08-00-2B-2D-8C-35 ms3201eng.sys ms2revers.dmp Total of 5 DECservers/MUXservers defined Press to continue < Return > C.3.5 Deleting a DECserver/MUXserver from the Database The following example deletes an existing server, with the node name revers from the load host node database. Your selection ? 4 < Return > At any time you may type a ? for help. Type < 6 > to return to menu. Node name of DECserver/MUXserver to be deleted ? revers < Return > Node revers deleted Use the LIST option to display a listing of servers, and check that revers no longer appears, as follows: Your selection ? 1 < Return > Node Svr Svc Ethernet Load Dump Id Type Ckt Addr Image File ============================================================================== clmon4 MS380 circuit-1 08-00-2B-15-6F-9A ms3801eng.sys ms8clmon4.dmp darlin MS320 circuit-1 08-00-2B-25-A6-CD ms3201eng.sys ms2darlin.dmp emulat MS300 circuit-1 08-00-2B-24-F5-06 ms4801eng.sys ms3emulat.dmp lintla MS90 circuit-1 08-00-2B-A1-18-2A ms3901eng.sys ms9lintla.dmp Installation, Configuration & Verification Examples C-7 Installation, Configuration & Verification Examples C.3 dsvconfig Configuration Examples Total of 4 DECservers/MUXservers defined Press to continue < Return > C.3.6 Restoring Existing Servers to the Database The following example shows the restoration of the local down-line load database. Your selection ? 5 < Return > Restoring existing DECservers from local database... Local database successfully restored. C.3.7 Exiting the dsvconfig Procedure To exit the dsvconfig MOP database management procedure, select option 6 from the main menu. Your selection ? 6 < Return > NOTE: The /usr/sbin/mop_mom daemon must be running before loading any DECservers/MUXservers. C.4 Verification Examples The following example, presented in four parts, shows the installation verification for an OSF/1 load host and the server system. The procedure tests that your OSF/1 system can perform successfully as a down-line load host for a particular server and that the server hardware and the correct version of the software operate successfully. In this example, the OSF/1 system is named HANSEL. The server that is loaded is a MUXserver with node name clmon4. This server is an existing server, currently operating on the network. This example assumes that the down-line load is performed during normal working hours and that server users are warned of the upcoming down-line load by way of ccr. C-8 Installation, Configuration & Verification Examples Installation, Configuration & Verification Examples C.4 Verification Examples C.4.1 Using ccr and Warning Server Users The following example uses the server's default log-in password of ACCESS, and the default server privileged password of SYSTEM. # /usr/sbin/ccr clmon4 -p ff23 < Return > ccr: Remote console reserved (press the key) # ACCESS (not echoed) < Return > MUXserver 380 Terminal Server V1.1 (BL7F) - LAT V5.2 Please type HELP if you need assistance Enter username> user < Return > Local> set priv < Return > Password> SYSTEM (not echoed) < Return > Local> attach all < Return > Local> broadcast all "The server will be reloaded in 3 minutes." < Return > Local> ccr: Remote console released # C.4.2 Checking Server Names Use the procedure given in Section C.3.2 in order to check the MUXserver node names for down-line loading. C.4.3 Down-line Loading with the load Command The following example will force the server image to be loaded into the server named clmon4 from the OSF/1 system where the command is entered. # /usr/sbin/load clmon4 -p ff23 < Return > Check the usr/spool/mqueue/syslog file for any error- logging messages. Installation, Configuration & Verification Examples C-9 Installation, Configuration & Verification Examples C.4 Verification Examples C.4.4 Verifying the Server System Installation The following example illustrates the verification of a server system installation for a newly installed MUXserver. This procedure tests the hardware, the correctness of the software version, and the ability of the new software to run successfully. It assumes that o An asynchronous terminal is connected to the console port 1, o The user name is USER, o The user password on the host system is USERFRIENDLY, o The load host is node name is PAISLY, o The Internet address of the load host is node 16.153.64.95, and o HANSEL is also a LAT service offered by the load host. (press the < Return > key a number of times) MUXserver 380 Terminal Server V2.0 (BL8E) - LAT V5.2 Please type HELP if you need assistance Enter username> USER < Return > Local> SHOW SERVER < Return > MUXserver 380 V2.0 BL8E LAT V5.2 FW 1.0-1 HW 0.0 Uptime: 0 00:24:31 Address: 08-00-2B-25-A6-CD Name: LAT_08002B25A6CD Number: 0 Identification: Circuit Timer: 80 Password Limit: 3 Console Port: 1 Prompt: Local> Inactivity Timer: 30 Queue Limit: 100 Keepalive Timer: 20 Retransmit Limit: 8 Multicast Timer: 30 Session Limit: 128 Node Limit: 200 User Limit: 32 Gateway Session Limit: 0 Software: MS3801ENG Service Groups: 0 Enabled Characteristics: Announcements, Broadcast, Dump, Lock C-10 Installation, Configuration & Verification Examples Installation, Configuration & Verification Examples C.4 Verification Examples Local> SET PRIVILEGED < Return > Password> SYSTEM (not echoed) < Return > Local> CHANGE SERVER NAME DARLING < Return > Local> SET SERVER GATEWAY 2 < Return > Local> CHANGE SERVICE DARLING COMMAND PASSWORD "LOCAL" < Return> Local> CHANGE INTERNET ADDRESS 16.153.64.224 < Return> Local> CHANGE INTERNET SUBNET 255.0.0.0 < Return> Local> CHANGE TELNET 23 SERVICE DARLING PASSWORD ENABLED < Return> Local> SET NOPRIVILEGED < Return > Local> TEST PORT COUNT 5 WIDTH 55 < Return > !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUV !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVW "#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWX #$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXY $%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ The display at the port of a new MUXserver should match the following example, which contains the factory-set values except for the port number and the user name: Local> SHOW PORT < Return > Port 1: USER Station: DARLING Character Size: 8 Input Speed: 9600 Flow control: XON Output Speed: 9600 Parity: None Modem Control: Disabled Access: Local Local Switch: None Backward Switch: None Name: PORT_A1_01 Break: Local Session Limit: 4 Forward Switch: None Type: Soft Default Protocol: LAT Alternate Speed: Disabled Preferred Service: None Authorized Groups: 0 Authorized Protocols: All Enabled Characteristics: Autobaud, Autoprompt, Broadcast, Input Flow Control, Loss Notification, Message Codes, Output Flow Control, Verification Local> SET PORT LOCAL ~ < Return > Installation, Configuration & Verification Examples C-11 Installation, Configuration & Verification Examples C.4 Verification Examples Local> SHOW SERVICES ALL SUMMARY < Return > Service Name Status Identification DEVELOP Available Hardware Timesharing Service Ident DOCUMENT Available Documentation Timesharing TEST Unavailable As usual TIMESHARING Unknown Server Software Development HANSEL Available OSF/1 Local> CONNECT HANSEL Local -010- Session 1 to HANSEL established OSF/1 () (ttyp0) login: user < Return > Password: userfriendly < Return > (not echoed) Last login: Mon Oct 18 13:11:03 from paisly DEC OSF/1 T2.0-1 (Rev. 114.2); Fri Sep 24 15:38:17 EST 1993 DEC OSF/1 T2.0-1 Worksystem Software (Rev. 114.2) The installation software has successfully installed your system. There are logfiles which contain a record of your installation. These are: /var/adm/smlogs/install.log - general log file /var/adm/smlogs/install.FS.log - file system creation logs /var/adm/smlogs/setld.log - log for the setld(8) utility /var/adm/smlogs/fverify.log - verification log file Fri Oct 29 17:12:51 EST 1993 # logout < Return > Local -011- Session 1 disconnected from HANSEL Local> TELNET 16.153.64.95 < Return > Local -010- Session 1 to host 16.153.64.95 established OSF/1 () (ttyp0) login: user < Return > Password: userfriendly < Return > (not echoed) Last login: Mon Oct 18 13:11:03 from paisly DEC OSF/1 T2.0-1 (Rev. 114.2); Fri Sep 24 15:38:17 EST 1993 DEC OSF/1 T2.0-1 Worksystem Software (Rev. 114.2) The installation software has successfully installed your system. C-12 Installation, Configuration & Verification Examples Installation, Configuration & Verification Examples C.4 Verification Examples There are logfiles which contain a record of your installation. These are: /var/adm/smlogs/install.log - general log file /var/adm/smlogs/install.FS.log - file system creation logs /var/adm/smlogs/setld.log - log for the setld(8) utility /var/adm/smlogs/fverify.log - verification log file Fri Oct 29 17:12:51 EST 1993 # logout < Return > Local -011- Session 1 disconnected from HANSEL Local> LOGOUT < Return > Local -020- Logged out port 1 on DARLING Installation, Configuration & Verification Examples C-13 ________________________________________________________________ Glossary This glossary defines terms used in the MUXserver Software Installation Guide for the OSF/1 operating system. ARP The Internet Address Resolution Protocol used to translate an Internet address to the Ethernet hardware address of the network device. Asynchronous Adjective used to refer to a communication method in which events are not tied to a timing signal. BOOTP The Internet Boot Protocol used to identify the actual location of a specified file. Console Port A DEC423 port used to connect a test terminal. DNS The Internet Domain Name Server facility. Ethernet A Xerox[TM] trade mark for a type of local area network based on carrier-sense multiple access/collision detection (CSMA/CD). LAN See Local Area Network. Glossary-1 LAT Local Area Transport - Digital's name for the Ethernet protocol used by the MUXserver for terminal connections. LED Light Emitting Diode. Local Area Network A network spanning a limited geographic area, such as a building or group of buildings, and using high speed data bus(es). MIB Management Information Base. MODEM A contraction of MOdulator DEModulator. A modem converts analog signals (for example, from a phone line) to digital signals (used, for example, in a computer), and digital signals to analog. Network Manager The person responsible for all components of a network in a particular geographic area. Note that this does not include the MUXserver/DECmux 300 network (see Server Manager). Node An intelligent device on a network. OpenVMS An operating system for Digital's VAX computers. OSF Open Systems Foundation Port The actual physical connection between equipment and, for example, a serial communications line. Glossary-2 Server A hardware and/or software device which provides many users with access to a system. Server Manager The person responsible for a particular server. This includes a person responsible for a MUXserver/DECmux 300 network which, in this context, is seen as a server. Service A resource, such as a computer. SNMP The Simple Network Management Protocol used to manage network devices, such as a computer and servers. Supervisor Port A DEC423 port used to connect a test terminal. Synchronous An adjective used to refer to a communication method in which events occur in relation to a timing signal. System Manager The person responsible for the policies, procedures and the daily operation of a computer system. Terminal An input/output computer peripheral device that has a keyboard and video screen or printer. Terminal Server An active device, such as a MUXserver/DECmux 300, used to attach terminals to a host system through a network. TFTP The Internet Trivial File Transfer Protocol used to transfer data to/from a specified file. Glossary-3 ULTRIX A UNIX[TM] operating system for Digital's VAX, MicroVAX, VAXstation and RISC hardware. Glossary-4 ________________________________________________________________ Index A Configuration options ___________________________ option 1, 3-7 Adding a MUXserver, 3-8 option 2, 3-8 Alternate load host option 3, 3-10 assignment, 1-3 option 4, 3-11 using, 2-16 option 5, 3-12 ARP, 1-10 CONNECT command, 5-14, C-12 B__________________________ Console carrier requester BOOTP, 1-3, 1-4, 1-6 see ccr bootptab, 1-10 Conventions, x database, 1-8 BOOTP Configuration D__________________________ preparation, 4-1 Database configuration BROADCAST command, C-9 load host, 3-1, 4-1 using ccr to issue, B-1 Deleting a MUXserver, 3-11 C Disk space requirements, ___________________________ 2-2 ccr Distribution kit, A-1 command, B-1 down-line loading connecting to node, B-1 server image, 3-13, 4-10 using to issue BROADCAST, dsvconfig B-1 different versions, 2-9 ccr command, 5-2, 5-6 example Configuration ADD option, C-5 example DELETE option, C-7 ADD option, C-5 EXIT option, C-8 DELETE option, C-7 LIST option, C-5 EXIT option, C-8 RESTORE option, C-8 LIST option, C-5 SWAP option, C-6 RESTORE option, C-8 options SWAP option, C-6 adding servers, C-5 Index-1 dsvconfig load command, C-9 options (cont'd) load command, 5-9 deleting servers, C-7 Load host exiting, C-8 alternate, 1-3 listing servers, C-5 assignment, 1-3 restoring servers, C-8 database, 1-8 swapping servers, C-6 database configuration, using for DECservers, 2-9 3-1, 4-1 dsvconfig, 1-8 dump verification, 5-15 conventions, 3-4 installation verification example of menu, C-4 , 5-2 introduction, 1-8, 3-2 LOGOUT command, 5-15, C-13 running, 3-5 dsvconfig menu, C-4 M__________________________ E MOP, 1-3, 1-4, 1-5 ___________________________ database restoration, Error 3-12 messages, 3-5 introduction, 1-8 Ethernet MOP Configuration address, x preparation, 3-1 G__________________________ N__________________________ Graphics conventions, x Numbering convention, x I__________________________ P__________________________ Installation, 2-16 Password disk space required, 2-2 server maintenance example, C-1 password, B-1 onto alternate load hosts service password, B-1 , 2-16 onto other operating R__________________________ systems, 2-16 Related publications, ix preparing for, 2-1 Release notes, 1-7 printing release notes, printing, C-1 C-1 Remote console carrier installation tasks, 1-2 see ccr L Restoring a MUXserver, ___________________________ 3-12 LED indications, 5-3 List MUXservers, 3-7 Index-2 TELNET command, 5-14, C-12 S__________________________ TEST PORT command, 5-13, Server image down-line C-11 loading, 3-13, 4-10 /tftpboot SET PRIVILEGED command, disk space required, 2-2 5-13, C-10 trigger command, 5-9 setld command, 1-7 U setld command ___________________________ CDROM distribution media, Up-line dumping 2-6 received by load host, introduction, 2-3 2-16 tape distribution media, /usr/lib/dnet 2-6 disk space required, 2-2 Shell script /usr/opt/MUXserver dsvconfig, 1-8 disk space required, 2-2 SHOW PORT command, 5-13, C-11 V__________________________ SHOW SERVER command, 5-12, Verifying load host C-10 installation SHOW SERVICES command, down-line loading example 5-13, C-11 , C-9 Software installation example, C-8 examples, C-1 example using ccr, C-9 network verification, warning server users, C-9 5-10 Verifying server system preparation, 2-1 installation verification, 1-11, 5-1 example, C-10 Software verification existing server, 5-8 network access, 5-5 new server, 5-3 Swapping MUXservers, 3-10 System installation, 5-1 T__________________________ tar, 1-7 tar command CDROM distribution media, 2-11 introduction, 2-3 tape distribution media, 2-13 Index-3