Console Server User Manual Page 4 of 261 5.1.2 Using SDT Connector client 66 5.1.3 Set up Windows XP/ 2003/Vista client 66 5.1.4 Set up earlier Windows clients 67 5.1.5 Set up Linux clients 67 5.2 OoB broadband access (IMG4xxx and IM42xx only) 67 5.3 Broadband Ethernet Failover (IMG4xxx and IM42xx only) 68 5.4 Dial-Out Failover (IMG4xxx and IM42xx only) 69 SECURE TUNNELING AND SDT CONNECTOR 71 6.1 Configuring for SDT Tunneling to Hosts 72 6.2 SDT Connector Configuration 72 6.2.1 SDT Connector client installation 73 6.2.2 Configuring a new gateway in the SDT Connector client 74 6.2.3 Auto-configure SDT Connector client with the users access privileges 75 6.2.4 Make an SDT connection through the gateway to a host 76 6.2.5 Manually adding hosts to the SDT Connector gateway 77 6.2.6 Manually adding new services to the new hosts 78 6.2.7 Adding a client program to be started for the new service 80 6.2.8 Dial in configuration 81 6.2.9 Choosing an alternate SSH client (e.g. PuTTY) 82 6.3 SDT Connector to Management Console 85 6.4 SDT Connector - telnet or SSH connect to serially attached devices 87 6.5 Using SDT Connector for out-of-band connection to the gateway 88 6.6 Importing (and exporting) preferences 90 6.7 SDT Connector Public Key Authentication 90 6.8 Setting up SDT for Remote Desktop access 91 6.8.1 Enable Remote Desktop on the target Windows computer to be accessed 91 6.8.2 Configure the Remote Desktop Connection client 93 6.9 SDT SHH Tunnel for VNC 96 6.9.1 Install and configure the VNC Server on the computer to be accessed 96 6.9.2 Install, configure and connect the VNC Viewer 97 6.10 Using SDT to IP connect to hosts that are serially attached to the gateway 99 6.10.1 Establish a PPP connection between the host COM port and console server 99 6.10.2 Set up SDT Serial Ports on console server 102 6.10.3 Set up SDT Connector to ssh port forward over the console server Serial Port 103
Console Server User Manual Page 6 of 261 9.1.4 LDAP authentication 135 9.1.5 RADIUS/TACACS user configuration 136 9.2 PAM (Pluggable Authentication Modules) 137 9.3 Secure Management Console Access 138 NAGIOS INTEGRATION 140 10.1 Nagios Overview 141 10.2 Central management and setting up SDT for Nagios 141 10.2.1 Set up central Nagios server 142 10.2.2 Set up distributed Opengear console servers 143 10.2.3 Set up SDT for Nagios on the central Nagios server 145 10.2.4 Set up the clients 146 10.3 Configuring Nagios distributed monitoring 147 10.3.1 Enable Nagios on the console server 148 10.3.2 Enable NRPE monitoring 149 10.3.3 Enable NSCA monitoring 150 10.3.4 Configure selected Serial Ports for Nagios monitoring 150 10.3.5 Configure selected Network Hosts for Nagios monitoring 151 10.3.6 Configure the upstream Nagios monitoring host 152 10.4 Advanced Distributed Monitoring Configuration 153 10.4.1 Sample Nagios configuration 153 10.4.2 Basic Nagios plug-ins 156 10.4.3 Additional plug-ins (IMG4xxx and IM42xx only) 156 10.4.4 Number of supported devices 158 10.4.5 Distributed Monitoring Usage Scenarios 159 SYSTEM MANAGEMENT 162 11.1 System Administration and Reset 162 11.2 Upgrade Firmware 163 11.3 Configure Date and Time 164 STATUS REPORTS 166 12.1 Port Access and Active Users 166 12.2 Statistics 166 12.3 Support Reports 167 12.4 Syslog 168 MANAGEMENT 169
A. Linux Commands B. Hardware Specification C. Safety and Certifications D. Connectivity and Serial I/O E. Hardware Test F. Terminology G. End User License Agreement H. Service and Warranty
This Users Manual walks you through installing and configuring your Integrated Management Gateway (IMG4004-5, IMG4216-25-DAC, IMG4216-25-DDC), Infrastructure Manager (IM4248-2-DAC, IM4248-2- DDC, IM4216-2-DAC, IM4216-2-DDC), Console Server (CM4001, CM4008, CM4116-SAC, CM4116-SDC, CM4148-SAC, CM4148-SDC) or KVM Console Server (KCS6104-SAC, KCS6104-DAC, KCS6116-SAC, KCS6116-DAC). Each of these products is referred to generically in this manual as a console server.
Once configured, you will be able to use your console server to securely monitor access and control the computers, networking devices, telecommunications equipment, power supply and operating environment in your data center or communications centers. This manual guides you in managing this infrastructure locally (across your operations or management LAN or through the local serial console port), and remotely (across the Internet, private network or via dial up).
Manual Organization This manual contains the following chapters: 1. Introduction An overview of the features of console server and information on this manual 2. Installation Physical installation of the console server and the interconnecting of controlled devices 3. System Configuration Describes the initial installation and configuration using the Management Console. Covers configuration of the console server on the network and the services that will be supported 4. Serial & Network Covers configuring serial ports and connected network hosts, and setting up User s and Groups 5. Failover and OoB dial-in Describes setting up the high availability access features of the console server 6. Secure Tunneling (SDT) Covers secure remote access using SSH and configuring for RDP, VNC, HTTP, HTTPS etc access to network and serially connected devices 7. Alerts and Logging Explains the setting up of local and remote event/ data logs and triggering SNMP and email alerts
Console Server User Manual Page 11 of 261 8. Power & Environment Management of USB, serial and network attached power strips and UPS supplies including Network UPS Tool (NUT) operation and IPMI power control. EMD environmental sensor configuration 9. Authentication All access to the console server requires usernames and passwords which are locally or externally authenticated 10. Nagios Integration Setting Nagios central management with SDT extensions and configuring the console server as a distributed Nagios server 11. System Management Covers access to and configuration of services to be run on the console server 12. Status Reports View the status and logs of serial and network connected devices (ports, hosts, power and environment) 13. Management Includes port controls and reports that can accessed by Users 14 Basic Configuration Command line installation and configuration using the config command 15. Advanced Config More advanced command line configuration activities where you will need to use Linux commands 16. KCS Thin Client Configuration and use of the thin client and other applications embedded in the KCS61xx The latest update of this manual can be found online at www.opengear.com/download.html
Types of users The console server supports two classes of users: I. Firstly there are the administrative users who will be authorized to configure and control the console server; and to access and control all the connected devices. These administrative users will be set up as members of the admin user group and any user in this class is referred to generically in this manual as the Administrator. An Administrator can access and control the console server using the config utility, the Linux command line or the browser based Management Console. By default the Administrator has access to all services and ports to control all the serial connected devices and network connected devices (hosts). II. The second class of users embraces those who have been set up by the Administrator with specific limits of their access and control authority. These users are set up as members of the users user group (or some other user groups the Administrator may have added). They are only authorized to perform specified controls on specific connected devices are referred to as Users. These Users (when authorized) can access serial or network connected devices; and control these devices using the specified services (e.g. Telnet, HHTPS, RDP, IPMI, Serial over LAN, Power Control). An authorized User can also use the Management Console to access configured devices and review port logs. In this manual, when the term user (lower case) is used, it is referring to both the above classes of users. This document also uses the term remote users to describe users who are not on the same LAN segment as the console server. These remote users may be Users, who are on the road connecting to managed devices over the public Internet, or it may be an Administrator in another office connecting to the console server itself over the enterprise VPN, or the remote user may be in the same room or the same office but connected on a separate VLAN to the console server.
Management Console The Management Console runs in a browser and provides a view of the console server and all the connected equipment. Administrators can use the Management Console, either locally or from a remote location, to configure the console server, the Users and the ports and connected hosts.
An authorized User can then use the Management Console to access and control configured devices, review port logs, use the in-built java terminal to access serially attached console and control power to connected devices. The console server runs an embedded Linux operating system, and experienced Linux and UNIX users may prefer to undertake configuration at the command line. You can get command line access by connecting through a terminal emulator or communications program to the console serial port; by ssh or telnet connecting through the LAN; or through an SSH tunneling to the console server.
Manual Conventions This manual uses different fonts and typefaces to show specific actions: Note Text presented like this indicates issues to take note of
Text presented like this highlights important issues and it is essential you read and take head of these warnings
Text presented with an arrow head indent indicates an action you should take as part of the procedure. Bold text indicates text that you type, or the name of a screen object (e.g. a menu or button) on the Management Console. Italic text is also used to indicate a text command to be entered at the command line level.
Console Server User Manual Page 15 of 261 2.1.1 IM4208-2, IM4216-2, IM4248-2 and IMG4216-25 kit components
Part # 509006 (509007) or Part # 50908
IM4216-2 (IM4248-2 or IM4208-2) Infrastructure Manager or IMG4216-25 Management Gateway
Part # 440016
2 x Cable UTP Cat5 blue
Part # 319000 and 319001
Connector DB9F-RJ45S straight and DB9F- RJ45S cross-over
Part # 440001
Dual IEC AC power cord (DAC models only)
Part # 539001
Quick Start Guide and CD-ROM
Unpack your IM/IMG42xx (IM4208-2, IM4216-2, IM4248-2 Infrastructure Manager or IM4216- 25 Management Gateway) kit and verify you have all the parts shown above, and that they all appear in good working order If you are installing your IM/IMG42xx in a rack you will need to attach the rack mounting brackets supplied with the unit, and install the unit in the rack. Take care to head the Safety Precautions listed in Appendix C Proceed to connect your IM/IMG42xx to the network, to the serial ports of the controlled devices, and to power as outlined below Note The IMG4216-2-DDC, IMG4248-2-DDC and IMG4216-25-DDC products are DC powered and the kits do not include an IEC AC power cord
2.1.2 IMG4004-5 kit components
Part # 509010
IMG4004-5 Management Gateway
Part # 440016
2 x Cable UTP Cat5 blue
Part # 319000 and 319001
Connector DB9F-RJ45S straight and DB9F-RJ45S cross-over
Part # 450006 and 440001 Power Supply 5VDC 2.0A IEC Socket and AC power cable
Part #539000
Quick Start Guide and CD-ROM
Unpack your IMG4004-5 kit and verify you have all the parts shown above, and that they all appear in good working order Proceed to connect your IMG4004-5 to the network, the serial ports and LAN ports of the controlled devices and to the AC power as shown below
2.1.3 CM4116 or CM4148 kit components
Part # 509001 (or Part # 509002)
CM4116 (CM4148) Console Server
Part # 440016
2 x Cable UTP Cat5 blue
Part # 319000 and 319001
Connector DB9F-RJ45S straight and DB9F-RJ45S cross-over
Part # 440001
IEC AC power cord (SAC model only)
Part # 539001
Quick Start Guide and CD-ROM
Unpack your CM4116 (or CM4148) kit and verify you have all the parts shown above, and that they all appear in good working order If you are installing your CM4116 (or CM4148) in a rack you will need to attach the rack mounting brackets supplied with the unit, and install the unit in the rack. Take care to head the Safety Precautions listed in Appendix C Proceed to connect your CM4116 (or CM4148) to the network, to the serial ports of the controlled devices, and to power as outlined below Note The CM4116-SDC and CM4148-SDC products are DC powered and the kits do not include an IEC AC power cord
Console Server User Manual Page 17 of 261 2.1.4 CM4008 Kit Components
Part # 509000
CM4008 Console Server
Part # 440016
2 x Cable UTP Cat5 blue
Part # 319000 and 319001
Connector DB9F-RJ45S straight and DB9F-RJ45S cross-over
Part # 450006 and 440001 Power Supply 5VDC 2.0A IEC Socket and AC power cable
Part #539000
Quick Start Guide and CD-ROM
Unpack your CM4008 kit and verify you have all the parts shown above, and that they all appear in good working order Proceed to connect your CM4008 to the network, the serial ports of the controlled servers and AC power as shown below
2.1.5 CM4001 Kit Components
Part # 509003
CM4001 Console Server
Part # 440016
2 x Cable UTP Cat5 blue
Part # 319000 and 319001
Connector DB9F-RJ45S straight and DB9F-RJ45S cross-over
Part # 4500XX
Power Supply 12VDC 1.0A Wall mount
Part #539000
Quick Start Guide and CD-ROM
Unpack your CM4001 and verify you have all the parts shown above, and that they all appear in good working order
Console Server User Manual Page 18 of 261 Proceed to connect your CM4001 to the network, to the serial ports of the controlled devices, and to power as outlined below
2.1.6 KCS6116 or KCS6104 kit components
Part # 509000
KCS6000 KVM console server
Part # 440016
2 x Cable UTP Cat5 blue
Part # 319000 and 319001
Connector DB9F-RJ45S straight and DB9F-RJ45S cross-over
Part # 440001
AC power cable
Part #539000
Quick Start Guide and CD-ROM
Unpack your KCS61xx (KCS6104, KCS6116 KVM Console Server) kit and verify you have all the parts shown above, and that they all appear in good working order If you are installing your KCS61xx in a rack you will need to attach the rack mounting brackets supplied with the unit, and install the unit in the rack. Take care to head the Safety Precautions listed in Appendix C Proceed to connect your KCS61xx to the network, to the serial and USB ports of the controlled devices, to any rack side LCD console or KVM switch, and to power as outlined below
Note The KCS6116-SDC and KCS6148-SDC products are DC powered and the kits do not include an IEC AC power cord
2.2 Power connection 2.2.1 IMG4216-25-DAC, IM4208-2-DAC, IM4216-2-DAC and IM4248-2-DAC power The IM42xx and IMG4216-25 console servers all have dual universal AC power supplies with auto failover built in. These power supplies each accept AC input voltage between 100 and 240 VAC with a frequency of 50 or 60 Hz and the total power consumption per console server is less than 30W. Two IEC AC power sockets are located at the rear of the metal case, and these IEC power inlets use conventional IEC AC power cords. Power cords for various regions are available, although the North American power cord is provided by default. There is a warning notice printed on the back of each unit.
To avoid electrical shock the power cord grounding conductor must be connected to ground
2.2.2 CM4116-SAC and CM4148-SAC power The CM4116 and CM4148 models have a built-in universal auto-switching AC power supply. This power supply accepts AC input voltage between 100 and 240 VAC with a frequency of 50 or 60 Hz and the power consumption is less than 20W.
Both CM4116 and CM4148 models have an IEC AC power socket located at the rear of the metal case. This IEC power inlet uses a conventional IEC AC power cord, and the power cords for various regions are available. (The North American power cord is provided by default). There is a warning notice printed on the back of each unit.
To avoid electrical shock the power cord grounding conductor must be connected to ground
2.2.3 IMG4004-5 and CM4008 power The IMG4004-5 and CM4008 are supplied with an external DC power supply unit. This unit accepts an AC input voltage between 100 and 250 VAC with a frequency of 50Hz or 60Hz. The DC power supply has an IEC AC power socket, which accepts a conventional IEC AC power cord. The power cord for North American is provided by default. The 5V DC connector from the power supply plugs into the 5VDC power socket on the rear of the IMG4004-5 or CM4008 chassis.
2.2.4 CM4001 power The CM4001 is supplied with an external DC wall mount power supply unit. Specific units are supplied for North American, Europe, UK, Japan and Australia. The 12V DC connector from the power supply unit plugs into the 9V-12VDC power socket on the rear of the CM4001 chassis.
Plug in the AC power cable (and the DC power cable for CM4001/4008) and turn AC power On
Confirm the Power LED on the CM4000 is lit. (Note: When you have applied power to the CM4008, you will also observe the LEDs P1 through P8 light up in sequence. On the CM4001 you will observe the Local and Serial LEDs flashing alternately)
Console Server User Manual Page 20 of 261 2.2.5 CM4116-SDC and CM4148-SDC Power The CM4116-SDC and CM4148-SDC models have a DC power connector block located at the rear of the metal case:
You must connect the CM41xx-SDC only to a DC-input power source that has an input supply voltage from 36 to 72 VDC. If the supply voltage is not in this range, the console server might not operate properly or might be damaged
You can identify the positive and negative feed positions from the label on the four way screw terminal block:
The + Terminal on the four way screw terminal block should always be connect to the more positive voltage (from 0V to +48 V) The - terminal on the four way screw terminal block should connect to the more negative voltage (from -48V to 0V) The CM41xx-SDC is a floating (wrt Earth); however there are two E terminals on the four way screw terminal block which are Earth or Chassis Ground It is recommended that 18-gauge copper wire be used to connect to the DC-power source. Strip each of the wires to 0.25inch (6.6 mm) (stripping more than this can leave exposed wire from the terminal block plug after installation):
Insert the exposed wire of each of the DC-input power source wires into the terminal block plug, making sure that you cannot see any wire lead, and tighten the terminal block captive screw:
Insert the terminal block plug in the terminal block header on the rear panel of the CM41xx-SDC: + E E -
2.2.6 IMG4216-25-DDC, IM4208-2-DDC, IM4216-2-DDC and IM4248-2-DDC power The IM42xx and IMG4216-25 DDC console servers all have dual DC power supplies with auto failover built in. To connect to the DC input supply:
Strip the DC wire insulation to expose approximately 0.4 inch (10 mm) of conductor Connect the safety ground wire to the E safety ground terminal on the terminal block first. The DDC is floating (wrt Earth), however the safety terminal on the three way screw terminal block connects to Earth or Chassis Ground Connect the power wires to the appropriate terminals of the terminal block: The + Terminal on the four way screw terminal block should always be connect to the more positive voltage (from 0V to +48 V) The - terminal on the four way screw terminal block should connect to the more negative voltage (from -48V to 0V) So the connections for -48 Volt DC input power are:
The connections for -48 Volt DC input power are:
Tighten the terminal screw to a torque of 8.0 0.5 in-lb (0.93 0.05 N-m) Repeat the connection steps above for the second power supply Turn on the DC power
The safety covers are an integral part of the DDC product. Do not operate the unit without the safety cover installed.
Any exposed wire lead from a DC-input power source can conduct harmful levels of electricity. So ensure that no exposed portion of the DC-input power source wire extends from the terminal block plug and safety cover
2.2.7 KCS6116-SAC and KCS6104-SAC power The standard KCS6104 and KCS6116 models have a built-in universal auto-switching AC power supply. This power supply accepts AC input voltage between 100 and 240 VAC with a frequency of 50 or 60 Hz and the power consumption is less than 40W.
Both KCS6104 and KCS6116 models have an IEC AC power socket located at the rear of the metal case. This IEC power inlet uses a conventional IEC AC power cord, and the power cords for various regions are available as accessories. Take note of the warning notice printed on the back of each unit:
To avoid electrical shock the power cord grounding conductor must be connected to ground
2.3 Network connection The RJ45 LAN ports are located on the rear panel of the CM4001/4008 and KCS61xx, and on the front panel of the rack-mount CM41xx and IM/IMG42xx. All physical connections are made using industry standard Cat5 cabling and connectors. Ensure you only connect the LAN port to an Ethernet network that supports 10Base-T/100Base-T. For the initial configuration of the console server you must connect a PC or workstation to the console servers principal network port (which is labeled NETWORK on IMG4xxx and KCS61xx, NETWORK1 on IM42xx and LAN on CM4xxx console servers)
2.4 Serial Port connection The RJ45 serial ports are located on the rear panel of the IMG4004-5, KCS61xx and CM4008; and on the front panel of the rack mount IMG4216-25, CM41xx and IM42xx. On all Opengear console servers the default RJ45 pinout is Opengear Classic RJ45 shown in 2.4.1 below. The CM4001 has a DB9 serial port connector. All devices also have a DB9 LOCAL (Console/Modem) port which is on the rear of the CM4001/4008 and KCS61xx, and the front of the CM41xx and IM/IMG42xx. The KCS6104 has four serial ports which by default are all configured as RJ Serial Console Ports 1-4 however Port 1 is also presented as the Modem port on the DB-9 connector. Conventional Cat5 cabling with RJ45 jacks are used for serial connections. Before connecting the console port of an external device to the console server serial port, confirm that the device does support the standard RS-232C (EIA-232). Opengear supplies an extensive range of cables and adapters that may be required to connect to the more popular servers and network appliances. These are overviewed in Appendix D (Connectivity and Serial I/O). More detailed information is available online at http://www.opengear.com/cabling.html The IM/IMG console servers are available with a selection of alternate RJ45 pinouts. These must be specified in the part number at the time of order. By default all product ships standard with Opengear Classic pinout: The IM4216-2 and IM4248-2 console servers are available with three RJ45 pinout configurations (standard Opengear Classic, Cisco or Cyclades). The IM4208-2 console server offers a choice selection of two RJ45 pinouts (standard Opengear Classic or Cyclades) The IMG4216-25 and KCS61xx console server offers a choice selection of two RJ45 pinouts (standard Opengear Classic or Cisco) These alternate pinouts need to be specified in the part number at the time of order e.g. to order an IM4248-2 dual power supply AC USA model, specify: IM4248-2-DAC-US for a unit equipped with standard Opengear Classic RJ pinouts IM4248-2-DAC-US-01 for a unit equipped with Cyclades RJ pinouts (rolled cable connection) IM4248-2-DAC-US-02 for a unit equipped with Cisco RJ pinouts (straight through cable connection)
2.4.1 Opengear Classic RJ45 pinout All Opengear console server products by default have the RJ45 pinout shown below:
PIN SIGNAL DEFINITION DIRECTION 1 RTS Request To Send Output 2 DSR Data Set Ready Input 3 DCD Data Carrier Detect Input 4 RXD Receive Data Input 5 TXD Transmit Data Output 6 GND Signal Ground NA 7 DTR Data Terminal Ready Output 8 CTS Clear To Send Input
2.4.2 Cyclades RJ45 pinout (option -01)
Easy to replace Cyclades products, for use with rolled RJ-45 cable.
PIN SIGNAL DEFINITION DIRECTION 1 RTS Request To Send Output 2 DTR Data Terminal Ready Output 3 TXD Transmit Data Output 4 GND Signal Ground NA 5 CTS Clear To Send Input 6 RXD Receive Data Input 7 DCD Data Carrier Detect Input 8 DSR Data Set Ready Input
2.4.3 Cisco RJ45 pinout (option -02) Straight through RJ-45 cable to equipment such as Cisco, Juniper, SUN, and more...
PIN SIGNAL DEFINITION DIRECTION 1 CTS Clear To Send Input 2 DSR Data Set Ready Input 3 RXD Receive Data Input 4 GND Signal Ground NA 5 GND Signal Ground NA 6 TXD Transmit Data Output 7 DTR Data Terminal Ready Output 8 RTS Request To Send Output
Console Server User Manual Page 25 of 261 The IM/IMG console servers each have one USB port and ship. External USB devices can be plugged into this USB port however the rack mount IM/IMG42xx console servers ship with a USB memory stick in anticipation it will generally be installed in this port for extended log file storage etc.
The IMG4004-5 has an internal USB flash as well as an unallocated external port, and there are four USB 2.0 ports on the rear panel of the KCS61xx models. These ports are used for connecting to USB consoles (of managed UPS hardware) and attaching other external devices (such as a USB memory stick or keyboard). External USB devices (including USB hubs) can be plugged into any USB port.
2.6 Keyboard /Video/ Mouse Connection (KCS61xx only) Connect the rack mounted LCD drawers PS/2 Keyboard and Video to the KCS61xx Video/Keyboard or DB15 VGA connectors. The default video resolution is 1024x768. The KCS61xx also supports USB keyboard/mouse.
Alternately the KCS61xx can be connected locally via a KVM switch to the existing KVM (and KVMoIP) infrastructure at the rack. The KCS will work seamlessly with and extend this legacy KVM infrastructure delivering next generation management capabilities.
Note Care should be taken in handling all console server products. There are no operator serviceable components inside, so please do not remove covers, and do refer service to qualified personnel
SYSTEM CONFIGURATION Introduction This chapter provides step-by-step instructions for the initial configuration of your console server, and connecting it to the Management or Operational LAN. This involves the Administrator: Activating the Management Console Changing the Administrator password Setting the IP address console servers principal LAN port Selecting the network services to be supported This chapter also discusses the communications software tools that the Administrator may use in accessing the console server, and the configuration of the additional LAN ports on the IM/IMG42xx.
3.1 Management console connection Your console server comes configured with a default IP Address 192.168.0.1 Subnet Mask 255.255.255.0 Directly connect a PC or workstation to the console server
Note For initial configuration it is recommended that the console server be connected directly to a single PC or workstation. However, if you choose to connect your LAN before completing the initial setup steps, it is important that: you ensure there are no other devices on the LAN with an address of 192.168.0.1 the console server and the PC/workstation are on the same LAN segment, with no interposed router appliances
3.1.1 Connected PC/workstation set up To configure the console server with a browser, the connected PC/ workstation should have an IP address in the same range as the console server (e.g. 192.168.0.100): To configure the IP Address of your Linux or Unix PC/workstation simply run ifconfig For Windows PCs (Win9x/Me/2000/XP/ Vista/ NT): Click Start -> (Settings ->) Control Panel and double click Network Connections (for 95/98/Me, double click Network). Right click on Local Area Connection and select Properties Select Internet Protocol (TCP/IP) and click Properties
Console Server User Manual Page 27 of 261 Select Use the following IP address and enter the following details: o IP address: 192.168.0.100 o Subnet mask: 255.255.255.0 If you wish to retain your existing IP settings for this network connection, click Advanced and Add the above as a secondary IP connection. If it is not convenient to change your PC/workstation network address, you can use the ARP-Ping command to reset the console server IP address. To do this from a Windows PC: Click Start -> Run Type cmd and click OK to bring up the command line Type arp d to flush the ARP cache Type arp a to view the current ARP cache which should be empty
Now add a static entry to the ARP table and ping the console server to have it take up the IP address. In the example below we have an console server with a MAC Address 00:13:C6:00:02:0F (designated on the label on the bottom of the unit) and we are setting its IP address to 192.168.100.23. Also the PC/workstation issuing the arp command must be on the same network segment as the console server (i.e. have an IP address of 192.168.100.xxx) Type arp -s 192.168.100.23 00-13-C6-00-02-0F (Note for UNIX the syntax is: arp -s 192.168.100.23 00:13:C6:00:02:0F) Type ping -t 192.18.100.23 to start a continuous ping to the new IP Address. Turn on the console server and wait for it to configure itself with the new IP address. It will start replying to the ping at this point Type arp d to flush the ARP cache again
3.1.2 Browser connection Activate your preferred browser on the connected PC/ workstation and enter https://192.168.0.1 The Management Console supports all current versions of the popular browsers (Netscape, Internet Explorer, Mozilla Firefox and more)
You will be prompted to log in. Enter the default administration username and administration password:
Username: root
Password: default
Note Console servers with firmware versions later than V2.2 are factory configured with HTTP disabled and HTTPS enabled appliances
A Welcome screen, which lists four initial installation configuration steps, will be displayed: 1. Change the default administration password on the System/Administration page (Chapter 3) 2. Configure the local network settings on the System/IP page (Chapter 3) 3. Configure port settings and enable .. the Serial & Network/Serial Port page (Chapter 4) 4. Configure users with access to serial ports on the Serial & Network/Users page (Chapter 3) After completing each of the above steps, you can return to the configuration list by clicking in the top left corner of the screen on the logo:
Note If you are not able to connect to the Management Console at 192.168.0.1 or if the default Username / Password were not accepted then reset your console server (refer Chapter 10)
Console Server User Manual Page 29 of 261 3.1.3 Initial KCS connection For initial configuration of the KCS61xx console server you will need to directly connect a video console and mouse (or KVM switch) to its Video/Keyboard or VGA port. When you power on the KCS initially and you will be prompted on your directly connected video console to log in:
Enter the default administration username and password (Username: root Password: default) and you will be presented with the KCS control panel
Click the Configure button on the control panel. This will load the Firefox browser and bring up the KCS Management Console At the Management Console: Welcome menu select System: Administration
3.2 Administrator Password For security reasons, only the administration user named root can initially log into your console server. So only those people who know the root password can access and reconfigure the console server itself. The corollary is that anyone who correctly guesses the root password could gain access (and the default root password is default). So it is essential that you enter and confirm a new password before giving the console server any access to, or control of, your computers and network appliances. Note: It is also recommended that you set up a new Administrator user as soon as convenient and log- in as this new user for all ongoing administration functions (rather than root). This Administrator can be configured in the admin group with full access privileges through the Serial & Network: Users & Groups menu as detailed in Chapter 4
Console Server User Manual Page 31 of 261 Enter a new System Password then re-enter it in Confirm System Password. This is the new password for root, the main administrative user account, so it is important that you choose a complex password, and keep it safe At this stage you may also wish to enter a System Name and System Description for the console server to give it a unique ID and make it simple to identify Click Apply. As you have changed the password you will be prompted to log in again. This time use the new password Note If you are not confident your console server has been supplied with the current release of firmware, you can upgrade. Refer Upgrade Firmware - Chapter 10
3.3 Network IP address The next step is to enter an IP address for the principal Ethernet (LAN/Network/Network1) port on the console server; or enable its DHCP client so that it automatically obtains an IP address from a DHCP server on the network it is to be connected to. or On the System: IP menu select the Network Interface page then check dhcp or static for the Configuration Method If you selected static you must manually enter the new IP Address, Subnet Mask, Gateway and DNS server details. This selection automatically disables the DHCP client
If you selected dhcp the console server will look for configuration details from a DHCP server on your management LAN. This selection automatically disables any static address. The console server MAC address can be found on a label on the base plate Note In its factory default state (with no Configuration Method selected) the console server has its DHCP client enabled, so it automatically accepts any network IP address assigned by a DHCP server on your network. In this initial state, the console server will then respond to both its Static address (192.168.0.1) and its newly assigned DHCP address By default the console server LAN port auto detects the Ethernet connection speed. However you can use the Media menu to lock the Ethernet to 10 Mb/s or 100Mb/s and to Full Duplex (FD) or Half Duplex (HD) Note If you have changed the console server IP address, you may need to reconfigure your PC/workstation so it has an IP address that is in the same network range as this new address (as detailed in an earlier note in this chapter) Click Apply You will need to reconnect the browser on the PC/workstation that is connected to the console server by entering http://new IP address
3.3.1 IPv6 configuration The console server Network and Management LAN Interfaces can also be configured for IPv6 operation: On the System: IP menu select General Settings page and check Enable IPv6
Then configure the IPv6 parameters on each Interface page
3.4 System Services The Administrator can access and configure the console server and connected devices using a range of access protocols. The factory default enables HTTPS and SSH access to the console server and disables HTTP and Telnet (The factory default for console servers pre firmware version 2.2 enabled HTTP, HTTPS, Telnet and SSH). The User can also use nominated enabled services to connect through the console server to attached serial and network connected devices. The Administrator can simply disable any of the services, or enable others:
Console Server User Manual Page 34 of 261 Select the System: Services option then select /deselect for the service to be enabled /disabled. The following access protocol options are available: HTTPS This ensures secure browser access to all the Management Console menus. It also allows appropriately configured Users secure browser access to selected Management Console Manage menus. If you enable HTTPS, the Administrator will be able to use a secure browser connection to the Console servers Management Console. For information on certificate and user client software configuration refer Chapter 9 - Authentication. By default HTTPS is enabled, and it is recommended that only HTTPS access be used if the console server is to be managed over any public network (e.g. the Internet). HTTP The HTTP service allows the Administrator basic browser access to the Management Console. It is recommended the HTTP service be disabled if the Console server is to be remotely accessed over the Internet. Telnet This gives the Administrator telnet access to the system command line shell (Linux commands). While this may be suitable for a local direct connection over a management LAN, it is recommended this service be disabled if the console server is to be remotely administered. SSH This service provides secure SSH access to the Linux command line shell. It is recommended you choose SSH as the protocol where the Administrator connects to the console server over the Internet or any other public network. This will provide authenticated communications between the SSH client program on the remote PC/workstation and the SSH sever in the console server. For more information on SSH configuration refer Chapter 9 - Authentication. There are also a number of related service options that can be configured at this stage: SNMP This will enable netsnmp in the console server, which will keep a remote log of all posted information. SNMP is disabled by default. The SNMP service is only available in CM4116/48 and IM/IMG4xxx models. To modify the default SNMP settings, the Administrator must make the edits at the command line as described in Chapter 15 Advanced Configuration TFTP This is relevant to IM42xx and IMG4xxx console servers only as it will set up default tftp server on the USB flash card. This server can be used to store config files, maintain access and transaction logs etc Ping This allows the console server to respond to incoming ICMP echo requests. Ping is enabled by default, however for security reasons this service should generally be disabled post initial configuration And there are some serial port access parameters that can be configured on this menu: Base The console server uses specific default ranges for the TCP/IP ports for the various access services that Users and Administrators can use to access devices attached to serial ports (as covered in Chapter 4 Configuring Serial Ports). The Administrator can also set alternate ranges for these services, and these secondary ports will then be used in addition to the defaults. The default TCP/IP base port address for telnet access is 2000, and the range for telnet is IP Address: Port (2000 + serial port #) i.e. 2001 2048. So if the Administrator were to set
Console Server User Manual Page 35 of 261 8000 as a secondary base for telnet then serial port #2 on the console server can be telnet accessed at IP Address:2002 and at IP Address:8002. The default base for SSH is 3000; for Raw TCP is 4000; and for RFC2217 it is 5000 Click Apply. As you apply your services selections, the screen will be updated with a confirmation message: Message Changes to configuration succeeded.
3.5 Communications Software You have configured access protocols for the Administrator client to use when connecting to the console server. User clients (who you may set up later) will also use these protocols when accessing console server serial attached devices and network attached hosts. So you will need to have appropriate communications software tools set up on the Administrator (and User) clients PC/workstation. Opengear provides the SDT Connector as the recommended client software tool, however other generic tools such as PuTTY and SSHTerm may be used, and these are all described below: 3.5.1 SDT Connector Opengear recommends using the SDT Connector communications software tool for all communications with Console servers, to ensure these communications are secure. Each console server is supplied with an unlimited number of SDT Connector licenses to use with that console server.
SDT Connector is a light weight tool that enables Users and Administrators to securely access the Console server, and the various computers, network devices and appliances that may be serially or network connected to the console server. SDT Connector is a Java client program that couples the trusted SSH tunneling protocol with popular access tools such as Telnet, SSH, HTTP, HTTPS, VNC, RDP to provide point-and-click secure remote management access to all the systems and devices being managed. Information on using SDT Connector for browser access to the console servers Management Console, Telnet/SSH access to the console server command line, and TCP/UDP connecting to hosts that are network connected to the console server can be found in Chapter 6 - Secure Tunneling
SDT Connector can be installed on Windows 2000, XP, 2003, Vista PCs and on most Linux, UNIX and Solaris. For full information on installing, configuring and using SDT Connector refer to the SDT Connector User Manual on the console server CD (or online at ftp://ftp.opengear.com/manual/ )
3.5.2 PuTTY Communications packages like PuTTY can be also used to connect to the Console server command line (and to connect serially attached devices as covered in Chapter 4). PuTTY is a freeware implementation of Telnet and SSH for Win32 and UNIX platforms. It runs as an executable application without needing to be installed onto your system. PuTTY (the Telnet and SSH client itself) can be downloaded at http://www.tucows.com/preview/195286.html
To use PuTTY for an SSH terminal session from a Windows client, you enter the console servers IP address as the Host Name (or IP address) To access the console server command line you select SSH as the protocol, and use the default IP Port 22 Click Open and you will be presented with the console server login prompt. (You may also receive a Security Alert that the hosts key is not cached, you will need to choose yes to continue.) Using the Telnet protocol is similarly simple - but you use the default port 23
3.5.3 SSHTerm Another common communications package that may be useful is SSHTerm, an open source package that can be downloaded from http://sourceforge.net/projects/sshtools
To use SSHTerm for an SSH terminal session from a Windows Client you simply Select the File option and click on New Connection. A new dialog box will appear for your Connection Profile where you can type in the host name or IP address (for the console server unit) and the TCP port that the SSH session will use (port 22). Then type in your username and choose password authentication and click connect.
You may receive a message about the host key fingerprint, and you will need to select yes or always to continue. The next step is password authentication and you will be prompted for your username and password from the remote system. You will then be logged on to the Console server
3.6 Management network configuration (IM42xx & IMG4xxx only) The IMG4xxx and IM42xx console servers have additional Ethernet network ports that can be configured as a management console server/ LAN port or as a failover/ OOB access port. 3.6.1 Enable the Management LAN The IMG4xxx and IM42xx provide a management LAN gateway with firewall, router and DHCP server. With an IM42xx you will need to connect an external LAN switch to Network 2 to attach hosts to the management LAN. Whereas the IMG4xxx has an integrated four or twenty four port management LAN switch (i.e. it provides a firewall, router, DHCP server and VLAN switch).
However these features are all disabled by default. To configure the Management LAN gateway: Select the Management LAN page on the System: IP menu and uncheck Disable Configure the IP Address and Subnet Mask for the Management LAN (leaving the Gateway and DNS fields blank) then click Apply
Console Server User Manual Page 39 of 261 Note The IMG4xxx can be configured with an active Management LAN/gateway and with one of the switched Ethernet ports configured for OOB/Failover (ETH 4 on the IMG4004-5 or ETH 24 on the IMG4216-25) With the IM42xx, the second Ethernet port can be configured as either a gateway port or it can be configured as an OOB/Failover port - but not both. So ensure you did not allocate Network 2 as the Failover Interface when you configured the IM42xxs principal Network connection on the System: IP menu
The management gateway function is now enabled with default firewall and router rules. These rules can be reconfigured at the command line. The IMG4xxx and IM42xx gateways also host a DHCP server, which by default is disabled.
3.6.2 Configure the Management LAN DHCP server The DHCP server enables the automatic distribution of IP addresses to hosts running DHCP clients on the Management LAN. To enable the DHCP server: On the System: IP menu select the Management LAN page and click the Disabled label in the DHCP Server field; or go to the System: DHCP Server menu and check Enable DHCP Server
To configure the DHCP server for the Management LAN: Enter the Gateway address that is to be issued to the DHCP clients. If this field is left blank, the IMG/IM4xxx units IP address will be used
Console Server User Manual Page 40 of 261 Enter the Primary DNS and Secondary DNS address to issue the DHCP clients. Again if this field is left blank, the IMG/IM4xxx units IP address is used, so leave this field blank for automatic DNS server assignment Optionally enter a Domain Name suffix to issue DHCP clients Enter the Default Lease time and Maximum Lease time in seconds. The lease time is the time that a dynamically assigned IP address is valid before the client must request it again Click Apply
The DHCP server will sequentially issue IP addresses from a specified address pool(s): Click Add in the Dynamic Address Allocation Pools field
Enter the DHCP Pool Start Address and End Address and click Apply
The DHCP server also supports pre-assigning IP addresses to be allocated only to specific MAC addresses and reserving IP addresses to be used by connected hosts with fixed IP addresses. To reserve an IP addresses for a particular host: Click Add in the Reserved Addresses field Enter the Hostname, the Hardware Address (MAC) and the Statically Reserved IP address for the DHCP client and click Apply When DHCP has initially allocated hosts addresses it is recommended to copy these into the pre- assigned list so the same IP address will be reallocated in the event of a reboot.
3.6.3 Select Failover or broadband OOB The IMG4xxx and IM42xx console servers provide a failover option so in the event of a problem using the main LAN connection for accessing the console server; an alternate access path is used. or By default the failover is not enabled. To enable, select the Network page on the System: IP menu Now select the Failover Interface to be used in the event of an outage on the main network. This can be:
Console Server User Manual Page 42 of 261 o an alternate broadband Ethernet connection (which would be the Network2 port on IM42xx, or Management LAN port 4 on the IMG4004-5 or Management LAN port 24 on the IMG4216-25) or o the IM/IMG42xx internal modem or o an external serial modem/ISDN device connected to the IM/IMG42xx Console port (for out-dialing to an ISP or the remote management office)
Click Apply. You have selected the failover method however it is not active until you have specified the external sites to be probed to trigger failover, and set up the failover ports themselves. This is covered in Chapter 5.
Note The IMG4xxx can be configured with an active Management LAN/gateway and with one of the switched Ethernet ports configured for OOB/Failover (Eth 4 on the IMG4004-5 or Eth 24 on the IMG4216-25). However with the IM42xx, the second Ethernet port can be configured as either a gateway port or as an OOB/Failover port, but not both. So ensure you did not enable the Management LAN function on Network 2
Chapter 4 Serial Port, Host and User Configuration
SERIAL PORT AND NETWORK HOST Introduction The Opengear console server enables access and control of serially-attached devices and network- attached devices (hosts). The Administrator must configure access privileges for each of these devices, and specify the services that can be used to control the devices. The Administrator can also set up new users and specify each users individual access and control privileges.
This chapter covers each of the steps in configuring hosts and serially attached devices: Configure Serial Ports setting up the protocols to be used in accessing serially-connected devices Users & Groups setting up users and defining the access permissions for each of these users Authentication covered in more detail in Chapter 9 Network Hosts configuring access to local network connected computers or appliances (referred to as hosts) Configuring Trusted Networks Cascading and Redirection of Serial Console Ports Connecting to Power (UPS PDU and IPMI) and Environmetal Monitoring (EMD) devices
4.1 Configuring Serial Ports To configure a serial port you must first set the Common Settings i.e. the protocols and the RS232 parameters that are to be used for the data connection to that port (e.g. baud rate).
Console Server User Manual Page 44 of 261 Then you must select what mode the port is to operate in. Each port can be set to support one of five operating modes: 1) Console Server Mode is the default and this enables general access to serial console port on the serially attached devices 2) Device Mode sets the serial port up to communicate with an intelligent serial controlled PDU, UPS or Environmental Monitor Devices (EMD) 3) SDT Mode enables graphical console access (with RDP, VNC, HTTPS etc) to hosts that are serially connected 4) Terminal Server Mode sets the serial port to await an incoming terminal login session 5) Serial Bridge Mode enables the transparent interconnection of two serial port devices over a network
Select Serial & Network: Serial Port and you will see the current labels, modes, logging levels and RS232 protocol options that are currently set up for each serial port By default each serial port is set in Console Server mode. For the port to be reconfigured click Edit When you have reconfigured the common settings (Chapter 4.1.1) and the mode (Chapters 4.1.2 - 4.1.6) for each port, you set up any remote syslog (Chapter 4.1.7), then click Apply Note If you wish to set the same protocol options for multiple serial ports at once click Edit Multiple Ports and select which ports you wish to configure as a group If the console server has been configured with distributed Nagios monitoring enabled then you will also be presented with Nagios Settings options to enable nominated services on the Host to be monitored (refer Chapter 10 Nagios Integration)
4.1.1 Common Settings There are a number of common settings that can be set for each serial port. These are independent of the mode in which the port is being used. These serial port parameters must be set so they match the serial port parameters on the device you attach to that port:
Specify a label for the port Select the appropriate Baud Rate, Parity, Data Bits, Stop Bits and Flow Control for each port. (Note that the RS485/RS422 option is not relevant for console servers) Before proceeding with further serial port configuration, you should connect the ports to the serial devices they will be controlling, and ensure they have matching settings Note The serial ports are all set at the factory to RS232 9600 baud, no parity, 8 data bits, 1 stop bit and Console Server Mode. The baud rate can be changed to 2400 230400 baud using the management console. Lower baud rates (50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800 baud) can be configured from the command line. Refer Chapter 14 Basic Configuration (Linux Commands)
4.1.2 Console Server Mode Select Console Server Mode to enable remote management access to the serial console that is attached to this serial port:
Console Server User Manual Page 46 of 261 Logging Level This specifies the level of information to be logged and monitored (refer Chapter 7 - Alerts and Logging) Telnet When the Telnet service is enabled on the console server, a Telnet client on a User or Administrators computer can connect to a serial device attached to this serial port on the console server. The Telnet communications are unencrypted so this protocol is generally recommended only for local connections. With Win2000/XP/NT you can run telnet from the command prompt (cmd.exe). Vista comes with a telnet client and server but they are not enabled by default. To enable telnet simply: Log in as Admin and go to Start/ Control Panel/Programs and Features Select Turn Windows features on or off, check the Telnet Client and click OK
If the remote communications are being tunneled with SDT Connector, then Telnet can be used for securely accessing these attached devices (refer Note below).
Note In Console Server mode, Users and Administrators can use SDT Connector to set up secure Telnet connections that are SSH tunneled from their client PC/workstations to the serial port on the console server. SDT Connector can be installed on Windows 2000, XP, 2003, Vista PCs and on most Linux platforms and it enables secure Telnet connections to be selected with a simple point-and-click. To use SDT Connector to access consoles on the console server serial ports, you configure SDT Connector with the console server as a gateway, then as a host, and you enable Telnet service on Port (2000 + serial port #) i.e. 20012048. Refer Chapter 6 for more details on using SDT Connector for Telnet and SSH access to devices that are attached to the console server serial ports. You can also use standard communications packages like PuTTY to set a direct Telnet (or SSH) connection to the serial ports (refer Note below): Note PuTTY also supports Telnet (and SSH) and the procedure to set up a Telnet session is simple. Enter the IM/CM4000 gateways IP address as the Host Name (or IP address). Select Telnet as the protocol and set the TCP port to 2000 plus the physical serial port number (i.e. 2001 to 2048).
Console Server User Manual Page 47 of 261 Click the Open button. You may then receive a Security Alert that the hosts key is not cached, you will need to choose yes to continue. You will then be presented with the login prompt of the remote system connected to the serial port chosen on the IM/CM4000 device. You can login as normal and use the host serial console screen.
PuTTY can be downloaded at http://www.tucows.com/preview/195286.html SSH It is recommended that you use SSH as the protocol where the User or Administrator connects to the console server (or connects through the console server to the attached serial consoles) over the Internet or any other public network. This will provide authenticated SSH communications between the SSH client program on the remote users computer and the console server, so the users communication with the serial device attached to the console server is secure For SSH access to the consoles on devices attached to the console server serial ports, you can use SDT Connector. You configure SDT Connector with the console server as a gateway, then as a host, and you enable SSH service on Port (3000 + serial port #) i.e. 3001-3048. Chapter 6 - Secure Tunneling has more information on using SDT Connector for SSH access to devices that are attached to the console server serial ports. Also you can use common communications packages, like PuTTY or SSHTerm to SSH connect directly to port address IP Address _ Port (3000 + serial port #) i.e. 30013048 Alternately SSH connections can be configured using the standard SSH port 22. The serial port being accessed is then identified by appending a descriptor to the username. This syntax supports any of: <username>:<portXX> <username>:<port label> <username>:<ttySX> <username>:<serial>
Console Server User Manual Page 48 of 261 So for a User named 'fred' to access serial port 2, when setting up the SSHTerm or the PuTTY SSH client, instead of typing username = fred and ssh port = 3002, the alternate is to type username = fred:port02 (or username = fred:ttyS1) and ssh port = 22. Or, by typing username=fred:serial and ssh port = 22, the User is presented with a port selection option:
This syntax enables Users to set up SSH tunnels to all serial ports with only a single IP port 22 having to be opened in their firewall/gateway TCP RAW TCP allows connections directly to a TCP socket. However while communications programs like PuTTY also supports RAW TCP, this protocol would usually be used by a custom application For RAW TCP, the default port address is IP Address _ Port (4000 + serial port #) i.e. 4001 4048 RAW TCP also enables the serial port to be tunneled to a remote console server, so two serial port devices can be transparently interconnect over a network (see Chapter 4.1.6 Serial Bridging) RFC2217 Selecting RFC2217 enables serial port redirection on that port. For RFC2217, the default port address is IP Address _ Port (5000 + serial port #) i.e. 5001 5048 Special client software is available for Windows UNIX and Linux that supports RFC2217 virtual com ports, so a remote host can monitor and manage remote serially attached devices, as though they were connected to the local serial port (see Chapter 4.6 Serial Port Redirection for details) RFC2217 also enables the serial port to be tunneled to a remote console server, so two serial port devices can be transparently interconnect over a network (see Chapter 4.1.6 Serial Bridging) Unauthenticated Telnet Selecting Unauthenticated Telnet enables telnet access to the serial port without requiring the user to provide credentials. When a user accesses the console server to telnet to a serial port they normally are given a login prompt. However with unauthenticated telnet they connect directly through to port with any console server login at all. This mode is mainly used when you have an external system (such as conserver) managing user authentication and access privileges at the serial device level. For Unauthenticated Telnet the default port address is IP Address _ Port (6000 + serial port #) i.e. 6001 6048
Console Server User Manual Page 49 of 261 Accumulation Period By default once a connection has been established for a particular serial port (such as a RFC2217 redirection or Telnet connection to a remote computer) then any incoming characters on that port are forwarded over the network on a character by character basis. The accumulation period changes this by specifying a period of time that incoming characters will be collected before then being sent as a packet over the network Escape Character This enables you to change the character used for sending escape characters. The default is ~. Single Connection This setting limits the port to a single connection so if multiple users have access privileges for a particular port only one user at a time can be accessing that port (i.e. port snooping is not permitted)
4.1.3 SDT Mode This Secure Tunneling setting allows port forwarding of RDP, VNC, HTPP, HTTPS, SSH, Telnet and other LAN protocols through to computers which are locally connected to the console server by their serial COM port. However such port forwarding requires a PPP link to be set up over this serial port.
Refer to Chapter 6.6 - Using SDT Connector to Telnet or SSH connect to devices that are serially attached to the console server for configuration details
4.1.4 Device (RPC, UPS, EMD) Mode This mode configures the selected serial port to communicate with a serial controlled Uninterruptable Power Supply (UPS), Remote Power Controller/ Power Distribution Units (RPC) or Environmental Monitoring Device (EMD)
Select the desired Device Type (UPS, RPC or EMD) Proceed to the appropriate device configuration page (Serial & Network: UPS Connections, RPC Connection or Environmental) as detailed in Chapter 8 - Power & Environmental Management)
4.1.5 Terminal Server Mode Select Terminal Server Mode and the Terminal Type (vt220, vt102, vt100, Linux or ANSI) to enable a getty on the selected serial port
The getty will then configure the port and wait for a connection to be made. An active connection on a serial device is usually indicated by the Data Carrier Detect (DCD) pin on the serial device being raised. When a connection is detected, the getty program issues a login: prompt, and then invokes the login program to handle the actual system login. Note Selecting Terminal Server mode will disable Port Manager for that serial port, so data is no longer logged for alerts etc.
4.1.6 Serial Bridging Mode With serial bridging, the serial data on a nominated serial port on one console server is encapsulated into network packets and then transported over a network to a second console server where is then represented as serial data. So the two console servers effectively act as a virtual serial cable over an IP network. One console server is configured to be the Server. The Server serial port to be bridged is set in Console Server mode with either RFC2217 or RAW enabled (as described in Chapter 4.1.2 Console Server Mode). For the Client console server, the serial port to be bridged must be set in Bridging Mode:
Select Serial Bridging Mode and specify the IP address of the Server console server and the TCP port address of the remote serial port (for RFC2217 bridging this will be 5001-5048)
Console Server User Manual Page 51 of 261 By default the bridging client will use RAW TCP so you must select RFC2217 if this is the console server mode you have specified on the server console server
You may secure the communications over the local Ethernet by enabling SSH however you will need to generate and upload keys (refer Chapter 14 Advanced Configuration)
4.1.8 Syslog In addition to inbuilt logging and monitoring (which can be applied to serial-attached and network- attached management accesses, as covered in Chapter 7 - Alerts and Logging) the console server can also be configured to support the remote syslog protocol on a per serial port basis: Select the Syslog Facility/Priority fields to enable logging of traffic on the selected serial port to a syslog server; and to appropriately sort and action those logged messages (i.e. redirect them/ send alert email etc.)
For example if the computer attached to serial port 3 should never send anything out on its serial console port, the Administrator can set the Facility for that port to local0 (local0 .. local7 are meant for site local values), and the Priority to critical. At this priority, if the console server syslog server does receive a message, it will automatically raise an alert. Refer to Chapter 7 - Alerts & Logging.
4.2 Add/ Edit Users The Administrator uses this menu selection to set up, edit and delete users and to define the access permissions for each of these users.
Users can be authorized to access specified console server serial ports and specified network-attached hosts. These users can also be given full Administrator status (with full configuration and management and access privileges). To simplify user set up, they can be configured as members of Groups. There are two Groups set up by default (admin and user) 1. Membership of the admin group provides the user with full Administrator privileges. The admin user (Administrator) can access the console server using any of the services which have been enabled in System: Services e.g. if only HTTPS has been enabled then the Administrator can only access the console server using HTTPS. However once logged in they can reconfigure the console server settings (e.g. to enabled HTTP/Telnet for future access). They can also access any of the connected Hosts or serial port devices using any of the services that have been enabled for these connections. But again the Administrator can reconfigure the access services for any Host or serial port. So only trusted users should have Administrator access. Note: For convenience the SDT Connector Retrieve Hosts function retrieves and auto-configures checked serial ports and checked hosts only, even for admin group users
2. Membership of the user group provides the user with limited access to the console server and connected Hosts and serial devices. These Users can access only the Management section of the Management Console menu and they have no command line access to the console server. They also can only access those Hosts and serial devices that have been checked for them, using services that have been enabled. 3. The Administrator can also set up additional Groups with specific serial port and host access permissions (same as Users). However users in these additional groups dont have any access to the Management Console menu nor any command line access to the console server itself. Lastly the Administrator can also set up users who are not a member of any Groups and they will have the same access as users in the additional groups. To set up new users and classify them as members of particular Groups: Select Serial & Network: Users & Groups to display the configured Groups and Users Click Add Group to add a new Group
Add a Group name and Description for each new Group, then nominate Accessible Hosts and Accessible Ports to specify the serial ports and hosts you wish any users in this new Group to be able to access Click Apply Select Serial & Network: Users to display the configured users Click Add User to add a new user
Add a Username and a confirmed Password for each new User. You may also include information related to the user (e.g. contact details) in the Description field Nominate Accessible Hosts and Accessible Ports to specify which serial ports and which LAN connected hosts you wish the user to have access to Specify which Group (or Groups) you wish the user to be a member of. Click Apply
Console Server User Manual Page 54 of 261 Your new user will now be able to access the nominated network devices and the devices attached to the nominated serial ports. Note There are no specific limits on the number of users you can set up; nor on the number of users per serial port or host. So multiple users (Users and Administrators) can control /monitor the one port or host. Similarly there are no specific limits on the number of Groups and each user can be a member of a number of Groups (in which case they take on the cumulative access privileges of each of those Groups). A user does not have to be a member of any Groups (but if the User is not even a member of the default user group then they will not be able to use the Management Console to manage ports).
Note that while there are no specific limits the time to re-configure does increase as the number and complexity increases so we recommend the aggregate number if users and groups be kept under 250 (or 1000 for KCS)
The Administrator can also edit the access settings for any existing users: Select Serial & Network: Users & Groups and click Edit for the User to be modified Note: For more information on enabling the SDT Connector so each user has secure tunneled remote RPD/VNC/Telnet/HHTP/HTTPS/SoL access to the network connected hosts refer Chapter 6.
4.3 Authentication Refer to Chapter 9.1 - Remote Authentication Configuration for authentication configuration details
4.4 Network Hosts To access a locally networked computer or appliances (referred to as a Host) you must identify the network connected Host; and then specify the TCP or UDP ports/services that will be used to control that Host:
Selecting Serial & Network: Network Hosts presents all the network connected Hosts that have been enabled for access, and the related access TCP ports/services
Console Server User Manual Page 55 of 261 Click Add Host to enable access to a new Host (or select Edit to update the settings for existing Host)
Enter the IP Address or DNS Name of the new network connected Host (and optionally enter a Description) Add or edit the Permitted Services (or TCP/UDP port numbers) that are authorized to be used in controlling this host. Only these permitted services will be forwarded through by SDT to the Host. All other services (TCP/UDP ports) will be blocked. If the console server has been configured with distributed Nagios monitoring enabled then you will also be presented with Nagios Settings options to enable nominated services on the Host to be monitored (refer Chapter 10 Nagios Integration) The Logging Level specifies the level of information to be logged and monitored for each Host access (refer Chapter 7 - Alerts and Logging) If the Host is a networked server with IPMI power control, then the Administrator can enable users (Users and Administrators) to remotely cycle power and reboot (refer Chapter 8.2 - Configuring IPMI Power Management) Click Apply
4.5 Trusted Networks The Trusted Networks facility gives you an option to nominate specific IP addresses that users (Administrators and Users) must be located at, to have access to console server serial ports:
Select Serial & Network: Trusted Networks To add a new trusted network, select Add Rule
Select the Accessible Port(s) that the new rule is to be applied to Then enter the Network Address of the subnet to be permitted access Then specify the range of addresses that are to be permitted by entering a Network Mask for that permitted IP range e.g. To permit all the users located with a particular Class C network (204.15.5.0 say) connection to the nominated port then you would add the following Trusted Network New Rule: Network IP Address 204.15.5.0 Subnet Mask 255.255.255.0 If you want to permit only the one users who is located at a specific IP address (204.15.5.13 say) to connect: Network IP Address 204.15.5.0 Subnet Mask 255.255.255.255 If however you want to allow all the users operating from within a specific range of IP addresses (say any of the thirty addresses from 204.15.5.129 to 204.15.5.158) to be permitted connection to the nominated port:
Console Server User Manual Page 57 of 261 Host /Subnet Address 204.15.5.128 Subnet Mask 255.255.255.224 Click Apply Note The above Trusted Networks will limit access by Users and the Administrator to the console serial ports. However they do not restrict access by the Administrator to the console server itself or to attached hosts. To change the default settings for this access, you will to need to edit the IPtables rules as described in the Chapter 14 - Advanced.
4.6 Serial Port Cascading Cascaded Ports enables you to cluster distributed console servers so a large number of serial ports (up to 1000) can be configured and accessed through one IP address and managed through the one Management Console. One console server, the Master, controls other console servers as Slave units and all the serial ports on the Slave units appear as if they are part of the Master. Opengears clustering connects each Slave to the Master with an SSH connection. This is done using public key authentication so the Master can access each Slave using the SSH key pair (rather than using passwords). This ensures secure authenticated communications between Master and Slaves enabling the Slave console server units to be distributed locally on a LAN or remotely around the world.
4.6.1 Automatically generate and upload SSH keys To set up public key authentication you must first generate an RSA or DSA key pair and upload them into the Master and Slave console servers. This can all be done automatically from the Master :
Select System: Administration on Masters Management Console Check Generate SSH keys automatically and click Apply
Next you must select whether to generate keys using RSA and/or DSA (if unsure, select only RSA). Generating each set of keys will require approximately two minutes and the new keys will destroy any old keys of that type that may previously been uploaded. Also while the new generation is underway on the master functions relying on SSH keys (e.g. cascading) may stop functioning until they are updated with the new set of keys. To generate keys: Select RSA Keys and/or DSA Keys Click Apply
Once the new keys have been successfully generated simply Click here to return and the keys will automatically be uploaded to the Master and connected Salves 4.6.2 Manually generate and upload SSH keys Alternately if you have a RSA or DSA key pair you can manually upload them to the Master and Slave console servers. Note If you do not already have RSA or DSA key pair and you do not wish to use you will need to create a key pair using ssh-keygen, PuTTYgen or a similar tool as detailed in Chapter 15.6 To manually upload the key public and private key pair to the Master console server: Select System: Administration on Masters Management Console Browse to the location you have stored RSA (or DSA) Public Key and upload it to SSH RSA (DSA) Public Key Browse to the stored RSA (or DSA) Private Key and upload it to SSH RSA (DSA) Private Key Click Apply
Next, you must register the Public Key as an Authorized Key on the Slave. In the simple case with only one Master with multiple Slaves, you need only upload the one RSA or DSA public key for each Slave.
Console Server User Manual Page 60 of 261 Note The use of key pairs can be confusing as in many cases one file (Public Key) fulfills two roles Public Key and Authorized Key. For a more detailed explanation refer the Authorized Keys section of Chapter 15.6. Also refer to this chapter if you need to use more than one set of Authorized Keys in the Slave Select System: Administration on the Slaves Management Console Browse again to the stored RSA (or DSA) Public Key and upload it to Salves SSH Authorized Key Click Apply The next step is to Fingerprint each new Slave-Master connection. This once-off step will validate that you are establishing an SSH session to who you think you are. On the first connection the Slave will receive a fingerprint from the Master which will be used on all future connections.: To establish the fingerprint first log in the Master server as root and establish an SSH connection to the Slave remote host: # ssh remhost Once the SSH connection has been established you will be asked to accept the key. Answer yes and the fingerprint will be added to the list of known hosts. For more details on Fingerprinting refer Chapter 15.6 If you are asked to supply a password, then there has been a problem with uploading keys. The keys should remove any need to supply a password 4.6.3 Configure the slaves and their serial ports You can now begin setting up the Slaves and configuring Slave serial ports from the Master console server:
Select Serial & Network: Cascaded Ports on the Masters Management Console: To add clustering support select Add Slave Note You will be prevented from adding any Slaves until you have automatically or manually generated SSH keys:
Console Server User Manual Page 61 of 261 To define and configure a Slave: Enter the remote IP Address (or DNS Name) for the Slave console server Enter a brief Description and a short Label for the Slave (use a convention here that enables effective management of large networks of clustered console servers and the connected devices) Enter the full number of serial ports on the Slave unit in Number of Ports Click Apply. This will establish the SSH tunnel between the Master and the new Slave
The Serial & Network: Cascaded Ports menu displays all the Salves and the port numbers that have been allocated on the Master. If the Master console server has 16 ports of its own then ports 1-16 are pre- allocated to the Master, so the first Slave added will be assigned port number 17 onwards. Once you have added all the Slave console servers, the Slave serial ports and the connected devices are configurable and accessible from the Masters Management Console menu; and accessible through the Masters IP address e.g. Select the appropriate Serial & Network: Serial Port and Edit to configure the serial ports on the Slave
Select the appropriate Serial & Network: Users & Groups to add new users with access privileges to the Slave serial ports (or to extend existing users access privileges) Select the appropriate Serial & Network: Trusted Networks to specify network addresses that can access nominated Slave serial ports Select the appropriate Alerts & Logging: Alerts to configure Slave port Connection, State Change or Pattern Match alerts
Console Server User Manual Page 62 of 261 All such configuration changes made on the Master are propagated out to all the Slaves. So whenever you change any User privileges or edit any serial port setting on the Master the updated configuration files will be sent out to each Slave in parallel. The Slaves will then make appropriate changes to their local configurations (i.e. only make those changes that relate to its particular serial ports). The Master is in control. You can still change all the settings on any Slave serial port (such as alter the baud rates) using the local Slave Management Console. However these changes will be overwritten next time the Master sends out a configuration file update. Also while the Master is in control of all Slave serial port related functions, it is not master over the Slave network host connections or over the Slave console server system itself. So Slave functions such as IP, SMTP & SNMP Settings, Date &Time, DHCP server must be managed by accessing each Salve directly and these functions are not over written when configuration changes are propagated from the Master. Similarly the Slaves Network Host and IPMI settings have to be configured at each Slave.
4.7 Serial Port Redirection Client To access the virtual serial ports that RFC2217 support, you need to run client software (to actually redirect local serial ports to remote console server serial ports). For Windows, Opengear recommends the Serial/IP COM Port Redirector from Tactical Software, which creates virtual COM ports for applications to use serial device servers without software changes. Tactical Software provides a trial copy of its products http://www.tacticalsoftware.com/products/serialip.htm
For Linux, AIX, HPUX, SCO, Solaris and UnixWare, Opengear has released an open source opengear- serial-client utility, which can be freely downloaded. This serial port redirector software is loaded in your desktop PC, and it allows you to use a serial device connected to the remote console server as if it were connected to your local serial port. opengear-serial- client creates a pseudo tty port, connects the serial application to the pseudo tty port, receives data from the pseudo tty port, transmits it to the console server through network and receives data from the console server through network and transmits it to the pseudo-tty port.
FAILOVER AND OoB DIAL-IN Introduction The console server has a number of fail-over and out-of-band access capabilities to ensure high availability - If there are difficulties in accessing the console server through the principal network path, the Administrator can access the console server out-of-band (OoB) from a remote location using dial- up modem or ISDN connection - The IM42xx and IMG4xxx can also be accessed out-of-band (OoB) using an alternate broadband link - IM42xx and IMG4xxx console servers also offer broadband failover, so in the event of a disruption to the principal management network connection, access is switched transparently to the standby network connection - The IM42xx and IMG4xxx can also be configured for out-dial failover, so in the event of a disruption in the principal management network, an external dial up ppp connection is established
5.1 OoB Dial-In access To enable OoB dial-in access, you first configure the Console server (and once set up for dial-in PPP access, the console server will await an incoming connection from a dial-in at remote site). Then set up the remote client dial-in software so it can establish a network connection from the Administrators client modem to the dial in modem on the console server.
Console Server User Manual Page 64 of 261 Note The IM42xx units are all supplied with an internal modem and a DB9 Local/Console port for OoB access. With the IM42xx units, an external modem can still be attached via a serial cable to the DB9 port, and the second Ethernet port can be configured for broadband OoB access. The IMG4216-25 has an internal modem as an option and supports broadband and external serial OoB access as above. The IMG4004-5 has the same OoB access facilities plus its supports PC card modems and wireless devices. The CM4xxx and KCS6116 units need to have an external modem attached via a serial cable to their DB9 port. This port is marked Local and is located on the back of the CM4001/4008 and KCS6116 units, and the front of the CM4116/4148 unit. The KCS6104 has four serial ports which by default are all configured as RJ Serial Console Ports 1-4 however Port 1 is also presented as the Modem port on the DB-9 connector.
5.1.1 Configure Dial-In PPP To enable dial-in PPP access on the console server console/modem port, or the IM42xx internal modem:
Select the System: Dial menu option and the port to be configured (Serial DB9 Port or Internal Modem Port) Note The console server console/modem serial port is set by default to 115200 baud, No parity, 8 data bits and 1 stop bit, with software (Xon-Xoff) flow control enabled. When enabling OoB dial-in on CM4000 units it is recommended that this be changed to 38,4000 baud with Hardware Flow Control Select the Baud Rate and Flow Control that will communicate with the modem Note You can further configure the console/modem port (e.g. to include modem init strings) by editing /etc/mgetty.config files as described in the Chapter 14 - Advanced. Check the Enable Dial-In Access box Enter the User name and Password to be used for the dial-in PPP link In the Remote Address field, enter the IP address to be assigned to the dial-in client. You can select any address for the Remote IP Address. However it, and the Local IP Address, must both be in the same network range (e.g. 200.100.1.12 and 200.100.1.67)
Console Server User Manual Page 65 of 261 In the Local Address field enter the IP address for the Dial-In PPP Server. This is the IP address that will be used by the remote client to access console server once the modem connection is established. Again you can select any address for the Local IP Address but it must both be in the same network range as the Remote IP Address The Default Route option enables the dialed PPP connection to become the default route for the Console server The Custom Modem Initialization option allows a custom AT string modem initialization string to be entered (e.g. AT&C1&D3&K3)
Then you must select the Authentication Type to be applied to the dial-in connection. The console server uses authentication to challenge Administrators who dial-in to the console server. (For dial-in access, the username and password received from the dial-in client are verified against the local authentication database stored on the console server). The Administrator must also have their client PC / workstation configured to use the selected authentication scheme. Select PAP CHAP MSCHAPv2 or None and click Apply None With this selection, no username or password authentication is required for dial-in access. This is not recommended. PAP Password Authentication Protocol (PAP) is the usual method of user authentication used on the internet: sending a username and password to a server where they are compared with a table of authorized users. Whilst most common, PAP is the least secure of the authentication options.
Console Server User Manual Page 66 of 261 CHAP Challenge-Handshake Authentication Protocol (CHAP) is used to verify a user's name and password for PPP Internet connections. It is more secure than PAP, the other main authentication protocol. MSCHAPv2 Microsoft Challenge Handshake Authentication Protocol (MSCHAP) is authentication for PPP connections between a computer using a Microsoft Windows operating system and a network access server. It is more secure than PAP or CHAP, and is the only option that also supports data encryption Console servers all support dial-back for additional security. Check the Enable Dial-Back box and enter the phone number to be called to re-establish an OoB link once a dial-in connection has been logged Note Chapter 13 (Advanced Configurations) has examples of Linux commands that can be used to control the modem port operation at the command line level
5.1.2 Using SDT Connector client Administrators can use their SDT Connector client to set up secure OoB dial-in access to remote Console servers. The SDT Connector Java client software provides point-and-click secure remote access. OoB access uses an alternate path for connecting to the console server to that used for regular data traffic. Starting an OoB connection in SDT Connector may be achieved by initiating a dial up connection, or adding an alternate route to the console server. SDT Connector allows for maximum flexibility is this regard, by allowing you to provide your own scripts or commands for starting and stopping the OoB connection. Refer Chapter 6.5
5.1.3 Set up Windows XP/ 2003/Vista client Open Network Connections in Control Panel and click the New Connection Wizard
Select Connect to the Internet and click Next On the Getting Ready screen select Set up my connection manually and click Next
Console Server User Manual Page 67 of 261 On the Internet Connection screen select Connect using a dial-up modem and click Next Enter a Connection Name (any name you choose) and the dial-up Phone number that will connect thru to the console server modem
Enter the PPP User name and Password for have set up for the console server
5.1.4 Set up earlier Windows clients For Windows 2000, the PPP client set up procedure is the same as above, except you get to the Dial-Up Networking Folder by clicking the Start button and selecting Settings. Then click Network and Dial-up Connections and click Make New Connection Similarly for Windows 98 you double click My Computer on the Desktop, then open Dial-Up Networking and double click Make New Connection and proceed as above
5.1.5 Set up Linux clients The online tutorial http://www.yolinux.com/TUTORIALS/LinuxTutorialPPP.html presents a selection of methods for establishing a dial up PPP connection: - Command line PPP and manual configuration (which works with any Linux distribution) - Using the Linuxconf configuration tool (for Red Hat compatible distributions). This configures the scripts ifup/ifdown to start and stop a PPP connection - Using the Gnome control panel configuration tool - - WVDIAL and the Redhat "Dialup configuration tool" - GUI dial program X-isp. Download/Installation/Configuration Note For all PPP clients: Set the PPP link up with TCP/IP as the only protocol enabled Specify that the Server will assign IP address and do DNS Do not set up the console server PPP link as the default for Internet connection
5.2 OoB broadband access (IMG4xxx and IM42xx only)
Console Server User Manual Page 68 of 261 IMG/IM console servers have a second Ethernet port (Network 2 on the IM42xx; Management LAN port 4 on the IMG4004-5; or Management LAN port 24 on the IMG4216-25) that can be configured for alternate and OoB (out-of-band) broadband access. With two active broadband access paths to the IM/IMG console server, in the event you are unable to access through the primary management network (Network or Network1) you can still access it through the alternate broadband path (e.g. a T1 link):
On the System: IP menu select Network 2 (IM42xx) or Out of Band/ Failover ( IMG4xxx) and configure the IP Address, Subnet Mask, Gateway and DNS with the access settings that relate to the alternate link Ensure when configuring the principal Network 1 Settings (eth0) connection, the Failover Interface is set to None
5.3 Broadband Ethernet Failover (IMG4xxx and IM42xx only) The second IM42XX Ethernet can also be configured for failover to ensure transparent high availability.
Console Server User Manual Page 69 of 261 When configuring the principal network connection, specify Management LAN/ Network 2 (eth1) as the Failover Interface to be used when a fault has been detected with Network 1 (eth0) Specify the Probe Addresses of two sites (the Primary and Secondary) that the IMG/IM is to ping to determine if Network 1 (eth0) is still operational
Then configure Management LAN Interface (Network 2 / eth1) with the same IP setting that you used for Network Interface (Network 1 / eth0) to ensure transparent redundancy
In this mode, Network 2 (eth1) is available as the transparent back-up port to Network 1 (eth0) for accessing the management network. Network 2 will automatically and transparently take over the work of Network 1, in the event Network 1 becomes unavailable for any reason. And when Network 1 becomes available again, it takes over the work again.
5.4 Dial-Out Failover (IMG4xxx and IM42xx only) IMG/IM console servers can be configured so a dial-out PPP connection is automatically set up in the event of a disruption in the principal management network:
Console Server User Manual Page 70 of 261 When configuring the principal network connection in System: IP, specify Internal Modem (or the Dial Serial DB9 if you are using an external modem on the Console port) as the Failover Interface to be used when a fault has been detected with Network / Network1 (eth0) Specify the Probe Addresses of two sites (the Primary and Secondary) that the IMG/IM console server is to ping to determine if Network / Network1 is still operational Select the System: Dial menu option and the port to be configured (Serial DB9 Port or Internal Modem Port) Select the Baud Rate and Flow Control that will communicate with the modem Note You can further configure the console/modem port (e.g. to include modem init strings) by editing /etc/mgetty.config files as described in the Chapter 13 - Advanced. Check the Enable Dial-Out Access box and enter the access details for the remote PPP server to be called
SECURE TUNNELING AND SDT CONNECTOR Introduction Each Opengear console server has an embedded SSH server and uses SSH tunneling so the one console server can securely manage all the systems and network devices in the data center - using text-based console tools (such as SSH, telnet, SoL) or graphical desktop tools (VNC, RDP, HTTPS, HTTP, X11, VMWare, DRAC, iLO etc). To set up Secure Tunnel access, the computer being accessed can be located on the same local network as the console server, or attached to the console server via its serial COM port. The remote User/Administrator then connects to the console server thru an SSH tunnel via dial-up, wireless or ISDN modem; a broadband Internet connection; the enterprise VPN network or the local network - To set up the secure SSH tunnel from the Client PC to the console server, you must install and launch SSH client software on the User/Administrators PC. Opengear recommends you use the SDT Connector client software that is supplied with the console server for this. SDT Connector is simple to install and auto-configure and it will provides all your users with point-and-click access to all the systems and devices in the secure network. With one click SDT Connector sets up a secure SSH tunnel from the client to the selected console server, then establishes a port forward connection to the target network connected host or serial connected device, then executes the client application that will be used in communicating with the host. This chapter details the basic SDT Connector operations: Configuring the console server for SSH tunneled access to network attached hosts and setting up permitted Services and Users access (Section 6.1) Setting up the SDT Connector client with gateway, host, service and client application details and making connections between the Client PC and hosts connected to the console server (Section 6.2)
Console Server User Manual Page 72 of 261 Using SDT Connector to browser access the Management Console (Section 6.3) Using SDT Connector to Telnet or SSH connect to devices that are serially attached to the console server (Section 6.4) The chapter then covers more advanced SDT Connector and SDT tunneling topics: Using SDT Connector for out of band access(Section 6.5) Automatic importing and exporting of configurations (Section 6.6) Configuring Public Key Authentication (Section 6.7) Setting up a SDT Secure Tunnel for Remote Desktop (Section 6.8) Setting up a SDT Secure Tunnel for VNC (Section 6.9) Using SDT to IP connect to hosts that are serially attached to the console server (Section 6.10)
6.1 Configuring for SDT Tunneling to Hosts To set up the Console server to SDT access a network attached host, the host and the permitted services that are to be used in accessing that host need to be configured on the gateway, and User access privileges need to specified: Add the new host and the permitted services using the Serial & Network: Network Hosts menu as detailed in Network Hosts (Chapter 4.4). Only these permitted services will be forwarded through by SDT to the host. All other services (TCP/UDP ports) will be blocked. Note Following are some of the TCP Ports used by SDT in the console server: 22 SSH (All SDT Tunneled connections) 23 Telnet on local LAN (forwarded inside tunnel) 80 HTTP on local LAN (forwarded inside tunnel) 3389 RDP on local LAN (forwarded inside tunnel) 5900 VNC on local LAN (forwarded inside tunnel) 73XX RDP over serial from local LAN where XX is the serial port number (i.e. 7301to 7348 on CM4148) 79XX VNC over serial from local LAN where XX is the serial port number
Add the new Users using Serial & Network: Users & Groups menu as detailed in Network Hosts (Chapter 4.4). Users can be authorized to access the console server ports and specified network-attached hosts. To simplify configuration, the Administrator can first set up Groups with group access permissions, then Users can be classified as members of particular Groups.
6.2 SDT Connector Configuration The SDT Connector client works with all Opengear console servers. Each of these remote console servers have an embedded OpenSSH based server which can be configured to port forward connections from the SDT Connector client to hosts on their local network as detailed in the previous chapter. The SDT Connector can also be pre-configured with the access tools and applications that will be available to be run when access to a particular host has been established.
SDT Connector can connect to the console server using an alternate OoB access, and can also be configured to access the console server itself and to access devices connected to serial ports on the console server. 6.2.1 SDT Connector client installation The SDT Connector set up program (SDTConnector Setup-1.n.exe or sdtcon-1.n.tar.gz) is included on the CD supplied with your Opengear console server product (or a copy can be freely download rom Opengears website) Run the set-up program:
Note For Windows clients, the SDTConnectorSetup-1.n.exe application will install the SDT Connector 1.n.exe and the config file defaults.xml. If there is already a config file on the Windows PC then it will not be overwritten. To remove earlier config file run the regedit command and search for SDT Connector then remove the directory with this name. For Linux and other Unix clients, SDTConnector.tar.gz application will install the sdtcon-1.n.jar and the config file defaults.xml Once the installer completes, you will have a working SDT Connector client installed on your machine and an icon on your desktop:
Click the SDT Connector icon on your desktop to start the client Note SDT Connector is a Java application so it must have a Java Runtime Environment (JRE) installed. This can be freely downloaded from http://java.sun.com/j2se/ It will install on Windows 2000, XP, 2003, Vista PCs and on most Linux platforms. Solaris platforms are also supported however they must have Firefox installed. SDT Connector can run on any system with Java 1.4.2 and above installed, but it assumes the web browser is Firefox, and that xterm -e telnet opens a telnet window To operate SDT Connector, you first need to add new gateways to the client software by entering the access details for each console server (refer Section 6.2.2) then let the client auto-configure with all host
Console Server User Manual Page 74 of 261 and serial port connections from each console server (refer Section 6.2.3) then point-and-click to connect to the Hosts and serial devices(refer Section 6.2.4) Alternately you can manually add network connected hosts (refer Section 6.2.5) and manually configure new services to be used in accessing the console server and the hosts (refer Section 6.2.6) then manually configuring clients to run on the PC that will use the service to connect to the hosts and serial port devices (refer Section 6.2.7 and 6.2.9). SDT Connector can also be set up to make an out-of-band connection to the console server (refer Section 6.2.9)
6.2.2 Configuring a new gateway in the SDT Connector client To create a secure SSH tunnel to a new console server: Click the New Gateway icon or select the File: New Gateway menu option
Enter the IP or DNS Address of the console server and the SSH port that will be used (typically 22) Note If SDT Connector is connecting to a remote console server through the public Internet or routed network you will need to: Determine the public IP address of the console server (or of the router/ firewall that connects the console server to the Internet) as assigned by the ISP. One way to find the public IP address is to access http://checkip.dyndns.org/ or http://www.whatismyip.com/ from a computer on the same network as the console server and note the reported IP address Set port forwarding for TCP port 22 through any firewall/NAT/router that is located between SDT Connector and the console server so it points to the console server. http://www.portforward.com has port forwarding instructions for a range of routers. Also you can use the Open Port Check tool from http://www.canyouseeme.org to check if port forwarding through local firewall/NAT/router devices has been properly configured
Enter the Username and Password of a user on the gateway that has been enabled to connect via SSH and/or create SSH port redirections
Optionally, enter a Descriptive Name to display instead of the IP or DNS address, and any Notes or a Description of this gateway (such as its firmware version, site location or anything special about its network configuration). Click OK and an icon for the new gateway will now appear in the SDT Connector home page Note For an SDT Connector user to access a console server (and then access specific hosts or serial devices connected to that console server), that user must first be setup on the console server, and must be authorized to access the specific ports / hosts (refer Chapter 5) and only these permitted services will be forwarded through by SDT to the Host. All other services (TCP/UDP ports) will be blocked.
6.2.3 Auto-configure SDT Connector client with the users access privileges Each user on the console server has an access profile which has been configured with those specific connected hosts and serial port devices the user has authority to access, and a specific set of the enabled services for each of these. This configuration can be auto-uploaded into the SDT Connector client:
Click on the new gateway icon and select Retrieve Hosts. This will:
Console Server User Manual Page 76 of 261 configure access to network connected Hosts that the user is authorized to access and set up (for each of these Hosts) the services (e.g. HTTPS, IPMI2.0) and the related IP ports being redirected configure access to the console server itself (this is shown as a Local Services host) configure access with the enabled services for the serial port devices connected to the console server
Note The Retrieve Hosts function will auto-configure all classes of user (i.e. they can be members of user or admin or some other group or no group) however SDT Connector will not auto- configure the root (and it recommended that this account is only used for initial config and for adding an initial admin account to the console server)
6.2.4 Make an SDT connection through the gateway to a host Simply point at the host to be accessed and click on the service to be used in accessing that host. The SSH tunnel to the gateway is then automatically established, the appropriate ports redirected through to the host, and the appropriate local client application is launched pointing at the local endpoint of the redirection:
Console Server User Manual Page 77 of 261 Note The SDT Connector client can be configured with unlimited number of Gateways. Each Gateway can be configured to port forward to an unlimited number of locally networked Hosts. Similarly there is no limit on the number of SDT Connector clients who can be configured to access the one Gateway. Nor are there limits on the number of Host connections that an SDT Connector client can concurrently have open through the one Gateway tunnel. However there is a limit on the number of SDT Connector SSH tunnels that can be open at the one time on a particular Gateway. SD4002/4008 and CM4001/4008 devices support at least 10 simultaneous client tunnels; IM4216/4248 and CM4116/4148 each support at least 50 such concurrent connections. So for a site with a CM4116 gateway you can have, at any time up to 50 users securely controlling an unlimited number of network attached computers and appliances (servers, routers etc) at that site.
6.2.5 Manually adding hosts to the SDT Connector gateway For each gateway, you can manually specify the network connected hosts that will be accessed through that console server; and for each host, specify the services that will used in communicating with the host Select the newly added gateway and click the Host icon to create a host that will be accessible via this gateway. (Alternatively select File: New Host)
Enter the IP or DNS Host Address of the host (if this is a DNS address, it must be resolvable by the gateway) Select which Services are to be used in accessing the new host. A range of service options are pre-configured in the default SDT Connector client (RDP, VNC, HTTP, HTTPS, Dell RAC, VMWare etc). However if you wish to add new services the range then proceed to the next section (Adding a new service) then return here Optionally, enter a Descriptive Name for the host, to display instead of the IP or DNS address, and any Notes or a Description of this host (such as its operating system/release, or anything special about its configuration) Click OK
6.2.6 Manually adding new services to the new hosts To extend the range of services that can be used when accessing hosts with SDT Connector: Select Edit: Preferences and click the Services tab. Click Add Enter a Service Name and click Add Under the General tab, enter the TCP Port that this service runs on (e.g. 80 for HTTP). Optionally, select the client to use to access the local endpoint of the redirection
Select which Client application is associated with the new service. A range of client application options are pre-configured in the default SDT Connector (RDP client, VNC client, HTTP browser, HTTPS browser, Telnet client etc). However if you wish to add new client applications to this range then proceed to the next section (Adding a new client) then return here
Click OK, then Close A service typically consists of a single SSH port redirection and a local client to access it. However it may consist of several redirections; some or all of which may have clients associated with them. An example is the Dell RAC service. The first redirection is for the HTTPS connection to the RAC server - it has a client associated with it (web browser) that is launched immediately upon clicking the button for this service.
Console Server User Manual Page 79 of 261 The second redirection is for the VNC service that the user may choose to later launch from the RAC web console. It is automatically loads in a Java client served through the web browser, so it does not need a local client associated with it.
On the Add Service screen you can click Add as many times as needed to add multiple new port redirections and associated clients You may also specify Advanced port redirection options: Enter the local address to bind to when creating the local endpoint of the redirection. It is not usually necessary to change this from "localhost". Enter a local TCP port to bind to when creating the local endpoint of the redirection. If this is left blank, a random port will be selected.
Note SDT Connector can also tunnel UDP services. SDT Connector tunnels the UDP traffic through the TCP SSH redirection, so in effect it is a tunnel within a tunnel.
Console Server User Manual Page 80 of 261 Enter the UDP port on which the service is running on the host. This will also be the local UDP port that SDT Connector binds as the local endpoint of the tunnel. Note that for UDP services, you still need to specify a TCP port under General. This will be an arbitrary TCP port that is not in use on the gateway. An example of this is the SOL Proxy service. It redirects local UDP port 623 to remote UDP port 623 over the arbitrary TCP port 6667
6.2.7 Adding a client program to be started for the new service Clients are local applications that may be launched when a related service is clicked. To add to the pool of client programs: Select Edit: Preferences and click the Client tab. Click Add
Enter a Name for the client. Enter the Path to the executable file for the client (or click Browse to locate the executable) Enter a Command Line associated with launching the client application. SDT Connector typically launches a client using command line arguments to point it at the local endpoint of the redirection. There are three special keywords for specifying the command line format. When launching the client, SDT Connector substitutes these keywords with the appropriate values: %path% is path to the executable file, i.e. the previous field. %host% is the local address to which the local endpoint of the redirection is bound, i.e. the Local Address field for the Service redirection Advanced options. %port% is the local port to which the local endpoint of the redirection is bound, i.e. the Local TCP Port field for the Service redirection Advanced options. If this port is unspecified (i.e. "Any"), the appropriate randomly selected port will be substituted. For example SDT Connector is preconfigured for Windows installations with a HTTP service client that will connect with whichever local browser the local Windows user has configured as the default. Otherwise the default browser used is Firefox:
Also some clients are launched in a command line or terminal window. The Telnet client is an example of this:
Click OK
6.2.8 Dial in configuration If the client PC is dialing into Local/Console port on the console server you will need to set up a dial-in PPP link: Configure the console server for dial-in access (following the steps in the Configuring for Dial-In PPP Access section in Chapter 5, Configuring Dial In Access) Set up the PPP client software at the remote User PC (following the Set up the remote Client section in Chapter 5) Once you have a dial-in PPP connection established, you then can set up the secure SSH tunnel from the remote Client PC to the console server.
6.2.9 Choosing an alternate SSH client (e.g. PuTTY) To set up the secure SSH tunnel from the Client PC to the console server, you must install and launch SSH client software on the Client PC. As described above Opengear recommends you use the SDT Connector client software that is supplied with the gateway. However theres also a wide selection of commercial and free SSH client programs that are supported: - PuTTY is a complete (though not very user friendly:) freeware implementation of SSH for Win32 and UNIX platforms - SSHTerm is a useful open source SSH communications package - SSH Tectia is leading end-to-end commercial communications security solution for the enterprise - Reflection for Secure IT (formerly F-Secure SSH) is another good commercial SSH-based security solution By way of example the steps below show the establishment of an SSH connection and then forwarding the RDP port over this SSH connection - using the PuTTY client software:
Under the Session tab, enter the IP address of the console server in the Host Name or IP address field. For dial-in connections, this IP address will be the Local Address that you assigned to the console server when you set it up as the Dial-In PPP Server For Internet (or local/VPN connections) connections this will be the public IP address of the console server Select the SSH Protocol, and the Port will be set as 22
Console Server User Manual Page 83 of 261 Under the SSH -> Tunnels tab, Add new forwarded port specifying the Source port as 1234 (or any number you choose) Set the Destination: If your destination computer is network connected to the console server, set the Destination as <SDT Host IP address/DNS Name>:3389 e.g. if the SDT Host IP Address you specified when setting up the SDT Hosts on the console server was accounts.myco.intranet.com, then specify the Destination as accounts.myco.intranet.com:3389
If your destination computer is serially connected to the console server, set the Destination as <port label>:3389 e.g. if the Label you specified on the SDT enabled serial port on the console server is win2k3, then specify the remote host as win2k3:3389 . Alternative you can set the Destination as portXX:3389 where XX is the SDT enabled serial port number e.g. if port 4 is on the console server is to carry the RDP traffic then specify port04:3389 Note http://www.jfitz.com/tips/putty_config.html has useful examples on configuring PuTTY for SSH tunneling
Select Local and click the Add button Click Open to SSH connect the Client PC to the console server. You will now be prompted for the Username/Password for the console server User you SDT enabled Note You can also secure the SDT communications from local and enterprise VPN connected Client PCs using SSH as above. This will protect against the risk of the man in the middle attacks to which RDP has a vulnerability http://www.securiteam.com/windowsntfocus/5EP010KG0G.html To set up the secure SSH tunnel from the Client (Viewer) PC to the console server for VNC follow the steps above, however when configuring the VNC port redirection specify port 5900 (rather than port 3389 as was used for RDP) e.g. if using PuTTY:
Note How secure is VNC? VNC access generally allows access to your whole computer, so security is very important. VNC uses a random challenge-response system to provide the basic authentication that allows you to connect to a VNC server. This is reasonably secure and the password is not sent over the network. However, once connected, all subsequent VNC traffic is unencrypted. So a malicious user could snoop your VNC session. Also there are VNC scanning programs available, which will scan a subnet looking for PCs which are listening on one of the ports which VNC uses. Tunneling VNC over a SSH connection ensures all traffic is strongly encrypted. Also no VNC port is ever open to the internet, so anyone scanning for open VNC ports will not be able to find your computers. When tunneling VNC over a SSH connection, the only port which you're opening on your console server the SDT port 22. So sometimes it may be prudent to tunnel VNC through SSH even when the Viewer PC and the console server are both on the same local network.
To set up the secure SSH tunnel for a HTTP browser connection from the client PC, follow the steps above. However when configuring the port redirection, specify port 80 (rather than port 3389 as was used for RDP) e.g. if using PuTTY:
Console Server User Manual Page 86 of 261 SDT Connector can also be configured for browser access the gateways Management Console and for Telnet or SSH access to the gateway command line. For these connections to the gateway itself, you must configure SDT Connector to access the gateway (itself) by setting the Console server up as a host, and then configuring the appropriate services: Launch SDT Connector on your PC. Assuming you have already set up the console server as a Gateway in your SDT Connector client (with username/ password etc) select this newly added Gateway and click the Host icon to create a host. Alternatively, select File -> New Host Enter 127.0.0.1 as the Host Address and give some details in Descriptive Name/Notes. Click OK
Click the HTTP or HTTPS Services icon to access the gateway's Management Console, and/or click SSH or Telnet to access the gateway command line console Note: To enable SDT access to the gateway console, you must now configure the console server to allow port forwarded network access to itself: Browse to the console server and select Network Hosts from Serial & Network, click Add Host and in the IP Address/DNS Name field enter 127.0.0.1 (this is the Opengear's network loopback address) and enter Loopback in Description Remove all entries under Permitted Services except for those that will be used in accessing the Management Console (80/http or 443/https) or the command line (22/ssh or 23/telnet) then scroll to the bottom and click Apply Administrators by default have gateway access privileges, however for Users to access the gateway Management Console you will need to give those Users the required access privileges. Select Users & Groups from Serial & Network. Click Add User. Enter a Username, Description and Password/Confirm. Select 127.0.0.1 from Accessible Host(s) and click Apply
Console Server User Manual Page 87 of 261 6.4 SDT Connector - telnet or SSH connect to serially attached devices SDT Connector can also be used to access text consoles on devices that are attached to the console server serial ports. For these connections, you must configure the SDT Connector client software with a Service that will access the target gateway serial port, and then set the gateway up as a host: Launch SDT Connector on your PC. Select Edit -> Preferences and click the Services tab. Click Add Enter "Serial Port 2" in Service Name and click Add Select Telnet client as the Client. Enter 2002 in TCP Port. Click OK, then Close and Close again
Assuming you have already set up the target console server as a gateway in your SDT Connector client (with username/ password etc), select this gateway and click the Host icon to create a host. Alternatively, select File -> New Host. Enter 127.0.0.1 as the Host Address and select Serial Port 2 for Service. In Descriptive Name, enter something along the lines of Loopback ports, or Local serial ports. Click OK. Click Serial Port 2 icon for Telnet access to the serial console on the device attached to serial port #2 on the gateway To enable SDT Connector to access to devices connected to the gateways serial ports, you must also configure the Console server itself to allow port forwarded network access to itself, and enable access to the nominated serial port: Browse to the Console server and select Serial Port from Serial & Network Click Edit next to selected Port # (e.g. Port 2 if the target device is attached to the second serial port). Ensure the port's serial configuration is appropriate for the attached device Scroll down to Console Server Setting and select Console Server Mode. Check Telnet (or SSH) and scroll to the bottom and click Apply Select Network Hosts from Serial & Network and click Add Host In the IP Address/DNS Name field enter 127.0.0.1 (this is the Opengear's network loopback address) and enter Loopback in Description
Console Server User Manual Page 88 of 261 Remove all entries under Permitted Services and select TCP and enter 200n in Port. (This configures the Telnet port enabled in the previous step, so for Port 2 you would enter 2002) Click Add then scroll to the bottom and click Apply Administrators by default have gateway and serial port access privileges; however for Users to access the gateway and the serial port, you will need to give those Users the required access privileges. Select Users & Groups from Serial & Network. Click Add User. Enter a Username, Description and Password/Confirm. Select 127.0.0.1 from Accessible Host(s) and select Port 2 from Accessible Port(s). Click Apply.
6.5 Using SDT Connector for out-of-band connection to the gateway SDT Connector can also be set up to connect to the console server (gateway) out-of-band (OoB). OoB access uses an alternate path for connecting to the gateway to that used for regular data traffic. OoB access is useful for when the primary link into the gateway is unavailable or unreliable. Typically a gateway's primary link is a broadband Internet connection or Internet connection via a LAN or VPN, and the secondary out-of-band connectivity is provided by a dial-up or wireless modem directly attached to the gateway. So out-of-band access enables you to access the hosts and serial devices on the network, diagnose any connectivity issues, and restore the gateway's primary link. In SDT Connector, OoB access is configured by providing the secondary IP address of the gateway, and telling SDT Connector how to start and stop the OoB connection. Starting an OoB connection may be achieved by initiating a dial up connection, or adding an alternate route to the gateway. SDT Connector allows for maximum flexibility is this regard, by allowing you to provide your own scripts or commands for starting and stopping the OoB connection.
To configure SDT Connector for OoB access: When adding a new gateway or editing an existing gateway select the Out Of Band tab
Console Server User Manual Page 89 of 261 Enter the secondary, OoB IP address of the gateway (e.g. the IP address it is accessible using when dialed in directly). You also may modify the gateway's SSH port if it's not using the default of 22 Enter the command or path to a script to start the OoB connection in Start Command To initiate a pre-configured dial-up connection under Windows, use the following Start Command: cmd /c start "Starting Out of Band Connection" /wait /min rasdial network_connection login password where network_connection is the name of the network connection as displayed in Control Panel -> Network Connections, login is the dial-in username, and password is the dial-in password for the connection. To initiate a pre-configured dial-up connection under Linux, use the following Start Command: pon network_connection where network_connection is the name of the connection. Enter the command or path to a script to stop the OoB connection in Stop Command To stop a pre-configured dial-up connection under Windows, use the following Stop Command: cmd /c start "Stopping Out of Band Connection" /wait /min rasdial network_connection /disconnect where network connection is the name of the network connection as displayed in Control Panel -> Network Connections. To stop a pre-configured dial-up connection under Linux, use the following Stop Command: poff network_connection
To make the OoB connection using SDT Connector: Select the gateway and click Out Of Band. The status bar will change color to indicate this gateway is now being access using the OoB link rather than the primary link
When you connect to a service on a host behind the gateway, or to the console server gateway itself, SDT Connector will initiate the OoB connection using the provided Start Command. The OoB connection isn't stopped (using the provided Stop Command) until Out Of Band under Gateway Actions is clicked off, at which point the status bar will return to its normal color.
6.6 Importing (and exporting) preferences To enable the distribution of pre-configured client config files, SDT Connector has an Export/Import facility:
To save a configuration .xml file (for backup or for importing into other SDT Connector clients) select File -> Export Preferences and select the location to save the configuration file To import a configuration select File -> Import Preferences and select the .xml configuration file to be installed
6.7 SDT Connector Public Key Authentication SDT Connector can authenticate against an SSH gateway using your SSH key pair rather than requiring your to enter your password. This is known as public key authentication. To use public key authentication with SDT Connector, first you must add the public part of your SSH key pair to your SSH gateway:
Console Server User Manual Page 91 of 261 Ensure the SSH gateway allows public key authentication, this is typically the default behavior If you do not already have a public/private key pair for your client PC (the one running SDT Connector on) generate them now using ssh-keygen, PuTTYgen or a similar tool. You may use RSA or DSA, however it is important that you leave the passphrase field blank: - PuTTYgen: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html - OpenSSH: http://www.openssh.org/ - OpenSSH (Windows): http://sshwindows.sourceforge.net/download/ Upload the public part of your SSH key pair (this file is typically named id_rsa.pub or id_dsa.pub) to the SSH gateway, or otherwise add to .ssh/authorized keys in your home directory on the SSH gateway Next, add the private part of your SSH key pair (this file is typically named id_rsa or id_dsa) to SDT Connector. Click Edit -> Preferences -> Private Keys -> Add, locate the private key file and click OK You do not have to add the public part of your SSH key pair, it is calculated using the private key. SDT Connector will now use public key authentication when connecting through the SSH gateway (console server). You may have to restart SDT Connector to shut down any existing tunnels that were established using password authentication. Also if you have a host behind the console server that you connect to by clicking the SSH button in SDT Connector you may also wish to configure access to it for public key authentication as well. This configuration is entirely independent of SDT Connector and the SSH gateway. You must configure the SSH client that SDT Connector launches (e.g. Putty, OpenSSH) and the host's SSH server for public key authentication. Essentially what you are using is SSH over SSH, and the two SSH connections are entirely separate.
6.8 Setting up SDT for Remote Desktop access Microsofts Remote Desktop Protocol (RDP) enables the system manager to securely access and manage remote Windows computers to reconfigure applications and user profiles, upgrade the servers operating system, reboot the machine etc. Opengears Secure Tunneling uses SSH tunneling, so this RDP traffic is securely transferred through an authenticated and encrypted tunnel. SDT with RDP also allows remote Users to connect to Windows XP, Vista, Windows 2003 computers and to Windows 2000 Terminal Servers; and to have access to all of the applications, files, and network resources (with full graphical interface just as though they were in front of the computer screen at work). To set up a secure Remote Desktop connection you must enable Remote Desktop on the target Windows computer that is to be accessed and configure the RPD client software on the client PC.
6.8.1 Enable Remote Desktop on the target Windows computer to be accessed To enable Remote Desktop on the Windows computer being accessed: Open System in the Control Panel and click the Remote tab
Check Allow users to connect remotely to this computer Click Select Remote Users
To set the user(s) who can remotely access the system with RDP click Add on the Remote Desktop Users dialog box Note If you need to set up new users for Remote Desktop access, open User Accounts in the Control Panel and proceed through the steps to nominate the new users name, password and account type (Administrator or Limited)
Note With Windows XP Professional, you have only one Remote Desktop session and it connects directly to the Windows root console. With Windows Server 2003, you have the console
Console Server User Manual Page 93 of 261 session and two other general sessions - so more than one user can have active sessions on a single computer. When the remote user connects to the accessed computer on the console session, Remote Desktop automatically locks that computer (so no other user can access the applications and files). When you come back to your computer at work, you can unlock it by typing CTRL+ALT+DEL.
6.8.2 Configure the Remote Desktop Connection client Now you have the Client PC securely connected to the console server (either locally, or remotely - thru the enterprise VPN, or a secure SSH internet tunnel or a dial-in SSH tunnel) you can establish the Remote Desktop connection from the Client. To do this you simply enable the Remote Desktop Connection on the remote client PC then point it to the SDT Secure Tunnel port in the console server: A. On a Windows client PC Click Start. Point to Programs, then to Accessories, then Communications, and click Remote Desktop Connection
In Computer, enter the appropriate IP Address and Port Number: Where there is a direct local or enterprise VPN connection, enter the IP Address of the console server, and the Port Number of the SDT Secure Tunnel for the console server serial port that is attached to the Windows computer to be controlled e.g. if the Windows computer is connected to serial Port 3 on a console server located at 192.168.0.50 then you would enter 192.168.0.50:7303 Where there is an SSH tunnel (over a dial up PPP connection or over a public internet connection or private network connection ) simply enter the localhost as the IP address i.e. 127.0.0.1 For Port Number, enter the source port you created when setting SSH tunneling /port forwarding (in Section 6.1.6) e.g. :1234 Click Option. In the Display section specify an appropriate color depth (e.g. for a modem connection it is recommended you not use over 256 colors). In Local Resources specify the peripherals on the remote Windows computer that are to be controlled (printer, serial port etc)
Click Connect Note The Remote Desktop Connection software is pre-installed with Windows XP, however for earlier Windows PCs you will need to download the RDP client: Go to the Microsoft Download Center site http://www.microsoft.com/downloads/details.aspx?familyid=80111F21-D48D-426E-96C2- 08AA2BD23A49&displaylang=en and click the Download button This software package will install the client portion of Remote Desktop on Windows 95, Windows 98 and 98 Second Edition, Windows Me, Windows NT 4.0, Windows 2000, and Windows 2003. When run, this software allows these older Windows platforms to remotely connect to a computer running Windows XP Professional or Windows 2003 Server
B. On a Linux or UNIX client PC: Launch the open source rdesktop client: rdesktop -u windows-user-id -p windows-password -g 1200x950 ms-windows-terminal- server-host-name option description -a Color depth: 8, 16, 24 -r Device redirection. i.e. Redirect sound on remote machine to local device i.e. -0 -r sound (MS/Windows 2003) -g Geometry: widthxheight or 70% screen percentage.
Console Server User Manual Page 95 of 261 -p Use -p - to receive password prompt.
You can use GUI front end tools like the GNOME Terminal Services Client tsclient to configure and launch the rdesktop client. (Using tsclient also enables you to store multiple configurations of rdesktop for connection to many servers)
Note The rdesktop client is supplied with Red Hat 9.0: rpm -ivh rdesktop-1.2.0-1.i386.rpm For Red Hat 8.0 or other distributions of Linux; download source, untar, configure, make, make then install. rdesktop currently runs on most UNIX based platforms with the X Window System and can be downloaded from http://www.rdesktop.org/
C. On a Macintosh client: Download Microsoft's free Remote Desktop Connection client for Mac OS X http://www.microsoft.com/mac/otherproducts/otherproducts.aspx?pid=remotedesktopclient
Console Server User Manual Page 96 of 261 6.9 SDT SHH Tunnel for VNC Alternately, with SDT and Virtual Network Computing (VNC), Users and Administrators can securely access and control Windows 98/NT/2000/XP/2003, Linux, Macintosh, Solaris and UNIX computers. Theres a range of popular VNC software available (UltraVNC, RealVNC, TightVNC) - freely and commercially. To set up a secure VNC connection you must install and configure the VNC Server software on the computer to be accessed, then install and configure the VNC Viewer software on the Viewer PC. 6.9.1 Install and configure the VNC Server on the computer to be accessed Virtual Network Computing (VNC) software enables users to remotely access computers running Linux, Macintosh, Solaris, UNIX, all versions of Windows and most other operating systems. A. For Microsoft Windows servers (and clients): Windows does not include VNC software, so you will need to download, install and activate a third party VNC Server software package: RealVNC http://www.realvnc.com is fully cross-platform, so a desktop running on a Linux machine may be displayed on a Windows PC, on a Solaris machine, or on any number of other architectures. There is a Windows server, allowing you to view the desktop of a remote Windows machine on any of these platforms using exactly the same viewer. RealVNC was founded by members of the AT&T team who originally developed VNC.
TightVNC http://www.tightvnc.com is an enhanced version of VNC. It has added features such as file transfer, performance improvements, and read- only password support. They have just recently included a video drive much like UltraVNC. TightVNC is still free, cross-platform (Windows Unix and Linux) and compatible with the standard (Real) VNC.
UltraVNC http://ultravnc.com is easy to use, fast and free VNC software that has pioneered and perfected features that the other flavors have consistently refused or been very slow to implement for cross platform and minimalist reasons. UltraVNC runs under Windows operating systems (95, 98, Me, NT4, 2000, XP, 2003) Download UltraVNC from Sourceforge's UltraVNC file list B. For Linux servers (and clients): Most Linux distributions now include VNC Servers and Viewers and they are generally can be launched from the (Gnome/KDE etc) front end e.g. with Red Hat Enterprise Linux 4 theres VNC Server software and a choice of Viewer client software, and to launch: Select the Remote Desktop entry in the Main Menu -> Preferences menu Click the Allow other users checkbox to allow remote users to view and control your desktop
To set up a persistent VNC server on Red Hat Enterprise Linux 4: o Set a password using vncpasswd o Edit /etc/sysconfig/vncservers o Enable the service with chkconfig vncserver on o Start the service with service vncserver start o Edit /home/username/.vnc/xstartup if you want a more advanced session than just twm and an xterm C. For Macintosh servers (and clients): OSXvnc http://www.redstonesoftware.com/vnc.html is a robust, full-featured VNC server for Mac OS X that allows any VNC client to remotely view and/or control the Mac OS X machine. OSXvnc is supported by Redstone Software D. Most other operating systems (Solaris, HPUX, PalmOS etc) either come with VNC bundled, or have third party VNC software that you can download
6.9.2 Install, configure and connect the VNC Viewer VNC is truly platform-independent so a VNC Viewer on any operating system can connect to a VNC Server on any other operating system. There are Viewers (and Servers) from a wide selection of sources (e.g. UltraVNC TightVNC or RealVNC) for most operating systems. There are also a wealth of Java viewers available so that any desktop can be viewed with any Java-capable browser (http://en.wikipedia.org/wiki/VNC lists many of the VNC Viewers sources). Install the VNC Viewer software and set it up for the appropriate speed connection Note To make VNC faster, when you set up the Viewer: Set encoding to ZRLE (if you have a fast enough CPU) Decrease color level (e.g. 64 bit) Disable the background transmission on the Server or use a plain wallpaper (Refer to http://doc.uvnc.com for detailed configuration instructions)
Console Server User Manual Page 98 of 261 To establish the VNC connection, first configure the VNC Viewer, entering the VNC Server IP address A. When the Viewer PC is connected to the console server thru a SSH tunnel (over the public Internet, or a dial-in connection, or private network connection), enter locahost (or 127.0.0.1) as the IP VNC Server IP address; and the source port you entered when setting SSH tunneling /port forwarding (in Section 6.2.6) e.g. :1234
B. When the Viewer PC is connected directly to the console server (i.e. locally or remotely through a VPN or dial in connection); and the VNC Host computer is serially connected to the CM400; enter the IP address of the console server unit with the TCP port that the SDT tunnel will use. The TCP port will be 7900 plus the physical serial port number (i.e. 7901 to 7948, so all traffic directed to port 79xx on the console server is tunneled thru to port 5900 on the PPP connection on serial Port xx) e.g. for a Windows Viewer PC using UltraVNC connecting to a VNC Server which is attached to Port 1 on a console server located 192.168.0.1
You can then establish the VNC connection by simply activating the VNC Viewer software on the Viewer PC and entering the password
Note For general background reading on Remote Desktop and VNC access we recommend the following: The Microsoft Remote Desktop How-To http://www.microsoft.com/windowsxp/using/mobility/getstarted/remoteintro.mspx The Illustrated Network Remote Desktop help page http://theillustratednetwork.mvps.org/RemoteDesktop/RemoteDesktopSetupandTroubleshooting.ht ml What is Remote Desktop in Windows XP and Windows Server 2003? by Daniel Petri http://www.petri.co.il/what's_remote_desktop.htm Frequently Asked Questions about Remote Desktop http://www.microsoft.com/windowsxp/using/mobility/rdfaq.mspx Secure remote access of a home network using SSH, Remote Desktop and VNC for the home user http://theillustratednetwork.mvps.org/RemoteDesktop/SSH-RDP- VNC/RemoteDesktopVNCandSSH.html Taking your desktop virtual with VNC, Red Hat magazine http://www.redhat.com/magazine/006apr05/features/vnc/ and http://www.redhat.com/magazine/007may05/features/vnc/ Wikipedia general background on VNC http://en.wikipedia.org/wiki/VNC
6.10 Using SDT to IP connect to hosts that are serially attached to the gateway Network (IP) protocols like RDP, VNC and HTTP can also be used for connecting to host devices that are serially connected through their COM port to the console server. To do this you must: establish a PPP connection (Section 6.7.1) between the host and the gateway, then set up Secure Tunneling - Ports on the console server (Section 6.7.2), then configure SDT Connector to use the appropriate network protocol to access IP consoles on the host devices that are attached to the Console server serial ports (Section 6.7.3)
6.10.1 Establish a PPP connection between the host COM port and console server (This step is only necessary for serially connected computers) Firstly, physically connect the COM port on the host computer that is to be accessed, tothe serial port on the console server then: A. For non Windows (Linux, UNIX, Solaris etc) computers establish a PPP connection over the serial port. The online tutorial http://www.yolinux.com/TUTORIALS/LinuxTutorialPPP.html presents a selection of methods for establishing a PPP connection for Linux B. For Windows XP and 2003 computers follow the steps below to set up an advanced network connection between the Windows computer, through its COM port to the console server. Both
Console Server User Manual Page 100 of 261 Windows 2003 and Windows XP Professional allow you to create a simple dial in service which can be used for the Remote Desktop/VNC/HTTP/X connection to the console server: Open Network Connections in Control Panel and click the New Connection Wizard
Select Set up an advanced connection and click Next On the Advanced Connection Options screen select Accept Incoming Connections and click Next Select the Connection Device (i.e. the serial COM port on the Windows computer that you cabled through to the console server). By default select COM1. The COM port on the Windows computer should be configured to its maximum baud rate. Click Next On the Incoming VPN Connection Options screen select Do not allow virtual private connections and click Next
Specify which Users will be allowed to use this connection. This should be the same Users who were given Remote Desktop access privileges in the earlier step. Click Next On the Network Connection screen select TCP/IP and click Properties
Select Specify TCP/IP addresses on the Incoming TCP/IP Properties screen select TCP/IP. Nominate a From: and a To: TCP/IP address and click Next Note You can choose any TCP/IP addresses so long as they are addresses which are not used anywhere else on your network. The From: address will be assigned to the Windows XP/2003 computer and the To: address will be used by the console server. For simplicity use the IP address as shown in the illustration above: From: 169.134.13.1 To: 169.134.13.2 Alternately you can set the advanced connection and access on the Windows computer to use the console server defaults: Specify 10.233.111.254 as the From: address Select Allow calling computer to specify its own address Also you could use the console server default username and password when you set up the new Remote Desktop User and gave this User permission to use the advance connection to access the Windows computer: The console server default Username is portXX where XX is the serial port number on the console server. The default Password is portXX So to use the defaults for a RDP connection to the serial port 2 on the console server, you would have set up a Windows user named port02
When the PPP connection has been set up, a network icon will appear in the Windows task bar
Note The above notes describe setting up an incoming connection for Windows XP. The steps are the same for Windows 2003, except that the set up screens present slightly differently:
You need to put a check in the box for Always allow directly connected devices such as palmtop.. Also the option for to Set up an advanced connection is not available in Windows 2003 if RRAS is configured. If RRAS has been configured it is a simply task to enable the null modem connection for the dial-in configuration.
C. For earlier version Windows computers again follow the steps in Section B. above, however to get to the Make New Connection button: For Windows 2000, click Start and select Settings then at the Dial-Up Networking Folder click Network and Dial-up Connections and click Make New Connection. Note you may need to first set up connection over the COM port using Connect directly to another computer before proceeding to Set up an advanced connection For Windows 98 you double click My Computer on the Desktop, then open Dial-Up Networking and double click
6.10.2 Set up SDT Serial Ports on console server To set up RDP (and VNC) forwarding on the console server Serial Port that is connected to the Windows computer COM port:
Console Server User Manual Page 103 of 261 Select the Serial & Network: Serial Port menu option and click Edit (for the particular Serial Port that is connected to the Windows computer COM port) On the SDT Settings menu select SDT Mode (which will enable port forwarding and SSH tunneling) and enter a Username and User Password.
Note When you enable SDT, this will override all other Configuration protocols on that port Note If you leave the Username and User Password fields blank, they default to portXX and portXX where XX is the serial port number. So the default username and password for Secure RDP over Port 2 is port02
Ensure the console server Common Settings (Baud Rate, Flow Control) are the same as were set up on the Windows computer COM port and click Apply RDP and VNC forwarding over serial ports is enabled on a Port basis. You can add Users who can have access to these ports (or reconfigure User profiles) by selecting Serial & Network :User & Groups menu tag - as described earlier in Chapter 4 Configuring Serial Ports
6.10.3 Set up SDT Connector to ssh port forward over the console server Serial Port In the SDT Connector software running on your remote computer specify the gateway IP address of your IM/IMG/CM4000 and a username/password for a user you have setup on the console server that has access to the desired port. Next you need to add a New SDT Host. In the Host address you need to put portxx where xx = the port you are connecting to. Example for port 3 you would have a Host Address of: port03 and then select the RDP Service check box.
ALERTS AND LOGGING Introduction This chapter describes the alert generation and logging features of the console server. The Alert facility monitors the serial ports, all logins, the power status and environmental monitors and probes, and sends emails, SMS, Nagios or SNMP alerts when specified trigger events occurs. First you must enable and configure the service that will be used to carry the alert (Section 7.1) Then specify the alert trigger condition and the actual destination to which that particular alert is to be sent (Section 7.2) All console server models can maintain log records of all access and communications with the console server and with the attached serial devices. A log of all system activity is also maintained as is a history of the status of any attached environmental monitors. Some models also log access and communications with network attached hosts and maintain a history of the UPS and PDU power status. If port logs are to be maintained on a remote server, then the access path to this location need to be configured (Section 7.3) Then you need to activate and set the desired levels of logging for each serial (Section 7.4) and/or network port (Section 7.5) and/or power and environment UPS (refer Chapter 8)
7.1 Configure SMTP/SMS/SNMP/Nagios alert service The Alerts facility monitors nominated ports/hosts/UPSs/PDUs/EMDs etc. for trigger conditions and when triggered sends an alert notification over the nominated alert service. Before setting up the alert trigger, you must configure these alert services:
7.1.1 Email alerts The console server uses SMTP (Simple Mail Transfer Protocol) for sending the email alert notifications. To use SMTP, the Administrator must configure a valid SMTP server for sending the email: Select Alerts & Logging: SMTP &SMS
In the SMTP Server field enter the IP address of the outgoing mail Server You may enter a Sender email address which will appear as the from address in all email notifications sent from this console server. Many SMTP servers check the senders email address with the host domain name to verify the address as authentic. So it may be useful to assign an email address for the console server such as [email protected] You may also enter a Username and Password if the SMTP server requires authentication Similarly can specify the specific Subject Line that will be sent with the email Click Apply to activate SMTP
7.1.2 SMS alerts The console server uses email-to-SMS services to send SMS alert notifications to mobile devices. Sending SMS via email using SMTP (Simple Mail Transfer Protocol) is much faster than sending text pages via a modem using the TAP Protocol and almost all mobile phone carriers provide an SMS gateway service that forwards email to mobile phones on their networks. Theres also a wide selection of SMS gateway aggregators who provide email to SMS forwarding to phones on any carriers. To use SMTP SMS the Administrator must configure a valid SMTP server for sending the email:
Console Server User Manual Page 106 of 261 In the SMTP SMS Server field in the Alerts & Logging: SMTP &SMS menu enter the IP address of the outgoing mail Server You may enter a Sender email address which will appear as the from address in all email notifications sent from this console server. Some SMS gateway service providers only forward email to SMS when the email has been received from authorized senders. So you may need to assign a specific authorized email address for the console server You may also enter a Username and Password as some SMS gateway service providers use SMTP servers which require authentication Similarly can specify the specific Subject Line that will be sent with the email. Generally the email subject will contain a truncated version of the alert notification message (which is contained in full in the body of the email). However some SMS gateway service providers require blank subjects or require specific authentication headers to be included in the subject line Click Apply to activate SMTP
7.1.3 SNMP alerts The Administrator can configure the Simple Network Management Protocol (SNMP) agent that resides on the console server to send Alerts to an SNMP management application: Select Alerts & Logging: SNMP Enter the SNMP transport protocol. SNMP is generally a UDP-based protocol though infrequently it uses TCP instead. Enter the IP address of the SNMP Manager and the Port to used for connecting Select the version being used. The console server SNMP agent supports SNMP v1, v2 and v3 Enter the Community name for SNMP v1 or 2c To configure for SNMP v3 you will need to enter an ID and authentication password and contact information for the local Administrator (in the Security Name) Click Apply to activate SNMP
Note All our console servers have an snmptrap daemon to send traps/notifications to remote SNPM servers on defined trigger events as detailed above. KCS61xx, IM42xx and IMG4xxx console servers also embed the net-snmpd daemon which accept SNMP requests from remote SNMP management servers and provides information on network interface, running processes, disk usage etc (refer Chapter 15.5 Modifying SNMP Configuration for more details)
7.1.4 Nagios alerts To notify the central Nagios server of Alerts, NSCA must be enabled under System: Nagios and Nagios must be enabled for each applicable host or port under Serial & Network: Network Hosts or Serial & Network: Serial Ports (refer Chapter 10)
7.2 Activate Alert Events and Notifications The Alert facility monitors the status of the console server and connected devices and when an alert event is triggered, a notification is emailed to a nominated email address or SMS gateway, or the configured SNMP or Nagios server is notified. The data stream from nominated serial ports can be monitored for matched patterns or flow control status changes can be configured to trigger alerts, as can user connections to serial ports and Hosts, or power events.
Select Alerts & Logging: Alerts which will display all the alerts currently configured. Click Add Alert
7.2.1 Add a new alert The first step is to specify the alert service that will be used for this event for sending notification, who to notify there, and what port/host/device is to be monitored:
At Add a New Alert enter a Description for this new alert Nominate the email address for the Email Recipient and/or the SMS Recipient be notified of the alert Activate SNMP notification if it is to used for this event Activate Nagios notification if it is to used for this event. In a SDT Nagios centrally managed environment you can check the Nagios alert option. On the trigger condition (for matched patterns, logins, power events and signal changes) an NSCA check "warning" result will be sent to the central Nagios server. This condition is displayed on the Nagios status screen and triggers a notification, which can cause the Nagios central server itself to send out an email or an SMS, page, etc Select from the list of all configured serial ports, hosts, power units, monitors and probes which devices this new alert is to be applied to. Select Applicable Port(s) (serial) and/or Applicable Host(s) and/or Applicable UPS(es) and/or Applicable RPC(s) and/or Applicable EMD(s) and/or Applicable Alarm Sensor(s) that are to be monitored for this alert trigger
7.2.2 Select general alert type Next you must select the Alert Type (Connection, Signal, Pattern Match, UPS Status or Environment and Power) that is to be monitored. You can configure a selection of different Alert types and any number of specific triggers
Connection Alert - This alert will be triggered when a user connects or disconnects from the applicable Host or Serial Port, or when a Slave connects or disconnects from the applicable UPS Serial Port Signal Alert - This alert will be triggered when the specified signal changes state and is applicable to serial ports only. You must specify the particular Signal Type (DSR, DCD or CTS) trigger condition that will send a new alert Serial Port Pattern Match Alert This alert will be triggered if a regular expression is found in the serial ports character stream that matches the regular expression you enter in the Pattern field. This alert type will only be applied serial ports UPS Power Status Alert - This alert will be triggered when the UPS power status changes between on line, on battery, and low battery. This alert type will only be applied to UPSes. Environment and Power Alert - Refer next section for details on selecting and configuring this alert type
Console Server User Manual Page 111 of 261 7.2.3 Configuring environment and power alert type This alert type will be applied to any UPSes RPCs and EMD temperature and humidity sensors you have nominated.
Select Sensor Alert to activate Specify which Sensor Type to alert on ( Temperature, Humidity, Power Load and Battery Charge) Set the levels at which Critical and/or Warning alerts are to be sent. You can also specify High and/or Low Set Points for sending alerts and the Hysteresis to be applied before resetting off the alerts Note Specify the Set Point values are in: Degrees Centigrade for Temperature Amps (Current) for Power Load % (Percentage) for Humidity and Battery Charge
If you have selected Applicable Alarm Sensor(s) that are to be monitored for this alert event then you can also set time windows when these sensors will not be monitored (e.g. for a door open sensor you may not wish to activate the sensor alert monitoring during the working day)
7.3 Remote Log Storage Before activating Serial or Network Port Logging on any port or UPS logging, you must specify where those logs are to be saved: Select the Alerts & Logging: Port Log menu option and specify the Server Type to be used, and the details to enable log server access
Console Server User Manual Page 113 of 261 7.4 Serial Port Logging In Console Server mode, activity logs can be maintained of all serial port activity. These records are stored on an off-server, or in the IM/IMG gateway flash memory. To specify which serial ports are to have activities recorded and to what level data is to be logged:
Select Serial & Network: Serial Port and Edit the port to be logged Specify the Logging Level of for each port as: Level 0 Turns off logging for the selected port Level 1 Logs all connection events to the port Level 2 Logs all data transferred to and from the port and all changes in hardware flow control status and all User connection events Click Apply Note A cache of the most recent 8K of logged data per serial port is maintained locally (in addition to the Logs which are transmitted for remote/USB flash storage). To view the local cache of logged serial port data select Manage: Port Logs
7.5 Network TCP or UDP Port Logging (IMG4xxx and IM42xx only) The IM42XX products support optional logging of access to and communications with network attached Hosts. For each Host, when you set up the Permitted Services which are authorized to be used, you also must set up the level of logging that is to be maintained for each service
Specify the logging level that is to be maintained for that particular TDC/UDP port/service, on that particular Host: Level 0 Turns off logging for the selected TDC/UDP port to the selected Host Level 1 Logs all connection events to the port Level 2 Logs all data transferred to and from the port Click Add then click Apply
POWER & ENVIRONMENTAL MANAGEMENT Introduction Opengear console servers manage Remote Power Control devices (RPCs including PDUs and IPMI devices) and Uninterruptible Power Supplies (UPSes) and the remote operating environment using Environmental Monitoring Devices (EMDs).
8.1 Remote Power Control (RPC) The console server Management Console monitors and controls Remote Power Control devices using the embedded PowerMan open source management tool. RPCs include power distribution units (PDUs) and IPMI power devices. Serial PDUs invariably can be controlled using their command line console, so you could manage the PDU through the console server using a remote Telnet client. Also you could use proprietary software tools no doubt supplied by the vendor. This generally runs on a remote Windows PC and you could configure the console server serial port to operate with a serial COM port redirector in the PC (as detailed in Chapter 4). Similarly network-attached PDUs with browser controls can be controlled by directly sending HTTP/HTTPS commands (with SDT as detailed in Chapter 6.3). Also servers and network- attached appliances with embedded IPMI service processors or BMCs invariably are supplied with their own management tools (like SoL) that will provide secure management when connected using with SDT Connector. However for simplicity all these devices can also be controlled using the Management Consoles RPC remote power control tools. 8.1.1 RPC connection Serial and network connected RPCs must first be connected to, and configured to communicate with the console server: For serial RPCs connect the PDU to the selected serial port on the console server and from the Serial and Network: Serial Port menu configure the Common Settings of that port with the RS232 properties etc required by the PDU (refer Chapter 4.1.1 Common Settings). Then select RPC as the Device Type Similarly for each network connected RPC go to Serial & Network: Network Hosts menu and configure the RPC as a connected Host
Console Server User Manual Page 116 of 261 Select the Serial & Network: RPC Connections menu. This will display all the RPC connections that have already been configured
Click Add RPC
Enter a RPC Name and Description for the RPC In Connected Via select the pre-configured serial port or the network host address that connects to the RPC Select any specific labels you wish to apply to specific RPC Outlets (e.g. the PDU may have 20 outlets connected to 20 powered devices you may wish to identify by name)
Enter the Username and Password used to login into the RPC (Note that these login credentials are not related the Users and access privileges you will have configured in Serial & Networks: Users & Groups) Check Log Status and specify the Log Rate (minutes between samples) if you wish the status from this RPC to be logged. These logs can be views from the Status: RPC Status screen Click Apply Note The Management Console has support for a growing number of popular network and serial PDUs. If your PDU is not on the default list it is simple to add support for more devices, and this is covered in Chapter 14 - Advanced Configurations IPMI service processors and BMCs can be configured so all authorized users can use the Management Console to remotely cycle power and reboot computers, even when their operating system is unresponsive. To set up IPMI power control, the Administrator first enters the IP address/domain name of the BMC or service processor (e.g. a Dell DRAC) in Serial & Network: Network Hosts, then in Serial & Network: RPC Connections specifies the RPC Type to be IPMI1.5 or 2.0
8.1.2 RPC alerts You can now set PDU and IPMI alerts using Alerts & Logging: Alerts (refer Chapter 7)
8.1.3 RPC status You can monitor the current status of your network and serially connected PDUs and IPMI RPCs Select the Status: RPC Status menu and a table with the summary status of all connected RPC hardware will be displayed
Click on View Log or select the RPCLogs menu and you will be presented with a table of the history and detailed graphical information on the select RPC Click Manage to query or control the individual power outlet. This will take you to the Manage: Power screen
8.1.4 User power management The Power Manager enables both Users and Administrators to access and control the configured serial and network attached PDU power strips, and servers with embedded IPMI service processors or BMCs:
Select the Manage: Power and the particular Target power device to be controlled (or click Manage on the Status: RPC Status menu)
Console Server User Manual Page 119 of 261 The outlet status is displayed and you can initiate the desired Action to be taken by selecting the appropriate icon: Power ON Power OFF Power Cycle Power Status You will only be presented with icons for those operations that are supported by the Target you have selected
8.2 Uninterruptible Power Supply Control (UPS) IM42xx, IMG4xxx and CM41xx families of console servers manage UPS hardware using Network UPS Tools (refer Section 8.2.6 for an overview of embedded open source Network UPS Tools - NUT software)
8.2.1 Managed UPS connections A Managed UPS is a UPS that is connected by serial or USB cable or by the network to the console server. The console server becomes the master of this UPS, and runs a upsd server to allow other computers that are drawing power through the UPS (slaves) to monitor its status and take appropriate action (such as shutdown in event of low battery).
The console server may or may not be drawing power through the Managed UPS (see the Configure UPS powering the console server section below) When the UPS's battery power reaches critical, the console server signals and waits for slaves to shutdown, then powers off the UPS. Serial and network connected UPSes must first be configured on the console server with the relevant serial control ports reserved for UPS usage, or the with the UPS allocated as a connected Host:
Console Server User Manual Page 120 of 261 Select UPS as the Device Type in the Serial & Network: Serial Port menu for each port which has Master control over a UPS and in the Serial & Network: Network Hosts menu for each network connected UPS (refer Chapter 4)
No such configuration is required for USB connected UPS hardware.
Select the Serial & Network: UPS Connections menu. The Managed UPSes section will display all the UPS connections that have already been configured. Click Add UPS
Enter a UPS Name and Description (optional) and the select if the UPS will be Connected Via USB or over pre-configured serial port or via HTTP/HTTPS over the preconfigured network Host connection Enter the UPS login details. This Username and Password is used by slaves of this UPS (i.e. other computers that are drawing power through this UPS) to connect to the console server to monitor the UPS status and shut themselves down when battery power is low. Monitoring will typically be performed using the upsmon client running on the slave server. See section 8.5.4 for details on setting up upsmon on slave servers powered by the UPS Note: These login credentials are not related the Users and access privileges you will have configured in Serial & Networks: Users & Groups If you have multiple UPSes and require them to be shut down in a specific order, specify the Shutdown Order for this UPS. This is a whole positive number, or -1. 0s are shut down first, then 1s, 2s, etc. -1s are not shut down at all. Defaults to 0 Select the Driver that will be used to communicate with the UPS. The drop down menu presents full selection of drivers from the latest Network UPS Tools (NUT version 2.2.0) and additional information on compatible Ups hardware can be found at http://www.networkupstools.org/compat/stable.html
Console Server User Manual Page 122 of 261 Click New Options in Driver Options if you need to set driver-specific options for your selected NUT driver and hardware combination (more details at http://www.networkupstools.org/doc
Check Log Status an specify the Log Rate (minutes between samples) if you wish the status from this UPS to be logged. These logs can be views from the Status: UPS Status screen Check Enable Nagios to enable this UPS to be monitored using Nagios central management Click Apply You can also customize the upsmon, upsd and upsc settings for this UPS hardware directly from the command line
8.2.2 Configure UPS powering the console server A Monitored UPS is a UPS that the Opengear console server is drawing power through. The purpose of configuring a Monitored UPS is in the event of a power failure, it provides an opportunity to perform any "last gasp" actions before power is lost. This is achieved by placing a script in /etc/config/scripts/ups- shutdown - you may use the /etc/scripts/ups-shutdown as a template. This script is run when then UPS reaches critical battery status.
If the console server is drawing power through a Managed UPS that has already been configured, select Local, enter the Managed UPS Name and check Enabled. The Opengear console server continues to be the master of this UPS.
If the UPS that powers the console server is not a Managed UPS for that console server, then then console server can still connect to a remote NUT server (upsd) to monitor its status as a slave. In this case, select Remote, and enter the address, username and password to connect.
8.2.3 Configuring powered computers to monitor a Managed UPS Once you have added a Managed UPS, each server that is drawing power through the UPS should be setup to monitor the UPS status as a slave. This is done by installing the NUT package on each server, and setting up upsmon to connect to the Opengear console server. Refer to the NUT documentation for details on how this is done, specifically sections 13.5 to 13.10. http://eu1.networkupstools.org/doc/2.2.0/INSTALL.html An example upsmon.conf entry might look like: MONITOR [email protected] 1 username password slave - managedups is the UPS Name of the Managed UPS - 192.168.0.1 is the IP address of the Opengear console server - 1 indicates the server has a single power supply attached to this UPS - username is the Username of the Managed UPS
Console Server User Manual Page 125 of 261 - password is the Password of the Manager UPS
8.2.4 UPS alerts You can now set UPS alerts using Alerts & Logging: Alerts (refer Chapter 7)
8.2.5 UPS status You can monitor the current status of all of your network, serially or USB connected Managed UPSes or any Monitored UPS Select the Status: UPS Status menu and a table with the summary status of all connected UPS hardware will be displayed
Click on any particular UPS System name in the table and you will be presented with a more detailed graphical information on the select UPS System
Click on any particular All Data for any UPS System in the table for more status and configuration information on the select UPS System
Select UPS Logs and you will be presented with the log table of the load, battery charge level. temperature and other status information from all the Managed and Monitored UPS systems. This information will be logged for all UPSes which were configured with Log Status checked. The information is also presented graphically
8.2.6 Overview of Network UPS Tools (NUT) Network UPS Tools (NUT) is a group of open source programs that provide a common interface for monitoring and administering UPS hardware; and ensuring safe shutdowns of the systems which are connected. NUT can be configured using the Management Console as described above, or you can configure the tools and manage the UPSes directly from the command line. This section provides an overview of NUT however you can find full documentation at http://www.networkupstools.org/doc. NUT is built on a networked model with a layered scheme of drivers, server and clients. 1. The driver programs talk directly to the UPS equipment and run on the same host as the NUT network server upsd. Drivers are provided for a wide assortment of equipment from most of the popular UPS vendors and they understand the specific language of each UPS and map it back to a compatibility layer. This means both an expensive "smart" protocol UPS and a simple "power strip" model can be handled transparently. 2. The NUT network server program upsd is responsible for passing status data from the drivers to the client programs via the network. upsd can caches the status from multiple UPSes and can then serve this status data to many clients. upsd also contains access control features to limit the abilities of the clients (e.g. so only authorized hosts may monitor or control the UPS hardware)
Console Server User Manual Page 127 of 261 3. There are a number of NUT clients that connect to upsd that to read that check on the status of the UPS hardware and do things based on the status. These clients can run on the same host as the NUT server or they can communicate with the NUT server over the network (enabling them to monitor any UPS anywhere). The upsmon client enables servers that draw power through the UPS (i.e. slaves of the UPS) to shutdown gracefully when the battery power reaches critical. Additionally, one server is designated the master of the UPS, and is responsible for shutting down the UPS itself when all slaves have shut down. Typically, the master of the UPS is the one connected to the UPS via serial or USB cable. upsmon can monitor multiple UPSes, so for high-end servers which receive power from multiple UPSes simultaneously won't initiate a shutdown until the total power situation across all source UPSes becomes critical. There also the two status/logging clients, upsc and upslog. The upsc client provides as a quick way to poll the status of a UPS. It can be used inside shell scripts and other programs that need UPS status information. upslog is a background service that periodically polls the status of a UPS, writing it to a file. All these clients all run on the Opengear console server (for Management Console presentations) but they also are run remotely (on locally powered servers and remote monitoring systems). This layered NUT architecture enables: Multiple manufacturer support: NUT can monitor USB models from 79 different manufacturers with a unified interface Multiple architecture support: NUT can manage serial and USB connected models with the same common interface. SNMP equipment can also be monitored (although at this stage this is still pre- release with experimental drivers and this feature will be added to the Opengears embedded UPS tools in future release). Multiple clients monitoring the one UPS: Multiple systems may monitor a single UPS using only their network connections and theres a wide selection of client programs) which support monitoring UPS hardware via NUT (Big Sister, Cacti, Nagios, Windows and more. Refer www.networkupstools.org/client-projects.) So NUT supports the more complex power architectures found in data centers, computer rooms and NOCs where many UPSes from many vendors power many systems with many clients and each of the larger UPSes power multiple devices and many of these devices are themselves dual powered.
8.3 Environmental Monitoring The Environmental Monitor Device (EMD) connects to any Opengear console server serial port and each console server can support multiple EMDs. Each EMD device has one temperature and one humidity sensor and two general purpose status sensors which can be connected to a smoke detector, water detector, vibration or open-door sensor.
Using the Management Console, Administrators can view the ambient temperature and humidity and set the EMD to automatically send alarms progressively from warning levels to critical alerts.
8.3.1 Connecting the EMD The Environmental Monitor Device (EMD) connects to any serial port on the console server via a special EMD Adapter and standard CAT5 cable. The EMD is powered over this serial connection and communicates using a custom handshake protocol. It is not an RS232 device and should not be connected without the adapter:
Plug the male RJ plug on the EMD Adapter into EMD and then connect to the console server serial port using the provided UTP cable. If the 6 foot (2 meter) UTP cable provided with the EMD is not long enough it can be replaced with a standard Cat5 UTP cable up to 33 feet (10meters) in length
Screw the bare wires on any smoke detector, water detector, vibration sensor, open-door sensor or general purpose open/close status sensors into the terminals on the EMD The EMD can be used only with an Opengear console server and cannot be connected to standard RS232 serial ports on other appliances. Select Environmental as the Device Type in the Serial & Network: Serial Port menu for the port to which the EMD is to be attached. No particular Common Settings are required. Click Apply
Select the Serial & Network: Environmental menu. This will display all the EMD connections that have already been configured
Enter a Name and Description for the EMD and select pre-configured serial port that the EMD will be Connected Via Provide Labels for each of the two alarms Check Log Status and specify the Log Rate (minutes between samples) if you wish the status from this EMD to be logged. These logs can be views from the Status: Environmental Status screen Click Apply
8.3.2 Environmental alerts You can now set temperature, humidity and probe status alerts using Alerts & Logging: Alerts (refer Chapter 7)
8.3.3 Environmental status You can monitor the current status of all of EMDs and their probes Select the Status: Environmental Status menu and a table with the summary status of all connected EMD hardware will be displayed
Click on View Log or select the Environmental Logs menu and you will be presented with a table of the history and detailed graphical information on the select EMD
AUTHENTICATION Introduction The console server platform is a dedicated Linux computer, and it embodies a myriad of popular and proven Linux software modules for networking, secure access (OpenSSH) and communications (OpenSSL) and sophisticated user authentication (PAM, RADIUS, TACACS+ and LDAP). This chapter details how the Administrator can use the Management Console to establish remote AAA authentication for all connections to the console server and attached serial and network host devices This chapter also covers establishing a secure link to the Management Console using HTTPS and using OpenSSL and OpenSSH for establishing secure Administration connection to the console server
9.1 Authentication Configuration Authentication can be performed locally, or remotely using an LDAP, Radius or TACACS+ authentication server. The default authentication method for the console server is Local.
Any authentication method that is configured will be used for authentication of any user who attempts to log in through Telnet, SSH or the Web Manager to the console server and any connected serial port or network host devices.
Console Server User Manual Page 133 of 261 The console server can be configured to the default (Local) or an alternate authentication method (TACACS, RADIUS or LDAP) with the option of a selected order in which local and remote authentication is to be used: Local TACACS /RADIUS/LDAP: Tries local authentication first, falling back to remote if local fails TACACS /RADIUS/LDAP Local: Tries remote authentication first, falling back to local if remote fails TACACS /RADIUS/LDAP Down Local: Tries remote authentication first, falling back to local if the remote authentication returns an error condition (e.g. the remote authentication server is down or inaccessible)
9.1.1 Local authentication Select Serial and Network: Authentication and check Local Click Apply
9.1.2 TACACS authentication Perform the following procedure to configure the TACACS+ authentication method to be used whenever the console server or any of its serial ports or hosts is accessed: Select Serial and Network: Authentication and check TACAS or LocalTACACS or TACACSLocal or TACACSDownLocal
Enter the Server Address (IP or host name) of the remote Authentication/Authorization server. Multiple remote servers may be specified in a comma separated list. Each server is tried in succession. In addition to multiple remote servers you can also enter for separate lists of Authentication/Authorization servers and Accounting servers. If no Accounting servers are specified, the Authentication/Authorization servers are used instead. Enter the Server Password Click Apply. TACAS+ remote authentication will now be used for all user access to console server and serially or network attached devices
TACACS+ The Terminal Access Controller Access Control System (TACACS+) security protocol is a recent protocol developed by Cisco. It provides detailed accounting information and flexible administrative control over the authentication and authorization processes. TACACS+ allows for a single access control server (the TACACS+ daemon) to provide authentication, authorization, and accounting services independently. Each service can be tied into its own database to take advantage of other services available on that server or on the network, depending on the capabilities of the daemon. There is a draft RFC detailing this protocol. Further information on configuring remote TACACS+ servers can be found at the following sites: http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080094e99.shtml http://www.cisco.com/en/US/products/sw/secursw/ps4911/products_user_guide_chapter09186a0 0800eb6d6.html http://cio.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/secur_c/scprt2/sctplu s.htm
9.1.3 RADIUS authentication Perform the following procedure to configure the RADIUS authentication method to be used whenever the console server or any of its serial ports or hosts is accessed: Select Serial and Network: Authentication and check RADIUS or LocalRADIUS or RADIUSLocal or RADIUSDownLocal
Enter the Server Address (IP or host name) of the remote Authentication/ Authorization server. Multiple remote servers may be specified in a comma separated list. Each server is tried in succession In addition to multiple remote servers you can also enter for separate lists of Authentication/Authorization servers and Accounting servers. If no Accounting servers are specified, the Authentication/Authorization servers are used instead Enter the Server Password Click Apply. RADIUS remote authentication will now be used for all user access to console server and serially or network attached devices
RADIUS The Remote Authentication Dial-In User Service (RADIUS) protocol was developed by Livingston Enterprises as an access server authentication and accounting protocol. The RADIUS server can support
Console Server User Manual Page 135 of 261 a variety of methods to authenticate a user. When it is provided with the username and original password given by the user, it can support PPP, PAP or CHAP, UNIX login, and other authentication mechanisms. Further information on configuring remote RADIUS servers can be found at the following sites: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/DepKit/d4fe8248-eecd- 49e4-88f6-9e304f97fefc.mspx http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a00800945cc.shtml http://www.freeradius.org/
9.1.4 LDAP authentication Perform the following procedure to configure the LDAP authentication method to be used whenever the console server or any of its serial ports or hosts is accessed: Select Serial and Network: Authentication and check LDAP or LocalLDAP or LDAPLocal or LDAPDownLocal
Enter the Server Address (IP or host name) of the remote Authentication server. Multiple remote servers may be specified in a comma separated list. Each server is tried in succession. Enter the Server Password Note To interact with LDAP requires that the user account exist on our console server to work with the remote server i.e. you can't just create the user on your LDAP server and not tell the console server about it. You need to add the user account.
Click Apply. LDAP remote authentication will now be used for all user access to console server and serially or network attached devices
Console Server User Manual Page 136 of 261 LDAP The Lightweight Directory Access Protocol (LDAP) is based on the X.500 standard, but significantly simpler and more readily adapted to meet custom needs. The core LDAP specifications are all defined in RFCs. LDAP is a protocol used to access information stored in an LDAP server. Further information on configuring remote RADIUS servers can be found at the following sites: http://www.ldapman.org/articles/intro_to_ldap.html http://www.ldapman.org/servers.html http://www.linuxplanet.com/linuxplanet/tutorials/5050/1/ http://www.linuxplanet.com/linuxplanet/tutorials/5074/4/
9.1.5 RADIUS/TACACS user configuration Users may be added to the local console server appliance. If they are not added and they log in via remote AAA, a user will be added for them. This user will not show up in the Opengear configurators unless they are specifically added, at which point they are transformed into a completely local user. The newly added user must authenticate off of the remote AAA server, and will have no access if it is down. If a local user logs in, they may be authenticated/ authorized from the remote AAA server, depending on the chosen priority of the remote AAA. A local user's authorization is the union of local and remote privileges. Example 1: User Tim is locally added, and has access to ports 1 and 2. He is also defined on a remote TACACS server, which says he has access to ports 3 and 4. Tim may log in with either his local or TACACS password, and will have access to ports 1 through 4. If TACACS is down, he will need to use his local password, and will only be able to access ports 1 and 2. Example 2: User Ben is only defined on the TACACS server, which says he has access to ports 5 and 6. When he attempts to log in a new user will be created for him, and he will be able to access ports 5 and 6. If the TACACS server is down he will have no access. Example 3: User Paul is defined on a RADIUS server only. He has access to all serial ports and network hosts. Example 4: User Don is locally defined on an appliance using RADIUS for AAA. Even if Don is also defined on the RADIUS server he will only have access to those serial ports and network hosts he has been authorised to use on the appliance. If a no local AAA option is selected, then root will still be authenticated locally. Remote users may be added to the admin group via either RADIUS or TACACS. Users may have a set of authorizations set on the remote TACACS server. Users automatically added by RADIUS will have authorization for all resources, whereas those added locally will still need their authorizations specified. LDAP has not been modified, and will still need locally defined users.
Note To interact with RADIUS, TACACS+ and LDAP with console server firmware pre 2.4.2 you must also set up the user accounts on the local console server. All resource authorizations must be added to the local appliance. With this release if remote AAA is selected, it is used for password checking only. Root is always authenticated locally. Any changes to PAM configurations will be destroyed next time the authentication configurator is run
9.2 PAM (Pluggable Authentication Modules) The console server supports RADIUS, TACACS+ and LDAP for two-factor authentication via PAM (Pluggable Authentication Modules). PAM is a flexible mechanism for authenticating Users. Nowadays a number of new ways of authenticating users have become popular. The challenge is that each time a new authentication scheme is developed; it requires all the necessary programs (login, ftpd etc.) to be rewritten to support it. PAM provides a way to develop programs that are independent of authentication scheme. These programs need "authentication modules" to be attached to them at run-time in order to work. Which authentication module is to be attached is dependent upon the local system setup and is at the discretion of the local Administrator. The console server family supports PAM to which we have added the following modules for remote authentication: RADIUS - pam_radius_auth (http://www.freeradius.org/pam_radius_auth/) TACACS+ - pam_tacplus (http://echelon.pl/pubs/pam_tacplus.html) LDAP - pam_ldap (http://www.padl.com/OSS/pam_ldap.html) Further modules can be added as required. Changes may be made to files in /etc/config/pam.d/ which will persist, even if the authentication configurator is run. Users added on demand: When a user attempts to log in, but does not already have an account on the console server, a new user account will be created. This account will have no rights, and no password set. They will not appear in the Opengear configuration tools. Automatically added accounts will not be able to log in if the remote servers are unavailable. RADIUS users are currently assumed to have access to all resources, so will only be authorized to log in to the console server. RADIUS users will be authorized each time they access a new resource. Admin rights granted over AAA: Users may be granted Administrator rights via networked AAA. For TACACS a priv-lvl of 12 of above indicates an administrator. For RADIUS, administrators are indicated via the Framed Filter ID. (See the example configuration files below for example) Authorization via TACACS for both serial ports and host access: Permission to access resources may be granted via TACACS by indicating an Opengear Appliance and a port or networked host the user may access. (See the example configuration files below for example.)
Console Server User Manual Page 138 of 261 TACACS Example: user = tim { service = raccess { priv-lvl = 11 port1 = cm4001/port02 port2 = 192.168.254.145/port05 } global = cleartext mit }
RADIUS Example: paul Cleartext-Password := "luap" Service-Type = Framed-User, Fall-Through = No, Framed-Filter-Id=":group_name=admin"
The list of groups may include any number of entries separated by a comma. If the admin group is included, the user will be made an Administrator.
If there is already a Framed-Filter-Id simply add the list of group_names after the existing entries, including the separating colon ":".
9.3 Secure Management Console Access Selecting HTTPS Server in System: Services enables the Administrator to establish a secure browser connection Management Console:
Activate your preferred browser and enter https:// IP address e.g. if the console server has been set up with an IP address of 200.122.0.12 you need to type https:// 200.122.0.12 in your address bar
Console Server User Manual Page 139 of 261 Your browser may respond with a message that verifies the security certificate is valid but notes that it is not necessarily verified by a certifying authority. To proceed you need to click yes if you are using Internet Explorer or select accept this certificate permanently (or temporarily) if you are using Mozilla Firefox. You will then be prompted for the Administrator account and password as normal. When you have a secure HTTPS connection in place the SSL secured icon will appear at the bottom of the browser screen. You can verify the level of encryption in place by clicking on this icon. When you first enable and connect via HTTPS it is normal that you may receive a certificate warning. The default SSL certificate in your console server is embedded during testing and it is not signed by a recognized third party certificate authority (rather it is signed by our own signing authority). These warnings do not affect the encryption protection you have against eavesdroppers. Note More detailed information on issuing certificates and configuring HTTPS can be found in Chapter 13 - Advanced
NAGIOS INTEGRATION Introduction Nagios is a powerful, highly extensible open source tool for monitoring network hosts and services. The core Nagios software package will typically be installed on a server or virtual server, the central Nagios server. Console servers operate in conjunction with a central/upstream Nagios server to provide distributing monitoring of attached network hosts and serial devices. They embed the NSCA (Nagios Service Checks Acceptor) and NRPE (Nagios Remote Plug-in Executor) add-ons this allows them to communicate with the central Nagios server, eliminating the need for a dedicated slave Nagios server at remote sites. The console server products all support basic distributed monitoring. Additionally, IMG/IM4000 families support extensive customizable distributed monitoring. Even if distributed monitoring is not required, the Console servers can be deployed locally alongside the Nagios monitoring host server, to provide additional diagnostics and points of access to managed devices. Opengears SDT for Nagios extends the capabilities of the central Nagios server beyond monitoring, enabling it to be used for central management tasks. It incorporates the Opengear SDT Connector client, enabling point-and-click access and control of distributed networks of Console servers and their attached network and serial hosts, from a central location.
Note If you have an existing Nagios deployment, you may wish to use the console server gateways in a distributed monitoring server capacity only. If this case and you are already familiar with Nagios, skip ahead to section 10.3.
Console Server User Manual Page 141 of 261 10.1 Nagios Overview Nagios provides central monitoring of the hosts and services in your distributed network. Nagios is freely downloadable, open source software. This section offers a quick background of Nagios and its capabilities. A complete overview, FAQ and comprehensive documentation are available at: http://www.nagios.org Nagios forms the core of many leading commercial system management solutions such as GroundWork: http://www.groundworkopensource.com Nagios does take some time to install and configure solutions such as GroundWork and Opengear SDT Nagios are aimed at simplifying this process. Once Nagios is up and running however, it provides an outstanding network monitoring system. With Nagios you can: Display tables showing the status of each monitored server and network service in real time Use a wide range of freely available plug-ins to make detailed checks of specific services e.g. don't just check a database is accepting network connections, check that it can actually validate requests and return real data Display warnings and send warning e-mails, pager or SMS alerts when a service failure or degradation is detected Assign contact groups who are responsible for specific services in specific time frames
10.2 Central management and setting up SDT for Nagios The Opengear Nagios solution has three parts: the Central Nagios server, Distributed Opengear console servers and the SDT for Nagios software.
Central Nagios server A vanilla Nagios 2.x or 3.x installation (typically on a Linux server) Generally running on a blade, PC, virtual machine, etc. at a central location Runs a web server that displays the Nagios GUI Imports configuration from distributed Opengear servers using the SDT for Nagios Configuration Wizard
Distributed Opengear console servers Opengear CM/IM/IMG console server running firmware 2.4.1 or later Serial and network hosts are attached to each console server Each runs Nagios plug-ins, NRPE and NSCA add-ons, but not a full Nagios server
Clients Typically a client PC, laptop, etc. running Windows, Linux or Mac OS X Runs SDT Connector client software 1.5.0 or later Possibly remote to the central Nagios server or distributed Opengear servers (i.e. a road warrior) May receive alert emails from the central Nagios server or distributed Opengear servers Connects to the central Nagios server web UI to view status of monitored hosts and serial devices Uses SDT Connector to connect through the distributed Opengear servers, to manage monitored hosts and serial devices
SDT Nagios setup involves the following steps: i. Install Nagios and the NSCA and NRPE add-ons on the central Nagios server (Section 10.2.1 - Set up central Nagios server) ii. Configure each Opengear distributed console server for Nagios monitoring, alerting, and SDT Nagios integration (Section 10.2.2 - Set up distributed Opengear servers) iii. Run the SDT for Nagios Configuration Wizard on the central Nagios server (Section 10.2.3 - Set up SDT Nagios on central Nagios server) and perform any additional configuration tasks iv. Install SDT Connector on each client (Section 10.2.4 - Set up clients)
10.2.1 Set up central Nagios server SDT for Nagios requires a central Nagios server running Nagios 2.x or 3.x. Nagios 1.x is not supported. The Nagios server software is available for most major distributions of Linux using the standard package management tools. Your distribution will have documentation available on how to install Nagios. This is usually the quickest and simplest way to get up and running. Note that you will need the core Nagios server package, and at least one of the NRPE or NSCA add-ons. NSCA is required to utilize the alerting features of the Opengear distributed hosts, installing both NRPE and NSCA is recommended. You will also require a web server such as Apache to display the Nagios web UI (and this may be installed automatically as a dependency of the Nagios packages). Alternatively, you may wish to download the Nagios source code directly from the Nagios website, and build and install the software from scratch. The Nagios website (http://www.nagios.org) has several Quick Start Guides that walk through this process. Once you are able to browse to your Nagios server and see its web UI and the local services it monitors by default, you are ready to continue.
10.2.2 Set up distributed Opengear console servers Each distributed console server must be running firmware 2.4.1 or later. Refer to Chapter 11 for details on upgrading Opengear firmware. This section provides a brief walkthrough on configuring a single Opengear console server to monitor the status one attached network host (a Windows IIS server running HTTP and HTTPS services) and one serially attached device (the console port of a network router), and to send alerts back to the Nagios server when an administrator connects to the router or IIS server. This walkthrough provides an example, however details of the configuration options are described in the next section. This walkthrough also assumes the network host and serial devices are already physically connected to the console server. First step is to set up the Nagios features on the console server:
Browse the Opengear console server and select System: Nagios on the console server Management Console. Check Nagios service Enabled Enter the Host Name and the Nagios Host Address (i.e. IP address) that the central Nagios server will use to contact the distributed Opengear console server Enter the IP address that the distributed Opengear console server will use to contact the central Nagios server in Nagios Server Address Enter the IP address that the clients running SDT Connector will use to connect through the distributed Opengear servers in SDT Gateway address Check Prefer NRPE, NRPE Enabled and NRPE Command Arguments Check NSCA Enabled, choose an NSCA Encryption Method and enter and confirm an NSCA Secret. Remember these details as you will need them later on. For NSCA Interval, enter: 5 Click Apply.
Console Server User Manual Page 144 of 261 Next you must configure the attached Window network host and specify the services you will be checking with Nagios (HTTP and HTTPS): Select Network Hosts from the Serial & Network menu and click Add Host. Enter the IP Address/DNS Name of the network server, e.g.: 192.168.1.10 and enter a Description, e.g.: Windows 2003 IIS Server Remove all Permitted Services. This server will be accessible using Terminal Services, so check TCP, Port 3389 and log level 1 and click Add. It is important to remove and re-add the service to enable logging
Scroll down to Nagios Settings and check Enable Nagios Click New Check and select Check Ping. Click check-host-alive Click New Check and select Check Permitted TCP. Select Port 3389 Click New Check and select Check TCP. Select Port 80 Click New Check and select Check TCP. Select Port 443 Click Apply Similarly you now must configure the serial port to the router to be monitored by Nagios: Select Serial Port from the Serial & Network menu Locate the serial port that has the router console port attached and click Edit Ensure the serial port settings under Common Settings are correct and match the attached routers console port Click Console Server Mode, and select Logging Level 1 Check Telnet (SSH access is not required, as SDT Connector is used to secure the otherwise insecure Telnet connection) Scroll down to Nagios Settings and check Enable Nagios Check Port Log and Serial Status Click Apply Now you can set the console server to send alerts to the Nagios server Select Alerts from the Alerts & Logging menu and click Add Alert
Console Server User Manual Page 145 of 261 In Description enter: Administrator connection Check Nagios (NSCA) In Applicable Ports check the serial port that has the router console port attached. In Applicable Hosts check the IP address/DNS name of the IIS server Click Connection Alert Click Apply Lastly you need to add a User for the client running SDT Connector: Select Users & Groups from the Serial & Network menu Click Add User In Username, enter: sdtnagiosuser, then enter and confirm a Password In Accessible Hosts click the IP address/DNS name of the IIS server, and in Accessible Ports click the serial port that has the router console port attached Click Apply
10.2.3 Set up SDT for Nagios on the central Nagios server Once the Nagios service, network host and serial port have been configured on the console server you are ready to run the SDT for Nagios Configuration Wizard on the central Nagios server. The primary function of the wizard is to connect to each distributed Opengear console server and import configuration into the central Nagios server. This effectively adds the hosts and service checks you set up on the distributed Opengear console servers into your central Nagios server. The wizard is a Linux command line script, and can be downloaded from http://www.opengear.com/download.html Copy or download the wizard to the central Nagios server and open a command line terminal: Download the wizard to a location on the central Nagios server Open a command line terminal and change directory to the location of the wizard Ensure the wizard script is executable by executing chmod +x sdtnagios-config Ensure you are running as a user with write permissions to Nagios configuration and web UI files and directories Execute the wizard script, e.g. ./sdtnagios-config The wizard will prompt you for the location of some Nagios configuration files (with the option to search), and the IP addresses and login credentials of the distributed Opengear console servers. After the distributed configuration has been imported, the wizard will ask if you want to apply the Opengear SDT Nagios UI theme. This is not required, and simply changes the look and feel of the Nagios UI to that pictured below.
Once the wizard has completed successfully, verify the Nagios configuration is valid as instructed, and restart Nagios. If you chose to apply the SDT for Nagios theme, you may need to flush your browsers cache for it to display correctly. Login to the SDT for Nagios web UI on the central Nagios server and select Service Detail from the Monitoring menu to see the imported hosts and service checks. Note: the wizard keeps a backup copy of each file it modifies, it displays the name of each of these backup files as it runs. If you wish to roll back the changes made by the wizard, simply move these files to their original names. Otherwise once you are satisfied with the new configuration, you may remove the backup files.
10.2.4 Set up the clients The final step is to set up SDT Connector on each of the client PCs. The client PCs use a web browser to view the Nagios web UI running on the central Nagios server. This web UI links to SDT Connector to enable point and click access through the distributed Opengear console servers to attached hosts and serial ports, and the Opengear unit itself. Detailed setup and configuration instructions for SDT Connector are contained elsewhere in this manual, but here are the basic steps you need to follow. Download SDT Connector 1.5.0 or later from: http://www.opengear.com/download.html Follow the usual SDT Connector setup procedure for your operating system (i.e. for Windows clients, run the setup executable, for other clients, decompress the distribution archive) Close any running web browsers
Console Server User Manual Page 147 of 261 Launch SDT Connector SDT Connector will prompt you to Enable sdt:// links? Click Yes Select File the New Gateway Enter the SDT Nagios Address (from section 10.2.2) in Gateway Address Enter the Username and Password (from10.2.2) in Gateway Username and Password in this example we used sdtnagiosuser Close SDT Connector (its not necessary to add any SDT Connector hosts) Now you can open your web browser and login to the SDT Nagios web UI on the central Nagios server: Select Service Detail from the Monitoring menu Locate the row with the Windows IIS Server host then the service check beginning with check_tcp_3339, and click the link to Connect via SDT
SDT Connector launches and starts up a Terminal Services session to the IIS Server, securely tunneled through the distributed Opengear server. Likewise, locate the row for the routers serial console port, and the service check beginning with check_serial, and click the link to Connect via SDT Note that these actions will also trigger the alert_login alerts that you added
Console Server User Manual Page 148 of 261 To activate the console server Nagios distributed monitoring: Nagios integration must be enabled and a path established to the central/upstream Nagios server If the console server is to periodically report on Nagios monitored services, then the NSCA client embedded in the console server must be configured the NSCA program enables scheduled check- ins with the remote Nagios server and is used to send passive check results across the network to the remote server If the Nagios server is to actively request status updates from the console server, then the NRPE server embedded in the console server must be configured the NRPE server is the Nagios daemon for executing plug-ins on remote hosts Each of the Serial Ports and each of the Hosts connected to the console server which are to be monitored must have Nagios enabled and any specific Nagios checks configured Lastly the central/upstream Nagios monitoring host must be configured
10.3.1 Enable Nagios on the console server Select System: Nagios on the console server Management Console and tick the Nagios service Enabled
Enter the Nagios Host Name that the Console server will be referred to in the Nagios central server this will be generated from local System Name (entered in System: Administration) if unspecified In Nagios Host Address enter the IP address or DNS name that the upstream Nagios server will use to reach the console server if unspecified this will default to the first network ports IP (Network (1) as entered in System: IP) In Nagios Server Address enter the IP address or DNS name that the the console server will use to reach the upstream Nagios monitoring server Check the Disable SDT Nagios Extensions option if you wish to disable the SDT Connector integration with your Nagios server at the head end this would only be checked if you want to run a vanilla Nagios monitoring
Console Server User Manual Page 149 of 261 If not, enter the IP address or DNS name the SDT Nagios clients will use to reach the console server in SDT Gateway Address When NRPE and NSCA are both enabled, NSCA is preferred method for communicating with the upstream Nagios server check Prefer NRPE to use NRPE whenever possible (i.e. for all communication except for alerts)
10.3.2 Enable NRPE monitoring
Enabling NRPE allows you to execute plug-ins (such as check_tcp and check_ping) on the remote Console server to monitor serial or network attached remote servers. This will offload CPU load from the upstream Nagios monitoring machine which is especially valuable if you are monitoring hundreds or thousands of hosts. To enable NRPE:
Select System: Nagios and check NRPE Enabled Enter the details the user connection to the upstream Nagios monitoring server and again refer the sample Nagios configuration example below for details of configuring specific NRPE checks By default the console server will accept a connection between the upstream Nagios monitoring server and the NRPE server with SSL encryption, without SSL, or tunneled through SSH. The security for the connection is configured at the Nagios server.
Console Server User Manual Page 150 of 261 10.3.3 Enable NSCA monitoring
NSCA is the mechanism that allows you to send passive check results from the remote console server to the Nagios daemon running on the monitoring server. To enable NSCA:
Select System: Nagios and check NSCA Enabled Select the Encryption to be used from the drop down menu, then enter a Secret password and specify a check Interval Refer the sample Nagios configuration section below for some examples of configuring specific NSCA checks
10.3.4 Configure selected Serial Ports for Nagios monitoring The individual Serial Ports connected to the console server to be monitored must be configured for Nagios checks. Refer Chapter 4.4 Network Host Configuration for details on enabling Nagios monitoring for Hosts that are network connected to the console server. To enable Nagios to monitor on a device connected to the console server serial port: Select Serial&Network: Serial Port and click Edit on the serial Port # to be monitored
Console Server User Manual Page 151 of 261 Select Enable Nagios, specify the name of the device on the upstream server and determine the check to be run on this port. Serial Status monitors the handshaking lines on the serial port and Check Port monitors the data logged for the serial port
10.3.5 Configure selected Network Hosts for Nagios monitoring The individual Network Hosts connected to the console server to be monitored must also be configured for Nagios checks: Select Serial&Network: Network Port and click Edit on the Network Host to be monitored
Select Enable Nagios, specify the name of the device as it will appear on the upstream Nagios server Click New Check to add a specific check which will be run on this host Select Check Permitted TCP/UDP to monitor a service that you have previously added as a Permitted Service Select Check TCP/UDP to specify a service port that you wish to monitor, but do not wish to allow external (SDT Connector) access to Select Check TCP to monitor
The Nagios Check nominated as the check-host-alive check is the check used to determine whether the network host itself is up or down Typically this will be Check Ping although in some cases the host will be configured not to respond to pings If no check-host-alive check is selected, the host will always be assumed to be up You may deselect check-host-alive by clicking Clear check-host-alive If required, customize the selected Nagios Checks to use custom arguments Click Apply
10.3.6 Configure the upstream Nagios monitoring host Refer to the Nagios documentation (http://www.nagios.org/docs/) for configuring the upstream server: The section entitled Distributed Monitoring steps through what you need to do to configure NSCA on the upstream server (under Central Server Configuration) NRPE Documentation has recently been added which steps through configuring NRPE on the upstream server http://nagios.sourceforge.net/docs/nrpe/NRPE.pdf At this stage, Nagios at the upstream monitoring server has been configured, and individual serial port and network host connections on the console server configured for Nagios monitoring. If NSCA is enabled, each selected check will be executed once over the period of the check interval. If NRPE is enabled, then the upstream server will be able to request status updates under it's own scheduling.
10.4 Advanced Distributed Monitoring Configuration 10.4.1 Sample Nagios configuration An example configuration for Nagios is listed below. It shows how to set up a remote Console server to monitor a single host, with both network and serial connections. For each check it has two configurations, one each for NRPE and NSCA. In practice, these would be combined into a single check which used NSCA as a primary method, falling back to NRPE if a check was late for details see the Nagios documentation (http://www.nagios.org/docs/) on Service and Host Freshness Checks ; Host definitions ; ; Opengear Console server define host{ use generic-host host_name opengear alias Console server address 192.168.254.147 }
; Managed Host define host{ use generic-host host_name server alias server address 192.168.254.227 }
Console Server User Manual Page 154 of 261 service_description Serial Status host_name server use generic-service check_command check_serial_status }
define service { service_description serial-signals-server host_name server use generic-service check_command check_serial_status active_checks_enabled 0 passive_checks_enabled 1 }
define servicedependency{ name opengear_nrpe_daemon_dep host_name opengear dependent_host_name server dependent_service_description Serial Status service_description NRPE Daemon execution_failure_criteria w,u,c }
Console Server User Manual Page 155 of 261 host_name opengear dependent_host_name server dependent_service_description Port Log service_description NRPE Daemon execution_failure_criteria w,u,c }
Console Server User Manual Page 156 of 261 use generic-service check_command check_conn_via_opengear!tcp!22 }
define service { service_description host-port-tcp-22-server ; host-port-<protocol>-<port>-<host> host_name server use generic-service check_command check_conn_via_opengear!tcp!22 active_checks_enabled 0 passive_checks_enabled 1 }
define servicedependency{ name opengear_nrpe_daemon_dep host_name opengear dependent_host_name server dependent_service_description SSH Port service_description NRPE Daemon execution_failure_criteria w,u,c }
10.4.2 Basic Nagios plug-ins Plug-ins are compiled executables or scripts that can be scheduled to be run on the console server to check the status of a connected host or service. This status is then communicated to the upstream Nagios server which uses the results to monitor the current status of the distributed network. Each console server is preconfigured with a selection of the checks that are part of the Nagios plug-ins package: check_tcp and check_udp are used to check open ports on network hosts check_ping is used to check network host availability check_nrpe is used to execute arbitrary plug-ins in other devices Each console server is preconfigured with two checks that are specific to Opengear: check_serial_signals is used to monitor the handshaking lines on the serial ports check_port_log is used to monitor the data logged for a serial port.
10.4.3 Additional plug-ins (IMG4xxx and IM42xx only) Additional Nagios plug-ins (listed below) are available for all the IMG/IM4000 products:
Console Server User Manual Page 157 of 261 check_apt check_by_ssh check_clamd check_dig check_dns check_dummy check_fping check_ftp check_game check_hpjd check_http check_imap check_jabber check_ldap check_load check_mrtg check_mrtgtraf check_nagios check_nntp check_nntps check_nt check_ntp check_nwstat check_overcr check_ping check_pop check_procs check_real check_simap check_smtp check_snmp check_spop check_ssh check_ssmtp check_swap check_tcp check_time check_udp check_ups check_users These plug-ins from the Nagios plug-ins package can be downloaded from ftp.opengear.com. There also are bash scripts which can be downloaded and run (primarily check_log.sh). To configure additional checks the downloaded plug-in program must be saved in the tftp addins directory on the USB flash and the downloaded text plug-in file saved in /etc/config To enable these new additional checks you select Serial&Network: Network Port, then Edit the Network Host to be monitored, and select New Checks. The additional check option will have been included in the updated Nagios Checks list, and you can again customize the arguments
If you need other plug-ins to be loaded into the IMG/IM4000 firmware: If the plug-in in a Perl script, it must be rewritten as the console server does not support Perl at this point. However, if you do require Perl support, please make a feature request to [email protected] Individual compiled programs may be generated using gcc for ARM. Again contact [email protected] for details
Opengear console server User Manual Page 158 of 261
10.4.4 Number of supported devices Ultimately the number of devices that can be supported by any particular console server is a function of the number of checks being made, and how often they are performed. Access method will also play a part. The table below shows the performance of three of the console server models (1/2 port, 8 port and 16/48 port) tabulating: Time No encryption 3DES SSH tunnel NSCA for single check ~ second ~ second ~ second NSCA for 100 sequential checks 100 seconds 100 seconds 100 seconds NSCA for 10 sequential checks, batched upload 1 seconds 2 seconds 1 second NSCA for 100 sequential checks, batched upload 7 seconds 11 seconds 6 seconds
No encryption SSL no encryption - tunneled over existing SSH session NRPE time to service 1 check 1/10 th second 1/3 rd
second 1/8 th second NRPE time to service 10 simultaneous checks 1 second 3 seconds 1 seconds Maximum number of simultaneous checks before timeouts 30 20 (1,2 and 8) or 25 (16 and 48 port) 25 (1,2 and 8 port), 35 (16 and 48 port)
The results were from running tests 5 times in succession with no timeouts on any runs. However there are a number of ways to increase the number of checks you can do: Usually when using NRPE checks, an individual request will need to set up and tear down an SSL connection. This overhead can be avoided by setting up an SSH session to the console server and tunneling the NRPE port. This allows the NRPE daemon to be run securely without SSL encryption, as SSH will take care of the security. When the console server submits NSCA results it staggers them over a certain time period (e.g. 20 checks over 10 minutes will result in two check results every minute). Staggering the results like this means that in the event of a power failure or other incident that causes multiple problems, the individual freshness checks will be staggered too. NSCA checks are also batched. So in the previous example the two checks per minute will be sent through in a single transaction.
Opengear console server User Manual Page 159 of 261 10.4.5 Distributed Monitoring Usage Scenarios Below are a number of distributed monitoring Nagios scenarios: Local office In this scenario, the console server is set up to monitor the console of each managed device. It can be configured to make a number of checks, either actively at the Nagios server's request, or passively at preset intervals, and submit the results to the Nagios server in a batch. The console server may be augmented at the local office site by one or more Intelligent Power Distribution Units (IPDUs) to remotely control the power supply to the managed devices. ]
Local office using IMG4216-25 In this scenario the IMG4216-25 is used to provide the management network in the office. The IMG4216-25 has sixteen serial ports for monitoring the consoles of managed devices, or to interface to an IPDU. It also has a total of 25 Ethernet ports, of which 24 are designed to be connected to management network ports or service processors. The IMG4216-25 provides secured, audited, and easily managed access to the management network. Further, each of the Ethernet ports is isolated from the others, meaning each managed device is unable to interfere with other managed devices, including sniffing data.
Opengear console server User Manual Page 160 of 261
A similar solution is to use an IM4216-2 or IM4248-2 and connect its second Ethernet port up to an external switch to provide the management network connections:
Remote site In this scenario the console server NRPE server or NSCA client can be configured to make active checks of configured services and upload to the Nagios server waiting passively. It can also be configured to service NRPE commands to perform checks on demand. In this situation, the console server will perform checks based on both serial and network access.
Remote site with restrictive firewall In this scenario the role of the console server will vary. One aspect may be to upload check results through NSCA. Another may be to provide an SSH tunnel to allow the Nagios server to run NRPE commands.
Opengear console server User Manual Page 161 of 261
Remote site with no network access In this scenario the console server allows dial-in access for the Nagios server. Periodically, the Nagios server will establish a connection to the console server and execute any NRPE commands, before dropping the connection
Opengear console server User Manual Page 162 of 261
Chapter 11 System Management
SYSTEM MANAGEMENT Introduction This chapter describes how the Administrator can perform a range of general console server system administration and configuration tasks such as: Applying Soft and Hard Resets to the gateway Reflashing the Firmware Configuring the Date, Time and NTP
System administration and configuration tasks are covered elsewhere include: Resetting the System Password and entering a new System Name and Description for the Console server (Chapter 3.2) Setting the gateways System IP Address (Chapter 3. 3) Setting the permitted Services by which to access the gateway (Chapter 3.4) Setting up OoB Dial-in (Chapter 5)
11.1 System Administration and Reset The Administrator can reboot or reset the gateway to default settings. A soft reset is affected by: Selecting Reboot in the System: Administration menu and clicking Apply
The console server reboots with all settings (e.g. the assigned network IP address) preserved. However this soft reset does disconnect all Users and ends any SSH sessions that had been established. A soft reset will also be affected when you switch OFF power from the console server, and then switch the power back ON. However if you cycle the power and the unit is writing to flash you could corrupt or lose data, so the software reboot is the safer option. A hard erase (hard reset) is effected by:
Opengear console server User Manual Page 163 of 261 Pushing the Erase button on the rear panel twice. A ball point pen or bent paper clip is a suitable tool for performing this procedure. Do not use a graphite pencil. Depress the button gently twice (within a 5 second period) while the unit is powered ON. This will reset the console server back to its factory default settings and clear the console servers stored configuration information.
The hard erase will clear all custom settings and return the unit back to factory default settings (i.e. the IP address will be reset to 192.168.0.1). You will be prompted to log in and must enter the default administration username and administration password: Username: root Password: default
11.2 Upgrade Firmware Before upgrading you should ascertain if you are already running the most current firmware in your gateway. Your console server will not allow you to upgrade to the same or an earlier version. The Firmware version is displayed in the header of each page
Or select Status: Support Report and note the Firmware Version
To upgrade, you first must download the latest firmware image from ftp://ftp.opengear.com : o For CM4001 download the cm4002.flash file o For CM4008 download the cm4008.flash file and o For both CM4116 and CM4148 download cm41xx.flash
Opengear console server User Manual Page 164 of 261 o For IM4216-2, IM4216-25 and IM4148-2 download im42xx.flash
Save this downloaded firmware image file on to a system on the same subnet as the console server
Also download and read the release_notes.txt for the latest information To then up-load the firmware image file to your console server, select System: Firmware Specify the address and name of the downloaded Firmware Upgrade File, or Browse the local subnet and locate the downloaded file Click Apply and the console server appliance will undertake a soft reboot and commence upgrading the firmware. This process will take several minutes
After the firmware upgrade has completed, click here to return to the Management Console. Your console server will have retained all its pre-upgrade configuration information
11.3 Configure Date and Time It is recommended that you set the local Date and Time in the console server as soon as it is configured. Features like Syslog and NFS logging, use the system time for time-stamping log entries, while certificate generation depends on a correct Timestamp to check the validity period of the certificate.
Opengear console server User Manual Page 165 of 261
Select the System: Date & Time menu option Manually set the Year, Month, Day, Hour and Minute using the Date and Time selection boxes, then click Apply The gateway can synchronize its system time with a remote time server using the Network Time Protocol (NTP). Configuring the NTP time server ensures that the console server clock will be accurate soon after the Internet connection is established. Also if NTP is not used, the system clock will be reset randomly every time the console server is powered up. To set the system time using NTP: Select the Enable NTP checkbox on the Network Time Protocol page Enter the IP address of the remote NTP Server and click Apply You must now also specify your local time zone so the system clock can show local time (and not UTP): Set your appropriate region/locality in the Time Zone selection box and click Apply
Opengear console server User Manual Page 166 of 261
Chapter 12 Status Reports
STATUS REPORTS Introduction This chapter describes the selection of status reports that are available for review: Port Access and Active Users Statistics Support Reports Syslog UPS Status
12.1 Port Access and Active Users The Administrator can see which Users have access privileges with which serial ports: Select the Status: Port Access
The Administrator can also see the current status as to Users who have active sessions on those ports: Select the Status: Active Users
12.2 Statistics The Statistics report provides a snapshot of the data traffic and other activities and operations of your console server
Opengear console server User Manual Page 167 of 261
12.3 Support Reports The Support Report provides useful status information that will assist the Opengear technical support team to solve any problems you may experience with your console server. If you do experience a problem and have to contact support, ensure you include the Support Report with your email support request. The Support Report should be generated when the issue is occurring, and attached in plain text format.
Opengear console server User Manual Page 168 of 261 Select the Status: Support Report menu option and you will be presented with a snapshot of your gateways status Save the file as a text file and attach it to your support email
12.4 Syslog The Linux System Logger maintains a record of all system messages and errors: Select Status: Syslog
Remote System Logging The syslog record can be redirected to a remote Syslog Server: Enter the remote Syslog Server address and port details and click Apply
Local System Logging To view the local Syslog file: Select Alerts & Logging: Syslog To make it easier to find information in the local Syslog file, a pattern matching filter tool is provided. Specify the Match Pattern that is to be searched for (e.g. the search for Mount is shown below) and click Apply. The Syslog will then be represented with only those entries that actually include the specified pattern
Opengear console server User Manual Page 169 of 261
Chapter 13 Management
MANAGEMENT Introduction The console server has a number of Management reports and tools that can be accessed by both Administrators and Users: Access and control configured devices View serial port logs and host logs Use SDT Connector or the java terminal to access serially attached consoles Power control
13.1 Device Management To display all the connected Serial devices, Network Hosts and Power devices: Select Manage: Devices. By then selecting the Serial/ Network/ Power item, the display will be reduced to such devices only
The user can take a range of actions on each of these Serial/Network/Power devices by selecting the Action icon or the related Manage menu item. Selecting the Manager Power icon or the Manage: Power menu for is covered in Chapter 8.
Opengear console server User Manual Page 170 of 261
13.2 Port Log Management Administrator and Users can view logs of data transfers to connected devices. Select Manage: Port Logs and the serial Port # to be displayed
To display Host logs select Manage: Host Logs and the Host to be displayed
13.3 Serial Port Terminal Connection
Administrator and Users can communicate directly with the console server command line and with devices attached to the console server serial ports using SDT Connector and their local tenet client, or using a java terminal in their browser Select Manage: Terminal
Click Connect to SDT Connector to access the IM/IMG/CM4000's command line shell or the serial ports via SDT Connector. This will to activate the SDT Connector client on the computer you are browsing and load your local telnet client to connect to the command line or serial port using SSH
Opengear console server User Manual Page 171 of 261
Note SDT Connector 1.5.0 or later must be installed on the computer you are browsing from and the IM/IMG/CM console server must be added as a gateway - as detailed in Chapter 6
The alternate to using SDT Connector and your local telnet client is to download the open source jcterm java terminal applet into your browser to connect to the console server and attached serial port devices. However jcterm does have some JRE compatibility issues which may prevent it from loading. Select Manage: Terminal. The jcterm java applet is downloaded from the console server to your browser and the virtual terminal will be displayed Select File -> Open SHELL Session from the jcterm menu to access the command line using SSH To access the IM/IMG/CM4000's command line enter the gateways TCP address (e.g. 192.168.254.198) as hostname and the Username e.g. [email protected] Then enter the Password To access the console server's serial ports append :serial to the username e.g. with the gateways TCP address (e.g. 192.168.254.198), the Username (e.g. root) enter root:[email protected] Then enter Password and select the TCP Port address for the serial port to be accessed. By default 3001 is selected (i.e. Port 1). To access Port 4 for example, this must be changed to 3004 for the Username
Opengear console server User Manual Page 173 of 261
Chapter 14 Basic Configuration - Linux Commands
BASIC CONFIGURATION - LINUX COMMANDS Introduction For those who prefer to configure their console server at the Linux command line level (rather than use a browser and the Management Console), this chapter describes getting command line access and using the config tool to manage the system and configure the ports etc. from the command line: Administration Configuration (System Settings and Authentication Configuration) Date and Time Configuration (Manually Change Clock Settings and Network Time Protocol Time Zone) Network Configuration (Static and DHCP IP Configuration, Dial-in Configuration and Services Configuration) Serial Port Configuration (Serial Port Settings, Supported Protocol Configuration, Users and Trusted Networks) Event Logging Configuration (Remote Serial Port Log Storage and Alert Configuration) The config documentation in this chapter walks thru basic configuration (in line with what can be done with the Management Console). For advanced and custom configurations using other standard commands refer to the next chapter, Advanced Configuration. The console server runs a standard Linux kernel so it is also possible to configure the gateway using other standard Linux and Busybox commands and applications (ifconfig, gettyd, stty etc.) However doing this will not guarantee these changes are permanent.
This chapter is not intended to teach you Linux. We assume you already have a certain level of understanding before you execute Linux kernel level commands.
Opengear console server User Manual Page 174 of 261 14.1 The Linux Command line
Power up the console server and connect the terminal device:
o If you are connecting using the serial line, plug a serial cable between the console server local DB-9 port and terminal device. Configure the serial connection of the terminal device/program you are using to 115200bps, 8 data bits, no parity and one stop bit. If you are using a program running on a Windows PC as the terminal device, then the cable is made up from a Cat5 UTP (#440016) cable and two DB-9 to RJ-45 adapters (#319000 and #319001)
o If you are connecting over the LAN then you will need to interconnect the Ethernet ports and direct your terminal emulator program to the IP address of the console server (192.168.0.1 by default)
Log on to the console server by pressing return a few times. The console server will request a username and password. Enter the username root and the password default. You should now see the command line prompt which is a hash (#)
The config Tool Syntax config [ -ahv ] [ -d id ] [ -g id ] [ -p path ] [ -r configurator ] [ -s id=value ]
Description The config tool allows manipulation and querying of the system configuration from the command line. Using config, the new configuration can be activated by running the relevant configurator which performs the action necessary to make the configuration changes live. Configuration elements which can be changed are specified by a unique '.' separated name. For example the configuration file version is identified as 'config.version'. The config tool is designed to perform multiple actions from one command if need be, so if necessary options can be chained together.
Options -a run-all Run all registered configurators. This performs every configuration synchronization action pushing all changes to the live system
Opengear console server User Manual Page 175 of 261 -h help Display a brief usage message. -v verbose Log extra debug information -d del=id Remove the given configuration element specified by a '.' separated identifier. -g get=id Display the value of a configuration element. -p path=file Specify an alternate configuration file to use. The default file is located at /etc/config/config.xml -r run=configurator Run the specified registered configurator. Registered configurators are listed below. -s --set=id=value Change the value of configuration element specified by a '.' separated identifier -e --export=file Save active configuration to file. -i --import=file Load configuration from file. -t --test-import=file Pretend to load configuration from file. -S --separator=char The pattern to separate fields with, default is '.'.
Opengear console server User Manual Page 176 of 261 System Name og.mydomain.com System Password (root account) secret System SMTP Server 192.168.0.124 System SMTP Sender [email protected]
The following commands must be issued: # /bin/config -set=config.system.name=og.mydomain.com # /bin/config -set=config.system.password= #secret # /bin/config -set=config.system.smtp.server=192.168.0.124 # /bin/config [email protected]
The following command will synchronize the live system with the new configuration: # /bin/config -run=systemsettings
The Opengear console server does not store user passwords in plain text so when manually setting the passwords using config -set you need to hash thesecretand enter the hashed password (#secret). (One easy way to generate a hashed password is to run perl -e 'print crypt("", "")' on a Perl enabled box)
Authentication Configuration You can configure the system remote authentication with the following settings: Remote Authentication Method LDAP Server IP Address 192.168.0.32 Server Password Secret LDAP Base Node Some base node By issuing the following commands: # /bin/config -set=config.auth.type=LDAP # /bin/config -set=config.auth.server=192.168.0.32 # /bin/config -set=config.auth.password=Secret # /bin/config -set=config.auth.ldap.basenode=some base node The following command will synchronize the live system with the new configuration.
Opengear console server User Manual Page 177 of 261 # /bin/config -run=auth
14.3 Date and Time Configuration
Manually Change Clock Settings
To change the running system time you need to issue the following commands: # date 092216452005.05 Format is MMDDhhmm[[CC]YY][.ss] Then the following command will save this new system time to the hardware clock: # /bin/hwclock systohc
Alternately to change the hardware clock time you need to issue the following commands: # /bin/hwclock --set --date=092216452005.05 Where the format is MMDDhhmm[[CC]YY][.ss] Then the following command will save this new hardware clock time as the system time: # /bin/hwclock hctosys
Network Time Protocol To enable NTP using a server at pool.ntp.org issue the following commands: # /bin/config -set=config.ntp.enabled=on # /bin/config -set=config.ntp.server=pool.ntp.org The following command will synchronize the live system with the new configuration. # /bin/config -run=time
Time Zone To change the system time zone USA eastern standard time you need to issue the following commands: # /bin/config -set=config.system.timezone=US/Eastern
Opengear console server User Manual Page 178 of 261 The following command will synchronize the live system with the new configuration. # /bin/config -run=time
14.4 Network Configuration
IP Configuration Please note that supported interface modes are 'dhcp' and 'static':
DHCP To enable a DHCP client on the primary Network interface (eth0) from the gateway command line:
# /bin/config --set=config.interfaces.wan.mode=dhcp Note: In early firmware pre 2.3 the command used interfaces.eth0 rather than interfaces.wan The following command will then synchronize the live system with the new configuration. # /bin/config -run=ipconfig Note: /bin/config commands can be combined into one command for convenience. Please note that supported interface modes are 'dhcp' and 'static'.
Static To set static configuration on the primary Network interface with the following attributes:
Opengear console server User Manual Page 179 of 261 You would need to issue the following commands from the command line: # /bin/config --set=config.interfaces.wan.mode=static # /bin/config --set=config.interfaces.wan.address=192.168.1.100 # /bin/config --set=config.interfaces.wan.netmask=255.255.255.0 # /bin/config --set=config.interfaces.wan.gateway=192.168.1.1 # /bin/config --set=config.interfaces.wan.dns1=192.168.1.254 # /bin/config --set=config.interfaces.wan.dns2=10.1.0.254 The following command will synchronize the live system with the new configuration. # /bin/config -run=ipconfig Note: In early firmware pre 2.3 the command used interfaces.eth0 rather than interfaces.wan
Dial-in Configuration To enable dial-in access on the DB9 serial port from the command line with the following attributes: Local IP Address 172.24.1.1 Remote IP Address 172.24.1.2 Authentication Type: MSCHAPv2 Serial Port Baud Rate: 115200 Serial Port Flow Control: Hardware Custom Modem Initialization: ATQ0V1H0 You would need to issue the following commands from the command line to set system configuration: # /bin/config -set=config.console.ppp.localip=172.24.1.1 # /bin/config -set=config.console.ppp.remoteip=172.24.1.2 # /bin/config -set=config.console.ppp.auth=MSCHAPv2 # /bin/config -set=config.console.ppp.enabled=on # /bin/config -set=config.console.speed=115200 # /bin/config -set=config.console.flow=Hardware # /bin/config -set=config.console.initstring=ATQ0V1H0 The following command will synchronize the live system with the new configuration. # /bin/config -run=dialin
Opengear console server User Manual Page 180 of 261 Please note that supported authentication types are 'None', 'PAP', 'CHAP' and 'MSCHAPv2'. Supported serial port baud-rates are '9600', '19200', '38400', '57600', '115200', and '230400'. Supported parity values are 'None', 'Odd', 'Even', 'Mark' and 'Space'. Supported data-bits values are '8', '7', '6' and '5'. Supported stop-bits values are '1', '1.5' and '2'. Supported flow-control values are 'Hardware', 'Software' and 'None'. If you do not wish to use out-of-band dial-in access please note that the procedure for enabling start-up messages on the console port is covered in Chapter 15 - Accessing the Console Port.
Services Configuration You can manually enable or disable network servers from the command line. For example if you wanted to guarantee the following server configuration: HTTP Server Enabled HTTPS Server Disabled Telnet Server Disabled SSH Server Enabled SNMP Server Disabled Ping Replies (Respond to ICMP echo requests) Disabled You would need to issue the following commands from the command line to set system configuration: # /bin/config -set=config.services.http.enabled=on # /bin/config -del=config.services.https.enabled # /bin/config -del=config.services.telnet.enabled # /bin/config -set=config.services.ssh.enabled=on # /bin/config -del=config.services.snmp.enabled # /bin/config -del=config.services.pingreply.enabled The following command will synchronize the live system with the new configuration. # /bin/config -run=services Note: /bin/config commands can be combined into one command for convenience.
Opengear console server User Manual Page 181 of 261
14.5 Serial Port Configuration Serial Port Settings To setup serial port 5 to use the following properties: Baud Rate 115200 Parity None Data Bits 8 Stop Bits 1 Flow Control Software You would need to issue the following commands from the command line to set the port configuration: # /bin/config -set=config.ports.port5.speed=115200 # /bin/config -set=config.ports.port5.parity=None # /bin/config -set=config.ports.port5.charsize=8 # /bin/config -set=config.ports.port5.stop=1 # /bin/config -set=config.ports.port5.flow=Software The following command will synchronize the live system with the new configuration. # /bin/config -run=serialconfig
Note that supported serial port baud-rates are 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400, 4800, 9600, '19200', '38400', '57600', '115200', and '230400'.
Supported parity values are 'None', 'Odd', 'Even', 'Mark' and 'Space'. Supported data-bits values are '8', '7', '6' and '5'. Supported stop-bits values are '1', '1.5' and '2'. Supported flow-control values are 'Hardware', 'Software' and 'None'.
Supported Protocol Configuration To ensure remote access to serial port 5 is configured as follows:
Opengear console server User Manual Page 182 of 261 Telnet Access LAN Disabled SSH Access LAN Enabled Raw TCP via LAN Disabled You would need to issue the following commands from the command line to set system configuration: # /bin/config -set=config.ports.port5.ssh=on # /bin/config -del=config.ports.port5.telnet # /bin/config -del=config.ports.port5.tcp
The following command will synchronize the live system with the new configuration. # /bin/config -run=serialconfig Note: /bin/config commands can be combined into one command for convenience.
Users You can add a User to the system from the command line by following the following instructions: Determine the total number of existing Users (if you have no existing Users) you can assume this is 0. # /bin/config -get=config.users.total This command should display: config.users.total 1 Note that if you see: config.users.total This means you have 0 Users configured. So your new User will be the existing total plus 1 so if the previous command gave you 0 then you start with user number 1, if you already have 1 user your new user will be number 2 etc. If you want a user named user1 with a password of secret who will have access to serial port 5 from the network you need to issue the these commands (assuming you have a previous user in place): # /bin/config -set=config.users.user2.username=user1
Opengear console server User Manual Page 183 of 261 # /bin/config -set=config.users.user2.password=secret # /bin/config -set=config.users.user2.description=The Second User # /bin/config -set=config.users.user2.port5=on # /bin/config -set=config.users.total=2 The following command will synchronize the live system with the new configuration. # /bin/config -run=users
Trusted Networks You can further restrict remote access to serial ports based on the source IP address. To configure this via the command line you need to do the following: Determine the total number of existing trusted network rules (if you have no existing rules) you can assume this is 0. # /bin/config -get=config.portaccess.total This command should display: config.portaccess.total 1 Note that if you see: config.portaccess.total This means you have 0 rules configured. Your new rule will be the existing total plus 1. So if the previous command gave you 0 then you start with rule number 1. If you already have 1 rule your new rule will be number 2 etc. If you want to restrict access to serial port 5 to computers from a single C class network 192.168.5.0, you need to issue the following commands (assuming you have a previous rule in place): # /bin/config -set=config.portaccess.rule2.address=192.168.5.0 # /bin/config -set=config.portaccess.rule2.netmask=255.255.255.0 # /bin/config -set=config.portaccess.rule2.description=foo bar. # /bin/config -set=config.portaccess.rule2.port5=on # /bin/config -set=config.portaccess.total=2 Please note that this rule becomes live straight away.
Opengear console server User Manual Page 184 of 261 14.6 Event Logging Configuration Remote Serial Port Log Storage To setup remote storage of serial port 5 log to a remote Windows share with the following properties: IP Address 192.168.0.254 Directory C:\\opengear\logs\ Username cifs_user Password secret Logging level 2 (input/output logging as well as user connections & disconnections) The following commands must be issued: # /bin/config -set=config.eventlog.server.type=cifs # /bin/config -set=config.eventlog.server.address=192.168.0.254 # /bin/config -set=config.eventlog.server.path=/opengear/logs # /bin/config -set=config.eventlog.server.username=cifs_user # /bin/config -set=config.eventlog.server.password=secret # /bin/config -set=config.ports.port5.loglevel=2 The following command will synchronize the live system with the new configuration. # /bin/config -run=eventlog Note that supported remote storage server types are 'None', 'cifs', 'nfs' and 'syslog'. Supported port logging levels are '0', '1' and '2'. Alert Configuration You can add an email alert to the system from the command line by following these instructions: Determine the total number of existing alerts (if you have no existing alerts) you can assume this is 0. # /bin/config -get=config.alerts.total This command should display output similar to: config.alerts.total 1
Opengear console server User Manual Page 185 of 261 Note that if you see: config.alerts.total This means you have 0 alerts configured. Your new alert will be the existing total plus 1. So if the previous command gave you 0 then you start with user number 1. If you already have 1 alert your new alert will be number 2 etc. To configure an email alert to be sent to [email protected] when the regular expression Cpu.*0.0% id, matches logging on serial port 5 you would need to issue the following commands (Assuming you have 1 previous alert in place): # /bin/config [email protected] # /bin/config -set=config.alerts.alert2.pattern=.*0.0% id, # /bin/config -set=config.alerts.alert2.port5=on # /bin/config -del=config.alerts.total=2 The following command will synchronize the live system with the new configuration. # /bin/config -run=alerts
14.7 SDT Host Configuration SDT host TCP Ports
To setup the list of tcp ports for a host, you use the config command: # config -s config.sdt.hosts.host3.tcpports.tcport1 = 23 # config -s config.sdt.hosts.host3.tcpports.tcport2 = 5900 # config -s config.sdt.hosts.host3.tcpports.tcport3 = 3389
The above assumes the config below: # vi /etc/config/config.xml ~ </users> </host1> <total>3</total> <host2> <address>accounts.intranet.myco.com</address>
Opengear console server User Manual Page 186 of 261 <description>Accounts server</description> <users> <total>1</total> <user1>JohnWhite</user1> </users> </host2> <host3> <address>192.168.254.191</address> <description>Tonys Win2000 Box</description> <users> <total>1</total> <user1>JohnWhite</user1> </users> <tcpports><tcpport1>23</tcpport1></tcpports> </host3> </hosts> </sdt> </config>
14.8 Configuration backup and restore Before backing up the configuration, you need to arrange a way to transfer the backup off-box. This could be via an NFS share, a Samba (Windows) share to USB storage or copied off-box via the network. If backing up directly to off-box storage, make sure it is mounted.
/tmp is not a good location for the backup except as a temporary location before transferring it off-box. The /tmp directory will not survive a reboot. The /etc/config directory is not a good place either, as it will not survive a restore.
Backup and restore should be done by the root user to ensure correct file permissions are set. The config command is used to create a backup tarball:
Opengear console server User Manual Page 187 of 261 The tarball will be saved to the indicated location. It will contain the contents of the /etc/config/ directory in an uncompressed and unencrypted form.
The config command is also used to restore a backup:
config -i <Input File>
This will extract the contents of the previously created backup to /tmp, and then synchronize the /etc/config directory with the copy in /tmp.
One problem that can crop up here is that there is not enough room in /tmp to extract files to. The following command will temporarily increase the size of /tmp:
mount -t tmpfs -o remount,size=2048k tmpfs /var
If restoring to either a new unit or one that has been factory defaulted, it is important to make sure that the process generating SSH keys is either stopped or completed before restoring configuration. If this is not done, then a mix of old and new keys may be put in place.
As SSH uses these keys to avoid man-in-the-middle attacks, logging in may be disrupted.
Opengear console server User Manual Page 188 of 261
Chapter 15 Advanced Configuration
ADVANCED CONFIGURATION Introduction This chapter documents Opengears portmanager application for gateway serial port management and gives examples of its use: portmanager documentation Scripts and alerts Raw data access to the ports and modems This chapter also describes details how to perform advanced and custom management tasks using Linux commands and script: iptables modifications and updating IP Filtering rules modifying SNMP with net-snmpd Public key authenticated SSH communications SSL, configuring HTTPS and issuing certificates using the pmpower application for power device management adding new Power Strips and Power Strip control using IPMItools CDK custom development kit
Opengear console server User Manual Page 189 of 261 15.1 Advanced Portmanager pmshell The pmshell command acts similar to the standard tip or cu commands, but all serial port access is directed via the portmanager. Example: To connect to port 8 via the portmanager: # pmshell -l port08
pmshell Commands: Once connected, the pmshell command supports a subset of the '~' escape commands that tip/cu support. For SSH you must prefix the escape with an additional ~ command (i.e. use the ~~ escape) Send Break: Typing the character sequence '~b' will generate a BREAK on the serial port. History: Typing the character sequence '~h' will generate a history on the serial port. Quit pmshell: Typing the character sequence '~.' will exit from pmshell. Set RTS to 1 run the command:
# pmshell --rts=1
Show all signa # pmshell signals
DSR=1 DTR=1 CTS=1 RTS=1 DCD=0
Read a line of text from the serial port: # pmshell getline
Opengear console server User Manual Page 190 of 261
pmchat The pmchat command acts similar to the standard chat command, but all serial port access is directed via the portmanager. Example: To run a chat script via the portmanager: # pmchat -v -f /etc/config/scripts/port08.chat < /dev/port08
For more information on using chat (and pmchat) you should consult the UNIX man pages:
The pmusers command is used to query the portmanager for active user sessions.
Example:
To detect which users are currently active on which serial ports:
# pmusers
This command will output nothing if there are no active users currently connected to any ports, otherwise it will respond with a sorted list of usernames per active port:
Port 1: user1 user2 Port 2: user1 Port 8: user2
The above output indicates that a user named user1 is actively connected to ports 1 and 2, while user2 is connected to both ports 1 and 8.
Opengear console server User Manual Page 191 of 261 Command line options There is normally no need to stop and restart the daemon. To restart the daemon normally, just run the command: # portmanager Supported command line options are: Force portmanager to run in the foreground: --nodaemon Set the level of debug logging: --loglevel={debug,info,warn,error,alert} Change which configuration file it uses: -c /etc/config/portmanager.conf Signals Sending a SIGHUP signal to the portmanager will cause it to re-read it's configuration file
15.2 External Scripts and Alerts The portmanager has the ability to execute external scripts on certain events. These events are: I. When a port is opened by the portmanager: When the portmanager opens a port, it attempts to execute /etc/config/scripts/portXX.init (where XX is the number of the port, e.g. 08). The script is run with STDIN and STDOUT both connected to the serial port. If the script cannot be executed, then portmanager will execute /etc/config/scripts/portXX.chat via the chat command on the serial port. II. When an alert occurs on a port: When an alert occurs on a port, the portmanager will attempt to execute /etc/config/scripts/portXX.alert (where XX is the port number, e.g. 08)
Opengear console server User Manual Page 192 of 261 The script is run with STDIN containing the data which triggered the alert, and STDOUT redirected to /dev/null, NOT to the serial port. If you wish to communicate with the port, use pmshell or pmchat from within the script. If the script cannot be executed, then the alert will be mailed to the address configured in the system administration section. III. When a user connects to any port:
If a file called /etc/config/pmshell-start.sh exists it is run when a user connects to a port. It is provided 2 arguments, the "Port number" and the "Username". Here is a simple example:
</etc/config/pmshell-start.sh >
#!/bin/sh
PORT="$1" USER="$2"
echo "Welcome to port $PORT $USER"
< /etc/config/pmshell-start.sh>
The return value from the script controls whether the user is accepted or not, if 0 is returned (or nothing is done on exit as in the above script) the user is permitted, otherwise the user is denied access.
Here is a more complex script which reads from configuration to display the port label if available and denies access to the root user:
Opengear console server User Manual Page 193 of 261 else echo "Welcome $USER, you are connected to Port $PORT ($LABEL)" fi </etc/config/pmshell-start.sh>
15.3 Raw Access to Serial Ports Access to Serial Ports
You can tip and stty to completely bypass the portmanager and have raw access to the serial ports. When you run tip on a portmanager controlled port, portmanager closes that port, and stops monitoring it until tip releases control of it.
With stty, the changes made to the port only "stick" until that port is closed and opened again, so it is doubtful that people will want to use stty for more than initial debugging of the serial connection.
If you want to use stty to configure the port, you can put stty commands in /etc/config/scripts/portXX.init, which gets run whenever portmanager opens the port.
Otherwise, any setup you do with stty will get lost when the portmanager opens the port. (the reason that portmanager sets things back to its config rather than using whatever is on the port, is so the port is in a known good state, and will work, no matter what things are done to the serial port outside of portmanager).
Accessing the Console Port The console dial-in is handled by mgetty, with automatic PPP login extensions. mgetty is a smart getty replacement, designed to be used with hayes compatible data and data/fax modems. mgetty knows about modem initialization, manual modem answering (so your modem doesnt answer if the machine isnt ready), UUCP locking (so you can use the same device for dial-in and dial-out). mgetty provides very extensive logging facilities. All standard mgetty options are supported.
Modem initialization strings
To override the standard modem initialization string either use the Management Console (refer Chapter 5) or the command line config tool (refer Dial-In Configuration Chapter 14).
Opengear console server User Manual Page 194 of 261
If you are not using a modem on the DB9 console port and instead wish to connect to it directly via a Null Modem cable you may want to enable verbose mode allowing you to see the standard linux start-up messages. This can be achieved with the following commands:
15.4 IP- Filtering Standard IP-Filter configuration: The system uses the iptables utility to provide a stateful firewall of LAN traffic. By default rules are automatically inserted to allow access to enabled services, and serial port access via enabled protocols. The commands which add these rules are contained in configuration files. /etc/config/ipfilter This is an executable shell script which is run whenever the LAN interface is brought up and whenever modifications are made to the iptables configuration as a result of CGI actions or the config command line tool. The basic steps performed are as follows: a) The current iptables configuration is erased. b) If a customized IP-Filter script exists it is executed and no other actions are performed. c) Standard policies are inserted which will drop all traffic not explicitly allowed to and through the system. d) Rules are added which explicitly allow network traffic to access enabled services e.g. HTTP, SNMP etc. e) Rules are added which explicitly allow traffic network traffic access to serial ports over enabled protocols e.g. Telnet, SSH and raw TCP.
Customizing the IP-Filter: /etc/config/filter-custom
Opengear console server User Manual Page 195 of 261 If the standard system firewall configuration is not adequate for your needs it can be bypassed safely by creating a file at /etc/config/filter-custom containing commands to build a specialized firewall. This firewall script will be run whenever the LAN interface is brought up (including initially) and will override any automated system firewall settings. Below is a simple example of a custom script which creates a firewall using the iptables command. Only incoming connections from computers on a C-class network 192.168.10.0 will be accepted when this script is installed at /etc/config/filter-custom (Note that when this script is called any preexisting chains and rules have been flushed from iptables): #/bin/sh # Set default policies to drop any incoming or routable traffic # and blindly accept anything from the 192.168.10.0 network. iptables -policy FORWARD DROP iptables -policy INPUT DROP iptables -policy OUTPUT ACCEPT
# Allow responses to outbound connections back in. iptables -append INPUT \ -match state -state ESTABLISHED,RELATED -jump ACCEPT
# Explicitly accept any connections from computers on # 192.168.10.0/24 iptables -append INPUT -source 192.168.10.0/24 -jump ACCEPT
Good documentation about using the iptables command can be found at the linux netfilter website http://netfilter.org/documentation/index.html
Resources There are many high-quality tutorials and HOWTOs available via the netfilter website, in particular peruse the tutorials listed on the netfilter HOWTO page. A list of useful web locations has been compiled for your convenience below: Netfilter Homepage http://netfilter.org
Opengear console server User Manual Page 196 of 261 tutorials
15.5 Modifying SNMP Configuration /etc/config/snmpd.conf The net-snmpd is an extensible SNMP agent which responds to SNMP queries for management information from SNMP management software. Upon receiving a request, it processes the request(s), collects the requested information and/or performs the requested operation(s) and returns the information to the sender. This includes built-in support for a wide range of MIB information modules, and can be extended using dynamically loaded modules, external scripts and commands. snmpd when enabled should run with a default configuration. Its behavior can be customized via the options in /etc/config/snmpd.conf. Changing standard system information such as system contact, name and location can be achieved by editing /etc/config/snmpd.conf file and locating the following lines:
sysdescr "opengear" syscontact root <root@localhost>(configure /etc/default/snmpd.conf) sysname Not defined (edit /etc/default/snmpd.conf) syslocation Not defined (edit /etc/default/snmpd.conf)
Simply change the values of sysdescr, syscontact, sysname and syslocation to the desired settings and restart snmpd. The snmpd.conf provides is extremely powerful and too flexible to completely cover here. The configuration file itself is commented extensively and good documentation is available at the net-snmp website http://www.net-snmp.org, specifically:
Man Page: http://www.net-snmp.org/docs/man/snmpd.conf.html
Opengear console server User Manual Page 197 of 261 Net-SNMPD Tutorial: http://www.net-snmp.org/tutorial/tutorial-5/demon/snmpd.html
Adding more than on SNMP server To add more than one SNMP server for alert traps add the first SNMP server using the Management Console (refer Chapter 7) or the command line config tool. Secondary and any further SNMP servers are added manually using config.
Log in to the console servers command line shell as root or an admin user. Refer back to the Management Console UI or user documentation for descriptions of each field.
To set the Manager Protocol field: config --set config.system.snmp.protocol2=UDP or config --set config.system.snmp.protocol2=TCP
To set the Manager Address field config --set config.system.snmp.address2=w.x.y.z .. replacing w.x.y.z with the IP address or DNS name.
To set the Manager Trap Port field config --set config.system.snmp.trapport2=162 .. replacing 162 with the TCP/UDP port number
To set the Version field config --set config.system.snmp.version2=1 or config --set config.system.snmp.version2=2c or config --set config.system.snmp.version2=3
To set the Community field (SNMP version 1 and 2c only) config --set config.system.snmp.community2=yourcommunityname .. replacing yourcommunityname with the community name
To set the Engine ID field (SNMP version 3 only) config --set config.system.snmp.engineid2=800000020109840301 .. replacing 800000020109840301 with the engine ID
To set the Username field (SNMP version 3 only) config --set config.system.snmp.username2=yourusername .. replacing yourusername with the username config.system.snmp.username2 (3 only)
To set the Engine ID field (SNMP version 3 only) config --set config.system.snmp.password2=yourpassword
Opengear console server User Manual Page 198 of 261 .. replacing yourpassword with the password
Once the fields are set, apply the configuration with the following command:
config --run snmp
You can add a third or more SNMP servers by incrementing the "2" in the above commands, e.g. config.system.snmp.protocol3, config.system.snmp.address3, etc.
15.6 Secure Shell (SSH) Public Key Authentication This section covers the generation of public and private keys in a Linux and Windows environment and configuring SSH for public key authentication. The steps to use in a Clustering environment are: - Generate a new public and private key pair - Upload the keys to the Master and to each Slave console server - Fingerprint each connection to validate
SSH Overview Popular TCP/IP applications such as telnet, rlogin, ftp, and others transmit their passwords unencrypted. Doing this across pubic networks like the Internet can have catastrophic consequences. It leaves the door open for eavesdropping, connection hijacking, and other network-level attacks.
Secure Shell (SSH) is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over insecure channels.
OpenSSH, the de facto open source SSH application, encrypts all traffic (including passwords) to effectively eliminate these risks. Additionally, OpenSSH provides a myriad of secure tunneling capabilities, as well as a variety of authentication methods.
OpenSSH is the port of OpenBSD's excellent OpenSSH[0] to Linux and other versions of Unix. OpenSSH is based on the last free version of Tatu Ylonen's sample implementation with all patent-encumbered algorithms removed (to external libraries), all known security bugs fixed, new features reintroduced and many other clean-ups. http://www.openssh.com/ The only changes in the Opengear SSH implementation are:
Opengear console server User Manual Page 199 of 261 EGD[1]/PRNGD[2] support and replacements for OpenBSD library functions that are absent from other versions of UNIX
The config files are now in /etc/config. e.g. o /etc/config/sshd_config instead of /etc/sshd_config o /etc/config/ssh_config instead of /etc/ssh_config o /etc/config/users/<username>/.ssh/ instead of /home/<username>/.ssh/
Generating Public Keys (Linux) To generate new SSH key pairs use the Linux ssh-keygen command. This will produce an RSA or DSA public/private key pair and you will be prompted for a path to store the two key files e.g. id_dsa.pub (the public key) and id_dsa (the private key). For example:
$ ssh-keygen -t [rsa|dsa] Generating public/private [rsa|dsa] key pair. Enter file in which to save the key (/home/user/.ssh/id_[rsa|dsa]): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_[rsa|dsa]. Your public key has been saved in /home/user/.ssh/id_[rsa|dsa].pub. The key fingerprint is: 28:aa:29:38:ba:40:f4:11:5e:3f:d4:fa:e5:36:14:d6 user@server $
It is advisable to create a new directory to store your generated keys. It is also possible to name the files after the device they will be used for. For example:
$ mkdir keys $ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): /home/user/keys/control_room Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/keys/control_room Your public key has been saved in /home/user/keys/control_room.pub. The key fingerprint is: 28:aa:29:38:ba:40:f4:11:5e:3f:d4:fa:e5:36:14:d6 user@server $
Opengear console server User Manual Page 200 of 261 You must ensure there is no password associated with the keys. If there is a password, then the Opengear devices will have no way to supply it as runtime.
Full documentation for the ssh-keygen command can be found at:
Installing the SSH Public/Private Keys (Clustering)
For Opengear gateways the keys can be simply uploaded through the web interface, on the System: Administration page. This enables you to upload stored RSA or DSA Public Key pairs to the Master and apply the Authorized key to the slave and is described in Chapter 4.6. Once complete you then proceed to Fingerprinting as described below.
Installing SSH Public Key Authentication (Linux)
Alternately the public key can be installed on the unit remotely from the linux host with the scp utility as follows:
Assuming the user on the Management Console is called "fred"; the IP address of the console server is 192.168.0.1 (default); and the public key is on the linux/unix computer in ~/.ssh/id_dsa.pub. Execute the following command on the linux/unix computer:
Opengear console server User Manual Page 201 of 261 chown fred /etc/config/users/fred/.ssh/authorized_keys
If the Opengear device selected to be the server will only have one client device, then the authorized_keys file is simply a copy of the public key for that device. If one or more devices will be clients of the server, then the authorized_keys file will contain a copy of all of the public keys. RSA and DSA keys may be freely mixed in the authorized_keys file. For example, assume we already have one server, called bridge_server, and two sets of keys, for the control_room and the plant_entrance: $ ls /home/user/keys control_room control_room.pub plant_entrance plant_entrance.pub $ cat /home/user/keys/control_room.pub /home/user/keys/plant_entrance.pub > /home/user/keys/authorized_keys_bridge_server
This section describes how to generate and configure SSH keys using Windows.
First create a new user from the Opengear Management Console on Opengear gateway (the following example users a user called "testuser") making sure it is a member of the "users" group.
If you do not already have a public/private key pair you can generate them now using ssh- keygen, PuTTYgen or a similar tool:
For example using PuTTYgen, make sure you have a recent version of the puttygen.exe (available from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) Make sure you have a recent version of WinSCP (available from http://winscp.net/eng/download.php )
To generate a SSH key using PuTTY http://sourceforge.net/docs/F02/#clients:
Execute the PUTTYGEN.EXE program Select the desired key type SSH2 DSA (you may use RSA or DSA) within the Parameters section It is important that you leave the passphrase field blank Click on the Generate button Follow the instruction to move the mouse over the blank area of the program in order to create random data used by PUTTYGEN to generate secure keys. Key generation will occur once PUTTYGEN has collected sufficient random data .
Opengear console server User Manual Page 204 of 261 Create a new file " authorized_keys " (with notepad) and copy your public key data from the "Public key for pasting into OpenSSH authorized_keys file" section of the PuTTY Key Generator, and paste the key data to the "authorized_keys" file. Make sure there is only one line of text in this file.
Use WinSCP to copy this "authorized_keys" file into the users home directory: eg. /etc/config/users/testuser/.ssh/authorized_keys of the Opengear gateway which will be the SSH server. You will need to make sure this file is in the correct format with the correct permissions with the following commands:
Using WinSCP copy the attached sshd_config over /etc/config/sshd_config on the server (Makes sure public key authentication is enabled)
Test the Public Key by logging in as "testuser" Test the Public Key by logging in as "testuser" to the client Opengear device and typing (you should not need to enter anything): # ssh -o StrictHostKeyChecking=no <server-ip>
To automate connection of the SSH tunnel from the client on every power-up you need to make the clients /etc/config/rc.local look like the following: #!/bin/sh ssh -L9001:127.0.0.1:4001 -N -o StrictHostKeyChecking=no testuser@<server-ip> &
This will run the tunnel redirecting local port 9001 to the server port 4001.
Fingerprinting Fingerprints are used to ensure you are establishing an SSH session to who you think you are. On the first connection to a remote server you will receive a fingerprint which you can use on future connections.
This fingerprint is related to the host key of the remote server. Fingerprints are stored in ~/.ssh/known_hosts.
To receive the fingerprint from the remote server, log in to the client as the required user (usually root) and establish a connection to the remote host:
Opengear console server User Manual Page 205 of 261 The authenticity of host 'remhost (192.168.0.1)' can't be established. RSA key fingerprint is 8d:11:e0:7e:8a:6f:ad:f1:94:0f:93:fc:7c:e6:ef:56. Are you sure you want to continue connecting (yes/no)?
At this stage, answer yes to accept the key. You should get the following message:
Warning: Permanently added 'remhost,192.168.0.1' (RSA) to the list of known hosts.
You may be prompted for a password, but there is no need to log in - you have received the fingerprint and can Ctrl-C to cancel the connection.
If the host key changes you will receive the following warning, and not be allowed to connect to the remote host:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is ab:7e:33:bd:85:50:5a:43:0b:e0:bd:43:3f:1c:a5:f8. Please contact your system administrator. Add correct host key in /.ssh/known_hosts to get rid of this message. Offending key in /.ssh/known_hosts:1 RSA host key for remhost has changed and you have requested strict checking. Host key verification failed.
If the host key has been legitimately changed, it can be removed from the ~/.ssh/known_hosts file and the new fingerprint added. If it has not changed, this indicates a serious problem that should be investigated immediately.
SSH tunneled serial bridging
You have the option to apply SSH tunneling when two Opengear gateways are configured for serial bridging.
Opengear console server User Manual Page 206 of 261
As detailed in Chapter 4, the Server gateway is setup in Console Server mode with either RAW or RFC2217 enabled and the Client gateway is set up in Serial Bridging Mode with the Server Address, and Server TCP Port (4000 + port for RAW or 5000 + port # for RFC2217) specified:
Select SSH Tunnel when configuring the Serial Bridging Setting
Next you will need to set up SSH keys for each end of the tunnel and upload these keys to the Server and Client gateways.
Client Keys
The first step in setting up ssh tunnels is to generate keys. Ideally, you will use a separate, secure, machine to generate and store all keys to be used on the Opengear devices. However, if this is not ideal to your situation, keys may be generated on the Opengear boxes themselves.
It is possible to generate only one set of keys, and reuse them for every SSH session. While this is not recommended, each organization will need to balance the security of separate keys against the additional administration they bring.
Opengear console server User Manual Page 207 of 261 Generated keys may be one of two types - RSA or DSA (and it is beyond the scope of this document to recommend one over the other). RSA keys will go into the files id_rsa and id_rsa.pub. DSA keys will be stored in the files id_dsa and id_dsa.pub.
For simplicity going forward the term private key will be used to refer to either id_rsa or id_dsa and public key to refer to either id_rsa.pub or id_dsa.pub.
To generate the keys using OpenBSD's OpenSSH suite, we use the ssh-keygen program:
$ ssh-keygen -t [rsa|dsa] Generating public/private [rsa|dsa] key pair. Enter file in which to save the key (/home/user/.ssh/id_[rsa|dsa]): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_[rsa|dsa]. Your public key has been saved in /home/user/.ssh/id_[rsa|dsa].pub. The key fingerprint is: 28:aa:29:38:ba:40:f4:11:5e:3f:d4:fa:e5:36:14:d6 user@server $
It is advisable to create a new directory to store your generated keys. It is also possible to name the files after the device they will be used for. For example:
$ mkdir keys $ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): /home/user/keys/control_room Enter passphrase (empty for no passphrase): Enter same passphrase again:
Opengear console server User Manual Page 208 of 261 Your identification has been saved in /home/user/keys/control_room Your public key has been saved in /home/user/keys/control_room.pub. The key fingerprint is: 28:aa:29:38:ba:40:f4:11:5e:3f:d4:fa:e5:36:14:d6 user@server $
You should ensure there is no password associated with the keys. If there is a password, then the Opengear devices will have no way to supply it as runtime.
Authorized Keys
If the Opengear device selected to be the server will only have one client device, then the authorized_keys file is simply a copy of the public key for that device. If one or more devices will be clients of the server, then the authorized_keys file will contain a copy of all of the public keys. RSA and DSA keys may be freely mixed in the authorized_keys file.
For example, assume we already have one server, called bridge_server, and two sets of keys, for the control_room and the plant_entrance: $ ls /home/user/keys control_room control_room.pub plant_entrance plant_entrance.pub $ cat /home/user/keys/control_room.pub /home/user/keys/plant_entrance.pub > /home/user/keys/authorized_keys_bridge_server
Uploading Keys
The keys for the server can be uploaded through the web interface, on the System: Administration page as detailed earlier. If only one client will be connecting, then simply upload the appropriate public key as the authorized keys file. Otherwise, upload the authorized keys file constructed in the previous step.
Each client will then need it's own set of keys uploaded through the same page. Take care to ensure that the correct type of keys (DSA or RSA) go in the correct spots, and that the public and private keys are in the correct spot.
SDT Connector Public Key Authentication
SDT Connector can authenticate against a Opengear gateway using your SSH key pair rather than requiring your to enter your password (i.e. public key authentication).
Opengear console server User Manual Page 209 of 261 To use public key authentication with SDT Connector, first you must first create an RSA or DSA key pair (using ssh-keygen, PuTTYgen or a similar tool) and add the public part of your SSH key pair to the Opengear gateway as described in the earlier section.
Next, add the private part of your SSH key pair (this file is typically named id_rsa or id_dsa) to SDT Connector client. Click Edit -> Preferences -> Private Keys -> Add, locate the private key file and click OK. You do not have to add the public part of your SSH key pair, it is calculated using the private key.
SDT Connector will now use public key authentication when SSH connecting through the Console server. You may have to restart SDT Connector to shut down any existing tunnels that were established using password authentication.
If you have a host behind the Console server that you connect to by clicking the SSH button in SDT Connector, you can also configure it for public key authentication. Essentially what you are using is SSH over SSH, and the two SSH connections are entirely separate, and the host configuration is entirely independent of SDT Connector and the Console server. You must configure the SSH client that SDT Connector launches (e.g. Putty, OpenSSH) and the host's SSH server for public key authentication.
15.7 Secure Sockets Layer (SSL) Support Secure Sockets Layer (SSL) is a protocol developed by Netscape for transmitting private documents via the Internet. SSL works by using a private key to encrypt data that's transferred over the SSL connection.
The console server includes OpenSSL. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full- strength general purpose cryptography library. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the OpenSSL toolkit and its related documentation. OpenSSL is based on the excellent SSLeay library developed by Eric A. Young and Tim J. Hudson. The OpenSSL toolkit is licensed under an Apache-style licence, which basically means that you are free to get and use it for commercial and non-commercial purposes subject to some simple license conditions. In the console server OpenSSL is used primarily in conjunction with http in order to have secure browser access to the GUI management console across insecure networks. More documentation on OpenSSL is available from:
15.8 HTTPS The Management Console can be served using HTTPS by running the webserver via sslwrap. The server can be launched on request using inetd.
The HTTP server provided is a slightly modified version of the fnord-httpd from http://www.fefe.de/fnord/
The SSL implementation is provided by the sslwrap application compiled with OpenSSL support. More detailed documentation can be found at http://www.rickk.com/sslwrap/
If your default network address is changed or the unit is to be accessed via a known Domain Name you can use the following steps to replace the default SSL Certificate and Private Key with ones tailored for your new address.
1. Generating an encryption key
To create a 1024 bit RSA key with a password issue the following command on the command line of a linux host with the openssl utility installed:
openssl genrsa -des3 -out ssl_key.pem 1024
2. Generating a self-signed certificate with OpenSSL
This example shows how to use OpenSSL to create a self-signed certificate. OpenSSL is available for most Linux distributions via the default package management mechanism. (Windows users can check http://www.openssl.org/related/binaries.html )
To create a 1024 bit RSA key and a self-signed certificate issue the following openssl command from the host you have openssl installed on:
Opengear console server User Manual Page 211 of 261 You will be prompted to enter a lot of information. Most of it doesn't matter, but the "Common Name" should be the domain name of your computer (e.g. test.opengear.com). When you have entered everything, the certificate will be created in a file called ssl_cert.pem.
3. Installing the key and certificate
The recommended method for copying files securely to the console server unit is with an SCP (Secure Copying Protocol) client. The scp utility is distributed with OpenSSH for most Unices, while Windows users can use something like the PSCP command line utility available with PuTTY.
The files created in steps 1 and 2 can be installed remotely with the scp utility as follows:
scp ssl_key.pem root@<address of unit>:/etc/config/ scp ssl_cert.pem root@<address of unit>:/etc/config/
or using PSCP:
pscp -scp ssl_key.pem root@<address of unit>:/etc/config/ pscp -scp ssl_cert.pem root@<address of unit>:/etc/config/
PuTTY and the PSCP utility can be downloaded from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
More detailed documentation on the PSCP can be found: http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter5.html#pscp
4. Launching the HTTPS Server
Note that the easiest way to enable the HTTPS server is from the web Management Console. Simply click the apropriate checkbox in Network -> Services -> HTTPS Server and the HTTPS server will be activated (assuming the ssl_key.pem & ssl_cert.pem files exist in the /etc/config directory).
Alternatively inetd can be configured to launch the secure fnord server from the command line of the unit as follows.
Edit the inetd configuration file. From the unit command line:
Save the file and signal inetd of the configuration change.
kill -HUP `cat /var/run/inetd.pid`
The HTTPS server should be accessible from a web client at a URL similar to this: https://<common name of unit>
More detailed documentation about the openssl utility can be found at the website: http://www.openssl.org/
15.9 Power Strip Control The console server supports a growing list of remote power-control devices (RPCs) which can be configured using the Management Console as described in Chapter 8. These RPCs are controlled using the open source PowerMan tools and with Opengears pmpower utility. PowerMan PowerMan provides power management in a data center or compute cluster environment. It performs operations such as power on, power off, and power cycle via remote power controller (RPC) devices. Target hostnames are mapped to plugs on RPC devices in powerman.conf powerman - power on/off nodes
Options -1, --on Power ON targets. -0, --off Power OFF targets. -c, --cycle Power cycle targets. -r, --reset Assert hardware reset for targets (if implemented by RPC). -f, --flash Turn beacon ON for targets (if implemented by RPC). -u, --unflash Turn beacon OFF for targets (if implemented by RPC). -l, --list List available targets. If possible, output will be compressed into a host range (see TARGET SPECIFICATION below). -q, --query Query plug status of targets. If none specified, query all targets. Status is not cached; each time this option is used, powermand queries the appropriate RPC's.
Opengear console server User Manual Page 213 of 261 Targets connected to RPC's that could not be contacted (e.g. due to network failure) are reported as status "unknown". If possible, output will be compressed into host ranges. -n, --node Query node power status of targets (if implemented by RPC). If no targets specified, query all targets. In this context, a node in the OFF state could be ON at the plug but operating in standby power mode. -b, --beacon Query beacon status (if implemented by RPC). If no targets are specified, query all targets. -t, --temp Query node temperature (if implemented by RPC). If no targets are specified, query all targets. Temperature information is not interpreted by powerman and is reported as received from the RPC on one line per target, prefixed by target name. -h, --help Display option summary. -L, --license Show powerman license information. -d, --destination host[:port] Connect to a powerman daemon on non-default host and optionally port. -V, --version Display the powerman version number and exit. -D, --device Displays RPC status information. If targets are specified, only RPC's matching the target list are displayed. -T, --telemetry Causes RPC telemetry information to be displayed as commands are processed. Useful for debugging device scripts. -x, --exprange Expand host ranges in query responses.
For more details refer http://linux.die.net/man/1/powerman. Also refer powermand (http://linux.die.net/man/1/powermand) documentation and powerman.conf (http://linux.die.net/man/5/powerman.conf)
Target Specification powerman target hostnames may be specified as comma separated or space separated hostnames or host ranges. Host ranges are of the general form: prefix[n-m,l-k,...], where n < m and l < k, etc., This form should not be confused with regular expression character classes (also denoted by ''[]''). For example, foo[19] does not represent foo1 or foo9, but rather represents a degenerate range: foo19. This range syntax is meant only as a convenience on clusters with a prefix NN naming convention and specification of ranges should not be considered necessary -- the list foo1,foo9 could be specified as such, or by the range foo[1,9]. Some examples of powerman targets follows. Power on hosts bar,baz,foo01,foo02,...,foo05: powerman --on bar baz foo[01-05] Power on hosts bar,foo7,foo9,foo10: powerman --on bar,foo[7,9-10]
Opengear console server User Manual Page 214 of 261 Power on foo0,foo4,foo5: powerman --on foo[0,4-5] As a reminder to the reader, some shells will interpret brackets ([ and ]) for pattern matching. Depending on your shell, it may be necessary to enclose ranged lists within quotes. For example, in tcsh, the last example above should be executed as: powerman --on "foo[0,4-5]"
pmpower The pmpower command is a high level tool for manipulating remote preconfigured power devices connected to the Opengear gateway either via a serial or network connection. pmpower [-?h] [-l device | -r host] [-o outlet] [-u username] [-p password] action -?/-h This help message. -l The serial port to use. -o The outlet on the power target to apply to -r The remote host address for the power target -u Override the configured username -p Override the configured password on This action switches the specified device or outlet(s) on off This action switches the specified device or outlet(s) off cycle This action switches the specified device or outlet(s) off and on again status This action retrieves the current status of the device or outlet Examples: To turn outlet 4 of the power device connected to serial port 2 on: # pmpower -l port02 -o 4 on To turn an IPMI device off located at IP address 192.168.1.100 (where username is 'root' and password is 'calvin': # pmpower -r 192.168.1.100 -u root -p calvin off Default system Power Device actions are specified in /etc/powerstrips.xml. Custom Power Devices can be added in /etc/config/powerstrips.xml. If an action is attempted which has not been configured for a specific Power Device pmpower will exit with an error. Adding new RPC devices There are two simple paths to adding support for new RPC devices.
Opengear console server User Manual Page 215 of 261 The first is to have scripts to support the particular RPC included in the open source PowerMan project (http://sourceforge.net/projects/powerman). The PowerMan device specifications are rather weird and it is suggested that you leave the actual writing of these scripts to the PowerMan authors. However documentation on how they work can be found at http://linux.die.net/man/5/powerman.dev Once the new RPC support has been built into the PowerMan Opengear will then include the updated PowerMan build in a subsequent firmware release. The second path is to directly add support for the new RPC devices (or to customize the existing RPC device support) on your particular console server. The Manage: Power page uses information contained in /etc/powerstrips.xml to configure and control devices attached to a serial port. The configuration also looks for (and loads) /etc/config/powerstrips.xml if it exists. The user can add their own support for more devices by putting definitions for them into /etc/config/powerstrips.xml. This file can be created on a host system and copied to the Management Console device using scp. Alternatively, login to the Management Console and use ftp or wget to transfer files. Here is a brief description of the elements of the XML entries in /etc/config/powerstrips.xml. <powerstrip> <id>Name or ID of the device support</id> <outlet port="port-id-1">Display Port 1 in menu</outlet> <outlet port="port-id-2">Display Port 2 in menu</outlet> ... <on>script to turn power on</on> <off>script to power off</off> <cycle>script to cycle power</cycle> <status>script to write power status to /var/run/power-status</status> <speed>baud rate</speed> <charsize>character size</charsize> <stop>stop bits</stop> <parity>parity setting</parity> </powerstrip> The id appears on the web page in the list of available devices types to configure. The outlets describe targets that the scripts can control. For example a power control board may control several different outlets. The port-id is the native name for identifying the outlet.
Opengear console server User Manual Page 216 of 261 This value will be passed to the scripts in the environment variable outlet, allowing the script to address the correct outlet. There are four possible scripts: on, off, cycle and status When a script is run, it's standard input and output is redirected to the appropriate serial port. The script receives the outlet and port in the outlet and port environment variables respectively. The script can be anything that can be executed within the shell. All of the existing scripts in /etc/powerstrips.xml use the pmchat utility. pmchat works just like the standard unix "chat" program, only it ensures interoperation with the port manager. The final options, speed, charsize, stop and parity define the recommended or default settings for the attached device.
15.10 IPMItool The console server includes the ipmitool utility for managing and configuring devices that support the Intelligent Platform Management Interface (IPMI) version 1.5 and version 2.0 specifications. IPMI is an open standard for monitoring, logging, recovery, inventory, and control of hardware that is implemented independent of the main CPU, BIOS, and OS. The service processor (or Baseboard Management Controller, BMC) is the brain behind platform management and its primary purpose is to handle the autonomous sensor monitoring and event logging features. The ipmitool program provides a simple command-line interface to this BMC. It features the ability to read the sensor data repository (SDR) and print sensor values, display the contents of the System Event Log (SEL), print Field Replaceable Unit (FRU) inventory information, read and set LAN configuration parameters, and perform remote chassis power control.
SYNOPSIS
ipmitool [-c|-h|-v|-V] -I open <command> ipmitool [-c|-h|-v|-V] -I lan -H <hostname> [-p <port>]
Opengear console server User Manual Page 217 of 261 [-U <username>] [-A <authtype>] [-L <privlvl>] [-a|-E|-P|-f <password>] [-o <oemtype>] <command> ipmitool [-c|-h|-v|-V] -I lanplus -H <hostname> [-p <port>] [-U <username>] [-L <privlvl>] [-a|-E|-P|-f <password>] [-o <oemtype>] [-C <ciphersuite>] <command> DESCRIPTION This program lets you manage Intelligent Platform Management Interface (IPMI) functions of either the local system, via a kernel device driver, or a remote system, using IPMI V1.5 and IPMI v2.0. These functions include printing FRU information, LAN configuration, sensor readings, and remote chassis power control. IPMI management of a local system interface requires a compatible IPMI kernel driver to be installed and configured. On Linux this driver is called OpenIPMI and it is included in standard distributions. On Solaris this driver is called BMC and is inclued in Solaris 10. Management of a remote station requires the IPMI-over-LAN interface to be enabled and configured. Depending on the particular requirements of each system it may be possible to enable the LAN interface using ipmitool over the system interface. OPTIONS -a Prompt for the remote server password. -A <authtype> Specify an authentication type to use during IPMIv1.5 lan session activation. Supported types are NONE, PASSWORD, MD5, or OEM. -c Present output in CSV (comma separated variable) format. This is not available with all commands. -C <ciphersuite> The remote server authentication, integrity, and encryption algorithms to use for IPMIv2 lanplus connections. See table 22-19 in the IPMIv2 specification. The default is 3 which specifies RAKP-HMAC-SHA1 authentication, HMAC-SHA1-96 integrity, and AES-CBC-128 encryption algorightms. -E The remote server password is specified by the environment variable IPMI_PASSWORD.
Opengear console server User Manual Page 218 of 261 -f <password_file> Specifies a file containing the remote server password. If this option is absent, or if password_file is empty, the password will default to NULL. -h Get basic usage help from the command line. -H <address> Remote server address, can be IP address or hostname. This option is required for lan and lanplus interfaces. -I <interface> Selects IPMI interface to use. Supported interfaces that are compiled in are visible in the usage help output. -L <privlvl> Force session privilege level. Can be CALLBACK, USER, OPERATOR, ADMIN. Default is ADMIN. -m <local_address> Set the local IPMB address. The default is 0x20 and there should be no need to change it for normal operation. -o <oemtype> Select OEM type to support. This usually involves minor hacks in place in the code to work around quirks in various BMCs from various manufacturers. Use -o list to see a list of current supported OEM types. -p <port> Remote server UDP port to connect to. Default is 623. -P <password> Remote server password is specified on the command line. If supported it will be obscured in the process list. Note! Specifying the password as a command line option is not recommended. -t <target_address> Bridge IPMI requests to the remote target address. -U <username> Remote server username, default is NULL user. -v Increase verbose output level. This option may be specified multiple times to increase the level of debug output. If given three times you will get hexdumps of all incoming and outgoing packets. -V Display version information. If no password method is specified then ipmitool will prompt the user for a password. If no password is entered at the prompt, the remote server password will default to NULL. SECURITY The ipmitool documentation highlights that there are several security issues to be considered before enabling the IPMI LAN interface. A remote station has the ability to control a system's power state as well as being able to gather certain platform information. To reduce vulnerability it is strongly advised that the IPMI LAN interface only be enabled in 'trusted'
Opengear console server User Manual Page 219 of 261 environments where system security is not an issue or where there is a dedicated secure 'management network' or access has been provided through an console server. Further it is strongly advised that you should not enable IPMI for remote access without setting a password, and that that password should not be the same as any other password on that system. When an IPMI password is changed on a remote machine with the IPMIv1.5 lan interface the new password is sent across the network as clear text. This could be observed and then used to attack the remote system. It is thus recommended that IPMI password management only be done over IPMIv2.0 lanplus interface or the system interface on the local station. For IPMI v1.5, the maximum password length is 16 characters. Passwords longer than 16 characters will be truncated. For IPMI v2.0, the maximum password length is 20 characters; longer passwords are truncated.
COMMANDS help This can be used to get command-line help on ipmitool commands. It may also be placed at the end of commands to get option usage help. ipmitool help Commands: raw Send a RAW IPMI request and print response lan Configure LAN Channels chassis Get chassis status and set power state event Send pre-defined events to MC mc Management Controller status and global enables sdr Print Sensor Data Repository entries and readings sensor Print detailed sensor information fru Print built-in FRU and scan SDR for FRU locators sel Print System Event Log (SEL) pef Configure Platform Event Filtering (PEF) sol Configure IPMIv2.0 Serial-over-LAN
Opengear console server User Manual Page 220 of 261 isol Configure IPMIv1.5 Serial-over-LAN user Configure Management Controller users channel Configure Management Controller channels session Print session information exec Run list of commands from file set Set runtime variable for shell and exec ipmitool chassis help Chassis Commands: status, power, identify, policy, restart_cause, poh, bootdev ipmitool chassis power help chassis power Commands: status, on, off, cycle, reset, diag, soft You will find more details on ipmitools at http://ipmitool.sourceforge.net/manpage.html 15.11 Custom Development Kit (CDK) As detailed in this manual customers can copy scripts, binaries and configuration files directly to the console server. Opengear also freely provides a development kit which allows changes to be made to the software in console server firmware image. The customer can use the CDK to:
generate a firmware image without certain programs, such as telnet, which may be banned by company policy
generate an image with new programs, such as custom Nagios plug-in binaries or company specific binary utilities
generate an image with custom defaults e.g. it may be required that the console server be configured to have a specific default serial port profile which is reverted to even in event of a factory reset
place configuration files into the firmware image, which cannot then be modified e.g. # /bin/config -set= tools update the configuration files in /etc/config which are read/write, whereas the files in /etc are read only and cannot be modified
Opengear console server User Manual Page 221 of 261 The CDK essentially provides a snapshot of the Opengear build process (taken after the programs have been compiled and copied to a temporary directory romfs) just before the compressed file systems are generated. You can obtain a copy of the Opengear CDK for the particular appliance you are working with from ftp://ftp.opengear.com/cdk and find further information online at http://www.opengear.com/faq284.html
Note The CDK is free, however Opengear does not provide free technical support for systems modified using the CDK and any changes are the responsibility of the user.
Opengear console server User Manual Page 222 of 261
Chapter 16 KCS Thin Client
KCS THIN CLIENT Introduction This chapter provides step-by-step instructions for configuring the thin client embedded in the KCS61xx console server and locally connecting the KCS to computers, networking, telecom, power and other management devices via serial, USB or IP over the LAN using an appropriate client (serial, Firefox browser, SSH, Telnet, VNC viewer, ICA, WTS RDP or custom). This chapter also covers remote administration using the KCS for overseeing local activity or taking remote control of the local devices.
16.1 KCS Local Client Service Connections You use the KCS console to access networked computers or devices (Hosts) or serial devices using a selection of local client services (such as Terminal, HTTP, HTTPS, VNC, RDP, ICA, IPMI) that are embedded in the KCS. These client connections first need to be configured: Select Connect: Add/Delete/Edit on the control panel Then select a Connect clients (such as RDP) and click Add to configure the Host connection for that client service
Opengear console server User Manual Page 223 of 261
For each new Host you add, you will be asked to enter a Label (enter a descriptive name) and a Hostname (enter the IP Address or DNS Name of the new network connected Host) and possibly a Username (enter the name you will use to log in to the Host) Once a Host has been added you can select Edit and update the commands that will be executed in connecting the service to the existing Host
The Serial terminal connection for the four (KCS6104) or sixteen (KCS6116) serial ports are pre- configured by default in Console Server Mode with RS232 settings of 9600 baud, no parity, 8 data bits and 1 stop bit. You change the settings as detailed in Chapter 4
16.1.1 Connect- serial terminal Select Connect: Serial on the control panel and click on the desired serial port. A window will be created with a connection to the device on the selected serial port:
Opengear console server User Manual Page 224 of 261
The embedded terminal emulator uses rxvt (a color vt102 terminal emulator) and you can find more details on configuration options in http://www.rxvt.org/manual.html
16.1.2 Connect- browser Select Connect: Browser on the control panel and click on the Host/web site you have configured to be accessed using the browser. Sites can be internal or external.
The KCS6000 provides a powerful Mozilla Firefox browser with a licensed Sun Java JRE
Opengear console server User Manual Page 225 of 261
Java and all Java based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries 16.1.3 Connect- VNC Select Connect: VNC on the control panel and click on the VNC server Host to be accessed The VNC Viewer client in your KCS will be started and a VNC connection window to the selected server will be opened
If the HostName was left blank when the VNC server connection was configured then the VNC Viewer will start with a request for the VNC server. Selecting Options at this stage enables you to configure the VNC Viewer Alternately you can select Options by right clicking on the VNC Viewer task Bar icon
Opengear console server User Manual Page 226 of 261
You can find more details on configuration options in http://www.realvnc.com/products/free/4.1/man/vncviewer.html
16.1.4 Connect- SSH SSH is typically used to log into a remote machine and execute commands Select Connect: SSH on the control panel and click on the Host to be accessed An SSH connection window will be opened. Enter the SSH login password and you will be securely connected to the selected Host
The KCS SSH connection uses OpenSSH (http://www.openssh.com/) and the terminal connection is presented using rxvt (ouR XVT) and you can find more details on configuration options in http://www.rxvt.org/manual.html
Opengear console server User Manual Page 227 of 261
16.1.5 Connect- IPMI The KCS control panel provides a number of IPMI tools for managing service processors or Baseboard Management Controllers (BMCs). These IPMI controls are built on the ipmitools program and you can find more details on configuration options in http://ipmitool.sourceforge.net/manpage.html The ipmitool program provides a simple command-line interface to the BMCs and features the ability to read the sensor data repository (SDR), display the contents of the System Event Log (SEL), read and set LAN configuration parameters, and perform remote chassis power control. The KCS Management Console also has additional tools for controlling power units with IPMI interfaces (refer Chapter 8). Select Connect: IPMI on the control panel and select the Serial over LAN connection to be accessed
This will kick off a Serial-Over-LAN session by running: # ipmitool -I lanplus -H hostname -U username -P password sol activate The resultant serial character connection is presented in an rxvt (ouR XVT) window. Also the Serial-Over- LAN feature is only applicable to IPMI2.0 devices. Select Logs: IPMI on the control panel and select the IPMI Event Log to be viewed
This will retrieve the selected IPMI event log by running: # ipmitool -I lanplus -H hostname -U username -P password sel info
16.1.6 Connect- Remote Desktop (RDP) Select Connect: RDP on the control panel and click on the Windows computer to be accessed
Opengear console server User Manual Page 228 of 261
The rdesktop program in your KCS will be started, an RDP connection to the Remote Desktop server in selected computer will be opened, the rdesktop window will appear on your KCS screen and you will be prompted for a password. (If the selected computer does not have RDP access enabled then the rdesktop window will not appear)
You can use Add/Delete/Edit to customize the rdesktop client (e.g. to include login username passwords). The command line protocol is: rdesktop -u windows-user-id -p windows-password -g 1200x950 ms-windows-terminal-server- host-name option Description -a Color depth: 8, 16, 24 -r Device redirection. i.e. Redirect sound on remote machine to local device i.e. -0 -r sound (MS/Windows 2003) -g Geometry: widthxheight or 70% screen percentage.
Opengear console server User Manual Page 229 of 261 -p Use -p - to receive password prompt.
Further information on rdesktop can be found at http://www.rdesktop.org/
16.1.7 Connect- Citrix ICA Select Connect: Citrix ICA on the control panel and click on the Citrix server to be accessed
16.2 Advanced Control Panel
16.2.1 System: Terminal Selecting System: Terminal on the control panel logs you in at the command line to the KCS Linux kernel. As detailed in Chapters 14 and 15 this enables you to configure and customize your KCS using the config and portmanager commands or general Linux commands
16.2.2 System: Shutdown / Reboot Clicking System: Shutdown on the control panel will shut down the KCS system. You will need to cycle the power to reactivate the KCS with a soft reset. Similarly by clicking System: Reboot you will affect a soft reset. With a soft reset the KCS reboots with all settings such as the assigned network IP address, preserved. However a soft reset does disconnect all Users and ends any SSH sessions that had been established. A soft reset will also be affected when you switch OFF power from the KCS, and then switch the power back ON. However if you cycle the power and the unit is writing to flash you could corrupt or lose data, so the software Shutdown or Reboot from the control panel is the safer option.
Opengear console server User Manual Page 230 of 261
16.2.3 System: Logout Clicking System: Logout closes the local user log in session (and remove the control panel). However this does not logout remote users who may be logged into the KCS console server, or accessing attached devices using SSH tunneling.
16.2.4 Custom The Custom button on the control panel enables you to customize your KCS by adding buttons the control panel that execute bash and other linux commands you specify
16.2.5 Status These menu items give the user a snapshot of the serial port and IPMI device status
16.2.6 Logs These menu items give the user an audit log of KCS activity
16.3 Remote control You can access the KCS locally with your directly connected (or KVM switched) screen and keyboard. If you connected the KCS to KVMoIP infrastructure that you already have installed then this may also provide you with some remote access to the KCS local consoles (RDP, Telnet, VNC, ICA, JRE etc).
The KCS also hosts an embedded VNC server that enables you to remotely monitor and control the thin client software (RDP, Telnet, VNC, ICA etc) that is running in the KCS itself.
Opengear console server User Manual Page 231 of 261 Alternately you can run the management client software (RDP etc) on the remote computer and use SDT to securely connect the client directly through to the managed devices that are serially or network attached to the KCS. This is particularly useful when you have proprietary applications (such as Dell OpenManage or VMware VDI client) on your remote management computer that you want to use to manage a DRAC service processor or VMware virtual device on one of your remote servers. Each KCS gateway has an internal VNC server enabling remote administrators to oversee local activity, and giving them the option to access and control all the devices themselves. To activate the VNC server in the KCS: Select the System: Services option in the Management Console menu then check VNC Server or Secure VNC Server
Click Manage: KCS then Launch Standard VNC Remote Control and your browser will automatically download and run a Java VNC applet client You will need to log in as root (or some other configured KCS username) and as a remote Administrator you connect to the VNC server in the KCS and gain remote access to (and monitor and take control of) the KCS local display.
Opengear console server User Manual Page 232 of 261
Alternately you can run a VNC client application such as RealVNC, TightVNC or UltraVNC directly on your remote computer and configure it with the KCS IP address to connect to the KCS VNC server
You can find more details on configuration options for the KCS realvnc server in http://www.realvnc.com/products/free/4.1/man/vncserver.html
Opengear console server User Manual Page 233 of 261
Appendix A Linux Kernel and Source Code
The console server platform is a dedicated Linux computer, optimized to provide secure access to serial consoles of critical server systems. Being based around uClinux (a small footprint but extensible Linux), it embodies a myriad, popular and proven Linux software modules for networking (NetFilter, IPTables), secure access (OpenSSH) and communications (OpenSSL) and sophisticated user authentication (PAM, RADIUS, TACACS+ and LDAP). Many components of the console server software are licensed under the GNU General Public License (version 2), which Opengear supports. You may obtain a copy of the GNU General Public License at http://www.fsf.org/copyleft/gpl.html. Opengear will provide source code for any of the components of the Software licensed under the GNU General Public License upon request. Opengear Console servers are built on the 2.4 uClinux kernel as developed by the uClinux project. This is GPL code and source can be found: http://cvs.uclinux.org
Commands that have config files that can be altered:
Opengear console server User Manual Page 234 of 261 mii-tool netstat route openntpd ping portmap pppd routed setserial smtpclient stty stunel tcpdump tftp tip traceroute
A full list of the Linux commands and applications included in the latest console server build can be found at http://www.opengear.com/faq233.html
More details on the Linux commands can found online at: http://en.tldp.org/HOWTO/HOWTO-INDEX/howtos.html http://www.faqs.org/docs/Linux-HOWTO/Remote-Serial-Console-HOWTO.html
http://www.stokely.com/unix.serial.port.resources/serial.switch.html The console server also embodies the okvm console management software. This is GPL code and the full source is available from http://okvm.sourceforge.net.
The console server BIOS (boot loader code) is a port of uboot which is also a GPL package with source openly available.
The console server CGIs (the html code, xml code and web config tools for the Console Manager) are proprietary to Opengear, however the code will be provided to customers, under NDA.
Also inbuilt in the console server is a Port Manager application and Configuration tools as described in Chapters 11 and 12. These both are proprietary to Opengear, but open to customers (as above).
Opengear console server User Manual Page 235 of 261
Appendix B Hardware Specifications
FEATURE VALUE Dimensions IM4208/16/48: 17 x 12 x 1.75 in (43.2 x 31.3. x 4.5 cm) IMG4216-25: 17 x 12 x 1.75 in (43.2 x 31.3. x 4.5 cm) IMG4004-5: 8.2 x 4.9 x 1.2 in (20.8 x 12.6 x 4.5 cm) CM4116/48: 17 x 8.5 x 1.75 in (43.2 x 21. x 4.5 cm) CM4008: 8.2 x 4.9 x 1.2 in (20.8 x 12.6 x 4.5 cm) CM4001: 3.9 x 2.8 x 1.0 in (10 x 7.2 x 2.5 cm) Weight IM4208/16/48: 5.4 kg (11.8 lbs) IMG4216-25: 5.4 kg (11.8 lbs) IMG4004-5: 1.7 kg (3.7 lbs) CM4116/48: 3.9 kg (8.5 lbs) CM4008:1.7 kg (3.7 lbs) CM4001: 1.1 kg (2.5 lbs) Ambient operating temperature 5C to 50C (41F to 122F) Non operating storage temperature -30C to +60C (-20F to +140F)
Humidity 5% to 90% Power Refer Chapter 2 for various models Power Consumption All less than 30W CPU Micrel KS8695P controller Memory
IM4208/16/48: 64MB SDRAM 16MB Flash 512MB USB Flash IM4248-2: 64MB SDRAM 16MB Flash 512MB USB Flash IMG4004-5: 64MB SDRAM 16MB Flash 1G USB Flash CM4116/48: 64MB SDRAM 16MB Flash
Opengear console server User Manual Page 236 of 261 CM4008: 16MB SDRAM 8MB Flash CM4001: 16MB SDRAM 8MB Flash Serial Connectors
IM4208-2: 8 RJ-45 RS-232 serial ports IM4216-2: 16 RJ-45 RS-232 serial ports IM4248-2: 48 RJ-45 RS-232 serial ports IMG4004-5: 4 RJ-45 RS-232 serial ports IMG4216-25: 16 RJ-45 RS-232 serial ports CM4116: 16 RJ-45 RS-232 serial ports CM4148: 48 RJ-45 RS-232 serial ports CM4008: 8 RJ-45 RS-232 serial ports CM4001: 1 DB-9 RS-232 serial port
All models: 1 DB-9 RS-232 console/ modem serial port Serial Baud Rates RJ45 ports - 50 to 230,400bps) DB9 port - 2400 to 115,200 bps
Ethernet Connectors IM4208/16/48-2: Two RJ-45 10/100Base-T Ethernet ports IMG4216-25: One RJ-45 10/100Base-T primary Ethernet port and 24 RJ-45 10/100Base-T management LAN switched ports IMG4004-5: One RJ-45 10/100Base-T primary Ethernet port and 4 RJ-45 10/100Base-T management LAN switched ports CM41xx One RJ-45 10/100Base-T Ethernet ports
Opengear console server User Manual Page 237 of 261
Appendix C Safety & Certifications
Please take care to follow the safety precautions below when installing and operating the console server:
Do not remove the metal covers. There are no operator serviceable components inside. Opening or removing the cover may expose you to dangerous voltage which may cause fire or electric shock. Refer all service to Opengear qualified personnel
To avoid electric shock the power cord protective grounding conductor must be connected through to ground.
Always pull on the plug, not the cable, when disconnecting the power cord from the socket.
Do not connect or disconnect the console server during an electrical storm. Also it is recommended you use a surge suppressor or UPS to protect the equipment from transients.
FCC Warning Statement
This device complies with Part 15 of the FCC rules. Operation of this device is subject to the following conditions: (1) This device may not cause harmful interference, and (2) this device must accept any interference that may cause undesired operation.
Opengear console server User Manual Page 238 of 261
Appendix D Connectivity and Serial I/O
Pinout standards exist for both DB9 and DB25 connectors; however there are not pinout standards for serial connectivity using RJ45 connectors. Most console servers and serially managed servers/ router/ switches/ PSUs have adopted their own unique pinout; so custom connectors and cables may be required to interconnect your console server.
In an endeavor to create some move to standardization, Opengear products all use the same RJ45 pinout convention as adopted by Avocent and Equinox.
Serial Port Pinout
The 8/16/48 RJ45 connectors on the CM4008/4116/4148 and IM4216/4248 unit have the following pinout: RJ45 PIN SIGNAL
Pin 1 2 3 4 5 6 7 8
Signal RTS DSR DCD RXD TXD GND DTR CTS
Direction Output Input Input Input Output NA Output Input
RS232 Signal Description Request To Send Data Set Ready Data Carrier Detect Receive Data Transmit Data Ground Data Terminal Ready Clear To Send
The LOCAL (console/modem) port on the console server uses a standard DB9 connector, as does the serial port on the CM4001. The RS232 pinout standards for the DB9 (and DB25) connectors are tabled below: DB25 SIGNAL DB9 DEFINITION 1 Protective Ground 2 TXD 3 Transmitted Data 3 RXD 2 Received Data 4 RTS 7 Request To Send 5 CTS 8 Clear To Send 6 DSR 6 Data Set Ready
Opengear console server User Manual Page 239 of 261 7 GND 5 Signal Ground 8 CD 1 Received Line Signal Detector 9 Reserved for data set testing 10 Reserved for data set testing 11 Unassigned 12 SCF Secondary Rcvd Line Signal Detector 13 SCB Secondary Clear to Send 14 SBA Secondary Transmitted Data 15 DB Transmission Signal Timing 16 SBB Secondary Received Data 17 DD Receiver Signal Element Timing 18 Unassigned 19 SCA Secondary Request to Send 20 DTR 4 Data Terminal Ready 21 CG Signal Quality Detector 22 9 Ring Indicator 23 CH/CI Data Signal Rate Selector 24 DA Transmit Signal Element Timing 25 Unassigned
FEMALE MALE 25 pin DB25
9 pin DB9
8 pin RJ45
Connectors included in console server
The CM4008/4116/4148 and IM4208/16/48 all ship with a cross-over and a straight RJ45- DB9 connector for connecting to other vendors products:
Opengear console server User Manual Page 240 of 261
Part # 319000
DB9F-RJ45S straight connector
Part # 319001
DB9F-RJ45S cross-over connector
Other available connectors and adapters Opengear also supplies a range of cables and adapters that will enable you to easily connect to the more popular servers and network appliances. More detailed information can be found online at http://www.opengear.com/cabling.html
Local/Console connection These adapters connect the console server LOCAL/Console port (via standard UTP Cat 5 cable) to modem devices (for out-of-band access):
319000 DB9F to RJ45 straight console server LOCAL Console Port to Modem 319002 DB25M to RJ45 straight console server LOCAL Console Port to Modem
Console server Serial Port connection The connectors and adapters in the table below all work with standard UTP Cat 5 cables: 319001 DB9F to RJ45 crossover DCE Adapter - console server Ports to X86 and other 319002 DB25M to RJ45 straight DTE Adapter - console server Ports
Opengear console server User Manual Page 241 of 261 319003 DB25M to RJ45 crossover DCE Adapter - console server Ports to Sun and other 319004 DB9M to RJ45 straight DTE Adapter - console server to Netscreen and Dell 319005 DB25F to RJ45 crossover DCE Adapter - console server to Cisco 7200 AUX 440016 5ft Cat5 RJ-45 to RJ-45 cables Extension cables 449016 RJ-45 Plug to RJ-45 Jack Adapter for Cisco console
Opengear console server User Manual Page 242 of 261
Appendix E Hardware Test
This section describes the Loopback Test facilities built into the console server code. When undertaking a Loopback Test, each of the serial ports loop data transmitted to data received, RTS to CTS, and DTR to DSR + DCD. The loopback program senses that data sent is received properly and that signals set and received properly. The Loopback Test also undertakes an Ethernet loopback that senses the data transmitted is received properly.
To undertake these tests you must have at hand:
console server unit (CM4008,CM4116 or CM4148) Terminal device (e.g. Windows PC and HyperTerminal program) Serial console cabling e.g. UTP Cat5 cable (#440016), DB-9 to RJ45 DTE adapter (#319000) and DB-9 to RJ45 DCE adapter (#319001) Custom made R-45 serial loopback plugs (SLB) Custom made RJ-45 Ethernet loopback plug (ELB)
Opengear console server User Manual Page 243 of 261
Signal Wiring on Custom made loopback plug:
Wire TXD+ to RXD+ (1 to 3)
Wire TXD- to RXD- (2 to 6)
The RJ-45 Ethernet modular jack pinout is:
1 TXD+ 2 TXD- 3 RXD+ 4 NC 5 NC 6 RXD- 7 NC 8 NC
Test Procedure
Power up the console server and you should observe the LEDs P1 through P8 light up in sequence
Configure the serial connection of the terminal device/program you are using to 9600bps, 8 data bits, no parity and one stop bit
Plug a serial cable between the console server local DB-9 port and terminal device. If you are using HyperTerminal or a similar program running on a Windows PC as the terminal device, then the cable is made up from a Cat5 UTP (440016) cable and two DB-9 to RJ-45 adapters (319000 and 319001)
Log on to the console server by pressing return a few times. The console server will request a username and password. The username is root and the password is default. You should now see the command line prompt which is a hash (#)
For CM4008:
Install the ELB on the Ethernet RJ45 socket and an SLB plug onto each serial RJ-45 sockets
Opengear console server User Manual Page 244 of 261
To invoke the inbuilt loopback diagnostics:
Type in loopback e eth0 /dev/port0[1-8] Then press return
The screen will show 8 columns for serial loopback and one for Ethernet.
1 2 3 4 5 6 7 8 E - - - - - - - - - (- is not looped) L L L L L L L L L (L is looped) S S S S S S S S S (S is too little data received) C C C C C C C C C (C is corrupt data received) D D D D D D D D D (DTR set but not sensed) R R R R R R R R R (RTS set but not sensed)
This will test port 1 through 8 and will repeat indefinitely.
The test can be terminated by pressing Ctrl C.
A successful test must have L active in each column.
For CM4116/ CM4148:
Install the ELB on the Ethernet RJ45 socket and an SLB plug onto each serial RJ-45 sockets
Opengear console server User Manual Page 245 of 261
To invoke the inbuilt loopback diagnostics:
Type in loopback e eth0 /dev/port0[1-9] Then press return
The screen will show 9 columns for serial loopback and one for Ethernet.
1 2 3 4 5 6 7 8 9 E - - - - - - - - - - (- is not looped) L L L L L L L L L L (L is looped) S S S S S S S S S S (S is too little data received) C C C C C C C C C C (C is corrupt data received) D D D D D D D D D D (DTR set but not sensed) R R R R R R R R R R (RTS set but not sensed)
This will test port 1 through 9.To test ports 10 through 16 on the CM4116 you need to type -
loopback e eth0 /dev/port1[0-6]
The screen will then show 7 columns for ports 10 through 16 and one for Ethernet.
Opengear console server User Manual Page 246 of 261 As the CM4148 has 48 ports you need to test ports, 1-9, 10-19, 20-29, 30-39, 40-48 in separate blocks.
For ports 10 through 19, type in
loopback e eth0 /dev/port1[0-9]
For ports 20 through 29, type in
loopback e eth0 /dev/port2[0-9]
For ports 30 through 39, type in
loopback e eth0 /dev/port3[0-9]
For ports 40 through 48, type in
loopback e eth0 /dev/port4[0-8]
The test will repeat indefinitely.
The test can be terminated by pressing Ctrl C.
A successful test must have L active in each column.
Opengear console server User Manual Page 247 of 261
Appendix F Terminology
TERM MEANING Authentication
Authentication is the technique by which a process verifies that its communication partner is who it is supposed to be and not an imposter. Authentication confirms that data is sent to the intended recipient and assures the recipient that the data originated from the expected sender and has not been altered on route BIOS Basic Input/Output System is the built-in software in a computer that are executed on start up (boot) and that determine what the computer can do without accessing programs from a disk. On PCs, the BIOS contains all the code required to control the keyboard, display screen, disk drives, serial communications, and a number of miscellaneous functions Bonding Ethernet Bonding or Failover is the ability to detect communication failure transparently, and switch from one LAN connection to another. BOOTP Bootstrap Protocol. A protocol that allows a network user to automatically receive an IP address and have an operating system boot without user interaction. BOOTP is the basis for the more advanced DHCP Certificates A digitally signed statement that contains information about an entity and the entity's public key, thus binding these two pieces of information together. A certificate is issued by a trusted organization (or entity) called a Certification Authority (CA) after the CA has verified that the entity is who it says it is. Certificate Authority
A Certificate Authority is a trusted third party, which certifies public key's to truly belong to their claimed owners. It is a key part of any Public Key Infrastructure, since it allows users to trust that a given public key is the one they wish to use, either to send a private message to its owner or to verify the signature on a message sent by that owner. Certificate Revocation List
A list of certificates that have been revoked by the CA before they expired. This may be necessary if the private key certificate has been compromised or if the holder of the certificate is to be denied the ability to establish a connection to the console server. CHAP Challenge-Handshake Authentication Protocol (CHAP) is used to verify a user's
Opengear console server User Manual Page 248 of 261 name and password for PPP Internet connections. It is more secure than PAP, the other main authentication protocol. DHCP Dynamic Host Configuration Protocol. A communications protocol that assigns IP addresses to computers when they are connected to the network. DNS Domain Name System that allocates Internet domain names and translates them into IP addresses. A domain name is a meaningful and easy to remember name for an IP address. DUN Dial Up Networking Encryption The technique for converting a readable message (plaintext) into apparently random material (ciphertext) which cannot be read if intercepted. The proper decryption key is required to read the message. Ethernet A physical layer protocol based upon IEEE standards Firewall A network gateway device that protects a private network from users on other networks. A firewall is usually installed to allow users on an intranet access to the public Internet without allowing public Internet users access to the intranet. Gateway A machine that provides a route (or pathway) to the outside world. Hub A network device that allows more than one computer to be connected as a LAN, usually using UTP cabling. Internet A worldwide system of computer networks - a public, cooperative, and self- sustaining network of networks accessible to hundreds of millions of people worldwide. The Internet is technically distinguished because it uses the TCP/IP set of protocols. Intranet A private TCP/IP network within an enterprise. IPMI Intelligent Platform Management Interface (IPMI) is a remote hardware health monitoring and management system that defines interfaces for use in monitoring the physical health of servers, such as temperature, voltage, fans, power supplies and chassis. It was developed by Dell, HP, Intel and NEC, but has now been adopted by more than 150 server technology and ships with over 70% of servers. Servers with IPMI functionality let network managers access and monitor server hardware, and diagnose and restore a frozen server to normal operation. IPMI defines the protocols for interfacing with a service processor embedded into a server platform. Key lifetimes The length of time before keys are renegotiated LAN Local Area Network
Opengear console server User Manual Page 249 of 261 LDAP The Lightweight Directory Access Protocol (LDAP) is based on the X.500 standard, but significantly simpler and more readily adapted to meet custom needs. The core LDAP specifications are all defined in RFCs. LDAP is a protocol used to access information stored in an LDAP server. LED Light-Emitting Diode MAC address Every piece of Ethernet hardware has a unique number assigned to it called it's MAC address. Ethernet is used locally to connect the console server to the Internet, and it may share the local network with many other appliances. The MAC address is used by the local Internet router in order to direct console server traffic to it rather than somebody else in the local area. It is a 48-bit number usually written as a series of 6 hexadecimal octets, e.g. 00:d0:cf:00:5b:da. A console server has a MAC address listed on a label underneath the device. MSCHAP Microsoft Challenge Handshake Authentication Protocol (MSCHAP) is authentication for PPP connections between a computer using a Microsoft Windows operating system and a network access server. It is more secure than PAP or CHAP, and is the only option that also supports data encryption. NAT Network Address Translation. The translation of an IP address used on one network to an IP address on another network. Masquerading is one particular form of NAT. Net mask The way that computers know which part of a TCP/IP address refers to the network, and which part refers to the host range. NFS Network File System is a protocol that allows file sharing across a network. Users can view, store, and update files on a remote computer. NTP Network Time Protocol (NTP) used to synchronize clock times in a network of computers OUT OF BAND Out-of-Band (OoB) management is any management done over channels and interfaces that are separate from those used for user/customer data. Examples would include a serial console interface or a network interface connected to a dedicated management network that is not used to carry customer traffic, or to a BMC/service processor. Any management done over the same channels and interfaces used for user/customer data is In Band. PAP Password Authentication Protocol (PAP) is the usual method of user authentication used on the internet: sending a username and password to a server where they are compared with a table of authorized users. Whilst most common, PAP is the least secure of the authentication options. PPP Point-to-Point Protocol. A networking protocol for establishing simple links between two peers.
Opengear console server User Manual Page 250 of 261 RADIUS
The Remote Authentication Dial-In User Service (RADIUS) protocol was developed by Livingston Enterprises as an access server authentication and accounting protocol. The RADIUS server can support a variety of methods to authenticate a user. When it is provided with the username and original password given by the user, it can support PPP, PAP or CHAP, UNIX login, and other authentication mechanisms. Router A network device that moves packets of data. A router differs from hubs and switches because it is "intelligent" and can route packets to their final destination. SMASH Systems Management Architecture for Server Hardware is a standards-based protocols aimed at increasing productivity of the management of a data center. The SMASH Command Line Protocol (SMASH CLP) specification provides an intuitive interface to heterogeneous servers independent of machine state, operating system or OS state, system topology or access method. It is a standard method for local and remote management of server hardware using out-of-band communication SMTP Simple Mail Transfer Protocol. console server includes, SMTPclient, a minimal SMTP client that takes an email message body and passes it on to a SMTP server (default is the MTA on the local host). SOL Serial Over LAN (SOL) enables servers to transparently redirect the serial character stream from the baseboard universal asynchronous receiver/transmitter (UART) to and from the remote-client system over a LAN. With SOL support and BIOS redirection (to serial) remote managers can view the BIOS/POST output during power on, and reconfigured. SSH Secure Shell is secure transport protocol based on public-key cryptography. SSL Secure Sockets Layer is a protocol that provides authentication and encryption services between a web server and a web browser. TACACS+ The Terminal Access Controller Access Control System (TACACS+) security protocol is a more recent protocol developed by Cisco. It provides detailed accounting information and flexible administrative control over the authentication and authorization processes. TACACS+ allows for a single access control server (the TACACS+ daemon) to provide authentication, authorization, and accounting services independently. Each service can be tied into its own database to take advantage of other services available on that server or on the network, depending on the capabilities of the daemon. There is a draft RFC detailing this protocol. TCP/IP Transmission Control Protocol/Internet Protocol. The basic protocol for Internet communication. TCP/IP address Fundamental Internet addressing method that uses the form nnn.nnn.nnn.nnn.
Opengear console server User Manual Page 251 of 261
For further technology definitions refer:
http://linux-documentation.com/en/documentation/linux-dictionary/index.html or
http://en.wikipedia.org/ Telnet Telnet is a terminal protocol that provides an easy-to-use method of creating terminal connections to a network. UTC Coordinated Universal Time. UTP Unshielded Twisted Pair cabling. A type of Ethernet cable that can operate up to 100Mb/s. Also known as Category 5 or CAT 5. VNC Virtual Network Computing (VNC) is a desktop protocol to remotely control another computer. It transmits the keyboard presses and mouse clicks from one computer to another relaying the screen updates back in the other direction, over a network. WAN Wide Area Network WINS Windows Internet Naming Service that manages the association of workstation names and locations with IP addresses
Opengear console server User Manual Page 252 of 261
Appendix G End User License Agreement
READ BEFORE USING THE ACCOMPANYING SOFTWARE YOU SHOULD CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS BEFORE USING THE ACCOMPANYING SOFTWARE, THE USE OF WHICH IS LICENSED FOR USE ONLY AS SET FORTH BELOW. IF YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT, DO NOT USE THE SOFTWARE. IF YOU USE ANY PART OF THE SOFTWARE, SUCH USE WILL INDICATE THAT YOU ACCEPT THESE TERMS. You have acquired a product that includes Opengear (Opengear) proprietary software and/or proprietary software licensed to Opengear. This Opengear End User License Agreement (EULA) is a legal agreement between you (either an individual or a single entity) and Opengear for the installed software product of Opengear origin, as well as associated media, printed materials, and online or electronic documentation (Software). By installing, copying, downloading, accessing, or otherwise using the Software, you agree to be bound by the terms of this EULA. If you do not agree to the terms of this EULA, Opengear is not willing to license the Software to you. In such event, do not use or install the Software. If you have purchased the Software, promptly return the Software and all accompanying materials with proof of purchase for a refund. Products with separate end user license agreements that may be provided along with the Software are licensed to you under the terms of those separate end user license agreements. LICENSE GRANT. Subject to the terms and conditions of this EULA, Opengear grants you a nonexclusive right and license to install and use the Software on a single CPU, provided that, (1) you may not rent, lease, sell, sublicense or lend the Software; (2) you may not reverse engineer, decompile, disassemble or modify the Software, except and only to the extent that such activity is expressly permitted by applicable law notwithstanding this limitation; and (3) you may not transfer rights under this EULA unless such transfer is part of a permanent sale or transfer of the Product, you transfer at the same time all copies of the Software to the same party or destroy such materials not transferred, and the recipient agrees to this EULA. No license is granted in any of the Softwares proprietary source code. This license does not grant you any rights to patents, copyright, trade secrets, trademarks or any other rights with respect to the Software. You may make a reasonable number of copies of the electronic documentation accompanying the Software for each Software license you acquire, provided that, you must reproduce and include all copyright notices and any other proprietary rights notices appearing on the electronic documentation. Opengear reserves all rights not expressly granted herein. INTELLECTUAL PROPERTY RIGHTS. The Software is protected by copyright laws, international copyright treaties, and other intellectual property laws and treaties. Opengear and
Opengear console server User Manual Page 253 of 261 its suppliers retain all ownership of, and intellectual property rights in (including copyright), the Software components and all copies thereof, provided however, that (1) certain components of the Software, including SDT Connector, are components licensed under the GNU General Public License Version 2, which Opengear supports, and (2) the SDT Connector includes code from JSch, a pure Java implementation of SSH2 which is licensed under BSD style license. Copies of these licenses are detailed below and Opengear will provide source code for any of the components of the Software licensed under the GNU General Public License upon request. EXPORT RESTRICTIONS. You agree that you will not export or re-export the Software, any part thereof, or any process or service that is the direct product of the Software in violation of any applicable laws or regulations of the United States or the country in which you obtained them. U.S. GOVERNMENT RESTRICTED RIGHTS. The Software and related documentation are provided with Restricted Rights. Use, duplication, or disclosure by the Government is subject to restrictions set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 or subparagraphs (c) (1) and (2) of the Commercial Computer Software Restricted Rights at 48 C.F.R. 52.227-19, as applicable, or any successor regulations. TERM AND TERMINATION. This EULA is effective until terminated. The EULA terminates immediately if you fail to comply with any term or condition. In such an event, you must destroy all copies of the Software. You may also terminate this EULA at any time by destroying the Software. GOVERNING LAW AND ATTORNEYS FEES. This EULA is governed by the laws of the State of Utah, USA, excluding its conflict of law rules. You agree that the United Nations Convention on Contracts for the International Sale of Goods is hereby excluded in its entirety and does not apply to this EULA. If you acquired this Software in a country outside of the United States, that countrys laws may apply. In any action or suit to enforce any right or remedy under this EULA or to interpret any provision of this EULA, the prevailing party will be entitled to recover its costs, including reasonable attorneys fees. ENTIRE AGREEMENT. This EULA constitutes the entire agreement between you and Opengear with respect to the Software, and supersedes all other agreements or representations, whether written or oral. The terms of this EULA can only be modified by express written consent of both parties. If any part of this EULA is held to be unenforceable as written, it will be enforced to the maximum extent allowed by applicable law, and will not affect the enforceability of any other part. Should you have any questions concerning this EULA, or if you desire to contact Opengear for any reason, please contact the Opengear representative serving your company. THE FOLLOWING DISCLAIMER OF WARRANTY AND LIMITATION OF LIABILITY IS INCORPORATED INTO THIS EULA BY REFERENCE. THE SOFTWARE IS NOT FAULT TOLERANT. YOU HAVE INDEPENDENTLY DETERMINED HOW TO USE THE SOFTWARE IN THE DEVICE, AND OPENGEAR HAS RELIED UPON YOU TO CONDUCT SUFFICIENT TESTING TO DETERMINE THAT THE SOFTWARE IS SUITABLE FOR SUCH USE.
Opengear console server User Manual Page 254 of 261 LIMITED WARRANTY Opengear warrants the media containing the Software for a period of ninety (90) days from the date of original purchase from Opengear or its authorized retailer. Proof of date of purchase will be required. Any updates to the Software provided by Opengear (which may be provided by Opengear at its sole discretion) shall be governed by the terms of this EULA. In the event the product fails to perform as warranted, Opengears sole obligation shall be, at Opengears discretion, to refund the purchase price paid by you for the Software on the defective media, or to replace the Software on new media. Opengear makes no warranty or representation that its Software will meet your requirements, will work in combination with any hardware or application software products provided by third parties, that the operation of the software products will be uninterrupted or error free, or that all defects in the Software will be corrected. OPENGEAR DISCLAIMS ANY AND ALL OTHER WARRANTIES, WHETHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OTHER THAN AS STATED HEREIN, THE ENTIRE RISK AS TO SATISFACTORY QUALITY, PERFORMANCE, ACCURACY, AND EFFORT IS WITH YOU. ALSO, THERE IS NO WARRANTY AGAINST INTERFERENCE WITH YOUR ENJOYMENT OF THE SOFTWARE OR AGAINST INFRINGEMENT. IF YOU HAVE RECEIVED ANY WARRANTIES REGARDING THE DEVICE OR THE SOFTWARE, THOSE WARRANTIES DO NOT ORIGINATE FROM, AND ARE NOT BINDING ON, OPENGEAR. NO LIABILITY FOR CERTAIN DAMAGES. EXCEPT AS PROHIBITED BY LAW, OPENGEAR SHALL HAVE NO LIABILITY FOR COSTS, LOSS, DAMAGES OR LOST OPPORTUNITY OF ANY TYPE WHATSOEVER, INCLUDING BUT NOT LIMITED TO, LOST OR ANTICIPATED PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, EXEMPLARY SPECIAL OR CONSEQUENTIAL DAMAGES, WHETHER UNDER CONTRACT, TORT, WARRANTY OR OTHERWISE ARISING FROM OR IN CONNECTION WITH THIS EULA OR THE USE OR PERFORMANCE OF THE SOFTWARE. IN NO EVENT SHALL OPENGEAR BE LIABLE FOR ANY AMOUNT IN EXCESS OF THE LICENSE FEE PAID TO OPENGEAR UNDER THIS EULA. SOME STATES AND COUNTRIES DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THIS LIMITATION MAY NOT APPLY TO YOU.
JSch License
SDT Connector includes code from JSch, a pure Java implementation of SSH2. JSch is licensed under BSD style license and it is:
Copyright (c) 2002, 2003, 2004 Atsuhiko Yamanaka, JCraft,Inc. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Opengear console server User Manual Page 255 of 261 3. The names of the authors may not be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL JCRAFT, INC. OR ANY CONTRIBUTORS TO THIS SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
SDT Connector License
GNU GENERAL PUBLIC LICENSE Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
Opengear console server User Manual Page 256 of 261
c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions.
Opengear console server User Manual Page 257 of 261 You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
Opengear console server User Manual Page 258 of 261 YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
SUN Java License (KCS61xx product only)
1. Java Technology Restrictions. Licensee shall not create, modify, change the behavior of, or authorize licensees of Licensee to create, modify, or change the behavior of, classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun" or similar convention as specified by Sun in any naming convention designation. In the event that Licensee creates an additional API(s) which: (a) extends the functionality of a Java Environment; and (b) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, Licensee must promptly publish broadly an accurate specification for such API for free use by all developers.
2. Trademarks and Logos. This License does not authorize an end user licensee to use any Sun Microsystems, Inc. name, trademark, service mark, logo or icon. The end user licensee acknowledges that Sun owns the Java trademark and all Java-related trademarks, logos and icons including the Coffee Cup and Duke ("Java Marks") and agrees to: (a) comply with the Java Trademark Guidelines at http://java.sun.com/trademarks.html; (b) not do anything harmful to or inconsistent with Sun's rights in the Java Marks; and (c) assist Sun in protecting those rights, including assigning to Sun any rights acquired by Licensee in any Java Mark.
3. Source Code. Software may contain source code that, unless expressly licensed for other purposes, is provided solely for reference purposes pursuant to the terms of your license. Source code may not be redistributed unless expressly provided for in the terms of your license.
4. Third Party Code. Additional copyright notices and license terms applicable to portions of the Software are set forth in the THIRDPARTYLICENSEREADME.txt file.
Opengear console server User Manual Page 259 of 261
Appendix H Service and Warranty
STANDARD WARRANTY Opengear, Inc., its parent, affiliates and subsidiaries, (collectively, "Opengear") warrant your Opengear product to be in good working order and to be free from defects in workmanship and material (except in those cases where the materials are supplied by the Purchaser) under normal and proper use and service for the period of four (4) years from the date of original purchase from an Authorized Opengear reseller (for CM4116, CM4148 and all IM/IMG42xx products) and one (1) year from the date of original purchase from an Authorized Opengear reseller for all other product. In the event that this product fails to meet this warranty within the applicable warranty period, and provided that Opengear confirms the specified defects, Purchaser's sole remedy is to have Opengear, in Opengear's sole discretion, repair or replace such product at the place of manufacture, at no additional charge other than the cost of freight of the defective product to and from the Purchaser. Repair parts and replacement products will be provided on an exchange basis and will be either new or reconditioned. Opengear will retain, as its property, all replaced parts and products. Notwithstanding the foregoing, this hardware warranty does not include service to replace or repair damage to the product resulting from accident, disaster, abuse, misuse, electrical stress, negligence, any non- Opengear modification of the product except as provided or explicitly recommended by Opengear, or other cause not arising out of defects in material or workmanship. This hardware warranty also does not include service to replace or repair damage to the product if the serial number or seal or any part thereof has been altered, defaced or removed. If Opengear does not find the product to be defective, the Purchaser will be invoiced for said inspection and testing at Opengear's then current rates, regardless of whether the product is under warranty. RMA RETURN PROCEDURE If this product requires service during the applicable warranty period, a Return Materials Authorization (RMA) number must first be obtained from Opengear. Product that is returned to Opengear for service or repair without an RMA number will be returned to the sender unexamined. Product should be returned, freight prepaid, in its original or equivalent packaging, to:
Opengear Service Center Suite A, 630 West 9560 South Sandy, Utah 84070 Proof of purchase date must accompany the returned product and the Purchaser shall agree to insure the product or assume the risk of loss of damage in transit. Contact Opengear by emailing [email protected] for further information.
Opengear console server User Manual Page 260 of 261
TECHNICAL SUPPORT Purchaser is entitled to thirty (30) days free telephone support (USA ONLY) and twelve (12) months free e-mail support (world wide) from date of purchase provided that the Purchaser first register their product(s) with Opengear by filling in the on-line form http://www.opengear.com/registration.html. Telephone and e-mail support is available from 9:00 AM to 5:00 PM, Mountain Time. Opengear's standard warranty includes free access to Opengear's Knowledge Base as well as any application notes, white papers and other on-line resources that may become available from time to time. Opengear reserves the right to discontinue all support for products that are no longer covered by warranty. LIMITATION OF LIABILITY No action, regardless of form, arising from this warranty may be brought by either party more than two (2) years after the cause of action has occurred. Purchaser expressly agrees that Opengear's liability, if any, shall be limited solely to the replacement or repair of the product in accordance with the warranties specifically and expressly set forth herein. The remedies of the Purchaser are the exclusive and sole remedies available, and, in the event of a breach or repudiation of any provision of this agreement by Opengear, the Purchaser shall not be entitled to receive any incidental damages as that term is defined in Section 2-715 of the Uniform Commercial Code. Opengear waives the benefit of any rule that disclaimer of warranty shall be construed against Opengear and agrees that such disclaimers herein shall be construed liberally in favor of Opengear. THE FOREGOING WARRANTIES ARE THE SOLE ANDEXCLUSIVE WARRANTIES GIVEN IN CONNECTION WITH THE PRODUCT AND THE HARDWARE. OPENGEAR DISCLAIMS ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES AS TO THE SUITABILITY OR MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. OPENGEAR DOES NOT PROMISE THAT THE PRODUCT IS ERROR-FREE OR WILL OPERATE WITHOUT INTERRUPTION. IN NO EVENT SHALL OPENGEAR BE LIABLE FOR ANY LOST OR ANTICIPATED PROFITS, OR ANY INCIDENTAL, EXEMPLARY, SPECIAL OR CONSEQUENTIAL DAMAGES, REGARDLESS OF WHETHER OPENGEAR WAS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.