BLACK BOX Advanced Console Server Console Server Command Reference Guide
Below you will find brief information for Console Server Advanced Console Server. This manual will provide instructions on how to configure your Console Server, including setting up network settings, enabling serial ports, accessing devices, and securing the device. You will also find information on additional features, such as clustering, power management, and PCMCIA card integration. The guide helps you manage and connect with multiple devices through a central point.
Advertisement
Advertisement
BLACK BOX®
Advanced Console Server
Command Reference Guide
Software Version 2.6.0
BLACK BOX® Corporation
1000 Park Drive
Lawrence, PA 15055-1018
877-877-2269
http://www.blackbox.com
Release Date: December 2005
v© 2005 BLACK BOX® Corporation, all rights reserved
Information in this document is subject to change without notice.
BLACK BOX® is the registered trademark of BLACK BOX® Corporation in the United
States and other countries.
All trademarks, trade names, logos and service marks referenced herein, even when not specifically marked as such, belong to their respective companies and are not to be considered unprotected by law.
Table of Contents
..........................................................................
Preface 1
Performing Basic Network Configuration Using the wiz Command . . . . . . . . . . 16
Log Into CS Through the Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Use the wiz Command to Configure Network Parameters . . . . . . . . . . . . . . . . . . 17
iii
To Enable a Serial Port [vi method] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Chapter 2 - Device Access 23
Opening and closing a Telnet session to a serial port . . . . . . . . . . . . . . . . . . . . . . 24
Opening and closing an SSH session to a serial port . . . . . . . . . . . . . . . . . . . . . . 25
Calling ts_menu without arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
How to close the session from ts_menu (from the console of your unit) . . . 27
How to close the session from ts_menu (from a Telnet/SSH session) . . . . . 27
VI mode - Parameters Involved and Passed Values . . . . . . . . . . . . . . . . . . . 30
CLI Method - Terminal Profile Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Example of starting CAS session commands . . . . . . . . . . . . . . . . . . . . . . . . 50
iv |
Table of Contents
Chapter 3 - Authentication 53
VI mode - Parameters involved and passed values . . . . . . . . . . . . . . . . . . . . 53
To configure the authentication type for the serial ports. . . . . . . . . . . . . . . . . . . . 57
To configure authentication type for device console access. . . . . . . . . . . . . . . . . 58
Access Control via Radius Attribute NAS-Port-id . . . . . . . . . . . . . . . . . . . . . . . . 60
Kerberos Server Authentication with Tickets support . . . . . . . . . . . . . . . . . . . . . 64
Configuring CS to use Kerberos Tickets authentication. . . . . . . . . . . . . . . . . . . . 64
Configuring an LDAP server on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
What needs to be set in the /etc/ldap.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Enabling TACACS+ Authorization for Serial Ports. . . . . . . . . . . . . . . . . . . . . . . 74
Configuring Authorization with a TACACS+ Server [CLI] . . . . . . . . . . . . . . . . 74
Configuring Authorization with a TACACS+ Server [vi] . . . . . . . . . . . . . . . . . . 75
Setting User Authorization Permissions on the TACACS+ Server [vi] . . . . 75
Configuring a TACACS+ authentication server. . . . . . . . . . . . . . . . . . . . . . . . . . 77
Configuring the authorization on CS to access the serial ports [CLI] . . . . . . 78
Configuring a RADIUS authentication server . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Configuring the authorization on CS to access the serial ports [CLI] . . . . . . 79
Configuring an LDAP authentication server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Table of Contents
| v
The Linux-PAM Configuration Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
To connect to CS’s serial ports using SSH X.509 certificate . . . . . . . . . . . . . . . . 95
Chapter 4 - Network 97
CLI Method - DNS and Domain Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
vi |
Table of Contents
CLI Method - TCP Keep Alive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
MASQUERADE (nat table only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
REDIRECT (NAT table only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Using secure tunnels to create a VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Setup on the "Road Warrior" machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Table of Contents
| vii
Adding and Removing a Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Starting and Stopping a Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
CLI Method - VPN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Chapter 5 - Administration 149
VI Method - Involved parameters and passed values . . . . . . . . . . . . . . . . . 151
Port Slave Parameters Involved with syslog-ng . . . . . . . . . . . . . . . . . . . . . . . . . 159
Some Examples of Defining Sources: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Some Examples of Defining Filters: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Some examples of defining actions: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Examples connecting sources, filters and actions:. . . . . . . . . . . . . . . . . . . . 171
Syslog-ng configuration to use with Syslog buffering feature . . . . . . . . . . . . . . 172
Syslog-ng configuration to use with multiple remote Syslog servers. . . . . . . . . 173
viii |
Table of Contents
VI method - Configuration to use with Alarm Feature . . . . . . . . . . . . . . . . 182
CLI Method - Alarm Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
VI Method - Involved parameters and passed values . . . . . . . . . . . . . . . . . 187
VI Method - Involved parameters and passed values . . . . . . . . . . . . . . . . . 189
CLI Method - Date and Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Configuring using set_timezone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
VI Method - Involved parameters and passed values . . . . . . . . . . . . . . . . . 200
CLI Method - Save/Restore Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 204
CLI Method - Selecting a Pre-defined Security Profile. . . . . . . . . . . . . . . . 209
CLI Method - Configuring a Custom Profile. . . . . . . . . . . . . . . . . . . . . . . . 210
Chapter 6 - AlterPath PM integration 215
Prerequisites for Power Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Table of Contents
| ix
Configuring Power Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
VI Method - Involved parameters and passed values . . . . . . . . . . . . . . . . . 217
CLI Method - IPDU Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
How to change the IPDU Password. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Accessing the AlterPath PM regular menu from the Console Session . . . . . . . . 223
Manage Devices Plugged into a Single Outlet . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Manage Devices Plugged into Multiple Outlets . . . . . . . . . . . . . . . . . . . . . . . . . 227
To Manage Multiple IPDUs from the Command Line . . . . . . . . . . . . . . . . . . . . 229
To Manage Power Through the Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Power Management for Authorized Users (firmware version prior to 2.2.0) . . . 236
Adding an user of the pmusers group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Changing the group of an already existing user. . . . . . . . . . . . . . . . . . . . . . 236
Listing the commands available for the AlterPath PM . . . . . . . . . . . . . . . . 243
Chapter 7 - PCMCIA Cards Integration 251
Tools for Configuring and Monitoring PCMCIA Devices . . . . . . . . . . . . . 251
Removing the configuration from a Ethernet PCMCIA device. . . . . . . . . . 253
CLI Method - Ethernet PCMCIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
x |
Table of Contents
Removing the configuration from a wireless PCMCIA device . . . . . . . . . . 256
CLI Method - Wireless PCMCIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Establishing a Callback with your Modem PC Card . . . . . . . . . . . . . . . . . . 259
CLI Method - Modem PCMCIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Establishing a Callback with your ISDN PC Card . . . . . . . . . . . . . . . . . . . 270
Establishing a Callback with your ISDN PC Card (2nd way) . . . . . . . . . . . 272
CLI Method - ISDN PCMCIA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
CLI Method - Media Cards PCMCIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
How to Save/Load Configuration to/from CF/IDE. . . . . . . . . . . . . . . . . . . . . . . 279
Chapter 8 - Profile Configuration 289
pslave.conf CAS (Console Access Server) parameters . . . . . . . . . . . . . . . . . . . 299
pslave.conf TS (Terminal Server) parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Using the CLI interface to configure common parameters. . . . . . . . . . . . . . . . . 314
Table of Contents
| xi
Chapter 9 - Additional Features and Applications 323
VI mode - Parameters Involved and Passed Values . . . . . . . . . . . . . . . . . . 330
VI method - Passed Values and Involved Parameters . . . . . . . . . . . . . . . . . 344
Appendix A - New User Background Information 349
Who is logged in and what they are doing . . . . . . . . . . . . . . . . . . . . . . . . . . 350
xii |
Table of Contents
Configuring the Session Channel Break Extension in SSH Server . . . . . . . 356
Appendix B - Upgrades and Troubleshooting 361
CLI Method - Firmware Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Setting the Maximum Number of Bytes Received by the Interface . . . . . . . . . . 370
To set a limit of bytes received by the interface per second:. . . . . . . . . . . . 370
Administration parameters in the CLI interface . . . . . . . . . . . . . . . . . . . . . . . . . 373
Appendix C - Cabling and Hardware Information 375
Table of Contents
| xiii
Cable #1: BLACK BOX® RJ-45 to DB-25 Male, straight-through. . . . . . . . . . 382
Cable #2: BLACK BOX® RJ-45 to DB-25 Female/Male, crossover . . . . . . . . 382
Cable #3: BLACK BOX® RJ-45 to DB-9 Female, crossover . . . . . . . . . . . . . . 382
Cable #4: BLACK BOX® RJ-45 to BLACK BOX® RJ-45, straight-through . 383
Cable #5: BLACK BOX®/Sun Netra Cable. . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Loop-Back Connector for Hardware Test . . . . . . . . . . . . . . . . . . . . . . . . . . 384
BLACK BOX®\Sun Netra Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
RJ-45 Female to DB-25 Female Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Cable #1: Terminal Block to Terminal Block, crossover half duplex . . . . . . . . 388
Cable #2: Terminal Block to Terminal Block, crossover full duplex . . . . . . . . . 388
Appendix D - Copyrights 391
xiv |
Table of Contents
Glossary 395
In-band network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Out-of-band network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Table of Contents
| xv
xvi |
Table of Contents
..........................................................................
Preface
1.1 Purpose
This Reference Guide covers configuration and administration of the BLACK BOX®
Advanced Console Server using vi and CLI (Command Line Interface) methods.
VI is a text editor for UNIX type systems, therefore related configuration involves editing text files. All available features in the Advanced Console Server can be configured using the vi editor. For each configuration method, the feature have an indicator where the configuration is done using the vi editor or the CLI interface (when available). For further information about how to use the vi editor, consult Appendix A -
New User Information.
1.2 Audience and User Levels
This command reference guide is intended for the users who are responsible for the deployment and day-to-day operation and maintenance of the CS. It assumes that the reader understands networking basics and is familiar with the terms and concepts used in Local and Wide Area Networking. UNIX and Linux users will find the configuration process very familiar. It is not necessary to be a UNIX expert, to get the Advanced
Console Server up and running. There are two audiences or user levels for this manual:
New Users
These are users new to Linux and/or UNIX with a primarily PC/Microsoft background.
You might want to brush up on such things as common Linux/UNIX commands and how to use the vi editor prior to attempting installation and configuration. This essential background information appears in
“Appendix A - New User Background Information” on page 349
. It is recommended that New Users configure the CS using a Web browser following the User’s Guide that is totally based on the Web Interface. However, new users can also configure the CS with vi or the Command Line Interface (CLI).
Preface
1
2 |
Power Users
These are UNIX/Linux experts who will use this manual mostly for reference. Power
Users can choose between configuring the Advanced Console Server via Web browser, vi, or CLI.
The Advanced Console Server is based on an embedded Linux operating system.
Configurations are done using the vi text editor or the Command Line Interface
(CLI). If you are f new to Linux, it is advisable to refer to the BLACK BOX® CS
Installation, Administration, and User’s Guide, which is focused on the CS Web
Manager.
Appendix A - New User Background Information has a section dedicated to the vi text editor and its commands.
1.3 How to use the CLI (Command Line Interface)
Throughout the manual a number of features can be configured using the CLI interface instead of the vi editor. The CLI, or Command Line Interface tool is preferred by many network and system administrators since it allows for automation of configuration through scripting and provides a simple way to document and record a systems configuration. This section introduces the CLI tool and provides information on how to use the interface.
Modes of Operation
1. Interactive mode - commands will be read from standard input.
2. File batch mode - commands will be taken from a file (-f <file>).
3. Batch mode - commands will be taken from the command line arguments
•
Each invocation of the CLI should return a value to the shell indicating success or failure of the command.
•
Each invocation of the CLI should return a text string if any error occurred. If the command is successful then no text is returned.
For example, from the CS prompt, to change the hostname you can directly do:
[root@CAS root]#/bin/CLI config network hostsettings hostname <host_name>
Both modes are oriented by keywords that allow the moving from one state to another.
Each state will have a specific set of keywords attached to it.
IMPORTANT: Strings with spaces in CLI Batch Mode must be quoted with single and double quotes. To enter strings with spaces using the Batch Mode the user must type '"<string1 string2>"' . Example:
# CLI config network hostsettings banner "'Welcome to CS'"
Keywords meanings
1. Changing from one state to another. For example: entering in configuration mode or exiting from configuration mode. Once the CLI goes to one state it will remain in this state until another keyword is entered to change the state.
2. Specifying a function or an action to be performed. For example: Apply changes
(runconfig), Save changes into flash (savetoflash), back up configuration script
(backupconfig), upgrade firmware (upgradefw), connect to a console (console), etc.
3. Specifying a set of parameters to be configured. For example: cli> config security security>adduser username john password john12 admin yes biouser no shell /bin/sh
| 3
4 |
4. Specifying a parameter to be changed. For example: cli> network hostsettings hostsettings> dhcp yes
Interactive Mode
The CLI has some features in order to easy its use. All of them are described in the lines below:
1. AutoComplete of keywords using the tab key.
2. Cursor movement keys:
•
<Ctrl> a - Move to the start of the current line.
•
<Ctrl> e - Move to the end of the line.
•
<Ctrl> b - Move back a character (same as <left arrow key>).
•
<Ctrl> f - Move forward a character (same as <right arrow key).
•
<Esc> b - Move back to the start of the current or previous word. Words are composed of letters and digits.
•
<Esc> f - Move forward to the end of the next word. Words are composed of letters and digits.
•
<Ctrl> l - Clear the screen and redraw the current line, leaving the current line at the top of the screen.
3. Command History keys:
•
<Ctrl> n - Move `forward' through the history list, fetching the next command
(same as <down arrow key>).
•
<Ctrl> p - Move `back' through the history list, fetching the previous command
(same as <up arrow key>)
The command history buffer is only available for the last 500 commands in the current session. The history is cumulative, so terminating the session will not clear the buffer. This means a user can login to the CLI and go back over the commands entered by a previous user.
4. Changing text keys:
•
<Ctrl> d - Delete the character under the cursor (same as <delete key>)
•
<Ctrl> h - Same as <Backspace key>
•
<Ctrl> k - Kill the text from the cursor to the end of the line.
•
<Ctrl> u - Kill backward from the cursor to the beginning of the current line.
•
<Ctrl> w - Kill the word behind point.
•
<Esc> d - Kill from point to the end of the current word, or if between words, to the end of the next word
•
<Esc> <tab> - This displays the current value of the parameter keyword entered.
You can then edit the value
For example: To display the current value for domain and edit it.
cli> config network hostsettings hostsettings> domain [press <Esc> <Tab> now]
You see: hostsettings> domain blackbox.com
5. Special Keywords
These words are global and can be used in any state. For these special keywords to work, they must be entered first before the rest of the keywords for that state, or they must be the only word in the command line.
•
quit - It finishes the CLI session.
•
return - It goes back to the previous state.
•
info - This shows the help info available for the current state. For example, user can enter the network more and type ‘info’ and a brief overview about network configuration may be presented. Or he can type ‘info config network’ from the cli>
prompt. Depending on the screen size of the user’s current shell, users may page through the info. If the info text lines exceeds the number of lines capable of being shown in the screen, the user will get the option to type ‘m’ for more, ‘b’ for back, or ‘q’ for quit.
•
show - Display the configuration parameter(s). It's valid only in configuration state. For example, the following displays some configurations for port 1.
cli> config physicalports 1
Ports[1]> show general general: alias: protocol: consoletelnet speed: 9600 flow: none parity: none datasize: 8 stopbits: 1
CLI arguments and its meanings
When calling the CLI interface by typing CLI in the shell prompt, you can pass some arguments to it. Here is a brief description
•
-q - suppresses the output of error messages from the CLI.
•
-t <time> - the timeout in minutes. Default 10 minutes.
•
-T - disable idle timeout. Same as "-t 0"
•
-s - save changes to flash (same as savetoflash keyword) (batch mode only)
•
-r - activate changes (same as runconfig keyword) (batch mode only)
•
-f <filename> - executes the commands in the file <filename>
Other important features of the CLI
1. Only one user logged in as “root” or “admin” can have an active CLI or Web
Manager session. A second user who connects through the CLI or the Web Manager
| 5
6 | as the “root” or “admin” has a choice to abort the session or close the other user’s session.
If there are cron jobs running through automated scripts, a “root” or “admin” user login can cause the automated cron jobs to fail. Make sure that the users with administrative privileges are aware of this.
2. CLI has 3 possible user levels:
•
Root user (Linux root user) - Has access to the full functionality of the CLI. Has
‘shell’ command in the CLI that allows the user to have access to the CS Linux shell prompt. (See note below)
•
Admin - Has access to the full functionality of the CLI except for the ‘shell’ command. So an admin user will not be able to have access to the CS Linux shell prompt. (See note below)
•
Regular user - Has access to a limited functionality of the CLI. Only has access to cli->applications
functionality.
NOTE:
Users can change the login shell in /etc/passwd to execute /bin/CLI so that they will get the CLI right away when they log into the
CS
. If user, root, is configured to have /bin/CLI as their default shell, he/she can still have access to the
CS
shell prompt by executing the command ‘shell’ from the CLI. Any other users who configured /bin/CLI as their default shell won’t have the ‘shell’ command so they won’t be able to have access to the
CS
shell prompt.
3. The CLI will generate syslog messages when the user open or close a session and for each command executed. Examples:
Apr 19 17:51:44 src_dev_log@swes-129 CLI[413]: User root starts a interactive CLI session.
cli>config
Apr 19 16:18:02 src_dev_log@swes-129 CLI[412]: User root executed
[config]config>Apr 19 16:28:02 src_dev_log@swes-129 CLI[412]: Session closed due idletimeout
Apr 19 17:54:23 src_dev_log@swes-129 CLI[413]: User root executed [quit]
Apr 19 17:54:23 src_dev_log@swes-129 CLI[413]: User root finishes the CLI session
4. The CLI will write every command executed in interactive mode in the file
"~/.history". This file will keep the last 1000 commands executed in any CLI session.
List of CLI Keywords
The following table list the keywords accessible through the CLI interface.
Table 1.1: CLI Keywords
administration
backupconfig sessions upgradefw
To restore/save configurations from/to a FTP server or a storage device.
To manage sessions kill - End a session to a specific serial port.
list - Display the list of current serial port connections.
To upgrade the firmware
.
Provide a domain name or the IP address of the server
applications
connect pm view
config
administration
bootconfig date/time notifications ntp timezone
application
terminalmenu
discardchanges ipmi network hosttable
To access the console server connection menu.
To access the CS power management menu.
To display the data buffer files for a serial port.
To configure boot configuration parameters.
To set the date and timer.
To set up alarm notifications.
To configure Network Time Protocol.
To select and set a GMT zone.
To configure a terminal profile menu.
To cancel the configuration changes
To configure devices configured with IPMI.
To configure Network Parameters.
To add or delete a host from the table.
| 7
8 | pcmcia snmp stroutes syslog vpn physicalports restorefromflash savetoflash security virtualports
portStatus shell
version
runconfig info quit return show
Table 1.1: CLI Keywords
To configure supported PCMCIA cards.
To configure SNMP server.
To setup routes manually for data routing to other subnets.
To setup a syslog server for logging system messages.
To setup a VPN connection.
To configure serial ports individually or collectively.
To restore the configuration saved in flash.
To save the configuration changes to flash
To configure security profiles and authentication servers.
To cascade multiple CS console servers.
To display the status on all serial ports.
To open the command shell.
To display the CLI version
To activate the changes.
To display a brief description on the current CLI parameter.
To exit the CLI mode.
To go up one level in the CLI menu structure.
To display the current configuration information.
1.4 How to use this Guide
This guide is organized into the following sections:
•
describes the basic configuration procedures to make the Advanced Console Server operational and available on the network. It includes configuring the network parameters, logging in and selecting a security profile.
•
contains the ways to access the serial ports, depending on the protocol you configured for that serial port. This chapter also has information about clustering, menu shell and data buffering.
•
provides configuration instructions for different types of authentication available in the CS. This chapter includes detailed information about the Linux-PAM module and Shadow Passwords.
•
all configuration related to network is explained in this chapter. This chapter approaches since basic configuration until the most the most advanced ones such as filters and VPN.
•
Administration
contains system’s management, administration and maintenance
related features.
•
Power Management with AlterPath™ PM Integration involves features for those
who have an IPDU being controlled by the CS.
•
PCMCIA Cards Integration this chapter has information about compatible
PCMCIA cards and the respective instructions to make them work with the CS.
•
Profile Configuration approaches the main configuration file of the unit. This
chapter explains each parameter of the pslave.conf file. It also has step by step examples for TS, CAS and RAS profiles.
•
Additional Features and Applications has information about special features and
step by step instructions on how to set up them.
•
Appendix A - New User Background Information
contains information for those who are new to Linux/UNIX.
•
Appendix B - Upgrades and Troubleshooting
covers the most common problems that users faces when using the CS.
•
Appendix C - Cabling and Hardware Information
Information has detailed information and pinout diagrams for cables used with the CS.
•
Appendix D - Copyrights lists details about applications that were incorporated
into the product.
•
contains information about specific words and terms used in this manual.
| 9
1.5 Conventions and Symbols
This section explains the significance of each of the various fonts, formatting, and icons that appear throughout this guide.
Fonts
This guide uses a regular text font for most of the body text and Courier for data that you would input, such as a command line instruction, or data that you would receive back, such as an error message. An example of this would be:
# telnet 200.200.200.1 7001
Hypertext Links
References to another section of this manual are hypertext links that are underlined (and are also blue in the PDF version of the manual). When you click on them in the PDF version of the manual, you will be taken to that section.
Glossary Entries
Terms that can be found in the glossary are underlined and slightly larger
than the rest of the text. These terms have a hypertext link to the glossary.
Quick Steps
Step-by-step instructions for installing and configuring the CS are numbered with a summarized description of the step for quick reference. Underneath the quick step is a more detailed description. Steps are numbered 1, 2, 3, etc.
For example:
Step 1 - Modify the pslave.conf file.
You will modify four Linux files to let the CS know about its local environment.
Open the file plsave.conf and add the following lines...
Parameter Syntax
This manual uses standard Linux command syntaxes and conventions for the parameters described within it.
10 |
Brackets and Hyphens (dashes)
The brackets ([])indicate that the parameter inside them is optional, meaning that the command will be accepted if the parameter is not defined. When the text inside the brackets starts with a dash (-) and/or indicates a list of characters, the parameter can be one of the letters listed within the brackets.
Example: iptables [-ADC] chain rule-specification [options]
Ellipses
Ellipses (...) indicate that the latest parameter can be repeated as many times as needed.
Usually this is used to describe a list of subjects.
Example: ls [OPTION]...[FILE]...
Pipes
The pipe (|) indicates that one of the words separated by this character should be used in the command.
Example: netstat {--statistics|-s} [--tcp|-t] [--udp|-u] [--raw|-w]
When a configuration parameter is defined, the Linux command syntax conventions will be also used, with a difference.
Greater-than and Less-than signs
When the text is encapsulated with the “<>” characters, the meaning of the text will be considered, not the literal text. When the text is not encapsulated, the literal text will be considered.
Spacing and Separators
The list of users in the following example must be separated by semicolons (;); the outlets should be separated by commas (,) to indicate a list or with dashes(-) to indicate range; there should not be any spaces between the values. sXX.pmusers: The user access list. For example: jane:1,2;john:3,4. The format of this field is:
[<username>:<outlet list>][;<username>:<outlet list>...]
| 11
where <outlet list>'s format is:
[<outlet number>|<outlet start>-<outlet end>][,<outlet number>|<outlet start>-<outlet end>]...
Cautionary and Instructional Information
Note boxes contain instructional or cautionary information that the reader especially needs to bear in mind. There are three levels of information:
WARNING:
A very important type of tip or warning. Do not ignore this information.
IMPORTANT:
An important tip that should be read. Review all of these notes for critical information.
TIP:
An informational tip or tool that explains and/or expedites the use of the product.
12 |
This page has been left intentionally blank.
| 13
14 |
Chapter 1
Basic Network Configuration
..........................................................................
This chapter describes the procedures for setting up the basic network configuration to make the CS available on the network. In addition, it provides procedures to login, change the default password, and setup the security profile.
Configuring network setting using the vi method or the CLI method are described in
Chapter 4, “Network” in detail.
1.1 Networking Settings
This following section describes how to configure the network parameters using the wiz command, vi, or CLI where applicable. The instructions assume that you are installing a new Advanced Console Server in your network, or you are restarting an existing unit from factory default parameters.
Performing Basic Network Configuration Using the wiz Command
The following procedure assumes that a hardware connection is made between the CS’s console port and the COM port of a computer.
Log Into CS Through the Console
From your terminal emulation application, log into the console port as root.
CS login: root
Password: bb
It is strongly recommended to change the default password “bb” before setting up the
CS
for secure access to the connected servers or devices.
Password
Change the “root” password. The default /etc/passwd file has the user “root” with password “bb”. You should change the password for user “root” as soon as possible.
To change any user password, run the command:
# passwd <user>
Security Advisory
The following Security Advisory appears the first time CS is powered on, or when the unit is reset to factory default parameters. After you have configured the basic network settings, a Security Profile must be selected before proceeding to other configuration
procedures, such as user and port settings. See “Selecting A Security Profile” on how to
configure a profile using CLI. See BLACK BOX® CS Installation, Administration, and
User’s Guide for detailed information on security profiles and configuration options using the Web Manager.
16
Important - Security Advisory!
Console Management provides critical access to management features of attached equipment. Please take the required precautions to understand the potential impacts this device may have to your SECURITY policies.
From factory, this device is configured as follows:
• Single password for ROOT;
• All serial port DISABLED;
• DHCP, Telnet, SSHv1 & SSHv2, and HTTP & HTTPS enabled.
Black Box STRONGLY recommends:
1. To change the ROOT password before setting up the box for secure access to the CS equipment.
2. That you SELECT A SECURITY PROFILE to complete the INITIAL
SETUP. Security is dependent on Policy and is Configurable to fit in environments with varying levels of Security. Black Box provides three preset Security Levels: SECURED, MODERATE and OPEN, and in addition, the ability to set a CUSTOM Security Profile.
3. Do not leave the equipment idle WITHOUT selecting a SECURITY
PROFILE.
4. To ENABLE Serial Ports and CONFIGURE them using Web UI or CLI.
Refer to the Quick Start Guide or the User's Guide for Security Profile selection details and Serial Port configuration.
Use the wiz Command to Configure Network Parameters
Step 1 - Launch the Configuration Wizard by entering the wiz command.
[root@CAS etc]# wiz
The system brings up a configuration wizard banner similar to the following figure and begins running the wizard.
BLACK BOX® CS Command Reference Guide
17
**********************************************
*****C O N F I G U R A T I O N W I Z A R D**
**********************************************
Current configuration:
Hostname: CAS
DHCP: disabled
System IP: 192.168.48.11
Domain name: blackbox.com
Primary DNS Server: 192.168.44.21
Second DNS Server: #
Gateway IP: 192.168.48.1
Network Mask: 255.255.252.0
Set to defaults? (y/n) [n]:
Set to defaults? (y/n) [n]:
Step 2 - At the prompt, enter n to change the defaults.
Set to defaults (y/n)[n]: n
Step 3 - Press Enter to accept the default hostname, otherwise enter your own hostname.
Hostname [CAS]: fremont_branch_CS
Step 4 - Press Enter to keep DHCP enabled, or enter “n” to specify a static IP address for CS.
By default, CS uses the IP address provided by the DHCP server. If your network does not use DHCP, then CS will default to 192.168.160.10.
Do you want to use DHCP to automatically assign an IP for your system? (y/n) [n] :
Step 5 - Change the default static IP address, see your network administrator to obtain a valid IP address.
System IP[192.168.160.10]: CS_IP_address
18
Step 6 - Enter the domain name.
Domain name[blackbox.com]: domain_name
Step 7 - Enter the IP address for the Primary DNS (domain name) server.
Primary DNS Server[192.168.44.21]: DNS_server_IP_address
Step 8 - Enter the IP address for the gateway.
Gateway IP[eth0]: gateway_IP_address
Step 9 - Enter the netmask for the subnetwork.
Network Mask[#] : netmask
The network configuration parameters appear.
Step 10 - Enter y after the prompts shown in the following screen example.
Are all these parameters correct? (y/n)[n]: y
Do you want to activate your configurations now? (y/n)[y]: y
Do you want to save your configuration to Flash? (y/n)[n]: y
Step 11 - To confirm the configuration, enter the ifconfig command.
BLACK BOX® CS Command Reference Guide
19
1.2 Selecting A Security Profile
A security profile must be selected before proceeding further with configuration of CS.
For detailed information on security profiles see BLACK BOX® CS Installation,
Administration, and User’s Guide.
To Select a Security Profile
Select a pre-defined Security Profile, or define a Custom profile for specific services.
The available profiles are:
•
Secured: Disables all protocols except SSHv2, HTTPS, and SSH to Serial Ports.
•
Moderate: Enables SSHv1, SSHv2, HTTP, HTTPS, Telnet, SSH and Raw connections to Serial Ports, ICMP, and HTTP redirection to HTTPS.
•
Open: Enables all services, Telnet, SSHv1, SSHv2, HTTP, HTTPS, SNMP, RPC,
ICMP and Telnet, SSH and Raw connections to Serial Ports.
•
Default: Sets the profile to the same configuration as Moderate.
•
Custom: Enable or disable individual protocols and services, and configure access to ports.
CLI Mode
Step 1 - Enter the CLI mode
[root@CAS etc]# CLI
Step 2 - At the prompt enter the following string.
cli > config security profile
The following commands are available under the “profile” prompt.
profile> show custom default info moderate open quit return secured
Step 3 - To configure a Default, Moderate, or Secured pre-defined security profile, enter the following string.
profile> <moderate> or, profile> <secured> or, profile> <default>
20
Step 4 - To configure a custom security profile, navigate to the custom menu.
profile > custom
Step 5 - From the custom menu enable or disable desired protocols using the following syntax.
custom > [protocol] [yes/no]
To display the current configuration as shown in the following figure, enter: custom > show custom>show
[custom]
ftp: no
telnet: no
.[ssh]
..[ssh_x509]
CA_file:
hostkey:
authorizedkeys:
sshv1: yes
sshv2: yes
sshd_port: 22
root_access: yes
snmp: no
.[web]
http: yes
https: yes
http_port: 80
https_port: 443
http2https: yes
rpc: no
ipsec: no
icmp: yes
.[ports]
ssh2sport: yes
telnet2sport: yes
raw2sport: yes
auth2sport: no
bidirect: yes
BLACK BOX® CS Command Reference Guide
21
1.3 Enabling Serial Ports
From the factory CS is configured with all serial ports disabled.
To Enable a Serial Port [vi method]
Step 1 - From the terminal window navigate to the portslave directory to edit the pslave.conf file.
[root@CAS /] cd /etc/portslave
[root@CAS portslave]# vi pslave.conf
Step 2 - Navigate to Port-specific parameters to uncomment the sxx.tty and enable the serial ports.
# Port-specific parameters
# s1.tty ttyS1
#s2.tty ttyS2
#s3.tty ttyS3
#s4.tty ttyS4
#s5.tty ttyS5
#s6.tty ttyS6
#s7.tty ttyS7
#s8.tty ttyS8
To Enable a Serial Port [CLI method]
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - To enable single or multiple serial ports enter the following command:
cli>config physicalports 1,2,3,4 enable yes
22
Chapter 2
Device Access
..........................................................................
Chapter 2 - Device Access
This chapter will introduce all the possible ways to access the serial ports of the CS.
From this point is considered that the unit is properly configured using one of the possible profiles (CAS or TS). More information about how to configure a profile can be found on
Chapter 8 - Profile Configuration
.
2.1 Accessing Serial Ports
There are four ways to access serial ports, depending on the protocol you configured for that serial port: setting all.protocol to socket_server for Telnet access, setting it to socket_ssh for
SSH access, or setting it to socket_server_ssh both.
An administrator can access the serial port by statically addressing it (using TCP port number, alias name, or IP address) or by accessing the next free serial port available from an existent pool (by using the pool's TCP port number, alias or IP address).
Default Configuration Parameters
These are the default configuration settings:
•
DHCP enabled (if there is no DHCP Server, IP for Ethernet is 192.168.160.10 with a
Netmask of 255.255.255.0)
•
CAS configuration
•
socket_server in all ports (access method is Telnet)
•
9600 bps, 8N1
•
No Authentication
Opening and closing a Telnet session to a serial port
To open a Telnet session to a serial port or the first free serial port belonging to a pool of serial ports, issue the command:
# telnet <CAS hostname> <TCP port number> where
•
<CAS hostname> is the hostname configured in the workstation where the Telnet client will run (through /etc/hosts or DNS table). It can also be just the IP address of the CS
(Ethernet's interface) configured by the user or learned from DHCP.
•
<TCP port number> is the number associated to the serial port or pool of serial ports.
From factory, 7001 corresponds to serial port 1, 7002 to serial port 2 and so forth, and
3000 is a pool with all serial ports.
To close the Telnet session, just press the Telnet hotkey configured in Telnet client application (usually it's "Ctrl]") and "q" to quit.
24
Opening and closing an SSH session to a serial port
To open a SSH session to a serial port or the next free serial port from a pool, issue the command:
# ssh -l <Username>:<Server> <CAS hostname>
•
<Username> is the user configured to access that serial port. It is present either in the local CAS database or in a Radius/Tacacs/LDAP/Kerberos, etc database.
•
<Server> can be just the TCP port number assigned for that serial port (7001, 7002, etc), pool of ports (3000, etc), the alias for the server connected to that serial port or the alias of a pool of ports.
•
<CAS hostname> is the hostname configured in the workstation where the SSH client will run (through /etc/hosts or DNS table). It can also be just the IP address of the CS (Ethernet's interface) configured by the user or learned from DHCP.
To close the SSH session, press the hotkey defined for the SSH client followed by a “.”
The default is "~."
Make sure you enter the escape character followed by a “.” at the beginning of a line to close the SSH session.
Accessing Serial Ports using “ts_menu”
ts_menu is an application to facilitate connection to the serial ports. The following are the methods of executing the ts_menu command.
•
Calling ts_menu without specifying any arguments.
•
Calling ts_menu with command line arguments
•
Using CLI to call ts_menu.
Calling ts_menu without arguments
To access the serial port (Telnet or SSH) using ts_menu, login to the CAS unit and, after receiving the shell prompt, run ts_menu. The servers (aliases) or serial ports will be shown as option to start a connection (Telnet/SSH). After typing ts_menu, you will see something similar to the following:
Serial Console Server Connection Menu for your Master Terminal Server
1 ttyS1 2 ttyS2 3 ttyS3 4 ttyS4
5 ttyS5 6 ttyS6 7 ttyS7 8 ttyS8
Type 'q' to quit, a valid option[1-8], or anything else to refresh:
BLACK BOX® CS Command Reference Guide
25
Calling ts_menu with arguments
Apart from calling ts_menu with no arguments (which directs the user to the traditional ts_menu interface) this application can be used with the following command line arguments: ts_menu [-u<user>] [-l[c]] [-ro] [-s] [-auth] [<console port>]
The meaning of each argument is:
•
-u<user> - Invokes ts_menu as the user named by <user>. This requires a password to be entered. The user have access only to the authorized serial ports.
•
-l[c] - Generates a list of all ports that the user has access to and terminates. Port aliases will be presented if defined. For the remote ports (clustering) if port alias is not defined they will be shown as "ip_addr:port" (ip_addr referring to the slave
CS). The default is displaying ports in alphabetical order, but in case "c" flag is also specified the listing will be sorted by console server (master unit showing first).
•
-ro - Invokes ts_menu in read only mode. It works even if the user is the only one logged to a certain port. In this mode, the user can connect to any port he has access to but cannot type in. He is in sniff mode. A message stating "Read only mode" is provided in case the user attempts to interact with that port. Note however that a real sniff session (the user isn't the first one to log to a certain port) is only allowed if he is authorized to.
•
-s - Invokes ts_menu in a way that all ports (including slave CS’s) are presented in a single list sorted in alphabetical order. Not using this option causes the display to be as for the old implementation.
•
-auth - For backward compatibility, this option makes the new ts_menu implementation behave as the old one so that authentication is performed again to access each port.
•
<console port> - If issued, produces a direct connection to that port. In the case the user doesn't have access to that port or the port doesn't exist, the application returns a "console not found" message and terminates. <console port> can be the port alias or the port number. In case of clustering, port number must include a reference to the slave CS as "host:port" (where host is the slave hostname or IP address).
Other options:
•
-p - Display TCP port
•
-P - Use the TCP port instead of IP address
•
-i - Display Local IP assigned to the serial port
•
-s - Show the ports in a sorted order
•
-u <name> - Username to be used in SSH/Telnet command
•
-U - Always ask for an username
•
-e <[^]char> - Escape char used by Telnet or SSH
26
How to close the session from ts_menu (from the console of your unit)
To close the session from the ts_menu, follow the steps bellow:
Step 1 - Enter the escape character.
The escape character is shown when you first connect to the port. In character/text Mode, the Escape character is ^]
After entering the escape character, the following is shown:
Console escape. Commands are:
•
l - go to line mode
•
c - go to character mode
•
z - suspend telnet
•
b - send break
•
t - toggle binary
•
e - exit telnet
Step 2 - Press “e” to exit from the session and return to the original menu.
Select the exit option and you will return to the shell prompt.
How to close the session from ts_menu (from a Telnet/SSH session to your unit)
You have to be sure that a different escape character is used for exiting your Telnet/SSH session; otherwise, if you were to exit from the session created through the ts_menu, you will close your entire Telnet session to your unit. To do this, when you first Telnet/SSH to your unit, use the -e option. So for example, to set Ctrl-? as the escape character, type:
# telnet -e ^? 192.168.160.10
# ssh -e ^? [email protected]
To exit from the session created through the ts_menu, just follow Step 1 from above.
To exit from the entire Telnet session to your unit, type the escape character you had set.
To exit from the entire SSH session to your unit, type the escape character you had set plus character "."(dot).
To close an SSH session the escape character followed by a “.” must be entered at the beginning of a line.
CLI Mode - ts_menu
You can call ts_menu from the CLI interface.
BLACK BOX® CS Command Reference Guide
27
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Call the menu.
To call the ts_menu, access the following menu: cli> applications connect [Enter]
A screen similar to the following appears:
Serial Console Server Connection Menu for your Master Terminal Server
1 PM 2 ttyS3 3 ttyS4 4 ttyS5
5 ttyS6 6 ttyS7 7 ttyS8 8 ttyS9
9 ttyS10 10 ttyS11 11 ttyS12 12 ttyS13
13 ttyS14 14 ttyS15 15 ttyS16
Type 'q' to quit, 'b' to return to previous menu, a valid port[1-15],
or anything else to refresh:
To see the “connect” options, at the following prompt press [tab] twice.
cli > applications > connect
The following options display.
consolename list readonly
To display a list of the available ports run the following command.
cli > applications > connect list
To connect to the console of a device in a read-only mode run the following command. cli > applications > connect readonly consolename <consolename>
The connection is made to the device and a “Read only mode” message is displayed.
To make a direct connection to the console of a device run the following command.
cli > applications > connect consolename <consolename>
Step 3 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
28
2.2 Data Buffering
Data buffering can be done in local files or in remote files through NFS. When using remote files, the limitation is imposed by the remote Server (disk/partition space) and the data is kept in linear (sequential) files in the remote Server. When using local files, the limitation is imposed by the size of the available ramdisk. You may wish to have data buffering done in file, syslog or both. For syslog, all.syslog_buffering and
conf.DB_facility are the parameters to be dealt with, and syslog-ng.conf file should be
set accordingly. (Please see Syslog-ng
for the syslog-ng configuration file.) For the file,
all.data_buffering is the parameter to be dealt with.
Conf.nfs_data_buffering is a remote network file system where data buffering will be written, instead of using the default directory /var/run/DB. When commented, it indicates local data buffering. The directory tree to which the file will be written must be NFS-mounted and the local path name is /mnt/DB_nfs. The remote host must have
NFS installed and the administrator must create, export, and allow reading/writing to this directory. The size of this file is not limited by the value of the parameter s1.data_buffering, though the value cannot be zero since a zero value turns off data buffering.
The conf.nfs_data_buffering parameter format is:
<server name or IP address>:<remote pathname>
If data buffering is turned on for port 1, for example, the data will be stored in the file
ttyS1.data in local directory /var/run/DB or in remote path name and server indicated by
conf.nfs_data_buffering.
Ramdisks
Data buffering files are created in the directory /var/run/DB. If the parameter
s<nn>.alias is configured for the port <nn>, this name will be used. For example, if the alias is called bunny, the data buffering file will be named bunny.data.
Linear vs. Circular Buffering
For local data buffering, this parameter allows users to buffer data in either a circular or linear fashion. Circular format (cir) is a revolving buffer file that is overwritten whenever the limit of the buffer size (set by all.data_buffering) is reached. In linear format (lin), data transmission between the remote device and the serial port ceases once the 4k bytes Rx buffer in the kernel is reached. Then if a session is established to the serial port, the data in the buffer is shown (all.dont_show_DBmenu or
sxx.dont_show_DBmenu must be 2), cleared, and data transmission is resumed. Linear buffering is impossible if flow control is set to none. Default is cir.
BLACK BOX® CS Command Reference Guide
29
How to Configure
VI mode - Parameters Involved and Passed Values
To configure Data Buffering, follow the steps bellow:
Step 1 - Open the /etc/portslave/pslave.conf file.
All parameters related to Data Buffering are in the pslave.conf file. Change the desired parameters according to the table below:
Parameter Description
all.data_buffering
A non zero value activates data buffering (local or remote, according to what was configured in the parameter conf.nfs_data_buffering). If local data buffering, a file is created on the CS; if remote, a file is created through NFS in a remote server.
All data received from the port is captured in this file. If local data buffering, this parameter means the maximum file size (in bytes). If remote, this parameter is just a flag to activate (greater than zero) or deactivate data buffering. When local data buffering is used, each time the maximum file size is reached the oldest 10% of stored data is discarded, releasing space for new data (FIFO system) - circular file. When remote data buffering is used, there's no maximum file size other than the one imposed by the remote server - linear file.
This file can be viewed using the normal UNIX tools (cat, vi, more, tail, etc...). Size is in BYTES not kilobytes.
conf.nfs_data_buffering
This is the Remote Network File System where data captured from the serial port will be written instead of being written to the local directory /var/run/ DB. The directory tree to which the file will be written must be NFS-mounted, so the remote host must have NFS installed and the administrator must have created, exported and allowed reading/writing to this directory. The size of this file is not limited by the value of the parameter all.data_buffering, though the value cannot be zero since a zero value turns off data buffering. The size of the file is dependent on the NFS server only (hard drive, partition size, etc.).
Table 2.1: Data buffering parameters in /etc/portslave/pslave.conf file
30
Parameter
all.DB_mode
all.DB_user_logs
Description
When configured as cir for circular format, the buffer is like a revolving file that is overwritten whenever the limit of the buffer size (as configured in all.data_buffering or s<n>.data_buffering) is reached. When configured as lin for linear format, once 4k bytes of the Rx buffer in the kernel is reached, a flow control stop (RTS off or XOFF-depending on how all.flow or s<n>.flow is set) is issued to prevent the serial port from receiving further data from the remote.
Then when a session is established to the serial port, a flow control start (RTS on or XON) will be issued and data reception will then resume. If all.flow or s<n>.flow is set to none, linear buffering isn’t possible. Default is cir.
When "on", a line containing the time stamp, the username, the event itself (connection/disconnection) and the type of session
(Read/Write or Read Only) will be added to the data buffering file every time a user connects or disconnects to the corresponding port.
The log message has the following formats:
1) "<connect> [timestamp] [username] [session type] </connect>"
2)"<disconnect> [timestamp] [username] </disconnect>".
all.syslog_buffering
when [timestamp] = "YYYY-MM-DD hh:mm:ss"
[session type] = "Read/Write" or "Read_Only"
When non zero, the contents of the data buffer are sent to the syslogng every time a quantity of data equal to this parameter is collected.
The syslog level for data buffering is hard coded to level 5 (notice) and facility is local plus
conf.DB_facility. The file /etc/syslog-ng/syslog-ng.conf
should be set accordingly for the syslog-ng to take some action. For
more information about it consult “Syslog-ng” on page 159
.
Table 2.1: Data buffering parameters in /etc/portslave/pslave.conf file
BLACK BOX® CS Command Reference Guide
31
Parameter Description
all.syslog_sess
all.dont_show_DBmenu
When zero, a menu with data buffering options is shown when a user connects to a port with a non empty data buffering file. When 1, the data buffering menu is not displayed. When 2, the data buffering menu is not shown but the data buffering file is displayed if not empty. When 3, the data buffering menu is shown, but without the erase and show and erase options.
all.DB_timestamp
This parameter determines whether syslog is generated when a user is connected to the port or not. Originally, syslog is always generated whether the user is connected to the port or not. Now, CS administrators have the option to NOT have syslog generate messages when there is a user connected to a port. This feature does not affect the local data_buffering file. When set to 0 (default), syslog is always generated. When set to 1, syslog is only generated when there are no users connected to the port sending the data.
When a user connects to the port that is sending data, syslog messages stop being generated.
Records the time stamp in the data buffering file (1) or not (0). If it is configured as 1, the software will accumulate input characters until it receives a CR and LF from the serial port or the accumulated data reaches 256 characters. Either way, the accumulated data will be recorded in the data buffering file along with the current time.
The parameter all.data_buffering has to be with a non-zero value for this parameter to be meaningful.
Table 2.1: Data buffering parameters in /etc/portslave/pslave.conf file
Step 2 - Activating and saving the changes made.
To activate the changes issue the command:
# runconf
To save the changes, run the command:
# saveconf
CLI Method - Data Buffering
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Configuring data buffering.
32
Data buffering parameters are under the following menu: cli>config physicalports all databuffering
Configurable parameters are:
•
buffersyslogeverytime - If YES is chosen Syslog will be buffered at all time. If NO is chosen, it will only be buffered when nobody is connected to the port.
•
nfspath - Defines the NFS path.
•
syslogserver - Defines the IP address of the Syslog server.
•
filesize - Defines the maximum size of the data buffer file. This parameter must be greater than zero otherwise all parameters relating to data buffering are disregarded.
•
showmenu - Controls the DB menu options. Valid values are: yes, no, noerase, file.
•
syslogsize - Maximum size of syslog data buffer message.
•
mode - Chooses between circular or linear data buffering.
•
syslogfacility - Defines the facility number for messages generated by the CS to be sent to the Syslog server.
•
timestamp - Choose YES to enable timestamp and NO to disable it.
Step 3 - Activate the configuration.
cli> config runconfig
Step 4 - Save the configuration.
cli> config savetoflash
Step 5 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
BLACK BOX® CS Command Reference Guide
33
2.3 Menu Shell
This application allows you to customize the menu presented to users when they connect to the CS from a dumb terminal. The menu can be set up to allow users to connect to different servers; thereby, making it quick and easy for users to connect to the those servers on the LAN.
How to use
Once the appropriate configurations are done the user will connect to the CS using a serial terminal. The user will then automatically receive a menu similar to that shown below:
Welcome!
1) Sun server
2) Dell server
3) Linux server
4) Quit
Option ==>
The user selects the option required to connect to the desired server or to exit the system.
How to configure
Basically the configuration for this feature is divided in two parts that are going to be described in this section.
Firstly it is necessary to assign which users are going to use the Menu Shell by using the proper options provided by the menush_cfg utility. The second part is
34
Setting up the Menu Shell
Step 1 - Type "menush_cfg" and use the options shown below to define the menu title and menu commands.
-------------------------------------------------
MenuShell Configuration Utility
-------------------------------------------------
Please choose from one of the following options:
1. Define Menu Title
2. Add Menu Option
3. Delete Menu Option
4. List Current Menu Settings
5. Save Configuration to Flash
6. Quit
Option ==>
Step 2 - Choose the second option (Add Menu Option) and complete the requested fields.
The first question will be:
Enter the name for the new menu option:
Here just fill up with a description for the host that will be accessed.
The second question defines the action that must be taken:
Enter the command for the new menu option:
Action can be telnet host_ip or ssh -l username host_ip where host_ip is the IP address of the server to connect to.
Step 3 - Save the changes.
Save the changes made by choosing the fifth option:
5. Save Configuration to Flash
Assigning ports to the Menu Shell
To configure which ports will prompt the menu shell and if it will require authentication to gain access to it, follow the steps bellow:
Step 1 - If no authentication is required to gain access to the menu.
BLACK BOX® CS Command Reference Guide
35
Configure the following parameters in /etc/portslave/pslave.conf for the ports that will use this menu shell.
s<x>.protocol telnet conf.telnet /bin/menush s<x>.authtype none
Where <x> is the port number being configured.
Step 2 - If authentication is required to gain access to the menu
The users default shell must be modified to run the /bin/menush. So in
/etc/passwd the shell should be changed as follows. There should be something like: user:FrE6QU:505:505:Embedix User,,,:/home/user:/bin/menush
In pslave.conf the port where the serial terminal is attached must be configured for login with authentication local. Configure the following lines: s<x>.protocol login s<x>.authtype local
Where <x> is the port number being configured.
Step 3 - Activating and saving the changes made.
To activate the changes issue the command:
# runconf
To save the changes, run the command:
# saveconf
CLI Method - Terminal Profile Menu
To set up which servers the users can access, follow the steps below:
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Configuring the terminal menu.
In this step we will configure the menu that will be prompted to the user connecting from a dumb terminal.
Enter the terminal menu configuration: cli>config applications terminalmenu
36
Define the menu title, example: terminalmenu>menutitle "Available Servers"
Create the entries. The example below will add an entry named “Server1” opening a Telnet connection to 192.168.100.3: terminalmenu>add actionname Server1 command "telnet 192.168.100.3"
You can also open a SSH connection to the desired server, to do that substitute the “telnet host_ip” by “ssh -l username host_ip”.
Step 3 - Activate the configuration.
cli>config runconfig
Step 4 - Save the configuration.
cli> config savetoflash
Step 5 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
BLACK BOX® CS Command Reference Guide
37
2.4 Clustering using Ethernet Interface
Clustering is available for the CS with firmware versions 2.1.0 and up. It allows the stringing of Terminal Servers so that one Master CS can be used to access all CS‘s on a
LAN. The Master CS can manage up to 1024 serial ports, so that the following can be clustered:
An example with one Master and two Slave is shown in the following figure:
Figure 2.1 - An example using the Clustering feature
How to Configure Clustering
The Master CS must contain references to the Slave ports. The configuration described for Console Access Servers should be followed with the following exceptions for the
Master and Slaves.
VI mode
Step 1 - Edit the /etc/portslave/pslave.conf file and change the necessary parameters.
The related file for clustering configuration is /etc/portslave/pslave.conf, to edit this file, run the command:
# vi /etc/portslave/pslave.conf
38
Edit parameters according to the explanation provided in the following table.
:
Parameter Description
Examples/ Valid
Values
conf.eth_ip
conf.eth_ip_alias
conf.eth_mask_alias
all.socket_port
all.protocol
all.authtype
s33.tty
s33.alias
s33.ipno
Ethernet Interface IP address.
Secondary IP address for the Ethernet
Interface (needed for clustering feature).
Mask for secondary IP address above.
20.20.20.1
209.81.55.110
255.255.255.0
This value applies to both the local ports and ports on Slave CS.
7001+
Depends on the application.
Depends on the application.
socket_ssh, socket_server, or socket_server_ssh
Radius, local, none, remote, TacacsPlus,
Ldap, kerberos, local/Radius, radius/local, local/TacacsPlus,
TacacsPlus, local,
RadiusDownLocal,
LdapDownLocal,
NIS
This parameter must be created in the Master
CS file for every Slave port. Its format is:
IP_of_Slave:[slave_socket_port] for non-
Master ports. In this case, the slave_socket_port value is not necessary because s33.socket_port is automatically set to 7033 by all.socket_port above.
20.20.20.2:7033
An alias for this port. (This is an optional parameter).
server_on_slave1_ serial_s1
This parameter must be created in the Master
CS file for every Slave port, unless configured using all.ipno.
0.0.0.0
Table 2.2: Master configuration (where it differs from the CAS standard)
BLACK BOX® CS Command Reference Guide
39
Parameter Description
Examples/ Valid
Values
s34.tty
s34.alias
s34.ipno
s35.tty
s35.alias
See s33.tty.
An alias for this port.
See s33.ipno.
See s33.tty.
An alias for this port.
20.20.20.2:7034 server_on_slave1_ serial_s2
0.0.0.0
20.20.20.2:7035 server_on_slave1_ serial_s3
0.0.0.0
s35.ipno
etc. for s36-s64 s65.tty
S65.alias
S65.ipno
S66.tty
S66.alias
S66.ipno
S67.tty
S67.alias
See s33.ipno.
The format of this parameter is
IP_of_Slave:[slave_socket_port] for non-
Master ports. The value 7301 was chosen arbitrarily for this example.
An alias for this port.
See s33.ipno.
See s65.tty.
An alias for this port.
See s33.ipno.
See s65.tty.
An alias for this port.
20.20.20.3:7301 server_on_slave2_ serial_s1
0.0.0.0
20.20.20.3:7302 server_on_slave2_ serial_s2
0.0.0.0
20.20.20.3:7303 server_on_slave2_ serial_s3
0.0.0.0
S67.ipno
etc. for s68-s96
See s33.ipno.
Table 2.2: Master configuration (where it differs from the CAS standard)
Step 2 - To configure the first Slave unit, follow the table below.
40
The Slave CS’s do not need to know they are being accessed through the Master
CS. (You are creating virtual terminals: virtual serial ports.) Their port numbers, however, must agree with those assigned by the Master. To configure the Slave units, follow the table below:
Parameter Value for this example
all.protocol
all.authtype
conf.eth_ip
all.socket_port
socket_server none
20.20.20.2
7033+
Table 2.3: Slave 1 configuration (where it differs from the CAS standard)
Step 3 - Configure the CS second slave.
To configure the second slave, follow the parameters of the table below:
Parameter Value for this example
all.protocol
all.authtype
conf.eth_ip
all.socket_port
socket_server none
20.20.20.3
7301+
Table 2.4: Slave 2 configuration (where it differs from the CAS standard)
Step 4 - Activating and saving the changes made.
To activate the changes issue the command:
# runconf
To save the changes, run the command:
# saveconf
Step 5 - Accessing the ports.
To access ports from the remote management workstation, use Telnet with the secondary IP address.
To access the first port of the Master CS:
# telnet 209.81.55.110 7001
BLACK BOX® CS Command Reference Guide
41
To access the first port of the Slave1 CS:
# telnet 209.81.55.110 7033
To access the first port of the Slave2 CS:
# telnet 209.81.55.110 7301
SSH can also be used from the remote management workstation.
To access the third port of Slave 2:
# ssh -l <username>:Server_on_slave2_serial_s3 209.81.55.110
To access the fifth port of Slave 2:
# ssh -l <username>:7305 209.81.55.110
TIP:
It is possible to get the clustering channel tunneled via IPSec. For more information about IPSec, see
VPN Configuration
.
42
2.5 Clustering using NAT (Enhanced)
With Enhanced Clustering, the CAS ports in the slave box can be configured as SSH or
Telnet and can have any type of authentication available. Authentication is performed in the Slave and not in the Master anymore. Additionally, the Master no longer needs to be the default gateway for all Slave boxes.
Enhanced clustering is available on implementations running Linux 2.4.x versions or newer. This new implementation is based on “iptables/nat” which is only available in these higher versions of Linux. Enhanced Clustering has improved performance and security. Performance is greatly increased because only the NAT translation is performed on the Master box. The Master doesn't open an intermediary TCP connection with the Slave box. Also if SSH encryption and decryption is desired, it is performed on the Slave.
New Parameters and Commands
A new parameter, conf.nat_clustering_ip allows you to enable or disable the clustering via the NAT table. This parameter should be configured with the IP address used to access the serial ports. The NAT clustering will work regardless of the interface where this IP address is assigned to. Additionally, there are two chains (post_nat_cluster and pre_nat_cluster) that holds all rules to perform NAT for clustering.
Table 2.5: Abbreviation List
clustering_ip master_ip slave_ip master_port slave_port
IP address of any CS interface (Master box). It is a public IP address and is the one that must be used to connect with the Slave's serial ports.
Primary or secondary ethernet IP address of the Master box (usually a public IP address).
Primary or secondary ethernet IP address of the Slave box (usually a non public IP address).
Remote serial port parameter "socket_port" (configured in the Master box).
Local serial port parameter “socket_port” (configured in the Slave box).
The Master CS box will issue a series of iptables commands to populate the nat table with the necessary rules to perform NAT translation for remote ports. Two chains will be created:
•
post_nat_cluster (to change the source IP address)
•
pre_nat_cluster (to change the destination IP address)
BLACK BOX® CS Command Reference Guide
43
The CS administrator must enable clustering via NAT in pslave.conf (conf.nat_clustering_ip
<clustering_ip>).
# iptables -D PREROUTING -t nat -p tcp -j pre_nat_cluster
# iptables -D POSTROUTING -t nat -p tcp -j post_nat_cluster
# iptables -t nat -F post_nat_cluster
# iptables -t nat -F pre_nat_cluster
# iptables -t nat -X pre_nat_cluster
# iptables -t nat -X post_nat_cluster
# iptables -t nat -N pre_nat_cluster
# iptables -t nat -N post_nat_cluster
# iptables -A PREROUTING -t nat -p tcp -j pre_nat_cluster
# iptables -A POSTROUTING -t nat -p tcp -j post_nat_cluster
# iptables -A pre_nat_cluster -t nat -p tcp -d <master_ip> --dport
<master_port> -j DNAT --to <slave_ip>:<slave_port>
.....
# iptables -A post_nat_cluster -t nat -p tcp -d <slave_ip> --dport
<slave_port> -j SNAT --to <master_ip>
.....
At any time the CS administrator can issue an iptables command to view, change (at his own risk), or delete the rules in the nat table. If the administrator issues a “fwset restore” command he must also execute the command “runconf” to recover the nat table.
CS clustering was primarily designed to allow a large number of serial ports (in more than one box) to be accessed using just one single public IP address. It only works for ports configured with the CAS profile. With iptables you can extend the access to the clustering.
Examples:
3. Accessing a Slave box with the WebUI from anywhere:
# iptables -A PREROUTING -t nat -p tcp -d 192.168.47.79 --dport 8081 -j DNAT
--to 192.168.51.2:80
4. Accessing a public DNS from any Slave box:
# iptables -A PREROUTING -t nat -p udp -d 64.186.161.2 --dport 53 -j SNAT
--to 64.186.161.79:53
How it works
The Master box (CS) will perform two translation for each packet. The destination IP address is translated in the PREROUTING stage. The source IP address is translated in the POSTROUTING stage.
44
The command to start a Telnet client session has not changed. As before, it looks like this:
# telnet <clustering_ip> <master_port>
And it will have the same result as the command below issued from a local workstation:
# telnet <slave_ip> <slave_port>
The command to start a SSH client session must have the following command line option:
# -p <master_port>
The <master_port> will define at least the Slave box with which a connection is desired.
For example, you may use the following commands:
# ssh -l <username1>:<server1> -p 7101 <master_ip>
# ssh -l <username2>:<server2> -p 7101 <master_ip>
The above commands will respectively have the same result as the following commands issued from a local workstation:
# ssh -l <username1>:<server1> <slave1_ip>
# ssh -l <username2>:<server2> <slave1_ip>
If the parameter <master_port> defines the local IP address assigned to the serial port, the command can be simplified:
# ssh -l <username1> -p 7101 <master_ip>
# ssh -l <username2> -p 7102 <master_ip>
BLACK BOX® CS Command Reference Guide
45
And it will have respectively the same result as the commands below issued from a local workstation:
# ssh -l <username1> <slave1_port1_ip>
# ssh -l <username2> <slave2_port1_ip>
NOTE:
In the old clustering implementation <username?> and <server?> must be valid in the Master box. In the new clustering they must be valid in the Slave. In the Master box there is no meaning anymore for remote port's alias and authtype parameters. If you wish to access all clustering ports with the SSH command option -p port, you must assign an IP address to the serial port. Do not omit the parameter socket_port in the Master box.
General Configuration
The configuration of clustering ports is pretty much the same as before. There is only one new parameter in the Master box (conf.nat_clustering_ip) that enables or disables the clustering via NAT. The parameters usernames (if authentication is local) and alias for remote ports must be configured now in the related Slave box.
In the following configuration examples, looking like “s[1-32].tty ttyS[1-32]” must be seen as 32 lines. For example: s1.tty ttyS1 s2.tty ttyS2
...
s32.tty ttyS32
46
Master box Configuration
All mentioned instructions must be made in the /etc/portslave/pslave.conf file of the
Master box
#Master box Configuration
#Enable Clustering via NAT
# conf.nat_clustering_ip 64.186.161.108
#
#Primary ethernet IP address (must be the public IP).
# conf.eth_ip 64.186.161.108
conf.eth_mask 255.255.255.0
conf.eth_mtu 1500
#
# Secondary ethernet IP address
# conf.eth_ip_alias 192.168.170.1
conf.eth_mask_alias 255.255.255.0
#
# Local CAS serial ports (32 socket_ssh ports)
# all.protocol socket_ssh all.authtype local all.socket_port 7001+ s[1-32].tty ttyS[1-32]
#
#Remote CAS serial ports, slave-1 (32 socket_ssh ports). This kind of
#configuration can be used for ssh only; just one entry is necessary.
File Description 2.2: Master box: /etc/portslave/pslave.conf
BLACK BOX® CS Command Reference Guide
47
s33.tty 192.168.170.2
s33.socket_port 7000 s65.protocol socket_server s66.protocol socket_server
...
s96.protocol socket_server
#
# Remote CAS serial ports, slave-2 (32 socket_server ports)
# s65.tty 192.168.170.3:7101 s66.tty 192.168.170.3:7102
....
s96.tty 192.168.170.3:7132 s65.socket_port 8001 s66.socket_port 8002
...
s96.socket_port 8032
#
# Remote CAS serial ports, slave-3 (32 socket_ssh ports)
# s97.tty 192.168.170.101
s98.tty 192.168.170.102
s99.tty 192.168.170.103
...
File Description 2.2: Master box: /etc/portslave/pslave.conf
Slave-1 box Configuration
All mentioned instructions must be made in the /etc/portslave/pslave.conf file of the first
Slave box:
#Slave-1 box Configuration
#Primary ethernet IP address
# conf.eth_ip 192.168.170.2
conf.eth_mask 255.255.255.0
File Description 2.3: Slave1 box: /etc/portslave/pslave.conf
48
conf.eth_mtu 1500
#
# Local CAS serial ports (32 socket_ssh ports)
# all.protocol socket_ssh all.authtype local s[1-32].tty ttyS[1-32] s[1-32].alias slave-1-port[1-32]
File Description 2.3: Slave1 box: /etc/portslave/pslave.conf
Slave-2 box Configuration
All mentioned instructions must be made in the /etc/portslave/pslave.conf file of the second Slave box:
#Slave-2 box Configuration
#Primary ethernet IP address
# conf.eth_ip 192.168.170.3
conf.eth_mask 255.255.255.0
conf.eth_mtu 1500
#
# Local CAS serial ports (32 socket_server ports)
# all.protocol socket_server all.authtype local all.socket_port 7101+ s[1-32].tty ttyS[1-32]
File Description 2.4: Slave2 box: /etc/portslave/pslave.conf
Slave-3 box Configuration
All mentioned instructions must be made in the /etc/portslave/pslave.conf file of the third Slave box:
#Slave-3 box Configuration
# Primary ethernet IP address
#
File Description 2.5: Slave2 box: /etc/portslave/pslave.conf
BLACK BOX® CS Command Reference Guide
49
conf.eth_ip 192.168.170.4
conf.eth_mask 255.255.255.0
conf.eth_mtu 1500
#
# Local CAS serial ports (32 socket_ssh ports)
# all.protocol socket_ssh all.authtype local all.ipno 192.168.170.101+ s[1-32].tty ttyS[1-32]
File Description 2.5: Slave2 box: /etc/portslave/pslave.conf
Example of starting CAS session commands
The alias, socket_port, or tty must be provided to select which serial port is to be connected to in the Slave box 1.
# ssh -l <username>:<slave-1-port[1-32]> -p 7000 64.186.161.108
The master_port (socket_port in the Master) will select which serial port is to be connected to in the Slave boxes 1 and 2.
# telnet 64.186.161.108 80[01-32]
# ssh -l <username> -p [7097-7128] 64.186.161.108
CLI Method - Clustering
The clustering process is made using the ethernet interface, this means that no special connection is needed between the boxes. All you need is to connect them in the same physical network. To configure one CS as master to control other CS (slave), using the
CLI just follow the steps below:
Information for the approached example:
•
Master box - 4 port unit; 172.22.65.2 as IP address
•
Slave box - 32 port unit; 172.22.65.3 as IP address
•
Telnet protocol to access the serial ports.
Step 1 - Open the CLI interface by issuing the command:
# CLI
50
Step 2 - Add a slave box.
cli>config virtualports addslave 172.22.65.3
Step 3 - Configuring the slave box.
All parameters that have to be configured will be listed, commented and given the correct value for this example.
•
numports: This sets the total number of ports of the slave box. The value for this example is 32.
•
firstlocalportnum: This parameter will act as the numbering continuation in the slave box. As the master unit is a 4 port box, the first port of the slave unit will be the first local port number. The value for this example is 5.
•
localip: To set the IP address of the slave box. The value for the example is
172.22.65.3.
•
firstlocaltcpport: Such as the firstlocalportnum parameter, but setting the tcp port.
The value for the example is 7005.
•
remoteip: The IP address of the master box. The value for this example is:
172.22.65.2.
•
firstremotetcpport: Where tcp port numbering starts in the master box. The value for this example is: 7001.
•
protocol: Protocol used to access the ports. Valid values are: Telnet or SSH.
Step 4 - Activate the configuration.
cli>config runconfig
Step 5 - Save the configuration.
cli>config savetoflash
Step 6 - Testing the configuration and additional options.
Telnet to port 10 of the slave box. Supposing you are in the same network as the master CS, run the command:
# telnet 172.22.65.2 7014
You can also edit or delete any previously configured virtual port: cli>config virtualports editslave <n.n.n.n> cli>config virtualports deleteslave <n.n.n.n>
Where n.n.n.n is the IP address of the configured virtual port.
Step 7 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
BLACK BOX® CS Command Reference Guide
51
52
Chapter 3
Authentication
..........................................................................
Chapter 3 - Authentication
This chapter presents the procedures for assigning and configuring the authentication service(s) that the CS, system or any of its components and devices will be using.
Authentication is the process by which the system, or more specifically, an authentication service such as Kerberos, Ldap or Tacacs, verifies the identity of users (to verify who they claim to be) as well as to confirm receipt of communication to authorized recipients. This chapter includes the following topics:
•
•
•
•
HTTP Signed Digital Certificate
•
X.509 Certificate on SSH
3.1 Device Authentication
Authentication is the process of identifying an individual, usually based on a username and password. In security systems, authentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity.
Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. With the CS, authentication can be performed locally, or with a remote Radius, Tacacs, ldap database, or kerberos.
How to configure
Follow the steps below to configure an authentication type.
VI mode - Parameters involved and passed values
To configure the authenticaton type of the CS, follow the steps below:
Step 1 - Edit the /etc/portslave/pslave.conf file.
Edit the all.authtype parameter in the pslave.conf file to specify the type of authentication server being configured. The table below contains a brief description of each authentication type.
Parameter Description
all.authtype
Type of authentication used. There are several authentication type options:
•
None (no authentication)
This option is invalid when the serial port is configured for Power
Management. The system defaults to “Local” if no authentication type is selected.
•
Local (authentication is performed using the /etc/passwd file)
•
Remote (This is for a terminal profile only. The unit takes in a username but does not use it for authentication. Instead it passes it to the remote server where it is then used for authentication.)
•
Radius (authentication is performed using a Radius authentication server)
•
TacacsPlus (authentication is performed using a TacacsPlus authentication server)
Table 3.1: Authentication parameters in /etc/portslave/pslave.conf
54
Parameter
all.authtype
(cont.)
Description
•
Ldap (authentication is performed against an ldap database using an ldap server. The IP address and other details of the ldap server are defined in the file /etc/ldap.conf)
•
Kerberos (authentication is performed using a kerberos server. The IP address and other details of the kerberos server are defined in the file
/etc/krb5.conf)
•
Local/Radius (authentication is performed locally first, switching to
Radius if unsuccessful)
•
Radius/Local (the opposite of the previous option)
•
Local/TacacsPlus (authentication is performed locally first, switching to TacacsPlus if unsuccessful)
•
TacacsPlus/Local (the opposite of the previous option)
•
RadiusDownLocal (local authentication is tried only when the Radius server is down)
•
TacacsPlusDownLocal (local authentication is tried only when the
TacacsPlus server is down)
•
Kerberos/Local (Kerberos authentication is tried first, switching to
Local if unsuccessful)
•
KerberosDownLocal (local authentication is tried only when the kerberos server is down)
•
Ldap/Local (LDAP authentication is tried first, switching to local if unsuccessful)
•
LdapDownLocal (local authentication is tried only when the ldap server is down)
•
NIS - All authentication types but NIS follow the format all.authtype
<Authentication>DownLocal or <Authentication> (e.g. all.authtype radius or radiusDownLocal or ldap or ldapDownLocal, etc). NIS requires all.authtype to be set as local, regardless if it will be "nis" or its “Downlocal" equivalent. The service related to "nis" or its
“Downlocal" equivalent would be configured in the /etc/nsswitch.conf file, not in the /etc/portslave/pslave.conf file.
Note that this parameter controls the authentication required by the
Advanced Console Server. The authentication required by the device to which the user is connecting is controlled separately.
Table 3.1: Authentication parameters in /etc/portslave/pslave.conf
NOTE:
If you want to dial in to the serial port on an CS series with CHAP authentication, you need to do the following:
1. Configure Sxx.authtype as local.
2. Add users in Advanced Console Server.
BLACK BOX® CS Command Reference Guide
55
3. Insert the users in the file /etc/ppp/chap-secrets.
4. Insert the file /etc/ppp/chap-secrets in the file /etc/config_files.
5. Execute the saveconf command.
Step 2 - Configuring an authentication server.
The parameters for each type of authentication server is stored in its own configuration file on CS.
Authentication
Server
Radisu
TacacsPlus
Kerberos
LDAP
NIS
File Path
/etc/raddb/server
/etc/tacplus.conf
/etc/krb5.conf
/etc/ladp.conf
/etc/yp.conf
Table 3.2: Authentication Servers and File Path
Step 3 - Activating and saving the changes made.
To activate the changes issue the command:
# runconf
To save the changes, run the command:
# saveconf
56
CLI Method - Authentication
Follow the below procedures to:
•
Configure the authentication type for the CS serial ports.
•
Configure user access to the serial ports.
•
Configure the authentication type for accessing the console of a connected device.
•
Configure an authentication server.
To configure the authentication type for the serial ports.
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Navigate to the following path.
cli>config physicalports access authtype [value]
For physicalports specify a port number, select a range, or enter “all”. For example,
“physicalport 4”, “physicalports 1-8”, or “physicalports all”.
Step 3 - To see the list of authentication types, from >authtypes
<Press tab to see list of possible values>
Authentication type “None” is not a valid option when the serial port is configured for Power
Management connection protocol. The system defaults to “Local” if no authentication type is selected.
To configure user access to the serial ports
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Navigate to the following path.
cli>config security
This menu lets you execute the following actions:
BLACK BOX® CS Command Reference Guide
57
•
adduser - To add an user you need to pass the following parameters: user name
<username>; administrator privileges or not <admin - yes|no>; biouser or not
<biouser - yes|no>; password <password>; comments <comments>. Example: security>adduser username john admin no biouser no password john1234
•
addgroup - To add a group it is necessary to inform the group name <groupname> and the members <usernames> of this group. Example: security>addgroup groupname test usernames john,mary
•
delgroup - To delete a group it is necessary to inform the name of the group
<groupname> you want to delete. Example: security>delgroup groupname test
•
deluser - To delete an existing user, it is necessary to inform the user you want to delete by specifying the <username> parameter. Example: security>deluser username blackbox
•
loadkey - This options allows you to get the user’s public key via scp. The user must be enrolled in the local database of the unit. You must specify the user name
<username> and the url <url>. The url must follow this syntax:
user@host:pathname. Example: security>loadkey username root url [email protected]/home/key
•
passwd - Change the password of a user. You need to inform the user <username> and the new password <newpassword> of the user. Example: security>passwd username root newpassword diffucultpasswd1234
To configure authentication type for device console access.
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Navigate to the following path.
cli>config security authentication authtype <string>
Step 3 - To see the list of authentication types, from >authtype
<Press tab to see list of possible values>
The following list of authentication types appears.
Nis, kerberos, local/Nis, Nis/local, kerberos/local, local/TacacsPlus, NisDownLocal, kerberosDownLocal, local/radius, RadiusDownLocal, ldap, none, TacacsPlus,
58
ldap/local, radius,TacacsPlus/local, ldapDownLocal,
radius/local, TacacsPlusDownlocal, and local. For more information about this please see the all.authtype parameter
Table 3.1, “Authentication parameters in
/etc/portslave/pslave.conf,” on page 54
To configure an authentication server.
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Navigate to the following path.
cli>config security authentication
Step 3 - To see the list of authentication server types, from
>authentication, press the tab to see the list of possible values. The following list of authentication types appears.
nisserver,radiussecret,tacplusauthsvr1,radiustimeout tacplusauthsvr2, krbdomain, radiusacctsvr1, tacplusraccess, krbserver,radiusacctsvr2, secureldap, tacplusretries, ldapbasedomain, radiusauthsvr1, tacplussecret, ldapserver, radiusauthsvr2,tacplusacctsvr1, tacplustimeout, nisdomain, radiusretries,tacplusacctsvr2
Step 4 - Configure an authentication server.
#config security authentication <server option> <ip address>
To activating the configuration.
cli> config runconfig
To save the configuration.
cli> config savetoflash
To exit the CLI mode.
cli> quit
BLACK BOX® CS Command Reference Guide
59
Access Control via Radius Attribute NAS-Port-id
This feature provides an additional way to control the access to serial ports other than the one based in usernames or groups. The authentication type must be Radius for this feature to function. The Radius server administrator must configure the user (in the radius server database) with one NAS-PORT-id attribute for each serial port that the user is allowed to access.
In the example below the user alfred can access the serial ports ttyS11, ttyS13, and ttyS17: alfred Auth-Type = Local, Password = ‘alfred’
Service-Type = Framed-User,
Framed-Protocol = PPP,
NAS-Port-Id = 11,
NAS-Port-Id = 13,
NAS-Port-Id = 17
The pam_radius module will check whether the NAS-Port-Id matches one of those sent by the radius server. If the radius server does not send the NAS-Port-Id attribute, no check is performed.
No configuration is needed for the CS. However, the authentication type must be
“radius”. Authentications like radiusDownLocal, radius/local, etc. will not validate the
NAS-port-Id if the user was locally authenticated.
NIS Client
NIS (Network Information System) provides simple and generic client-server database access facilities that can be used to distribute information. This makes the network appear as a single system, with the same accounts on all hosts. The objective of this feature is to allow the administrator to manage CS accounts on a NIS server.
The NIS client feature needs these following files/commands:
File/Command
/etc/yp.conf
/etc/domainname.conf
Description
This file contains the configuration used by ypbind.
This file contains the NIS domain name (set by the command domainname).
Table 3.3: NIS client requirements
60
File/Command
/usr/sbin/ypbind
/usr/bin/ypwhich
/usr/bin/ypcat
/usr/bin/ypmatch
/usr/sbin/domainname
Description
Finds the server for NIS domains and maintains the NIS binding information.
Returns the name of the NIS server that supplies the NIS services.
Prints the values of all keys from the NIS database specified by map name.
Prints the values of one or more keys from the NIS database specified by map name.
Shell script to read/write the NIS domain name.
Table 3.3: NIS client requirements
NIS Client Configuration
Step 1 - Run the command domainname.
You’ll want to make sure that you have the NIS domain name set.
Command:
# domainname [NIS domain name] show or set the system's NIS/YP domain name, e.g.:
# domainname blackbox mycompany-nis
Step 2 - Edit the /etc/yp.conf file.
You will need to configure the NIS server. Example: If the NIS server has the IP address 192.168.160.110, you’ll have to add the following line in the file: ypserver 192.168.160.110
Step 3 - Edit the /etc/nsswitch.conf file.
Change the /etc/nsswitch.conf file ("System Databases and Name service Switch
"configuration file) to include the NIS in the lookup order of the databases.
Step 4 - Configure the parameter "<all/sxx>.authype" as "local".
How to Test the Configuration
To test the configuration do the following:
BLACK BOX® CS Command Reference Guide
61
Step 1 - Start up the following command:
# /usr/sbin/ypbind
Step 2 - Display the NIS server name.
Display the name of NIS server by running the following command:
# /usr/bin/ypwhich
Step 3 - Display the “all users” entry.
Displays the all users' entry in the NIS database by running the following command:
# /usr/bin/ypcat -t passwd.byname
Step 4 - Display the user's entry in the NIS passwd file.
# /usr/bin/ypmatch -t <userid/username> passwd.byname
If the preceding steps were performed successfully, you now need to change the
/etc/inittab file by uncommenting the line that performs a ypbind upon startup.
nsswitch.conf file format
The /etc/nsswitch.conf file has the following format:
<database> : <service> [ <actions> <service> ] where:
<database> - available: aliases, ethers, group, hosts, netgroup, network, passwd, protocols, publickey, rpc, services and shadow
<service> - available: nis (use NIS version 2), dns (use Domain Name Service) and files
(use the local files)
<actions> - Has this format: [ <status> = <action> ] where:
<status> = SUCCESS, NOTFOUND, UNAVAIL or TRYAGAIN
<action> = return or continue
•
SUCCESS - No error occurred and the desired entry is returned. The default action for this status is 'return'
•
NOTFOUND - The lookup process works fine, but the needed value was not found. The default action for this status is “continue.”
62
•
UNAVAIL - The service is permanently unavailable.
•
TRYAGAIN - The service is temporarily unavailable.
To use NIS only to authenticate users, you need to change the lines in /etc/nsswitch.conf that reference passwd, shadow, and group.
Examples
4. You wish to authenticate the user first in the local database. If the user is not found, then use NIS: passwd: files nis shadow: files nis group: files nis
5. You wish to authenticate the user first using NIS. If the user is not found, then use the local database: passwd: nis files shadow: nis files group: nis files
6. You wish to authenticate the user first using NIS. If the user was not found or the
NIS server is down, then use the local database: passwd: nis [UNAVAIL=continue TRYAGAIN=continue] files shadow: nis [UNAVAIL=continue TRYAGAIN=continue] files group: nis [UNAVAIL=continue TRYAGAIN=continue] files
BLACK BOX® CS Command Reference Guide
63
3.2 Kerberos Authentication
Kerberos is a computer network authentication protocol designed for use on insecure networks, based on the key distribution model. It allows individuals communicating over a network to prove their identity to each other while also preventing eavesdropping or replay attacks, and provides for detection of modification and the prevention of unauthorized reading
Kerberos Server Authentication with Tickets support
The CS has support to interact on a kerberized network. You can find in the next lines a brief explanation about how kerberos works. Later in this section, a practical a step by step example will be presented.
How Kerberos Works
On a kerberized network, the Kerberos database contains principals and their keys (for users, their keys are derived from their passwords). The Kerberos database also contains keys for all of the network services.
When a user on a kerberized network logs in to their workstation, their principal is sent to the Key Distribution Center (KDC) as a request for a Ticket Granting Ticket (TGT).
This request can be sent by the login program (so that it is transparent to the user) or can be sent by the kinit program after the user logs in.
The KDC checks for the principal in its database. If the principal is found, the KDC creates a TGT, encrypts it using the user's key, and sends it back to the user.
The login program or kinit decrypts the TGT using the user's key (which it computes from the user's password). The TGT, which is set to expire after a certain period of time, is stored in your credentials cache. An expiration time is set so that a compromised TGT can only be used for a certain period of time, usually eight hours (unlike a compromised password, which could be used until changed). The user will not have to re-enter their password until the TGT expires or they logout and login again.
When the user needs access to a network service, the client uses the TGT to request a ticket for the service from the Ticket Granting Service (TGS), which runs on the KDC.
The TGS issues a ticket for the desired service, which is used to authenticate the user.
Configuring CS to use Kerberos Tickets authentication
For this example we will consider that a kerberos server with ticket support is properly configured in the network. The manual will only approach the CS configuration.
Here we will assume that the kerberos server has the following configuration:
64
•
Principal: john
•
Host (Black Box CS): cs48-2.blackbox.com
CS Configuration
Configuring it for SSH:
Step 1 - Configure and start a NTP server
All involved parts must be synchronized with a NTP server. To configure a NTP server see
“NTP (Network Time Protocol)” on page 197
.
Step 2 - Configure authentication and protocol in the /etc/portslave/pslave.conf file. Open the file and edit these parameters:
all.authtype local all.protocol socket_ssh.
Step 3 - Activate and save the configuration, by issuing the commands:
# runconf
# saveconf
Step 4 - Add an user with the same name as the “principal”, configured in the
Kerberos server.
# adduser john
Step 5 - Configure the krb5.conf file. The /etc/krb5.conf file must be exactly the same as the one that is in the Kerberos server.
It is highly recommended to copy it directly from the server, instead of editing it.
To copy using scp, issue the command:
# scp [email protected]:/etc/krb5.conf /etc/krb5.conf
Step 6 - Extract the host that is in the Kerberos server database to the CS:
# kadmin -p admin/admin
Where the first “admin” is the service and the second one is the user.
This will prompt a Kerberos server menu. To extract the configured hosts run the following commands in the kadmin menu: kadmin: ktadd host/cs48-2.blackbox.com
kadmin: q
To list all configured hosts in the Kerberos server, run the command:
BLACK BOX® CS Command Reference Guide
65
# klist -k
The above command will show all hosts added through the ktadd command in the
Kerberos server.
Step 7 - Configure hostname and domain name.
To configure the hostname and the domain name, issue the commands:
# hostname cs48-2
# domainname blackbox.com
Rlogin and Telnet:
To access the CS through rlogin or Telnet, follow the steps described above plus the ones describe below.
Step 1 - Configure the /etc/inetd.conf file by uncommenting the lines:
#KERBEROS SERVICES klogin stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/klogind -ki telnet stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/telnetd
Step 2 - Restart the inetd service, by issuing the command:
# daemon.sh restart NET
Step 3 - Save the configuration.
# saveconf
Test the configuration:
All the steps below will be performed in the client side:
Step 1 - The client must have a kerberized SSH and configure the
/etc/ssh/ssh_config file, according to the example below:
GSSAPIAuthentication yes
GSSAPICleanupCreds yes
Step 2 - The client must have the same krb5.conf file present in the Kerberos server.
# scp [email protected]:/etc/krb5.conf /etc/krb5.conf
66
Step 3 - Requesting the ticket to the Kerberos server.
# kinit -f -p john
Password for [email protected]: ******
You will be prompted to insert a password, that is the “principal” password that is in the Kerberos server database.
Step 4 - Checking if the ticket was successful received:
# klist
Step 5 - Connect, from the client, to the CS via SSH:
Opening a SSH connection to the CS itself:
#ssh [email protected]
Opening a SSH session to one of the CS ports:
# ssh john:[email protected]
Step 6 - Connecting via RLOGIN to the CS itself, with forwardable tickets (to connect to the CS ports using ts_menu):
# rlogin -l john cs48-2.blackbox.com -F
Then run ts_menu to access the desired serial port.
Step 7 - Connecting via Telnet to the CS itself with forwardable tickets (to connect to the CS ports using ts_menu):
telnet -l john cs48-2.blackbox.com -F
Then run ts_menu to access the desired serial port.
Kerberos Server Authentication
To authenticate users on a Kerberos sever, it is necessary to edit two configuration files: pslave.conf and krb5.conf. Below is a step by step example:
Step 1 - Edit the /etc/portslave/pslave.conf file.
Open the /etc/portslave/pslave.conf file running the following command:
# vi /etc/portslave/pslave.conf
Look for the all.authtype and all.protocol parameters and change their values according to the example below:
BLACK BOX® CS Command Reference Guide
67
all.authtype kerberos all.protocol socket_ssh ##or socket_server or socket_server_ssh
To use the Telnet protocol to access the serial ports of the unit, set the all.protocol parameter to socket_server.
To use both Telnet and SSH to access the unit, set the all.protocol parameter to socket_server_ssh. In this example we are using the SSH protocol.
Step 2 - Edit the /etc/krb5.conf file.
Open the /etc/krb5.conf running the following command:
# vi /etc/krb5.conf
Basically, all the changes needed in this file are related to the network domain.
Substitute all listed parameters that are configured with “blackbox.com” with the correspondent domain of your network. Below is an example of the file:
[logging] default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults] ticket_lifetime = 24000 default_realm = BLACBOX.COM
default_tgs_enctypes = des-cbc-crc default_tkt_enctypes = des-cbc-crc
[realms]
BLACKBOX.COM = { kdc = kerberos.blackbox.com:88 admin_server = kerberos.blackbox.com:749 default_domain = blackbox.com
}
[domain_realm]
.blackbox.com = BLACKBOX.COM
blackbox.com = BLACKBOX.COM
File Description 3.1: /etc/krb5.conf
68
[kdc] profile = /var/kerberos/krb5kdc/kdc.conf
[pam] debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false
File Description 3.1: /etc/krb5.conf
Step 3 - Activating changes.
To activate the changes made, run the command:
# runconf
Step 4 - Testing configuration
To test the configuration, it is necessary to access any serial port using the Telnet protocol (this is the case of the approached e.g.). From a remote machine issue the following command:
# telnet 192.168.0.1 7001
# w
A prompt will ask for an user and password. Log with the user and password previously configured in the Kerberos server.
In the CS run the command:
The response for this command will be something like this:
1:03pm up 57 min, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root ttyS0 12:07pm 0.00s 1.47s 0.15s /bin/sh /usr/bin
CAS users : 1
USER TTY FROM LOGIN@ PID/Command blackbox ttyS1 192.168.0.143:1503 01:02pm 512/-RW_srv ttyS
The last line of the command response shows the user “blackbox” accessing the first serial port of the CS unit.
BLACK BOX® CS Command Reference Guide
69
Step 5 - Saving changes.
To save the configuration, run the command:
# saveconf
70
3.3 LDAP Authentication
Here we are going to describe the basic steps to configure a LDAP server on linux. We will also give instructions about how to configure the CS box.
Configuring an LDAP server on Linux
The steps below are intended to guide the installation of a LDAP server on a generic
Linux machine.
Step 1 - The packages required for the LDAP servers are:
•
db (Sleepycat Berkeley Database)
•
openssl (OpenSSL)
•
openldap (OpenLDAP)
It's also possible to load the source codes and compile them, but it is easier to load these packages from your distribution CD-ROM or via Internet.
Step 2 - Go to the directory /etc/openldap or /usr/local/etc/openldap.
Change the directory running the following command:
# cd /usr/local/etc/openldap
NOTE:
The example uses /usr/local path. Change all references of /usr/local if the path is different, and check if the directory/file really exists.
Step 3 - Create the certificates:
To create the certificates, run the following commands in the given sequence:
# ln -s /usr/local/bin/openssl.
# ln -s /usr/local/ssl/misc/CA.pl.
# PATH=$PATH:.
# CA.pl -newca <-- answer questions, you MUST fill in "commonName"
# CA.pl -newreq <-- repeat
# CA.pl -signreq
# mv newreq.pem ldapkey.pem
# chmod 0600 ldapkey.pem
# mv newcert.pem ldapcert.pem
Step 4 - Edit slapd.conf. The basic configuration to make it work is:
BLACK BOX® CS Command Reference Guide
71
The basic configuration of the file is like described below: include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
pidfile /usr/local/var/slapd.pid
argsfile /usr/local/var/slapd.args
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCertificateFile /usr/local/etc/openldap/ldapcert.pem
TLSCertificateKeyFile /usr/local/etc/openldap/ldapkey.pem
TLSCACertificateFile /usr/local/etc/openldap/demode/cacert.pem
database bdb suffix "dc=blackbox,dc=com,dc=br" rootdn "cn=admin,dc=blackbox,dc=com,dc=br" rootpw bitadmin directory /usr/local/var/openldap-data index objectClass eq
File Description 3.2: slapd.conf configuration
Step 5 - Start LDAP server.
To start the server run the command:
# /usr/local/libexec/slapd -h "ldap:/// ldaps:///"
This will allow the LDAP server accept both secured mode and non-secure mode.
Step 6 - Add entries.
Example: ldapadd -x -D "cn=admin,dc=blackbox,dc=com,dc=br" -w bitadmin dn: uid=helio,dc=blackbox,dc=com,dc=br objectClass: person objectClass: uidobject uid: helio cn: Helio Fujimoto sn: Fujimoto userPassword: bithelio
To list the entries:
72
ldapsearch -x -D "cn=admin,dc=blackbox,dc=com,dc=br" -w bitadmin
'(objectClass=*)'
This is enough to set up a LDAP server with some users, for PAM authentication purposes.
Configuring the CS side
To configure the unit for PAM authentication, follow the steps below:
Step 1 - Configure all.protocol as ldap, in /etc/portslave/pslave.conf
Step 2 - Configure the /etc/ldap.conf file.
Edit the following parameters: host 200.246.93.95 <== LDAP server IP address or name base dc=blackbox,dc=com,dc=br <== distinguished name of the search base uri ldaps://200.246.93.95 <== to use secure LDAP
File Description 3.3: /etc/ldap.conf configuration
Step 3 - Activating and saving the changes made.
To activate the changes issue the command:
# runconf
To save the changes, run the command:
# saveconf
Active Directory
A Windows 2000 or Windows 2003 Server edition is necessary. In the CS side, the
/etc/ldap.conf must be configured.
BLACK BOX® CS Command Reference Guide
73
What needs to be set in the /etc/ldap.conf
Follow the example below to set correctly the necessary parameters:
# The Windows 2003 server IP address host 200.246.93.118
# The Distinguished name (In our active directory, the format was set
# to blackboxcorporation.local) base dc=blackboxCorporation,dc=local
# Here you can insert any user you had created, or the administrator
# user.
binddn cn=Administrator,cn=Users,dc=blackbox,dc=local
# Password for that user bindpw test123
# PAM login attribute pam_login_attribute sAMAccountName
# Update Active Directory password, by creating Unicode password and
# updating unicodePwd attribute.
pam_password ad
File Description 3.4: /etc/ldap.conf
Enabling TACACS+ Authorization for Serial Ports
Using an authorization method in addition to authentication provides an extra level of system security. By enabling the raccess parameter, administrators require an additional level of security checking. After each user is successfully authenticated through the standard login procedure, the CS uses TACACS+ to authorize whether or not each user is allowed to access specific serial ports.
By default the raccess parameter is not enabled allowing all users full authorization.
When the raccess parameter is enabled, users are denied access unless they have the proper authorization, which must be set on the TACACS+ server itself.
Configuring Authorization with a TACACS+ Server [CLI]
Step 1 - In CLI mode, enter the following string:
config > security > authentication> tacplusraccess yes
Step 2 - To save the configuration, enter the command:
74
config > savetoflash
Configuring Authorization with a TACACS+ Server [vi]
Step 1 - Open /etc/tacplus.conf
Step 2 - Edit the service parameter to be raccess:
service=raccess
Setting User Authorization Permissions on the TACACS+ Server [vi]
The authorization for each user is defined on the TACACS+ server itself in the file
/etc/tacacs/tac_plus.cfg on the "Linux Fedora Core 3"
The location of this configuration file may be different on other Linux distributions.
Step 1 - On the TACACS+ server, open the file
/etc/tacacs/tac_plus.cfg
.
Step 2 - Edit the following lines:
The text in bold type face is included as an example. user = tomj{
name = "Tom Jones"
service = raccess {
port1 = LAB2/ttyS2
port2 = 192.168.0.1/ttyS1
port3 = CAS/ttyS1
port4 = 172.32.20.10/ttyS6
port5 = LAB1/ttyS7
port6 = Knuth/ttyS16
}
}
Table 3-4: Parameters for Specifying User Authorization on a TACACS+ Server
Parameter Description Example Value user =
<username>
Defines the username as specified on the CS.
tomj
BLACK BOX® CS Command Reference Guide
75
Table 3-4: Parameters for Specifying User Authorization on a TACACS+ Server
Parameter Description Example Value name =
<"optional description">
Optional to specify additional information about user.
This parameter must include quotes.
The maximum number of characters allowed is 256.
Adding more than 256 characters stops the server from restarting and produces a "FAILED" message at the time of authorization.
"Tom Jones" raccess
service =
<authorization method>
Specifies the authorization method used whether the user is allowed or denied access when the raccess parameter is set on the CS.
Only users who have this parameter set to raccess will have authorization to access the specified ports?
port<#> =
<
CS
>/<Port>
Specify which serial ports on the CS the user has authorization to access. port# is a sequential label used by the CS.
< CS> is the name or IP address of the CS box.
<Port> is the serial port the user can access on the specified CS box.
port1 = LAB2/ttyS2
76
3.4 Group Authorization
This feature enables the “group” information retrieval from the authentication servers
TACACS+, RADIUS, and LDAP, and adds another layer of security by adding a network-based authorization. It retrieves the “group” information from the authentication server and performs an authorization through CS.
The following sections describe the procedures to configure TACACS+, RADIUS, and
LDAP authentication servers, and the corresponding configuration process on CS.
Configuring a TACACS+ authentication server
On the server, add “raccess” service to the user configuration and define which group or groups the user belongs to.
user = <username>{ service = raccess{ group_name = <Group1>[,<Group2,...,GroupN>];
}
}
On the CS, edit the following parameters in the /etc/tacplus.conf file.
authhost1=192.168.160.21 accthost1=192.168.160.21 secret=secret encrypt=1 service=ppp protocol=lcp timeout=10 retries=2
authhost1: This address indicates the location of the TacacsPlus authentication server. A second
TacacsPlus authentication server can be configured with the parameter authhost2.
accthost1: This address indicates the location of the TacacsPlus accounting server, which can be used to track how long users are connected after being authorized by the authentication server. Its use is optional. If this parameter is not used, accounting will not be performed. If the same server is used for authentication and accounting, both parameters must be filled with the same address. A second TacacsPlus accounting server can be configured with the parameter accthost2.
secret: This is the shared secret (password) necessary for communication between the CS and the
TacacsPlus servers.
encrypt: The default is 1 which means encryption is enabled. To disable encryption change the value to 0.
BLACK BOX® CS Command Reference Guide
77
service: The service that should be enabled. The default is ppp. If you are enabling another service, for example, “raccess” authorization on the TacacsPlus server, then it should be mentioned in this field on CS.
protocol: The default is lcp (line control protocol). Specify another paramter if required.
timeout: This is the timeout (in seconds) for a TacacsPlus authentication query to be answered.
retries: Defines the number of times each TacacsPlus server is tried before another is contacted.
The first server authhost1 is tried for the specified number of times, before the second authhost2, if configured, is contacted and tried for the specified number of times. If the second server fails to respond TacacsPlus authentication fails.
Configuring the authorization on CS to access the serial ports [CLI]
In CLI mode, enter the following string:
1. cli > config security authentication tacplusraccess yes
2. cli > config physicalports <serial port number> access users/groups <list of users or group names separated by commas>
Save the configuration to flash
3. cli > config > savetoflash
Configuring a RADIUS authentication server
On the server, edit /etc/raddb/users and add a new string attribute (ATTRIBUTE
Framed-Filter-Id) similar to the following example?
groupuser1 Auth-Type= Local, Password =”xxxx”
Service-Type=Callback-Framed-User,
Callback-Number=”305”,
Framed-Protocol=PPP,
Fall-Through=No
If the Frame-Filter-Id already exists, just add the group_name to the string starting with a colon “:”
Framed-Filter-
Id=”:group_name=<Group1>[,<Group2>,...,<GroupN>]”,
On the CS, edit /etc/raddb/server format: server[:port] secret [retries] [timeout] for example,
78
auth1 172.20.0.2 blackbox 3 5 acct1 172.20.0.2 blackbox 3 5
Where,
server : The radius server address.
port: The port field is optional. The default port name is “radius” and is looked up through
/etc/services.
secret: The shared password required for communication between CS and the Radius server.
retries: The number of times each Radius server is tried before another is contacted
timeout: The default is 3 seconds. The timeout field determines how long the system should wait before responding with a success or failure response from the authentication server.
Multiple radius servers can be configured in this file. The servers are tried in the order in which they appear. If a server fails to respond, the next configured server is tried.
Configuring the authorization on CS to access the serial ports [CLI]
In CLI mode, enter the following string: cli > config physicalports <serial port number> access users/groups <list of users or group names separated by commas>
Save the configuration to flash
2. cli > config > savetoflash
Configuring an LDAP authentication server
On the server, edit the “info” attribute for the user and add the following syntax.
info: group_name=<Group1>[,<Group2>,...,<GroupN>];
Configuring the authorization on CS to access the serial ports [CLI]
In CLI mode, enter the following string: cli > config physicalports <serial port number> access users/groups <list of users or group names separated by commas>
Save the configuration to flash
BLACK BOX® CS Command Reference Guide
79
2. cli > config > savetoflash
80
3.5 Linux-PAM
Linux-PAM (Pluggable Authentication Modules for Linux) is a suite of shared libraries that enable the local system administrator to choose how applications authenticate users.
In other words, without (rewriting and) recompiling a PAM-aware application, it is possible to switch between the authentication mechanism(s) it uses. Indeed, one may entirely upgrade the local authentication system without touching the applications themselves.
It is the purpose of the Linux-PAM project to separate the development of privilegegranting software from the development of secure and appropriate authentication schemes. This is accomplished by providing a library of functions that an application may use to request that a user be authenticated. The PAM library has a series of configuration files located in /etc/pam.d/ to authenticate a user request via the locally available authentication modules. The modules themselves will usually be located in the directory /lib/security and take the form of dynamically loadable object files.
The Linux-PAM authentication mechanism gives the system administrator the freedom to stipulate which authentication scheme is to be used. S/he has the freedom to set the scheme for any/all PAM-aware applications on your Linux system. That is, s/he can authenticate from anything as generous as simple trust (pam_permit) to something as severe as a combination of a retinal scan, a voice print and a one-time password!
Linux-PAM deals with four separate types of (management) task. These are: authentication management, account management, session management, and password management. The association of the preferred management scheme with the behavior of an application is made with entries in the relevant Linux-PAM configuration file. The management functions are performed by modules specified in the configuration file.
Following is a figure that describes the overall organization of Linux-PAM:
BLACK BOX® CS Command Reference Guide
81
Figure 3.1 - Data flow diagram of Linux-PAM
The left of the figure represents the application: Application X. Such an application interfaces with the Linux-PAM library and knows none of the specifics of its configured authentication method. The Linux-PAM library (in the center) consults the contents of the PAM configuration file and loads the modules that are appropriate for Application
X. These modules fall into one of four management groups (lower center) and are stacked in the order they appear in the configuration file. These modules, when called by Linux-PAM, perform the various authentication tasks for the application. Textual information, required from or offered to the user can be exchanged through the use of the application-supplied conversation function.
The Linux-PAM Configuration Directory
Linux-PAM is designed to provide the system administrator with a great deal of flexibility in configuring the privilege-granting applications of their system. The local configuration of those aspects of system security controlled by Linux-PAM is contained in the directory /etc/pam.d/. In this section we discuss the correct syntax of and generic options respected by entries for the files in this directory.
82
Configuration File Syntax
The reader should note that the Linux-PAM-specific tokens are case-insensitive. The module paths, however, are case-sensitive since they indicate a file’s name and reflect the case-dependence of typical Linux file systems. The case-sensitivity of the arguments to any given module is defined for each module in turn.
In addition to the lines described below, there are two special characters provided for the convenience of the system administrator:
# Comments are preceded by this character and extend to the next end-of-line.
A general configuration line of a file in the /etc/pam.d/ directory has the following form: filename module-type control-flag module-path arguments
The meaning of each of these tokens is explained below. After the meaning of the above tokens is explained, the method will be described.
Token
File-name
Module-type
Description
The service name associated with the entry. For example, ‘ftpd’,
‘rlogind’, ‘su’, etc. There is a special service-name, reserved for defining a default authentication mechanism. It has the name ‘OTHER’ and may be specified in either lower or upper case characters. Note, when there is a module specified for a named service, the ‘OTHER’ entries are ignored.
One of (currently) the four types of module. The four types are as follows:
•
Auth - This module type provides two aspects of authenticating the user. First, it establishes that the user is who they claim to be, by instructing the application to prompt the user for a password or other means of identification. Second, the module can grant group membership, independently of the /etc/groups, or other privileges through its credential-granting properties.
Table 3.5: /etc/pam.d/ tokens description
BLACK BOX® CS Command Reference Guide
83
Token
Module-type (cont.)
Control-flag
Description
•
Account - This module performs non-authentication-based account management. It is typically used to restrict or permit access to a service based on the time of day, currently available system resources (maximum number of users) or perhaps the location of the applicant user—‘root’ login only on the console.
•
Session - Primarily, this module is associated with doing things that need to be done for the user before or after they can be given service. Such things include the logging of information concerning the opening or closing of some data exchange with a user, mounting directories, etc.
•
Password - This last module type is required for updating the authentication token associated with the user. Typically, there is one module for each ‘challenge/response’ based authentication
(auth) module-type.
The control-flag is used to indicate how the PAM library will react to the success or failure of the module it is associated with. Since modules can be stacked (modules of the same type execute in series, one after another), the control-flags determine the relative importance of each module. The application is not made aware of the individual success or failure of modules listed in the ‘/etc/pam.d/ directory. Instead, it receives a summary of success or fail responses from the Linux-PAM library.
The order of execution of these modules is that of the entries in the
/etc/pam.d/ directory: The control-flag can be defined with one of two syntaxes. The simpler (and historical) syntax for the control-flag is a single keyword defined to indicate the severity of concern associated with the success or failure of a specific module. There are four such keywords: required, requisite, sufficient and optional.
Table 3.5: /etc/pam.d/ tokens description
The Linux-PAM library interprets these keywords in the following manner:
Keyword
Required
Description
This indicates that the success of the module is required for the moduletype facility to succeed. Failure of this module will not be apparent to the user until all of the remaining modules (of the same module-type) have been executed.
Table 3.6: /etc/pam.d/ keywords description
84
Keyword
Requisite
Sufficient
Optional
Description
This is similar to required. However, in the case that such a module returns a failure, control is directly returned to the application. The return value is that associated with the first required or requisite module to fail. Note that this flag can be used to protect against the possibility of a user getting the opportunity to enter a password over an unsafe medium. It is conceivable that such behavior might inform an attacker of valid accounts on a system. This possibility should be weighed against the significant concerns of exposing a sensitive password in a hostile environment.
The success of this module is deemed ‘sufficient’ to satisfy the Linux-
PAM library that this moduletype has succeeded in its purpose. In the event that no previous required module has failed, no more ‘stacked’ modules of this type are invoked. (Note: in this case subsequent required modules are not invoked.) A failure of this module is not deemed as fatal to satisfying the application.
As its name suggests, this control-flag marks the module as not being critical to the success or failure of the user’s application for service. In general, Linux-PAM ignores such a module when determining if the module stack will succeed or fail. However, in the absence of any definite successes or failures of previous or subsequent stacked modules this module will determine the nature of the response to the application.
One example of this latter case is when the other modules return something like PAM_IGNORE.
Table 3.6: /etc/pam.d/ keywords description
Module Path
Module Path is the path-name of the dynamically loadable object file--the pluggable module itself. If the first character of the module path is ‘/’, it is assumed to be a complete path. If this is not the case, the given module path is appended to the default module path: /lib/security.
Currently, the CS has the following modules available:
Module Name
pam_access pam_deny
Description
Provides logdaemon style login access control.
Deny access to all users.
Table 3.7: Available PAM modules in the CS
BLACK BOX® CS Command Reference Guide
85
Module Name
pam_env pam_filter pam_group pam_issue pam_lastlog pam_limits pam_listfile pam_motd pam_nologin pam_permit pam_radius pam_rootok
Description
This module allows the (un)setting of environment variables. The use of previously set environment variables as well as PAM_ITEMs such as
PAM_RHOST is supported.
This module was written to offer a plug-in alternative to programs like ttysnoop. Since a filter that performs this function has not been written, it is currently only a toy. The single filter provided with the module simply transposes upper and lower case letters in the input and output streams. (This can be very annoying and is not kind to termcap-based editors.)
This module provides group settings based on the user’s name and the terminal they are requesting a given service from. It takes note of the time of day.
This module presents the issue file (/etc/issue by default) when prompting for a username.
This session module maintains the /var/log/lastlog file. It adds an open entry when called via the pam_open_session()function and completes it when pam_close_session() is called. This module can also display a line of information about the last login of the user. If an application already performs these tasks, it is not necessary to use this module.
This module, through the Linux-PAM open-session hook, sets limits on the system resources that can be obtained in a user session. Its actions are dictated more explicitly through the configuration file discussed in
/etc/security/pam_limits.conf.
The listfile module provides a way to deny or allow services based on an arbitrary file.
This module outputs the motd file (/etc/motd by default) upon successful login.
Provides standard Unix nologin authentication.
This module should be used with extreme caution. Its action is to always permit access. It does nothing else.
Provides Radius server authentication and accounting.
This module is for use in situations where the superuser wishes to gain access to a service without having to enter a password.
Table 3.7: Available PAM modules in the CS
86
Module Name
pam_securetty pam_time pam_tacplus pam_unix pam_warn pam_krb5 pam_ldap
Description
Provides standard UNIX securetty checking.
Running a well-regulated system occasionally involves restricting access to certain services in a selective manner. This module offers some time control for access to services offered by a system. Its actions are determined with a configuration file. This module can be configured to deny access to (individual) users based on their name, the time of day, the day of week, the service they are applying for and their terminal from which they are making their request.
Provides TacacsPlus Server authentication, authorization (account management), and accounting (session management).
This is the standard UNIX authentication module. It uses standard calls from the system’s libraries to retrieve and set account information as well as authentication. Usually this is obtained from the /etc/passwd and the /etc/shadow file as well when shadow is enabled.
This module is principally for logging information about a proposed authentication or application to update a password.
The Kerberos module currently used is pam_krb5. This PAM module requires the MIT 1.1+ release of Kerberos, or the Cygnus CNS distribution. It has not been tested against heimdal or any other Kerberos distributions. Important file: /etc/krb5.conf. The krb5.conf file contains
Kerberos configuration information, including the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm and for Kerberos applications, and mappings of hostnames onto Kerberos realms. Normally, you should install your krb5.conf file in the directory/etc. You can override the default location by setting the environment variable KRB5_CONFIG.
Pam_ldap looks for the ldap client configuration file “ldap.conf” in
/etc/. Here's an example of the ldap.conf file (partial):
# file name: ldap.conf
# This is the configuration file for the LDAP
# nameservice
# switch library and the LDAP PAM module.
# Your LDAP server. Must be resolvable without using
# LDAP.
host 127.0.0.1
# The distinguished name of the search base.
base dc=padl,dc=com
Table 3.7: Available PAM modules in the CS
BLACK BOX® CS Command Reference Guide
87
Arguments
The arguments are a list of tokens that are passed to the module when it is invoked. They are much like arguments to a typical Linux shell command. Generally, valid arguments are optional and are specific to any given module. Invalid arguments are ignored by a module, however, when encountering an invalid argument, the module is required to write an error to syslog(3).
The following are optional arguments which are likely to be understood by any module.
Arguments (including these) are in general, optional.
Arguments
debug no_warn use_first_pass try_first_pass use_mapped_ pass
Description
Use the syslog(3) call to log debugging information to the system log files.
Instruct module to not give warning messages to the application.
The module should not prompt the user for a password. Instead, it should obtain the previously typed password (from the preceding auth module), and use that. If that doesn’t work, then the user will not be authenticated. (This option is intended for auth and password modules only).
The module should attempt authentication with the previously typed password (from the preceding auth module). If that doesn’t work, then the user is prompted for a password. (This option is intended for auth modules only).
This argument is not currently supported by any of the modules in the
Linux-PAM distribution because of possible consequences associated with U.S. encryption exporting restrictions.
Table 3.8: List of valid arguments to PAM
88
Arguments
expose_account
Description
In general, the leakage of some information about user accounts is not a secure policy for modules to adopt. Sometimes information such as user names or home directories, or preferred shell, can be used to attack a user’s account. In some circumstances, however, this sort of information is not deemed a threat: displaying a user’s full name when asking them for a password in a secured environment could- also be called being
‘friendly’. The expose_account argument is a standard module argument to encourage a module to be less discrete about account information as deemed appropriate by the local administrator. Any line in (one of) the configuration file(s), that is not formatted correctly will generally tend (erring on the side of caution) to make the authentication process fail. A corresponding error is written to the system log files with a call to syslog(3).
Table 3.8: List of valid arguments to PAM
BLACK BOX® CS Command Reference Guide
89
3.6 Shadow Passwords
The default /etc/passwd file has the user “root” with password “bb”. You should change the password for user “root” as soon as possible.
The Advanced Console Server has support for Shadow Passwords, which enhances the security of the system authentication files.
For
CS
release 2.6, Shadow Passwords are enabled by default. If you are upgrading from release 2.3.0-2 (or earlier), a previous configuration is detected and the translation from
/etc/passwd to /etc/shadow happens automatically.
90
3.7 Certificate for HTTP Security
The following procedure enables you to obtain a Signed Digital Certificate. A certificate for the HTTP security is created by a CA (Certificate Authority). Certificates are most commonly obtained through generating public and private keys using a public key algorithm like RSA or X.509. The keys can be generated by using a key generator software.
Procedure
Step 1 - Enter OpenSSL command.
On a Linux computer, key generation can be done using the OpenSSL package, through the following command:
# openssl req -new -nodes -keyout private.key -out public.csr
If this command is used, the following information is required:
Parameter Description
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-
State]:
Locality Name (e.g., city) []:
The country code consisting of two letters.
Provide the full name (not the code) of the state.
Enter the name of your city.
Organization Name (e.g., company) [Internet
Widgits Ltd]:
Organization that you work for or want to obtain the certificate for.
Organizational Unit Name (e.g., section) []:
Common Name (e.g., your name or your server’s hostname) []:
Email Address []:
Department or section where you work.
Name of the machine where the certificate must be installed.
Your email address or the administrator’s email address.
Table 3.9: Required information for the OpenSSL package
The other requested information can be skipped.
The certificate signing request (CSR) generated by the command above contains some personal (or corporate) information and its public key.
Step 2 - Submit CSR to the CA.
BLACK BOX® CS Command Reference Guide
91
The next step is to submit the CSR and some personal data to the CA. This service can be requested by accessing the CA Web site and is not free. There is a list of
CAs at the following URL pki-page.org
The request will be analyzed by the CA, for policy approval and to be signed.
Step 3 - Upon receipt, install certificate.
After the approval, the CA will send a certificate file to the origin, which we will call Cert.cer, for example purposes. The certificate is also stored on a directory server.
The certificate must be installed in the GoAhead Web server, by following these instructions:
Step 3.1 - Open a Terminal Server session and do the login.
Step 3.2 - Join the certificate with the private key into the file
/web/server.pem.
#cat Cert.cer private.key > /web/server.pem
Step 3.3 - Copy the certificate to the file /web/cert.pem.
#cp Cert.cer /web/cert.pem
Step 3.4 - Include the files /web/server.pem and /web/cert.pem in
/etc/config_files.
Step 3.5 - Save the configuration in flash.
#saveconf
The certification will be effective in the next reboot.
92
3.8 X.509 Certificate on SSH
The OpenSSH software included with CS has support for X.509 certificates. The administrator must activate and configure the SSH to use X.509. In order to implement authentication of SSH sessions through exchange of X.509 certificates, the following configuration is required.
Step 1 - The certificates signed and issued by CA (Certification Authority) should be loaded on both user and the client. See the procedures in section 3.7 on how to obtain and install signed digital certificates.
Step 2 - Client Identification extracted by OpenSSL command from the client’s certificate, and added to the AuthorizedKeyFile in sshd_config file.
Step 2.1 - Use the following command to extract the client identification
#openssl x509 -noout -subject -in cli_cert.crt
Step 2.2 - Change “subject=” to “x509v3-sign-rsa disTinguishednameE:” in the result and append to AuthorizedKeysFile in “sshd_config” file in CS.
Step 3 - Upload hostkey to CS in /etc/ssh directory.
To configure X.509 certificate for SSH
vi Mode
Step 1 - Edit /etc/ssh/sshd_config file
Step 2 - Uncomment or modify the following lines to read as follows.
AllowedCertPurpose sslclient
CACertificateFile /etc/ssh/ca/ca-bundle.crt
HostKey /etc/ssh/hostkey
ChallengeResponseAuthentication no
HostbasedAuthentication no
StrictModes no
PasswordAuthentication no
PubkeyAuthentication yes
RhostsRSAAuthentication no
RSAAuthentication no
UsePrivilegeSeparation yes
BLACK BOX® CS Command Reference Guide
93
Step 3 - Restart SSH
CLI Mode
Step 1 - Enter the CLI mode
[root@CAS etc]# CLI
Step 2 - Enter the following string at the cli> prompt
cli>config network profile custom ssh_x509
At the ssh_x509> prompt, enter the following strings.
ssh_x509>CA_file <path and filename of CA certificate> ssh_x509>hostkey <path and filename of hostkeys> ssh_x509>authorizedkeys <path and filename of authorized keys>
For example: ssh_x509>CA_file /etc/ssh/ca-bundle.crt ssh_x509>hostkey /etc/ssh/hostkey ssh_x509>authorizedkeys /etc/ssh/authorized_keys
To check the configuration, enter the following command at the prompt.
ssh_x509>show
The following information should appear.
[ssh_x509]
CA_file: /etc/ssh/ca-bundle.crt
hostkey: /etc/ssh/hostkey authorizedkeys: /etc/ssh/authorized_keys
Script Mode
Step 1 - Run the following “ssh_act_x509” script
[root@CAS root]# ssh_act_x509
The following message appears:
94
For X509 authentication, first you need to be sure that you had upload the CA certificate, the HostKey and added the proper Authorized Key.
Step 2 - Enter the required information at each prompt.
AuthorizedKeysFile[/etc/ssh/authorized_keys]:
CACertificateFile[/etc/ssh/ca/ca-bundle.crt]:
HostKey[/etc/ssh/ssh_host_key]:
Do you want disable Password Authentication and accept only
Certificates?(y/n)
Step 3 - Check the configuration in /etc/ssh/sshd_config file.
To connect to CS using SSH X.509 certificate
Step 1 - Edit /etc/ssh/sshd_config file. See “To configure X.509 certificate for
Step 2 - Configure the client you need to access with X.509 certificate
Step 3 - Copy the certificate files to CS. See “Certificate for HTTP Security”, if
needed.
To check if the file was copied, run the following command at the prompt.
[root@cs48 root]# ls -l /etc/ssh/ca/ca-bundle.crt
[root@cs48 root]# ls -l /etc/ssh/hostkey
To connect to CS’s serial ports using SSH X.509 certificate
Step 1 - Edit /etc/ssh/sshd_config file. See “To configure X.509 certificate for
Step 2 - Configure the client you need to access with X.509 certificate
Step 3 - Copy the certificate files to CS. See “Certificate for HTTP Security”, if
needed.
To check if the file was copied, run the following command at the prompt.
[root@cs48 root]# ls -l /etc/ssh/ca/ca-bundle.crt
BLACK BOX® CS Command Reference Guide
95
[root@cs48 root]# ls -l /etc/ssh/hostkey
Step 4 - Configure the serial ports for “socket_ssh” protocol and assign the IP address of the connected device.
96
Chapter 4
Network
..........................................................................
Chapter 4 - Network
4.1 Introduction
This chapter will show important configuration settings regarding the network configuration or any feature related to it. The contents of this chapter is briefly presented below:
•
•
•
•
•
•
•
•
Filters and Network Address Translation
•
4.2 Basic Network Settings
This section will show how to configure basic network parameters. This includes configuration of ip addresses, netmasks and hostname.
Hostname
The most basic network related configuration is setting up a hostname. In the CS this can be done editing the /etc/hostname file.
VI mode
The related file to this configuration is the /etc/hostname. To change the hostname, edit it and set the desired hostname.
[root@CAS etc]# vi /etc/hostname
CAS
File Description 4.1: /etc/hostname
CLI Method - Hostname
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Set the hostname, where <string> is the desired hostname. cli> config network hostsettings hostname <string>
Step 3 - Activate the configuration.
cli> config runconfig
Step 4 - Save the configuration.
cli> config savetoflash
Step 5 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
IP address and Netmask
This section will show how to configure the IP address and network mask in the unit.
These settings can be made using both methods (VI and CLI).
VI mode
To set the IP address (if DHCP client is disabled) and the netmask it is necessary to edit the conf.eth_ip and conf.eth_mask parameters in the /etc/pslave/pslave.conf file.
The example below will set 192.168.160.10 as IP address and 255.255.255.0 as mask.
To do that follow the steps below:
Step 1 - Open the /etc/portslave/pslave.conf file.
To change these parameters it is necessary to edit the /etc/portslave/pslave.conf file:
# vi /etc/portslave/pslave.conf
Step 2 - Change parameters values.
98
With the /etc/portslave/pslave.conf file opened search for the parameters described below and change their values according to your necessities:
.
.
conf.eth_ip 192.168.100.1
conf.eth_mask 255.255.255.0
.
conf.dhcp_client 0
File Description 4.2: /etc/portslave/pslave.conf
NOTE:
To define a static IP address it is necessary to disable the DHCP client. Set to “zero” the value of the following line: conf.dhcp_client 0
Step 3 - Activate the changes.
Execute the following command to activate the changes:
# runconf
Step 4 - Test the configuration
Now you will want to make sure that the ports have been set up properly. Ping the CS from a remote machine. Using the Windows OS open a command prompt window, type in the following, and then press Enter:
# ping <IP assigned to the CS by DHCP or you>
An example would be:
# ping 192.168.160.10
If you receive a reply, your CS connection is OK. If there is no reply see
Appendix C - Cabling and Hardware Information
.
Step 5 - Telnet to the server connected to the first port of the CS. (This will only
work if you selected socket_server or socket_server_ssh as your all.protocol
parameter.)
While still in the DOS window, type the following and then press Enter:
# telnet <IP assigned to the CS by DHCP or you> 7001
An example would be:
# telnet 192.168.160.10 7001
BLACK BOX® CS Command Reference Guide
99
If everything is configured correctly, a Telnet session should open on the server connected to port 1. If not, check the configuration, follow the above steps again, and check Appendix C - Software Upgrade and Troubleshooting.
Step 6 - Save the changes.
Execute the following command to save the configuration:
# saveconf
CLI Method - IP address
It is also possible to configure the IP address and netmask using the CLI interface. This example will set 192.168.160.10 as IP address and 255.255.255.0 as mask. To configure it, follow the steps below:
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Configuring the unit’s IP address
cli> config network hostsettings primipaddress 192.168.160.10
Where 192.168.160.10 is the desired IP address.
Step 3 - Configuring unit’s network mask address.
cli> config network hostsettings primsubnetmask 255.255.255.0
Where 255.255.255.0 is the desired subnet mask.
Step 4 - Activate the configuration.
cli> config runconfig
Step 5 - Save the configuration.
cli> config savetoflash
Step 6 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
100
4.3 DHCP Client
DHCP is a protocol that allows network administrators to assign IP addresses automatically to network devices. Without DHCP (or a similar protocol like BOOTP), each device would have to be manually configured. DHCP automatically sends a new IP address to a connected device when it is moved to another location on the network.
DHCP uses the concept of a fixed time period during which the assigned IP address is valid for the device it was assigned for. This “lease” time can vary for each device. A short lease time can be used when there are more devices than available IP numbers. For more information, see RFC 2131.
VI mode
The DHCP client on the Ethernet Interface can be configured in two different ways, depending on the action the CS should take in case the DHCP Server does not answer the IP address request:
1. No action is taken and no IP address is assigned to the Ethernet Interface (most common configuration):
Step 1 - In the /etc/portslave/pslave.conf file set the global parameter
conf.dhcp_client to 1.
Step 2 - Still in the portslave.conf file comment all other parameters related to
the Ethernet Interface (conf.eth_ip, etc.).
Step 3 - Add the necessary options to the file /etc/network/dhcpcd_cmd (some
options are described later in this session).
2. The CS restores the last IP address previously provided in another boot and assigns this IP address to the Ethernet Interface. For the very first time the unit is powered
ON, the IP address restored is 192.168.160.10 in case of failure in the DHCP. The unit goes out from the factory with DHCP enabled (conf.dhcp_client 2):
Step 1 - Set the global parameter conf.dhcp_client to 2.
Step 2 - Comment all other parameters related to the Ethernet Interface
(conf.eth_ip, etc.).
BLACK BOX® CS Command Reference Guide
101
Step 3 - Add the following lines to the file /etc/config_files (from factory file
already present in /etc/config_files):
/etc/network/dhcpcd_cmd
/etc/dhcpcd-eth0.save
File Description 4.3: /etc/config_files
Step 4 - Add the option “-x” to the factory default content of the file
/etc/network/dhcpcd_cmd:
/sbin/dhcpcd -l 3600 -x -c /sbin/handle_dhcp
File Description 4.4: /etc/network/dhcpcd_cmd
NOTE:
From the factory, /etc/network/dhcpcd_cmd already has such content.
Step 5 - Add all other necessary options to the file /etc/network/dhcpcd_cmd
(some options are described later in this section).
In both cases if the IP address of the CS or the default gateway are changed, the
CS will adjust the routing table accordingly.
102
Files related to DHCP:
Command/File
/bin/handle_dhcp
/etc/network/dhcpcd_cmd
Description
The script which is run by the DHCP client each time an IP address negotiation takes place.
Contains a command that activates the DHCP client (used by the cy_ras program). Its factory contents are:
/bin/dhcpcd -c /bin/handle_dhcp
The options available that can be used on this command line are:
•
-D - This option forces dhcpcd to set the domain name of the host to the domain name parameter sent by the DHCP
Server. The default option is to NOT set the domain name of the host to the domain name parameter sent by the
DHCP Server.
•
-H - This option forces dhcpcd to set the host name of the host to the hostname parameter sent by the DHCP Server.
The default option is to NOT set the host name of the host to the hostname parameter sent by the DHCP Server.
•
-R - This option prevents dhcpcd from replacing the existing /etc/resolv.conf file.
Table 4.1: DHCP related files and commands
NOTE.
Do not modify the -c /bin/handle_dhcp option.
CLI Method - DHCP
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Activate/Deactivate DHCP in the unit.
cli> config network hostsettings dhcp <option>
Where possible values for <option> are: yes to activate DHCP or no to deactivate it.
Step 3 - Activate the configuration.
cli> config runconfig
BLACK BOX® CS Command Reference Guide
103
Step 4 - Save the configuration.
cli> config savetoflash
Step 5 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
104
4.4 Routes and Default Gateway
The CS has a static routing table that can be seen using the commands:
# route or
# netstat -rn
The file /etc/network/st_routes is the CS method for configuring static routes. Routes should be added to the file (which is a script run when the CS is initialized) or at the prompt (for temporary routes) using the following syntax: route [add|del] [-net|-host] target netmask nt_msk [gw gt_way] interf
Action/Option
[add|del]
[-net|-host] target netmask nt_msk gw gt_way interf
Description
One of these tags must be present. Routes can be either added or deleted.
Net is for routes to a network and -host is for routes to a single host.
Target is the IP address of the destination host or network.
The tag netmask and nt_mask are necessary only when subnetting is used, otherwise, a mask appropriate to the target is assumed. nt_msk must be specified in dot notation.
Specifies a gateway, when applicable. gt_way is the IP address or hostname of the gateway.
The interface to use for this route. Must be specified if a gateway is not.
When a gateway is specified, the operating system determines which interface is to be used.
Table 4.2: Actions and options for the route command
The next lines will show how to configure the default gateway of the CS .
VI mode
To add routes it is necessary to edit the /etc/network/st_routes file using the following syntax: route [add|del] [-net|-host] target [netmask] mask [gw] gateway [metric] metric
BLACK BOX® CS Command Reference Guide
105
The below example will set the default gateway to the IP address 192.168.0.1. To configure it follow these steps:
Step 1 - Open the /etc/network/st_routes file using the VI editor.
To do this, run the command:
# vi /etc/network/st_routes
Step 2 - Inserting the default route.
Insert into this file the default route using one of the following commands:
# route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.0.1
the same route can be added in the following way:
# route add default gw 192.168.0.1
To add a default route to the 192.168.0.1 IP address, just ONE of the above commands must be inserted into the file /etc/network/st_routes.
Step 3 - Save the changes made.
To save the changes run the following command:
# saveconf
CLI Method - Routes
Basically all configuration regarding the addition of static routes can be done accessing the following menu of the CLI interface: cli> config network stroutes
The example below will show how to add a default gateway in the unit:
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Inserting the default route. The default gateway of the below example will be 192.168.0.1
cli> config network stroutes add default gateway 192.168.0.1
Step 3 - Activate the configuration.
cli> config runconfig
106
Step 4 - Save the configuration.
cli> config savetoflash
Step 5 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
BLACK BOX® CS Command Reference Guide
107
4.5 DNS Server and Domain Name
DNS server is a host that resolves host names in the network. This is related to the domain name of the unit, both configurations are made in the same file, so they will be presented together in this section.
VI mode
To set the DNS server and the domain name of your network edit the /etc/resolv.conf file.
The below example will configure “blackbox.com” as domain and 192.168.0.2 as DNS.
To configure it follow the steps below:
Step 1 - Open the /etc/resolv.conf file.
It is necessary to edit this file, to do this, run the command:
# vi /etc/resolv.conf
Step 2 - Configure the /etc/resolv.conf file
The syntax of this file must be as the following example: domain blackbox.com
nameserver 192.168.0.2
#Domain name for the network
#DNS server for the network
File Description 4.5: /etc/resolv.conf
Step 3 - Save the configuration.
To save all changes made, run the command:
# saveconf
CLI Method - DNS and Domain Name
The example below will set up blackbox.com as domain name and 192.168.0.2 as DNS server of the CS .
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Configuring blackbox.com as domain name. cli> config network hostsettings domain blackbox.com
NOTE:
This parameter is disregarded when DHCP is enabled.
108
Step 3 - Configuring the primary DNS server IP address.
cli> config network hostsettings primdnsserver 192.168.0.2
NOTE:
This parameter is disregarded when DHCP is enabled.
Step 4 - Activate the configuration.
cli> config runconfig
Step 5 - Save the configuration.
cli> config savetoflash
Step 6 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
BLACK BOX® CS Command Reference Guide
109
4.6 Bonding
The CS provides failover Ethernet bonding using a PCMCIA card as a second Ethernet port. Bonding enables redundancy for the Ethernet devices, using the standard Ethernet interface as the primary mode of access and one PCMCIA card as a secondary mode of access.
When bonding is enabled, both the Ethernet port and the PCMCIA cards are configured with the same IP address and the same MAC address. So the PCMCIA interface automatically takes the place of the standard Ethernet interface if any conditions prevent access to the CS through the primary Ethernet port. When the standard interface regains functionality, it automatically assumes its role as the primary interface, and all connection sessions are kept up with no interruption.
VI mode
To set the failover Ethernet bonding, edit the /etc/bonding.opts file. To configure it follow the steps below:
Step 1 - Open the /etc/bonding.opts file.
It is necessary to edit this file, to do this, run the command:
# vi /etc/bonding.opts
Step 2 - Configure the /etc/bonding.opts file
The syntax of this file must be as the following example: enabled = < YES | NO > <--- make the bonding feature active if true and inactive otherwise miimon = <positive integer value> <--- this parameter is the interval, in milliseconds, in which the active interface will be checked to see if it is still communicating.
updelay = <positive integer value> <--- this parameter will define the time, in milliseconds, that the system will wait to make the primary interface active again after it has been detected as up.
File Description 4.6: /etc/bonding.opts
Step 3 - Save the configuration.
To save all changes made, run the command:
# saveconf
110
CLI Method - Bonding
The example below will set up blackbox.com as domain name and 192.168.0.2 as DNS server of the CS .
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Enter the bonding menu.
cli> config network hostsettings bonding
Step 3 - Enable failover bonding.
bonding> enabled yes
To disabled fail-over bonding, type the following command: bonding> enabled no
NOTE:
This parameter is disregarded when DHCP is enabled.
Step 4 - Configure the interval, in milliseconds, in which the active interface will be checked to see if it is still communicating.
bonding> miimon <positive integer value>
Step 5 - Configure the time, in milliseconds, that the system will wait to make the primary interface active again after it has been detected as up.
bonding> updelay <positive integer value>
Step 6 - Optionally, confirm values.
bonding> show
BLACK BOX® CS Command Reference Guide
111
A display similar to the following example appears: bonding>show
[bonding]
enabled: no
miimon: 100
updelay: 200
File Description 4.7: Bonding Default Configuration
Step 7 - Activate the configuration.
cli> config runconfig
Step 8 - Save the configuration.
cli> config savetoflash
The failover is enabled.
Step 9 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
Step 10 - Check the bonding configuration
To check if the feature is active, execute the ifconfig command in the Linux shell.
[root@CAS /]# ifconfig
112
[root@CAS /]# ifconfig bond0 Link encap:Ethernet HWaddr 00:60:2E:00:4F:97
inet addr:172.20.0.131 Bcast:172.20.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:484130 errors:0 dropped:0 overruns:0 frame:0
TX packets:234236 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:40453479 (38.5 MiB) TX bytes:25311651 (24.1 MiB) eth0 Link encap:Ethernet HWaddr 00:60:2E:00:4F:97
inet addr:172.20.0.131 Bcast:172.20.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:237695 errors:0 dropped:0 overruns:0 frame:0
TX packets:121503 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:19993021 (19.0 MiB) TX bytes:14356423 (13.6 MiB)
Base address:0xe00 eth1 Link encap:Ethernet HWaddr 00:60:2E:00:4F:97
inet addr:172.20.0.131 Bcast:172.20.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING NOARP SLAVE MULTICAST MTU:1500 Metric:1
RX packets:246435 errors:0 dropped:0 overruns:0 frame:0
TX packets:112733 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:20460458 (19.5 MiB) TX bytes:10955228 (10.4 MiB)
Interrupt:9 Base address:0x300 lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 iB) TX bytes:0 (0.0 iB)
[root@CAS /]#
After the failover is enabled, the bonded Ethernet interfaces are referred to as
“bond0”. eth0 and eth1 in the above example, represents the two physical interfaces. To check which physical interface is the primary and which is the failover, look for the status “NOARP”. The interface which has the “NOARP” status - eth1 in the above case - is the failover. eth0 is sending and receiving packets, eth1 is in active and standby mode.
BLACK BOX® CS Command Reference Guide
113
IMPORTANT:
If you have IP Filtering rules set before bonding is activated, the interface reference in the firewall IP filtering will be eth0. You need to change the interface to bond0 in order to reference the bonded interface.
For example, There is a rule to drop the SSH packets to access the CS box with no
Bonding:
[root@CAS /]# iptables -A INPUT -p tcp –dport 22 -i eth0 -j REJECT
If you activate Bonding you need to change the rule to reference the bonded interface:
[root@CAS /]# iptables -A INPUT -p tcp –dport 22 -i bond0 -j REJECT
For more information on setting up filters and structure of iptables, see “Filters and
Network Address Translation” on page 119
114
4.7 Hosts
This file should contain the IP address for the Ethernet interface and the same hostname that you entered in the /etc/hostname file. It may also contain IP addresses and host names for other hosts in the network. The file /etc/hosts is consulted before the DNS server and is used to convert a name into an IP address.
VI mode
To configure this file follow the steps below:
Step 1 - Open the /etc/hosts file.
To open the file, run the command:
# vi /etc/hosts
This file should also contain IP addresses and host names for other hosts in the network. The syntax of this file is the following:
127.0.0.1
localhost
192.168.160.10
CAS
192.168.160.2
dns-server
File Description 4.8: /etc/hosts
Enter as many hosts as necessary, following the above syntax.
Step 2 - Saving the configuration.
To save all the changes made, run the command:
# saveconf
CLI Method - Hosts
The example below will add a host named test with IP address 192.168.0.111 in the known hosts file of the CS .
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Adding a host named test with IP address 192.168.0.111. cli> config network hosttable add hostip 192.168.0.111 name test
You can repeat this step as many times as necessary.
BLACK BOX® CS Command Reference Guide
115
Step 3 - Activate the configuration.
cli> config runconfig
Step 4 - Save the configuration.
cli> config savetoflash
Step 5 - Exiting the CLI mode.
To exit the CLI mode and return to CS ’s shell, type the following command: cli> quit
116
4.8 TCP Keepalive
The objective of this feature is to allow the CS to recognize when the socket client (SSH or Telnet) goes down without closing the connection properly. Currently, if this happens in a serial port the system administrator must close the connection manually or nobody else can access that port anymore.
How it works
The TCP engine of CS will send a tcp keepalive message (ACK) to the client. If the maximum retry number is reached without an answer from the client, the connection is closed.
VI mode
The configuration is done in the file /bin/init_proc_fs using the linux proc filesystem.
# Enable TCP keepalive timer in CS (six retries with ten seconds
# of interval from each other).
# keepalive interval when the client is answering echo 20 > /proc/sys/net/ipv4/tcp_keepalive_time
# keepalive interval when the client is not answering.
echo 10 > /proc/sys/net/ipv4/tcp_keepalive_intvl
# number of retries echo 6 > /proc/sys/net/ipv4/tcp_keepalive_probes
# Enable TCP keepalive timer (six retries with twenty seconds
# of interval from each other).
echo 20 > /proc/sys/net/ipv4/tcp_keepalive_time echo 6 > /proc/sys/net/ipv4/tcp_keepalive_probes
File Description 4.9: /bin/init_proc_fs
CLI Method - TCP Keep Alive
Step 1 - .Open the CLI interface by issuing the command:
# CLI
BLACK BOX® CS Command Reference Guide
117
Step 2 - Configuring the pool interval (ms).
The command below will set a 50 ms pool interval.
cli>config physicalports all other tcpkeepalive 50
Step 3 - Activate the configuration.
cli> config runconfig
Step 4 - Save the configuration.
cli> config savetoflash
Step 5 - Exiting the CLI mode.
To exit the CLI mode and return to CS ’s shell, type the following command: cli> quit
118
4.9 Filters and Network Address Translation
The Filter feature is available for firmware versions 2.1.0 and above; the Network
Address Translation (NAT) feature is available for firmware versions 2.1.1 and above.
Description
IP filtering consists of blocking or not the passage of IP packets, based on rules which describe the characteristics of the packet, such as the contents of the IP header, the input/output interface, or the protocol. This feature is used mainly in firewall applications, which filter the packets that could crack the network system or generate unnecessary traffic in the network.
Network Address Translation (NAT) allows the IP packets to be translated from local network to global network, and vice-versa. This feature is particularly useful when there is demand for more IP addresses in the local network than available as global IP addresses. In the CS, this feature will be used mainly for clustering (one “Master”
Console server works as the interface between the global network and the “slave”
Console servers).
The CS uses the Linux utility iptables to set up, maintain and inspect both the filter and the NAT tables of IP packet rules in the Linux kernel. Besides filtering or translating packets, the iptables utility is able to count the packets which match a rule, and to create logs for specific rules.
Structure of the iptables
The iptables are structured in three levels: table, chain, and rule. A table can contain several chains, and each chain can contain several rules.
Table
The table indicates how the iptables will work. There are currently three independent tables supported by the iptables, but only two will be used:
•
filter: This is the default table.
•
nat: This table is consulted when a packet that creates a new connection is encountered.
Chain
Each table contains a number of built-in chains and may also contain user-defined chains. The built-in chains will be called according to the type of packet. User-defined chains will be called when a rule which is matched by the packet points to the chain.
Each table has a particular set of built-in chains:
BLACK BOX® CS Command Reference Guide
119
for the filter table:
•
INPUT - For packets coming into the box itself.
•
FORWARD - For packets being routed through the box.
•
OUTPUT - For locally-generated packets.
for the nat table:
•
PREROUTING - For altering packets as soon as they come in.
•
OUTPUT - For altering locally-generated packets as soon as they come in.
•
POSTROUTING - For altering packets as they are about to go out.
Rule
Each chain has a sequence of rules. These rules contain:
•
How the packet should appear in order to match the rule -> Some information about the packet is checked according to the rule, for example, the IP header, the input and output interfaces, the TCP flags and the protocol.
•
What to do when the packet matches the rule -> The packet can be accepted, blocked, logged or jumped to a user-defined chain. For the nat table, the packet can also have its source IP address and source port altered (for the POSTROUTING chain) or have the destination IP address and destination port altered (for the
PREROUTING and OUTPUT chain).
When a chain is analyzed, the rules of this chain are reviewed one-by-one until the packet matches one rule. If no rule is found, the default action for that chain will be taken.
Syntax
An iptables tutorial is beyond the scope of this manual. For more information on iptables, see the iptables man page (not included with the CS) or the how-to: http://www.netfilter.org or http://www.iptables.org
The syntax of the iptables command is:
# iptables -command chain rule-specification [-t table] [options]
# iptables -E old-chain-name new-chain-name where:
•
table - Can be filter or nat. If the option -t is not specified, the filter table will be assumed.
120
•
chain - Is one of the following: for filter table: INPUT, OUTPUT, FORWARD or a user-created chain.
for nat table: PREROUTING, OUTPUT, POSTROUTING or a user-created chain.
Command
Only one command can be specified on the command line unless otherwise specified below. For all the long versions of the command and option names, you need to use only enough letters to ensure that iptables can differentiate it from all other options.
Command Description
-A - - append
-D - - delete
-R - - replace
-I - - insert
Append one or more rules to the end of the selected chain. When the source and/or destination names resolve to more than one address, a rule will be added for each possible address combination.
Delete one or more rules from the selected chain. There are two versions of this command. The rule can be specified as a number in the chain
(starting at 1 for the first rule) or as a rule to match.
Replace a rule in the selected chain. If the source and/or destination names resolve to multiple addresses, the command will fail. Rules are numbered starting at 1.
Insert one or more rules in the selected chain as the given rule number.
Thus if the rule number is 1, the rule or rules are inserted at the head of the chain. This is also the default if no rule number is specified.
-L - - list
-F - - flush
-Z - - zero
-N - - new-chain
List all rules in the selected chain. If no chain is selected, all chains are listed. It is legal to specify the -Z (zero) option as well, in which case the chain(s) will be atomically listed and zeroed. The exact output is affected by the other arguments given.
Flush the selected chain. This is equivalent to deleting all the rules oneby-one.
Zero the packet and byte counters in all chains. It is legal to specify the -
L, --list (list) option as well, to see the counters immediately before they are cleared. (See above.)
New chain. Create a new user-defined chain by the given name. There must be no target of that name already.
-X - - delete-chain Delete the specified user-defined chain. There must be no references to the chain. If there are, you must delete or replace the referring rules before the chain can be deleted. If no argument is given, it will attempt to delete every non-built-in chain in the table.
Table 4.3: iptables commands options
BLACK BOX® CS Command Reference Guide
121
Command Description
-P - - policy Set the policy for the chain to the given target. Only non-user-defined chains can have policies, and neither built-in nor user-defined chains can be policy targets.
-E - - rename-chain Rename the user-specified chain to the user-supplied name. This is cosmetic, and has no effect on the structure of the table.
-h - - help Help. Gives a (currently very brief) description of the command syntax.
Table 4.3: iptables commands options
Rule Specification
The following parameters make up a rule specification (as used in the add, delete, insert, replace and append commands):
-p
Parameter
-s
-d
Description
- -protocol[!]protocol
The protocol of the rule or of the packet to check. The specified protocol can be one of tcp, udp, icmp, or all, or it can be a numeric value, representing one of these protocols or a different one. A protocol name from /etc/protocols is also allowed. A "!" argument before the protocol inverts the test. The number zero is equivalent to all. Protocol all will match with all protocols and is taken as default when this option is omitted.
- -source[!]address[/mask]
Source specification. Address can be either a hostname, a network name, or a plain IP address. The mask can be either a network mask or a plain number, specifying the number of 1's at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0. A "!" argument before the address specification inverts the sense of the address. The flag - -src is a convenient alias for this option.
- -destination[!]address[/mask]
Destination specification. See the description of the -s (source) flag for a detailed description of the syntax. The flag - -dst is an alias for this option.
Table 4.4: iptables rules specifications
122
-j
Parameter
-i
-o
[!]
-c
Description
- - jump target
This specifies the target of the rule; i.e., what to do if the packet matches it.
The target can be a user-defined chain (other than the one this rule is in), one of the special built-in targets which decide the fate of the packet immediately, or an extension (see EXTENSIONS below). If this option is omitted in a rule, then matching the rule will have no effect on the packet's fate, but the counters on the rule is incremental. The special built-in targets are :
•
ACCEPT means to let the packet through.
•
DROP means to drop the packet on the floor.
•
QUEUE means to pass the packet to userspace (if supported by the kernel).
•
RETURN means stop traversing this chain and resume at the next rule in the previous (calling) chain. If the end of a built-in chain is reached or a rule in a built-in chain with target RETURN is matched, the target specified by the chain policy determines the fate of the packet.
- -in-interface[!][name]
Optional name of an interface via which a packet is received (for packets entering the INPUT and FORWARD chains). When the "!" argument is used before the interface name, the sense is inverted. If the interface name ends in a
"+" then any interface which begins with this name will match. If this option is omitted, the string "+" is assumed, which will match with any interface name.
- -out-interface[!][name]
Optional name of an interface via which a packet is going to be sent (for packets entering the FORWARD and OUTPUT chains). When the "!" argument is used before the interface name, the sense is inverted. If the interface name ends in a "+" then any interface which begins with this name will match. If this option is omitted, the string "+" is assumed, which will match with any interface name.
-f - -fragment
This means that the rule only refers to second and further fragments of fragmented packets. Since there is no way to tell the source or destination ports of such a packet (or ICMP type), such a packet will not match any rules which specify them. When the "!" argument precedes the "-f" flag, the rule will only match head fragments, or unfragmented packets.
- -set-counters PKTS BYTES
This enables the administrater to initialize the packet and byte counters of a rule (during INSERT, APPEND, REPLACE operations).
Table 4.4: iptables rules specifications
BLACK BOX® CS Command Reference Guide
123
Parameter Description
-v - -verbose
Verbose output. This option makes the list command show the interface address, the rule options (if any), and the TOS masks. The packet and byte counters are also listed, with the suffix 'K', 'M' or 'G' for 1000, 1,000,000 and
1,000,000,000 multipliers respectively (but see the -x flag to change this). For appending, insertion, deletion and replacement, this causes detailed information on the rule or rules to be printed.
-n
-x
- -numeric
Numeric output. IP addresses and port numbers will be printed in numeric format. By default, the program will try to display them as host names, network names, or services (whenever applicable).
- -exact
Expand numbers. Display the exact value of the packet and byte counters, instead of only the rounded number in K's (multiples of 1000) M's (multiples of 1000K) or G's (multiples of 1000M). This option is only relevant for the -L command.
- -line-numbers When listing rules, add line numbers to the beginning of each rule, corresponding to that rule's position in the chain.
Table 4.4: iptables rules specifications
Match Extensions
Iptables can use extended packet matching modules. These are loaded in two ways: implicitly, when -p or - -protocol is specified, or with the -m or - -match option, followed by the matching module name; after these, various extra command line options become available, depending on the specific module.
124
TCP Extensions
These extensions are loaded if the protocol specified is tcp or “-m tcp” is specified. It provides the following options:
TCP extension Description
- - source-port [!] [port[:port]]
- - destination-port [!] [port[:port]] Destination port or port range specification. The flag
- -dport is an alias for this option.
- - tcp-flags [!] mask comp Match when the TCP flags are as specified. The first argument is the flags which we should examine, written as a comma-separated list, and the second argument is a comma-separated list of flags which must be set. Flags are: SYN ACK FIN RST URG PSH ALL NONE. Hence the command iptables
-A FORWARD -p tcp - -tcp-flags SYN,ACK,FIN,RST
SYN will only match packets with the SYN flag set, and the ACK, FIN and RST flags unset.
[!] - - syn
Source port or port range specification. This can either be a service name or a port number. Inclusive range can also be specified, using the format port:port. If the first port is omitted, "0" is assumed; if the last is omitted, “65535” is assumed. If the second port is greater then the first they will be swapped. The flag - -sport is an alias for this option.
- - tcp-option [!] number
Only match TCP packets with the SYN bit set and the
ACK and FIN bits cleared. Such packets are used to request TCP connection initiation; for example, blocking such packets coming in an interface will prevent incoming TCP connections, but outgoing TCP connections will be unaffected. It is equivalent to
- -tcp-flags SYN,RST,ACK SYN.
If the "!" flag precedes the "- -syn," the sense of the option is inverted.
Match if TCP option set.
Table 4.5: TCP extensions
BLACK BOX® CS Command Reference Guide
125
UDP Extensions
These extensions are loaded if the protocol udp is specified or “-m udp” is specified. It provides the following options:
UDP extension Description
- - source-port [!] [port[:port]] Source port or port range specification. See the description of the - -source-port option of the TCP extension for details.
- - destination-port [!] [port[:port]] Destination port or port range specification. See the description of the - -destination-port option of the TCP extension for details.
Table 4.6: UDP extensions
ICMP Extension
This extension is loaded if the protocol icmp is specified or “-m icmp” is specified. It provides the following option:
ICMP extension
- - icmp-type [!] typename
Description
This allows specification of the ICMP type, which can be a numeric ICMP type, or one of the ICMP type names shown by the command: iptables -p icmp -h
Table 4.7: ICMP extensions
Multiport Extension
This module matches a set of source or destination ports. Up to 15 ports can be specified.
It can only be used in conjunction with -m tcp or -m udp.
Multiport extension Description
- - source-port [port[,port]] Match if the source port is one of the given ports.
- - destination-port [port[,port]] Match if the destination port is one of the given ports.
- - port [port[,port]] Match if the both the source and destination port are equal to each other and to one of the given ports.
Table 4.8: Multiport extensions
126
Target Extensions
Iptables can use extended target modules. The following are included in the standard distribution.
LOG
Turn on kernel logging of matching packets. When this option is set for a rule, the Linux kernel will print some information on all matching packets (like most IP header fields) via the kernel log (where it can be read with syslog-ng).
LOG extension
- - log-level level
- - log-prefix prefix
- - log-tcp-sequence
- - log-tcp-options
- - log-ip-options
Description
Level of logging (numeric or see syslog.conf(5)).
Prefix log messages with the specified prefix; up to 29 letters long, and useful for distinguishing messages in the logs.
Log TCP sequence numbers. This is a security risk if the log is readable by users.
Log options from the TCP packet header.
Log options from the IP packet header.
Table 4.9: LOG extensions
BLACK BOX® CS Command Reference Guide
127
REJECT (filter table only)
This is used to send back an error packet in response to the matched packet: otherwise it is equivalent to DROP. This target is only valid in the INPUT, FORWARD and OUTPUT chains, and user-defined chains which are only called from those chains. Several options control the nature of the error packet returned:
LOG extension
- - reject-with type
Description
The type given can be icmp-net-unreachable, icmp-hostunreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited or icmp-host-prohibited, which return the appropriate ICMP error message (port-unreachable is the default).
The option echo-reply is also allowed; it can only be used for rules which specify an ICMP ping packet, and generates a ping reply.
Finally, the option tcp-reset can be used on rules which only match the TCP protocol: this causes a TCP RST packet to be sent back.
This is mainly useful for blocking ident probes which frequently occur when sending mail to broken mail hosts (which won't accept your mail otherwise).
Table 4.10: LOG extension
SNAT (NAT table only)
This target is only valid in the nat table, in the POSTROUTING chain. It specifies that the source address of the packet should be modified (and all future packets in this connection will also be mangled), and rules should cease being examined. It takes one option:
SNAT target Description
- - to-source <ipaddr>[-<ipaddr>][:port-port] This can specify a single new source IP address, an inclusive range of IP addresses, and optionally, a port range (which is only valid if the rule also specifies -p tcp or -p udp). If no port range is specified, then source ports below 1024 will be mapped to other ports below 1024: those between 1024 and
1023 inclusive will be mapped to ports below
1024, and other ports will be mapped to 1024 or above. Where possible, no port alteration will occur.
Table 4.11: SNAT target
128
DNAT (nat table only)
This target is only valid in the nat table, in the PREROUTING and OUTPUT chains, and user-defined chains which are only called from those chains. It specifies that the destination address of the packet should be modified (and all future packets in this connection will also be mangled), and rules should cease being examined. It takes one option:
DNAT target Description
- - to-destination <ipaddr>[-<ipaddr>][:port-port] This can specify a single new destination
IP address, an inclusive range of IP addresses, and optionally, a port range
(which is only valid if the rule also specifies -p tcp or -p udp). If no port range is specified, then the destination port will never be modified.
Table 4.12: DNAT target
MASQUERADE (nat table only)
This target is only valid in the nat table, in the POSTROUTING chain. It should only be used with dynamically assigned IP (dialup) connections: if you have a static IP address, you should use the SNAT target. Masquerading is equivalent to specifying a mapping to the IP address of the interface the packet is going out on, but also has the effect that connections are forgotten when the interface goes down. This is the correct behavior when the next dialup is unlikely to have the same interface address (and hence any established connections are lost anyway). It takes one option:
Target Description
- - to-ports <port>[-<port>] This specifies a range of source ports to use, overriding the default SNAT source port-selection heuristics (see above). This is only valid if the rule also specifies -p tcp or -p udp).
Table 4.13: Masquerade target
BLACK BOX® CS Command Reference Guide
129
REDIRECT (NAT table only)
This target is only valid in the nat table, in the PREROUTING and OUTPUT chains, and user-defined chains which are only called from those chains. It alters the destination IP address to send the packet to the machine itself (locally-generated packets are mapped to the 127.0.0.1 address). It takes one option:
Target Description
- - to-ports <port>[-<port>] This specifies a range of source ports to use, overriding the default SNAT source port-selection heuristics (see above). This is only valid if the rule also specifies -p tcp or -p udp).
Table 4.14: Redirect target
How to configure it
The file with the iptables rules is /etc/network/firewall. The fwset script saves the iptables rules in the file /etc/network/firewall (command iptables-save >
/etc/network/firewall) and then save the file in the flash memory. The fwset restore restores the iptables rules previously saved in /etc/network/firewall file (command
iptables-restore </etc/network/firewall). This command is executed at boot to invoke the last configuration saved.
VI method
Step 1 - Execute fwset restore.
This script will restore the IP Tables chains and rules configured in the
/etc/network/firewall file. This script can be called in the process, whenever the user wants to restore the original configuration.
Step 2 - Add the chains and rules using the command line.
See details of the iptables syntax earlier in this chapter.
Step 3 - Execute iptables-save > /etc/network/firewall.
This program will save all the rules and chains of all the tables in the
/etc/network/firewall file.
Step 4 - Execute updatefiles /etc/network/firewall.
This program will save the configuration to the flash memory.
130
4.10 VPN Configuration
The IPSec protocol provides encryption and authentication services at the IP level of the network protocol stack. Working at this level, IPSec can protect any traffic carried over
IP, unlike other encryption which generally protects only a particular higher-level protocol (PGP for mail, SSH for login, SSL for Web work and so on). The implementation of IPSec used by the CS is Openswan 2.3.0.
IPsec can be used on any machine which does IP networking. Dedicated IPsec gateway machines can be installed wherever required to protect traffic. IPsec can also run on routers, on firewall machines, on various application servers, and on end-user desktop or laptop machines.
IPsec is used mainly to construct a secure connection (tunnel) between two networks
(ends) over a not-necessarily-secure third network. In our case, the IPsec will be used to connect the CS securely to a host or to a whole network configurations frequently called host-to-network and host-to-host tunnel. Considering practical aspects, this is the same thing as a VPN, but here one or both sides have a degenerated subnet (only one machine).
Applications of IPsec
Because IPsec operates at the network layer, it is remarkably flexible and can be used to secure nearly any type of Internet traffic.
Two applications, however, are extremely widespread:
•
A Virtual Private Network, or VPN, allows multiple sites to communicate with the
Console Server securely over an insecure Internet by encrypting all communication between the sites and the Console Server.
•
Road Warriors connect to the Console Server from home, or perhaps from a hotel somewhere.
A somewhat more detailed description of each of these applications is below. Our Quick
Start section will show you how to build each of them.
Using secure tunnels to create a VPN
A VPN, or Virtual Private Network lets the Console Server and a whole network communicate securely when the only connection between them is over a third network which is not trustable. The method is to put a security gateway machine in the network and create a security tunnel between the Console Server and this gateway. The gateway machine and the Console Server encrypt packets entering the untrusted net and decrypt packets leaving it, creating a secure tunnel through it.
BLACK BOX® CS Command Reference Guide
131
Road Warriors
The prototypical Road Warrior is a traveler connecting to the Console Server from a laptop machine. For purposes of this document:
•
Anyone with a dynamic IP address is a Road Warrior.
•
Any machine doing IPsec processing is a gateway. Think of the single-user Road
Warrior machine as a gateway with a degenerate subnet (one machine: itself) behind it.
These require a somewhat different setup than VPN gateways with static addresses and with client systems behind them, but are basically not problematic. There are some difficulties which appear for some Road Warrior connections:
•
Road Warriors who get their addresses via DHCP may have a problem. Openswan can quite happily build and use a tunnel to such an address, but when the DHCP lease expires, Openswan does not know that. The tunnel fails, and the only recovery method is to tear it down and rebuild it.
•
If Network Address Translation (NAT) is applied between the two IPsec
Gateways, this breaks IPsec. IPsec authenticates packets on an end-to-end basis, to ensure they are not altered en route. NAT rewrites packets as they go by.
In most situations, however, Openswan supports Road Warrior connections just fine.
Before you start
This is a quick guide to set up two common configurations: VPN and Road Warrior.
There are two examples: a Road Warrior using RSA signature and a VPN using RSA signature. When listing the configuration of the remote side (the equipment the CS will create a tunnel with) these examples will assume the other end is also running the
Openswan. If it is not your case, make the appropriate conversions for your IPsec software.
Setup and test networking. Before trying to get Openswan working, you should configure and test IP networking on the Console Server and on the other end. IPsec can not function without a working IP network beneath it. Many reported Openswan problems turn out to actually be problems with routing or firewalling. If any actual IPsec problems turn up, you often cannot even recognize them (much less debug them) unless the underlying network is right.
Enabling IPsec on your CS. The IPsec is disabled by default in the Console Server family. To enable it you must edit the file /etc/daemon.d/ipsec.sh change
“ENABLE=NO” to “ENABLE=YES” and run the “saveconf” command. To start
IPSEC, type “daemon.sh restart IPSEC” <enter>. IPSEC will start automatically during subsequent reboots if you have saved /etc/daemon.d/ipsec.sh with “saveconf”.
132
"Road Warrior" configuration
Think about the administrator that wants to access the CS securely from wherever he is, from his office desk, from his house, or from the hotel room. His IP address will not be always the same, so, for IPsec purposes, he is a "Road Warrior." We refer to the remote machines as Road Warriors. For purposes of IPsec, anyone with a dynamic IP address is a Road Warrior.
Necessary Information
To set up a Road Warrior connection, you need some information about the system on the other end. Connection descriptions use left and right to designate the two ends. We adopt the convention that, from the Console Server's point of view, left=local and right
=remote. The Console Server administrator needs to know some things about each Road
Warrior:
•
The system's public key (for RSA only).
•
The ID that system uses in IPsec negotiation.
To get system's public key in a format suitable for insertion directly into the Console
Server's ipsec.conf file, issue this command on the warrior machine:
# /usr/local/sbin/ipsec showhostkey --right
The output should look like this (with the key shortened for easy reading): rightrsasigkey=AQNe6hpbROGVES6uXeCxpnd88fdafpO0w5OT0s1LgR7/oUM...
The Road Warrior needs to know:
•
The Console Server's public key or the secret, and
•
The ID the Console Server uses in IPsec negotiation. which can be generated by running:
# /usr/local/sbin/ipsec showhostkey --left on the Console Server. Each warrior must also know the IP address of the Console
Server. This information should be provided in a convenient format, ready for insertion in the warrior's ipsec.conf file. For example:
# left=1.2.3.4 [email protected] leftrsasigkey=0s1LgR7/oUM...
The Console Server administrator typically needs to generate this only once. The same file can be given to all warriors.
BLACK BOX® CS Command Reference Guide
133
Setup on the "Road Warrior" machine
Simply add a connection description us-to-Console Server, with the left and right information you gathered above to the ipsec.conf file of the warrior system. This might look like:
# pre-configured link to Console Server conn us-to-cs
# information obtained from Console Server admin left=1.2.3.4 # Console Server IP address [email protected]
# real keys are much longer than shown here leftrsasigkey=0s1LgR7/oUM...
# warrior stuff right=%defaultroute [email protected]
rightrsasigkey=0s1LgR7/oUM
# Start this connection when IPsec starts auto=start
File Description 4.1: Road Warrior ipsec.conf file
IMPORTANT!
The connection name line: "conn us-to-cs" must start on the FIRST column of the line. All other lines after that line must be indented by 1 TAB. This is MANDATORY.
134
Setup on the CS
Adding Road Warrior support so people can connect remotely to your Console Server is straightforward. Just create the file /etc/warrior.connection and add the following lines to this file: conn gate-by left=1.2.3.4
leftrsasigkey=0s1LgR7/oUM...
# allow connection attempt from any address
# attempt fails if caller cannot authenticate right-angle
# authentication information [email protected]
rightrsasigkey=0s1LgR7/oUM...
# Add this connection to the database when IPsec starts autoload
File Description 4.2: CS ipsec.conf file
IMPORTANT!
The connection name line: "conn gate-xy" must start on the FIRST column of the line. All other lines after that line must be indented by 1 TAB. This is MANDATORY.
BLACK BOX® CS Command Reference Guide
135
VPN configuration
Often it may be useful to have explicitly configured IPsec tunnels between the Console
Server and a gateway of an office with a fixed IP address (in this case every machine on the office network would have a secure connection with the Console Server), or between the Console Server and the Console Server administrator machine, which must, in this case, have a fixed IP address.
To do it just insert this connection description in your ipsec.conf file with the variables that fit your environment:
# sample tunnel
# The network here looks like:
# CS ----csnexthop......rightnexthop----right====rightsubnet
# If CS and right are on the same Ethernet, omit leftnexthop and
# rightnexthop. conn sample
# CS left=10.0.0.1 [email protected]
# next hop to reach right leftnexthop=10.44.55.66
# This line is only for RSA signature leftrsasigkey=0s1LgR7/oUM...
# right s.g., subnet behind it, and next hop to reach left right=10.12.12.1 [email protected] rightnexthop=10.88.77.66 rightsubnet=192.168.0.0/24
# Start this connection when IPsec starts auto=start
# This line is for RSA signature rightrsasigkey=0s1LgR7/oUM...
File Description 4.3: Sample of the ipsec.conf file
IMPORTANT!
The connection name line: "conn sample" must start on the FIRST column of the line. All other lines after that line must be indented by 1 TAB. This is MANDATORY.
TIP.
There is an alternative way to configure the left and right ipsec rsa keys. Instead of typing (copy/paste) the entire rsa key in the fields: leftrsasigkey and rightrsasigkey inside the
/etc/ipsec.conf file, the administrator can just type in the filename where the rsa key was generated. Example: leftrsasigkey=@file /etc/CS48AL.lrsa
136
The keyword @file and at least one space must precede the filename. Do not forget to include the path of the files containing the RSA keys in the /etc/config_files file.
The good part is that this connection descriptor can be added to both the Console Server and the other end. This is the advantage of using left and right instead of using local remote parameters.
If you give an explicit IP address for left (and left and right are not directly connected), then you must specify leftnexthop (the router which Console Server sends packets to in order to get them delivered to right). Similarly, you may need to specify rightnexthop
(vice versa).
Authentication Keys
To build a connection, the Console Server and the other end must be able to authenticate each other. For Openswan, the default is public key authentication based on the RSA algorithm. IPsec does allow several other authentication methods. On this chapter you will learn how to generate authentication keys and how to exchange keys between systems.
Generating an RSA key pair. The Console Server doesn't have an RSA key pair by default. It will be generated on the first reboot after you have enabled the IPsec daemon in the file /etc/daemon.d/ipsec.sh. You also can generate your key pair by issuing the following commands as root:
# /usr/local/sbin/ipsec newhostkey --bits <key length> --output /etc/ipsec.secrets
# chmod 600 /etc/ipsec.secrets
Key generation may take some time. In addition, the Console Server needs a lot of random numbers and therefore needs and uses traffic on the Ethernet to generate them.
It is also possible to use keys in other formats, not generated by Openswan. This may be necessary for interoperation with other IPsec implementations.
Exchanging authentication keys. Once your CS 's key is in ipsec.secrets, the next step is to send your public key to everyone you need to set up connections with and collect their public keys. To extract the public part in a suitable format you can use the
ipsec_showhostkey command. For VPN or Road Warrior applications, use one of the following:
If your CS is the left side of the tunnel:
# /usr/local/sbin/ipsec showhostkey --left
BLACK BOX® CS Command Reference Guide
137
If your CS is the right side of the tunnel:
# /usr/local/sbin/ipsec showhostkey --right
These two produce the key formatted for insertion in an ipsec.conf file. Public keys need not be protected as fanatically as private keys. They are intended to be made public; the system is designed to work even if an enemy knows all the public keys used. You can safely make them publicly accessible. For example, put a gateway key on a Web page or make it available in DNS, or transmit it via an insecure method such as email.
IPsec Management
After you have all the configuration done you need to manage all tunnels and manage
IPsec itself. This section will show you a few commands that have proven to be useful when managing IPsec and IPsec connections.
The IPsec Daemon
The IPsec daemon (PLUTO) is the program that loads and negotiates the connections.
To start the IPsec daemon use the following command:
# /usr/local/sbin/ipsec setup --start
Similarly, this command accepts the usual daemon commands as stop and restart.
The ipsec daemon is automatically initialized when you boot your Console Server equipment.
NAT-Transversal
CS 2.6 uses Openswan 2.3.0, which has support for NAT-Transversal. NAT-T allows
IPSec to be used behind any NAT device by encapsulating ESP (Encapsulated Security
Payload) in UDP.
Add the following line to /etc/ipsec.conf file to enable NAT-Transversal.
nat_transversal=yes
138
Adding and Removing a Connection
All the connections can be loaded to the IPsec database at boot time if these connections have the auto parameter set to add. However if a certain connection doesn't have this option set and you wish to add this connection manually you can use the following command:
# /usr/local/sbin/ipsec auto --add <connection name>
Similarly, to take a connection out of the IPsec database you can use the command:
# /usr/local/sbin/ipsec auto --delete <connection name>
Once a connection descriptor is in the IPsec internal database, IPsec will accept the other end to start the security connection negotiation. You can also start its negotiation as explained in the next section.
Starting and Stopping a Connection
All the connections can be negotiated at boot time if these connections have the auto parameter set to start. However if a certain connection doesn't have this option set, you can set it. Once a connection descriptor is in the IPsec internal database, you can start its negotiation using the command:
# /usr/local/sbin/ipsec auto --up <connection name>
Similarly to close a tunnel you use the command:
# /usr/local/sbin/ipsec auto --down <connection name>
Below you can see the output of a successful up operation:
[root@cs_cas root]# ipsec auto --up test
104 "test" #5: STATE_MAIN_I1: initiate
106 "test" #5: STATE_MAIN_I2: sent MI2, expecting MR2
108 "test" #5: STATE_MAIN_I3: sent MI3, expecting MR3
004 "test" #5: STATE_MAIN_I4: ISAKMP SA established
112 "test" #6: STATE_QUICK_I1: initiate
004 "test" #6: STATE_QUICK_I2: sent QI2, IPsec SA established
BLACK BOX® CS Command Reference Guide
139
IPsec whack
The ipsec whack command show the status of the connections.
[root@cs_cas root]# ipsec whack --status
000 interface ipsec0/eth0 64.186.161.96
000
000 "test": 64.186.161.96[@micro]...64.186.161.128[@CS ]
000 "test": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "test": policy: RSASIG+ENCRYPT+TUNNEL+PFS; interface: eth0; routed
000 "test": newest ISAKMP SA: #5; newest IPsec SA: #6; route owner: #6
000
000 #6: "test" STATE_QUICK_I2 (sent QI2, IPsec SA established);
EVENT_SA_REPLACE in 28245s; newest IPSEC; route owner
000 #6: "test" [email protected] [email protected]
[email protected] [email protected]
000 #5: "test" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in
3019s; newest ISAKMP
As you can see, it shows almost the same information shown by the ipsec auto -up command. You can use this command if the up command doesn't show anything on the screen (it can happen depending on the CS syslog configuration).
The IPsec Configuration Files in Detail
This section will describe the file /etc/ipsec.conf in detail.
Description
The ipsec.conf file specifies most configuration and control information for the
Openswan IPsec subsystem. (The major exception is secrets for authentication;
ipsec.secrets) Its contents are not security-sensitive unless manual keying is being done for more than just testing, in which case the encryption and authentication keys in the descriptions for the manually-keyed connections are very sensitive (and those connection descriptions are probably best kept in a separate file, via the include facility described below).
The file is a text file, consisting of one or more sections. White space followed by # followed by anything to the end of the line is a comment and is ignored, as are empty lines which are not within a section.
140
A line which contains include and a file name, separated by white space, is replaced by the contents of that file, preceded and followed by empty lines. If the file name is not a full pathname, it is considered to be relative to the directory containing the including file.
Such inclusions can be nested. Only a single filename may be supplied, and it may not contain white space, but it may include shell wildcards for example: include ipsec.*.conf
The intention of the include facility is mostly to permit keeping information on connections, or sets of connections, separate from the main configuration file. This permits such connection descriptions to be changed, copied to the other security gateways involved, etc., without having to constantly extract them from the configuration file and then insert them back into it. Note the also parameter (described below) which permits splitting a single logical section (e.g., a connection description) into several actual sections.
A section begins with a line of the form: type name where type indicates what type of section follows, and name is an arbitrary name which distinguishes the section from others of the same type. (Names must start with a letter and may contain only letters, digits, periods, underscores, and hyphens.) All subsequent non-empty lines which begin with white space are part of the section; comments within a section must begin with white space too. There may be only one section of a given type with a given name.
Lines within the section are generally of the following form: parameter=value
(Note the mandatory preceding TAB.) There can be white space on either side of the =.
Parameter names follow the same syntax as section names, and are specific to a section type. Unless otherwise explicitly specified, no parameter name may appear more than once in a section.
An empty value stands for the system default value (if any) of the parameter, i.e., it is roughly equivalent to omitting the parameter line entirely. A value may contain white space only if the entire value is enclosed in double quotes ("); a value cannot itself contain a double quote, nor may it be continued across more than one line.
Numeric values are specified to be either an integer (a sequence of digits) or a decimal number (sequence of digits optionally followed by . and another sequence of digits).
There is currently one parameter which is available in any type of section: also
BLACK BOX® CS Command Reference Guide
141
The value is a section name; the parameters of that section are appended to this section, as if they had been written as part of it. The specified section must exist, must follow the current one, and must have the same section type. (Nesting is permitted, and there may be more than one also in a single section, although it is forbidden to append the same section more than once.) This allows, for example, keeping the encryption keys for a connection in a separate file from the rest of the description, by using both an also parameter and an include line.
A section with name %default specifies defaults for sections of the same type. For each parameter in it, any section of that type which does not have a parameter of the same name gets a copy of the one from the %default section. There may be multiple %default sections of a given type, but only one default may be supplied for any specific parameter name, and all %default sections of a given type must precede all non-%default sections of that type. %default sections may not contain also parameters.
Currently there are two types of sections: a config section specifies general configuration information for IPsec, while a conn section specifies an IPsec connection.
Conn Sections
A conn section contains a connection specification, defining a network connection to be made using IPsec. The name given is arbitrary, and is used to identify the connection to
ipsec_auto and ipsec_manual. Here's a simple example: conn snt left=10.11.11.1 leftsubnet=10.0.1.0/24 leftnexthop=172.16.55.66 right=192.168.22.1 rightsubnet=10.0.2.0/24 rightnexthop=172.16.88.99 keyingtries=0 # be very persistent
File Description 4.4: part of the /etc/ipsec.conf file
To avoid trivial editing of the configuration file to suit it to each system involved in a connection, connection specifications are written in terms of left and right participants, rather than in terms of local and remote. Which participant is considered left or right is arbitrary; IPsec figures out which one it is being run on based on internal information.
This permits using identical connection specifications on both ends.
Many of the parameters relate to one participant or the other; only the ones for left are listed here, but every parameter whose name begins with left has a right counterpart, whose description is the same but with left and right reversed.
142
Parameters are optional unless marked required; a parameter required for manual keying need not be included for a connection which will use only automatic keying, and vice versa.
Conn parameters: General. The following parameters are relevant to both automatic and manual keying. Unless otherwise noted, for a connection to work, in general it is necessary for the two ends to agree exactly on the values of these parameters. The two ends can be defined as Left or Local, and Right or Remote.
•
type: The type of the connection. Currently the accepted values are: tunnel (the default) signifying a host-to-host, host-to-subnet, or subnet-to-subnet tunnel; transport, signifying host-to-host transport mode; and passthrough (supported only for manual keying), signifying that no IPsec processing should be done at all.
•
left (local) and right (remote) IP: The IP address of the participant's network interface. If it is the magic value %defaultroute, and interfaces=%defaultroute is used in the config setup section, left will be filled in automatically with the local address of the default-route interface (as determined at IPsec startup time). This also overrides any value supplied for leftnexthop. (Either left or right may be
%defaultroute, but not both.) The magic value %any signifies an address to be filled in (by automatic keying) during negotiation; the magic value %opportunistic signifies that both left and leftnexthop are to be filled in (by automatic keying) from DNS data for left's client.
•
left(local) and right (remote) subnet: Private subnet behind the left and right participants, expressed as network/netmask.
•
left(local) and right (remote) nexthop: NextHop gateway IP address for the left and right participant connection to the public network.
•
left (local) and right (remote) updown script: What updown script to run to adjust routing and/or firewalling when the status of the connection changes. The path to the default updown script on CS is /usr/local/lib/ipsec/_updown
Conn parameters: Automatic Keying. The following parameters are relevant only to automatic keying, and are ignored in manual keying. Unless otherwise noted, for a connection to work, in general it is necessary for the two ends to agree exactly on the values of these parameters.
•
auto: What operation, if any, should be done automatically at IPsec startup; currently- accepted values are add (signifying an ipsec auto --add), route
(signifying that plus an ipsec auto --route), start (signifying that plus an ipsec auto
--up), and ignore (also the default) (signifying no automatic startup operation).
This parameter is ignored unless the plutoload or plutostart configuration parameter is set suitably; see the config setup discussion below.
•
auth: Whether authentication should be done as part of ESP encryption, or separately using the AH protocol, acceptable values are esp (the default) and ah.
•
authby: How the two security gateways should authenticate each other. Acceptable values are secret for shared secrets (the default) and rsasig for RSA digital signatures.
BLACK BOX® CS Command Reference Guide
143
•
leftid and rightid: How the left and right participant should be identified for authentication. Defaults to left. Can be an IP address or a fully-qualified domain name preceded by @ (which is used as a literal string and not resolved).
•
leftrsasigkey and rightrsasigkey: The left and right participants public key for RSA signature authentication, in RFC 2537 format. The magic value %none means the same as not specifying a value (useful to override a default). The value
%dnsondemand means the key is to be fetched from DNS at the time it is needed.
The value %dnsonload means the key is to be fetched from DNS at the time the connection description is read from ipsec.conf. Currently this is treated as %none if right=%any or right=%opportunistic. The value %dns is currently treated as
%dnsonload but will change to %dnsondemand in the future. The identity used for the left participant must be a specific host, not %any or another magic value.
Caution: if two connection descriptions specify different public keys for the same leftid, confusion and madness will ensue.
•
pfs: Whether Perfect Forward Secrecy of keys is desired on the connection's keying channel. (With PFS, penetration of the key-exchange protocol does not compromise keys negotiated earlier.) Acceptable values are yes (the default) and no.
•
keylife: How long a particular instance of a connection (a set of encryption/ authentication keys for user packets) should last, from successful negotiation to expiry. Acceptable values are an integer optionally followed by s (a time in seconds) or a decimal number followed by m, h, or d (a time in minutes, hours, or days respectively) (default 8.0h, maximum 24h).
•
rekey: Whether a connection should be renegotiated when it is about to expire.
Acceptable values are yes (the default) and no.
•
rekeymargin: How long before connection expiry or keying-channel expiry should attempts to negotiate a replacement begin. Acceptable values as for keylife
(default 9m).
•
redeyfuzz: Maximum percentage by which rekeymargin should be randomly increased to randomize rekeying intervals (important for hosts with many connections). Acceptable values are an integer, which may exceed 100, followed by a %.
•
keyingtries: How many attempts (an integer) should be made to negotiate a connection, or a replacement for one, before giving up (default 3). The value 0 means never give up.
•
ikelifetime: How long the keying channel of a connection (buzzphrase: ISAKMP
SA) should last before being renegotiated. Acceptable values as for keylife.
•
compress: Whether IPComp compression of content is desired on the connection.
Acceptable values are yes and no (the default).
Conn parameters: Manual Keying. The following parameters are relevant only to manual keying, and are ignored in automatic keying. Unless otherwise noted, for a connection to work, in general it is necessary for the two ends to agree exactly on the values of these parameters. A manually-keyed connection must specify at least one of
AH or ESP.
•
esp: ESP encryption/authentication algorithm to be used for the connection, e.g.
3des-md5-96.
•
espenckey: ESP encryption key.
144
•
espauthkey: ESP authentication key.
•
espreplay_window: ESP replay-window setting. An integer from 0 to 64. Relevant only if ESP authentication is being used.
•
ah: AH authentication algorithm to be used for the connection, e.g. hmac-md5-96.
Default is not to use AH.
•
ahkey: Required if ah is present. AH authentication key
•
ahreplay_window: AH replay-window setting. An integer from 0 to 64.
Config Section
At present, the only config section known to the IPsec software is the one named setup, which contains information used when the software is being started. Here's an example: config setup interfaces="ipsec0=eth1 ipsec1=ppp0" klipsdebug=none plutodebug=all manualstart= plutoload="snta sntb sntc sntd" plutostart=
File Description 4.5: part of the /etc/ipsec.conf file
Parameters are optional unless marked required. The currently-accepted parameter names in a config setup section are:
•
interfaces: Required. Virtual and physical interfaces for IPsec to use: a single virtual= physical pair, a quoted list of pairs separated by white space, or
%defaultroute, which means to find the interface d that the default route points to, and then act as if the value was ipsec0=d.
•
forwardcontrol: Whether setup should turn IP forwarding on (if it's not already on) as IPsec is started, and turn it off again (if it was off) as IPsec is stopped.
Acceptable values are yes and (the default) no.
•
klipsdebug: How much KLIPS debugging output should be logged. An empty value, or the magic value none, means no debugging output (the default). The magic value all means full output.
•
plutodebug: How much Pluto debugging output should be logged. An empty value, or the magic value none, means no debugging output (the default). The magic value all means full output.
•
dumpdir: In what directory should things started by setup (notably the Pluto daemon) be allowed to dump core. The empty value (the default) means they are not allowed to.
•
manualstart: Which manually-keyed connections to set up at startup (can be empty, a name, or a quoted list of names separated by white space).
•
plutoload: Which connections (by name) to load into Pluto's internal database at startup (can be empty, a name, or a quoted list of names separated by white space); see ipsec_auto for details. Default is none. If the special value %search is used, all connections with auto=add, auto=route, or auto=start are loaded.
BLACK BOX® CS Command Reference Guide
145
•
plutostart: Which connections (by name) to attempt to negotiate at startup (can be empty, a name, or a quoted list of names separated by white space). Any such names which do not appear in plutoload are implicitly added to it. Default is none.
If the special value %search is used, all connections with auto=route or auto=start are routed, and all connections with auto=start are started.
•
plutowait: Specify if Pluto should wait for each plutostart negotiation attempt to finish before proceeding with the next one. Values are yes (the default) or no.
•
prepluto: Shell command to run before starting Pluto. For example, to decrypt an encrypted copy of the ipsec.secrets file. It's run in a very simple way. Complexities like I/O redirection are best hidden within a script. Any output is redirected for logging, so running interactive commands is difficult unless they use /dev/tty or equivalent for their interaction. Default is none.
•
postpluto: Shell command to run after starting Pluto (e.g., to remove a decrypted copy of the ipsec.secrets file).
•
fragicmp: Whether a tunnel need to fragment a packet should be reported back with an ICMP message, in an attempt to make the sender lower his PMTU estimate.
Acceptable values are yes (the default) and no.
•
packetdefault: What should be done with a packet which reaches KLIPS (via a route into a virtual interface) but does not match any route. Acceptable values are pass (insecure unless you really know what you're doing), drop (the default), and reject (currently same as drop).
•
hidetos: Whether a tunnel packet's TOS field should be set to 0 rather than copied from the user packet inside. Acceptable values are yes (the default) and no.
•
uniqueids: Whether a particular participant ID should be kept unique, with any new
(automatically keyed) connection using an ID from a different IP address deemed to replace all old ones using that ID. Acceptable values are yes and no (the default).
•
overridemtu: Value that the MTU of the ipsec interface(s) should be set to, overriding IPsec's (large) default. This parameter is needed only in special situations.
CLI Method - VPN Configuration
It is possible to configure almost everything using the CLI interface. You just won’t be able to generate the RSA keys neither copy the keys of remote hosts. Be sure to do it before entering the CLI mode.
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Access the VPN menu.
cli> config network vpn
This menu lets you add, edit or delete a VPN connection. When adding or editing a connection, you’ll be prompted to configure the following parameters:
146
Parameter Values
connectionname authprotocol authmethod rightid rightip rightnexthop rightsubnet rightrsa
<name> - Edit mode only
<esp|ah>
<rsa|secret>
<id>
<n.n.n.n>
<hop>
<n.n.n.n>
<rsa key> leftid leftip leftnexthop leftsubnet
<id>
<n.n.n.n>
<hop>
<n.n.n.n> leftrsa bootaction
<rsa key>
<ignore|add|start> secret <secret>
Table 4.15: VPN parameters
How each parameter works and their respective descriptions can be found just above in the section
.
Step 3 - Activate the configuration.
cli> config runconfig
Step 4 - Save the configuration.
cli> config savetoflash
Step 5 - Connection management.
BLACK BOX® CS Command Reference Guide
147
After configuring the VPN connection you will have to manage the VPN connections in the prompt shell. The CLI does not provide management utilities.
Find more information on
“IPsec Management” on page 138 .
Step 6 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
148
Chapter 5
Administration
..........................................................................
The objective of this chapter is showing any task related to the administration of the unit. This includes the following topics:
•
SNMP
•
CronD
•
Dual Power Management
•
Syslog-ng
•
Generating Alarms (Syslog-ng)
•
Terminal Appearance
•
Centralized Management
•
Date, Time and Timezone
•
Session Sniffing
•
Saveconf and Restoreconf
•
Start and Stop Services
•
Security Profiles
Chapter 5 - Administration
5.1 SNMP
Short for Simple Network Management Protocol: a set of protocols for managing complex networks. The first versions of SNMP were developed in the early 80s. SNMP works by sending messages, called protocol data units (PDUs), to different parts of a network. SNMP-compliant devices, called agents, store data about themselves in Management Information
Bases (MIBs) and return this data to the SNMP requesters.
CS uses the net-snmp package (http://www.net-snmp.org).
Note:
IMPORTANT!
Check the SNMP configuration before gathering information about CS by SNMP. There are different types of attacks an unauthorized user can implement to retrieve sensitive information contained in the MIB. By default, the SNMP configuration in CS cannot permit the public community to read SNMP information.
The net-snmp supports snmp version 1, 2 and 3. To use SNMP version 1 or 2 (community), you need to configure the communities in the snmp config file (/etc/snmp/snmpd.conf). For example, to include the
communities blackbox and public, you need add the following lines in /
etc/snmp/snmpd.conf:
# blackbox is read-write community rwcommunity blackbox
# public is a read-only community rocommunity public
File Description 5.1: part of the /etc/snmp/snmpd.conf file
To use SNMP version 3 (username/password), perform the following steps:
1. Create a file /etc/snmp/snmpd.local.conf with the following line:
# createUser <username> MD5 <password> DES
For example :
# createUser usersnmp MD5 user_snmp_passwd DES
Note: The SNMP v3 password must be less than 31 characters.
a.
Edit the /etc/snmp/snmpd.conf file.
If the user has permission to read only, to add the line :
# rouser <username> (eg.: rouser usersnmp).
If the user has permission to read and write, to add the line :
# rwuser <username> (eg.: rwuser usersnmp). a.
Include the following line in /etc/config_files:
/etc/snmp/snmpd.local.conf
You can configure the /etc/snmp/snmpd.conf file as indicated later in this section.
1. Snmp version 1
• RFC1155 - SMI for the official MIB tree
• RFC1213 - MIB-II
2. Snmp version 2
• RFC2578 - Structure of Management Information Version 2
(SMIv2)
• RFC2579 - Textual Conventions for SMIv2
150
• RFC2580 - Conformance Statements for SMIv2
3. Snmp version 3
• RFC2570 - Introduction to Version 3 of the Internet-standard
Network Management Framework.
• RFC2571 - An Architecture for Describing SNMP Management
Frameworks.
• RFC2572 - Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP).
• RFC2573 - SNMP Applications.
• RFC2574 - User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3).
• RFC2575 - View-based Access Control Model (VACM) for the
Simple Network Management Protocol (SNMP).
• RFC2576 - Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework.
4. Private UCD SNMP mib extensions (enterprises.2021)
• Information about memory utilization (/proc/meminfo)
• Information about system status (vmstat)
• Information about net-snmp packet
5. Private Blackbox Vendor MIB (enterprises.2925)
• CS remote Management Object Tree (blackbox.4). This MIB permits you to get informations about the product, to read/write some configuration items and to do some administration commands. (For more details see the blackbox.mib file.)
Configuration
This section describe how to configure the SNMP using the vi editor.
VI Method - Involved parameters and passed values
The followings steps shows how to configure SNMP v1 and v2 using /etc/
snmp/snmpd.conf file.
BLACK BOX® CS Command Reference Guide
151
1. To define the public community, insert the following line in the /etc/ snmp/snmp.conf file. This is a read-only access to the MIB
(Management Information Base) values.
rocommunity public <“default”, hostname, or network/mask> .1
2. Save the configuration changes in the snmp.conf file.
[root@CAS root]# saveconf
3. Restart the SNMP daemon to read the new configuration.
[root@CAS root]# daemon.sh restart SNMP
152
CLI Method - SNMP
You can configure SNMP v1, v2 and v3 just using the CLI interface. The steps below will give an overview of this process.
1. Open the CLI interface by issuing the command:
# CLI a.
Configuring SNMP v1/v2.
cli>config network snmp v1v2 add community test1 oid .1 permission ro source 192.168.0.200
The command presented above will configure SNMP v1/v2 with the following characteristics:
• community: test1
• OID: .1
• permission: ro (read only)
• source (allowed host): 192.168.0.200 a.
Configuring SNMP v3.
cli>config network snmp v3 add username john password john1234 oid .1 permission ro
The command presented above will configure SNMP v1/v2 with the following characteristics:
• username: john
• password: john1234
• OID: .1
• permission: ro (read only)
Note: The SNMP v3 password must be less than 31 characters.
a.
Activating the configuration.
cli>config runconfig a.
Testing the configuration.
Considering that the targeted CS has the IP address 192.168.0.1 and the Linux machine from where the commands will be issued is 192.168.0.200, run the following commands:
For SNMP v1/v2
# snmpwalk -v 2c -c test1 192.168.0.1 .1
BLACK BOX® CS Command Reference Guide
153
For SNMP v3
# snmpwalk -v 3 -u john -l authpriv -a MD5 -A john1234 -x DES -X john1234
192.168.0.1 .1
a.
Save the configuration.
cli> config savetoflash a.
Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
154
5.2 CronD
CronD is a service provided by the CS system that allows automatic, periodically-run custom-made scripts. It replaces the need for the same commands to be run manually.
How to configure
The crond daemon in the CS has a peculiar way of configuration that is basically it is divided in three parts:
•
/etc/crontab_files - The name of this file can’t be changed and it
must point only to ONE file. Further information about it will be given in the next lines.
• source file - This file holds information about frequency and which files should be executed. It can have any name, since it is pointed out by the /etc/crontab_files.
• script files - These are the script files scheduled and pointed by the source file explained above.
The following parameters are created in the /etc/crontab_files file:
• status - Active or inactive. If this item is not active, the script will not be executed.
• user - The process will be run with the privileges of this user, who must be a valid local user.
• source - Pathname of the crontab file that specifies frequency of execution, the name of shell script, etc. It should be set using the traditional crontab file format.
active root /etc/tst_cron.src
File Description 5.2: /etc/crontab_files
Note:
NOTE:
In /etc/crontab_files, you can only have one active entry per user.
For instance, from the example above, you cannot add another active entry for root because it already has an entry. If you want to add more scripts, you can just add them to the source file, eg.: (/etc/tst_cron.src).
The /etc/crontab_files file can point to any desired file that calls the scripts to be run. The CS has example file for it (/etc/tst_cron.src). The
BLACK BOX® CS Command Reference Guide
155
file that is pointed out in the /etc/crontab_files file must follow this structure:
PATH=/usr/bin:/bin
SHELL=/bin/sh
HOME=/
0-59 * * * * /etc/tst_cron.sh
File Description 5.3: /etc/tst_cron.src
This file is called /etc/tst_cron.src, but it could have any other name, since it follows the above structure.
The fourth line of the example file follows this structure: minutes, hours, month day, month, week day and command .
It is possible to specify different tasks to run on different dates and times.
Each command must be on a separated line lines. Find more information about the crontab syntax below:
Crontab Syntax.
A crontab task consists of four date/time fields and a command field.
Every minute cron checks all crontabs for a match between the current date/time and their tasks. If there's a match, the command is executed. The system crontab has an additional field "User" that tells cron with which user id the command should be executed.
The fields are:
• Min - minute of execution, 0-59
• Hour - hour of execution, 0-23
• Mday - day of month of execution, 1-31
• Month - month of execution, 1-12 (or names)
• Wday - day of week of execution, 0-7 (0 or 7 is sunday, or names)
• Command - Anything that can be launched from the command line
Possible values for the fields:
• * - matches all values, e.g. a * in month means: "every month"
• x-y - matches the range x to y, e.g. 2-4 in Mday means "on the
2nd, 3rd, and 4th of the month"
• x/n - in range x with frequency n, e.g. */2 in Hour means "every other hour"
Month also accepts names, e.g. jan, Feb (case insensitive). This does not
156
support ranges, though. Weekdays can also be given as names, e.g. sun,
Mon.
VI Method - Involved parameters and passed values
Example:
In this step by step example we will configure a script named tst_cron.sh to run every minute. This example just explains the necessary steps, because actually all files are already present in the CS by default.
1. Activate the crond daemon in the /etc/crontab_files.
As explained before this file configures which file contains information about which scripts are going to be run. Activate the daemon, by editing the /etc/crontab_files changing the line, like below: active root /etc/tst_cron.src
a.
Edit the /etc/tst_cron.src, to specify which scripts will be executed.
This file must point out all scripts to be executed. It also specifies the periodicity of execution of each script, according to the following syntax:
0-59 * * * * /etc/tst_cron.sh
In this case the tst_cron.sh script will run every minute.
a.
Save the changes.
Execute the following command in to save the configuration:
# saveconf a.
Activate changes.
To activate the changes it is necessary to reboot the CS by issuing the command:
# reboot
BLACK BOX® CS Command Reference Guide
157
5.3 Dual Power Management
The CS comes with two power supplies which it can self-monitor. If either of them fails, two actions are performed: sounding a buzzer and generating a syslog message. This automanagement can be disabled (no actions are taken) or enabled (default), any time by issuing the commands:
# signal_ras buzzer off
# signal_ras buzzer on
To disable the buzzer in boot time, edit the shell script /bin/ex_wdt_led.sh and remove the keyword “buzzer.” The buzzer won’t sound if there is a power failure in any power supply. This parameter does not affect the behavior of the command “signal_ras buzzer on/off.” To make this change effective even after future reboots, create a line with “/bin/ex_wdt_led.sh” in /etc/config_files, save and quit that file and run saveconf.
Note:
NOTE:
This section applies only to the dual power supply model of the
CS.
How to configure
There are no parameters to be configured. However, if you want to generate alarms in case of a power failure, the syslog-ng.conf file must be changed. See the section Generating Alarms.
158
5.4 Syslog-ng
The syslog-ng daemon provides a modern treatment to system messages.
Its basic function is to read and log messages to the system console, log files, other machines (remote syslog servers) and/or users as specified by its configuration file. In addition, syslog-ng is able to filter messages based on their content and to perform an action (e.g. to send an e-mail or pager message). In order to access these functions, the syslog-ng.conf file needs some specific configuration.
The configuration file (default: /etc/syslog-ng/syslog-ng.conf) is read at startup and is reread after reception of a hangup (HUP) signal. When reloading the configuration file, all destination files are closed and reopened as appropriate. The syslog-ng reads from sources (files, TCP/
UDP connections, syslogd clients), filters the messages and takes an action (writes in files, sends snmptrap, pager, e-mail or syslogs to remote servers).
There are five steps required for configuring syslog-ng:
Step 1: Define Global Options.
Step 2: Define Sources.
Step 3: Define Filters.
Step 4: Define Actions (Destinations).
Step 5: Connect all of the above.
These five tasks are going to be explained in this section.
Port Slave Parameters Involved with syslog-ng
•
conf.facility - This value (0-7) is the Local facility sent to the
syslog-ng from PortSlave.
•
conf.DB_facility - This value (0-7) is the local facility sent to the
syslog-ng with data when syslog_buffering and/or alarm is active. When nonzero, the contents of the data buffer are sent to the syslog-ng every time a quantity of data equal to this parameter is collected. The syslog level for data buffering is hard coded to level five (notice) and facility local[0+ conf.DB_facility]. The file /etc/syslog-ng/syslog-ng.conf should be set accordingly for the syslog-ng to take some action.
Example value: 0.
•
all.syslog_buffering - When nonzero, the contents of the data
buffer are sent to the syslog-ng every time a quantity of data equal to this parameter is collected. The syslog message is sent
BLACK BOX® CS Command Reference Guide
159
to syslog-ng with NOTICE level and
LOCAL[0+conf.DB_facility] facility.
The Syslog Functions
This section shows the characteristics of the syslog-ng that is implemented for all members of the CS family. It is divided into three parts:
1. Syslog-ng and its Configuration
2. Syslog-ng Configuration to use with Syslog Buffering Feature
3. Syslog-ng Configuration to use with Multiple Remote Syslog Servers
Syslog-ng and its Configuration
The five steps previously mentioned are detailed below.
1. Specify Global Options.
You can specify several global options to syslog-ng in the options statement: options { opt1(params); opt2(params); ... }; where optN can be any of the following:
Table 5-1: “Global Options” parameters (Syslog-ng configuration)
Option Description
time_reopen(n) The time to wait before a dead connection is reestablished.
time_reap(n) The time to wait before an idle destination file is closed.
sync_freq(n) mark_freq(n)
The number of lines buffered before written to file. (The file is synced when this number of messages has been written to it.)
The number of seconds between two MARKS lines.
log_fifo_size(n) The number of lines fitting to the output queue.
chain_hostname
(yes/no) or long_hostname
(yes/no)
Enable/disable the chained hostname format.
use_time_recvd
(yes/no)
Use the time a message is received instead of the one specified in the message.
160
Table 5-1: “Global Options” parameters (Syslog-ng configuration)
Option Description
use_dns (yes/ no) gc_idle_threshold( n) gc_busy_threshold( n) create_dirs(yes/ no) owner(name)
Enable or disable DNS usage. syslog-ng blocks on DNS queries, so enabling DNS may lead to a Denial of Service attach.
Sets the threshold value for the garbage collector, when syslog-ng is idle. GC phase starts when the number of allocated objects reach this number. Default: 100.
Sets the threshold value for the garbage collector. When syslog-ng is busy, GC phase starts.
Enable the creation of new directories.
group(name) perm(mask)
Set the owner of the created file to the one specified.
Default: root.
Set the group of the created file to the one specified.
Default: root.
Set the permission mask of the created file to the one specified. Default: 0600.
a.
Define sources.
To define sources use this statement: source <identifier> { source-driver([params]); source driver([params]);
...}; where:
•
identifier - Has to uniquely identify this given source.
•
source-driver - Is a method of getting a given message.
•
params - Each source-driver may take parameters. Some of
them are required, some of them are optional.
The following source-drivers are available:
Table 5-2: “Source Drivers” parameters (Syslog-ng configuration)
Option Description
internal() Messages are generated internally in syslog-ng.
BLACK BOX® CS Command Reference Guide
161
Table 5-2: “Source Drivers” parameters (Syslog-ng configuration)
Option Description
unix-stream
(filename
[options]) and unix-dgram
(filename
[options])
They open the given AF_UNIX socket, and start listening for messages.
Options: owner(name), group(name), perm(mask) are equal global options keep-alive(yes/no) - Selects whether to keep connections opened when syslog-ng is restarted. Can be used only with unix_stream. Default: yes max-connections(n) - Limits the number of simultaneously opened connections. Can be used only with unix_stream. Default: 10.
tcp([options]) and udp([options])
These drivers let you receive messages from the network, and as the name of the drivers show, you can use both
TCP and UDP.
None of tcp() and udp() drivers require positional parameters. By default they bind to 0.0.0.0:514, which means that syslog-ng will listen on all available interfaces.
Options: ip(<ip address>) - The IP address to bind to. Default:
0.0.0.0.
port(<number>) - UDP/TCP port used to listen messages.
Default: 514.
max-connections(n) - Limits the number of simultaneously opened connections. Default: 10.
file(filename) Opens the specified file and reads messages.
pipe(filename) Opens a named pipe with the specified name, and listens for messages. (You'll need to create the pipe using mkfifo command).
Some Examples of Defining Sources:
1) To read from a file:
source <identifier> {file(filename);};
Example to read messages from “/temp/file1” file:
162
source file1 {file(‘/temp/file1’);};
Example to receive messages from the kernel: source s_kernel { file(‘/proc/kmsg’); };
2) To receive messages from local syslogd clients:
source sysl {unix-stream(‘/dev/log’);};
3) To receive messages from remote syslogd clients:
source s_udp { udp(ip(<cliente ip>) port(<udp port>)); };
Example to listen to messages from all machines on UDP port 514: source s_udp { udp(ip(0.0.0.0) port(514));};
Example to listen to messages from one client (IP address=10.0.0.1) on UDP port 999: source s_udp_10 { udp(ip(10.0.0.1) port(999)); }; a.
Define filters.
To define filters use this statement: filter <identifier> { expression; }; where:
• identifier - Has to uniquely identify this given filter.
• expression - Boolean expression using internal functions, which has to evaluate to true for the message to pass.
The following internal functions are available:
Table 5-3: “Filters” parameters (Syslog-ng configuration)
Option Description
facility
(<facility code>) level(<level code>) or priority
(<level code>)
Selects messages based on their facility code.
Selects messages based on their priority.
BLACK BOX® CS Command Reference Guide
163
Table 5-3: “Filters” parameters (Syslog-ng configuration)
Option Description
) program(<string>) match(<string>
Tries to match the <string> to the program name field of the log message.
host(<string>) Tries to match the <string> to the hostname field of the log message.
Tries to match the <string> to the message itself.
Some Examples of Defining Filters:
1) To filter by facility:
filter f_facilty { facility(<facility name>); };
Examples: filter f_daemon { facility(daemon); }; filter f_kern { facility(kern); }; filter f_debug { not facility(auth, authpriv, news, mail); };
2) To filter by level:
filter f_level { level(<level name>);};
Examples: filter f_messages { level(info .. warn)}; filter f_emergency { level(emerg); }; filter f_alert { level(alert); };
3) To filter by matching one string in the received message:
filter f_match { match(‘string’); };
Example to filter by matching the string “named”: filter f_named { match(‘named’); };
4) To filter ALARM messages (note that the following three examples should be one line):
164
filter f_alarm { facility(local[0+<conf.DB_facility>]) and level(info) and match('ALARM') and match('<your string>'); } ;
Example to filter ALARM message with the string “kernel panic”: filter f_kpanic { facility(local[0+<conf.DB_facility>]) and level(info) and match('ALARM') and match('kernel panic'); };
Example to filter ALARM message with the string “root login”: filter f_root { facility(local[0+<conf.DB_facility>]) and level(info) and match('ALARM') and match('root login'); };
5) To eliminate SSHD debug messages:
filter f_sshd_debug { not program('sshd') or not level(debug); };
6) To filter the syslog_buffering:
filter f_syslog_buf { facility(local[0+<conf.DB_facility>]) and level(notice); }; a.
Define Actions.
To define actions use this statement (note that the statement should be one line): destination <identifier> {destination-driver([params]); destinationdriver([param]);..}; where:
•
identifier - Has to uniquely identify this given destination.
•
destination driver - Is a method of outputting a given message.
•
params - Each destination-driver may take parameters. Some of
them required, some of them are optional.
BLACK BOX® CS Command Reference Guide
165
configuration)
The following destination drivers are available:
Table 5-4: “Destination Drivers” parameters (Syslog-ng
Option Description
file
(filename[options])
This is one of the most important destination drivers in syslog-ng. It allows you to output log messages to the named file. The destination filename may include macros (by prefixing the macro name with a '$' sign) which gets expanded when the message is written. Since the state of each created file must be tracked by syslog-ng, it consumes some memory for each file. If no new messages are written to a file within 60 seconds (controlled by the time_reap global option), it's closed, and its state is freed.
166
configuration)
Table 5-4: “Destination Drivers” parameters (Syslog-ng
Option Description
file
(filename[options])
continuation...
Available macros in filename expansion:
•
HOST - The name of the source host where the message originated from.
•
FACILITY - The name of the facility the message is tagged as coming from.
•
PRIORITY or LEVEL - The priority of the message.
•
PROGRAM - The name of the program the message was sent by.
•
YEAR, MONTH, DAY, HOUR, MIN, SEC - The year, month, day, hour, min, sec of the message was sent.
•
TAG - Equals FACILITY/LEVEL.
•
FULLHOST - The name of the source host and the sourcedriver:
•
<source-driver>@<hostname>
•
MSG or MESSAGE - The message received.
FULLDATE - The date of the message was sent.
pipe
(filename[options]) unix-stream(filename) and unixdgram(filename)
Available options:
•
log_fifo_size(number) - The number of entries in the output file.
•
sync_freq(number) - The file is synced when this number of messages has been written to it.
•
owner(name), group(name), perm(mask) - Equals global options.
•
template(“string”) - Syslog-ng writes the “string” in the file.
You can use the MACROS in the string.
•
encrypt(yes/no) - Encrypts the resulting file.
•
compress(yes/no) - Compresses the resulting file using zlib.
This driver sends messages to a named pipe. Available options: owner(name), group(name), perm(mask) - Equals global options.
template(“string”) - Syslog-ng writes the “string” in the file. You can use the MACROS in the string.
This driver sends messages to a UNIX socket in either
SOCKET_STREAM or SOCK_DGRAM mode.
BLACK BOX® CS Command Reference Guide
167
configuration)
Table 5-4: “Destination Drivers” parameters (Syslog-ng
Option Description
udp("<ip address>" port(number);) and tcp("<ip address>" port(number);) program(<program name and arguments>) usertty(<username>)
This driver sends messages to another host (ip address/ port) using either UDP or TCP protocol.
This driver fork()'s executes the given program with the arguments and sends messages down to the stdin of the child.
This driver writes messages to the terminal of a loggedin username.
Some examples of defining actions:
1) To send e-mail:
destination <ident> { pipe(‘/dev/cyc_alarm’ template(‘sendmail
<pars>’));}; where ident: uniquely identifies this destination. Parameters:
•
-t <name>[,<name>] - To address
•
[-c <name>[,<name>]] - CC address
•
[-b <name>[,<name>]] - Bcc address
•
[-r <name>[,<name>]] - Reply-to address
•
-f <name> - From address
•
-s \"<text>\" - Subject
•
-m \”<text message>\” - Message
•
-h <IP address or name> - SMTP server
•
[-p <port>] - Port used. default:25
To mount the message, use this macro:
•
$FULLDATE - The complete date when the message was sent.
•
$FACILITY - The facility of the message.
•
$PRIORITY or $LEVEL - The priority of the message.
168
•
$PROGRAM - The message was sent by this program (BUFF-
ERING or SOCK).
•
$HOST - The name of the source host.
•
$FULLHOST - The name of the source host and the source
driver. Format: <source>@<hostname>
•
$MSG or $MESSAGE - The message received.
Example to send e-mail to [email protected] (SMTP's IP address 10.0.0.2) from the e-mail address [email protected] with subject “ALARM”. The message will carry the current date, the host-name of this CS and the message that was received from the source. destination d_mail1 { pipe('/dev/cyc_alarm' template('sendmail -t [email protected] -f [email protected] -s \”ALARM\” \\
-m \'$FULLDATE $HOST $MSG\' -h 10.0.0.2'));
};
File Description 5.4: Send e-mail example
2) To send to pager server (sms server):
destination <ident> {pipe(‘/dev/cyc_alarm’ template(‘sendsms
<pars>’));}; where ident: uniquely identify this destination
• pars: -d <mobile phone number>
• -m \’<message - max.size 160 characters>\’
• -u <username to login on sms server>
• -p <port sms - default : 6701>
• <server IP address or name>
Example to send a pager to phone number 123 (Pager server at 10.0.0.1) with message carrying the current date, the hostname of this CS and the message that was received from the source: destination d_pager { pipe(‘/dev/cyc_alarm’ template(‘sendsms -d 123 -m \’$FULLDATE $HOST $MSG\’ 10.0.0.1’));
};
File Description 5.5: To send a pager phone example
3) To send snmptrap.
BLACK BOX® CS Command Reference Guide
169
destination <ident> {pipe(‘/dev/cyc_alarm’ template(‘snmptrap <pars>’));
}; where ident : uniquely identify this destination
• pars : -v 1
• <snmptrapd IP address>
• -c public : community
• \"\" : enterprise-oid
• \"\" : agent/hostname
• <trap number> : 2-Link Down, 3-Link Up, 4-Authentication
Failure
• 0 : specific trap
• \"\" : host-uptime
• .1.3.6.1.2.1.2.2.1.2.1 :interfaces.iftable.ifentry.ifdescr.1
• s : the type of the next field (it is a string)
• \"<message - max. size 250 characters>\"
Example to send a Link Down trap to server at 10.0.0.1 with message carrying the current date, the hostname of this CS and the message that was received from the source: destination d_trap { pipe("/dev/cyc_alarm" template("snmptrap -v 1 -c public 10.0.0.1 public \"\" \"\" 2 0 \"\" \\
.1.3.6.1.2.1.2.2.1.2.1 s \"$FULLDATE $HOST $MSG\" "));
};
File Description 5.6: Sending a link down trap
4) To write in file :
destination d_file { file(<filename>);};
Example send message to console : destination d_console { file("/dev/ttyS0");};
File Description 5.7: Sending messages to console
170
Example to write a message in /var/log/messages file: destination d_message { file("/var/log/messages"); };
File Description 5.8: Writing messages to file
5) To write messages to the session of a logged-in user:
destination d_user { usertty("<username>"); };
Example to send message to all sessions with root user logged: destination d_userroot { usertty("root"); };
File Description 5.9: Sending messages to logged user
6) To send a message to a remote syslogd server:
destination d_udp { udp("<remote IP address>" port(514)); };
Example to send syslogs to syslogd located at 10.0.0.1 : destination d_udp1 { udp("10.0.0.1" port(514)); };
File Description 5.10: Sending syslogs to a remote server
Connect all of the above.
a.
To connect the sources, filters, and actions, use the following statement. (Actions would be any message coming from one of the listed sources. A match for each of the filters is sent to the listed destinations.) log { source(S1); source(S2); ... filter(F1);filter(F2);... destination(D1); destination(D2);...
}; where :
• Sx - Identifier of the sources defined before.
• Fx - Identifier of the filters defined before.
• Dx - Identifier of the actions/destinations defined before.
Examples connecting sources, filters and actions:
1) To send all messages received from local syslog clients to console:
BLACK BOX® CS Command Reference Guide
171
log { source(sysl); destination(d_console);};
2) To send only messages with level alert and received from local syslog clients to all logged root user:
log { source(sysl); filter(f_alert); destination(d_userroot); };
3) To write all messages with levels info, notice, or warning and received from
syslog clients (local and remote) to /var/log/messages file: log { source(sysl); source(s_udp); filter(f_messages); destination(d_messages); };
4) To send e-mail if message received from local syslog client has the string
“kernel panic”:
log { source(sysl); filter(f_kpanic); destination(d_mail1); };
5) To send e-mail and pager if message received from local syslog client has the string “root login”:
log { source(sysl); filter(f_root); destination(d_mail1); destination(d_pager);
};
6) To send messages with facility kernel and received from syslog clients (local and remote) to remote syslogd:
log { source(sysl); source(s_udp); filter(f_kern); destination(d-udp1);
};
Syslog-ng configuration to use with Syslog buffering feature
This configuration example uses the syslog buffering feature, and sends messages to the remote syslogd (10.0.0.1).
VI Method
1. Configure /etc/portslave/pslave.conf file parameters.
In the pslave.conf file the parameters of the syslog buffering feature are configured as: conf.DB_facility 1 all.syslog_buffering 100
File Description 5.11: portslave.conf necessary configuration
172
a.
Add lines to /etc/syslog-ng/syslog-ng.conf file.
Add the following lines by vi to the file:
#local syslog clients source src { unix-stream("/dev/log"); }; destination d_buffering { udp("10.0.0.1"); }; filter f_buffering { facility(local1) and level(notice); };
#send only syslog_buffering messages to remote server log { source(src); filter(f_buffering); destination(d_buffering); };
File Description 5.12: portslave.conf necessary configuration
Syslog-ng configuration to use with multiple remote Syslog servers
This configuration example is used with multiple remote syslog servers.
VI Method
1. Configure pslave.conf parameters.
In the pslave.conf file the facility parameter is configured as: conf.facility 1
File Description 5.13: portslave.conf “facility” configuration
BLACK BOX® CS Command Reference Guide
173
a.
Add lines to /etc/syslog-ng/syslog-ng.conf file.
# local syslog clients source src { unix-stream("/dev/log"); };
# remote server 1 - IP address 10.0.0.1 port default destination d_udp1 { udp("10.0.0.1"); };
# remote server 2 - IP address 10.0.0.2 port 1999 destination d_udp2 { udp("10.0.0.2" port(1999););};
# filter messages from facility local1 and level info to warning filter f_local1 { facility(local1) and level(info..warn);};
# filter messages from facility local 1 and level err to alert filter f_critic { facility(local1) and level(err .. alert);};
# send info, notice and warning messages to remote server udp1 log { source(src); filter(f_local1); destination(d_udp1); };
# send error, critical and alert messages to remote server udp2 log { source(src); filter(f_critic); destination(d_udp2); };
File Description 5.14: syslog-ng.conf configuration
CLI Method - Syslog
You can configure Syslog by following the steps below:
1. Open the CLI interface by issuing the command:
# CLI a.
Configure the syslog facility number.
This is the facility number for the messages. The remote Syslog server filters received messages according to this parameter.
cli>config network syslog facility <local0-local7>
Possible values for it ranges from local0 - local7 a.
Set up the server IP address to where syslog messages will be sent
.
In this example the server will have the fictitious IP address 200.200.200.1.
cli>config network syslog add server 200.200.200.1
You can repeat this step as many times as necessary, depending on the quantity of remote servers you want to add.
174
a.
Activate the configuration.
cli> config runconfig a.
Save the configuration.
cli> config savetoflash a.
Exit the CLI mode.
To exit the CLI mode and return to CS ’s shell, issue the command: cli> quit
BLACK BOX® CS Command Reference Guide
175
5.5 How Syslog Messages are generated
The CS can generate syslog messages, which enable system administrators to monitor changes in the box. When certain actions/ conditions are met through the web interface as well as through CLI or commands which users enter from a shell prompt, the system generates and sends messages to the syslog-ng file.
The messages use the following format:
•
Level
- the syslog level used
•
Tag
- a fixed string used by the user to create filters
•
Text
- the text that contains the condition or action.
Generated Syslog Messages
The syslog messages are generated as a result of specific actions or conditions are as follows:
CS
generates syslog messages when the following conditions are met: info info info info info info info info info
Table 5-5: CS Syslog Messages Format
Level Tag info [PMD]-Serial
Port p info AUTH
AUTH
AUTH
AUTH
CONFIG
CONFIG
CONFIG
CONFIG
CONFIG
CONFIG
Text
One or more IPDUs were added to the chain.
This chain has now X IPDUs and Y outlets
User [xyz] for session [abc] successfully authenticated
User [xyz] for session [abc] logged out
Cancel new admin [abc] login
Session [%d] timed out", sid
Configuration saved to flash
New configuration activated
Password changed for user [xyz] by user [abc]
User [xyz] added by user [abc]
User [xyz] deleted by user [abc]
Network daemon [daemon name] stopped
176
Table 5-5: CS Syslog Messages Format
Level Tag info APPLICA-
TION info info
APPLICA-
TION
APPLICA-
TION alert alert alert
[PMD]-Serial
Port p
[PMD]-Serial
Port p
[PMD]-Serial
Port p alert alert alert alert alert alert alert alert
[PMD]-Serial
Port p
AUTH
AUTH
AUTH
CONFIG
SYSTEM
PORT DCD
PORT DCD debug AUTH
Text
User [abc] connected to port [x] (ttySx) via socket server
User [abc] connected to port [x] (ttySx) via socket ssh
User [abc] connected to port [x] (ttySx) via socket ssh
Outlet X has been turned OFF by user <username>
Outlet X has been turned ON by user <username>
OVER CURRENT on IPDU #X (current: <current detected> threshold:<threshold configured>)
One or more IPDUs were removed from the chain. This chain has now X IPDUs and Y outlets
User [xyz] login failed
User [%s] login failed. There exists another admin session
Previous admin session terminated by new admin [abc] login
Network daemon [daemon name] started
System rebooted by admin [xyz] [hostname] [ip address]
Port <serial port number> DCD went high
Port <serial port number> DCD went low
User [%s] login failed. Group 'admin' does not exist
BLACK BOX® CS Command Reference Guide
177
notice [PMD]-Serial notice warning
Port p notice DAEMON notice DAEMON
DAEMON
[PMD]-Serial
Port p
Table 5-5: CS Syslog Messages Format
Level Tag debug AUTH
Text
User [%s] login failed. Maximum number of connected users reached
PMD has started on this port. The chain has X
IPDUs and W outlets.
Web server started on port xx
Web server stopped
Caught SIGINT: Web server stopped
Current is now back to normal on IPDU #X (current: <current detected> threshold:<threshold configured>)
Note:
NOTE ABOUT PMD SYSLOG MESSAGES:
To not generate PMD syslog messages, the file "/etc/pmd.sh" has to be edited. The parameter DPARM must be changed from "" to "-s". After this, the command “saveconf" and
"daemon restart PMD" must be run.
You can use the information provided in the table above to create filters and generate alarms about events that happens in the CS itself. More about this issue will be approached in the next section of this chapter.
DCD ON/OFF Syslog messages
The CS can generate an alert when a serial console cable is removed from the console server or the server/network equipment attached to the console is powered down. Also if a modem is in use then to detected if the modem is still powered on and active.
The DCD signal will be monitored and a syslog message will be generated whenever the state of the signal changes. The syslog message can be handled by syslog-ng to generate an event notification.
How to configure
The necessary steps to enable syslog messages generation in the CS will be described below:
1. Open the /etc/portslave/pslave.conf file.
178
# vi /etc/portslave/pslave.conf
a.
Set the all.dcd or sXX.dcd parameter to 1 in the /etc/portslave/
pslave.conf file.
all.dcd 1 or sXX.dcd 1
Where XX is the desired port number.
a.
Configure the syslog-ng.conf file to monitor DCD status.
a.
Save the configuration.
# saveconf
The source for all generated Syslog messages are “src_dev_log”, the only exceptions are Syslog messages generated when DCD goes on/off, that is
“s_kernel”. You can follow the table on
page 176
trigger alarms.
Examples
To configure the examples given below edit the /etc/syslog-ng/syslog-
ng.conf and add the presented lines.
Generating Syslog messages to be sent to console, when the user root tries to connect together with an already logged root user.
filter f_info { level(info); }; filter f_named { match("AUTH"); }; destination console { usertty("root"); }; log { source(src_dev_log); filter(f_info, f_named); destination(console);
};
Generating messages and sending them to console when any user login attempt fails.
filter f_info { level(alert); }; filter f_named { match("AUTH"); }; destination console { usertty("root"); }; log { source(src_dev_log); filter(f_info, f_named); destination(console);
};
BLACK BOX® CS Command Reference Guide
179
Generating messages and sending them to console if the DCD signal changes its state.
filter f_dcdchg { level(alert) and match("PORT DCD") }; destination console { usertty("root"); }; log { source(s_kernel); filter(f_dcdchg); destination(console); };
180
5.6 Generating Alarms (Syslog-ng)
This feature helps the administrator to manage the servers. It filters the messages received by the serial port (the server’s console) based on the contents of the messages. It then performs an action, such as sending an email or pager message. To configure this feature, you need to configure filters and actions in the
syslog-ng.conf file. (You can read more about syslog-ng in the
Syslog-ng
section.)
How to configure
Alarm generation is strictly related to the syslog-ng configuration. It is highly recommended to read the
Syslog-ng
section before configuring this
feature. This section will show practical examples of utilization of this feature.
The /etc/portslave.conf related parameters are:
• conf.DB_facility - This value (0-7) is the Local facility sent to the syslog-ng with data when syslog_buffering and/or alarm is active.
• all.alarm - When nonzero, all data received from the port is captured and sent to syslog-ng with INFO level and
LOCAL[0+conf.DB_facility] facility. This parameter must be set to a non zero value to activate alarm generation.
The syslog-ng reads from sources (files, TCP/UDP connections, syslogd clients), filters the messages and takes an action (writes in files, sends snmptrap, pager, email or syslogs).
Basically, alarms are triggered by a combination of sources, filters and destinations. To connect the sources, filters and actions (any message coming from one of the listed sources, matching the filters (each of them) is sent to the listed destinations). Use this statement: log { source(S1); source(S2); ...
filter(F1);filter(F2);...
destination(D1); Destination(D2);...
};
For more information about sources, destinations and filters, please refer
Syslog-ng
BLACK BOX® CS Command Reference Guide
181
VI method - Configuration to use with Alarm Feature
This configuration example is used for the alarm feature.
1. Configure the /etc/portslave/pslave.conf file parameter.
In the /etc/portslave/pslave.conf file the parameters of the alarm feature are configured as: all.alarm 1 conf.DB_facility 2 a.
Configure the /etc/syslog-ng/syslog-ng.conf. file:
This step has the objective to configure the /etc/syslog-ng/syslog-ng.conf file. Several examples will be given here. All commands are present (commented) in the original syslog-
ng.conf file by default. Choose the example that best fits to your application.
Example 1 - To send all messages received from local syslog clients to console.
Insert the lines below at the END of the file syslog-ng.conf file, keeping all lines above commented. source sysl {unix-stream("/dev/log");}; destination d_console { file("/dev/ttyS0");}; log { source(sysl); destination(d_console);};
File Description 5.15: part of the /etc/syslog-ng/syslog-ng.conf file
Example 2 - To send only messages with level alert and received from local syslog clients to all logged root user.
Insert the lines below at the END of the file
syslog-ng.conf file, keeping all lines above commented. source sysl {unix-stream("/dev/log");}; filter f_alert { level(alert); }; destination d_userroot { usertty("root"); }; log { source(sysl); filter(f_alert); destination(d_userroot); };
File Description 5.16: part of the /etc/syslog-ng/syslog-ng.conf file
182
Example 3 - Write all messages with levels info, notice or warning and
received from syslog clients (local and remote) to /var/log/ messages file :
Insert the lines below at the END of the file syslog-ng.conf file, keeping all lines above commented. source sysl {unix-stream("/dev/log");}; source s_udp { udp(ip(<ip client>) port(<udp port>)); }; filter f_messages { level(info..warn);}; destination d_message { file("/var/log/messages"); }; log { source(sysl); source(s_udp); filter(f_messages); destination(d_messages);};
File Description 5.17: part of the /etc/syslog-ng/syslog-ng.conf file
Example 4 - Send e-mail if message received from local syslog client has the string "kernel panic".
Insert the lines below at the END of the file syslog-ng.conf file, keeping all lines above commented.
source sysl {unix-stream("/dev/log");}; filter f_kpanic{facility(local1) and level(info) and match("ALARM") and match("kernel panic");}; destination d_mail1 { pipe("/dev/cyc_alarm" template("sendmail -t [email protected] -f [email protected] -s \"ALARM\" \\
-m \"$FULLDATE $HOST $MSG\" -h 10.0.0.2"));
}; log { source(sysl); filter(f_kpanic); destination(d_mail1); };
File Description 5.18: part of the /etc/syslog-ng/syslog-ng.conf file
Example 5 - Send e-mail and pager if message received from local syslog client has the string "root login".
Insert the lines below at the END of the file syslog-ng.conf file, keeping all lines above commented.
source sysl {unix-stream("/dev/log");}; filter f_root {facility(local1) and level(info) and match("ALARM") and match("root login");}; destination d_mail1 { pipe("/dev/cyc_alarm" template("sendmail -t [email protected] -f [email protected] -s \"ALARM\" \\
-m \"$FULLDATE $HOST $MSG\" -h 10.0.0.2"));
}; destination d_pager { pipe("/dev/cyc_alarm" template("sendsms -d 123 -m \"$FULLDATE $HOST $MSG\" 10.0.0.1"));
}; log { source(sysl); filter(f_root); destination(d_mail1); destination(d_pager); };
File Description 5.19: part of the /etc/syslog-ng/syslog-ng.conf file
BLACK BOX® CS Command Reference Guide
183
Example 6 - Send messages with facility kernel and received from syslog clients (local and remote) to remote syslogd.
Insert the lines below at the END of the file syslog-ng.conf file, keeping all lines above commented.
source sysl {unix-stream("/dev/log");}; source s_udp { udp(ip(<ip client>) port(<udp port>)); }; filter f_kern { facility(kern); }; destination d_udp1 { udp("10.0.0.1" port(514)); }; log { source(sysl); source(s_udp); filter(f_kern); destination(d-udp1); };
File Description 5.20: part of the /etc/syslog-ng/syslog-ng.conf file
a.
Activate changes.
To activate the changes made, run the following commands in the presented order:
# runconf
# killall syslog-ng
# syslog-ng
The first command activate the changes made in the /etc/portslave/pslave.conf file. The second and the third commands activate the changes made in the /etc/syslog-ng/syslog-
ng.conf file.
a.
Save the changes to the flash memory.
To save the changes made, run the command:
# saveconf
CLI Method - Alarm Notification
The CLI interface allows the configuration of alarm notifications when is an event is generated in any port of the CS . Generating alarms for the CS itself is not customizable using the CLI interface.
Into the CLI interface all options are under the following menu: cli> config administration notifications
There you’ll have the options:
• addemail
- Sends a message to the configured e-mail address if the defined string appears.
• addpager
- Sends a message to the configured pager if the defined string appears.
• addsnmptrap
- Sends a snmp trap to the configured server if the defined string appears.
184
• alarm
- Activates/Deactivates the alarm feature. If you don't enable it, syslog messages won’t be generated when there is incoming data from the ports.
• delete
- Deletes any previously configured string.
• edit
- Edit any previously configured string.
Example:
The below example will configure the CS to send an e-mail every time root user logs into a server connected to the a port. We will configure the trigger string as “root login”. Note that the server connected to the CS must be properly configured to send Syslog messages.
1. Open the CLI interface by issuing the command:
# CLI a.
Enable Alarm Notification.
You need to enable this option, otherwise messages received in the ports will be ignored and not treated by Syslog-ng.
cli> config administration notifications alarm yes a.
Add the trigger string.
Here you need to configure what string will trigger the e-mail notification. In our case it will be “root login”.
cli> config administration notifications addemail "root login" a.
Configure the necessary parameters.
For sending an e-mail the following parameters need to be configured: add Email>body "Testing configuration" add Email>from CS add Email>to [email protected]
add Email>smtpserver 200.200.200.2
add Email>smtpport 25 add Email>subject "Testing Config"
The above commands configure the from/to fields, SMTP server/port and the subject/body of the e-mail message.
a.
Activate the configuration.
cli> config runconfig a.
Save the configuration.
cli> config savetoflash a.
Exit the CLI mode.
BLACK BOX® CS Command Reference Guide
185
To exit the CLI mode and return to CS ’s shell, issue the command: cli> quit
186
5.7 Terminal Appearance
You can change the format of the login prompt and banner that is issued when a connection is made to the system. Prompt and banner appearance can be port-specific as well.
configuration
VI Method - Involved parameters and passed values
Terminal Appearance involves the following parameters in the /etc/
portslave/pslave.conf file:
Table 5-6: pslave.conf parameters for Terminal Appearance
Parameter Description
all.prompt
all.issue
all.lf_suppress
all.auto_answer_in
put
This text defines the format of the login prompt. Expansion characters can be used here. Example value: %h login:
This text determines the format of the login banner that is issued when a connection is made to the CS.
\n represents a new line and \r represents a carriage return. Expansion characters can be used here.
Value for this Example:
\r\n\
Welcome to terminal server %h port S%p
\n\
\r\n
This activates line feed suppression. When configured as
0, line feed suppression will not be performed. When 1, extra line feed will be suppressed.
This parameter is used in conjunction with the next parameter, auto_answer_output. If configured and if there is no session established to the port, this parameter will constantly be compared and matched up to the string of bytes coming in remotely from the server. If a match is found, the string configured in auto_answer_output is sent back to the server. To represent the ESC character as part of this string, use the control character, ^[.
BLACK BOX® CS Command Reference Guide
187
configuration
Table 5-6: pslave.conf parameters for Terminal Appearance
Parameter Description
all.auto_answer_out
put
This parameter is used in conjunction with the previous parameter, auto_answer_input. If configured, and if there is no session established to the port, this parameter is sent back to the server when there is a match between the incoming data and auto_answer_input. To represent the ESC character as part of this string, use the control character, ^[.
CLI Method - Banner
To configure certain parameters for a specific serial port:
1. Open the CLI interface by issuing the command:
# CLI a.
Configure the desired banner.
The command below will configure “testing banner” as the default banner for all ports. cli> config physicalports all other banner “testing banner”
You can configure different banners for different ports, all you have to do is to change the ALL parameter to the desired port number or port range. Eg. 1 or 1-3 (from port 1 to 3).
a.
Activate the configuration.
cli> config runconfig a.
Save the configuration.
cli> config savetoflash a.
Exit the CLI mode.
To exit the CLI mode and return to CS ’s shell, issue the command: cli> quit
188
5.8 Centralized Management
The CS allows centralized management through the use of a Master
pslave.conf file. Administrators should consider this approach to configure multiple CS . Using this feature, each unit has a simplified
pslave.conf file where a Master include file is cited. This common configuration file contains information for all units, properly divided in separate sections, and would be stored on one central server. This file, in our example shown in the following figure, is /etc/portslave/
TScommon.conf. It must be downloaded to each CS .
Note:
NOTE:
Centralized management can mean one big configuration file (the common file) that is placed in a management host. This same file would be downloaded into all
CS
boxes (each of those boxes would include a tiny config file and that big common file). In this application, there may or may not be clustering involved. The user may want to access each box individually, without passing through la central point (master), using the common file just to make his/her life easier in regard to maintain the config file. This user could ALSO add the clustering application on a daily basis. Clustering does NOT require a common config file. A common config file does NOT apply to clustering, however, common config files can be used in an integrated manner.
Figure 5.21 - Example of Centralized Management
VI Method - Involved parameters and passed values
The abbreviated /etc/portslave/pslave.conf and /etc/hostname files in each unit, for the above example are:
BLACK BOX® CS Command Reference Guide
189
Unit 1 configuration:
For the /etc/hostname file in unit 1: unit1
File Description 5.22: Unit 1 /etc/hostname file
For the /etc/portslave/plsave.conf file in unit 1: conf.eth_ip 10.0.0.1
conf.eth_mask 255.0.0.0
conf.include /etc/portslave/TScommon.conf
File Description 5.23: Unit 1 /etc/portslave/portslave.conf file configuration
Unit 2 configuration:
For the /etc/hostname file in unit 2: unit2
File Description 5.24: Unit 2 /etc/hostname file
For the /etc/portslave/plsave.conf file in unit 2: conf.eth_ip 10.0.0.2
conf.eth_mask 255.0.0.0
conf.include /etc/portslave/TScommon.conf
File Description 5.25: Unit 2 /etc/portslave/portslave.conf file configuration
Unit 3 configuration:
For the /etc/hostname file in unit 3: unit3
File Description 5.26: Unit 3 /etc/hostname file
190
For the /etc/portslave/plsave.conf file in unit 3: conf.eth_ip 10.0.0.3
conf.eth_mask 255.0.0.0
conf.include /etc/portslave/TScommon.conf
File Description 5.27: Unit 3 /etc/portslave/portslave.conf file configuration
The common include file (located in the server) for the example is:
all.authtype none all.protocol socket_server conf.host_config unit1 all.socket_port 7001+ s1.tty ttyS1 s2.tty ttyS2
...
s16.tty ttyS16 s17.tty 20.20.20.3:7033 s18.tty 20.20.20.3:7034
...
conf.host_config unit2 all.socket_port 7033+ s1.tty ttyS1 s2.tty ttyS2
...
sN.tty ttySN conf.host_config unit3 all.socket_port 7301+ s1.tty ttyS1 s2.tty ttyS2
...
sN.tty ttySN conf.host_config end
File Description 5.28: Common /etc/portslave/pslave.conf file
When this file is included, unit1 would read only the information between
conf.host_config unit1 and conf.host_config unit2. Unit2 would use only the information between conf.host_config unit2 and conf.host_config
unit3 and unit3 would use information after conf.host_config unit3 and before conf.host_config end.
BLACK BOX® CS Command Reference Guide
191
Steps for using Centralized Configuration
1. Create and save the /etc/portslave/pslave.conf and /etc/hostname files in each CS .
a.
Create, save, and download the common configuration.
Create and save the common configuration file on the server, then download it (probably using scp) to each unit. Make sure to put it in the directory set in the pslave.conf file (/etc/
portslave in the example).
a.
Execute the command runconf
on each unit.
a.
Test each unit.
If everything works, add the line /etc/portslave/TScommon.conf to the /etc/config_files file.
a.
Save the file and close it. a.
Execute the saveconf command.
Note:
NOTE:
The included file /etc/portslave/TScommon.conf cannot contain another include file (i.e., the parameter conf.include must not be defined).
Also, <max ports of CS > + N(+) is done same way as serial port.
192
5.9 Date, Time and Timezone
To adjust the date and time use the date command. Timezone is configured using the CLI utility, or the set_timezone script.
Note: Setting the system timezone creates a new file called
/etc/localtime
, which erases the
/etc/TIMEZONE
.
Date and Time
The date command prints or sets the system date and time.
date MMDDhhmmYYYY where:
• MM = month
• DD = day
• hh = hour
• mm = minute
• YYYY = year
For example:
date 101014452002 displays:
Thu Oct 10 14:45:00 <timezone> 2002
Note: The time zone is configured using the CLI utility or set_timezone script.
CLI Method - Date and Time
Configuring date and time using CLI automatically disables any previously configured NTP server.
To configure date/time using the CLI:
1. Open the CLI interface by issuing the command:
# CLI
2. Configuring the date.
The date format must follow this syntax: mm/dd/yyyy, where:
BLACK BOX® CS Command Reference Guide
193
• mm - Month
• dd - Day
• yyyy - Year
The following example configures the date, December, 31st 2005.
cli> config administration date/time date 12/31/2005
3. Setting the time.
The time format must follow this syntax: hh:mm:ss, where:
• hh - hour
• mm - minutes
• ss - seconds
The following example configures the time, nine o’clock AM: cli> config administration date/time time 09:00:00
4. Activate the configuration.
cli> config runconfig
5. Save the configuration.
cli> config savetoflash
6. Exit the CLI mode.
To exit the CLI mode and return to CS ’s shell, issue the command: cli> quit
Setting Local Timezone
You can set the time to your local timzone using the set_timezone command or the CLI utility. The system uses GMT (Greenwich Mean
Time) as a reference point.
Configuring using set_timezone
1. From a shell within the
CS
box, run set_timezone as root by entering the following command:
#set_timezone
194
The following options appear:
Please choose the time zone where this machine is located.
0)GMT
1)1h West GMT
2)10h West GMT
3)11h West GMT
4)12h West GMT
5)2h West GMT
6)3h West GMT
7)4h West GMT
8)5h West GMT
9)6h West GMT
10)7h West GMT
11)8h West GMT
12)9h West GMT
13)1h East GMT
14)10h East GMT
15)11h East GMT
16)12h East GMT
17)13h East GMT
18)14h East GMT
19)2h East GMT
20)3h East GMT
21)4h East GMT
22)5h East GMT
23)6h East GMT
24)7h East GMT
25)8h East GMT
26)9h East GMT
Type your option:
2. Type the number corresponding to your Local GMT and press
<Enter>.
A message verifies your selection. For example if you choose 8, the system displays the following message:
Your choice was: GMT+4
3.
Run saveconf
to save your changes.
Note: Setting your system timezone creates a new file called
/etc/localtime
, which erases the old
/etc/TIMEZONE
.
BLACK BOX® CS Command Reference Guide
195
Configuring Using CLI
You can configure your local timezone using the CLI utility.
1. Enter the following command to enter the CLI mode.
#CLI
2. At the cli> prompt enter the following command.
#cli>config>administration>timezone <value>
Note: You can enter the value if known, otherwise, press tab to see the list of possible values.
#cli>config>administration>timezone <Press tab to see list of possible values>
The following possible values display:
10h_East_GMT 13h_East_GMT 3h_East_GMT 6h_East_GMT 9h_East_GMT
10h_West_GMT 14h_East_GMT 3h_West_GMT 6h_West_GMT 9h_West_GMT
11h_East_GMT 1h_East_GMT 4h_East_GMT 7h_East_GMT GMT
11h_West_GMT 1h_West_GMT 4h_West_GMT 7h_West_GMT
12h_East_GMT 2h_East_GMT 5h_East_GMT 8h_East_GMT
12h_West_GMT 2h_West_GMT 5h_West_GMT 8h_West_GMT
3. Select the desired GMT zone and enter it at the prompt. For example,
#cli>config>administration>timezone 2h_West_GMT
4. Activate the configuration.
cli> config runconfig
5. Save the configuration.
cli> config savetoflash
6. Exit the CLI mode.
cli> quit
196
5.10 NTP (Network Time Protocol)
The ntpclient is a Network Time Protocol (RFC-1305) client for UNIX- and Linux-based computers. In order for the CS to work as a NTP client, the IP address of the NTP server must be set in the file /etc/daemon.d/
ntpclient.conf. The program /bin/daemon.sh reads the configuration file (/
etc/daemon.d/ntpclient.conf) and runs with the settings of this file.
VI mode configuration
The file /etc/daemon.d/ntpclient.conf has all the configurable parameters.
The parameters that are not presented in the table below should not be changed.
1. Edit the /etc/daemon.d/ntpclient.conf and change the parameters according to the table below:
Table 5-7: /etc/daemon.d/ntpclient.conf parameters
Parameter Description
ENABLE
NTPSERVER
NTPINTER-
VAL
NTPCOUNT
This parameter enables the NTP client. It defaults to
NO, to enable it choose “YES”.
NTP server ip address.
Time in seconds to ask server.
NTP_OPT
Specifies how many times the server will be asked. 0 means forever.
Other ntp parameters. The possible values for this parameter are listed below:
•
-d -> Print diagnostics
•
-h hostname -> NTP server host (mandatory).
•
-l -> Attempt to lock local clock to server using adjtimex(2).
•
-p port -> Local NTP client UDP port.
•
-r -> Replay analysis code based on stdin.
•
-s -> Clock set (if count is not defined this sets count to 1).
a.
Activate and save the changes made.
To activate the configuration, issue the following command:
# daemon.sh NTP restart
BLACK BOX® CS Command Reference Guide
197
To save the changes, run the command:
# saveconf
CLI Method - NTP
To configure an NTP server using the CLI follow the steps below:
1. Open the CLI interface by issuing the command:
# CLI a.
Set the IP address of the NTP server.
cli> config administration ntp xxx.xxx.xxx.xxx
Where xxx.xxx.xxx.xxx is the IP address of the NTP server.
Note:
NOTE:
To deactivate the NTP service you just need to configure date by issuing the command: cli> config administration date/time date <mm/dd/yyyy> a.
Activate the configuration.
cli> config runconfig a.
Save the configuration.
cli> config savetoflash a.
Exiting the CLI mode.
To exit the CLI mode and return to CS ’s shell, type the following command: cli> quit
198
5.11 Session Sniffing
When multiple sessions are allowed for one port, the behavior of the CS will be as follows:
1. The first user to connect to the port will open a common session.
2. From the second connection on, only admin users will be allowed to connect to that port. The CS will send the following menu to these administrators (defined by the parameter all.admin_users or sN.admin_users in the file pslave.conf):
——————————————————————————————————————————————————————
* * * ttySN is being used by (<first_user_name>) !!!
*
1 - Initiate a regular session
2 - Initiate a sniff session
3 - Send messages to another user
4 - Kill session(s)
5 - Quit
Enter your option:
——————————————————————————————————————————————————————
If the user selects 1 - Initiate a regular session, s/he will share that serial port with the users that were previously connected. S/he will read everything that is received by the serial port, and will also be able to write to it.
If the user selects 2 - Initiate a sniff session, s/he will start reading everything that is sent and/or received by the serial port, according to the parameter all.sniff_mode or sN.sniff_mode (that can be in, out or i/o).
When the user selects 3 - Send messages to another user, the CS will send the user’s messages to all the sessions, but not to the tty port. Everyone connected to that port will see all the “conversation” that’s going on, as if they were physically in front of the console in the same room. These messages will be formatted as:
[Message from user/PID] <<message text goes here>> by the CS.
To inform the CS that the message is to be sent to the serial port or not, the user will have to use the menu.
If the administrator chooses the option 4 - Kill session(s), the CS will show him/her a list of the pairs PID/username, and s/he will be able to select one session typing its PID, or “all” to kill all the sessions. If the administrator kills all the regular sessions, his session initiates as a regular session automatically.
Option 5 - Quit will close the current session and the TCP connection.
BLACK BOX® CS Command Reference Guide
199
Only for the administrator users:
Typing all.escape_char or sN.escape_char from the sniff session or “send message mode” will make the CS show the previous menu. The first regular sessions will not be allowed to return to the menu. If you kill all regular sessions using the option 4, your session initiates as a regular session automatically.
VI Method - Involved parameters and passed values
Session sniffing involves the following parameters in the /etc/portslave/
pslave.conf:
•
all.admin_users - This parameter determines which users can
receive the sniff menu. When users want access per port to be controlled by administrators, this parameter is obligatory and
authType must not be none. User groups (defined with the
parameter conf.group) can be used in combination with user names in the parameter list. Example values: peter, john, user_group.
•
all.sniff_mode - This parameter determines what other users
connected to the very same port (see parameter admin_users below) can see of the session of the first connected user (main session): in shows data written to the port, out shows data received from the port, and i/o shows both streams, whereas no means sniffing is not permitted.The second and later sessions are called sniff sessions and this feature is activated whenever the protocol parameter is set to socket_ssh, socket_server, or
socket_server_ssh. Example value: out.
•
all.escape_char - This parameter determines which character
must be typed to make the session enter menu mode. The possible values are <CTRL-a> to <CTRL-z>. Represent the CTRL with character: ^. This parameter is only valid when the port protocol is socket_server or socket_ssh. Default value is ^z.
•
all.multiple_sessions - If it is configured as no, only two users
can connect to the same port simultaneously. If it is configured as yes, more than two simultaneous users can connect to the same serial port. A “Sniffer menu” will be presented to the user and they can choose either to open a sniff session; to open a read and/or write session; to cancel a connection; or to send a message to other users connected to the same serial port. If it is configured as RW_sessions, only read and/or write sessions will
200
be opened, and the sniffer menu will not be presented. If it is configured as sniff_session only, a sniff session will be opened, and the sniffer menu won’t be presented. Default value: no.
•
all.multiuser_notif - Multiple User notification selects if users
of a certain serial port should receive a warning message every time a new user logs in or out. By default this parameter is not activated. The warning messages doesn't go to the buffering file and will be like the following example:
WARNING: New user connected to this port.
Current number of users: x or
WARNING: User disconnection from this port.
Current number of users: x
Where x is the current number of connected users. The last user will know he/she is alone again when x = 1.
CLI Method - Session Sniffing
To configure session sniffing using the CLI interface follow the steps:
1. Open the CLI interface by issuing the command:
# CLI a.
Configure sniffing parameters.
The multiuser state configuration is under the menu: cli>config physicalports <'all' or range/list[1-4]> multiuser
Under this menu you can configure the following parameters:
• hotkey
- This parameter configures the escape character. The chosen character must be preceded by the ‘
^
’ character. Eg.:
^k
.
• notifyusers
- To configure multiuser notification (YES or NO).
• multisessions
- To configure multiple sessions. Valid values are: yes, no, ro, rw.
• privilegeusers
- This parameter determines which users can receive the sniff menu.
• sniffmode
- Determines what other users connected to the very same port can see of the session of the first connected user
(main session). Valid values are: in - shows data written to the
BLACK BOX® CS Command Reference Guide
201
port; out - shows data received from the port; in/out - shows both streams; off - disables sniffing.
a.
Activate the configuration.
cli> config runconfig a.
Save the configuration.
cli> config savetoflash a.
Exiting the CLI mode.
To exit the CLI mode and return to CS ’s shell, type the following command: cli> quit
202
5.12 Saveconf and Restoreconf
The CS has two utilities that are responsible for saving and restoring the unit’s configuration. Both are going to be described in this section.
Saveconf Utility
The syntax is:
# saveconf [media <media parameters>]
Where media can be any of these options:
•<none> - Save the configuration to internal flash
•local <remote Path and filename> - Save the configuration to the local file <remote Path and filename>
•ftp <remote Path and filename> <IP address of the FTP server>
<username> <password> - Save the configuration to the
remote FTP server
•sd [default] [replace] - Save the configuration to the PCMCIA storage device (Compact Flash or IDE)
The new media is storagedevice which has the two parameters, default and replace.
The saveconf utility creates one file in the storage device to save the default and replace flags. The filename is: /mnt/ide/proc/flash/
storageOptions and it can contain the words DEFAULT and/or REPLACE.
Restoreconf Utility
The syntax is :
# restoreconf [media <media parameters>]
Where media can be any of these options:
•<none> - Read the configuration file from the PCMCIA storage device and if the DEFAULT flag is set, use this file as the configuration default and if the REPLACE flag is set, copy this file to the internal flash of the CS. If the DEFAULT flag is not set or there is no configuration file in the PCMCIA storage device, read the configuration from the internal flash
•local <remote Path and filename> - Read the configuration from the local file <remote Path and filename>.
BLACK BOX® CS Command Reference Guide
203
•ftp <remote Path and filename> <IP address of the FTP server>
<username> <password> - Read the configuration from the
remote FTP server
•sd - Read the configuration from the PCMCIA storage device
(Compact Flash or IDE) and if the REPLACE flag is set, copy the file to the internal flash of the CS.
CLI Method - Save/Restore Configuration
Configuration can be saved/restored through the following menus:
• Saving the configuration to the internal flash memory cli>config savetoflash
• Saving the configuration to a PCMCIA storage device: cli>administration backupconfig saveto sd [-default] [-replace]
• Saving the configuration to a remote server using FTP protocol: cli>administration backupconfig saveto ftpserverip <n.n.n.n> pathname
<string> username <string> password <string>
• Loading the configuration from a PCMCIA storage device: cli>administration backupconfig loadfrom sd
• Loading the configuration from a remote server using FTP protocol: cli>administration backupconfig loadfrom ftpserverip <n.n.n.n> pathname
<string> username <string> password <string>
204
5.13 Start and Stop Services
This feature allows daemons (services) to be enabled or disabled without need of reboot the unit. A simple engine detects configuration changes
(file comparison). This feature is implemented with shell scripts. There is one main shell script called daemon.sh and one sourced shell script
(included by daemon.sh) for every daemon (service) that runs in the unit.
The shell script daemon.sh must be run once by inittab and every time a configuration change is made. The daemon.sh reads a file /etc/
daemon_list which contains the names of all sourced shell scripts and performs the start/stop/restart operation needed if any file related to service was changed. The daemon.sh will keep a hidden copy, prefixed with “.” and suffixed with .tmp, of all related files in the directory /var/
run.
Each sourced shell script has a set of mandatory shell variables handled directly by the shell script daemon.sh. The sourced shell scripts may have other shell variables not handled directly by daemon.sh. Such variables have the sole purpose of facilitating the configuration of command line parameters.
The mandatory shell variables define:
1. If the service is enabled or disabled. (ENABLE=YES/NO)
2. The pathname to the daemon. (DNAME=<daemon name, DPATH=<daemon path>)
3. How to restart the daemon: by signal (kill, hup, term, etc) or by command
(start, stop. etc). (DTYPE=sig/cmd)
4. Signal to be sent to the daemon. Default is term. (DSIG=<signal>)
5. A list of configuration files. The files in this list will be checked for changes.
(ConfigFiles=<config file list>)
6. A initialization shell script that will be run before start the service. (Shell-
Init=<shell_script_name [command line parameters]>)
7. Command line parameters to start the daemon. (DPARM=<command line parameters>)
8. Command Line parameters to stop the daemon. (DSTOP=<command line parameters>)
The daemon.sh may be executed in two ways:
1. Without parameters in the command line, it will check the configuration files of the service and restart or stop it if needed.
2. It will perform the requested action (stop/restart) in the list of services given in the command line regardless any configuration changes.
BLACK BOX® CS Command Reference Guide
205
The command daemon.sh help will display a list of services available.
Currently the following services are handled by daemon.sh. The first column is the service ID, the second is the name of the shell script file.
NIS
RPC
DB
NET
/etc/daemon.d/ypbind.conf
/etc/daemon.d/portmap.conf
/etc/daemon.d/cy_buffering.sh
/etc/daemon.d/inetd.sh
LOG
SSH
/etc/daemon.d/syslog.sh
/etc/daemon.d/sshd.sh
NTP /etc/daemon.d/ntpclient.conf
SNMP /etc/daemon.d/snmpd.sh
IPSEC /etc/daemon.d/ipsec.sh
PMD /etc/daemon.d/pmd.sh
LP
WEB
GDF
/etc/daemon.d/lpd.sh
/etc/daemon.d/webui.conf
/etc/daemon.d/gendial.sh
The following example will restart power management and Data Buffering services and it will stop SSH and network timer client services :
# daemon.sh PMD stop SSH NTP restart DB
206
How to Configure Them
Example of sourced shell script that activates the ntpclient service (type sig).
# This file defines the NTP client configuration
ENABLE=NO
DNAME=ntpclient
DPATH=/bin
ShellInit=
ConfigFiles=
DTYPE=sig
DSIG=kill
(lowercase)
# Must be "NO" or "YES" (uppercase)
# daemon name
# daemon path
# Performs any required initialization
# configuration files
# must be "sig" or "cmd" (lowercase)
# signal to stop/restart the daemon
# if it's hup term will be used to stop the daemon
# daemon command line parameters
NTPSERVER="-h 129.6.15.28"
NTPINTERVAL="-l 300"
NTPCOUNT="-c 0" # counter : 0 means forever
DPARM="$NTPCOUNT $NTPSERVER $NTPINTERVAL"
DSTOP=
# NTP server ip address
# Time in seconds to ask server
File Description 5.29: /etc/daemon.d/ntpclient.conf file
Example of sourced shell script that activates the ipsec service.
# This file defines the ipsec configuration
ENABLE=NO # Must be "NO" or "YES" (uppercase)
DNAME=ipsec # daemon name
DPATH=/usr/local/sbin # daemon path
ShellInit=/etc/ipsec.init # Performs any required initialization
ConfigFiles= # configuration files
DTYPE=cmd # must be "sig" or "cmd"
DSIG=kill # signal to stop/restart the daemon
(lowercase)
# if it's hup term will be used to stop the
daemon
# daemon command line parameters
DPARM="setup --start"
DSTOP="setup --stop"
File Description 5.30: /etc/daemon.d/ipsec.sh file
BLACK BOX® CS Command Reference Guide
207
5.14 Security Profiles
A Security Profile consists of a set of parameters that can be set to control access to the
CS
. The
CS
offers three pre-defined security profiles,
Secured, Moderate, Open, and an option to configure a Custom profile.
A fifth option, Default sets the parameters to the same as Moderate.
The following tables illustrates the properties for each of the Security
Profiles. The enabled services in each profile is designated with a check mark. Note that the Default option will set the parameters to the same as
Moderate, and the Custom Profile allows for individual configurations.
Table 5-8: Enabled services to access the
CS
box for each security profile.
Access to
CS
Secured Moderate Open Default Custom
Telnet
SSHv1
SSHv2
Allow SSH root access
HTTP
HTTPS
HTTP redirection to
HTTPS
Port 22
Port 22
Port 80
Port 443
Table 5-9: Enabled services to access the serial ports for each profile.
Access to
Serial Ports
Secured Moderate Open Default Custom
Console
(Telnet)
Console (SSH)
Console (Raw)
208
Access to
Serial Ports
Serial Port
Authentication
Bidirect
(Dynamic
Mode Support)
Secured Moderate Open Default Custom
Table 5-10: Enabled protocols for each profile shown with a check mark.
Other
Services
Secured Moderate Open Default Custom
SNMP
RPC
ICMP
FTP
IPSec
CLI Method - Selecting a Pre-defined Security Profile
1. Open the CLI interface by issuing the command:
#CLI a.
Enter the Security Profile menu: cli> config security profile a.
Type one of the pre-defined Security Profiles and press Enter: profile> secured moderate open default a.
To view the details of the selected profile, type the command: profile> show
BLACK BOX® CS Command Reference Guide
209
A window similar to following appears showing the details of the profile: profile>show
[profile]
[open]: custom
[moderate]: custom
[secured]: custom
.[custom]
ftp: no
telnet: yes
..[ssh]
sshv1: yes
sshv2: yes
sshd_port: 22
root_access: no
snmp: yes
..[web]
http: yes
https: yes
http_port: 80
https_port: 443
http2https: no
rpc: yes
ipsec: no
icmp: yes
..[ports]
ssh2sport: yes
telnet2sport: yes
raw2sport: yes
auth2sport: no
CLI Method - Configuring a Custom Profile
1. Open the CLI interface by issuing the command:
#CLI a.
Enter the Custom Security Profile menu: cli> config security profile custom
210
custom> a.
Configure Network Protocols.
The following parameters are available under custom menu:
• FTP
• ICMP
• IPSec
• RPC
• SNMP
• Telnet
To enable or disable a parameter issue the following command: custom> [parameter] <option>
Where possible values for <option> are yes to enable and no to disable the parameter.
To see the Custom profile configuration, type the command “show”.
custom> show
BLACK BOX® CS Command Reference Guide
211
A window similar to the following appears showing the details of the profile: custom>show
[custom]
ftp: no
telnet: yes
.[ssh]
sshv1: yes
sshv2: yes
sshd_port: 22
root_access: no
snmp: yes
.[web]
http: yes
https: yes
http_port: 80
https_port: 443
http2https: no
rpc: yes
ipsec: no
icmp: yes
.[ports]
ssh2sport: yes
telnet2sport: yes
raw2sport: yes
auth2sport: no a.
Configure Secure Shell (SSH) options.
Change the directory from custom> to ssh>. The following parameters are available under the ssh> menu:
• SSHv1 - Secure Shell version1
• SSHv2 - Secure Shell version 2
• sshd_port - SSH port ID
• root_access - Allow root access
To enable or disable a parameter issue the following command: ssh> [parameter] <option>
Where possible values for <option> are yes to enable and no to disable a parameter.
To assign an SSH port, type: ssh> sshd_port <portnumber>
212
To see the SSH configuration type the command “show” ssh> show
A window similar to the following appears showing the details of the
Note:
ssh>show
Note:
[ssh]
Note:
sshv1: yes
Note:
sshv2: yes
Note:
sshd_port: 22
Note:
root_access: no profile: a.
Configure Web Access Protocols.
Change the directory from custom> to web>. The following parameters are available under the web> menu:
• http
• http_port
• http2https
• https
• https_port
To enable or disable a parameter type the command: web> [parameter] <option>
Where possible values for <option> are yes to enable and no to disable a parameter.
To assign an http or https port, type: web> http <portnumber> https <portnumber>
To see the web configuration type the command “show”.
ssh> show
Note:
web>show
Note:
[web]
Note:
http: yes
Note:
https: yes
Note:
http_port: 80
Note:
https_port: 443
Note:
http2https: no
BLACK BOX® CS Command Reference Guide
213
a.
Configure Access to Serial Ports.
Change the directory from custom> to ports>. The following parameters are available under the ports> menu:
• auth2sport - Authentication to Access Serial Ports
• ssh2sport - SSH to Serial Ports
• raw2sport - Raw Connection to Serial Ports
• telnet2sport - Telnet to Serial Ports
To enable or disable a parameter issue the command: ports> [parameter] <option>
Where possible values for <option> are yes to enable and no to disable a parameter.
To see the ports configuration type the command “show” ports> show
Note:
ports>show
Note:
[ports]
Note:
ssh2sport: yes
Note:
telnet2sport: yes
Note:
raw2sport: yes
Note:
auth2sport: no a.
To activate the configuration, type the following command: cli> config runconfig a.
To save the configuration, type the following command: cli> config savetoflash a.
To exit CLI and return to the shell, type the following command: cli> quit
Note: The protocols and access methods for the Serial Ports must match the selected Security Profile. To configure parameters for the Serial Ports,
see “Chapter 8 - Profile Configuration” on page 8-289.
214
Chapter 6
Power Management with
..........................................................................
AlterPath™ PM Integration
Chapter 6 - AlterPath PM integration
The AlterPath™ PM is a family of Intelligent Power Distribution Units (IPDUs) that enables remote power control of servers and network gear. Through a serial port, the administrator can use the AlterPath PM to control all the equipment connected to its outlets, using operations like On, Off, Cycle, Lock, and Unlock.
When used in conjunction with BLACK BOX® console servers, the AlterPath PM delivers easier management capabilities and faster problem solving by integrating console access and power control into a single interface. The administrator can, for example, reboot the data center equipment when it crashes, without leaving his console session (Telnet or SSH). To do that, the administrator must simply press a configurable hotkey and select the appropriate option from the menu displayed in the session.
This chapter approaches all configuration that is integrated with the Advanced Console
Server. Below are the sections that are going to be presented in this chapter:
•
Power Management Configuration
•
•
6.1 Power Management Configuration
The CS can have multiple PMs connected to serial ports that are configured for power management. Devices can be plugged into outlets on the PMs and also connected to other serial ports on the CS. In addition one or more outlets can be configured for each port and controlled individually or simultaneously with other outlets in a configured group. The CS administrator can control all outlets or can assign outlets to individual users or groups of users.
Figure 6.1 shows a typical setup for the AlterPath PM and the Advanced Console Server.
The AlterPath PM's serial console is connected to port YY of the Console Server, the server's serial console is connected to port XX of the Console Server, and the server's power plug is connected to power outlet ZZ on the AlterPath PM.
For hardware and cabling installation instructions for the AlterPath PM, Please refer to the AlterPath PM User Guide included in the product.
Figure 6.1 - Configuration diagram
Figure 6.1 - Configuration diagram shows a typical setup for the AlterPath PM and the
Advanced Console Server. The AlterPath PM's serial console is connected to port YY of the Console Server, the server's serial console is connected to port XX of the Console
Server, and the server's power plug is connected to power outlet ZZ on the AlterPath PM.
These port denominations will be used in the descriptions below.
Prerequisites for Power Management
In order to control individual outlets or groups of outlets from the Multi Outlet Control page, the following prerequisites must be met:
•
An AlterPath PM must be plugged into one of the serial ports, and that serial port must be configured for power management.
•
A device must be plugged into at least one outlets on the PM, and this device must be connected to a serial port.
•
The PM and the outlet numbers to which the device is plugged must be configured on the serial port to which the device is connected.
Configuring Power Management
There are two different types of parameters:
216
VI Method - Involved parameters and passed values
1. Parameters to the port YY where the AlterPath PM is connected:
•
sYY.protocol: New protocol Integrated Power Distribution Unit. For example: ipdu.
•
sYY.pmtype: The IPDU manufacturer. For example: blackbox.
•
sYY.pmusers: The user access list. For example: jane:1,2;john:3,4. The format of this field is:
[<username>:<outlet list>][;<username>:<outlet list>...] where <outlet list>'s format is:
[<outlet number>|<outlet start>-<outlet end>][,<outlet number>|<outlet start>-<outlet end>]
The list of users must be separated by semicolons (;); the outlets should be separated by commas (,) to indicate a list or with dashes (-) to indicate range; there should not be any spaces between the values.
•
sYY.pmNumOfOutlets: the number of outlets of the AlterPath PM. Default: 8.
•
sYY.pmsessions: Only users logged in with the connection method defined by this parameter will be allowed to access the IPDU unit. It is also necessary to define the authentication method in the sXX.authtype parameter and configure the
sXX.users parameter in order to allow users to access the IPDU port. Valid values are: "none" , "ssh", "telnet" or "ssh_telnet".
IMPORTANT:
By defining the sYY.pmsessions parameter and making all other necessary configuration, an user can access the IPDU directly by opening a SSH or Telnet connection to the desired port. The user will be prompted to enter the username and password, then he/she will have direct access to the pmCommand menu.
2. Parameters to the other ports where the servers are connected:
•
all.protocol: Protocols for the CAS profile. For example: socket_server, socket_raw, socket_ssh.
•
all.pmkey: The hot-key that starts a power management session. Default: ^p (Ctrlp).
•
sYY.pmoutlet: The outlet list where the server XX is plugged. The outlet is passed as a pair /PM_serial_port.outlet_number/. If the server has a dual power supply, the outlets are separated by space char. For example, one power supply is plugged in the second outlet of the IPDU connected in serial port 1. The other is plugged in the third outlet of the IPDU connected in serial port 5. The value is 1.2 5.3".
SXX.PMUSERS NOTES:
The ellipses in the field format for sXX.pmusers means that you can add as many users as you need. The [ ] indicates that the parameter is optional, again indicating that you can configure more than one user. The separator is the semicolon.
BLACK BOX® CS Command Reference Guide
217
CLI Method - IPDU Configuration
The CLI allows you to set some ports to the pm protocol. Configuring a port with the pm protocol means that you have an IPDU connected to it. Then you will have to configure power management parameters in other ports that are not configured as protocol pm.
Example: To show how power management works in the CLI, we will approach a practical example.
Suppose that we have a 4-port CS unit and an IPDU, with eight outlets, connected to serial port 1 of the CS.
To manage the IPDU we will have to configure port 1 as pm protocol and then associate which ports (anyone, but port 1) of the CS unit will be allowed to issue power management commands to port 1.
Step 1 - Open the CLI interface by issuing the command.
# CLI
Step 2 - Enable the serial port that the IPDU is connected to. For example, serial port 1 is being configured for IPDU.
cli>config physicalports 1 enable yes
Step 3 - Configure the serial port that the IPDU is connected to. For example, serial port 1 is being configured for IPDU.
cli>config physicalports 1 general protocol pm
You can specify from what type of session (SSH, Telnet or both) users will be allowed to connect to the IPDU.
cli>config physicalports 1 general pmsessions ssh
The command above restricted the access to the IPDU port, only for users that connect to the Advanced Console Server via SSH. Valid values for the pmsessions parameter are: ssh, telnet, ssh_telnet and none.
Step 4 - Configure from which ports of the CS, commands to the configured
IPDU port will be allowed to be issued.
We will allow users connected to serial port 2, to run power management commands to the IPDU connected to the serial port1 of the CS.
cli>config physicalports 2 powermanagement powermanagement>enable addoutlet pm 1 outlets 1,2
218
The above configuration makes an association between the outlet numbers (outlet
1 and outlet 2) and the power strip connected at port 1. The logic means that this server's power cords are plugged into outlet 1 and 2 of the power strip connected to port 1.
Step 5 - Configuring allowed users.
You can restrict access to IPDU units just for some users, to do that issue the command: enable> pmusers test1,test2
The command above allows the users test1 and test2 to run power management commands into the IPDU connected to serial port 1.
Step 6 - Configuring the hotkey.
You also need to define a hotkey, otherwise users will not be able to open the
IPDU menu: enable> pmkey ^i
Step 7 - Checking the configuration
enable> show
You should be prompted with something like this:
[enable] pmkey: ^i pmusers: test1,test2
[PM Alias and Outlet Number]:
Port1 - [no alias] Outlets:1,2
Step 8 - Activating the configuration.
Return to the main menu by running the command: enable> return powermanagement> return config>
Then, run the command: config > runconfig
Step 9 - Saving the configuration.
config > savetoflash
BLACK BOX® CS Command Reference Guide
219
Step 10 - Managing the IPDU unit.
To manage the outlets of the IPDU issue the command: cli>applications pm 1
Where “1” is the port number where the IPDU is connected in the CS.
You’ll be prompted with the pm command menu. You can find more information
about the “pm command” on page 238
Step 11 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
How to change the IPDU Password
Step 1 - Change the connection protocol on the serial port that the IPDU is connected to.
a) Change the connection protocol on the serial port by editing the
/etc/portslave/pslave.conf file. For example, change the serial port 1 protocol from
ipdu to socket_ssh or socket_server.
s1.protocol socket_ssh, or
s1.protocol socket_server
b) Save the pslave.conf file and activate the new configuration by entering the following command.
[root@CAS root]# runconf
Step 2 - Access the IPDU console using the protocol you have selected indicating the port which the IPDU is connected to.
For example, if a socket_sever protocol is selected in Step 1, do the following.
[root@CAS root]# telnet <CS ip address> [tcp port number] where the TCP port number is the serial port that the IPDU is connected to.
The following prompt appears:
Entering charater/text Mode
Escape character is ^]
220
AlterPath PM
Copyright (c) 2002-2003
V 1.5.0 Oct 25, 2004
[PM]: IPDU: 2
[PM]: OUT: 16
Username:
Step 3 - Login to the IPDU console.
Login to the IPDU using the factory-default username/password admin/pm8.
Step 4 - Change the IPDU password using the passwd command in the IPDU console as follows.
a) The pm> command appears after you login.
Enter the passwd command at the prompt, and follow the prompts to enter the new password.
pm> passwd
Password:
Re-enter password:
Username/password set for user admin.
pm> b)Save the new password by issuing the command: pm>save
The system prompt the following:
Saving configuration to flash on IPDU #1 ... Done.
pm>
Step 5 - Close the connection to access the IPDU console by entering the escape character ^] (Ctrl-])
Step 6 - Edit the /etc/pm.* config file and change the passwd parameter as
follows:
admPasswd="<put the password you saved in IPDU>"
b) Save the new pm.* file and activate the new configuration by entering the following command.
[root@CAS root]# saveconf
Step 7 - Change the connection protocol for the serial port back to the original
IPDU.
BLACK BOX® CS Command Reference Guide
221
a) Edit /etc/portslave/pslave.conf file as follows:
s1.protocol ipdu
b) Save the pslave.conf file and enter the following command to activate the new configuration.
[root@CAS root]# runconf
Step 8 - Restart the pmd process for the new configuration file to take effect.
pmd is a Linux daemon process to control the communication between CS and
PM.
a) Execute the ps command to note the current pmd process
[root@CAS root]# ps -fe|grep pmd
878 root 644 S /bin/pmd
1108 root 552 S grep pmd b) Restart the pmd process by issuing the following command.
[root@CAS root]# daemon.sh restart PMD
The system prompts the following:
[root@CAS root]# Sep 22 14:32:04 src_dev_log@CAS showlogmsg:/bin/daemon.sh:
CONFIG: Network daemon [pmd] started c) Check to see if the process restarted. Note the process ID, which should be different from the earlier executed ps command.
[root@CAS root]# ps -fe|grep pmd
1126 root 680 S /bin/pmd
1130 root 552 S grep pmd
222
Accessing the AlterPath PM regular menu from the Console Session
The Power Management Utility can be used to manage power on devices plugged into one or more outlets on an AlterPath PM. The PM Utility can be started by the following two methods.
1. Issuing the pm command, which invokes the following menu and prompt:
---------------------------------------------------------
Power Management Menu v1.0
---------------------------------------------------------
---------------------------------------------------------
Power Management Menu
---------------------------------------------------------
1. Exit 2. individual ipdus 3. multi-outlet device 4.Info
Please choose an option:
The following table explains each menu item, its use and behavior.
Command
Exit
Table 6.1: Menu Options for PM Utility
Description
Exits the PM Utility and returns to the CS shell.
Individual
IPDUs
Multi-outlet device
Info
Invokes a menu for controlling and monitoring IPDUs and for controlling power on their individual outlets.
See “Manage Devices Plugged into a Single Outlet” on page 224 for more details.
Invokes a menu for controlling power on groups of outlets connected to devices. These outlets can be on the same or on different IPDUs.
See “Manage Devices Plugged into Multiple Outlets” on page 227 for more details.
Shows help text explaining each option.
BLACK BOX® CS Command Reference Guide
223
2. Issuing the pmCommand
Use: pmCommand <serial port number> <command> <arguments> where,
<serial port number> is the serial port number configured as IPDU
<command> <arguments> are the PM command and its arguments.
See the list of commands in Table 6.2.
Using the Power Management Utility
You can use the Power Management Utility to control IPDUs and individual outlets.
Manage Devices Plugged into a Single Outlet
Selecting option “2” for “Individual IPDUs” from the PM menu invokes the following prompt:
Give serial port number:
224
Entering the serial port number that is configured for power management brings up the following menu options:
----------------------------------------------------------------
Power Management Menu v1.0
----------------------------------------------------------------
PowerPort: PM
Number of units: 2
Serial Port: 1
----------------------------------------------------------------
----------------------------------------------------------------
Power Management Menu
PowerPort: PM
----------------------------------------------------------------
1. Return 9. Status 17. Factory Default
2. Help 10. Power Up Interval 18. Reboot
3. Who Am I 11. Name 19. Restore
4. On 12. Current 20. Save
5. Off 13. Temperature 21. Syslog
6. Cycle 14. Version 22. Alarm
7. Lock 15. Buzzer
8. Unlock 16. Current Protection
Please choose an option:
The following table explains each menu item, its use and behavior.
Table 6.2: Power Management Individual IPDUs Menu
Command
Return
Help
Who Am I
On
Off
Cycle
Lock
Description
Exits and returns to the main power management menu.
Provides a brief description of the menu items.
Displays the current username.
Turns an outlet On. Prompts you to enter the outlet number.
Turns an outlet Off. Prompts you to enter the outlet number.
Turns an outlet Off and On again, recycles the power. The system prompts you to enter an outlet number.
Locks an outlet in On or Off state to avoid accidental changes.
BLACK BOX® CS Command Reference Guide
225
Command
Unlock
Status
Power Up
Interval
Name
Current
Temperature
Version
Buzzer
Current
Protection
Factory Default
Reboot
Restore
Save
Syslog
Alarm
Description
Unlock the selected outlets.
Provides an overall status of the selected outlet.
Set the time interval (in seconds) that the system waits between turning on the currently-selected outlet and the next outlet.
Add a name or an alias for an outlet.
Displays the amount of current that is running through the
IPDU.
Displays the temperature on the IPDU, if the IPDU unit is equipped with a temperature sensor.
Displays the software and hardware version of the IPDU.
Configures a buzzer to sound when a specified alarm threshold has reached. Options are On to activate and Off to deactivate.
Activate or deactivate the current protection. This option is to prevent the outlets from being turned on, if the current on the
IPDU exceeds the specified threshold.
Restores the factory defaults.
Restarts the IPDUs in chain.
Restores the configuration saved in flash.
Saves the current configuration in flash.
Activates or deactivates the syslogging and alarm notifications.
Select a current value to set an alarm notification when the current exceeds the selected threshold.
Once you select a command, the following options may occur:
•
If command you select applies to the PM unit, then the command will be issued
226
•
If command you select applies to the outlets, the following prompt appears
Outlet name or outlet number(? for help, m for main menu):
Enter one or more outlet numbers separated by commas or dashes, as shown in the following screen example, or enter “all.”
Outlet name or outlet number(? for help, m for main menu):
1,3,5
Manage Devices Plugged into Multiple Outlets
You can use the Power Management Utility to simultaneously control all outlets that are configured to the same serial port, regardless of whether the outlets are on the same PM.
This option is applicable to devices with multiple power supplies.
Selecting option “3” for “Multi-outlet Devices” from the PM menu invokes the following menu and prompt:
-----------------------------------------------------------
Power Management Menu
-----------------------------------------------------------------
1. Return 4. Cycle 6. Unlock 8. Show
2. On 5. Lock 7. Status 9. Info
3. Off
Please choose an option:
The following table explains each menu item, its use and behavior.
Table 6-3: Menu Options for Multi-Outlet Control PM Utility
Command Description
Return
Takes the user back to the first menu.
On
Off
Cycle
Powers on all the outlets belonging to this multioutlet device.
Powers off all the outlets belonging to this multioutlet device.
Turns the outlets off and back on.
BLACK BOX® CS Command Reference Guide
227
Table 6-3: Menu Options for Multi-Outlet Control PM Utility
Command Description
Lock
Unlock
Locks all the outlets belonging to the multi-outlet device so that no command can be executed on them, except an unlock command.
Unlocks all the outlets belonging to this multi-outlet device.
Issue individual status commands on each of the outlets belonging to this multi-outlet device as in the following example:
Status
Show
Info
These are the status for these outlets in the IPDU attached to ttyS3
Outlet Name Status Users Interval
(s)
1 Unlocked ON 0.50
4 Unlocked ON 0.50
5 Unlocked ON 0.50
Shows which outlets in which ipdu chain belong to the multi-outlet device as in the following example: alias: (null) port: ttyS4 outlets: 3.1
3.5 3.4
where ttyS4
is the serial port that the device is connected to and
3.1
,
3.5
, and
3.4
indicate ports 1, 5, and 4 on a PM that is connected to port 3.
Shows help text explaining each option.
228
Note: The multi-outlet device menu is inaccessible if there are no devices configured with pmoutlet parameter in /etc/portslave/pslave.conf. You need to configure the
“sxx.pmoutlet” line in pslave.conf file.
In the following example, the Sun Server is a multi-outlet device connected to outlet 7 of IPDU 1 and outlet 2 of IPDU 2. The sequence of power up interval is 1.7 then 2.2.
s3. alias Sun Server
To Manage Multiple IPDUs from the Command Line
Step 1 - Connect to the CONSOLE port of the CS or use Telnet or SSH to access the CS, and log in.
Step 2 - Enter the pm command.
[root@CAS root]# pm
The power management menu displays as shown in the following screen example.
Power Management Menu v1.0
-----------------------------------------------------------
-----------------------------------------------------------
Power Management Menu
-----------------------------------------------------------
1. Exit 2. individual ipdus 3. multi-outlet device 4.Info
Please choose an option:
To control power on multi-outlet devices, Enter the number 3. .
1. Exit 2. individual ipdus 3. multi-outlet device 4.Info
Please choose an option: 3
BLACK BOX® CS Command Reference Guide
229
The power management utility displays as shown in the following screen example.
-----------------------------------------------------------
Power Management Menu
-----------------------------------------------------------1.
Return 4. Cycle 6. Unlock 8. Show
2. On 5. Lock 7. Status 9. Info
3. Off
Please choose an option:
Step 1 - Enter the number that corresponds to the desired option (“On,” “Off,”
“Cycle,” “Lock,” “Unlock,” “Status,” “Show,” or “Info.”
The following prompt appears
Please supply the serial port number or the alias for the multi-outlet devices
If in doubt, type ? followed by enter and a list of available devices will be shown
Step 2 - Enter the number or alias of the serial port to which the multi-outlet device is connected.
The command is executed.
To Manage Power Through the Console
Step 1 - Open a console session.
Open a Telnet or SSH session for the serial port.
Step 2 - Access the IPDU regular menu.
This should be done, for example, when the server crashes and it necessary to change the power status. Type the pre-configured hot-key.
If the user does not have permission to access any outlet, the following message will appear, and you will return to the Console Session:
It was impossible to start a Power Management Session
You can't access any Power Management functionality.
Please contact your Console Server Administrator.
If the user does not have permission to access the outlet(s) of this server, but can access another outlet, the following message will appear:
230
You cannot manage the outlet(s) of this server.
Please enter the outlet(s) (or 'h' for help):
The user should type the outlet(s) he wants to manage, before reaching the main menu. The main menu will appear only if the user has permission for this/these outlet(s). Typing 'h' will cause the session to show text explaining what to type, and
'l' will cause the PM session to be logged out, and the user to return to the Console
Session. If the user has permission to access the outlet(s) of this server, these outlets will be managed by the PM session.
Step 3 - Regular User Menu.
This is the AlterPath PM regular user menu:
-------------------------------------------------------------------
Power Management Menu
PowerPort: PM
-------------------------------------------------------------------
1. Return 6. Cycle 11. Name
2. Help 7. Lock 12. Current
3. Who Am I 8. Unlock 13. Temperature
4. On 9. Status 14. Version
5. Off 10. Power Up Interval
Please choose an option:
Menu Description 6.1: AlterPath PM regular menu
Option
Return
Help
Description
Exits and returns to the main power management menu.
Provides a brief description of the menu items.
Displays the current username.
Who Am I
On
Turns an outlet On. Prompts you to enter the outlet number.
Table 6.4: AlterPath PM regular user menu options
BLACK BOX® CS Command Reference Guide
231
Option
Off
Cycle
Lock
Description
Turns an outlet Off. Prompts you to enter the outlet number.
Turns an outlet Off and On again, recycles the power. The system prompts you to enter an outlet number.
Locks an outlet in On or Off state to avoid accidental changes.
Unlock the selected outlets.
Unlock
Status
Power Up
Interval
Provides an overall status of the selected outlet.
Set the time interval (in seconds) that the system waits between turning on the currently-selected outlet and the next outlet.
Add a name or an alias for an outlet.
Name
Current
Temperature
Version
Displays the amount of current that is running through the IPDU.
Displays the temperature on the IPDU, if the
IPDU unit is equipped with a temperature sensor.
Displays the software and hardware version of the IPDU.
Table 6.4: AlterPath PM regular user menu options
Step 4 - Check the status of the server's outlet or the outlet list.
232
Type '9' and wait for the answer. For example:
Please choose an option: 9
Outlet name or outlet number(all for all, ? for help, m for main menu):
1-3
Outlet Name Status Users Interval
(s)
1 pm Unlocked ON 0.50
2 Unlocked ON 0.50
3 Unlocked ON 0.50
-------------------------------------------------------------------
Power Management Menu
PowerPort: PM
-------------------------------------------------------------------
1. Return 6. Cycle 11. Name
2. Help 7. Lock 12. Current
3. Who Am I 8. Unlock 13. Temperature
4. On 9. Status 14. Version
5. Off 10. Power Up Interval
Please choose an option:
Menu Description 6.2: Outlet Status
BLACK BOX® CS Command Reference Guide
233
Step 5 - Reboot the server.
If the outlet(s) is/are locked, the user must unlock the outlet(s) first (option 8 -
Unlock). The Cycle command turns the power off for some seconds and the turn it on again. Type '6' and wait for the answer. For example:
Please choose an option: 6
Outlet name or outlet number(? for help, m for main menu): 1
1: Outlet turned off.
1: Outlet turned on.
-------------------------------------------------------------------
Power Management Menu
PowerPort: PM
-------------------------------------------------------------------
1. Return 6. Cycle 11. Name
2. Help 7. Lock 12. Current
3. Who Am I 8. Unlock 13. Temperature
4. On 9. Status 14. Version
5. Off 10. Power Up Interval
Please choose an option:
Menu Description 6.3: Outlet Cycle
Step 6 - Manage other outlets.
To Manage Other Oulets
Perform this procedure if you need to access other outlets.
•
Enter option “9. Status” to view the Outlets you are authorized to manage, and at the Outlent name or outlet number prompt, type “all”.
234
•
Select a command from the menu and then select the outlet that you are authorized to manage.
Please choose an option: 9
Outlet name or outlet number(all for all, ? for help, m for main menu):
all
Outlet Name Status Users Interval
(s)
1 pm Unlocked ON 0.50
2 Unlocked ON 0.50
3 Unlocked ON 0.50
9 Unlocked ON 1.25
10 Unlocked ON 0.50
11 Unlocked ON 0.50
12 Unlocked ON 0.50
13 Unlocked ON 0.50
14 Unlocked ON 0.50
15 Unlocked ON 0.50
16 Unlocked ON 0.50
-------------------------------------------------------------------
Power Management Menu
PowerPort: PM
-------------------------------------------------------------------
1. Return 6. Cycle 11. Name
2. Help 7. Lock 12. Current
3. Who Am I 8. Unlock 13. Temperature
4. On 9. Status 14. Version
5. Off 10. Power Up Interval
Please choose an option:
Menu Description 6.4: Changing the outlet list
From this point, all the commands will be related to the 2nd outlet of the IPDU in the port 1.
Step 7 - Return to the Console Session.
The user can exit from the PM session and return to the Console Session in three ways:
1.Type the hot-key again, any time.
2.If the session is waiting for a menu option, type the option 1 - Exit.
BLACK BOX® CS Command Reference Guide
235
3.If the session is waiting for the outlet, type 'l'.
When the user leaves the PM session, the following message will appear:
Exit from PM session
Power Management for Authorized Users (firmware version prior to 2.2.0)
The administrator or any user that belongs to the pmusers group, can log onto the
Console server itself, and have total control over all the IPDU outlets. An additional menu, with more options than the regular menu, is provided for the administrator and users contained in the pmusers group to manage any IPDU.
There are two commands which can be used to manage the IPDU. The first one (pm) deals with menu options, while the second one (pmCommand) deals with the commands as they are sent to the IPDU, and requires more knowledge about the AlterPath-PM commands.
Adding an user of the pmusers group
Only the root user and users belonging to the pmusers group can do power management by using the pm or pmCommand. To add an user as member of the pmusers group, log in as "root" and run the 'adduser' command with the following syntax:
# adduser -G pmusers <username>
Changing the group of an already existing user
It is also possible to change the group of an already existing user. In this example we will change the groups of the already existing users: “blackbox” and “test”. To do that follow the steps below:
Step 1 - Open the file /etc/group.
To open this file, run the command:
# vi /etc/group
Step 2 - Adding the “blackbox” and “test” users to the pmusers group.
To change the group of these users, look for the line that begins with “pmusers”.
At the end of this line, just after the ´:´ character, insert the “blackbox” and
“testusers”.
webadmin:504:root pmusers:505:blackbox,test blackbox:x:506: test:x:507:
236
Step 3 - Save the configuration.
To save the changes done, run the command:
# saveconf
BLACK BOX® CS Command Reference Guide
237
pm command
The pm command provides a menu that can be reached by typing the following command, from the prompt.
238
# pm <IPDU port>
------------------------------------------------------------------------
Power Management Menu v1.0
------------------------------------------------------------------------
PowerPort: PM
Number of units: 2
Serial Port: 1
------------------------------------------------------------------------
Power Management Menu
PowerPort: PM
------------------------------------------------------------------------
1. Exit 9. Status 17. Factory Default
2. Help 10. Power Up Interval 18. Reboot
3. Who Am I 11. Name 19. Restore
4. On 12. Current 20. Save
5. Off 13. Temperature 21. Syslog
6. Cycle 14. Version 22. Alarm
7. Lock 15. Buzzer
8. Unlock 16. Current Protection
Please choose an option: 2
Exit ----------------------- Exit
Help ----------------------- Show this help
Who Am I ------------------- Display the username currently logged in
On ------------------------- Turn on outlets
Off ------------------------ Turn off outlets
Cycle ---------------------- Power cycle outlets
Lock ----------------------- Lock outlets in current state
Unlock --------------------- Unlock outlets
Status --------------------- Display state of the outlets
Power Up Interval ---------- Set/read the power up interval
Name ----------------------- Name an outlet
Current -------------------- Set/Read/Reset the current
Temperature ---------------- Set/Read/Reset the temperature
Version -------------------- Show the software and hardware version
Buzzer --------------------- Set/read the buzzer
Current Protection --------- Set/read the over current protection
Factory Default ------------ Bring the unit to factory configuration
Reboot --------------------- Reboot the units in chain
Restore -------------------- Restore the configuration in flash
Save ----------------------- Save the current configuration in flash
Syslog --------------------- Set/read the syslog
Alarm ---------------------- Set/read the alarm status
Menu Description 6.5: pm command options
Some of these options require the outlet number (On, Off, Cycle, Lock, Unlock, Status), and others don't. In the first case, when the option is selected, the number of the outlet
BLACK BOX® CS Command Reference Guide
239
will be asked. The user can enter one or more outlets (separated by commas or dashes), or “all,” to apply the option to all the outlets.
Following are examples of some things which can be done through this command.
Turning the outlet off
----------------------------------------------------------------------
Power Management Menu
PowerPort: pm10
----------------------------------------------------------------------
1. Exit 9. Status 17. Factory Default
2. Help 10. Power Up Interval 18. Reboot
3. Who Am I 11. Name 19. Restore
4. On 12. Current 20. Save
5. Off 13. Temperature 21. Syslog
6. Cycle 14. Version 22. Alarm
7. Lock 15. Buzzer
8. Unlock 16. Current Protection
Please choose an option: 5
Outlet name or outlet number(? for help, m for main menu): 1
1: Outlet turned off.
Menu Description 6.6: Turning the outlet off
240
Locking the outlets
When the outlet is locked, the previous status cannot be changed, until the outlet is unlocked. This means that if the outlet was on, it cannot be turned off and, if it was off, it cannot be turned on.
---------------------------------------------------------------------
Power Management Menu
PowerPort: pm10
---------------------------------------------------------------------
1. Exit 9. Status 17. Factory Default
2. Help 10. Power Up Interval 18. Reboot
3. Who Am I 11. Name 19. Restore
4. On 12. Current 20. Save
5. Off 13. Temperature 21. Syslog
6. Cycle 14. Version 22. Alarm
7. Lock 15. Buzzer
8. Unlock 16. Current Protection
Please choose an option: 7
Outlet name or outlet number(? for help, m for main menu): 1-3
1: Outlet locked.
2: Outlet locked.
3: Outlet locked.
Menu Description 6.7: Locking the outlet
BLACK BOX® CS Command Reference Guide
241
Retrieving the status of the outlets
Power Management Menu
PowerPort: pm10
---------------------------------------------------------------------
1. Exit 9. Status 17. Factory Default
2. Help 10. Power Up Interval 18. Reboot
3. Who Am I 11. Name 19. Restore
4. On 12. Current 20. Save
5. Off 13. Temperature 21. Syslog
6. Cycle 14. Version 22. Alarm
7. Lock 15. Buzzer
8. Unlock 16. Current Protection
Please choose an option: 9
Outlet name or outlet number(all for all,? for help, m for main menu): all
Outlet Name Status Users Interval (s)
1 pm Locked ON 0.50
2 Unlocked ON 0.50
3 Unlocked ON 0.50
4 Unlocked ON 0.50
5 Unlocked ON 0.50
6 Unlocked ON 0.50
7 Unlocked ON 0.50
8 Unlocked ON 0.50
9 Unlocked ON 1.25
10 Unlocked ON 0.50
11 Unlocked ON 0.50
12 Unlocked ON 0.50
13 Unlocked ON 0.50
14 Unlocked ON 0.50
15 Unlocked ON 0.50
16 Unlocked ON 0.50
Menu Description 6.8: Turning the outlet off
242
pmCommand command
Through pmCommand command, the administrator has access to other options beyond the menu options, because he will be accessing the IPDU itself. The administrator must have a good knowledge of the AlterPath PM command set to use it.
There are two ways to use this command. If only the IPDU port is passed as an argument, it will appear in a prompt where the administrator can write the command. Otherwise, the arguments after the IPDU port will be considered the PM command.
Syntax: pmCommand <IPDU port> [<command>]
For example:
[root@CAS root]# pmCommand 1
-----------------------------------------------------------------------
Power Management Command Prompt v1.1
-----------------------------------------------------------------------
Power Name: PM
[PM]
The following are examples of some things which can be done through this command.
Listing the commands available for the AlterPath PM
[root@CAS root]# pmCommand 1 help
•
exit ----------------------- Exit
•
help ----------------------- Show this help
•
menu ---------------------- Start the menu driven text interface(pm)
•
whoami --------------------Display the username currently logged in
•
getname -------------------Get the name of the server
•
on ------------------------- Turn on outlets
•
off ------------------------ Turn off outlets
•
cycle ---------------------- Power cycle outlets
•
lock --------------------- Lock outlets in current state
•
unlock -------------------Unlock outlets
•
status --------------------Display state of the outlets
•
interval ------------------ Set/read the power up interval
•
name -------------------- Name an outlet
•
current ------------------ Set/Read/Reset the current
•
temperature ------------- Set/Read/Reset the temperature
•
ver ------------------------ Show the software and hardware version
BLACK BOX® CS Command Reference Guide
243
•
buzzer --------------------- Set/read the buzzer
•
currentprotection ---------- Set/read the over current protection
•
factory_defaults ----------- Bring the unit to factory configuration
•
reboot ---------------------Reboot the units in chain
•
restore -------------------- Restore the configuration in flash
•
save -----------------------Save the current configuration in flash
•
syslog ---------------------Set/read the syslog
•
alarm ----------------------Set/read the alarm status
Type 'help <command>' to see details of <command>
Cycling all the outlets
[Power Management Prompt]# cycle 4,5
4: Outlet turned off.
5: Outlet turned off.
4: Outlet turned on.
5: Outlet turned on.
Unlocking the outlets 1, 5 and 8
[Power Management Prompt]# unlock 1, 5, 8
1: Outlet unlocked.
5: Outlet unlocked.
8: Outlet unlocked.
Retrieving the status of all outlets
[Power Management Prompt]# status all
Outlet Name Status Users Interval (s)
1 pm Unlocked ON 0.50
2 Unlocked ON 0.50
3 Unlocked ON 0.50
4 Unlocked ON 0.50
5 Unlocked ON 0.50
6 Unlocked ON 0.50
7 Unlocked ON 0.50
8 Unlocked ON 0.50
Turning the outlet off
[Power Management Prompt]# off 2
2: Outlet turned off.
244
BLACK BOX® CS Command Reference Guide
245
6.2 IPDU Firmware Upgrade
It is possible to upgrade the firmware of the IPDU unit connected to any serial port of the CS. It is also possible to upgrade the whole daisy-chain of AlterPath PM units, since the unit(s) before the targeted one has firmware version 1.2.2 or greater.
Upgrade Process
To upgrade the firmware of the PM units follow the steps below:
Step 1 - Download the firmware.
The first step of the upgrade process is to download the new firmware. Cyclades provides a directory on its FTP site where it is possible to check for new firmware and download them to the CS. It is recommended to download the new firmware to the /tmp directory because files in this directory are deleted during the boot process. See the BLACK BOX® CS Installation, Administration, and User’s Guide under IPDU firmware upgrade.
Step 2 - Run the pmfwupgrade application.
After downloading it is necessary to call an application called pmfwupgrade.
This application has the following syntax:
# pmfwupgrade [-h] [-f] [-F] [-v] <serial port number>[:<unit number>] <filename>
where :
•
-h = Show the help message and exit
•
-f = The upgrade is done without asking any questions
•
-F = The upgrade is done without waiting logical connection with the AlterPath
PM. This is should be used after possible power failure during the upgrade process.
•
-v = show messages about the status of the upgrade.
•
<serial port number> = the serial port where the PM unit is connected
•
[:<unit number>] = number of the PM unit when in daisy-chain. If is not used, all units in the serial port will have the firmware upgraded, when possible
246
•
<filename> = complete path of the file that has the PM firmware (default:
/tmp/pmfirmware)
IMPORTANT!
If the AlterPath PM unit is not configured with the default password, it will be necessary to inform it to the CS by editing the /etc/pm.bb file and changing the parameter admPasswd with the correct password.
The pmfwupgrade application will try to stop all the process that are using the serial port.
Just type YES to proceed into the upgrade process. Another message will prompt asking for confirmation to proceed with the upgrade process. Type ‘y’ to upgrade the PM unit firmware.
WARNING!
Depending on the hardware version of the AlterPath PM, it is possible that all outlets completely powers off during the upgrade process. Make sure to shutdown all devices connected to them before starting the firmware upgrade process.
BLACK BOX® CS Command Reference Guide
247
6.3 SNMP Proxy
The SNMP Proxy for Power management feature allows the BLACK BOX® CS console servers to proxy SNMP requests to the Intelligent Power Distribution Units.
This allows SNMP clients to query and control the remote IPDU using standard set and get commands.
How to Configure
You should ensure that the AlterPath PM is correctly installed and configured by
following the procedure outlined in section 6.1 Power Management Configuration
of this Reference Guide. You must also ensure that SNMP is correctly configured by
following the configuration instructions in the SNMP section of Chapter 5 -
The parameters and features that can be controlled in the remote IPDU are as follows:
•
The number AlterPath PM units connected to a given console server
•
The number of the outlets connected to a given port
•
The number the AlterPath PM units connected to this port (when a daisy-chain configuration is being used).
•
The instantaneous RMS current being drawn from each of the AlterPath PM unit(s) connected to this port.
•
The software version of the AlterPath PM unit(s) connected to this port
•
The temperature of the AlterPath PM unit(s) connected to this port
•
The name of the outlet as configured in the AlterPath PM.
•
The alias of the server that is configured as using this outlet
•
The name of the serial console connection that corresponds to the host which this outlet controls power.
248
•
The status of the outlet
. power status : 0 (off), 1 (on), 3 (unknow)
. lock state : 0 (unlock), 1 (lock) , 2 (unknow)
This feature will allow the user to control the AlterPath PM outlets using SNMP set commands. These following actions will be allowed to each outlet by this feature :
1) ON
2) OFF
3) CYCLE
4) LOCK
IMPORTANT!
The CS proxies all SNMP requests to the AlterPath PM unit. Therefore there is a small delay if an outlet cycling is requested by the snmpset command. To successfully cycle an outlet, a 4 second or higher timeout must be specified. To run this command for more than one outlet or for units configured as daisy-chain, this time should be recalculated.
Examples:
This feature allows the user do these following SNMP requests:
1) Get the number of CS/TS serial ports that has PM connected to:
# snmpget -m all -v 2c -t 4 -c blackbox 10.10.0.1 .cyNumberOfPM <enter> enterprises.blackbox.cyCSMgmt.cyPM.cyNumberOfPM.0 = 2
2) Get the number of outlets of the PM connected to serial port 16:
# snmpget -m all -v 2c -t 4 -c blackbox 10.10.0.1 .cyPMNumberOutlets.16 <enter> enterprises.blackbox.cyCSMgmt.cyPM.cyPMtable.cyPMEntry.cyPMNumberOutlets.16 = 8
3) get the number of units of the PM connected to serial port 14:
# snmpget -m all -v 2c -t 4 -c blackbox 10.10.0.1 .cyPMNumberUnits.14 <enter> enterprises.blackbox.cyCSMgmt.cyPM.cyPMtable.cyPMEntry.cyPMNumberUnits.14 = 2
For more examples and MIB definition please search the online FAQ at: www.blackbox.com/support/faqs.php
BLACK BOX® CS Command Reference Guide
249
250
Chapter 7
PCMCIA Cards Integration
..........................................................................
Chapter 7 - PCMCIA Cards Integration
PCMCIA slots allow for enhanced functionality with support for many interface cards, such as Ethernet, modem (V.90, GSM, CDMA, and ISDN) and wireless LAN.
7.1 Supported Cards
For a list of the supported PCMCIA cards see Appendix C in the BLACK BOX®
Installation, Administration, and User’s Guide.
Tools for Configuring and Monitoring PCMCIA Devices
During the CS boot, the /etc/init.d/pcmcia script loads the PCMCIA core drivers and the cardmgr daemon. The cardmgr daemon is responsible for monitoring PCMCIA sockets, loading client drivers when needed, and running user-level scripts in response to card insertions and removals.
•
lsmod - This command shows the modules loaded for the PCMCIA devices.
•
cardctl - This command can be used to check the status of a socket, or to see how it is configured. Just type cardctl to see the syntax of the command. cardctl config displays the card configuration. cardctl ident can be used to get card identification information. cardctl eject stops the application and unloads the client driver, and cardctl insert re-loads the driver and re-starts the application.
NOTE:
“cardctl suspend”, “cardctl resume” and “cardctl reset” are not supported.
Ejecting Cards
You can insert the card anytime, and the drivers should be loaded automatically. But you will need to run cardctl eject before ejecting the card to stop the application using the card. Otherwise the CS may hang during the card removal. You must specify the slot number when using the cardctl command. For example: cardctl eject 0 for the lower slot and cardctl eject 1 for the upper slot
7.2 PCMCIA Network devices configuration
Ethernet PC cards
The onboard Ethernet device has the eth0 name. The first PCMCIA Ethernet card or wireless LAN card detected will receive the eth1 name, the second card will be eth2.
cardmgr will read the network settings from the /etc/network/interfaces and assign an IP to eth1.
NOTE:
Before changing the /etc/network/interfaces file, unload the network client driver using cardctl eject.
VI Method
The factory default for the /etc/network/interfaces file has the following lines:
#
#
#
#
# auto eth1
#iface eth1 inet static
# address 192.168.0.42
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1
File Description 7.1: part of the /etc/network/interfaces file
Remove the # in the beginning of the line, and change the IPs to suit your network configuration. For instance, you may want the following configuration: auto eth1 iface eth1 inet static address 192.168.162.10
network 192.168.162.0
netmask 255.255.255.0
broadcast 192.168.162.255
gateway 192.168.162.1
File Description 7.2: part of the /etc/network/interfaces file
252
Don't forget to run saveconf to save this configuration in the flash, so that it can be restored in the next boot. Run cardctl insert to load the network drivers with the new configuration.
IMPORTANT:
Do not use ifconfig to change the network settings for the PCMCIA device.
Otherwise, you may be unable to unload the network driver during “cardctl eject” and the
CS may hang. The correct way is to change the /etc/network/interfaces file.
Removing the configuration from a Ethernet PCMCIA device
Before removing the configuration from an Ethernet PCMCIA card configured in CS, you should first run “cardctl eject <slot number>” and then delete the lines of the desired interface from the /etc/network/interfaces file.
CLI Method - Ethernet PCMCIA
To configure an Ethernet PCMCIA card using the CLI, follow the steps:
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Configuring IP address and network mask.
Supposing that the PCMCIA card is placed on slot 1 of the unit, run the command: cli>config network pcmcia 2 ethernet ip 192.168.0.100 mask 255.255.255.0
This command will configure 192.168.0.100 as IP address and 255.255.255.0 as netmask.
Step 3 - Save the configuration.
cli>config savetoflash
Step 4 - Activating the configuration.
Due to CLI restrictions, the configuration must be activated in the shell prompt, by running the two commands below in the presented sequence:
# cardctl eject
# cardctl insert
Step 5 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
BLACK BOX® CS Command Reference Guide
253
254
Wireless LAN PC Cards
First do the appropriate PCMCIA network configuration. Additionally, the configuration of the wireless driver is done in the following file:
/etc/pcmcia/wireless.opts
For instance, to configure the network name as MyPrivateNet, and the WEP encryption key as secu1, the following settings could be added to the default “*,*,*,*)" entry :
*,*,*,*)
INFO="This is a test"
ESSID="MyPrivateNet"
KEY="s:secu1"
File Description 7.3: part of the /etc/pcmcia/wireless.opts file
NOTE:
The "s:" prefix in the KEY line indicates that the key is an ASCII string, as opposed to hex digits. Five ASCII characters or ten hexadecimal digits could be entered for WEP 64bit (also known as 40-bit) and 13 ASCII characters or 26 hexadecimal digits could be entered for WEP 128-bit (also known as 104-bit). Any ascii characters will be accepted if it starts with "s:" otherwise only characters between [0-9,a-f] will be accepted. Check your PCMCIA card specifications.
There is a generic sample in the end of the wireless.opts file that explains all possible settings. For more details in wireless configuration, search for manpage iwconfig on the
Internet. The parameters in wireless.opts are used by the iwconfig utility. After changing any of the parameters, run “cardctl eject” followed by cardctl insert to load the new settings. Also, run saveconf to save the new settings to flash. iwconfig eth1 shows the basic wireless parameters set in eth1. iwlist allows to list frequencies, bit-rates, encryption, etc. The usage is: iwlist eth1 frequency iwlist eth1 channel iwlist eth1 ap iwlist eth1 accesspoints iwlist eth1 bitrate iwlist eth1 rate iwlist eth1 encryption iwlist eth1 key iwlist eth1 power iwlist eth1 txpower iwlist eth1 retry
BLACK BOX® CS Command Reference Guide
255
Removing the configuration from a wireless PCMCIA device
Before removing the configuration from a Wireless PCMCIA card configured in CS, you should first run “cardctl eject <slot number>” and then delete the lines of the desired interface from the /etc/network/interfaces file.
CLI Method - Wireless PCMCIA
Basically you just need to configure 4 parameters to have a wireless network up and running:
•
ESSID - is the identifying name of an 802.11b wireless network. By specifying the
ESSID in your client setup is how you make sure that you connect to your wireless network instead of your neighbors network by mistake.
•
IP address - The IP address of the wireless interface
•
Network Mask - Network mask of the wireless interface
•
Encryption - Enables WEP data encryption, not necessary to have a wireless network up, but strongly recommended due to security issues.
To configure a wireless PCMCIA card using the CLI, follow the steps:
Step 1 - Plug the PCMCIA wireless device into one of the available slots (slot 2, for this example) and open the CLI interface by issuing the command:
# CLI
Step 2 - Configuring basic parameters.
The command below will configure 192.168.100.1 as IP address and
255.255.255.0 as network mask: cli>config network pcmcia 2 wireless ip 192.168.100.1 mask 255.255.255.0
Now we need to configure the ESSID (Extended Service Set ID), that will be the string “test” for this example: cli>config network pcmcia 2 wireless essid test
Step 3 - Setting security parameters.
It is strongly recommended to enable encryption on wireless connections. The following command will enable connection encryption and set the string “test1” as key.
cli>config network pcmcia 2 wireless encrypt yes key s:test1
IMPORTANT:
Check the note about WEP keys on
page 255
.
Step 4 - Activating the configuration.
256
cli>config runconfig
Step 5 - Save the configuration.
cli>config savetoflash
Step 6 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
BLACK BOX® CS Command Reference Guide
257
Modem PC Cards
The modem device gets the /dev/ttySn name, where n is the number of embedded serial devices plus 1. For instance, if the CS has 32 onboard serial devices, the modem card becomes the /dev/ttyS33.
VI Method
When a modem card is detected, cardmgr starts a script which loads mgetty for the modem device automatically. mgetty provides the login screen to the remote user. mgetty may also be configured to start PPP (pppd) and let PPP login the caller. The steps to allow PPP connections are:
Step 1 - Enable login and PAP authentication in /etc/mgetty/login.config.
Enable the desired authentication in /etc/mgetty/login.config. For instance, you may want the following authentication in /etc/mgetty/login.config to enable PAP and system password database authentication:
/AutoPPP/ - a_ppp /usr/local/sbin/pppd auth -chap +pap login nobsdcomp nodeflate
Step 2 - Create a user name in /etc/ppp/pap-secrets.
If +pap authentication was selected, create a user name in
/etc/ppp/pap-secrets. For instance, you may add the following line: mary * marypasswd *
Step 3 - Create the user for login in the Radius server.
If the login option was used, create the user either locally (by running adduser) or create the user in the Radius server for Radius authentication.
Step 4 - Copy the /etc/ppp/options.ttyXX as /etc/ppp/options.ttyS33 (the modem
port).
Copy the /etc/ppp/options.ttyXX to have the device name assigned to the pcmcia modem. For instance, if the modem is the ttyS33, /etc/ppp/options.ttyXX should be copied as /etc/ppp/options.ttyS33. If you are not sure which ttySxx is the modem device, do a "ls -al /dev/modem" with the modem inserted.
Step 5 - Uncomment local and remote IPs in /etc/ppp/options.ttyS33.
Uncomment the line that assigns the local and remote IPs in
/etc/ppp/options.ttyS33 (or whatever is the tty name in your system). For instance, you may want to assign 192.168.0.1 for local ip, and 192.168.0.2 for the remote ip.
Step 6 - Save /etc/ppp/options.ttyS33 in flash.
258
Step 7 - Create an entry in /etc/config_files.
It should have the name of the file you created, so that the new file can be saved to the flash. For instance, you will have to add a line with /etc/ppp/options.ttyS33 in /etc/config_files.
Step 8 - Run saveconf to save the files listed in /etc/config_files to the flash.
Step 9 - Insert the pcmcia modem if not inserted yet.
Step 10 - Run ps to see that mgetty is running.
The CS is ready to receive dial in calls.
Step 11 - Establish PPP connection with the CS.
From the remote system, use pppd to dial and establish a PPP connection with the
CS. The remote system should have the login user name set in their /etc/ppp/pap-
secrets to have a successful login in to the CS.
Establishing a Callback with your Modem PC Card
Setting up a callback system serves two purposes:
1. Cost savings: reversing line charges - allows your company to call you back.
2. Security: makes sure users are who they pretend to be by calling a well-known or pre-configured number back.
The steps to allow callback are divided into two parts. Part One is the configuration for the Advanced Secure Console Port ServerCS (Server Side CS Setup). Part Two is the configuration for the client side.
Server Side CS Setup.
Step 1 - Enable authentication.
Enable the desired authentication in /etc/mgetty/login.config. For instance, you may want the following authentication in /etc/mgetty/login.config to enable PAP and system password database authentication:
/AutoPPP/ - a_ppp /usr/local/sbin/pppd auth -chap +pap login nobsdcomp nodeflate
Step 2 - Configure a pseudo callback user.
Add the following line to /etc/mgetty/login.config with the appropriate values. At the end of the file there is a line, like the presented below:
BLACK BOX® CS Command Reference Guide
259
* /bin/login @
Do this before the above presented line:
<pseudo callback name>/sbin/callback -S <phone number of the client> eg.: call /sbin/callback -S 12345
Where, 'call' is the pseudo callback name and '123456' is the number to dial back.
NOTE:
1. The order of configuration in /etc/mgetty/login.config matters. By default, it has the line
* - - /bin/login @ at the end of the file. This line allows any users to log in and be verified by the login program. If you were to add the callback line after this line, the callback program will not be initiated when you try logging in. Instead, the login program will be used to verify you since it was encountered first. List the callback users first if you want the option of having some users access the callback program and the others the login program.
call /sbin/callback -S 12345
* call2
-
-
-
/sbin/callback -S 77777
/bin/login @
The example above will allow you to have the option whether or not you want to use the callback functionality. If you log in with call or call2, then callback starts immediately. If you log in as anybody else other than call or call2, callback will not start and you'll be verified by the login program.
2. Don't use * instead of some callback user name. Mgetty will fall to infinite callback.
3. If you don't specify a telephone number, callback will ask for a number after you log in as the pseudo callback user.
Step 3 - If you plan to login through PPP with PAP authentication create pap
user name in /etc/ppp/pap-secrets.
Add a line similar to the following: (include the quotes and the two asterisks).
"myUserName" * "myUserNamePassword"*
Step 4 - If you plan to login through PPP follow steps 4 - 9 in the section above on Modem PC Cards.
Step 5 - Create users.
Step A: Create a new user with the command adduser myUserName.
260
This will create an entry in /etc/passwd that resembles this: myUserName:$1$/3Qc1pGe$./h3hzkaJQJ/:503:503:Embedix
User,,,:/home/myUserName:/bin/sh
Step B: If you want to limit myUserName to getting ONLY PPP access and
NOT shell access to the server, edit the entry for myUserName in /etc/passwd.
Do this by replacing /bin/sh with a pathname to a script that you will be creating later. In the following example, the script is: /usr/ppp/ppplogin myUserName:$1$/3Qc1pGe$./h3hzkaJQJ/:503:503:Embedix
User,,,:/home/myUserName:/usr/ppp/ppplogin
Step 6 - If you executed Step 5b, create the ppp login script.
Step A: Create a script called /etc/ppp/ppplogin following this format:
#!/bin/sh exec /usr/local/sbin/pppd <ppp options>
Step B: Make script executable.
Type chmod 755 /etc/ppp/ppplogin.
Step C: Save this file to flash.
Save this file to flash so the next time the CS gets rebooted, you won't lose the new file. Add /etc/ppp/ppplogin into /etc/config_files.
Now execute saveconf.
Step 7 - Change permission of pppd.
Type chmod u+s /usr/local/sbin/pppd
TIP.
To prevent from always having to manually change permission every time your
CS reboots:
1. Edit /etc/users_scripts by uncommenting the following line:
/bin/chmod_pppd
2. Add /etc/users_scripts into /etc/config_files.
3. Execute saveconf. The next time the
CS
reboots, this change will be in effect. You should not need to manually change the pppd permission.
Step 8 - Your CS is ready to establish a callback connection.
See Client Side Setup to start the callback connection.
BLACK BOX® CS Command Reference Guide
261
Client Side Setup.
Step 1 - Activate Show Terminal Window option.
(From Win2000) Go to your Connection window (the window to dial the CS ) -
> Properties -> Security -> look for Interactive Logon and Scripting -> click on
Show Terminal Window.
Step 2 - Disable/enable encryption protocols.
If you are going to be using PPP connection with PAP authentication, make sure you disable all other encryption protocols.
(from Win2000) go to your Connection window (the window to dial the CS) ->
Properties -> Security -> click on Advanced (custom settings) -> click on Settings
-> click on Allow these protocols -> disable all protocols except the PAP one.
Step 3 - Set up modem init string.
It is very important that before callback hangs the call, the modem in the
Windows box does not tell Windows that the call has been dropped. Otherwise,
Windows Dial-up Networking will abort everything (because it thinks the call was dropped with no reason).
(From Win2000) Go to Windows' control panel -> Phone and Modem -> Modems
-> choose your modem -> Properties -> Advanced -> add &c0s0=1 to Extra
Settings.
Step 4 - Call your CS.
Step A - Dial to the CS modem using either the normal username or the ppp username that you created in Step 5 when configuring the server side.
Step B - Once a connection is made, you get a login prompt.
Step C - Login with the pseudo callback name to start the callback.
Step D - Your connection gets dropped. The CS is now calling you back.
Step E - After reconnection to you, you get a login prompt again.
Step F - Now you can:
•
Log in through character mode: Log in with username and password. You will get the CS shell prompt.
•
Log in through ppp: Click on Done on the Terminal Window.
CLI Method - Modem PCMCIA
To configure a modem PCMCIA card using the CLI, follow the steps:
Step 1 - Open the CLI interface by issuing the command:
# CLI
262
Step 2 - Enabling the PCMCIA modem and configuring it.
The line below configures a PCMCIA modem placed on slot 2 with local IP address 10.0.0.1 and remote IP address 10.0.0.2
cli>config network pcmcia 2 modem ppp yes localip 10.0.0.1 remoteip 10.0.0.2
Step 3 - Enabling callback (OPTIONAL STEP).
Supposing that the PCMCIA modem is placed in slot2, to enable the callback feature, run the following commands in the given sequence: cli>config network pcmcia 2 modem modem>ppp yes modem>enablecallback yes modem>callbacknum 55552515 localip 10.0.0.1 remoteip 10.0.0.2
Step 4 - Activating the configuration.
cli>config runconfig
Step 5 - Save the configuration.
cli>config savetoflash
Step 6 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
Step 7 - Creating users.
The CLI does not automatically provide the PPP nor the system users addition,
so you will have to add them through the shell. Please see: “Create a user name in
/etc/ppp/pap-secrets.” on page 258
and
“Create the user for login in the Radius server.” on page 258
.
To setup the client side, please see:
“Client Side Setup” on page 262
BLACK BOX® CS Command Reference Guide
263
GSM Card Configuration
This works for firmware 2.1.3 and up. The GSM card can be used either as Dial-in or
Dial-out profile, but both will be connected through GSM modulation. You also have the option to close a ppp connection using GSM (CLI mode). All these options will be shown in the steps below:
VI Method
Step 1 - In /etc/mgetty/mgetty.config, add this entry: port ttyS2 data-only y init-chat "" \d\d\d+++\d\d\dATZ OK
Where ttyS2 may have to be changed to the serial port that will be assigned to the
GSM card, eg. replace ttyS2 by ttyS9 for an CS8.
Step 2 - If the SIM card needs a PIN, edit /etc/pcmcia/serial.opts. Uncomment
the line
INITCHAT="- \d\d\d+++\d\d\datz OK at+cpin=1111 OK" and replace '1111' by the PIN.
Step 3 - Add '/etc/mgetty/mgetty.config' to /etc/config_files and call saveconf:
# echo /etc/mgetty/mgetty.config >> /etc/config_files
# saveconf
Insert the card. The card should flash red first. After the PIN is sent, the LED stays red, until the card found network. It then flashes green.
CLI Method
To configure a GSM PCMCIA card using the CLI, follow the steps:
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Configuring the GSM parameters.
Depending the way you wish to use the GSM card, some parameters do not need to be configured. Here we will explain all configurable parameters:
264
PIN NUMBER: The command below will configure 1010 as PIN number: cli>config network pcmcia 2 gsm pin 1010
LOCALIP/REMOTEIP: Just configure it if you want to establish a PPP connection. The first command below defines the unit’s local IP address and the second one the other side IP address.
cli>config network pcmcia 2 gsm localip cli>config network pcmcia 2 gsm remoteip
ENABLECALLBACK: Configure it if you want to call back another GSM modem.
cli>config network pcmcia 2 gsm enablecallback yes callbacknum 5552255
Step 3 - Activating the configuration.
cli>config runconfig
Step 4 - Save the configuration.
cli>config savetoflash
Step 5 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
BLACK BOX® CS Command Reference Guide
265
CDMA Card Configuration
CDMA cards are in fact modem cards that makes it possible for CS to receive a dial-in connection and callback using the “ppp” protocol.
CDMA card configuration is made by setting the following parameters, which are similar to the parameters set in a modem card.
Parameter Description
Local and Remote IP addresses (optional)
IP addresses used by “ppp” connection and set in /etc/ppp/options.ttyXX file, where XX is the serial port being configured.
Phone number
(optional)
Speed
Additional
Initialization
(optional)
The syntax is local_IP:remote_IP
This number will be used by the callback feature when activated and set in /etc/mgetty/login.config file.
This parameter defines the speed that CS uses to access the card. The parameter is set in /etc/mgetty/mgetty.config file.
Set an additional initialization parameter to be sent to the card. There is a default command sequence to initialize the card, but if an additional initialization command is required by the card, it can be added using the feature.
The command sequence is set in /etc/mgetty/mgetty.config file.
Table 7.1: CDMA configuration parameters
vi Method
Step 1 - In /etc/mgetty/mgetty.config, add this entry: port ttyxx speed 57600 data-only y init-chat "" \d\d\d+++\d\d\dATZ OK AT$QCVAD=4 OK
Where xx is the serial port number that will be assigned to the CDMA card.
Step 2 - In /etc/pcmcia/serial.opts, add this entry:
266
*,0,*)
INFO="Modem Slot 1 Setup"
LINK="/dev/modem"
INITCHAT="- \d\d\d+++\d\d\datz OK"
INITTAB="/sbin/mgetty" start_fn () { return; } stop_fn () { return; }
NO_CHECK=n
NO_FUSER=n
;;
Step 3 - If configuring a local and remote IP, modify local_IP:remote_IP entry
in /etc/ppp/options.ttyXX file.
Step 4 - To enable the call back feature, add the following entry to
/etc/mgetty/login.config
PSEUDO_CB_NAME - - /sbin/callback -S PHONE (PSEUDO_CB_NAME=cbuser)
*
At the end of the login.config file there is a line similar to the following:
/bin/login @
Enter the below command before the above mentioned line:
<pseudo callback name>/sbin/callback -S <phone number of the client> for example: call /sbin/callback -S 5551212
Where, 'call' is the pseudo callback name and '5551212' is the number to dial back.
CLI Method
To configure a CDMA PCMCIA card using the CLI method, follow the below steps:
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Configuring the CDMA parameters.
To configure speed
BLACK BOX® CS Command Reference Guide
267
cli>config network pcmcia <slot> cdma speed <speed>
To configure local IP and remote IP to establish a PPP connection cli>config network pcmcia <slot> cdma localip <ip_address> cli>config network pcmcia <slot> cdma remoteip <ip_address>
To enable the callback option cli>config network pcmcia <slot> cdma enablecallback <yes> callbacknum
<number>
To include additional initialization command cli>config network pcmcia <slot> cdma addinit <command>
Step 3 - Activate the configuration.
cli>config runconfig
Step 4 - Save the configuration.
cli>config savetoflash
Step 5 - Exiting the CLI mode.
To exit the CLI mode and return to the CS’s shell, type the following command: cli> quit
268
ISDN PC Cards
You can establish synchronous PPP connections with ISDN cards. The ipppd is the daemon that handles the synchronous PPP connections.
VI Method
How to configure dial in.
Step 1 - Create a user.
Create a user in /etc/ppp/pap-secrets or in /etc/ppp/chap-secrets, depending if you want PAP or CHAP authentication. You will also have to create a user in
/etc/ppp/pap-secrets if you want radius or local authentication. In case you don't want to repeat all the user database from the radius server an option is to use '*' as the user in /etc/ppp/pap-secrets:
* * "" *
Step 2 - Change the options in /etc/pcmcia/isdn.opts to fit your environment.
Make sure that $DIALIN is set to "yes." Set the desired authentication in
DIALIN_AUTHENTICATION. For instance, "+pap" for PAP, "+chap" for CHAP,
"login auth" or "login +pap" for radius, "login auth" or "login +pap" for local.
When "login auth" or "login +pap" are used, PAM libraries are used so
/etc/pam.d/login should be also configured.
Step 3 - Run saveconf to save your changes to the flash.
Step 4 - If the ISDN card is not inserted, it is time to insert the card.
ipppd is started automatically. Go to step 6.
Step 5 - Restart script.
If the card was already inserted, you will need to restart the isdn script to re-load any changed configuration. To restart the script, issue:
# /etc/pcmcia/isdn stop ippp0
# /etc/pcmcia/isdn start ippp0
Step 6 - You can dial from the remote system to the CS, and get a PPP connection.
Step 7 - To hang up the connection from the CS side, just issue:
# isdnctrl hangup ippp0
BLACK BOX® CS Command Reference Guide
269
How to configure dial out.
Step 1 - Create a user.
Create a user in /etc/ppp/pap-secrets or in /etc/ppp/chap-secrets,depending if you want PAP or CHAP authentication.
Step 2 - Change options.
Change the options in /etc/pcmcia/isdn.opts to fit your environment. Make sure that $DIALIN is set to "no". Set $USERNAME to the user name provided by your
ISP.
Step 3 - Run saveconf to save your changes to the flash.
Step 4 - If the ISDN card is not inserted, it is time to insert the card.
ipppd is started automatically. Go to step 6.
Step 5 - Restart script.
If the card was already inserted, you will need to restart the isdn script to reload any changed configuration. To restart the script, issue:
# /etc/pcmcia/isdn stop ippp0
# /etc/pcmcia/isdn start ippp0
Step 6 - To dial out, issue the command:
# isdnctrl dial ippp0
Step 7 - To hangup the connection from the CS side, just issue:
# isdnctrl hangup ippp0
Establishing a Callback with your ISDN PC Card
For the same cost saving reasons explained in Establishing a Callback with your Modem
PC Card, the ISDN card in the CS can be configured to callback client machines after receiving dial in calls.
The steps to allow callback are divided into two parts. Part One is the configuration for the CS (CS Setup) as callback server. Part Two is the configuration of a Windows 2000
Professional computer as callback client.
CS setup (Callback Server).
270
Step 1 - Change the parameters in /etc/pcmcia/isdn.opts to fit your environment.
Step 2 - Set the callback number in DIALOUT_REMOTENUMBER:
DIALOUT_REMOTENUMBER="8358662" # Remote phone that you want to dial to
Step 3 - If your isdn line supports caller id, it is recommended that you also
configure the DIALIN_REMOTENUMBER and enable secure calls. Otherwise
skip to step 4.
DIALIN_REMOTENUMBER="8358662" #Remote phone from which you will receive
# calls
SECURE="on" # "on" = incoming calls accepted only if
# remote phone matches DIALIN_REMOTENUMBER;
# "off" = accepts calls from any phone. "on"
# will work only if your line has the caller
# id info.
Step 4 - Make sure the CALLBACK is set to “in” in /etc/pcmcia/isdn.opts file.
CALLBACK="in" # "in" will enable callback for incoming calls.
Step 5 - Uncomment line with user "mary" in /etc/ppp/pap-secrets.
Step 6 - Save changes to flash.
# saveconf
Step 7 - Activate the changes by stopping and starting the isdn script:
# /etc/pcmcia/isdn stop ippp0
# /etc/pcmcia/isdn start ippp0
The CS side is done.
Windows 2000 Professional configuration (Callback Client).
Step 1 - Create user “mary” with password “marypasswd” in Control Panel->
"User and Passwords".
Step 2 - Create a dial-up connection that uses “Modem - AVM ISDN Internet
(PPP over ISDN) (AVMISDN1)”.
BLACK BOX® CS Command Reference Guide
271
(To create a dial-up connection, go to Start->Settings->Network and Dial-up
Connections->Make New Connection, select “I want to set up my Internet connection manually, or I want to connect through a local area network”, select “I connect through a phone line and a modem”, select the “AVM ISDN Internet (PPP over ISDN)” modem, type the phone number you dial to connect to the CS, and enter mary as User name and marypasswd as password.). After creating this dialup, click on the Properties of this dial-up, select the “Options” panel, and change the redial attempts to 0.
Step 3 - Accept incoming connections.
To accept incoming connections, go to Start->Settings->Network and Dial-up
Connections->Make New Connection, select “Accept incoming connections” (the words are slightly different in XP), select AVM ISDN Internet (PPP over ISDN), select “Do not allow virtual private connections”, click the user “mary”, then click on Properties of TCP/IP to specify the IP addresses for the calling computers. Also in “mary” Properties, select the Callback tab and make sure the option “Do not allow callback” is selected. After any change in the Incoming Connection
Properties, it is recommended that the Windows is rebooted to apply the changes.
The Windows side is done.
Now you can dial from Windows to the CS. Go to Start-> Settings-> “Network and Dialup Connections” and select the dial-up that you created. After the “Dialing” message, you will see a window with a warning message:
Opening port....
Error 676: The phone line is busy.
Just click Cancel. In a few seconds, the CS will call you back, and you will see the connection icon in the task bar.
Establishing a Callback with your ISDN PC Card (2nd way)
The previous section explained how to do callback at D-Channel level. The advantages of having callback at D-Channel level is that it works independent of the Operating
System on the client side. But a big disadvantage is that the callback call happens before the authentication phase in PPP. The only security is by that only calls from predefined phone numbers are accepted.
To fix that drawback, this section explains another way to have callback with the CS. The steps described here will work when the remote side is a UNIX machine, not Windows.
The callback call will happen after the PPP authentication is successful.
CS Setup (Callback Server).
272
Step 1 - Change the parameters in /etc/pcmcia/isdn.opts file to fit your
environment.
Step A - Set the callback number in DIALOUT_REMOTENUMBER.
DIALOUT_REMOTENUMBER="8358662" # Remote phone that you want to dial to
Step B - Configure the DIALIN_REMOTENUMBER.
If your ISDN line supports caller id, it is recommended that you also configure the DIALIN_REMOTENUMBER and enable secure calls. Otherwise skip to Step
C.
DIALIN_REMOTENUMBER="8358662" # Remote phone from which you will receive
# calls
SECURE="on" # "on" = incoming calls accepted only if
# remote phone matches DIALIN_REMOTENUMBER;
# "off" = accepts calls from any phone. "on"
# will work only if your line has the caller
# id info.
Step C - Set the desired IPs for local and remote machines.
Step D - Set DIALIN to “yes”.
DIALIN="yes" # "yes" if you want dial in, "no" if you want dial out
Step E - Make sure the CALLBACK parameter is disabled.
CALLBACK="off" # "off" = callback disabled.
Step F - Add the user that will callback the client in
DIALIN_AUTHENTICATION.
DIALIN_AUTHENTICATION="auth login user mary"
Step 2 - Make sure /etc/pam.d/ has the configuration files you want (e.g., radius).
This step is only required if you are using “auth login” in
DIALIN_AUTHENTICATION. When using “auth login,” /etc/pam.d/ is what defines which authentication will be used.
Step 3 - Add the user "mary" in /etc/ppp/pap-secrets.
Step 4 - Uncomment lines in /etc/ppp/auth-up.
Step 5 - Save changes to flash:
# saveconf
BLACK BOX® CS Command Reference Guide
273
Step 6 - Activate the changes by stopping and starting the isdn script:
# /etc/pcmcia/isdn stop ippp0
# /etc/pcmcia/isdn start ippp0
Linux (Callback Client).
Step 1 - Configure the ipppd to have user mary and pap authentication.
Step 2 - Dial to the CS:
# isdnctrl dial ippp0
Step 3 - As soon the CS authenticates the user mary, the CS will disconnect and callback.
CLI Method - ISDN PCMCIA
To configure an ISDN PCMCIA card using the CLI, follow the steps:
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Configuring ISDN parameters.
Depending the way you wish to use the ISDNISDN card, some parameters do not need to be configured. Here we will explain all configurable parameters:
LOCALIP/REMOTEIP: Just configure it if you want to establish a PPP connection. The first command below defines the unit’s local IP address and the second one the other side IP address.
cli>config network pcmcia 2 isdn localip cli>config network pcmcia 2 isdn remoteip
ENABLECALLBACK: Configure it if you want to call back another ISDN modem.
cli>config network pcmcia 2 isdn enablecallback yes callbacknum 55552244
Step 3 - Activating the configuration.
cli>config runconfig
274
Step 4 - Save the configuration.
cli>config savetoflash
Step 5 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli>quit
BLACK BOX® CS Command Reference Guide
275
7.3 Media Cards
Media cards (compact flash, hard drives) are small memory cards with a capacity up to
5 Gigabytes. They can be used like a normal hard disk drive using IDE. Using an adapter,
CF cards can be used in PCMCIA slots. Such an adapter is very cheap, because the
PCMCIA and CF card standard are the same, only the pin layout and the socket is different. On the market, there are also small PCMCIA hard drives available, eg. a drive from Toshiba with a capacity of 5GB (Toshiba MK5002MPL). CF card support can be used in the CS for storing files. This would be especially useful for example to save the configuration. CF cards cannot be rewritten indefinitely. For this reason, CF should not be used for logging.
For data buffering, a PCMCIA hard drive is ideal:
•
data will not be lost on power loss / crash / reboot of the CAS.
•
no dependency on an NFS server that may fail.
How it works
When inserting an adapter with a CF card or a PCMCIA hard drive, an ide device appears. This can be mounted, eg. by:
# mkdir /mnt/ide
# mount /dev/hda1 /mnt/ide
Apart from the ext2 filesystem, the VFAT filesystem will be supported. This makes it easy to exchange data with a Windows system. To create a vfat filesystem, the it is possible to run the utility mkdosfs .
To initialize a card with VFAT, do:
# echo ",,0x0e" | sfdisk /dev/hda
# mkdosfs /dev/hda1 for ext2 filesystem, do:
# echo ",,L" | sfdisk /dev/hda
The "mke2fs" utility, is the system creator for ext2 filesystems, and can be run like the following example:
# mke2fs /dev/hda1
In addition, an utility to create or partition the CF has been added. For this, the program sfdisk will be used. sfdisk can be easily used for scripting, so it can be called from the prompt shell.
276
To check an ext2 or vfat filesystem, the utility fsck has been added.
# fsck -t <ftype> /dev/<hdxx>
When the card is inserted, cardmgr loads the ide-cs module, which depends on ide-
mod.o. This in turn loads ide-probe-mod.o, which recognizes the CF as a disk, and ide-
disk.o will be loaded. From this point on, the partitions (usually one) can be mounted using mount. If the filesystem is vfat, the modules fat.o and vfat.o will be loaded.
VI Method - Configuration
Step 1 - Insert the card.
Step 2 - Automatic compact flash mounting.
The compact flash will mount automatically because by default, the parameter
DO_MOUNT is set to YES in the /etc/pcmcia/ide.opts file. Below is an example of the file:
# ATA/IDE drive adapter configuration
# The address format is "scheme,socket,serial_no[,part]".
#
# For multi-partition devices, first return list of partitions in
# $PARTS. Then, we'll get called for each partition.
case "$ADDRESS" in
*,*,*,1)
#INFO="Sample IDE setup"
DO_FSTAB="y" ; DO_FSCK="n" ; DO_MOUNT="y"
FSTYPE="vfat"
#OPTS=""
MOUNTPT="/mnt/ide"
[ -d $MOUNTPT ] || mkdir $MOUNTPT
;;
*,*,*)
PARTS="1"
# Card eject policy options
NO_CHECK=n
NO_FUSER=n
;; esac
File Description 7.4: /etc/pcmcia/ide.opts file
These parameters can be changed:
BLACK BOX® CS Command Reference Guide
277
•
DO_FSTAB - If set to 'y', an entry in /etc/fstab will be created. This parameter defaults to "n" if not mentioned in the /etc/pcmcia/ide.opts file.
•
DO_FSCK - A boolean (y/n) setting. Specifies if the filesystem should be checked before being mounted. This parameter defaults to “n” in the /etc/pcmcia/ide.opts file.
•
DO_MOUNT - If set to ‘y’, the card will be mounted automatically upon insertion.
This parameter defaults to ‘n’ if not mentioned in the /etc/pcmcia/ide.opts file.
•
FS_TYPE - Can be either 'vfat' or 'ext2'. Determines the filesystem type.
•
MOUNTPT - The mount point where the partition will be mounted.
•
NO_CHECK/NO_FUSER - Boolean (y/n) settings for card eject policy. If
NO_CHECK is true, then “cardctl eject” will shut down a device even if it is busy.
If NO_FUSER is true, then the script will not try to kill processes using an ejected device. These parameters defaults to "n" if not mentioned in the
/etc/pcmcia/ide.opts file.
•
PARTS - A list of partitions to be mounted. The conf file will be called again for each partition. In the example above, there is an entry only for partition '1', but you can eg. set PARTS="1 3 4" and add entries for the case statement like:
*,*,*,3)
# settings for partition 3
;;
*,*,*,4)
# settings for partition 4
;;
To give different configuration for slot 0 and 1, the second parameter in the case statement can be used. For example:
*,0,*,1)
# settings for slot 0
;;
*,1,*,1)
# settings for slot 1
;;
Step 3 - Save the configuration.
To save any configuration done in the /etc/pcmcia/ide.opts file is necessary to run the command:
# saveconf
WARNING:
Before removing the media pcmcia card from the CS you MUST run “cardctl eject”, otherwise data might not be correctly written to disk and result in corruption of the media. Correct operation of the CS is not guaranteed if eject is not executed.
278
CLI Method - Media Cards PCMCIA
Mounting PCMCIA storage devices using the CLI is extremely simple. Just follow the steps below:
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Enabling the Compact Flash or mini hard drive.
Supposing that the PCMCIA card is placed on slot 1 of the unit, run the command: cli>config network pcmcia 1 cflash enable yes
To enable data buffering on this device run the command: cli>config network pcmcia 2 cflash databuf yes
Step 3 - Activating the configuration.
cli>config runconfig
Step 4 - Save the configuration.
cli>config savetoflash
Step 5 - Check the configuration
The device should be mounted under the /mnt/ide directory.
Step 6 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
WARNING:
Before removing the media pcmcia card from the CS you MUST run “cardctl eject”, from the shell prompt (not possible using the CLI), otherwise data might not be correctly written to disk and result in corruption of the media. Correct operation of the CS is not guaranteed if eject is not executed.
How to Save/Load Configuration to/from CF/IDE
It is also possible to save and restore the configuration file to/from any PCMCIAconnected file system. By configuring the saveconf utility, you can enable the CS to save the configuration to PCMCIA-mounted file system and define the type of the configuration saved in the device.
BLACK BOX® CS Command Reference Guide
279
There are two ways in which the admin can define this feature:
•
default - the system will apply the configuration in the storage device to the current running system after reboot
•
replace - the system will use the configuration in the storage device to replace the existing one in the internal flash of the CS.
The PCMCIA cards are detected when they are inserted in the slot. If the card is a storage device (Compact Flash or IDE), the system mounts the file system ext2 in the /mnt/ide directory.
During the boot time, before the call of the restoreconf from the internal flash, the system checks for the existence of a config file in the /mnt/ide/proc/flash/script directory. If the
DEFAULT flag is set, the system will use the file in the storage device as the config file.
If the DEFAULT flag is not set then the system will use the file in internal flash as the config file.
Saveconf Utility. The syntax is:
# saveconf sd [default | replace]
The saveconf utility will allow to save configuration to PCMCIA mounted file system and will define the type of the configuration saved in the device. The administrator can define the following types :
•
default: the configuration in the storage device should be applied to the current running system after reboot
•
replace: the configuration in the storage device should be used to replace the existing in the internal flash of the CS.
The saveconf utility creates one file in the storage device to save the default and replace flags. The filename is: /mnt/ide/proc/flash/storageOptions and it can contain the words
DEFAULT and/or REPLACE.
Restoreconf Utility. The syntax is :
# restoreconf sd [default | replace]
The restoreconf utility can read the configuration from storage device mounted file system and do the following actions:
•
default: the configuration is used as the config file (it overrides the internal flash configuration during the boot time)
•
replace: the configuration is copied to the internal flash and is used as the config file.
280
CLI Method: backupconfig
To save/restore the configuration to/from a PCMCIA media card follow the steps below:
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Saving the configuration to a Storage Device:
cli> administration backupconfig saveto sd [default] [replace]
Step 3 - Restoring the configuration from a Storage Device:
cli> administration backupconfig loadfrom sd
Step 4 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
Generic Dial-Out
This feature allows an application to connect from a central office to a remote location to inquire system status. The remote system can then send asynchronous alarm notification to the application at the central office.
The connection between the central office and the remote location can be done using
TCP/IP over an Ethernet network (In-Band), or through a GSM/GPRS and
CDMA/1xRTT profiles (Out-of-Band).
Currently “dial-out” application is supported. Use the “/etc/generic-dial.conf” file to configure dial-out ppp connections through a GPRS and 1xRTT profiles. The following example illustrates a dial-out configuration with a wireless ppp connection. The text in bold type face indicates edited text.
BLACK BOX® CS Command Reference Guide
281
The tail of the file /etc/generic-dial.conf
#begin dial-out testApp
#
#inPort.name InPort
#inPort.device /dev/ttyS1
#
#outPort.name OutPort
#outPort.pppcall wireless
#outPort.remote_ip 200.246.93.87
#outPort.remote_port 7001
#
#appl.retry 7
#
#end dial-out
The content of the file /etc/ppp/peers/wireless nodetach
#debug
/dev/ttyM1
57600 crtscts lock noauth
#nomagic user claro show-password noipdefault defaultroute ipcp-accept-local ipcp-accept-remote noproxyarp novj novjccomp lcp-echo-interval 0 connect '/usr/local/sbin/chat -v -t3 -f /etc/chatscripts/wireless'
Configuring the generic-dial.conf
The file "/etc/generic-dial.conf" contains sections that corresponds to instances of generic-dial applications. For example,
282
# begin <application-type> [instanceID]
#....
#....
# end <application-type>
Where [instanceID] is an optional string to identify a particular instance, and
<application type> corresponds to specific application(s) built over the infrastructure.
Within each application the parameters needed to create the objects for that specific instance is inserted.
Configuring Generic Dial-Out
Step 1 - To enable the generic dial-out application, configure the desired ports
with the protocol parameter in /etc/portslave/pslave.conf.
For example: s<N>.protocol
generic_dial
where <N> is the port number.
Step 2 - To enable dial-out for the ports chosen in pslave.conf, configure the
file /etc/generic-dial.conf as described in the following table.
Parameter
begin <dial-out> [
<instance-id>
] inPort.name <name> inPort.device </dev/ttyXX> inPort.speed <9600> inPort.datasize <8> inPort.parity [ none | even | odd ] inPort.stopbits <1>
Description
Begins the dial-out application.
Optionally specify a name for the particular instance.
A label for the incoming port to be used in log messages.
The modem device used for this interface.
Connection speed.
The number of data bits.
None, even, or odd.
The number of stop bits.
BLACK BOX® CS Command Reference Guide
283
Parameter
inPort.flowctrl [ none | hw | sw ] outPort.name <name> outPort.pppcall <filename> outPort.remote_ip <IP address> outPort.remote_port <port> outPort.connection [ permanent | on_demand ] outPort.timeout <timeout> (seconds) appl.retry <interval> (minutes) end <dial-out>
Description
Gateway or interface address used for the route.
A label for the outgoing port to be used in log messages.
Name of file that the pppd reads options from. The file is located at
/etc/ppp/peers/
filename
.
IP address of remote work station to be connected to.
Remote TCP port for connections from this interface.
Specifies how to maintain the outgoing path:
• permanent
– always connected.
• on_demand
– connects only when data enters through the serial port.
Specify the inactivity time in seconds after which the connection is dropped.
Any value other than zero enables the timeout.
Specify the time to wait before reconnecting after a connection failure.
Ends the dial-out application.
Step 3 - Configure the PPP options (pppd) in
/etc/ppp/peers/<name>
Where <name> is the same as the <filename> variable specified in the outPort.pppcall <filename>
parameter in /etc/genericdial.conf
.
The following example shows the /etc/ppp/peers/wirelss file.
284
In this example note that the “connect” script initiates the connection. The file
“wireless” executes using the “chat” automated modem communication scrip with the parameters -v (verbose mode), -t (timeout), and -f (read the chat script from the
/etc/chatscripts/wireless file).
[root@CAS root]# more /etc/ppp/peers/wireless nodetach
#debug
/dev/ttyM1
57600 crtscts lock noauth
#nomagic user claro show-password noipdefault defaultroute ipcp-accept-local ipcp-accept-remote noproxyarp novj novjccomp lcp-echo-interval 0 connect '/usr/local/sbin/chat -v -t3 -f /etc/chatscripts/wireless'
Step 4 - Edit the /etc/pcmcia/serial.opts file: a. If the SIM card (GSM) needs a PIN, uncomment the following line and replace
1111
with the PIN
.
INITCHAT="- \d\d\d+++\d\d\datz OK at+cpin=
1111
OK" b. To inactivate mgetty on the specified port so that the port will be directly controlled by the pppd application, comment out the following line.
#INITTAB="/sbin/mgetty"
Step 5 - Activate the function to automatically restart the dial-out application after reboot.
BLACK BOX® CS Command Reference Guide
285
Edit the following parameter in the /etc/daemon.d/gendial.sh file to enable the
"automatically established" feature. The script restarts the dial-out function after a reboot. a) Set the parameter as described below.
ENABLE = YES b) Save the gendial.sh configuration file by issuing the following command in
CS.
[root@CAS root]# saveconf
Step 6 - To Activate the dial-out function, issue the following command.
Note: It is not necessary to reboot the
CS
to activate the dial-out function. You can do this by restarting the GDF daemon.
[root@CAS root]# daemon.sh restart GDF
A message similar to the following displays, confirming the GDF daemon restart.
[root@CAS root]# Sep 23 18:06:10 src_dev_log@CAS showlogmsg:
/bin/daemon.sh: CONFIG: Network daemon [generic-dial] started
The default route is not replaced in the static router table. The following message displays.
[root@CAS root]# Sep 23 18:06:17 src_dev_log@CAS pppd[1028]: not replacing existing default route to eth0 [172.20.0.1]
Step 7 - To change a static route or create a new one.
a) Edit the parameters in the /etc/network/st_routes file.
b) Activate the new routes by issuing the following command:
#> runconf c) Save the new configuration to flash.
#> saveconf d) Check the routes by issuing the following command.
#> route -n
286
BLACK BOX® CS Command Reference Guide
287
288
Chapter 8
Profile Configuration
..........................................................................
Chapter 8 - Profile Configuration
This chapter begins with a table containing parameters common to all profiles, followed by tables with parameters specific to a certain profile. You can find samples of the pslave configuration files (pslave.conf, .cas, .ts, and .ras) in the /etc/portslave directory.
Then all possible profiles (CAS, TS and RAS) and the necessary parameters that need to be configured in the /etc/portslave/pslave.conf file. This chapter includes the following sections:
•
•
Examples for configuration testing
8.1 The pslave.conf file
This is the main configuration file (/etc/portslave/pslave.conf) that contains most product parameters and defines the functionality of the CS .
There are three basic types of parameters in this file:
•
conf.* parameters are global or apply to the Ethernet interface.
•
all.* parameters are used to set default parameters for all ports.
•
s#.* parameters change the default port parameters for individual ports.
An all.* parameter can be overridden by a s#.* parameter appearing later in the
pslave.conf file (or vice-versa).
TIP.
You can do a find for each of these parameters in vi, once you open this file by typing:
/ <your string>
To search the file downward for the string specified after the /.
pslave.conf common parameters
The tables below present all parameters with their respective descriptions. The first table presents parameters that are common for any profile. The second, third and fourth tables define specific parameters for CAS, TS and Dial-in profiles respectively.
Parameter
conf.dhcp_client
conf.eth_ip_alias
Description Factory Configuration
It defines the dhcp client operation mode.
Valid values:
0 - DHCP disabled
1 - DHCP active
2 - DHCP active and the unit saves the last IP assigned by the DHCP server in flash.
2
Secondary IP address for the Ethernet interface (needed for clustering feature).
0
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
conf.eth_mask_alias
Mask for the secondary IP address above.
0 conf.rlogin
conf.facility
conf.group
conf.eth_ip
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
It defines the location of rlogin utility
Note: This is a parameter specific to TS profile.
The local facility sent to syslog-ng from PortSlave.
/usr/local/bin/rlogin-radius
7
Used to group users to simplify the configuration of the parameter all.users later on. This parameter can be used to define more than one group.
0
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
Configured in Chapter 4. This is the IP address of the
Ethernet interface. This parameter, along with the next two, is used by the cy_ras program to OVERWRITE the file /etc/network/ifcfg_eth0 as soon as the command
“runconf” is executed. The file /etc/network/ifcfg_eth0 should not be edited by the user unless the cy_ras configuration is not going to be used.
0 (IP address received from DHCP Server)
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
Table 8.1: /etc/portslave/pslave.conf common parameters
290
Parameter
conf.eth_mask
conf.eth_mtu
conf.lockdir
all.dcd all.users
Description Factory Configuration
The mask for the Ethernet network.
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
0 (IP mask received from
DHCP Server)
The Maximum Transmission Unit size, which determines whether or not packets should be broken up.
1500
The lock directory, which is /var/lock for the CS . It should not be changed unless the user decides to customize the operating system.
/var/lock
DCD signal (sets the tty parameter CLOCAL). Valid values are 0 or 1. If all.dcd=0, a connection request will be accepted regardless of the DCD signal and the connection will not be closed if the DCD signal is set to
DOWN. If all.dcd=1 a connection request will be accepted only if the DCD signal is UP and the connection will be closed if the DCD signal is set to
DOWN.
0
Restricts access to ports by user name (only the users listed can access the port or, using the character “!”, all but the users listed can access the port.) In this example, the users joe, mark and members of user_group cannot access the port. A single comma and spaces/tabs may be used between names. A comma may not appear between the “!” and the first user name.
The users may be local, Radius or TacacsPlus. User groups (defined with the parameter conf.group) can be used in combination with user names in the parameter list. Notice that these are common users, not administrators.
null
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
Table 8.1: /etc/portslave/pslave.conf common parameters
BLACK BOX® CS Command Reference Guide
291
Parameter
all.issue
all.prompt
all.media
all.netmask
all.mtu
all.mru
all.sysutmp
Description Factory Configuration
This text determines the format of the login banner that is issued when a connection is made to the CS . \n represents a new line and \r represents a carriage return.
Expansion characters can be used here. The default parameter is:
See Description column
\r\n\
Welcome to Console Server Management Server
%h port S%p \n\
\r\n
This text defines the format of the login prompt.
Expansion characters can be used here.
%h login:
It defines media type RS232/RS484 and operation mode half/full duplex.
Valid values for all products :
•
rs232 - RS232 (default value).
•
rs232_half - RS232 with RTS legacy half duplex
•
rs232_half_cts - RS232 with RTS legacy half duplex and CTS control rs232
Valid values for the CS1 only :
•
rs485_half - RS485 half duplex with out terminator
•
rs485_half_terminator - RS485 half duplex with terminator
•
rs485_full_terminator - RS485 full duplex with terminator
•
rs422 - alike rs485_full_terminator
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
It defines the network mask for the serial port.
It defines the maximum transmit unit
255.255.255.255
1500
It defines the maximum receive unit
It defines whether portslave must write login records.
Valid values are yes or no.
1500
1
Table 8.1: /etc/portslave/pslave.conf common parameters
292
Parameter
all.pmtype
all.pmusers
all.pmkey
all.sttyCmd
Description
Name of the IPDU manufacturer.
Factory Configuration
null
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
List of the outlets each user can access.
null
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
The hotkey that identifies the power management command.
off
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
The TTY is programmed to work as configured and this user-specific configuration is applied over that serial port. Parameters must be separated by a space.
The following example sets :
-igncr
This tells the terminal not to ignore the carriage-return on input,
-onlcr
Do not map newline character to a carriage return or newline character sequence on output, opost
Post-process output,
-icrnl
Do not map carriage-return to a newline character on input. all.sttyCmd -igncr -onlcr opost -icrnl
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
null
Table 8.1: /etc/portslave/pslave.conf common parameters
BLACK BOX® CS Command Reference Guide
293
Parameter
all.utmpfrom
all.radnullpass
all.speed all.datasize
all.stopbits
all.parity
all.authtype
Description
It allow the administrator to customize the field
"FROM" in the login records (utmp file). It is displayed in the "w" command.
The default value is "%g:%P.%3.%4"
%g : process id
%P : Protocol
%3 : Third nibble of remote IP
%J : Remote IP
Factory Configuration
"%g:%P.%3.%4"
Note: In the pslave.conf file there is a list of all expansion variables available.
It defines whether the access to users with null password in the radius server must be granted or not.
The speed for all ports.
The data size for all ports.
The number of stop bits for all ports.
The parity for all ports.
0
Configured in Chapter 2, “Device Authentication” on page 53 . Type of authentication used. There are
several authentication type options:
• none
(no authentication)
•
local (authentication is performed using the
/etc/passwd file)
•
remote (This is for a terminal profile only. The unit takes in a username but does not use it for authentication. Instead it passes it to the remote server where it is then used for authentication.)
•
radius (authentication is performed using a
Radius authentication server)
•
TacacsPlus (authentication is performed using a
TacacsPlus authentication server)
•
ldap (authentication is performed against an ldap database using an ldap server. The IP address and other details of the ldap server are defined in the file /etc/ldap.conf) none
9600
8
1 none
Table 8.1: /etc/portslave/pslave.conf common parameters
294
Parameter
all.authtype
continuation...
Description
•
kerberos (authentication is performed using a kerberos server. The IP address and other details of the kerberos server are defined in the file
/etc/krb5.conf)
•
local/radius (authentication is performed locally first, switching to Radius if unsuccessful)
•
radius/local (the opposite of the previous option)
•
local/TacacsPlus (authentication is performed locally first, switching to TacacsPlus if unsuccessful)
•
TacacsPlus/local (the opposite of the previous option)
•
RadiusDownLocal (local authentication is tried only when the Radius server is down)
•
TacacsPlusDownLocal (local authentication is tried only when the TacacsPlus server is down)
•
kerberosDownLocal (local authentication is tried only when the kerberos server is down)
•
ldapDownLocal (local authentication is tried only when the ldap server is down)
•
NIS - All authentication types but NIS follow the format all.authtype <Authentication> DownLocal or <Authentication> (e.g. all.authtype radius or
radiusDownLocal or ldap or ldapDownLocal, etc). NIS requires all.authtype to be set as local, regardless if it will be "nis" or its “Downlocal" equivalent. The service related to "nis" or its
“Downlocal" equivalent would be configured in the /etc/nsswitch.conf file, not in the
/etc/portslave/pslave.conf file.
Factory Configuration
all.break_sequence
This parameter is the string that is used to send a break to the TTY. It is only valid if TTY protocol is socket_ssh, socket_server, or socket_server_ssh.
~break all.break_interval
Note: This parameter controls the authentication required by the CS . The authentication required by the device to which the user is connecting is controlled separately.
This parameter defines the break duration in milliseconds. It is valid if TTY protocol is socket_ssh,socket_server, socket_server_ssh, or ssh-2
(client).
500
Table 8.1: /etc/portslave/pslave.conf common parameters
BLACK BOX® CS Command Reference Guide
295
Parameter
all.flow
Description Factory Configuration
This sets the flow control to hardware, software, or none.
none
Table 8.1: /etc/portslave/pslave.conf common parameters
296
Parameter
all.protocol
Description Factory Configuration
Defines the protocol used to connect with the CS . For each profile there are some valid values:
•
CAS profile:
- socket_server when Telnet is used.
- socket_ssh when SSHv1 or SSHv2 is used.
- socket_server_ssh when Telnet or SSHv1 or SSHv2 is
used.
- raw_data to exchange data in transparent mode. It is similar to “socket_server” mode, but without Telnet negotiation, breaks to serial ports, etc.
•
TS profile:
- login requests username and password.
- rlogin receives username from the CS and requests a password.
- Telnet
- SSHv1
- SSHv2
- socket_client
If the protocol is configured as Telnet or socket_client the socket_port parameter needs to be configured.
•
Bidirectional Telnet profile: socket_server (CAS), and login (TS)
•
RAS profile: slip, cslip, ppp, ppp_only
•
Power Management: ipdu
•
Serial Printer : lpd
•
Billing profile: billing socket_server
CS1001 only:
•
Automation profile: "modbus", in this case, serial mode can be ascii or rtu. To enable "modbus" it is necessary to uncomment the related line as shown below:
# Modbus/TCP Protocol modbus stream tcp nowait.1000
root /bin/modbusd modbusd
Then, enable it by running the command: daemon.sh restart NET
•
PPP over leased lines (only authentication
PAP/CHAP): “ppp_only”
•
PPP with terminal post dialing (Auto detect PPP):
“ppp”
Table 8.1: /etc/portslave/pslave.conf common parameters
BLACK BOX® CS Command Reference Guide
297
Parameter
all.web_WinEMS
all.xml_monitor
all.translation
sX.pmoutlet
s1.tty
Description Factory Configuration
Defines whether or not management of Windows
Emergency Management Service is allowed from the
Web.
no
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
A non-zero value activates XML monitoring. All XML data received from the port is captured and sent to syslog-ng with facility LOCAL<DB_facility> and priority INFO. The format of the message is
"XML_MONITOR (ttySx) [data]". XML tags are sent by Windows Server 2003 Emergency Management
Services during boot or crash. You can read more on
XML_MONITOR in:
/etc/syslog-ng/syslog-ng.conf
0
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
Defines whether or not to perform translation of Fnkeys (e.g. F8 key) from one terminal type to VT-UTF8.
Currently only translation from xterm to VT-UTF8 is supported.
null
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
sX indicates the serial port number to which the PM hardware is connected. The pmoutlet part of the parameter indicates the outlet # on the PM hardware that manages the server/network equipment in question.
8
The device name for the port is set to the value given in this parameter. If a device name is not provided for a port, it will not function.
disabled
Note: This parameter is disable by default. To activate, uncomment the parameter.
Table 8.1: /etc/portslave/pslave.conf common parameters
298
pslave.conf CAS (Console Access Server) parameters
You can configure additional CAS features with the parameters given on the following tables.
In addition to the above parameters which are common to all local and remote access scenarios, you can also configure the following parameters for additional options. Many of the parameters are unique to CAS, but some also apply to TS and Dial-in port profiles.
These are going to be indicated in the appropriate instances.
Parameter Description Factory Configuration
conf.nfs_data_buffering
This is the Remote Network File System where data captured from the serial port will be written instead of being written to the local directory /var/run/DB. The directory tree to which the file will be written must be
NFS-mounted, so the remote host must have NFS installed and the administrator must create, export and allow reading/writing to this directory. The size of this file is not limited by the value of the parameter all.data_buffering, though the value cannot be zero since a zero value turns off data buffering. The size of the file is dependent on the NFS server only (hard drive, partition size, etc.).
null conf.DB_facility
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
This value (0-7) is the Local facility sent to the syslog with the data when syslog_buffering is active. The file
/etc/syslog-ng/syslog-ng.conf contains a mapping between the facility number and the action (see more
on Section 5.4, “Syslog-ng,” on page 159
).
7
Table 8.2: CAS specific parameters for the pslave.conf
BLACK BOX® CS Command Reference Guide
299
Parameter
conf.nat_clustering_ip
all.ipno
all.netmask
all.DTR_reset
all.break_sequence
all.break_interval
Description Factory Configuration
IP address of any CS interface (master box). It is a public IP address (e.g. Ethernet's interface IP address) and it is the one that must be used to connect the slave's serial ports. You can use the same value assigned to the Ethernet's IP address as that of the master box in the chain.
0
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
This is the default IP address of the CS 's serial ports.
The “+” indicates that the first port should be addressed as 192.168.1.101 and the following ports should have consecutive values. Any host can access a port using its IP address as long as a path to the address exists in the host's routing table.
0
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
It defines the network mask for the serial port.
255.255.255.255
This parameter specifies the behavior of the DTR signal in the serial port. If set to zero the DTR signal will be ON if there is a connection to the serial port, otherwise OFF. If set from 1 to 99 the DTR signal will be always ON. A value greater or equal 100 specifies for how long (in milliseconds) the DTR signal will be turned off before it is turned back on again when a connection to the serial port is closed.
100
This parameter is the string that is used to send a break to the TTY. It is only valid if TTY protocol is socket_ssh, socket_server, or socket_server_ssh.
~break
This parameter defines the break duration in milliseconds. It is valid if TTY protocol is socket_ssh.
500
Table 8.2: CAS specific parameters for the pslave.conf
300
Parameter
all.modbus_smode
Description Factory Configuration
Communication mode through the serial ports. This parameter is meaningful only when modbus protocol is configured. The valid options are ascii (normal
TX/RX mode) and rtu (some time constraints are observed between characters while transmitting a frame). If not configured, ASCII mode will be assumed.
ascii all.lf_suppress
all.auto_answer_input
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
This can be useful because Telneting (from DOS) from some OS such as Windows 98 causes produces an extra line feed so two prompts appear whenever you press Enter. When set to 1, line feed suppression is active which will eliminate the extra prompt. When set to 0 (default), line feed suppression is not active.
0
This parameter works in conjunction with
all.auto_answer_output. It allows you to configure a string that will be matched against all data coming in from the tty (remote server). If there is a match, the configured output string (auto_answer_output) will then be send back to the tty. This parameter works only when there is no session to the port. If uncommented and a string of bytes is set, matching occurs whenever there is not session established to the port. If this parameter is commented out, then no checking and matching occurs.
null
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
Table 8.2: CAS specific parameters for the pslave.conf
BLACK BOX® CS Command Reference Guide
301
Parameter
all.auto_answer_output
all.poll_interval
Description Factory Configuration
This parameter works in conjunction with
all.auto_answer_input. It allows you to configure a string that is sent back to the remote server whenever the incoming data remote server matches with
all.auto_answer_input. This parameter works only when there is no session to the port. If this parameter is commented, then nothing will be sent back to the remote server even if all.auto_answer_input is uncommented. If this parameter is uncommented and if all.auto_answer_input is also uncommented, then the string configured will be sent back to the remote server.
null
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
Valid only for protocols socket_server and raw_data.
When not set to zero, this parameter sets the wait for a
TCP connection keep-alive timer. If no traffic passes through the CS for this period of time, the CS will send a line status message to the remote device to see if the connection is still up. If not configured, 1000 ms is assumed (the unit for this parameter is ms). If set to zero, line status messages will not be sent to the socket client.
1000
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
Table 8.2: CAS specific parameters for the pslave.conf
302
Parameter
all.socket_port all.data_buffering
Description Factory Configuration
In the CAS profile, this defines an alternative labeling system for the CS ports. The “+” after the numerical value causes the serial interfaces to be numbered consecutively. In this example, serial interface 1 is assigned the port value 7001,serial interface 2 is assigned the port value 7002, etc. One example on how this could be used is in the case of all.protocol or s<n>.protocol socket_ssh and the port value (7001,
7002, etc), if supplied by the SSH client like username:port value, the SSH client will be directly connected with the serial interface.
7001+
A non zero value activates data buffering (local or remote, according to what was configured in the parameter conf.nfs_data_buffering see
in Chapter 1). If local data buffering, a file is created on the CS ; if remote, a file is created through NFS in a remote server. All data received from the port is captured in this file. If local data buffering, this parameter means the maximum file size (in bytes). If remote, this parameter is just a flag to activate (greater than zero) or deactivate data buffering. When local data buffering is used, each time the maximum is reached the oldest 10% of stored data is discarded, releasing space for new data (FIFO system) - circular file. When remote data buffering is used, there's no maximum file size other than the one imposed by the remote server - linear file. This file can be viewed using the normal Unix tools (cat, vi, more, etc.). Size is in bytes not kilobytes. See Data
Buffering for details.
0
Table 8.2: CAS specific parameters for the pslave.conf
BLACK BOX® CS Command Reference Guide
303
Parameter
all.DB_mode all.DB_timestamp
Description Factory Configuration
When configured as cir for circular format, the buffer works like a revolving file at all times. The file is overwritten whenever the limit of the buffer size (as configured in all.data_buffering or
s<n>.data_buffering) is reached. As for linear format
(lin), once the limit of the kernel buffer size is reached
(4k), a flow control stop (RTS off or XOFF-depending on how all.flow or s<n>.flow is set) is issued automatically to the remote device so that it will stop sending data to the serial port. Then, when a session is established to the serial port, the data in the buffer is shown to the user if not empty (dont_show_DBmenu parameter assumed to be 2), cleared, and a flow control start (RTS on or XON) is issued to resume data transmission. Once exiting the session, linear data buffering resumes. If all.flow or s<n>.flow is set to none, linear buffering is not possible as there is no way to stop reception through the serial line. Default is cir.
cir
Records the time stamp in the data buffering file (1) or not (0). If it is configured as 1, the software will accumulate input characters until it receives a CR and
LF from the serial port or the accumulated data reaches 256 characters. Either way, the accumulated data will be recorded in the data buffering file along with the current time. The parameter all.data_buffering has to be with a non-zero value for this parameter to be meaningful.
0
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
Table 8.2: CAS specific parameters for the pslave.conf
304
Parameter Description Factory Configuration
all.syslog_buffering
all.syslog_sess
When non zero, the contents of the data buffer are sent to the syslog-ng every time a quantity of data equal to this parameter is collected. The syslog level for data buffering is hard coded to level 5 (notice) and facility local[0+conf.DB_facility]. The file /etc/syslog-
ng/syslog-ng.conf should be set accordingly for the
syslog-ng to take some action. (See Section 2.2,
to use it with Syslog
Buffering Feature.)
0
Syslog_buffering must be activated for the following to work. When 0, syslog messages are always generated whether or not there is a session to the port sending data to the unit. When 1, syslog messages are
NOT generated when there IS a session to the port sending data to the unit, but resumes generation of syslog messages when there IS NOT a session to the port.
0 all.dont_show_DBmenu
When zero, a menu with data buffering options is shown when a non empty data buffering file is found.
•
When 1, the data buffering menu is not shown.
When 2, the data buffering menu is not shown but the data buffering file is shown if not empty.
•
When 3, the data buffering menu is shown, but without the erase and show and erase options.
0 all.alarm
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
When non zero, all data received from the port are captured and sent to syslog-ng with level INFO and local[0+conf.DB_facility]facility. The syslog-ng.conf file should be set accordingly, for the syslog-ng to take
some action (please see Section 5.4, “Syslog-ng,” on page 159 for the syslog-ng configuration file).
0
Table 8.2: CAS specific parameters for the pslave.conf
BLACK BOX® CS Command Reference Guide
305
Parameter
all.billing_records
all.billing_timeout
all.billing_eor
all.sniff_mode
Description Factory Configuration
Billing file size configuration. A non-zero value defines the maximum number of billing records within a billing file. Zero stops billing recording. The billing files are located at /var/run/DB and are named cycXXXXX-YYMMDD.hhmmss.txt (e.g., cycTS100-030122.153611.txt.
50
Billing timeout configuration. A non-zero value defines how long (minutes) a billing file should be waiting for records before close. After a file is closed, this file is available for transfer and a new one is opened. Zero means “no timeout” and so the file is only closed after “billing_records” are received.
60
Defines the character sequence that terminates each billing record. Any character sequence is valid, including '\r' or '^M' (carriage return), '\n' or '^J' (new line), etc..."
"\n"
This parameter determines what other users connected to the very same port (see parameter admin_users below) can see of the session of the first connected user (main session):
•
in shows data written to the port
•
out shows data received from the port
•
i/o shows both streams
•
no means sniffing is not permitted.
The second and later sessions are called sniff sessions and this feature is activated whenever the protocol parameter is set to socket_ssh, socket_server, or socket_server_ssh.
no
Table 8.2: CAS specific parameters for the pslave.conf
306
Parameter
all.admin_users all.multiple_sessions
Description Factory Configuration
This parameter determines which users can receive the sniff session menu. Then they have options to open a sniff session or cancel a previous session. When users want access per port to be controlled by administrators, this parameter is obligatory and authtype must not be none. User groups (defined with the parameter conf.group) can be used in combination with user names in the parameter list.
null
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
Allows users to open more than one common and sniff session on the same port. The options are “yes,” “no,”
“RW_session,” or “sniff_session.” Default is set to
“no.” Please see
Section 5.11, “Session Sniffing,” on page 199 for details.
no
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
typed to make the session enter “menu mode”. The possible values are <CTRL-a> to <CTRL-z>.
Represent the CTRL with '^'. This parameter is only valid when the port protocol is socket_server, socket_ssh, or socket_server_ssh. Default value is '^z'.
^z
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
Table 8.2: CAS specific parameters for the pslave.conf
BLACK BOX® CS Command Reference Guide
307
Parameter
all.tx_interval all.idleinterval
s1.alias
Description Factory Configuration
Valid for protocols socket_server and raw_data.
Defines the delay (in milliseconds) before transmission to the Ethernet of data received through a serial port. If not configured, 100ms is assumed. If set to zero or a value above 1000, no buffering will take place.
100
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
Specifies how long (in minutes) a connection can remain inactive before it is cut off. If it set to zero, the connection will not time out.
0
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
Alias name given to the server connected to the serial port. Server_connected.
null s1.pool_ipno
s1.pool_socket_port
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
This is the default IP of the CS's pool of serial ports.
Any host can access a port from the pool using its pool's IP address as long as a path to the address exists in the host's routing table.
192.168.2.1
In the CAS profile, this defines an alternative labeling system for the CS pool of ports. In this example, serial interface 1 is assigned to the pool identified by port value 3001. Using s<serial port #>.pool_socket_port one can assign each serial interface to a different pool of ports. One serial interface can belong to just one pool of ports. Each pool of ports can have any number of serial interfaces.
3000
Table 8.2: CAS specific parameters for the pslave.conf
308
Parameter
s1.pool_alias
s2.tty s8.tty
Description Factory Configuration
Alias name given to the pool where this serial interface belong to. Important: pool_alias can’t have the characters '~', '*', '?', ' ', and '/'.
pool_1
It defines the physical device name associated to the serial port (without the /dev/).
disabled
Note: This parameter is inactive by default. To activate, uncomment the parameter.
It defines the physical device name associated to the serial port (without the /dev/).
disabled
Note: This parameter is inactive by default. To activate, uncomment the parameter.
Table 8.2: CAS specific parameters for the pslave.conf
pslave.conf TS (Terminal Server) parameters
The following parameters are unique to a TS setup except where indicated.
Parameter
conf.telnet
conf.ssh
conf.locallogins
all.host
Description Factory Configuration
Location of the Telnet utility
Location of the SSH utility.
/usr/bin/telnet
/bin/ssh
This parameter is only necessary when authentication is being performed for a port. When set to one, it is possible to log in to the CS directly by placing a “!” before your login name, then using your normal password. This is useful if the Radius authentication server is down.
1
The IP address of the host to which the terminals will connect.
192.168.160.8
Table 8.3: TS specific parameters for the pslave.conf file
BLACK BOX® CS Command Reference Guide
309
Parameter
all.term
all.userauto
Description
This parameter defines the terminal type assumed when performing rlogin or Telnet to other hosts.
Username used when connected to a UNIX server from the user’s serial terminal.
Factory Configuration
vt100 null
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
all.protocol (for TS) For the terminal server configuration, the possible protocols are,
- login, requests username and password.
- rlogin, receives username from the CS and requests a password.
- Telnet
- SSHv1
- SSHv2
- socket_client
If the protocol is configured as Telnet or socket_client the all.socket_port parameter needs to be configured.
socket_server all.socket_port
The socket_port is the TCP port number of the application that will accept connection requested by this serial port. That application usually is Telnet (23).
7001+ all.telnet_client_mode
When the protocol is Telnet, this parameter configured as BINARY (1) causes an attempt to negotiate the
Telnet Binary option on both input and output with the
Telnet server. So it puts the Telnet client in binary mode. The acceptable values are "0" or "1", where "0" is text mode (default) and "1" is a binary mode.
0 s16.tty (TS)
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
It defines the physical device name associated to the serial port (without the /dev/).
disabled
Note: This parameter is inactive by default. To activate, uncomment the parameter.
Table 8.3: TS specific parameters for the pslave.conf file
310
pslave.conf Dial-in parameters
The following parameters are unique to a Dial-in setup except where indicated.
Parameter
conf.pppd
all.netmask
all.ipno (CAS and
Dial-in) all.initchat
Description
Location of the ppp daemon with
Radius.
It defines the network mask for the serial port.
See description in CAS section.
Modem initialization string.
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
Factory Configuration
/usr/local/sbin/pppd
255.255.255.255
192.168.1.101+ null all.autoppp all.autoppp PPP options to auto-detect a ppp session. The cb-script parameter defines the file used for callback and enables negotiation with the callback server. Callback is available in combination with Radius Server authentication. When a registered user calls the CS , it will disconnect the user, then call the user back. The following three parameters must be configured in the Radius Server: attribute
Service_type(6): Callback Framed; attribute Framed_Protocol(7): PPP; attribute Callback_Number(19): the dial number (example: 50903300).
null
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
Table 8.4: Dial-in specific parameters for the pslave.conf
BLACK BOX® CS Command Reference Guide
311
Parameter
all.pppopt
Description
all.pppopt PPP options when user has already been authenticated.
Factory Configuration
null
Note: This parameter is inactive by default. To activate, uncomment the parameter and set the desired value.
all.protocol
s32.tty
For the Dial-in configuration, the available protocols are ppp, ppp_only,
slip, and cslip.
ppp
See the s1.tty entry in the CAS section.
disabled
Note: This parameter is inactive by default. To activate, uncomment the parameter.
Table 8.4: Dial-in specific parameters for the pslave.conf
pslave.conf Bidirectional Telnet parameters
Bidirectional Telnet protocol or “Dynamic Mode” supports both “socket_server” connection (CAS) and “login” (TS) profiles. Both connection protocols are supported on one port, however, connections cannot be opened simultaneously.
CS accepts the incoming TCP connection directed to a serial port as a socket_server connection. When the serial port is configured for “login”, the TCP connection is refused.
The “login” mode allows the administrator to build custom menus using the “menush_cfg” MenuShell Configuration
Utility. When the attached terminal is powered on and the keyboard’s [Enter] key is pressed, a login banner and a login prompt is displayed.
If the user does not login within a configurable time frame, the serial port returns to an idle state.
312
The following parameters are specific to the Bidirectional
Telnet in the /etc/portslave/pslave.conf file.
Parameter Description Example
sxx.protocol
sxx.authtype
The connection protocol for the specified serial port.
The authentication method configured for the serial port.
s1.protocol bidirect s1.authtype local sxx.logintimeout
The time (in seconds) for the serial port to return to idle state, if the user does not login.
s1.logintimeout 60 s1.sh /bin/menush sxx.sh
The shell command used to present a menu to the user.
“xx” represents the serial port number being configured.
Table 8.5: Bidirectional Telnet specific parameters for pslave.conf
See ‘CAS specific parameters for the pslave.conf” on
To configure Bidirectional Telnet
CLI Method
Follow the below steps to configure Bidirectional Telnet protocol.
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Activate bidirectional Telnet
cli> config physicalports <'all' or range/list[1-4]> general protocol
<protocolname>
Step 3 - To specify a login timeout
cli> config physicalports <'all' or range/list[1-4]> access logintimeout
<login timeout in seconds>
BLACK BOX® CS Command Reference Guide
313
Step 4 - Save the configuration.
cli> config savetoflash
Step 5 - Exit the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
To configure a menu shell
Enter the following command at the prompt.
[root@CAS /]# menush_cfg
The following configuration utility is displayed allowing you to configure a menu shell for the user.
--------------------------------------
MenuShell Configuration Utility
--------------------------------------
Please choose from one of the following options:
1. Define Menu Title
2. Add Menu Option
3. Delete Menu Option
4. List Current Menu Settings
5. Save Configuration to Flash
6. Quit
Using the CLI interface to configure common parameters
You can configure some of the physical port parameters that were presented in the previous pages, using the CLI interface.
General State Parameters:
General configurations are under the menu: cli>config physicalports <'all' or range/list[1-4]> general
Under this menu you can configure the following parameters:
•
alias - To configure an alias to a server connected to the serial port.
•
datasize - This parameter configures the number of bits per character. Valid values are: 5-8.
•
flow - Set the flow control. Valid values are: none, hard for hardware and soft for software.
314
•
parity - To configure the parity. Valid values are: none, even and odd.
•
protocol - This parameter configures the protocol that will be used to connect to the ports. Valid values are: bidirectionaltelnet, consoleraw, cslip, ppp, slip, telnet,
consolessh, local, pppnoauth, sshv1, consoletelnet, pm, rawsocket, sshv2.
•
speed - Configure the serial port speed. Valid values are:
300 1200 2400 4800 9600 14400 19200 28800
38400 57600 76800 115200 230400 460800 921600
•
stopbits - This parameter configures the number of stop bits.
Valid values are: 1 and 2.
Other State Parameters:
Other state configurations are under the menu: cli>config physicalports <'all' or range/list[1-4]> other
Under this menu you can configure the following parameters:
•
authbio - Configure if an AlterPath Bio authentication scanner is used.
•
banner - This parameters sets the banner that will be issued when the user connects to the port. Strings must be entered between “” (double quotes).
•
breakinterval - To set break interval in milliseconds (ms).
•
breaksequence - To set the break sequence. Usually a character sequence, ~break
(Ctrl-b)
•
host - IP address of the device you are connecting to.
•
idletimeout - This parameter configures idle timeout in minutes.
•
portip - To configure an ip alias to the serial port.
•
sttyoptions - To configure stty parameters.
•
tcpkeepalive - To configure pool interval in milliseconds (ms).
•
tcpport - To configure socket port number. Four digit values are valid for this parameter. Eg.: 7001.
•
terminaltype - The terminal type when using a TS profile for connecting to a host system.
•
winems - Enables/Disables windows EMS.
BLACK BOX® CS Command Reference Guide
315
8.2 Examples for configuration testing
The following three examples are just given to test a configuration. The steps should be followed after configuring the CS .
Console Access Server
With the CS set up as a CAS you can access a server connected to the CS through the server’s serial console port from a workstation on the LAN or WAN. There is no authentication by default, but the system can be configured for authentication to be performed by a Radius server, a TacacsPlus server, or even by a local database. Either
Telnet or SSH can be used.
.
See Appendix A - New User Background Information
for more information about SSH.
This Chapter contains all the necessary information to configure a fully-functional CAS environment. Consult the tables above and configure the necessary parameters for the
/etc/portslave/pslave.conf file according to your environment.
An example of a CAS environment is shown in the following figure. This configuration example has local authentication, an Ethernet interface provided by a router, and serially-connected workstations
Figure 8.1 - Console Access Server diagram
The following diagram, shows additional scenarios for the CS: both remote and local authentication, data buffering, and remote access.
316
Figure 8.2 - CAS diagram with various authentication methods
As shown in the above figure, our “CAS with local authentication” scenario has either
Telnet or SSH (a secure shell session) being used. After configuring the serial ports as described in this chapter, the following step-by-step check list can be used to test the configuration.
Step 1 - Create a new user.
Run the adduser <username> to create a new user in the local database. Create a password for this user by running passwd <username>.
Step 2 - Confirm physical connection.
Make sure that the physical connection between the CS and the servers is correct.
A cross cable (not the modem cable provided with the product) should be used.
Please see
Appendix C - Cabling and Hardware Information
for pin-out diagrams.
Step 3 - Confirm that server is set to same parameters as the CS.
The CS has been set for communication at 9600 bps, 8N1. The server must also be configured to communicate on the serial console port with the same parameters.
Step 4 - Confirm routing.
Also make sure that the computer is configured to route console data to its serial console port (Console Redirection).
Telnet to the server connected to port 1.
BLACK BOX® CS Command Reference Guide
317
From a server on the LAN (not from the console), try to Telnet to the server connected to the first port of the CS using the following command:
# telnet 200.200.200.1 7001
For both Telnet and SSH sessions, the servers can be reached by either:
1. Ethernet IP of the CS and assigned socket port.
or
2. Individual IP assigned to each port.
If everything is configured correctly, a Telnet session should open on the server connected to port 1. If not, check the configuration, follow the steps above again, and check the troubleshooting appendix.
Step 5 - Activate the changes.
Now continue on
“Activate the changes.” on page 99
through “Save the changes.” on page 100
listed in
NOTE:
It is possible to access the serial ports from Microsoft stations using some off-theshelf packages. Although Black Box is not liable for those packages, successful tests were done using at least one of them. From the application’s viewpoint running on a Microsoft station, the remote serial port works like a regular COM port. All the I/O with the serial device attached to the CS is done through socket connections opened by these packages and a COM port is emulated to the application.
Terminal Server
The CS provides features for out-of-band management via the configuration of terminal ports. All ports can be configured as terminal ports. This allows a terminal user to access a server on the LAN. The terminal can be either a dumb terminal or a terminal emulation program on a PC.
318
Figure 8.3 - Terminal Server diagram
No authentication is used in the example shown above and rlogin is chosen as the protocol. After configuring the serial ports as described in this chapter, the following step-by-step check list can be used to test the configuration.
Step 1 - Create a new user.
Since authentication was set to none, the CS will not authenticate the user.
However, the Linux Server receiving the connection will. Create a new user on the server called test and provide him with the password test.
Step 2 - Confirm that the server is reachable.
From the console, ping 200.200.200.3 to make sure the server is reachable.
Step 3 - Check physical connections.
Make sure that the physical connection between the CS and the terminals is correct. A cross cable (not the modem cable provided with the product) should be used. Please see the
Appendix C - Cabling and Hardware Information for pin-
out diagrams.
Step 4 - Confirm that terminals are set to same parameters as the CS .
The CS has been set for communication at 9600 bps, 8N1. The terminals must also be configured with the same parameters.
Step 5 - Log onto server with new username and password.
From a terminal connected to the CS , try to login to the server using the username and password configured in step one.
BLACK BOX® CS Command Reference Guide
319
Step 6 - Activate changes.
Now continue on
“Activate the changes.” on page 99
through “Save the changes.” on page 100
listed in
Dial-in Access
The CS can be configured to accommodate out-of-band management. Ports can be configured on the CS to allow a modem user to access the LAN. Radius authentication is used in this example and ppp is chosen as the protocol on the serial (dial-up) lines.
BLACK BOX® recommends that a maximum of two ports be configured for this option.
Figure 8.4 - Ports configured for dial-in access
After configuring the serial ports as described in this Chapter, the following step-by-step check list can be used to test the configuration.
Step 1 - Create a new user.
Since Radius authentication was chosen, create a new user on the Radius authentication server called test and provide them with the password test.
Step 2 - Confirm that the Radius server is reachable.
From the console, ping 200.200.200.2 to make sure the Radius authentication server is reachable.
Step 3 - Confirm physical connections.
320
Make sure that the physical connection between the CS and the modems is correct. The modem cable provided with the product should be used. Please see
Appendix C - Cabling and Hardware Information
for pinout diagrams.
Step 4 - Confirm modem settings.
The CS has been set for communication at 57600 bps, 8N1. The modems should be programmed to operate at the same speed on the DTE interface.
Step 5 - Confirm routing.
Also make sure that the computer is configured to route console data to the serial console port.
Step 6 - Perform a test dial-in.
Try to dial in to the CS from a remote computer using the username and password configured in step one. The computer dialing in must be configured to receive its
IP address from the remote access server (the CS in this case) and to use PAP authentication.
Step 7 - Activate changes.
Now continue on
“Activate the changes.” on page 99
through “Save the changes.” on page 100
listed in
BLACK BOX® CS Command Reference Guide
321
322
Chapter 9
Additional Features and
..........................................................................
Applications
Chapter 9 - Additional Features and Applications
This chapter covers special features or applications that does not fit into any of the previous chapters. The following features will be shown in this chapter:
•
Windows 2003 Server Management
•
•
•
•
9.1 Windows 2003 Server Management
Emergency Management Services (EMS) is a new feature in the Windows 2003 Server that allows out-of-band remote management and system recovery tasks. All Emergency
Management Services output is accessible using a terminal emulator connected to the server serial port. Besides the normal character mode output sent to the serial console,
Windows also sends xml tags. Those tags can be captured and processed by the CS so that the administrator can automate the actions to be taken.
You can manage the server through the Special Administration Console (SAC), which is the console when connected directly to the Windows Server through Telnet or SSH session.
How it works
To manage a Windows 2003 server it is necessary to enable the EMS (Emergency
Management Services) service using the following syntax: bootcfg /ems [EDIT|OFF|ON] [/s [computer] [/u [[domain\]user] /p password [/baud baud_rate] [/port communications_port] /id line_number
Where:
Parameters:
•
EDIT - Allows changes to port and baud rate settings by changing the redirect=COMx setting in the [bootloader] section. The value of COMx is set to the value of the /port.
•
OFF - Disables output to a remote computer. Removes the /redirect switch from the specified line_number and the redirect=comX setting from the [boot loader] section.
•
ON - Enables remote output for the specified line_number. Adds a /redirect switch to the specified line_number and a redirect=comX setting to the [boot loader] section. The value of comX is set by the /port.
Switches:
•
/ems - Enables the user to add or change the settings for redirection of the EMS console to a remote computer. By enabling EMS, you add a "redirect=Port#" line to the [boot loader] section of the BOOT.INI file and a /redirect switch to the specified operating system entry line. The EMS feature is enabled only on servers.
•
/baud baud_rate - Specifies the baud rate to be used for redirection. Do not use if remotely administered output is being disabled. Valid values are: 9600, 19200,
38400, 57600, 115200
•
/id line_number - Specifies the operating system entry line number in the
[operating systems] section of the Boot.ini file to which the operating system load options are added. The first line after the [operating systems] section header is 1.
•
/p password - Specifies the password of the user account that is specified in /u.
•
/port communications_port - Specifies the COM port to be used for redirection. Do not use if remotely administered output is being disabled.
BIOSSET get BIOS settings to determine port
COM1
COM2
COM3
COM4
•
/s computer - Specifies the name or IP address of a remote computer (do not use backslashes). The default is the local computer.
•
/u [[domain\]user] - Runs the command with the account permissions of the user specified by User or Domain\User. The default is the permissions of the current logged on user on the computer issuing the command.
With the EMS service enabled in the Windows machine, just configure the CS as CAS profile to manage the Windows 2003 server.
•
Windows sends xml tags in the following situations:
•
During Windows installation, it sends <channel-switch> with the setup logs.
•
During boot, it sends the <machine-info> information.
•
When switching channels, it sends the <channel-switch> information.
•
During system crash, it sends the <BP> to indicate BreakPoint.
324
The <machine-info> tag is emitted once by Windows Server during its system boot sequence. This tag is also emitted as part of the <BP> tag. The following elements are included in <machine-info> tag:
Element
<guid>
<name>
<os-build-number>
<os-product>
It is the GUID that uniquely identifies the server platform.
Normally, this is an SMBIOS provided identification. If no such value is available, all 0’s GUID string is used (see sample encoding below).
Is the system name.
Is a numeric string that identifies a successive Windows Build.
<os-service-pack>
Is the name of the Windows Server 2003 product currently running on this server. It is one of the following:
•
Windows Server 2003 Datacenter Edition
•
Windows Server 2003 Embedded
•
Windows Server 2003 Enterprise Edition
•
Windows Server 2003
Is an alphanumeric string that identifies the most up-to-date service pack installed. If none installed, the string is None.
<os-version> Is the numeric identification of the Windows version currently running.
<processor-architecture> Is either x86 or IA64, designating the two processor architectures currently supported by Windows Server 2003.
Table 9.1: machine info tag
A sample encoding of this tag follows:
Description
<?xml>
<machine-info>
<name>NTHEAD-800I-1</name>
<guid>00000000-0000-0000-0000-000000000000</guid>
<processor-architecture>x86</processor-architecture>
<os-version>5.2</os-version>
<os-build-number>3735</os-build-number>
<os-product>Windows Server 2003 Enterprise Edition</os-product>
<os-service-pack>None</os-service-pack>
</machine-info>
File Description 9.1: Machine info sample tag
BLACK BOX® CS Command Reference Guide
325
The console environment provided by the serial port is called Special Administration
Console (SAC). In the SAC command line, each time we enter the “cmd” command we create a channel. A channel is the “Command Prompt” environment, where you can enter the Command Prompt commands (dir, cd, edit, del, copy, etc). We can switch back and forth between channel(s) and SAC by pressing Esc Tab keys. We can create up to 9 channels, i.e., up to 9 Command Prompt sessions. Whenever we switch channels, the
<channel-switch> tag is sent. The following elements are included in the <channelswitch> tag:
Element
<application-type>
<description>
Description
Is a hexadecimal GUID signifying the application or tool that is running on the Windows Server platform and communicating via this active channel. It is to be used to discern the different interaction modes. During the Windows GUI-mode Setup phase, the following GUIDs identify the specific types of data being emitted:
1) Debug Log (5ED3BAC7-A2F9-4E45-9875-B259EA3F291F)
2) Error Log (773D2759-19B8-4D6E-8045-26BF38402252)
3) Action Log (D37C67BA-89E7-44BA-AE5A-112C6806B0DD)
During nominal Windows Server operations, the following GUIDs can be expected:
1) SAC (63D02270-8AA4-11D5-BCCF-806D6172696F)
2) CMD (63D02271-8AA4-11D5-BCCF-00B0D014A2D0)
The above are constant GUIDs and should not be confused with those provided via the <guid> tag below.
Is the user-friendly name of the active channel. For the GUI-Mode
Setup tool they are:
Debug Log (Setup tracing log)
Error Log (Setup errors log)
Action Log (Setup actions log)
For the Windows Server, they are:
SAC (Special Administration Console)
CMD (Command Prompt)
Table 9.2: Elements in the <channel-switch> tag
326
<guid>
<name>
<type>
Element Description
Is a hexadecimal GUID that identifies a specific instance of a channel. During a life-span of a Windows Server (between any two system boots), there is a total of 10 channels being allocated.
Of those, one can be expected a GUID for each of the following channel types:
1) GUI-Mode Setup Debug Log
2) GUI-Mode Setup Error Log
3) GUI-Mode Setup Action Log
4) SAC
The remaining GUIDs are of the CMD channel type. For example, during Windows setup, there are 3 GUIDs assigned to Setup, 1 to
SAC and the remaining 6 to CMD. However, during normal
Windows operations, there is 1 GUID assigned to SAC and the remaining 9 to CMD.
These GUIDs are created a new for each instance of channels, and should not be confused with the constant GUIDs provided via the
<application-type> tag above.
Is the system name of the active channel. For the GUI-mode
Setup tool, they are the file names where the data is written:
1) Debug Log (setuplog.txt)
2) Error Log (setuperr.log)
3) Action Log (setupact.log)
For Windows Server, they are:
1) SAC (SAC)
2) CMD (Cmdnnnn), where nnnn indicates the corresponding channel number
Is the type of data being emitted on the active channel. Currently, there are two types of data supported:
1) Raw for the 3 GUI-Mode Setup channels
2) VT-UTF8 for the SAC and CMD channels
Table 9.2: Elements in the <channel-switch> tag
BLACK BOX® CS Command Reference Guide
327
A sample encoding of the SAC channel tag follows:
<channel-switch>
<name>SAC</name>
<description>Special Administration Console</description>
<type>VT-UTF8</type>
<guid>1aee4cc0-cff3-11d6-9a3d-806e6f6e6963</guid>
<application-type>63d02270-8aa4-11d5-bccf-806d6172696f</application-type>
</channel-switch>
File Description 9.2: SAC channel tag example
A sample encoding of the CMD channel tag follows:
<channel-switch>
<name>Cmd0001</name>
<description>Command Prompt</description>
<type>VT-UTF8</type>
<guid>970438d1-12bb-11d7-8a92-505054503030</guid>
<application-type>63d02271-8aa4-11d5-bccf-00b0d014a2d0</application-type>
</channel-switch>
File Description 9.3: CMD channel tag example
A sample encoding of the GUI-Mode Setup Debug Log channel tag follows:
<channel-switch>
<name>setuplog.txt</name>
<description>Setup tracing log</description>
<type>Raw</type>
<guid>6f28e904-1298-11d7-b54e-806e6f6e6963</guid>
<application-type>5ed3bac7-a2f9-4e45-9875-b259ea3f291f</application-type>
</channel-switch>
File Description 9.4: GUI-Mode setup debug log channel tag example
328
The <BP> tag is emitted when the Windows Server system halts such that only elements of the kernel are the most recently operating logic.
Element
<INSTANCE
CLASSNAME=>
<machine-info>
<PROPERTY NAME=>
Description
Is the type of break point. Currently, there is only one type emitted, i.e. “Blue Screen” which indicates the system was halted prematurely. It is represented by the
CLASSNAME=”BLUESCREEN” value.
Is described above.
Provides additional details, such as error code of the abnormal condition that caused the break point.
Table 9.3: <BP> tags description
A sample encoding of the Break Point tag follows:
<?xml>
<BP>
<INSTANCE CLASSNAME="BLUESCREEN">
<PROPERTY NAME="STOPCODE" TYPE="string"><VALUE>"0xE2"</VALUE>
</PROPERTY>
<machine-info>
<name>NTHEAD-800I-1</name>
<guid>00000000-0000-0000-0000-000000000000</guid>
<processor-architecture>x86</processor-architecture>
<os-version>5.2</os-version>
<os-build-number>3735</os-build-number>
<os-product>Windows Server 2003 Enterprise Edition</os-product>
<os-service-pack>None</os-service-pack>
</machine-info>
</INSTANCE>
</BP>
File Description 9.5: Break Point tag example
How to Configure
Some parameters need to be configured in the /etc/portslave/pslave.conf to configure this feature. To enable it, follow the instructions below.
BLACK BOX® CS Command Reference Guide
329
VI mode - Parameters Involved and Passed Values
There is a new parameter in /etc/portslave/pslave.conf to monitor for xml data. For instance, for ttyS1 we could configure: s1.xml_monitor 1
When the xml_monitor is set, cy_buffering will search for xml packets coming from the serial port. When a complete xml packet is received, cy_buffering will send it to syslog-
ng. In syslog-ng.conf, the following filters are available to filter the xml messages: filter f_windows_bluescreen { facility(local<conf.DB_facility>) and level(info)nd match("XML_MONITOR") and match("BLUESCREEN"); } ; and filter f_windows_boot { facility(local<conf.DB_facility>) and level(info) and match("XML_MONITOR") and not match("BLUESCREEN") and match("machine-info"); } ;
Once the desired message is filtered, we have to define which actions we would like to take. Syslog-ng will create macros that can give easy access for the administrators to access the xml information. If the administrator uses these macros, syslog-ng replaces the macros by the data received in the xml packet. For instance, the following table shows the macros that are available when filter f_windows_bluescreen is successful and the examples of values that can replace the macros:
Macro Description
Value to replace macro
$<INSTANCE
CLASSNAME=>
$<PROPERTY NAME=>
$<VALUE>
$<name>
$<guid>
$<processor-architecture>
Reason for the break point. Currently there is only one type, BLUESCREEN.
BLUESCREEN
Additional details about break point.
Additional details about break point.
STOPCODE
0xE2
Machine name MY_WIN_SERVER
GUID that uniquely identifies this server. If no such value is available, all
0’s GUID string is used.
4c4c4544-8e00-
4410-8045-
80c04f4c4c20
Processor architecture. It can be either x86 or IA64.
x86
Table 9.4: f_windows_boot macros
330
Macro
$<os-version>
$<os-product>
$<os-service-pack>
$<tty>
Description
Value to replace macro
Windows version.
5.2
Which Windows Server product. It can be: Windows Server 2003 Datacenter
Edition, Windows Server 2003
Embedded, Windows Server 2003
Enterprise Edition or Windows Server
2003.
Windows Server
2003
Alphanumeric string that identifies the most up-to-date service pack installed.
If none installed, the string is None.
None
CS serial port tty or alias name.
S1.ttyS1
Table 9.4: f_windows_boot macros
For the f_windows_boot, the following macros are available:
Macro Description
Value to replace macro
$<name>
$<guid>
$<processor-architecture>
$<os-version>
$<os-build-number>
Machine name MY_WIN_SERVER
GUID that uniquely identifies this server. If no such value is available, all
0’s GUID string is used.
4c4c4544-8e00-
4410-8045-
80c04f4c4c20
Processor architecture. It can be either x86 or IA64.
x86
Windows version.
Numeric string that identifies a successive Windows Build.
5.2
3763
Table 9.5: f_windows_boot available macros
BLACK BOX® CS Command Reference Guide
331
Macro Description
Value to replace macro
$<os-product>
$<os-service-pack>
$<tty>
Which Windows Server product. It can be: Windows Server 2003 Datacenter
Edition, Windows Server 2003
Embedded, Windows Server 2003
Enterprise Edition or Windows Server
2003.
Windows Server
2003
Alphanumeric string that identifies the most up-to-date service pack installed.
If none installed, the string is None.
None
CS serial port tty or alias name.
S2.server_connected_
to_serial2
Table 9.5: f_windows_boot available macros
As an example on how we can use above macros, let’s say we want the CS to send an email to the administrator whenever a crash happens. The e-mail should have the information about the reason of the crash, machine name and windows version information. So we just have to create the following entry in syslog-ng.conf: destination win2003mail { pipe("/dev/cyc_alarm" template("sendmail -t [email protected] -f cs -s \"\
Server $<name> crashed\" -m \'\
Break Point: $<INSTANCE CLASSNAME=> $<PROPERTY NAME=> $<VALUE>\
Server: $<name>\
OS: $<os-product>\
Build: $<os-build-number> Version: $<os-version>\
Service Pack: $<os-service-pack>\
Processor: $<processor-architecture>\
Server GUID: $<guid>\
CS port: $<tty>\
\' -h mail.blackbox.com "));};
File Description 9.6: Send e-mail when crashing example
And the following entry will activate the win2003mail action when the
f_windows_bluescreen filter is successful: source src { unix-stream("/dev/log"); }; log { source(src); filter(f_windows_bluescreen); destination(win2003mail); };
332
Server Commands
The following are the different commands and their descriptions that can be sent to the server.
Command Set Description
Table 9.6: Server Commands
BLACK BOX® CS Command Reference Guide
333
Command Set
shutdown
Description
Shut down the system immediately.
Table 9.6: Server Commands
334
9.2 IPMI Configuration
Intelligent Platform Management Interface (IPMI) is a service-level protocol and implementation that provides intelligent management to servers (and other system types in the future). IPMI allows server control and monitoring by means of a small "alwayson" computer located on the server's motherboard called the Baseboard Management
Controller (BMC) that can respond to IPMI commands out-of-band.
The CS has an implementation of IPMI over LAN which allows the unit to control power
(i.e. power cycle) on these servers and also to obtain sensor readings such as CPU temperature(s), fan speed(s) etc.
The IPMI support in the CS extends it’s functionality so that the unit can be used for serial console access to the servers and also provide power control through the IPMI protocol.
How it works
This program lets you manage Intelligent Platform Management Interface (IPMI) functions of either the local system or of a remote system, using IPMI V1.5. These functions include printing FRU information, LAN configuration, sensor readings, and remote chassis power control.
You can configure IPMI using the following methods:
•
•
IPMI [ipmitool]
Utility for controlling IPMI-enabled devices.
Name
ipmitool
Usage
ipmitool [-hvV] -I interface -H hostname [-L privlvl] [-A authType] [-P password]
<expression>
BLACK BOX® CS Command Reference Guide
335
Options
Use the following options to configure IPMI.
Table 9-7: Options for ipmitool
Option Description Valid Values
-h
-v
-V
-I <interface>
-H <address>
Get basic usage help from the command line.
N/A
Increase verbose output level. This option may be specified multiple times to increase the level of debug output.
N/A
Display version information.
Selects IPMI interface to use.
N/A lan | lanplus | open
N/A Remote server address, can be IP address or hostname. This option is required for the LAN interface connection.
-U <username> Remote username.
-L <privlvl> Force session privilege level.
-A <authtype
-P <password>
Force session authentication type.
Remote server password.
Default is NULL.
USER | OPERATOR
| ADMIN.
Default is USER
PASSWORD | MD5 |
MD2
Valid password for specified username account.
Expressions
1.0 chassis
1.1 status
Returns information about the high-level status of the system chassis and main power subsystem
1.2 poh
Returns the Power-On Hours counter
1.3 identify <interval>
336
Controls the front panel identify light. Default is 15. Use
0 to turn off.
1.4 restart_cause
Queries the chassis for the cause of the last system restart
1.5 policy
Sets the chassis power policy in the event power failure
1.5.1 list – Return supported policies
1.5.2 always-on – Turn on when power is restored
1.5.3 previous – Return to previous state when power is restored
1.5.4 always-off – Stay off after power is restored
1.6 power
Performs a chassis control command to view and change the power state
1.6.1 status – Show current chassis power status
1.6.2 on – Power up chassis
1.6.3 off – Power down chassis into soft off
1.6.4 cycle – Provide power off interval of at least 1 second
1.6.5 reset – Perform a hard reset
1.7 sensor
1.7.1 list – Lists sensors and thresholds in a wide table format
IPMI [CLI]
You can configure IPMI using the ipmi keyword and the following attributes in CLI mode:
1.0 config – enter into configuration state
1.1 ipmi – configure IPMI devices
1.1.1 add <alias> – add a IPMI device serverIP serverIP <n.n.n.n> – IP address of the device
BLACK BOX® CS Command Reference Guide
337
authType <authentication options: md2, md5, none, password> – authentication type privilege <user or operator or admin> – user access level username <string> – user name used to access the device password <string> – password used to access the device
1.1.2 edit <alias> – edit the IPMI device serverIP <n.n.n.n> – IP address of the device authType <authentication options: md2, md5, none, password> – authentication type privilege <user or operator or admin> – user access level username <string> – user name used to access the device password <string> – password used to access the device
1.1.3 delete <alias> – delete the IPMI device
1.2 physicalports <port number(s)> – configure physical serial ports
1.2.1 powermanagement state disableIPMI – disable the
IPMI menu
1.2.1.1 enableIPMI – to enable the IPMI menu server <alias / list IPMI devices> – alias of the IPMI device key <^(character)> – the hotkey used to access the
IPMI menu.
The default IPMI hotkey is “^I”, where ^ stands for the Ctrl key on the keyboard. The hexadecimal code for the <Ctrl-I> default IPMI hotkey is the same as the keyboard’s <Tab> key. You can choose to change the default through the CLI command, cli>config>physicalports [port]>powermanagement>enableIPMI>key [value]
338
9.3 Line Printer Daemon
This feature implements the Unix Line Printer Daemon (LPD) in the CS and can be used with local serial printers. It enables the CS to receive network print requests and service them using locally attached Serial printers.
To configure the lpd you need to follow these steps:
Step 1 - Setup the serial port where the serial printer is connected.
Edit the /etc/portslave/pslave.conf file (PortSlave configuration) and set the protocol of the serial port as "lpd".
Example: s2.protocol lpd
Step 2 - Create the printer definition.
Edit the /etc/printcap file and configure the printer. The spool directory is created automatically by cy_ras process. Example:
#comment
# primary printer name and alias
# lp |lp2| serial printer on port ttyS2
#suppress header and/or banner page
# :sh:
#spool directory - the name is fixed as lp_ttySnn when nn is the
#serial port number
# :sd=/var/spool/lpd/lp_ttyS2:
#printer device
# :lp=/dev/ttyS2:
#log filename
# :lf=/var/log/lpd.log:
#set serial port speed as 115.200 bps
# :br115200: lp|lp2| serial printer on port ttyS2:\
:sh: \
:sd=/var/spool/lpd/lp_ttyS2: \
:lp=/dev/ttyS2: \
:lf=/var/log/lpd.log:
File Description 9.7: /etc/printcap file
Step 3 - Enable the printer daemon.
Edit the file /etc/lpd.sh and change the option ENABLE to YES
Step 4 - Allow clients to use the service.
BLACK BOX® CS Command Reference Guide
339
Edit the file /etc/hosts.lpd and include the hosts name that you allow to user the
CS printers.
NOTE:
(The lpd needs to translate the IP address of the request message to the host name, check your resolv.conf file).
Step 5 - Restart the processes, use the command "runconf" and "daemon.sh".
Step 6 - Save the configuration in flash, use the command "saveconf".
In your Linux client machine type the following command to check the CS configuration is OK:
# lpr -P lp@<CS IP address> <file that you want printer> <enter>
340
9.4 CAS Port Pool
This feature is available for the CS 2.1.4 onward. CAS Port Pooling allows you to access a free serial port from a pool in addition to the original feature where you could access a specific serial port. When you access a serial port through the pool the features sniff session and multiple sessions are not available. This feature is available for serial ports configured as CAS profile only.
You can define more than one pool of serial ports. Each serial port can only belong to
ONE pool.The pool is uniquely identified by a four parameter scheme:
•
protocol,
•
pool_ipno,
•
pool_alias, and
•
pool_socket_port
The three new parameters: pool_ipno, pool_alias, and pool_socket_port have the same meaning as ipno, alias, and socket_port respectively. Ports belonging to the same pool
MUST be configured with the same value in these fields.
It is strongly recommended that you configure the same values in all parameters related to authentication for all serial ports belonging to a pool. Some of the authentication parameters are users, admin_users, and authtype.
You can access the serial ports from a pool with the same commands you use today to access a specific serial port. You just need to use pool_ipno, pool_alias, or pool_socket_port instead ipno, alias, or socket_port respectively in the SSH/Telnet command.
When a connection request arrives using one of pool_ipno, pool_alias, or
pool_socket_port the CS will look for the first free serial port from the pool and that port will be assigned to connection. If there is no serial port free in the pool the connection is just dropped.
How to Configure it
The configuration for this feature is made directly in the /etc/portslave/pslave.conf file.
Don’t forget to activate and save the configuration by issuing the commands runconf and
saveconf respectively.
VI method
Following is an example of serial port pool configuration:
BLACK BOX® CS Command Reference Guide
341
# Serial port pool: pool-1
# s1.tty ttyS1 s1.protocol socket_server s1.socket_port 7001 // TCP port # for specific allocation s1.pool_socket_port 3000 // TCP port # for the pool s1.ipno 10.0.0.1 // IP address for specific allocation s1.pool_ipno 10.1.0.1 // IP address for the pool s1.alias serial-1 // alias for specific allocation s1.pool_alias pool-1 // alias for the pool s2.tty ttyS2 s2.protocol socket_server s2.socket_port 7002 // TCP port # for specific allocation s2.pool_socket_port 3000 // TCP port # for the pool s2.ipno 10.0.0.2 // IP address for specific allocation s2.pool_ipno 10.1.0.1 // IP address for the pool s2.alias serial-2 // alias for specific allocation s2.pool_alias pool-1 // alias for the pool
#
# Serial port pool: pool-2
# s3.tty ttyS3 s3.protocol socket_ssh s3.socket_port 7003 // TCP port # for specific allocation s3.pool_socket_port 4000 // TCP port # for the pool s3.ipno 10.0.0.3 // IP address for specific allocation s3.pool_ipno 10.2.0.1 // IP address for the pool s3.alias serial-3 // alias for specific allocation s3.pool_alias pool-2 // alias for the pool s4.tty ttyS4 s4.protocol socket_ssh s4.socket_port 7004 // TCP port # for specific allocation s4.pool_socket_port 4000 // TCP port # for the pool s4.ipno 10.0.0.4 // IP address for specific allocation s4.pool_ipno 10.2.0.1 // IP address for the pool s4.alias serial-4 // alias for specific allocation s4.pool_alias pool-2 // alias for the pool
File Description 9.8: Part of the /etc/portslave/pslave.conf file
In the example above, there are two pools:
•
pool-1 (identified by Protocol socket_server, TCP port #3000, IP 10.1.0.1, and alias pool-1)
•
pool-2 (identified by Protocol socket_ssh, TCP port #4000, IP 10.2.0.1, and alias pool-2)
342
The serial ports ttyS1 and ttyS2 belong to the pool-1. The serial ports ttyS3 and ttyS4 belong to the pool-2.
You can access specifically serial port ttyS1 by using TCP port 7001, IP address 10.0.0.1 or alias serial-1. If the ttyS1 is being used by somebody else the connection will be dropped if the user is not a admin_user. Alternately, you can access ttyS1 through pool
(if it's free) using TCP port 3000, IP 10.1.0.1 or alias pool-1. If it is not free ttyS2 will be automatically allocated. Additionally, if ttyS2 is not free, the connection will be dropped.
BLACK BOX® CS Command Reference Guide
343
9.5 Billing
All CS family of products can be used as an intermediate buffer to collect serial data (like billing tickets from a PBX), making them available for a posterior file transfer. Different ports can have simultaneous "billing sessions".
General Feature Description
CS reads the serial port and saves the information to Ramdisk files, which is limited to the maximum number of records per file. After the files are closed, they are available for transfer at /var/run/DB, or an alternate path defined by the user in the pslave.conf file.
See Table 8.2 on page 299 for additional details on billing file configuration.
How to configure it
The configuration for this feature is made in the /etc/portslave/plsave.conf file.
Billing parameters can be configured using the vi method and by using the wizard.
VI method - Passed Values and Involved Parameters
Open the /etc/portslave/pslave.conf file and configure the following parameters according to your application:
•
all.protocol - billing
Data Buffering Section:
•
all.billing_records - 50
•
all.billing_timeout - 60 min
•
all.billing_eor - "\n"
For detailed description about the parameters shown above, please see Chapter 8,
.
NOTE:
All presented values above are going to implement the billing feature for ALL ports of the product. If the configuration for a specific port is required, all related parameters beginning with all must be changed to S.x, where x is the number of the port to be configured.
344
How it works
Once the cy_ras program detects the protocol as “billing,” it starts the billing application. The billing application then opens the port (as configured in pslave.conf) and starts reading it. Records terminated by "billing_eor string" are expected to be received. The CS doesn’t change the termination method, transferring the same sequence to the file. The name of the temporary file used to write these records is: cycXXXXX-YYMMDD.hhmmss.tmp
where:
•
XXXXX is the “hostname” or “alias”
•
YYMMDD is the year/month/day
•
hhmmss is the hour:min:sec
This name helps the user archive and browse their directory as the file can be chronologically listed, not based on its creation or modification times, but based on when its contents were recorded. Also, whenever “hostname” is not significant, the user can use the “alias” name (s1.alias in pslave.conf) to match their actual plant (like PABXtrunk9). The temporary file described above is closed and renamed to cycXXXXX-
YYMMDD.hhmmss.txt and a new temporary file is opened when:
1. The maximum number of records specified by “billing_records” is reached;
2. The lifetime specified by “billing_timeout” finishes.
If no record is received within a file lifetime period, no file will be actually saved.
NOTE:
A zero-value for “billing_records” stops the application and a zero-value for
“billing_timeout” means no timeout is desired and so the file will only be closed after
“billing_records” are received.
Disk Space Issue
Finally, it is important to note that there is a protection against disk space problems. If you configure flow control to “hardware” for the serial port (all.flow = hard in the pslave.conf file), the application monitors the available disk space and if it is less than
100 Kb, the serial interface deactivates “RTS” signal on the RS-232. “RTS” is reactivated once the disk free space is greater than 120 Kb.
BLACK BOX® CS Command Reference Guide
345
Billing Wizard
This feature improves the billing application by using a script and automating the upload of the billing records files from the CS to a remote server using FTP or SSH.
How to Configure
The config_billing.sh script is used to configure a serial port for billing protocol, and configure upload scripts using FTP or SSH. The config_billing.sh script configures the files /etc/billing_up.conf /etc/billing_crontab, and /etc/crontab_files.
To configure a port for billing
Step 1 - Execute the config_billing.sh and enter the parameters to be configured.
Usage: config_billing.sh [X] [options] where:
X is the port number to be configured
[options] are:
-s speed
-b stopbit
-p parity
-e billing EOR (this parameter must be on " ", like "\n")
-S serverFarm
-t date
-T timeout
-i ip
-n netmask
-R route
-u upload
Any parameter that is not specified will remain unchanged. The following parameters are configured by default for billing.
346
sxx.authtype none sxx.protocol billing sxx.flow none sxx.dcd 0 sxx.sniff_mode no
Select the -u option to execute the billing_upload_files.sh script. The script presents the following sequential menu where the upload options can be configured.
[root@CAS etc]# billing_upload_files.sh
Transfer Mode (ftp or scp)[ftp]:
Local Directory[/var/run/DB]:
Remote server IP [192.168.1.101]:
Remote directory [/var/billing]:
User [billing]:
Password [billing]:
Upload Interval in minutes []:
Instead of running the -u option, the /etc/billing_up.conf can be configured manually to change the parameters. If the parameters remains unchanged the default parameters are uploaded.
If the “scp” transfer mode is selected and there is no defined authentication, the script generates a key and uploads to the server. The key must be stored on the server with the appropriate configuration.
Step 2 -
Execute saveconf
Step 3 - Restart CS to activate the options related to billing upload.
BLACK BOX® CS Command Reference Guide
347
348
Appendix A
New User Background
..........................................................................
Information
Appendix A - New User Background Information
This appendix has the objective to introduce new users with commands, file structure, processes, programs and other features used by the Advanced Console Server operating system. This appendix includes the following sections:
•
•
Who is logged in and what they are doing?
•
•
•
•
•
•
•
A.1 User and Passwords
A username and password is necessary to log in to the CS. The user “root” is predefined with a password “bb”. The password should be changed as soon as possible to avoid unauthorized access.
To change the password for the “root” , enter the following command.
# passwd
To create a regular user (without root privileges), enter the following command:
# adduser user_name
To change the password for a regular user, enter the following command.
# passwd user_name
To log out, type “logout” at the command prompt.
A regular user who wants to run the command su - to become a superuser needs to:
Step 1 - Make sure the group wheel is already created.
An administrator with root access would run the following command:
| 349
# addgroup wheel
In file /etc/group there should be a line with at least the following: wheel::zzz:
Step 2 - Belong to the group wheel.
An administrator with root access would edit /etc/group file and insert the username at the end of the wheel line. For example, for user steve, the administrator would edit the line in file/etc/group: wheel::zzz: to add "steve" at the end like this: wheel::zzz:steve
A.2 Who is logged in and what they are doing
The command “w” displays information about the users currently on the machine, and their processes. It calls two commands: w_ori and w_cas. The w_ori is the new name of the original command “w” and the w_cas shows the CAS sessions information.
The header of w_ori shows, in this order: the current time, how long the system has been running, how many users are currently logged on (excluded the CAS users), and the system load averages for the past 1, 5, and 15 minutes.
The following entries are displayed for each user (excluded the CAS users): login name, the tty name, the remote host, login time, idle time, JCPU time (it is the time used by all processes attached to the tty), PCPU time (it is the time used by the current process, named in the “what” field), and the command line of their current process.
The header of w_cas shows how many CAS users are currently logged on. The following entries are displayed for each CAS user: login name, the tty name, the remote host and remote port, login time, the process ID and the command line of the current process.
A.3 Linux File Structure
The Linux file system is organized hierarchically, with the base (or root) directory represented by the symbol “/”. All folders and files are nested within each other below this base directory. The directories located just below the base directory are:
•
/home - Contains the work directories of system users.
•
/bin - Contains applications and utilities used during system initialization.
•
/dev - Contains files for devices and ports.
•
/etc - Contains configuration files specific to the operating system.
350 | Appendix A -
•
/lib - Contains shared libraries.
•
/proc - Contains process information.
•
/mnt - Contains information about mounted disks.
•
/opt - Location where packages not supplied with the operating system are stored.
•
/tmp - Location where temporary files are stored.
•
/usr - Contains most of the operating system files.
A.4 Basic File Manipulation
The basic file manipulation commands allow the user to copy, delete, and move files and create and delete directories.
cp file_name destination a) cp text.txt /tmp b) cp /chap/robo.php ./excess.php
rm file_name mv file_name destination mkdir directory_name a) mkdir spot b) mkdir /tmp/snuggles rmdir directory_name
Copies the file indicated by file_name to the path indicated by destination. a) Copies the file text.txt in the current directory to the tmp directory.
b) Copies the file robo.php in the chap directory to the current directory and renames the copy excess.php.
Removes the file indicated by file_name.
Moves the file indicated by file_name to the path indicated by destination.
Creates a directory named directory_name. a) creates the directory spot in the current directory. b) creates the directory snuggles in the directory tmp.
Removes the directory indicated by directory_name.
Other commands allow the user to change directories and see the contents of a directory.
pwd
Supplies the name of the current directory. While logged in, the user is always “in” a directory. The default initial directory is the user's home directory: /home/<username> ls [options] directory_name Lists the files and directories within directory_name. Some useful options are -l for more detailed output and -a which shows hidden system files.
cd directory_name cat file_name
Changes the directory to the one specified.
Prints the contents of file_name to the screen.
| 351
Shortcuts:
. (one dot)
.. (two dots)
Represents the current directory.
Represents one directory above the current directory (i.e. one directory closer to the base directory).
A.5 The vi Editor
To edit a file using the vi editor, type: vi file_name
Vi is a three-state line editor: it has a command mode, a line mode and an editing mode.
If in doubt as to which mode you are in, press the <ESC> key which will bring you to the command mode.
Mode
Command mode
Editing mode
Line mode
What is done there How to get there
Navigation within the open file.
Press the <ESC> key.
Text editing.
See list of editing commands below.
File saving, opening, etc. Exiting from vi.
From the command mode, type “:”
(colon).
Table A.1: vi modes
When you enter the vi program, you are automatically in command mode. To navigate to the part of the file you wish to edit, use the following keys:
k l h j
Moves the cursor to the left (left arrow).
Moves the cursor to the next line (down arrow).
Moves the cursor to the previous line (up arrow).
Moves the cursor to the right (right arrow).
Table A.2: vi navigation commands
352 | Appendix A -
Having arrived at the location where text should be changed, use these commands to modify the text (note commands “i” and “o” will move you into edit mode and everything typed will be taken literally until you press the <ESC> key to return to the command mode).
i o dd x
Inserts text before the cursor position (everything to the right of the cursor is shifted right).
Creates a new line below the current line and insert text (all lines are shifted down).
Removes the entire current line.
Deletes the letter at the cursor position.
Table A.3: vi file modification commands
After you have finished modifying a file, enter line mode (by typing “:” from command mode) and use one of the following commands:
w wq q!
w file e file
Saves the file (w is for write).
Saves and closes the file (q is for quit).
Closes the file without saving.
Saves the file with the name <file>.
Opens the file named <file>.
Table A.4: vi line mode commands
A.6 The Routing Table
The CS has a static routing table that can be seen using the commands:
# route or
# netstat -rn
The file /etc/network/st_routes is the CS’s method for configuring static routes. Routes should be added to the file (which is a script run when the CS is initialized) or at the prompt (for temporary routes) using the following syntax: route [add|del] [-net|-host] target netmask nt_msk [gw gt_way] interf
| 353
•
[add|del] - One of these tags must be present. Routes can be either added or deleted.
•
[-net|-host] - Net is for routes to a network and -host is for routes to a single host.
•
target - Target is the IP address of the destination host or network.
•
netmask and nt_msk - The tag netmask and nt_mask are necessary only when subnetting is used, otherwise, a mask appropriate to the target is assumed. nt_msk must be specified in dot notation.
•
gw and gt_way - Specifies a gateway, when applicable. gt_way is the IP address or hostname of the gateway.
•
interf - The interface to use for this route. Must be specified if a gateway is not.
When a gateway is specified, the operating system determines which interface is to be used.
A.7 Secure Shell Session
SSH is a command interface and protocol often used by network administrators to connect securely to a remote computer. SSH replaces its non-secure counterpart rsh and rlogin. There are two versions of the protocol, SSHv1 and SSHv2. The CS offers both.
The command to start an SSH client session from a UNIX workstation is: ssh -t <user>@<hostname> where
•
<user> = <username>:ttySnn or
<username>:socket_port or
<username>:ip_addr or
<username>:alias
NOTE:
“alias” is a physical port alias. It can be configured in the file pslave.conf.
An example: username:
CS16 IP address: host name: blackboxmycompany
192.168.160.1
cs16 servername for port 1: file_server ttyS1 is addressed by IP 10.0.0.1 or socket port 7001. The various ways to access the server connected to the port are: ssh -t blackbox:ttyS1@cs16 ssh -t blackbox:7001@cs16 ssh -t blackbox:10.0.0.1@cs16 ssh -t blackbox:file_server@cs16 ssh -t -l blackbox:10.0.0.1 cs16 ssh -t -l blackbox:7001 cs16
354 | Appendix A -
For OpenSSH clients, version 4.1p1 or later SSHv2 is the default. In that case, the -1 flag is used for SSHv1.
# ssh -t blackbox:7001@cs16
# ssh -t -2 blackbox:7001@cs16
# ssh -t blackbox:7001@cs16
(openssh 4.1p1 or later - CS version 2.1.0 or later -> SSHv2 will be used)
# ssh -t -1 blackbox:7001@cs16
(OpenSSH 4.1p1 or later - CS version 2.1.0 or later -> SSHv1 will be used)
To log in to a port that does not require authentication, the username is not necessary: ssh -t -2 :ttyS1@cs16
Note: In this case, the file sshd_config must be changed in the following way:
PermitRootLogin Yes
PermitEmptyPassword Yes
The Session Channel Break Extension
This feature was introduced in CS version 2.1.3. It is a method of sending a break signal during a SSHv2 terminal session. The implementation is defined by “Session Channel
Break Extension: draft-ietf-secsh-break-00.txt” (IETF Internet-Draft document).
In the previous versions of CS there was one break length measured in milliseconds. The current version of CS supports the parameter <all/Sx>.break_interval, which is used with all.break_sequence (<all/Sxx>.break_sequence). This has improved the SSH-break implementation.
The SSHv2-client receives a command (“<ssh escape char>B" or "<break_sequence>”, for example:"~break" and sends one "break request" to SSH-server. The SSH-server receives the "break request" and sends a break command to the serial port. The SSH client can then send the break duration (break interval) so the user can configure this value using the command line (" -B <break interval in milliseconds> ", for example: "ssh
-l <user>:<port> <CS IP Server > -B <breakinterval in milliseconds>").
How it works in SSH Server (all.protocol is socket_ssh)
| 355
The serial driver accepts the parameter break interval in the break command. If the
SSHv2, then the server accepts and treats the "break request" sent by the client. The
"break request" defines the break-length in milliseconds. The server sends a break command with the break-length to the serial driver to perform the break in the serial port.
If the parameter all.break_sequence is configured and the server finds the sequence in the data received from client, the server sends a break command with all.break_interval to serial driver.
How it works in SSH Client
The SSH client has an option " -B <break interval in milliseconds> ", for example, "ssh
-l <user>:<port> <CS IP Server > -B <breakinterval in milliseconds>".
When the user types "<ssh-escape>B" (where ssh-escape is "~") or "<break_sequence>" the client sends a "break request" to ssh-server. When CS calls the ssh-client automatically, it uses the parameter all.break_interval to calls the ssh-2 client.
Configuring the Session Channel Break Extension in SSH Server
Step 1 - Configure the parameter break_interval, and break_sequence in
/etc/portslave/pslave.conf.
This can be done by the admin using the vi editor.
For example, all.break_interval 500 all.break_sequence ~break
Step 2 - Enter the following commands.
#runconf
#saveconf
You can then get the kernel's attention by sending a BREAK by typing <ENTER> + the break sequence configured + the key corresponding to a given command (from SysRq).
If you send an invalid command key, it will simply display the help (the SysRq HELP).
For example,
1 - Establish an SSH connection to the CS console port.
ssh -l <user>:<socket_port> <CS_TS_IP>
356 | Appendix A -
2 - You can get the kernel's attention by sending a BREAK signal.
<ENTER> + ~break
The Result will be:
SysRq : HELP : loglevel0-8 reBoot Crash tErm kIll saK showMem Nice powerOff showPc unRaw Sync showTasks Unmount or if you type for example,
<ENTER> + ~breakp
The Result will be:
SysRq : Show Regs
Pid: 0, comm: swapper
EIP: 0060:[<c010103b>] CPU: 0
EIP is at default_idle+0x23/0x29
EFLAGS: 00000246 Not tainted (2.6.10-1.771_FC2)
EAX: 00000000 EBX: 00010809 ECX: de0f3000 EDX: 0baf3110
ESI: 00099100 EDI: c03dc120 EBP: 00461007 DS: 007b ES: 007b
CR0: 8005003b CR2: b7ff2000 CR3: 19b6a000 CR4: 000006d0
[<c010108f>] cpu_idle+0x1f/0x34
A.8 The Process Table
The process table shows which processes are running. Type ps -a to see a table similar to the following.
PID UID VmSize State Command
1
31
32
36
154 root root root root root
592
928
584
1148
808
S
S
S
S
R
/sbin/inetd
/sbin/inetd
/sbin/cy_ras
/sbin/cy_wdt_led wdt led
/ps -a
Table A.5: Process Table
To restart the cy_ras process use its process ID or execute the command:
# runconf
| 357
This executes the ps command, searches for the cy_ras process id, then sends the signal hup to the process, all in one step. Never kill cy_ras with the signals -9 or SIGKILL.
A.9 TS Menu Script
The ts_menu script can be used to avoid typing long Telnet or SSH commands. It presents a short menu with the names of the servers connected to the serial ports of the
CS. The server is selected by its corresponding number. ts_menu must be executed from a local session: via console, Telnet, SSH, dumb terminal connected to a serial port, etc.
Only ports configured for console access (protocols socket_server, socket_ssh, or
socket_server_ssh) will be presented. To start having familiarity with this application, run ts_menu - h:
# ts_menu -h
USAGE: ts_menu options {<console port>}
-p : Display Tcp port
-P : Use the TCP port instead just IP
-i : Display Local Ip assigned to the serial port
-u <name> : Username to be used in ssh/telnet command
-U : Always ask for an username
-e <[^]char> : Escape char used by telnet or ssh
-l[c] : Sorted list ports (c option sort by console server) and exit
-auth : Interactive authentication
-ro : Read Only mode
-s : Show sorted ports
<console port> : Connect direct to [console port]
Below is an example on how TS Menu can be used:
# ts_menu
Master and Slaves Console Server Connection Menu
1 TSJen800
2 test.blackbox.com
3 az84.blackbox.com
4 64.186.190.85
5 az85.blackbox.com
Type 'q' to quit, a valid option [1-5], or anything else to refresh:
By selecting 1 in this example, the user will access the local serial ports on that CS. If the user selects 2 through 5, remote serial ports will be accessed. This is used when there is clustering (one CS master box and one or more CS slave boxes).
If the user selects 1, the following screen is displayed:
358 | Appendix A -
Serial Console Server Connection Menu for your Master Terminal Server
1 ttyS1 2 ttyS2 3 s3alias
Type 'q' to quit, 'b' to return to previous menu, a valid option[1-3], or anything else to refresh:
Options 1 to 3 in this case are serial ports configured to work as a CAS profile. Serial port 3 is presented as an alias name (s3alias). When no name is configured in
pslave.conf, ttyS<N> is used instead. Once the serial port is selected, the username and password for that port (in case there is a per-user access to the port and -U is passed as parameter) will be presented, and access is granted.
To access remote serial ports, the presentation will follow a similar approach to the one used for local serial ports.
The ts_menu script has the following line options:
-p : Displays Ethernet IP Address and TCP port instead of server names.
CS: Serial Console Server Connection menu
1 209.81.55.79 7001 2 209.81.55.79 7002 3 209.81.55.79 7003
4 209.81.55.79 7004 5 209.81.55.79 7005 6 209.81.55.79 7006
Type 'q' to quit, a valid option [1-6], or anything else to refresh :
-i : Displays Local IP assigned to the serial port instead of server names.
CS: Serial Console Server Connection menu
1 192.168.1.101
5 192.168.1.105
2 192.168.1.102
3 192.168.1.103 4 192.168.1.104
6 192.168.1.106
Type 'q' to quit, a valid option [1-6], or anything else to refresh :
-u <name> : Username to be used in the SSH/Telnet command. The default username is that used to log onto the CS.
-h : Lists script options.
| 359
360 | Appendix A -
Appendix B
Upgrades and Troubleshooting
..........................................................................
Appendix B - Upgrades and Troubleshooting
This appendix has the objective to cover the most common problems that users faces when using the CS . This appendix will also show the necessary steps to upgrade the firmware of the CS unit and how to correctly interpret the CPU LED status.
B.1 Upgrades
Users should upgrade the CS whenever there is a bug fix or new features that they would like to have. Below are the six files added by BLACK BOX® to the standard Linux files in the /mnt/flash directory when an upgrade is needed. They are:
•
boot_alt - alternate boot code
•
boot_conf - active boot code
•
boot_ori - original boot code
•
config.tgz - CS configuration information
•
zImage - Linux kernel image
The Upgrade Process
To upgrade the CS , follow these steps:
Step 1 - Log in to the CS as root.
Provide the root password if requested.
Step 2 - Go to the /mnt/flash directory using the following command: cd /mnt/flash
Step 3 - FTP to the host where the new firmware is located.
Log in using your username and password. Go to the directory where the firmware is located. Select binary transfer and “get” the firmware file.
# ftp
ftp> open server ftp> user admin ftp> Password: adminpw ftp> cd /tftpboot ftp> bin ftp> get zImage.134 zImage ftp> quit
NOTE:
The destination file name in the /mnt/flash directory must be zImage. Example
(hostname = server; directory = /tftpboot; username= admin; password = adminpw; firmware filename on that server = zImage.134).
NOTE:
Due to space limitations, the new zImage file may not be downloaded with a different name, then renamed. The CS searches for a file named zImage when booting and there is no room in flash for two zImage files.
Step 4 - Verify zImage.
To make sure the downloaded file is not corrupted and to verify the zImage saved in flash run the following command: md5sum /mnt/flash/zImage
The system responds with a message similar to the following:
5bcc7d9b3c61502b5c9269cbecd20317 /mnt/flash/zImage
Step 5 - Check the system’s response against the “.md5” zImage text file on the tftp server.
For example, the zImage zvmppccs.1005_qa.cs-k26.md5 text file contains the following information:
5bcc7d9b3c61502b5c9269cbecd20317 /tftpboot/zvmppccs.1005_qa.cs-k26
If the alphanuemeric string matches the downloaded file is not corrupted.
Step 6 - Issue the command reboot.
# reboot
Step 7 - Confirm that the new Linux kernel has taken over.
After rebooting, the new Linux kernel will take over. This can be confirmed by typing the following to see the Linux kernel version:
# cat /proc/version
362 | Appendix B -
CLI Method - Firmware Upgrade
To upgrade the CS firmware follow the steps below:
Step 1 - Open the CLI interface by issuing the command:
# CLI
Step 2 - Upgrading the firmware.
All you need to know to upgrade the CS’s firmware is the remote IP address of the FTP server and the path of the image file in the remote server.
For the example given we will use:
•
FTP Server: 192.168.100.111
•
Path: /images/zImage
•
User: john
•
Password: john1234 cli> administration upgradefw ftpsite 192.168.100.111 username john password john1234 filepathname /images/zImage checksum no
Step 3 - Return to the main menu by issuing the command
cli>return
Step 4 - Activate the configuration.
cli>config runconfig
Step 5 - Save the configuration.
cli> config savetoflash
Step 6 - Exiting the CLI mode.
To exit the CLI mode and return to CS’s shell, type the following command: cli> quit
Step 7 - Reboot the unit (shell prompt).
To make the changes effective, reboot the unit by issuing the command (in the shell prompt):
#reboot
Step 8 - Testing the configuration (shell prompt).
To check if the version of the installed image, run the command:
# cat /proc/version
| 363
B.2 Troubleshooting
Flash Memory Loss
If the contents of flash memory are lost after an upgrade, please follow the instructions below to restore your system:
Step 1 - Turn the CS OFF, then back ON.
Step 2 - Using the console, wait for the self test messages.
If you get no boot messages, verify that you have the correct setting, otherwise press “s” immediately after powering ON to skip an alternate boot code. CS will boot using its original boot code.
Step 3 - During the self test, press <Esc> after the Ethernet test.
Testing Ethernet .........................
Step 4 - When the Watch Dog Timer prompt appears, press <Enter>.
Watchdog timer ((A)ctive or (I)nactive) [I] :
Step 5 - Choose the option Network Boot when asked.
Firmware boot from ((F)lash or (N)etwork) [N] :
Step 6 - Select the TFTP option instead of BOOTP. The host must be running
TFTPD and the new zImage file must be located in the proper directory. For example, /tftpboot for Linux.
Boot type ((B)ootp,(T)ftp or Bot(H)) [H] :
Step 7 - Enter the filename of the zImage file on the host.
Boot File Name [zvmppccs.1004_qa.cs-k26] :
Step 8 - Enter the IP address of the Ethernet interface.
IP address assigned to Ethernet interface [192.168.48.11] :
Step 9 - Enter the IP address of the host where the new zImage file is located.
Server's IP address [192.168.49.127] :
Step 10 - Accept the default MAC address by pressing <Enter>.
364 | Appendix B -
MAC address assigned to Ethernet [00:60:2E:01:6B:61] :
Step 11 - When the “Fast Ethernet” prompt appears, press <Enter>.
Fast Ethernet ((A)uto Neg, 100 (B)tH, 100 Bt(F), 10 B(t)F, 10 Bt(H)) [A] :
CS should begin to boot off the network and the new image will be downloaded and begin running in RAM. At this point, follow the upgrade process in section B.1 above to save the new zImage file into flash again.
NOTE:
Possible causes for the loss of flash memory may include: downloaded wrong zImage file, downloaded as ASCII instead of binary; problems with flash memory.
If the CS booted properly, the interfaces can be verified using ifconfig and ping. If ping does not work, check the routing table using the command route. Of course, all this should be tried after checking that the cables are connected correctly.
The file /etc/config_files contains a list of files that are affected by saveconf and
restoreconf commands. At the command prompt issue the command cat /etc/config_files to see the list of files that are available in the flash and are loaded into the RAMDisk at the boot time.
IMPORTANT!
If any of the files listed in /etc/config_files is modified, the CS administrator must execute the command saveconf before rebooting the CS or the changes will be lost. If a file is created (or a filename altered), its name must be added to this file before executing saveconf and rebooting.
IMPORTANT!
BLACK BOX® Technical Support is always ready to help with any configuration problems. Before calling, execute the command
# cat /proc/version
and note the Linux version and CS version written to the screen. This will speed the resolution of most problems.
Hardware Test
A hardware test called tstest is included with the CS firmware. It is a menu-driven program, run by typing tstest at the command prompt. The various options are described below. Note that the CS should not be tested while in use as the test will inactivate all ports. You should inactivate all processes that may use the serial ports: inetd, sshd,
cy_ras, and cy_buffering. Following are the hardware test steps:
| 365
Step 1 - signal_ras stop.
Step 2 - Perform all hardware tests needed.
Step 3 - signal_ras start.
Port Test
Either a cross cable or a loop-back connector is necessary for this test. Their pinout diagrams are supplied in
Appendix C - Cabling and Hardware Information . Connect the
loop-back connector to the modem cable and then connect the modem cable to the port to be tested (or connect a crossover cable between two ports to be tested).
When tstest senses the presence of the cable or connector, the following information is displayed on your screen.
HW Test/Linux
This tool is for internal use ONLY!
It should not be used if the serial port is
configured and/or running.
Press any key to continue or <ESC> to cancel ==>
To start the Port test,
Step 1 - Select option 2 "Test Asynchronous Ports"
Step 2 - Enter the media type [(0) RS232 (1) RS485-FULL] :
For example, 0 for RS232
When the test runs with a cable or connector without the DSR signal (see the pinout diagram for the cable or connector being used), errors will appear in the DSR column.
This does not indicate a problem with the port.
366 | Appendix B -
Port Conversation
This test sends and receives data on the selected port. One way to run this test is to place a loop-back connector on the port to be tested and begin. Enter the number of the port and a baud rate (9600 is a typical value). Type some letters, and if the letters appear on the screen, the port is working. If the letters do not appear on the screen (which also occurs if the loop-back connector is removed), the port is not functioning correctly.
A second method that can be used to test the port is to connect it to a modem with a straight cable. Begin the test and type “at”. The modem should respond with “OK”, which will appear on the screen. Other commands can be sent to the modem or to any other serial device. Press Ctrl-Q to exit the terminal emulation test.
Test Signals Manually
This test confirms that signals are being sent and received on the selected port. Neither the loop-back connector nor the cross cable are necessary. Enter the number of the port to be tested and begin the test.
Figure B.1 - Initial Test
First, type Ctrl-D to see the X in the DTR column move position, then type Ctrl-R to see the X in the RTS column change position. If each of the Xs moves in response to its command, the signals are being sent. Another method to test the signals is to use a loopback connector. Enter the number of the port with the loopback connector and start the test. In this case, when Ctrl-D is typed, the Xs in the first three columns will move as shown below.
Figure B.2 - Second screen, showing changed positions
This is because the test is receiving the DTR signal sent through the DCD and DSR pins.
When Ctrl-R is typed, the Xs in the RTS and CTS columns should move together. If the
Xs change position as described, the signals are being sent and received correctly.
| 367
Single User Mode
The CS has a single user mode used when:
•
The name or password of the user with root privileges is lost or forgotten,
•
After an upgrade or downgrade which leaves the CS unstable,
•
After a configuration change which leaves the CS inoperative or unstable.
Type the word “ single” (with a blank space before the word) during boot using a console connection. This cannot be done using a Telnet or other remote connection. The initial output of the boot process is shown below.
Entry Point = 0x00002120 loaded at: 00002120 0000D370 relocated to: 00300020 0030B270 board data at: 003052C8 0030537C relocated to: 002FF120 002FF1D4 zimage at: 00008100 0006827E relocated to: 00DB7000 00E1717E initrd at: 0006827E 0024F814 relocated to: 00E18000 00FFF596 avail ram: 0030B270 00E18000
Linux/PPC load: root=/dev/ram
After printing “Linux/PPC load: root=/dev/ram,” the CS waits approximately 10 seconds for user input. This is where the user should type “<sp>single” (spacebar, then the word “single”). When the boot process is complete, the Linux prompt will appear on the console:
[root@(none) /]#
If the password or username was forgotten, execute the following commands:
# passwd
# saveconf
# reboot
For configuration problems, you have two options:
1. Edit the file(s) causing the problem with vi, then execute the commands:
[root@CAS root]# saveconf
[root@CAS root] # reboot
2. Reset the configuration by executing the following commands:
[root@CAS root]# defconf
The following warning message displays.
368 | Appendix B -
WARNING: this will erase all of your current configuration and restore the system's factory default configuration. This action is irreversible and the
CS must be rebooted to apply that.
Enter y or N at the following prompt.
Are you sure you wish to continue? (y/N)
If you entered ‘y’, type reboot at the following prompt.
[root@CAS root]# reboot
The system reboots and displays the following message.
Sep 27 19:39:09 src_dev_log@CAS reboot: The system is going down. Rebooted by root.
If the problem is due to an upgrade/downgrade, a second downgrade/upgrade will be necessary to reverse the process. First, the network must be initialized in order to reach a FTP server. Execute the following script, replacing the parameters with values appropriate for your system. The gw and mask parameters are optional.
[root@CAS root]# config_eth0 ip 200.200.200.1 mask 255.255.255.0 gw
200.200.200.5
Edit the file(s) causing the problem with vi, then execute the commands:
[root@CAS root]# saveconf
[root@CAS root]# reboot
At this point, the DNS configuration in the file /etc/resolv.conf should be checked. Then download the kernel image using the ftp command.
Using a different speed for the Serial Console
The serial console is originally configured to work at 9600 bps. If you want to change that, it is necessary to change the configuration following the steps:
Step 1 - Run bootconf. The user will be presented with the screen:
| 369
Current configuration
MAC address assigned to Ethernet [00:60:2e:00:16:b9]
IP address assigned to Ethernet interface [192.168.160.10]
Watchdog timer ((A)ctive or (I)nactive) [A]
Firmware boot from ((F)lash or (N)etwork) [F]
Boot type ((B)ootp,(T)ftp or Bot(H)) [T]
Boot File Name [zvmppcts.bin]
Server's IP address [192.168.160.1]
Console speed [9600]
(P)erform or (S)kip Flash test [P]
(S)kip, (Q)uick or (F)ull RAM test [F]
Fast Ethernet ((A)uto Neg, (1)00 BtH, 100 Bt(F), 10 B(t)F, 10 Bt(H)) [A]
Fast Ethernet Maximum Interrupt Events [0]
Maximum rate of incoming bytes per second [0]:
Type <Enter> for all fields but the Console Speed. When presented the following line:
Do you confirm these changes in flash ( (Y)es, (N)o (Q)uit ) [N] :
Step 2 - Enter Y and the changes will be saved in flash.
Step 3 - Logout and login again to use the console at the new speed.
Setting the Maximum Number of Bytes Received by the Interface
You can avoid CPU overload due to too many bytes received by the interface at one time by setting a limit to the rate of bytes received. The bootconf utility offers a way of setting this limit. The default is set to 0, which disables the function. For optimum performance set the value to: 50000.
Just inform the maximum allowed rate of bytes to be received, or 0 disable completely the feature (all bytes will be processed at any rate). An optimum rate determined by
BLACK BOX® during the testing process was 50000. Notice that, though bigger values won't cause harm (will only make the system more sensible to storms), smaller values can cause the feature be triggered by the normal equipment traffic.
To set a limit of bytes received by the interface per second:
Step 1 - Run bootconf.
370 | Appendix B -
The following screen appears:
Current configuration
MAC address assigned to Ethernet [00:60:2e:00:16:b9]
IP address assigned to Ethernet interface
[192.168.160.10]
Watchdog timer ((A)ctive or (I)nactive) [A]
Firmware boot from ((F)lash or (N)etwork) [F]
Boot type ((B)ootp,(T)ftp or Bot(H)) [T]
Boot File Name [zvmppcts.bin]
Server's IP address [192.168.160.1]
Console speed [9600]
(P)erform or (S)kip Flash test [P]
(S)kip, (Q)uick or (F)ull RAM test [F]
Fast Ethernet ((A)uto Neg, (1)00 BtH, 100 Bt(F), 10
B(t)F, 10 Bt(H)) [A]
Fast Ethernet Maximum Interrupt Events [0]
Maximum rate of incoming bytes per second [0]
Step 2 - Press <Enter> for all fields but the Maximum rate of incoming bytes per second
field.
Step 3 - Between the brackets following the Maximum rate of incoming bytes per second
field, type the maximum amount of bytes that can be received by the interface per second.
A value of zero disables the feature. Enter a value of 50000 for optimum performance.
Note: Using larger values does not harm your system but makes it more sensible to storms. Using smaller values, however, can trigger this feature be triggered by the normal equipment traffic.
Step 4 - When presented the following line:
Do you confirm these changes in flash ( (Y)es, (N)o (Q)uit
) [N] :
Enter Y to save the changes in flash.
| 371
B.3 LEDs
CPU LEDs
Normally the CPU status LED should blink consistently one second on, one second off.
If this is not the case, an error has been detected during the boot. The blink pattern can be interpreted via the following table:
Event CPU LED Morse code
Normal Operation
Flash Memory Error - Code
S (short, short, short . . . )
L (long, long, long . . . )
Flash Memory Error - Configuration S, L
Ethernet Error S, S, L
No Interface Card Detected
Network Boot Error
Real-Time Clock Error
S, S, S, L
S, S, S, S, L
S, S, S, S, S, L
Table B.1: CPU LED Code Interpretation
NOTE:
The Ethernet error mentioned in the above table will occur automatically if the Fast
Ethernet link is not connected to an external hub during the boot. If the Fast Ethernet is not being used or is connected later, this error can be ignored.
Rear Panel LEDs
The CS' rear panel has connectors (serial, console and Ethernet) with some LEDs that have the following functionality:
Ethernet Connector
•
Col (collision) - Shows collision on the LAN every time the unit tries to transmit an Ethernet packet.
•
DT/LK (data transaction/link state) - DT flashes when there's data transmitted to or received from the LAN. It's hardware-controlled. LK keeps steady if the LAN is active. The green LED is Data Transaction activity and the yellow one is LinK state.
•
100 - If 100BT is detected the LED lights on. If 10BT is detected it turns off.
372 | Appendix B -
Console Connector
•
CP - CPU activity. It flashes at roughly 1 second intervals.
•
P1 - Power supply #1 ON.
•
P2 - Power supply #2 ON.
Serial Connector
•
LK - DTR. It's software-controlled.
•
DT - Data transmitted to or received from the serial line. It's hardware-controlled.
Administration parameters in the CLI interface
Some of the procedures described above can be configured using the CLI interface.
Below we will divide it into boot and administration configuration:
Boot configuration parameters:
To configure boot parameters access the menu: cli>config administration bootconfig
Entering this menu you will be able to configure the following parameters:
•
boottype - Chooses the network boot type. Valid values are: tftp, bootp or both.
•
bootunit - Sets from where the unit will boot from. Valid values are: flash and
network.
•
consolespeed - To configure the console speed. Valid values are: 115200, 57600,
38400, 19200, 9600 and 4800.
•
ethernetip - Temporary IP address assigned to the Ethernet interface.
•
ethernetmode - Fast Ethernet mode. Valid values for this field are: auto, 10F, 10H,
100H, 100F.
•
filename - File name of the image placed in the tftp server.
•
flashtest - Enables or disables the flash test. Valid values are: full and skip.
•
maxevents - Maximum number of Ethernet events handled at once.
•
ramtest - Chooses the type of ram test. Valid values are: full, quick and skip.
•
tftpserver - Sets up the IP address of the tftpserver.
•
wdt - To enable/disable wdt (watch dog timer).
Administration Menu:
Basically the administration section of the CLI interface is divided in 3 parts: Session
Management, Backup Configuration and Firmware Upgrade that was already approached in this chapter; see
“CLI Method - Firmware Upgrade” on page 363
| 373
Session Management: To manage sessions, access: cli>administration sessions
This menu lets you do following:
•
kill - To cancel a connection to the serial port <n>
•
list - Lists the current sessions
Backup Configuration: It is possible to save/restore configurations to/from a FTP server. To configure it, access the menu: cli>administration backupconfig
The following options can be set up:
•
loadfrom - When loading configuration from a server it is necessary to specify: server IP address <serverip>; username <username>; password <password>; path <pathname>.
•
saveto - The same parameters of the loadfrom command must be specified.
Example: The command below will load configuration from a server with IP address 192.168.0.1, username “john”, password “john1234” and the configuration file located at /home/configuration.
backupconfig>loadfrom serverip 192.168.0.1 pathname /home/configuration username john password john1234
374 | Appendix B -
Appendix C
Cabling and Hardware
..........................................................................
Information
Appendix CAppendix C - Cabling and Hardware Information
This appendix will show all hardware specifications of the CS . It will also show all cables and connectors characteristics.
C.1 General Hardware Specifications
The power consumption and heat dissipation, environmental conditions and physical specifications of the CS are listed below.
BLACK BOX® Advanced Console Server Products Power Consumption and
Heat Dissipation
Input = 120Vac Input = 230 Vac
Model Power (watts)
Heat Exchange
(BTU/hr.)
Power (Watts)
Heat Exchange
(BTU/hr.)
LS1001A
LS1004A
LS1008A
LS1016A
LS1032A
LS1048A
12
16
18
22
24
26
41.0
54.6
61.5
75.1
81.0
88.8
17
25
28
30
32
35
Table C.1: CS Products Power Consumption and Heat Dissipation
58.1
85.4
95.6
102.5
109.3
119.5
Environmental Information
LS1001A LS1004A LS1008A LS1016A LS1032A LS1048A
Operating
Temperature
50F to 122F
(10ºC to
50ºC)
50F to 112F
(10ºC to
44ºC)
50F to 112F
(10ºC to
44ºC)
50F to 112F
(10ºC to
44ºC)
50F to 112F
(10ºC to
44ºC)
50F to 112F
(10ºC to
44ºC)
Relative
Humidity
10 - 90%, noncondensing
10 - 90%, noncondensing
10 - 90%, noncondensing
10 - 90%, noncondensing
10 - 90%, noncondensing
10 - 90%, noncondensing
Table C.2: CS environmental conditions
Physical Information
External
Dimensions
Weight
LS1001A LS1004A LS1008A LS1016A LS1032A LS1048A
2.76in.x
3.35in.x
1.18 in.
0.3 lb.
8,5in.x
4,75in.
x1 in.
1.5 lb.
8.5 in.x
4.75 in.x
1 in.
1.6 lb.
17 in. x
8.5 in.x
1.75 in.
6 lb.
Table C.3: CS physical information
17 in.x
8.5 in.x
1.75 in.
6.2 lb.
17 in. x
8.5 in.x
1.75 in.
8 lb.
Safety Information
Approvals
LS1001A LS1004A LS1008A LS1016A LS1032A LS1048A
FCC and CE, Class A
Table C.4: CS Safety Information
The following section has all the information you need to quickly and successfully purchase or build cables to the CS . It focuses on information related to the RS-232 interface, which applies not only to the CS but also to any RS-232 cabling.
376 | Appendix C -
The RS-232 Standard
RS-232C, EIA RS-232, or simply RS-232 refer to a standard defined by the Electronic
Industries Association in 1969 for serial communication. More than 30 years later, more applications have been found for this standard than its creators could have imagined.
Almost all electronic devices nowadays have serial communication ports.
RS-232 was defined to connect Data Terminal Equipment, (DTE, usually a computer or terminal) to Data Communication Equipment (DCE, usually a modem):
DTE > RS-232 > DCE > communication line > DCE > RS-232 > DTE
RS-232 is now mostly being used to connect DTE devices directly (without modems or communication lines in between). While that was not the original intention, it is possible with some wiring tricks. The relevant signals (or wires) in a RS-232 cable, from the standpoint of the computer (DTE), are:
•
Receive Data (RxD) and Transmit Data (TxD) - The actual data signals
•
Signal Ground (Gnd) - Electrical reference for both ends
•
Data Terminal Ready (DTR) - Indicates that the computer (DTE) is active
•
Data Set Ready (DSR) - Indicates that the modem (DCE) is active.
•
Data Carrier Ready (DCD) - Indicates that the connection over the communication line is active
•
CTS (Clear to Send, an input) - Flow control for data flowing from DTE to DCE
•
RTS (Request to Send, an output) - Flow control for data flowing from DCE to
DTE
Not all signals are necessary for every application, so the RS-232 cable may not need all
7 wires. The RS-232 interface defines communication parameters such as parity, number of bits per character, number of stop-bits and the baud rate. Both sides must be configured with the same parameters. That is the first thing to verify if you think you have the correct cable and things still do not work. The most common configuration is
8N1 (8 bits of data per character, no parity bit included with the data, 1 stop-bit to indicate the end of a character). The baud rate in a RS-232 line translates directly into the data speed in bits per second (bps). Usual transmission speeds range between 9,600 bps and 19,200bps (used in most automation and console applications) to 115,200 bps
(used by the fastest modems).
Cable Length
The original RS-232 specifications were defined to work at a maximum speed of 19,200 bps over distances up to 15 meters (or about 50 feet). That was 30 years ago. Today, RS-
232 interfaces can drive signals faster and through longer cables. As a general rule, consider:
•
If the speed is lower than 38.4 kbps, you are safe with any cable up to 30 meters
(100 feet)
| 377
•
If the speed is 38.4 kbps or higher, cables should be shorter than 10 meters (30 feet)
•
If your application is outside the above limits (high speed, long distances), you will need better quality (low impedance, low-capacitance) cables.
Successful RS-232 data transmission depends on many variables that are specific to each environment. The general rules above are empirical and have a lot of safety margins built-in.
378 | Appendix C -
C.2 Connectors
The connector traditionally used with RS-232 is the 25-pin D-shaped connector (DB-
25). Most analog modems and most older computers and serial equipment use this connector. The RS-232 interface on DB-25 connector always uses the same standard pin assignment.
The 9-pin D-shaped connector (DB-9) saves some space and is also used for RS-232.
Most new PC COM ports and serial equipment (specially when compact size is important) uses this connector. RS-232 interfaces on DB-9 connectors always use the same standard pin assignment.
The telephone-type modular RJ-45 plug and jack are very compact, inexpensive and compatible with the phone and Ethernet wiring systems present in most buildings and data centers. Most networking equipment and new servers use RJ-45 connectors for serial communication. Unfortunately there is no standard RS-232 pin assignment for RJ-
45 connectors. Every equipment vendor has its own pin assignment.
Most connectors have two versions. The ones with pins are said to be “male” and the ones with holes are said to be “female.”
RS-232
Signal
Chassis
TxD
RxD
DTR
DSR
DCD
RTS
CTS
GnD
Name/Function
(Input/Output)
Safety Ground
Transmit Data (O)
Receive Data (I)
Data Terminal Ready (O)
Data Set Ready (I)
Data Carrier Detect (I)
Request To Send (O)
Clear To Send (I)
Signal Ground
DB-25 pins
(Standard)
DB-9 pins
(Standard)
RJ-45 pins
(Black Box)
1
2
3
20
6
8
4
5
7
7
8
6
1
5
Shell
3
2
4
Table C.5: Cables and their pin specifications
1
5
8
7
4
Shell
3
6
2
| 379
Straight-Through vs. Crossover Cables
The RS-232 interface was originally intended to connect a DTE (computer, printer and other serial devices) to a DCE (modem) using a straight-through cable (all signals on one side connecting to the corresponding signals on the other side one-to-one). By using some “cabling tricks,” we can use RS-232 to connect two DTEs as is the case in most modern applications.
A crossover (a.k.a. null-modem) cable is used to connect two DTEs directly, without modems or communication lines in between. The data signals between the two sides are transmitted and received and there are many variations on how the other control signals are wired. A “complete” crossover cable would connect TxD with RxD, DTR with
DCD/DSR, and RTS with CTS on both sides. A “simplified” crossover cable would cross TxD and RxD and locally short-circuit DTR with DCD/DSR and RTS with CTS.
Which cable should be used?
First, look up the proper cable for your application in the table below. Next, purchase standard off-the-shelf cables from a computer store or cable vendor. For custom cables, refer to the cable diagrams to build your own cables or order them from BLACK BOX® or a cable vendor.
To Connect To Use Cable
DCE DB-25 Female (standard)
•
•
Analog Modems
ISDN Terminal Adapters
Cable 1:
RJ-45 to DB-25 M straight-through (Custom). This custom cable can be ordered from BLACK BOX® or other cable vendors. A sample is included with the product (“straight-through”).
DTE RJ-45 BLACK BOX® (custom)
•
All BLACK BOX®
Console Ports
Cable 2:
RJ-45 to RJ-45 crossover (custom). A sample is included with the product (“straight-through”) This custom cable can be ordered from BLACK BOX® or other cable vendors using the provided wiring diagram.
Table C.6: Which cable to use
Cable Diagrams
Before using the following cable diagrams refer to the tables above to select the correct cable for your application. Sometimes, crossover cables are wired slightly differently depending on the application. A “complete” crossover cable would connect the TxD with RxD, DTR with DCD/DSR, and RTS with CTS across both sides. A “simplified” crossover cable would cross TxD and RxD and locally short-circuit DTR with
DCD/DSR and RTS with CTS.
380 | Appendix C -
Most of the diagrams in this document show the “complete” version of the crossover cables, with support for modem control signals and hardware flow control. Applications that do not require such features have just to configure NO hardware flow control and
NO DCD detection on their side. Both ends should have the same configuration for better use of the complete version of the cables.
NOTE:
These cables appear in Cable Package #1 and/or Cable Package #2. You may or may not find them in your box depending on which package you received.
| 381
C.3 Cable Packages
Cable #1: BLACK BOX® RJ-45 to DB-25 Male, straight-through
Application: This cable connects BLACK BOX® products (serial ports) to modems and other DCE RS-232 devices. It is included in both Cable Package #1 and #2.
Figure C.7 - Cable 1 - BLACK BOX® RJ-45 to DB-25 Male, straight-through
Cable #2: BLACK BOX® RJ-45 to DB-25 Female/Male, crossover
This cable connects BLACK BOX® products (serial ports) to console ports, terminals, printers and other DTE RS-232 devices. If you are using Cable Package #1, after connecting the appropriate adapter to the RJ-45 straight-through cable, you will essentially have the cable shown in this picture. If you are using Cable Package #2, no assembly is required. You will have the cable shown below.
Cable #3: BLACK BOX® RJ-45 to DB-9 Female, crossover
This cable connects BLACK BOX® products (serial ports) to console ports, terminals, printers and other DTE RS-232 devices. If you are using Cable Package #1, after connecting the appropriate adapter to the RJ-45 straight-through cable, you will essentially have the cable shown in this picture. If you are using Cable Package #2, no assembly is required. You will have the cable shown below.
382 | Appendix C -
Figure C.8 - Cable 3 - BLACK BOX® RJ-45 to DB-9 Female, crossover
Cable #4: BLACK BOX® RJ-45 to BLACK BOX® RJ-45, straight- through
This cable is the main cable that you will use. Along with one of the adapters provided
(RJ-45 to DB-9 or RJ-45 to DB-25) you can create a crossover cable like the ones explained in Cable #2 or #3 for configuration or to connect to a server. This cable is only included in Cable Package. #1.
Figure C.9 - Cable 4 - BLACK BOX® RJ-45 to BLACK BOX® RJ-45, straight-through
Cable #5: BLACK BOX®/Sun Netra Cable
This Adapter attaches to a Cat 3 or Cat 5 network cable. It is usually used in console management applications to connect BLACK BOX® products to a Sun Netra server or to a Cisco product. This cable is included in Cable Package #2.
| 383
Figure C.10 - Cable 4 - BLACK BOX® RJ-45 to BLACK BOX® RJ-45, straightthrough
Adapters
The following four adapters are included in the product box. A general diagram is provided below and then a detailed description is included for each adapter.
Loop-Back Connector for Hardware Test
The use of the following DB-25 connector is explained in the Troubleshooting chapter.
It is included in both Cable Package #1 and #2.
TxD
RxD
RTS
CTS
DSR
DCD
DTR
Figure C.11 - Loop-Back Connector
384 | Appendix C -
BLACK BOX®\Sun Netra Adapter
This Adapter attaches to a Cat 3 or Cat 5 network cable. It is usually used in console management applications to connect BLACK BOX® products to a Sun Netra server or to a Cisco product. At one end of the adapter is the black CAT.5e Inline Coupler box with a female RJ-45 terminus, from which a 3-inch-long black Sun Netra-labeled cord extends, terminating in an RJ-45 male connector. This adapter is included in Cable
Package #2.
Figure C.12 - BLACK BOX®\Sun Netra Adapter
RJ-45 Female to DB-25 Male Adapter
The following adapter may be necessary. It is included in Cable Package #1.
Figure C.13 - RJ-45 Female to DB-25 Male Adapter
RJ-45 Female to DB-25 Female Adapter
The following adapter may be necessary. It is included in Cable Package #1.
| 385
Figure C.14 - RJ-45 Female to DB-25 Female Adapter
RJ-45 Female to DB-9 Female Adapter
The following adapter may be necessary. This is included in Cable Package #1.
386 | Appendix C -
Figure C.15 - RJ-45 Female to DB-9 Female Adapter
C.4 LS1001A-only Cabling Information
LS1001A Connectors
RS-485 Signal Name/Function Terminal Block pins
Chassis
TXA-
TXB+
RXA-
RXB
Chassis
Not in use
Transmit Data - (A)
Transmit Data + (B)
Receive Data - (A)
Receive Data + (B)
Not in use
Table C.16: RS-485 Pinout for the LS1001A - Connector pin assignment
3
4
1
2
5
6
LS1001A-only Cabling Information
The RS-485 Standard
The RS-485 is another standard for serial communication and is available only in the
LS1001A. Different from the RS-232, the RS-485 uses fewer wires - either two wires
(one twisted pair) for half duplex communication or four wires (two twisted pairs) for full duplex communication. Another RS-485 characteristic is the “termination.” In a network that uses the RS-485 standard, the equipment is connected one to the other in a cascade arrangement. A “termination” is required from the last equipment to set the end of this network.
LS1001A Connectors
Although the RS-485 can be provided in different kinds of connectors, the LS1001A uses a 9-pin D-shaped connector (DB-9) and a Terminal Block with the pin assignment described below.
| 387
Cable #1: Terminal Block to Terminal Block, crossover half duplex
Application: It connects the LS1001A (serial port) to DTE RS-485 devices with half duplex communication.
Figure C.17 - Cable 1 for the LS1001A - Terminal Block to Terminal Block, crossover half duplex
Cable #2: Terminal Block to Terminal Block, crossover full duplex
Application: It connects the LS1001A(serial port) to DTE RS-485 devices with full duplex communication.
Figure C.18 - Cable 2 LS1001A - Terminal Block to Terminal Block, crossover full duplex
388 | Appendix C -
Cable #3: DB-9 Female to DB-25 Female, crossover
This cable connects the LS1001A to console ports, terminals, printers and other DTE RS-232 devices. You will essentially have the cable shown in this picture:
Figure C.19 - Cable 3 for the LS1001A - DB-9 Female to DB-25 Female, crossover
| 389
This page has been left intentionally blank.
390 | Appendix C -
Glossary
Authentication
Authentication is the process of identifying an individual, usually based on a username and password. In security systems, authentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity.
Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. (Source: www.webopedia.com)
Break Signal
A break signal is generated in an RS-232 serial line by keeping the line in zero for longer than a character time. Breaks at a serial console port are interpreted by Sun servers as a signal to suspend operation and switch to monitor mode.
Console Access Server (CAS)
A CAS has an Ethernet LAN connection and many RS-232 serial ports. It connects to the console ports of servers and networking equipment and allows convenient and secure access from a single location.
Console Port
Most of the equipment in a data center (servers, routers, switches, UPS, PBX, etc.) has a serial console port for out-of-band management purposes.
Cluster
A cluster is a group of one or more computers working as a group to execute a certain task. From the user standpoint, a cluster acts as a large computer system.
Flash
Flash refers to a type of memory that can be erased and reprogrammed in units of memory known as blocks rather than one byte at a time; thus, making updating to memory easier.
In-band network management
In a computer network, when the management data is accessed using the same network that carries the data, this is called “in-band management.”
IP packet filtering
This is a set of facilities in network equipment that allows the filtering of data packets based on source/destination addresses, protocol, TCP port number and other parameters.
Packet filtering is one of the main functions of a firewall.
KVM Switch (KVM)
Keyboard-Video-Mouse Switches connect to the KVM ports of many computers and allow the network manager to access them from a single KVM station.
Mainframe
Large, monolithic computer system.
MIBs
Management Information Bases. SNMP-compliant devices, called agents, store data about themselves in MIBs and return this data to the SNMP requesters.
Out-of-band network management
In a computer network, when the management data is accessed through a network that is independent of the network used to carry data, this is called “out-of-band network management.”
Off-line data buffering
This is a CAS feature that allows capture of console data even when there is no one connected to the port.
Profile
Usage setup of the CS : either as a Console Access Server (CAS), a Terminal Server, or a Remote Access Server.
RADIUS
Protocol between an authentication server and an access server to authenticate users trying to connect to the network.
396 | Chapter E -
RISC
Reduced Instruction Set Computer. This describes a computer processor architecture that uses a reduced set of instructions (and achieves performance by executing those instructions very fast.) Most UNIX servers (Sun Sparc, HP, IBM RS6000, Compaq
Alpha) were designed with a processor using a RISC architecture. The Intel ® x86 architecture.
RS-232
A set of standards for serial communication between electronic equipment defined by the Electronic Industries Association in 1969. Today, RS-232 is still widely used for low-speed data communication.
Secure Shell (SSH)
SSH has the same functionality as Telnet (see definition below), but adds security by encrypting data before sending it through the network.
Server Farm
A collection of servers running in the same location (see Cluster).
Shadow Password
Normally, each user's password is stored, encrypted, in the file /etc/passwd. This file must be readable by all users so that certain system functions will operate correctly. This means that copies of user's encrypted passwords are easily obtained, making it possible to run an automated password-guessing program against them. Shadow passwords, on the other hand, store the encrypted passwords in a separate highly-protected file, making it much more difficult to crack passwords.
SNMP
Short for Simple Network Management Protocol, a set of protocols for managing complex networks. The first versions of SNMP were developed in the early 80s. SNMP works by sending messages, called protocol data units (PDUs), to different parts of a network. SNMP-compliant devices, called agents, store data about themselves in
Management Information Bases (MIBs) and return this data to the SNMP requesters.
(Source: Webopedia)
| 397
Telnet
Telnet is the standard set of protocols for terminal emulation between computers over a
TCP/IP connection. It is a terminal emulation program for TCP/IP networks such as the
Internet. The Telnet program runs on your computer and connects your PC to a server on the network. You can then enter commands through the Telnet program and they will be executed as if you were entering them directly on the server console. This enables you to control the server and communicate with other servers on the network. To start a
Telnet session, you must log in to a server by entering a valid username and password.
Telnet is a common way to remotely control Web servers. (from webopedia.com)
Terminal Server
A terminal server has one Ethernet LAN port and many RS-232 serial ports. It is used to connect many terminals to the network. Because they have the same physical interfaces, terminal servers are sometimes used as console access servers.
TTY
The UNIX name for the COM (Microsoft) port.
U Rack height unit
A standard computer rack has an internal width of 17 inches. Rack space on a standard rack is measured in units of height (U). One U is 1.75 inches. A device that has a height of 3.5 inches takes 2U of rack space.
X.509
A widely used standard for defining digital certificates. X.509 is an ITU recommendation, which means that it has not yet been officially defined or approved for standardized usage. As a result, companies have implemented the standard in different ways. For example, both Netscape and Microsoft use X.509 certificates to implement
SSL in their Web servers and browsers. But an X.509 Certificate generated by Netscape may not be readable by Microsoft products, and vice versa.
398 | Chapter E -
List of Tables
..........................................................................
2. Data buffering parameters in /etc/portslave/pslave.conf file . . . . . . . . . . . 30
3. Master configuration (where it differs from the CAS standard) . . . . . . . . . 39
4. Slave 1 configuration (where it differs from the CAS standard) . . . . . . . . 41
5. Slave 2 configuration (where it differs from the CAS standard) . . . . . . . . 41
7. Authentication parameters in /etc/portslave/pslave.conf . . . . . . . . . . . . . . 54
8. Authentication Servers and File Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
12. Available PAM modules in the CS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
14. Required information for the OpenSSL package . . . . . . . . . . . . . . . . . . . 91
15. DHCP related files and commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
16. Actions and options for the route command . . . . . . . . . . . . . . . . . . . . . . 105
30. “Global Options” parameters (Syslog-ng configuration) . . . . . . . . . . . . 160
31. “Source Drivers” parameters (Syslog-ng configuration) . . . . . . . . . . . . 161
32. “Filters” parameters (Syslog-ng configuration) . . . . . . . . . . . . . . . . . . . 163
33. “Destination Drivers” parameters (Syslog-ng configuration) . . . . . . . . . 166
35. pslave.conf parameters for Terminal Appearance configuration . . . . . . 187
36. /etc/daemon.d/ntpclient.conf parameters . . . . . . . . . . . . . . . . . . . . . . . . 197
38. Power Management Individual IPDUs Menu . . . . . . . . . . . . . . . . . . . . 225
39. Menu Options for Multi-Outlet Control PM Utility . . . . . . . . . . . . . . . . 227
40. AlterPath PM regular user menu options . . . . . . . . . . . . . . . . . . . . . . . . 231
41. CDMA configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
42. /etc/portslave/pslave.conf common parameters . . . . . . . . . . . . . . . . . . . 290
43. CAS specific parameters for the pslave.conf . . . . . . . . . . . . . . . . . . . . . 299
44. TS specific parameters for the pslave.conf file . . . . . . . . . . . . . . . . . . . . 309
45. Dial-in specific parameters for the pslave.conf . . . . . . . . . . . . . . . . . . . 311
46. Bidirectional Telnet specific parameters for pslave.conf . . . . . . . . . . . . 313
48. Elements in the <channel-switch> tag . . . . . . . . . . . . . . . . . . . . . . . . . . 326
51. f_windows_boot available macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
400 | List of Tables
58. CPU LED Code Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
59. CS Products Power Consumption and Heat Dissipation . . . . . . . . . . . . 375
65. RS-485 Pinout for the LS1001A - Connector pin assignment . . . . . . . . 387
List of Tables
| 401
402 | List of Tables
Appendix D
Copyrights
..........................................................................
Appendix D - Copyrights
The BLACK BOX® Advanced Console Server is based in the HardHat Linux distribution, developed by Montavista Software for embedded systems. Additionally, several other applications were incorporated into the product, in accordance with the free software philosophy.
The list below contains the packets and applications used in the BLACK BOX®
Advanced Console Server and a reference to their maintainers. The copyrights notices required in some packets are placed in the /COPYRIGHTS directory of the BLACK
BOX® Advanced Console Server .
Bash
Bourne Again Shell version 2.0.5a. Extracted from the HardHat Linux distribution.
http://www.gnu.org/software/bash
Bootparamd
NetKit Bootparamd version 0.17
ftp://ftp.uk.linux.org/pub/linux/Networking/netkit
Busybox
BusyBox version 1.0 ftp://ftp.lineo.com/pub/busybox/
Cron
Paul Vixie's cron version 3.0.1. [email protected]
DHCPCD
PhysTech DHCP Client Daemon version 1.3.20.p10. http://www.phystech.com/download/dhcpcd.html
Flex
Flex version 2.5.4
COPYRIGHT: This product includes software developed by the University of
California, Berkeley and its contributors
GNU
The GNU project http://www.gnu.org
HardHat Linux
MontaVista Software - HardHat version 2.1
http://www.montavista.com
IPSec
The Linux Openswan IPsec version 2.3.0
http://www.openswan.org
IPtables
Netfilter IPtables version 1.2.2. Extracted from the HardHat Linux distribution.
http://www.netfilter.org
Linux Kernel
Linux Kernel version 2.2.17 2.4.18. Extracted from the HardHat Linux distribution http://www.kernel.org
Net-SNMP
SourceForge Net-SNMP project version 5.2.1.2
http://sourceforge.net/projects/net-snmp/
NTP
NTP client http://doolittle.faludi.com/ntpclient/
392 | Appendix D -
OpenSSH
OpenSSH version 4.1p1
http://www.openssh.org
COPYRIGHT: This product includes software developed by the University of
California, Berkeley and its contributors.
OpenSSL
OpenSSL Project version 0.9.8
http://www.openssl.org
COPYRIGHT: This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)
COPYRIGHT: This product includes cryptographic software written by Eric Young
PAM
Linux PAM version 0.75
http://www.kernel.org/pub/linux/libs/pam/
Portslave
SourceForge Portslave project version 2000.12.25. (modified). Includes pppd version
2.4.1 and rlogin version 8.10
http://sourceforge.net/projects/portslave/
RSYNC
rsync version 2.5.5
http://rsync.samba.org/rsync/
Syslog-ng
Syslog new generation version 1.5.17
http://www.balabit.hu/products/syslog-ng/
Tinylogin
TinyLogin version 0.80 ftp://ftp.lineo.com/pub/tinylogin/
| 393
UCD-SNMP
SourceForge Net-SNMP project version 5.2.1.2
http://sourceforge.net/projects/net-snmp/
WEBS
GoAhead WEBS version 2.1 (modified) http://goahead.com/webserver/webserver.htm
Copyright (c) 20xx GoAhead Software, Inc. All Rights Reserved
ZLIB
zlib version 1.2.3 http://www.gzip.org/zlib/
394 | Appendix D -
List of Figures
..........................................................................
1. An example using the Clustering feature . . . . . . . . . . . . . . . . . . . . . . . . . .38
2. Data flow diagram of Linux-PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
3. Example of Centralized Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
5. Console Access Server diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316
6. CAS diagram with various authentication methods . . . . . . . . . . . . . . . . 317
10. Second screen, showing changed positions . . . . . . . . . . . . . . . . . . . . . . 367
11. Cable 1 - BLACK BOX® RJ-45 to DB-25 Male, straight-through . . . 382
12. Cable 3 - BLACK BOX® RJ-45 to DB-9 Female, crossover . . . . . . . . 383
13. Cable 4 - BLACK BOX® RJ-45 to BLACK BOX® RJ-45, straight-through
14. Cable 4 - BLACK BOX® RJ-45 to BLACK BOX® RJ-45, straight-through
16. BLACK BOX®\Sun Netra Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
17. RJ-45 Female to DB-25 Male Adapter . . . . . . . . . . . . . . . . . . . . . . . . . 385
18. RJ-45 Female to DB-25 Female Adapter . . . . . . . . . . . . . . . . . . . . . . . 386
19. RJ-45 Female to DB-9 Female Adapter . . . . . . . . . . . . . . . . . . . . . . . . 386
21. Cable 2 LS1001A - Terminal Block to Terminal Block, crossover full duplex
22. Cable 3 for the LS1001A - DB-9 Female to DB-25 Female, crossover 389
404 |
List of Figures
Download
Public link updated
The public link to your chat has been updated. You may view and manage your chat links after registration here.
Document public link
Advertisement
Key features
Secure and reliable access to console ports
Remote management of network devices
Support for multiple authentication methods
Advanced data buffering and management
Clustering capabilities for high availability
Power management integration with AlterPath PM
Frequently asked questions
You can configure the Advanced BLACK BOX Console Server using either the Command Line Interface (CLI) or the Virtual Interface (VI) mode.
The Advanced BLACK BOX Console Server supports a variety of authentication methods, including RADIUS, TACACS+, Kerberos, LDAP, and local user accounts.
Yes, the Advanced BLACK BOX Console Server supports clustering, which allows you to manage multiple devices from a single console.
You can access the console ports of your network devices remotely using Telnet or SSH connections.
Data buffering helps to ensure that data is not lost in case of network interruptions. You can configure data buffering using the CLI or VI mode.