Remote Control HOWTO

IBM Cluster Systems Management for Linux(R)
Remote Control HOWTO

Version 1 Release 1

Document Number SA22-7856-00

5799-GNJ

Note!

Before using this information and the product it supports, read the information in Notices.

First Edition (June 2001)

This edition of the IBM Cluster Systems Management for Linux Remote Control HOWTO applies IBM Cluster Systems Management for Linux Version 1 Release 1, program number 5799-GNJ, and to all subsequent releases of this product until otherwise indicated in new editions.

IBM(R) welcomes your comments. A form for readers' comments may be provided at the back of this publication, or you may address your comments to the following address:

International Business Machines Corporation
Department 55JA, Mail Station P384
2455 South Road
Poughkeepsie, NY 12601-5400
United States of America
 
FAX (United States & Canada): 1+845+432-9405
FAX (Other Countries):
   Your International Access Code +1+845+432-9405
 
IBMLink(TM) (United States customers only): IBMUSM10(MHVRCFS)
IBM Mail Exchange: USIB6TC9 at IBMMAIL
Internet e-mail: mhvrcfs@us.ibm.com

If you would like a reply, be sure to include your name, address, telephone number, or FAX number.

Make sure to include the following in your comment or note:

When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you.

© Copyright International Business Machines Corporation 2001. All rights reserved.
U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.


Table of Contents

