Tripp Lite 0 Idades Manual

							241
Chapter 15: Advanced Configuration
Some examples of powerman targets:
Power on hosts bar,baz,foo01,foo02,...,foo05: powerman --on bar baz foo[01-05] 
Power on hosts bar,foo7,foo9,foo10: powerman --on bar,foo[7,9-10] 
Power on foo0,foo4,foo5: powerman --on foo[0,4-5] 
As a reminder to the reader, some shells will interpret brackets ([ and ]) for pattern matching. \
Depending on your shell, it may 
be necessary to enclose ranged lists within quotes. For example, in tcsh, the last example above should be executed as:
powerman --on "foo[0,4-5]"
15.9.2 pmpower
The pmpower command is a high-level tool for manipulating remote, preconfigured p\
ower devices connected to the Console 
Servers either via a serial or network connection.
pmpower [-?h] [-l device | -r host] [-o outlet] [-u username] [-p passwo\
rd] action
-?/-h  This help message.
-l      The serial port to use.
-o     The outlet on the power target to apply to
-r     The remote host address for the power target
-u     Override the configured username
-p     Override the configured password
on     This action switches the specified device or outlet(s) ON
off     This action switches the specified device or outlet(s) OFF
cycle  This action switches the specified device or outlet(s) OFF and ON ag\
ain
status  This action retrieves the current status of the device or outlet
Examples:
To turn outlet 4 of the power device connected to serial port 2 on:
# pmpower -l port02 -o 4 on
To turn an IPMI device located at IP address 192.168.1.100  to OFF (wher\
e username is 'root' and password is 'calvin':
# pmpower -r 192.168.1.100 -u root -p calvin off 
Default system Power Device actions are specified in /etc/powerstrips.xml. Custom Power Devices can be added in /etc/config/
powerstrips.xml. If an action is attempted which has not been configured for a specifi\
c Power Device, pmpower will exit with an 
error.
15.9.3 Adding new RPC devices 
There are two simple paths to adding support for new RPC devices. 
The first is to have scripts to support the particular RPC included in\
 the open source PowerMan project (http://sourceforge.net/
projects/powerman). The PowerMan device specifications are unusual and it is suggested that you leave \
the actual writing of 
these scripts to the PowerMan authors. However documentation on how they work can be found at \
http://linux.die.net/man/5/
powerman.dev. Once the new RPC support has been built into the PowerMan, we will include the updated PowerMan build in 
a subsequent firmware release.  
The second path is to directly add support for the new RPC devices (or \
to customize the existing RPC device support) on your 
particular Console Server. The Manage: Power page uses information contained in /etc/powerstrips.xml to configure and 
control devices attached to a serial port. The configuration also look\
s for (and loads) /etc/config/powerstrips.xml if it exists.
The user can add their own support for more devices by putting definit\
ions for them into /etc/config/powerstrips.xml. This 
file can be created on a host system and copied to the Management Cons\
ole device using scp. Alternatively, log in to the 
Management Console and use ftp or wget to transfer files.  
						

							242
Chapter 15: Advanced Configuration
Here is a brief description of the elements of the XML entries in /etc/config/powerstrips.xml.

 Name or ID of the device support
 Display Port 1 in menu
 Display Port 2 in menu
 ...
 script to turn power on
 script to power off
 script to cycle power
 script to write power status to /var/run/power-status
 baud rate
 character size
 stop bits
 parity setting

The id appears on the web page in the list of available devices types to confi\
gure.
The outlets describe targets that the scripts can control. For example, a power control board may control several different 
outlets. The port-id is the native name for identifying the outlet. This\
 value will be passed to the scripts in the environment 
variable outlet, allowing the script to address the correct outlet.
There are four possible scripts: on, off, cycle and status
When a script is run, its standard input and output is redirected to the\
 appropriate serial port. The script receives the outlet 
and port in the outlet and port environment variables respectively.
The script can be anything that can be executed within the shell.
All of the existing scripts in /etc/powerstrips.xml use the pmchat utility.
pmchat works just like the standard unix "chat" program,  only it ensures inte\
roperation with the port manager. 
The final options, speed, charsize, stop and parity define the recommended or default settings for the attached device.  
						

							243
Chapter 15: Advanced Configuration
15.10  IPMItool  
The Console Server includes the ipmitool utility for managing and configuring devices that support the Intelli\
gent Platform 
Management Interface (IPMI) version 1.5 and version 2.0 specificatio\
ns. 
IPMI is an open standard for monitoring, logging, recovery, inventory, and control of hardware that is implemented independent 
of the main CPU, BIOS, and OS. The service processor (or Baseboard Mana\
gement Controller, BMC) is the brain behind 
platform management and its primary purpose is to handle the autonomous \
sensor monitoring and event logging features. 
The ipmitool program provides a simple command-line interface to this BMC. It featur\
es the ability to read the sensor data 
repository (SDR) and print sensor values, display the contents of the \
System Event Log (SEL), print Field Replaceable Unit 
(FRU) inventory information, read and set LAN configuration paramete\
rs, and perform remote chassis power control. 
SYNOPSIS
ipmitool  [-c|-h|-v|-V] -I open  
ipmitool  [-c|-h|-v|-V] -I lan -H  
           [-p ] 
          [-U ] 
          [-A ] 
          [-L ] 
          [-a|-E|-P|-f ] 
          [-o ] 
           
ipmitool  [-c|-h|-v|-V] -I lanplus -H  
           [-p ] 
          [-U ] 
          [-L ] 
          [-a|-E|-P|-f ] 
          [-o ] 
          [-C ] 
             
DESCRIPTION
This program lets you manage Intelligent Platform Management Interface (\
IPMI) functions of either the local system, via a 
kernel device driver, or a remote system, using IPMI V1.5 and IPMI v2.0. These functions inc\
lude printing FRU information, 
LAN configuration, sensor readings, and remote chassis power control. \
IPMI management of a local system interface requires a compatible IPMI k\
ernel driver to be installed and configured. On Linux, 
this driver is called OpenIPMI and it is included in standard distributi\
ons. On Solaris, this driver is called BMC and is included 
in Solaris 10. Management of a remote station requires the IPMI-over-LAN interface to be enabled and configured. Depending 
on the particular requirements of each system, it may be possible to ena\
ble the LAN interface using ipmitool over the system 
interface.  
OPTIONS
-a   Prompt for the remote server password. 
-A   Specify an authentication type to use during IPMIv1.5 lan session activation. Supported types are 
NONE, PASSWORD, MD5, or OEM. 
-c   Present output in CSV (comma separated variable) format. This is not available with all c\
ommands. 
-C   The remote server authentication, integrity, and encryption algorithms to use for IPMIv2 lanplus 
connections. See table 22-19 in the IPMIv2 specification. The default \
is 3 which specifies RAKP-
HMAC-SHA1 authentication, HMAC-SHA1-96 integrity, and AES-CBC-128 encryption algorithms. 
-E   The remote server password is specified by the environment variable IPMI_PASSWORD. 
-f   Specifies a file containing the remote server password. If this opti\
on is absent, or if password_file is 
empty, the password will default to NULL. 
-h   Get basic usage help from the command line.   
						

							244
Chapter 15: Advanced Configuration
-H   Remote server address can be an IP address or hostname. This option is r\
equired for lan and lanplus 
interfaces. 
-I   Selects IPMI interface to use. Supported interfaces that are compiled in\
 and visible in the usage help 
output. 
-L    Force session privilege level. Can be CALLBACK, USER, OPERATOR, ADMIN. Default is ADMIN. 
-m   Set the local IPMB address. The default is 0x20 and there should be no n\
eed to change it for normal 
operation. 
-o    Select OEM type to support. This usually involves minor hacks in place i\
n the code to work around 
quirks in various BMCs from various manufacturers. Use -o list to see a list of current supported OEM 
types. 
-p    Remote server UDP port to connect to. Default is 623. 
-P   Remote server password is specified on the command line. If supported,\
 it will be obscured in the 
process list. Note! Specifying the password as a command line option is not recommended. 
-t   Bridge IPMI requests to the remote target address. 
-U    Remote server username, default is NULL user. 
-v   Increase verbose output level. This option may be specified multiple t\
imes to increase the level of 
debug output. If given three times, you will get hexdumps of all incomin\
g and outgoing packets. 
-V   Display version information. 
If no password method is specified, then ipmitool will prompt the user for a password. If no password is entered at the p\
rompt, 
the remote server password will default to NULL.  
SECURITY
The ipmitool documentation highlights that there are several security issues to be c\
onsidered before enabling the IPMI LAN 
interface. A remote station has the ability to control a system's power \
state as well as being able to gather certain platform 
information. To reduce vulnerability, it is strongly advised that the IPMI LAN interface only be enabled in \
'trusted' environments 
where system security is not an issue or where there is a dedicated secu\
re 'management network' or access has been provided 
through an Console Server. 
Further, it is strongly advised that you should not enable IPMI for remote acce\
ss without setting a password, and that the 
password should not be the same as any other password on that system. 
When an IPMI password is changed on a remote machine with the IPMIv1.5 lan interface, the new password is sent across the 
network as clear text. This could be observed and then used to attack th\
e remote system. It is thus recommended that IPMI 
password management only be done over IPMIv2.0 lanplus interface or the system interface on the local station. 
For IPMI v1.5, the maximum password length is 16 characters. Passwords longer than 16 characters will be truncated. 
For IPMI v2.0, the maximum password length is 20 characters; longer passw\
ords are truncated.    
						

							245
Chapter 15: Advanced Configuration
COMMANDS
help 
This can be used to get command-line help on ipmitool commands. It may also be placed at the end of commands to get 
option usage help. 
ipmitool help 
Commands: 
        raw Send a RAW IPMI request and print response 
        lan   Configure LAN Channels 
        chassis  Get chassis status and set power state 
        event      Send pre-defined events to MC 
        mc         Management Controller status and global enables 
        sdr        Print Sensor Data Repository entries and readings 
        sensor   Print detailed sensor information 
        fru           Print built-in FRU and scan SDR for FRU locators 
        sel           Print System Event Log (SEL) 
        pef           Configure Platform Event Filtering (PEF) 
        sol            Configure IPMIv2.0 Serial-over-LAN 
        isol          Configure IPMIv1.5 Serial-over-LAN 
        user          Configure Management Controller users 
        channel  Configure Management Controller channels 
        session    Print session information 
        exec           Run list of commands from file 
        set    Set runtime variable for shell and exec 
ipmitool chassis help 
Chassis Commands: status, power, identify, policy, restart_cause, poh, bootdev 
ipmitool chassis power help 
chassis power Commands: status, on, off, cycle, reset, diag, soft 
You will find more details on ipmitools at http://ipmitool.sourceforge.net/manpage.html
15.11  Scripts for Managing Slaves 
When the Console Servers are cascaded, the Master is in control of the s\
erial ports on the Slaves, and the Master’s 
Management Console provides a consolidated view of the settings for its \
own and all the Slave’s serial ports. However, the 
Master does not provide a fully consolidated view, e.g. Status: Active Users. It only displays those users active on the Master’s 
ports. You will need to write a custom bash script that parses the port logs if \
you want to find out who's logged in to cascaded 
serial ports from the master.
You will probably also want to enable remote or USB logging, as local log\
s only buffer 8K of data and don't persist between 
reboots.
This script would parse each port log file line by line. Each time it \
sees ‘LOGIN: username', it adds the username to the list 
of connected users for that port, each time it sees 'LOGOUT: username' it removes it from the list. The list can then be nicely 
formatted and displayed. It is also possible to run this as a CGI script\
 on the B092-016. In this case, the remote/USB logged 
port logs files are in: /var/run/portmanager/logdir (or they are in /var/log). Otherwise you can run the script on the remote log 
server.
To enable log storage and connection logging:
• Select Alerts & Logging: Port Log
• Configure log storage
• Select Serial & Network: Serial Port, Edit the serial port(s)
• Under Console Server, select Logging Level 1 and click Apply  
						

							246
Chapter 15: Advanced Configuration
To run the CGI script on the Console Server:
• Login to the B092-016
• Run: mount -o remount,rw /dev/hda1 /
• Copy the script to /home/httpd/cgi-bin/
• Run: mount -o remount,ro /dev/hda1 /
• Browse to: http://192.168.0.1/cgi-bin/yourscript.cgi where 192.168.0.1 i\
s the IP address of the Console Server and 
yourscript.cgi is the name of the script
There is a useful tutorial on creating a bash script CGI at http://www.yolinux.com/TUTORIALS/LinuxTutorialCgiShellScript.html
Similarly the Master maintains a view of the status of the Slaves:
• Select Status: Support Report
• Scroll down to Processes
• Look for: /bin/ssh -MN -o ControlPath=/var/run/cascade/%h Slavename. These are the Slaves that are connect\
ed 
Note: The end of the Slaves' names will be truncated, so the first 5 c\
haracters must be unique
Alternatively, you can write a custom CGI script as described above. The currently co\
nnected Slaves can be determined by 
running: ls /var/run/cascade and the configured Slaves can be displayed by running: config -g config.cascade.Slaves
15.12  SMS Server Tools 
Console Servers include the SMS Server Tools software which provides an SMS Gateway which can send and receive short 
messages through GSM modems and mobile phones. 
You can send short messages by simply storing text files into a special\
 spool directory. The program monitors this directory 
and sends new files automatically. It also stores received short messages into another directory as text \
files. Binary messages 
(including Unicode text) are also supported, for example ring tone mes\
sages. It's also possible to send a WAP Push message 
to the WAP / MMS capable mobile phone. 
The program can be run as a SMS daemon which can be started automaticall\
y when the operating system starts. High 
availability can be ensured by using multiple GSM devices (currently up\
 to 64, this limit is easily changeable). 
The program can run other external programs or scripts after events like\
 reception of a new message, successful sending and 
also when the program detects a problem. These programs can inspect the \
related text files and perform automatic actions
The SMS Server Tools software needs a GSM modem (or mobile phone) with SMS command set\
 according to the European 
specifications GSM 07.05 (=ETSI TS 300 585) and GSM 03.38 (=ETSI TS\
 100 900). AT command set is supported. Devices 
can be connected with serial port, infrared or USB. 
For more information, refer to http://smstools3.kekekasvi.com 
15.13  Multicast  
By default, Console Servers have Multicasting enabled. Multicasting prov\
ides products with the ability to simultaneously 
transmit information from a single device to a select group of hosts.  
Multicasting can be disabled and re-enabled from the command line.  To disable multicasting type:
  ifconfig eth0 –multicast
To re-enable multicasting from the command line type:         
 ifconfig eth0 multicast
IPv6 may need to be restarted when toggling between multicast states.   
						

							247
Chapter 15: Advanced Configuration
15.14  Zero Touch Provisioning
Zero Touch Provisioning (ZTP) was introduced with firmware release 3.15 to\
 allow appliances to be provisioned during their 
initial boot from a DHCP server.
15.14.1 Preparation
These are typical steps for configuration over a trusted network:
1. Configure a same-model appliance.
2. Save the configuration as a backup (.opg) file under System: Configuration Backup in the web UI, or via config -e in the 
CLI. Alternatively, you can save the XML configuration as a file ending in .xml.
3. Publish the .opg or.xml file on a fileserver that understands one of the HTTPS, HTTP, FTP or TFTP protocols.
4. Configure your DHCP server to include a “vendor specific” opti\
on for Tripp Lite appliances. The option text should be a URL 
to the location of the .opg or .xml file. The option text should not e\
xceed 250 characters in length. It must end in either 
.opg or .xml.
5. Connect a new appliance (either at defaults from the factory, or config erased) to the network and apply power.
6. It may take up to 5 minutes for the device to find the .opg or .xml fi\
le via DHCP, download, install the file and reboot itself.
15.14.2 Example ISC DHCP server configuration
The following is an example of an ISC DHCP server configuration fragme\
nt for serving an .opg configuration image:
option space tripplite  code width 1  length width 1; 
option tripplite.config-url code 1 = text;
class “tripplite-ztp” { 
  match if option vendor-class-identifier ~~ “^TrippLite/”; 
  vendor-option-space tripplite; 
  option tripplite.config-url “https://example.com/opg/${class}.opg\
”; 
}
For other DHCP servers, please consult their documentation on specifying \
“Vendor Specific” option fields. We use sub-option 1 
to hold the URL text.
15.14.3 Setup for an untrusted L AN
If network security is a concern, and you can have remote hands insert a\
 trusted USB flash drive into the appliance during 
provisioning, then follow the steps below to configure in an untrusted\
 network:
1. Generate an X.509 certificate for the client. Place it and its private\
 key file onto a USB flash drive (concatenated as a 
single file, client.pem).
2. Set up a HTTPS server that restricts access to the .opg or .xml file for HTTPS connections providing the client certificate.
3. Put a copy of the CA cert (that signed the HTTP server’s certificate) onto the USB flash drive as well (ca-b\
undle.crt).
4. Insert the USB flash drive into the Appliance before attaching power or network.
5. Continue with the steps above, but using only a https URL.
6. Detailed step-by-step instructions for preparing a USB flash drive and using OpenSSL to create keys can be found later in 
this section.  
						

							248
15.14.4 How it works
This section explains in detail how the Appliance uses DHCP to obtain it\
s initial configuration.
First, an appliance is either configured or unconfigured. ZTP needs \
it to be in an unconfigured state, which is only obtained in 
the following ways:
• Firmware programming at factory
• Pressing the Config Erase button twice during operation
• Selecting Config Erase under System: Administration in the web UI, and rebooting
• Creating the file /etc/config/.init and then rebooting (command-lin\
e)
When an unconfigured appliance boots, it performs these steps to fin\
d a configuration:
• The appliance transmits a DHCP DISCOVER request onto its primary Network Interface (wan). This DHCP reques\
t will carry 
a Vendor Class Identifier of the form TrippLite/model-name (for example, TrippLite/B096-016) and its parameter request 
list will include option 43 (Vendor-Specific Information).
• On receipt of a DHCP OFFER, the device will use the information in the o\
ffer to assign an IPv4 address to its primary 
Network Interface, add a default route, and prepare its DNS resolver.
• If the offer also contained an option 43 with sub-option 1, the device i\
nterprets the sub-option as a whitespace-separated 
list of URLs to configuration files to try to restore.
• If an NTP server option was provided in the DHCP offer, the system clock is quickly synchronized with the NTP server.
• The system now searches all attached USB storage devices for two optiona\
l certificate files. The first file is named ca-
bundle.crt and the second one is whichever one of the following filena\
mes is found first:
o client-AABBCCDDEEFF.pem (where AABBCCDDEEFF is the MAC address of the primary network interface); or
o client-MODEL.pem (where MODEL is the (vendor class) model name in low\
ercase, truncated to before the first 
hyphen); or
o client.pem
• If both files are found (ca-bundle.crt and a client.pem), then secur\
e mode is enabled for the next section.
• Each URL in the list obtained from option 43 sub-option 1 is tried in se\
quence until one succeeds:
o The URL undergoes substring replacement from the following table:
SubstringReplaced by
${mac}the 12-digit MAC address of the appliance, lowercase 
${model}the full model name, in lowercase
${class}the firmware hardware class
${version}the firmware version number
o The resulting URL must end in .opg or .xml (an optional ?query-string is permitted). If it doesn’t, then it is skipped and 
the next URL is tried.
o In secure mode, the URL must use the https scheme or it is skipped.
o Otherwise the available schemes are: http, https, tftp, ftp, ftps
o The curl program is used to download the URL.
o In secure mode, the server’s certificate must validate against the \
ca-bundle.crt. The (required) client.pem file is 
provided to authenticate the client to the server. Please see the curl documentation for the format of these files.
• The URL is downloaded. For .opg files its header is checked to see if it is compatible with th\
e current appliance. For .xml 
files, a parse check is made. If the check fails, the downloaded fil\
e is abandoned and the next URL is tried.
• The file is imported into the current configuration.
• The system checks to see if a hostname has been set in the config. If \
not, it is set to ${model}-${mac}.
Chapter 15: Advanced Configuration  
						

							249
Chapter 15: Advanced Configuration
• The system checks to see if it is still in an unconfigured state. If i\
t is, then the network interface mode is set to DHCP. This 
effectively forces the system into a configured state, preventing a fu\
ture reboot loop.
• The system reboots
Note: If all the URLs were skipped or failed, the system will wait for 30 sec\
onds before retrying again. It will retry all the URLs 
up to 10 times. After the 10th retry, the system reboots. If the system has been manually configured in th\
e meantime, the 
retries stop and ZTP is disabled.
Note: If no option 43 is received over DHCP, no URLs are downloaded and no reboots occur: the system must be manual\
ly 
configured. Once configured (manually or by ZTP), the appliance wi\
ll no longer request option 43 from the DHCP server, and it 
will ignore any option 43 configuration URLs presented to it.
15.14.5 Setup a USB key for authenticated restore
The ZTP feature has a secure mode that requires a USB flash drive to b\
e present in the appliance when it boots unconfigured.
This section explains how to set up the USB key and configure an HTTPS server to serve the .opg file you want to use for 
configuration.
We use openssl to generate the certificates, the lighttpd web server an\
d isc-dhcp-server on Ubuntu 14.10 to demonstrate.
A. Generate certificates
First, let’s generate a CA certificate so we can sign the client an\
d server CSRs with it later. We’ve called it DavesCA but you 
can choose your own name. (In a real, enterprise deployment, the enterp\
rise’s secure CA process would be used instead of 
the openssl ca commands below). 
cp /etc/ssl/openssl.cnf . 
mkdir -p demoCA/newcerts 
echo 00 > demoCA/serial 
echo 00 > demoCA/crlnumber 
touch demoCA/index.txt 
openssl genrsa -out ca.key 8192 
openssl req -new -x509 -days 3650 -key ca.key -out demoCA/cacert.pem -su\
bj /CN=DavesCA cp demoCA/cacert.pem  
ca-bundle.crt
Now generate the server certificate. Make sure the hostname or IP addr\
ess used is what you will use in the URL later (Here it 
is demo.example.com)
openssl genrsa -out server.key 4096  
openssl req -new -key server.key -out server.csr -subj /CN=demo.example.com  
openssl ca -days 365 -in server.csr -out server.crt -keyfile ca.key -policy policy_anything -batch -notext
And the client certificate. The name ExampleClient should be chosen to identify the USB flash drive.
openssl genrsa -out client.key 4096  
openssl req -new -key client.key -out client.csr -subj /CN=ExampleClient  
openssl ca -days 365 -in client.csr -out client.crt -keyfile ca.key -p\
olicy policy_anything -batch -notext cat client.key client.crt 
> client.pem  
						

							250
Chapter 15: Advanced Configuration
B. Create the secure USB key
1. Format a USB flash drive as a single FAT32 volume.
2. Move the client.pem and ca-bundle.crt files onto the flash drive’s root directory.
 Configure lighttpd
 This is an example web server on Ubuntu 14.10. We will be putting the protected demo.opg file into /var/www/opg/.
 Due to a limitation in lighttpd, SSL connections to the server have to be either rejected or accepted befo\
re the URL is 
known. There is no syntax to test the certificate subject name in ligh\
ttpd. There should be in other web servers.
 As root, edit /etc/lighttpd/conf-available/99-opg.conf and add this to turn on SSL client authenticatoin:
$HTTP[“scheme”] == “https” { 
  ssl.ca-file = “/etc/ssl/certs/DavesCA.pem” 
  ssl.verifyclient.activate = “enable” 
  ssl.verifyclient.enforce = “enable” 
  ssl.verifyclient.username = “SSL_CLIENT_S_DN_CN”  
}  
$HTTP[“url”] =~ “^/opg/” { 
     $HTTP[“scheme”] != “https” { 
      url.access-deny = ( “” ) 
     } 
}
Now run these commands to enable SSL and copy the certificates into the right directories:
mkdir /var/www/opg  
cp demoCA/cacert.pem /usr/local/share/ca-certificates/DavesCA.crt  
update-ca-certificates  
(umask 77; cat server.key server.crt > /etc/lighttpd/server.pem)  
lighttpd-enable-mod ssl opg  
/etc/init.d/lighttpd force-reload
C. Obtain the .opg file to serve
1. Configure the appliance manually until it is how you want it to be.
2. Visit its System:Configuration Backup screen.
3. Click Save Backup.
4. Save, rename and copy the resulting .opg file to the web server directory /var/www/opg/demo.opg.
 Testing:
• Try downloading the URL https://demo.example.com/opg/demo.opg from a web \
browser; the file should be protected.
• Try fetching the URL metadata (i.e. HEAD) using curl with the client.pem:
curl -I -E client.pem https://demo.example.com/opg/demo.opg HTTP/1.1 200\
 OK ...