About This HOWTO

  • Who Should Use This HOWTO
  • Typographic Conventions
  • Related Information
  • How to Obtain Publications
  • Cluster Systems Management Remote Control Overview

  • Hardware Configuration
  • Networking Configuration
  • Management VLAN
  • Cluster VLAN
  • Public VLAN
  • Hardware and Networking Configuration Diagrams
  • Node Attributes Table
  • Remote Power

  • Remote Power Architecture
  • Remote Power Configuration
  • Writing a Custom Power Method
  • Node Configuration
  • Adding a New Node
  • Verifying Remote Power Configuration
  • ISP Remote Passwords
  • Testing Remote Control
  • Remote Console

  • Hardware Console Configuration
  • ESP and Serial Ports
  • Remote Console Configuration
  • Writing a Custom Console Method
  • Node Configuration
  • Verifying Remote Console Configuration
  • Verifying Equinox ESP Console
  • Equinox Configuration and Diagnostics
  • Equinox Diagnostics
  • Equinox Configuration Examples
  • Serial References
  • Notices

  • Trademarks
  • Publicly Available Software
  • Index


    About This HOWTO

    This HOWTO is a description of how to use the IBM Cluster Systems Management for Linux Remote Control functions. It describes the administrative tasks that can be accomplished with greater ease and efficiency by using these functions.


    Who Should Use This HOWTO

    This HOWTO is intended for system administrators who want to use IBM Cluster Systems Management for Linux. The system administrator should have experience in UNIX(R) administration and networked systems.


    Typographic Conventions

    This HOWTO follows these typographic conventions:

    Typographic Usage
    Bold
    • Bold words or characters represent system elements that you must use literally, such as commands, flags, and path names.

    Italic
    • Italic words or characters represent variable values that you must supply.
    • Italics are also used for book titles and for general emphasis in text.

    Constant width Examples and information that the system displays appear in constant width typeface.
    [ ] Brackets enclose optional items in format and syntax descriptions.
    { } Braces enclose a list from which you must choose an item in format and syntax descriptions.
    | A vertical bar separates items in a list of choices. (In other words, it means "or.")
    < > Angle brackets (less-than and greater-than) enclose the name of a key on the keyboard. For example, <Enter> refers to the key on your terminal or workstation that is labeled with the word Enter.
    ... An ellipsis indicates that you can repeat the preceding item one or more times.
    <Ctrl-x> The notation <Ctrl-x> indicates a control character sequence. For example, <Ctrl-c> means that you hold down the control key while pressing <c>.
    \ The continuation character is used in coding examples in this book for formatting purposes.

    Related Information

    For information on using serial devices, see these Linux HOWTO documents, located at /usr/doc/HOWTO or on the Linux Documentation Project Web site (http://metalab.unc.edu/mdw/index.html):


    How to Obtain Publications

    The IBM Cluster Systems Management for Linux publications are available as HTML and PDF files on the CD-ROM in the /doc directory or on the installed system in the /opt/csm/doc directory. The README is available on the CD-ROM in the root directory (/). The file names are as follows:

    Publications for IBM Cluster Systems Management for Linux were also available at the time of this release at the IBM Linux Clusters Web site (http://www.ibm.com/eserver/clusters/linux). The IBM Linux Clusters Web site also includes links to the following resources:


    Cluster Systems Management Remote Control Overview

    IBM Cluster Systems Management for Linux (CSM) Remote Control software allows a system administrator to control nodes in a Linux cluster from a remote location. This essentially frees the CSM cluster from any restrictions associated with geographic node location. The two main functions for CSM Remote Control are the remote power and remote console commands. The rpower command allows an administrator to query, power on, power off, and reset remote nodes. The rconsole command allows an administrator to open a console for a remote node. The CSM administrator runs the rpower and rconsole commands from a control node called the management server. See the man pages or the IBM Cluster Systems Management for Linux Technical Reference for detailed command usage information.


    Hardware Configuration

    CSM Remote Control cluster software is dependent upon the hardware configuration. For IBM Netfinity clusters, CSM hardware control point and internal service processor database attributes have to match the IBM Netfinity Advanced System Management (ASM) PCI adapter and the IBM Netfinity Internal Service Processors (ISP) names, respectively. (This relationship will be explained in more detail in this section.) This will ensure that the physical connections are correct and that the relationship between the hardware control and nodes is defined correctly in the CSM database.

    The remote power command, rpower, is directly related to the physical cabling of the Netfinity Advanced System Management PCI adapter and the internal processors that it controls. It is also dependent on the names defined to the internal processors. The remote console command, rconsole is dependent on the cabling of the remote console server and the cabling description in the CSM database. These details will be explained in the remote power and remote console sections to help you understand the interdependencies between the hardware and software. With the correct definitions, the rpower and rconsole commands will target the intended node or node group. (You can control hardware other than Netfinity hardware by writing custom power and console methods, which is discussed in later sections.)


    Networking Configuration

    For security reasons, the networking configuration must separate the remote control functions rpower and rconsole from other clusters functions. An efficient way to do this is to create a virtual LAN (VLAN) for the remote control functions, which is separate and distinct from the more general purpose VLAN connecting the cluster's nodes. Optionally, the cluster VLAN can be isolated from the larger network. See the following sections for more details.

    Management VLAN

    The management VLAN connects the management server to the cluster's terminal server(s) and to the ASM PCI adapter(s) installed in some of the nodes. Since this is intended to be an isolated network, traffic flows without encryption using clear text authentication. Access to the rpower and rconsole commands is limited to root user on the management server. All other nodes have no access to the Management VLAN.

    Cluster VLAN

    A cluster VLAN subdivides the Ethernet switch so each node can use the cluster VLAN for Network I/O (NFS, tftp, ftp) and job control traffic.

    Public VLAN

    Each node connects to a public VLAN to allow authorized access to the nodes in the cluster. You may choose to combine the cluster VLAN and public VLAN.


    Hardware and Networking Configuration Diagrams

    The following diagram (Figure 1) shows the hardware and networking configuration required for using CSM remote control. The Management Server connects to the Management VLAN and the Cluster VLAN through Ethernet adapters. The terminal server (an Equinox ESP in this example) connects to the Management VLAN through an Ethernet adapter, and to the cluster nodes through their serial (COM) ports as shown. (An Equinox ESP-16 can connect up to 16 nodes. Other terminal servers may have different capacities.) The nodes must be connected to the Cluster VLAN through their Ethernet adapters, and directly or indirectly to an ASM PCI adapter through their ISP ports. The Management VLAN connects to the ASM PCI adapters in select nodes. (One ASM PCI adapter is required for every 10 nodes.) The ASM PCI adapters connect to their own node's ISP port, and up to 9 more node ISP ports are daisy-chained from there. Configuration for a Public VLAN is optional and can be defined by the system administrator.

    Figure 1. CSM Remote Control Hardware and Networking Configuration



    View figure.

    The following diagram (Figure 2) shows the relationship between the ManagedNode database attributes and the actual (internal) hardware names used in the example. The Management Server database attribute names match those for the Management Server internal hardware names. The ISP database attribute names match those for the ISP internal hardware names. For remote power and remote console to work as expected, this matching of database attribute names to the internal hardware names must be correct for all Management Servers, ISPs, and ESPs in the cluster.

    Figure 2. CSM Remote Control Database Attributes



    View figure.

    Node Attributes Table

    For planning purposes, it is helpful to fill out a table describing all of the nodes' attributes. In the example, the cluster has 20 nodes. The following page contains a blank template you can fill out.

    Table 1. Node Attributes Table: Example

    Hostname* HW ControlPoint* Power Method Svc ProcName ConsoleServer Name* ConsoleServer Number Console Method Console PortNum** HWType
    clsn01 mgtn03 netfinity node01 mgtn02 1 esp 0 netfinity
    clsn02 mgtn03 netfinity node02 mgtn02 1 esp 1 netfinity
    clsn03 mgtn03 netfinity node03 mgtn02 1 esp 2 netfinity
    clsn04 mgtn03 netfinity node04 mgtn02 1 esp 3 netfinity
    clsn05 mgtn03 netfinity node05 mgtn02 1 esp 4 netfinity
    clsn06 mgtn03 netfinity node06 mgtn02 1 esp 5 netfinity
    clsn07 mgtn03 netfinity node07 mgtn02 1 esp 6 netfinity
    clsn08 mgtn03 netfinity node08 mgtn02 1 esp 7 netfinity
    clsn09 mgtn03 netfinity node09 mgtn02 1 esp 8 netfinity
    clsn10 mgtn03 netfinity node10 mgtn02 1 esp 9 netfinity
    clsn11 mgtn04 netfinity node01 mgtn02 1 esp a netfinity
    clsn12 mgtn04 netfinity node02 mgtn02 1 esp b netfinity
    clsn13 mgtn04 netfinity node03 mgtn02 1 esp c netfinity
    clsn14 mgtn04 netfinity node04 mgtn02 1 esp d netfinity
    clsn15 mgtn04 netfinity node05 mgtn02 1 esp e netfinity
    clsn16 mgtn04 netfinity node06 mgtn02 1 esp f netfinity
    clsn17 mgtn04 netfinity node07 mgtn03 2 esp 0 netfinity
    clsn18 mgtn04 netfinity node08 mgtn03 2 esp 1 netfinity
    clsn19 mgtn04 netfinity node09 mgtn03 2 esp 2 netfinity
    clsn20 mgtn04 netfinity node10 mgtn03 2 esp 3 netfinity

    * These are short names. A long name is clsn01.pok.ibm.com, for example.

    ** The console port number is the physical port the node's serial port is connected to in the console server hardware.


    Table 2. Node Attributes Table: Template

    Hostname* HW ControlPoint* Power Method Svc ProcName ConsoleServer Name* ConsoleServer Number Console Method Console PortNum** HWType
































































































































































































































































































    * These are short names. A long name is clsn01.pok.ibm.com, for example.

    ** The console port number is the physical port the node's serial port is connected to in the console server hardware.


    Remote Power

    The remote power command, rpower, boots and resets hardware, powers hardware on and off, and queries node power state. See the rpower man page or the IBM Cluster Systems Management for Linux Technical Reference for detailed usage information.

    The rpower command is structured so it can be easily expanded for another hardware type. It uses the PowerMethod attribute in the CSM database to determine which underlying hardware control routine will be used. If the PowerMethod attribute is netfinity, the hardware control routine called is /opt/csm/bin/netfinity_power. To use other hardware types you need to change the entry in CSM and write a new custom power method named /opt/csm/bin/PowerMethod_power. See Writing a Custom Power Method.


    Remote Power Architecture

    CSM hardware configuration consists of the following components:

    For optimal security, the components must be configured so that the management server is the only node attached to the management VLAN, and has sole access to the console servers and the ASM PCI adapter.

    Internal service processor names must correlate with the internal node names defined in the ASM PCI adapter. The names must match for the management server to power on and off the correct target nodes.

    For each node definition in the CSM database, the HWControlPoint attribute must match the ASM PCI adapter host name. Likewise, the node SvcProcName attribute in the database must match the text ID for the node's ISP.

    Each ASM PCI adapter manages a group of up to ten nodes. By default, each group contains nodes with SvcProcName attributes node01 - node10. Since you may have more than one group of nodes, the host name HWControlPoint attribute specifies the ASM PCI adapter associated with each group.

    Note:
    For the SvcProcName attribute, the node short host name can be used instead of the node01 - node10 format.

    Remote Power Configuration

    There is a direct relationship between the hardware configuration and the CSM database information created with the definenode command. Planning is required prior to running definenode to ensure that nodes are defined correctly. For detailed information on the definenode command, see the man page or the IBM Cluster Systems Management for Linux Technical Reference. For the define node procedure, see the IBM Cluster Systems Management for Linux Set-Up HOWTO.

    When replacing a node, the new service processor's text ID must be changed to match the SvcProcName attribute of the replaced node. You can use the lsnode command to verify the SvcProcName of the node. Likewise, you can use the lsnode command for debugging problems. For example, if an unexpected node powers off, use the lsnode command to verify that the CSM database SvcProcName attribute name of the node matches the text ID specified in the service processor. The same procedure is required when replacing an ASM PCI adapter. The service processor allows for a telnet or an http connection to the host name of the ASM PCI adapter, where you can use ASM panels to perform tasks such as checking node configuration and status. To check the ID and password see the /etc/opt/csm/bin/netfinity_power.config file. To change text IDs for ASM or ISP adapters, you must use the ASM PCI Adapter Firmware Update Diskette utility, which is downloadable from the Netfinity Web site. The Netfinity Web site is accessible from the IBM Linux Clusters Web site (http://www.ibm.com/eserver/clusters/linux).

    Writing a Custom Power Method

    You can write a custom power method to suit your hardware environment. Each environment has its own routine (in /opt/csm/bin/PowerMethod_power). The rpower command runs the power method and passes the following parameters. If you write a new power method to manage another power type, you must include these parameters in the order shown in the interface definition:

    1. option_string
    2. target_system_hostname
    3. HWControlPoint_hostname
    4. SvcProcName
    5. remote_action

    Node Configuration

    Remote power requires the following CSM attributes for each node:

    HWControlPoint
    Host name of the ASM PCI adapter to which this node's ISP is connected. For example: mgtn03.

    PowerMethod
    Determines the program to invoke for a specific type of hardware power control. For example: netfinity (which corresponds to /opt/csm/bin/netfinity_power).

    SvcProcName
    The internal service processor name. For example: node01.

    To specify the passwords and user IDs for remote power, edit the /etc/opt/csm/netfinity_power.config file.

    To replace a node, set the user ID, password, and text ID on the internal processor to the values which were configured for the replaced node. For details, see ISP Remote Passwords.

    Adding a New Node

    Adding a new node requires some initial planning using the Node Attributes Table and the lsnode command. The text ID of the Internal Service Processor and the SvcProcName attribute must match, and the PCI Adapter host name and HWControlPoint attribute must match. You should verify that these attributes are correct before running the definenode command.


    Verifying Remote Power Configuration

    To verify the remote power configuration, use the lsnode command. By viewing the output you can verify that the ASM PCI adapter and ISPs are configured correctly. For example, the command:

    lsnode -Al clsn03
    

    lists all the attributes for the specified node. Output is similar to:

    Hostname = clsn03.ppd.pok.ibm.com
    OSVersion =
    UniversalId = 0
    InstallDisk =
    ConsoleServerName = mgtn02.ppd.pok.ibm.com
    ConfigChanged = 0
    Status = 1
    HWControlPoint = mgtn03.ppd.pok.ibm.com
    OSType =
    SvcProcName = node03
    InstallMethod =
    PowerMethod = netfinity
    Macaddr =
    PowerStatus = 127
    ConsolePortNum = 2
    HWType = netfinity
    HWModel =
    OSDistribution =
    ConsoleMethod = esp
    LParID =
    OSKernel =
    InstallDiskType =
    ConsoleServerNumber = 1
    HWSerialNum =
     
    

    The service processor allows for a telnet or an http connection to the host name of the ASM PCI adapter, where you can use ASM panels to perform tasks such as checking node configuration and status. To check the ID and password see the /etc/opt/csm/netfinity_power.config file.


    ISP Remote Passwords

    IBM suggests that you change the ISP and ASM PCI adapter user IDs and passwords immediately upon system configuration. To change user IDs and passwords you must boot the node using the ASM PCI Adapter Firmware Update Utility diskette, which can be downloaded from the IBM Linux Clusters Web site (http://www.ibm.com/eserver/clusters/linux).

    To change user IDs and passwords using the ASM PCI Adapter Firmware Update Utility diskette:

    1. Boot the node using the diskette.
    2. Navigate to the Login Profiles.
    3. Select "USERID".
    4. Enter the new user ID and password.
    5. Click "Save".
    6. Update the /etc/opt/csm/netfinity_power.config file.

    See the IBM Linux Clusters Web site (http://www.ibm.com/eserver/clusters/linux) for a link to ASM PCI adapter utility information.


    Testing Remote Control

    You should test the remote control functions before using them in a production environment. Run query, power on, and power off to verify that the nodes are configured correctly and are responding accordingly. See the rpower man page or the IBM Cluster Systems Management for Linux Technical Reference for detailed examples.


    Remote Console

    The remote console command, rconsole, opens a remote console for each node specified with the command. The method used for opening a remote console is dependent upon the hardware and software supporting the remote console. This section describes remote console hardware configuration, software support, and the relationship between them.

    Notes:

    1. For Equinox ESP terminal servers, you must install Equinox espx RPM version 3.02 or later on the Management Server, because this is the minimum level required by Red Hat version 7.1

    2. Ethernet adapters on some Equinox terminal servers are only 10 Mb/s, so you must ensure the ports on the Ethernet switches are set accordingly.

    Hardware Console Configuration

    The console or terminal server is connected to the management VLAN by an Ethernet connection. Each console port is connected to the serial port of a node. The default console configuration is Equinox ESP; any other terminal server hardware requires different configuration by the system administrator.

    ESP and Serial Ports

    The serial ports' connection from the ESP to the nodes must be in the same order that the nodes are defined for the Equinox console server in CSM. The CSM database has a number associated with each ESP, and with each port within the ESP. Attention to detail is required when configuring both the hardware connectivity and the definitions of this relationship in the CSM database. More detailed information on this relationship is covered in Remote Console Configuration.


    Remote Console Configuration

    The definenode command updates the CSM database with the information describing the console server and each node's associated port number. There is a direct relationship between the hardware configuration and the CSM database information created with this command. Planning is required prior to running definenode to ensure that nodes are defined correctly. (A sample worksheet is shown in Node Attributes Table.) This section will expand on the CSM database contents and its relationship to the hardware and the rconsole command.

    The remote console function supports two software environments: Equinox ESP and Conserver. You specify which environment you want to use for the console for each node with the ConsoleMethod attribute. Supported values for this attribute are esp and conserver. For more information about the Conserver software environment, see the Conserver open source software Web site (http://www.conserver.com).

    Writing a Custom Console Method

    You can write a custom console method to suit your hardware environment. Each environment has its own routine (in /opt/csm/bin/ConsoleMethod_console) that returns the command that rconsole uses in the xterm window where the command is run. For example:

    The following parameters are passed to any console method. If you write a new console method to manage another console type, you must include these parameters in the order shown in the interface definition:

    1. console_server_hostname
    2. target_system_hostname
    3. console_port_number
    4. console_server_number

    Node Configuration

    The /etc/lilo.conf and /etc/inittab files on each node must contain the following settings, which direct the console to the serial port. When installnode is run, these files are automatically modified.

    Note:
    To enable the remote console, you must reboot all new nodes after running installnode.

    Remote console requires the following CSM attributes for each node:

    ConsoleServerName
    The console server host name. For example: mgtn02.pok.ibm.com.

    ConsoleServerNumber
    The console server number. For example: some number, 1 - N. For ESP this is the ESP number associated with the Equinox ESP system.

    ConsoleMethod
    Determines the program to invoke for a specific type of console server. The attribute value is one of two options: esp | conserver.

    ConsolePortNum
    The console port number. For ESP, this must be a 0 - f single hexadecimal digit.

    Verifying Remote Console Configuration

    The lsnode - Al command lists the node attributes in the CSM database. When the host parameter is specified, either by host name or IP address, the command displays all of the host's attributes.

    Verifying Equinox ESP Console

    To verify the remote console configuration, use the esptty and lsnode commands. The esptty command opens the Equinox Service Processor (ESP) Port Diagnostic Utility. This utility allows system administrators and users to verify or modify port characteristics or dump status information about Equinox ESP Serial Hub serial ports (ttys).

    You can also verify or change a Console Server configuration using the espcfg command. This command opens the ESP Configuration Wizard, which allows you to manage Equinox Service Processors. For further information on these verification commands, see the command man pages.


    Equinox Configuration and Diagnostics

    Note:
    The espcfg espdiag, and esptty commands are installed when you install the ESP RPM. For more information about Equinox ESP software configuration, see /usr/doc/espx-3.00/INSTALL.

    Equinox Diagnostics

    To test the Equinox hardware configuration:

    1. Ping the console server from the management server to test the connection.
    2. Run the espcfg command to:
    3. Run the espdiag command to:
    4. Verify that the Equinox ESP is on the management network associated with the management server by comparing the IP address and SubNetMask attribute in the ESP panel to the ifconfig command output.

    Equinox Configuration Examples

    1. To query Equinox ESP ports on a remote cluster, type:
      esptty -c
      
      Output is similar to:
      ESP Device   UdpState           TcpState         Ports
      /dev/esp1    HEARTBEAT          TCP_ACTIVE         16
      /dev/esp2    HEARTBEAT          TCP_ACTIVE         16
      /dev/esp3    HEARTBEAT          TCP_ACTIVE         16
      /dev/esp4    HEARTBEAT          TCP_ACTIVE         16
      /dev/esp5    HEARTBEAT          TCP_ACTIVE         16
      /dev/esp6    HEARTBEAT          TCP_ACTIVE         16
       
       
      
    2. To list the ttys for each port, type:
      ls /dev/ttyQ*
       
       
      
      The format of the tty is: ttyQesp_numbereport_number where: Output is similar to:
      /dev/ttyQ01e0  /dev/ttyQ02e4  /dev/ttyQ03e8  /dev/ttyQ04ec  /dev/ttyQ06e0
      /dev/ttyQ01e1  /dev/ttyQ02e5  /dev/ttyQ03e9  /dev/ttyQ04ed  /dev/ttyQ06e1
      /dev/ttyQ01e2  /dev/ttyQ02e6  /dev/ttyQ03ea  /dev/ttyQ04ee  /dev/ttyQ06e2
      /dev/ttyQ01e3  /dev/ttyQ02e7  /dev/ttyQ03eb  /dev/ttyQ04ef  /dev/ttyQ06e3
      /dev/ttyQ01e4  /dev/ttyQ02e8  /dev/ttyQ03ec  /dev/ttyQ05e0  /dev/ttyQ06e4
      /dev/ttyQ01e5  /dev/ttyQ02e9  /dev/ttyQ03ed  /dev/ttyQ05e1  /dev/ttyQ06e5
      /dev/ttyQ01e6  /dev/ttyQ02ea  /dev/ttyQ03ee  /dev/ttyQ05e2  /dev/ttyQ06e6
      /dev/ttyQ01e7  /dev/ttyQ02eb  /dev/ttyQ03ef  /dev/ttyQ05e3  /dev/ttyQ06e7
      /dev/ttyQ01e8  /dev/ttyQ02ec  /dev/ttyQ04e0  /dev/ttyQ05e4  /dev/ttyQ06e8
      /dev/ttyQ01e9  /dev/ttyQ02ed  /dev/ttyQ04e1  /dev/ttyQ05e5  /dev/ttyQ06e9
      /dev/ttyQ01ea  /dev/ttyQ02ee  /dev/ttyQ04e2  /dev/ttyQ05e6  /dev/ttyQ06ea
      /dev/ttyQ01eb  /dev/ttyQ02ef  /dev/ttyQ04e3  /dev/ttyQ05e7  /dev/ttyQ06eb
      /dev/ttyQ01ec  /dev/ttyQ03e0  /dev/ttyQ04e4  /dev/ttyQ05e8  /dev/ttyQ06ec
      /dev/ttyQ01ed  /dev/ttyQ03e1  /dev/ttyQ04e5  /dev/ttyQ05e9  /dev/ttyQ06ed
      /dev/ttyQ01ee  /dev/ttyQ03e2  /dev/ttyQ04e6  /dev/ttyQ05ea  /dev/ttyQ06ee
      /dev/ttyQ01ef  /dev/ttyQ03e3  /dev/ttyQ04e7  /dev/ttyQ05eb  /dev/ttyQ06ef
      /dev/ttyQ02e0  /dev/ttyQ03e4  /dev/ttyQ04e8  /dev/ttyQ05ec
      /dev/ttyQ02e1  /dev/ttyQ03e5  /dev/ttyQ04e9  /dev/ttyQ05ed
      /dev/ttyQ02e2  /dev/ttyQ03e6  /dev/ttyQ04ea  /dev/ttyQ05ee
      /dev/ttyQ02e3  /dev/ttyQ03e7  /dev/ttyQ04eb  /dev/ttyQ05ef
       
       
      
    3. To query remote nodes, enter:
      lsnode -Al clsn03
       
      
      Output is similar to:
      Hostname = clsn03.ppd.pok.ibm.com
      OSVersion =
      UniversalId = 0
      InstallDisk =
      ConsoleServerName = mgtn02.ppd.pok.ibm.com
      ConfigChanged = 0
      Status = 1
      HWControlPoint = mgtn03.ppd.pok.ibm.com
      OSType =
      SvcProcName = node03
      InstallMethod =
      PowerMethod = netfinity
      Macaddr =
      PowerStatus = 127
      ConsolePortNum = 2
      HWType = netfinity
      HWModel =
      OSDistribution =
      ConsoleMethod = esp
      LParID =
      OSKernel =
      InstallDiskType =
      ConsoleServerNumber = 1
      HWSerialNum =
       
       
      

    Serial References

    For more information on using serial devices, see the following Linux HOWTO documents, located at /usr/doc/HOWTO or on the Linux Documentation Project Web site (http://metalab.unc.edu/mdw/index.html):


    Notices

    This information was developed for products and services offered in the U.S.A.

    IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

    IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

    IBM Director of Licensing
    IBM Corporation
    North Castle Drive
    Armonk, NY 10504-1785
    U.S.A.

    For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to:

    IBM World Trade Asia Corporation
    Licensing
    2-31 Roppongi 3-chome, Minato-ku
    Tokyo 106, Japan

    The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law:

    INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

    This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

    IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

    Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:

    IBM Corporation
    Department LJEB/P905
    2455 South Road
    Poughkeepsie, NY 12601-5400
    U.S.A.

    Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.

    The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us.

    Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

    This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

    COPYRIGHT LICENSE:

    This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.


    Trademarks

    The following trademarks apply to this book:

    IBM and AIX are registered trademarks of International Business Machines Corporation.

    Linux is a registered trademark of Linus Torvalds.

    Red Hat and RPM are trademarks of Red Hat, Inc.

    UNIX is a registered trademark in the United States and other countries licensed exclusively through The Open Group.

    Other company, product, and service names may be the trademarks or service marks of others.


    Publicly Available Software

    IBM Cluster Systems Management for Linux includes software that is publicly available:

    cfengine
    A software package that is licensed under GPL and is used to create customization scripts.

    Conserver
    An application that adds logging and multi-user access for remote administration of serial ports, using locally installed multi-port serial interfaces and/or "reverse-telnet" to console servers.

    DBD-CSV, DBI
    Licensed by GPL or Artistic, these are dynamically loaded Perl modules.

    fping
    Licensed by BSD, this is executed as a separate binary.

    Perl
    Practical Extraction and Report Language is licensed under the Artistic license.

    Pidentd
    Public domain program by Peter Eriksson that implements the RFC-1413 identification server.

    SQL-Statement
    Licensed under GPL or Artistic, this is a dynamically loaded Perl module.

    This book discusses the use of these products only as they apply specifically to the IBM Cluster Systems Management for Linux product.

    Note:
    The distribution for these products includes the source code and associated documentation. All copyright notices in the source code and the documentation must be respected. You can find version and distribution information for each of these products that are part of your selected install options in the README file.

    Index

    A C D E H I M N O P R S T V
    A
  • about this HOWTO (61)
  • adding a new node (90)
  • architecture, Remote Power (84)
  • audience of this HOWTO (62)
  • C
  • Cluster Systems Management Remote Control overview (67)
  • cluster VLAN (75)
  • configuration, hardware (70)
  • configuration, hardware console (100)
  • configuration, networking (72)
  • configuration, Remote Console (104)
  • configuration, Remote Power (86)
  • configuration and diagnostics, Equinox (111)
  • configuration diagrams, hardware and networking (80)
  • configuration examples, Equinox (116)
  • configuration verification, Remote Power (93)
  • console method, custom (105)
  • D
  • diagnostics, configuration, Equinox (112)
  • diagnostics, Equinox (113)
  • E
  • Equinox configuration and diagnostics (110)
  • Equinox configuration examples (115)
  • Equinox diagnostics (114)
  • Equinox ESP Console, verifying (109)
  • ESP and Serial Ports (101)
  • H
  • hardware and networking configuration diagrams (79)
  • hardware configuration (69)
  • hardware console configuration (99)
  • I
  • ISP remote passwords (94)
  • M
  • management VLAN (73)
  • N
  • networking configuration (71)
  • node, adding new (91)
  • node attributes table (81)
  • node configuration, Remote Console (107)
  • node configuration, Remote Power (89)
  • O
  • overview, Cluster Systems Management Remote Control (68)
  • P
  • passwords, ISP remote (95)
  • power method, custom (87)
  • prerequisite knowledge for this HOWTO (63)
  • public VLAN (77)
  • publications, obtaining (66)
  • publicly available software (120)
  • R
  • references, serial (118)
  • related information (65)
  • Remote Console (98)
  • Remote Console configuration (103)
  • Remote Console configuration, verifying (108)
  • Remote Console node configuration (106)
  • Remote Control, testing (97)
  • Remote Power (82)
  • Remote Power architecture (83)
  • Remote Power configuration (85)
  • Remote Power configuration, verifying (92)
  • Remote Power node configuration (88)
  • S
  • Serial Ports, ESP (102)
  • serial references (117)
  • T
  • testing Remote Control (96)
  • Trademarks (119)
  • typographic conventions (64)
  • V
  • VLAN, cluster (76)
  • VLAN, management (74)
  • VLAN, public (78)