Tripp Lite 0 Idades Manual

							211
Chapter 15: Advanced Configuration
Console Servers run the embedded Linux operating system. So Administrato\
r class users can configure the Console Server and 
monitor and manage attached serial console and host devices from the com\
mand line using Linux commands and the config 
utility (as described in Chapter 14). 
The Linux kernel in the Console Server also supports GNU bash shell scri\
pt enabling the Administrator to run custom scripts. 
This chapter presents a number of useful scripts and scripting tools inc\
luding 
• delete-node which is a general script for deleting users, groups, hosts,\
 UPS's etc
• ping-detect which will run specified commands when a specific host s\
tops responding to ping requests
This chapter then details how to perform advanced and custom management \
tasks using Linux commands and the open 
source tools embedded in the Console Server:
• portmanager serial port management
• raw data access to the ports and modems 
• iptables modifications and updating IP filtering rules 
• retrieving status information using SNMP and modifying SNMP with net-snmpd
• public key authenticated SSH communications
• SSL, configuring HTTPS and issuing certificates
• using  pmpower for NUT and PowerMan power device management
• using IPMItools 
• sms server tools
• disable multicasting
15.1   Custom Scripting
The Console Server supports GNU bash shell commands (refer Appendix A)\
 enabling the Administrator to run custom scripts. 
15.1.1   Custom script to run when booting 
The /etc/config/rc.local script runs whenever the system boots. By default this script file is\
 empty. You can add any commands 
to this file if you want them to be run at boot time e.g. if you wante\
d to display hello world: 
#!/bin/sh
echo "Hello World!" 
If this script has been copied from a Windows machine you may need to run the following command on the script b\
efore bash 
can run it successfully: 
# dos2unix /etc/config/rc.local 
Another scenario would be to call another custom script from the /etc/config/rc.local file, ensuring that your custom script will 
run whenever the system is booted.   
						

							212
Chapter 15: Advanced Configuration
15.1.2  Running custom scripts when alerts are triggered
Whenever an alert gets triggered, specific scripts get called. These s\
cripts all reside in /etc/scripts/. Below is a list of the default 
scripts that get run for each applicable alert:
• For a connection alert (when a user connects or disconnects from a port \
or network host):  
/etc/scripts/portmanager-user-alert (for port connections) or /etc/scripts/sdt-user-alert (for host connections)
• For a signal alert (when a signal on a port changes state): /etc/scripts/portmanager-signal-alert
• For a pattern match alert (when a specific regular expression is found\
 in the serial ports character stream):  
/etc/scripts/portmanager-pattern-alert
• For a UPS status alert (when the UPS power status changes between on lin\
e, on battery, and low battery):  
/etc/scripts/ups-status-alert
• For a environmental, power and alarm sensor alerts(temperature, humidity\
, power load and battery charge alerts):  
/etc/scripts/environmental-alert
• For an interface failover alert: /etc/scripts/interface-failover-alert
All of these scripts do a check to see whether you have created a custom\
 script to run instead. The code that does this check 
is shown below (an extract from the file /etc/scripts/portmanager-pattern-alert):
# If there's a user-configured script, run it instead                           
scripts[0]="/etc/config/scripts/pattern-alert.${ALERT_PORTNAME}"                
scripts[1]="/etc/config/scripts/portmanager-pattern-alert"                      
for (( i=0 ; i < ${#scripts[@]} ; i++ )); do                        \
            
        if [ -f "${scripts[$i]}" ]; then                                \
        
                exec /bin/sh "${scripts[$i]}"                           \
        
        fi                                                            \
          
done
This code shows that there are two alternative scripts that can be run i\
nstead of the default one. This code first checks 
whether a file "/etc/config/scripts/pattern-alert.${ALERT_PORTNAME}" exists. The variable ${ALERT_PORTNAME} must be 
replaced with "port01" or "port13" or whichever port the alert should ru\
n for. If this file cannot be found, the script checks 
whether the file "/etc/config/scripts/portmanager-pattern-alert" exists. If either of these files exists the script calls the exec 
command on the first file that it finds and runs that custom fil\
e/script instead.
As an example, you can copy the /etc/scripts/portmanager-pattern-alert script file to 
/etc/config/scripts/portmanager-pattern-alert:
# cd /
# mkdir /etc/config/scripts   (if the directory does not already exist)
# cp /etc/scripts/portmanager-pattern-alert /etc/config/scripts/portmanager-pattern-alert
The next step will be to edit the new script file. Firstly, open the file /etc/config/scripts/portmanager-pattern-alert using vi (or 
any other editor), and remove the lines that check for a custom script \
(the code from above) - this will prevent the new custom 
script from repeatedly calling itself. After these lines have been removed, edit the file, or add any addit\
ional scripting to the 
file.   
						

							213
Chapter 15: Advanced Configuration
15.1.3  Example script - Power cycling on pattern match
If for example we had an RPC (PDU) connected to port 1 on a Console Se\
rver and also have some telecommunications device 
connected to port 2 and which is powered by the RPC outlet 3. Now assume\
 the telecom device transmits a character stream 
"EMERGENCY" out on its serial console port every time that it encounters\
 some specific error, and the only way to fix this error 
is to power cycle the telecom device. 
The first step is to setup a pattern-match alert on port 2 to check fo\
r the pattern "EMERGENCY".
Next we need to create a custom script to deal with this alert: 
# cd /
# mkdir /etc/config/scripts   (if the directory does not already exist)
# cp /etc/scripts/portmanager-pattern-alert /etc/config/scripts/portmanager-pattern-alert
Note: Make sure to remove the if statement (which checks for a custom script) from the new script, in \
order to prevent an 
infinite loop.
The pmpower utility is used to send power commands to RPC device in order to power \
cycle our telecom device:
# pmpower -l port01 -o 3 cycle  (The RPC is on serial port 1. The telecom device is powered by RPC out\
let 3)
We can now append this command to our custom script. This will guarantee \
that our telecom device will be power cycled every 
time the console reads the "EMERGENCY" character stream on port 2. 
15.1.4  Example script - Multiple email notifications on each alert 
If you desire to send more than one email when an alert triggers, you ha\
ve to create a replacement script using the method 
described above and add the appropriate lines to your new script.
Currently, there is a script /etc/scripts/alert-email which gets run from within all the alert scripts (e.g. portmanager-user-alert or 
environmental-alert). The alert-email script is responsible for sending the email. The lin\
e which invokes the email script looks 
as follows:
/bin/sh /etc/scripts/alert-email $suffix &
If you wish to send another email to a single address or the same email \
to many recipients, edit the custom script 
appropriately. You can follow the examples in any of the seven alert scripts listed abov\
e. In particular let’s consider the 
portmanager-user-alert script. If you need to send the same alert email to more than one email\
 address, find the lines in the 
script responsible for invoking the alert-email script, then add the fol\
lowing lines below the existing lines:
export TOADDR="[email protected]"
/bin/sh /etc/scripts/alert-email $suffix &
These two lines assign a new email address to TOADDR and invoke the aler\
t-email script in the background.  
						

							214
Chapter 15: Advanced Configuration
15.1.5  Deleting configuration values from the CLI
The delete-node script is provided to help with deleting nodes from the command line. T\
he "delete-node" script takes one 
argument, the node name you want to delete (e.g. "config.users.user1" or "config.sdt.hosts.host1").
So delete-node is a general script for deleting any node you desire (users, groups, h\
osts, UPS's etc) from the command line. 
The script deletes the specified node and shuffles the remainder of \
the node values.
For example if we have five users configured and we use the script to\
 delete user 3, then user 4 will become user 3, and user 
5 will become user 4. 
This creates an obvious complication as this script does NOT check for a\
ny other dependencies that the node being deleted 
may have had. So you are responsible for making sure that any references\
 and dependencies connected to the deleted node 
are removed or corrected in the config.xml file. 
The script treats all nodes the same. The syntax to run the script is # \
./delete-node {node name} so to remove user 3:
# ./delete-node config.users.user3   
The delete-node script
#!/bin/bash
#User must provide the node to be removed. e.g. "config.users.user1"
# Usage: delete-node {full node path}
if [ $# != 1 ]
then
 echo "Wrong number of arguments"
 echo "Usage: delnode {full '.' delimited node path}"
 exit 2
fi
# test for spaces
TEMP=`echo "$1" | sed 's/.* .*/N/'`
if [ "$TEMP" = "N" ]
then 
  echo "Wrong input format"
 echo "Usage: delnode {full '.' delimited node path}"
 exit 2
fi
# testing if node exists
TEMP=`config -g config | grep "$1"`
if [ -z "$TEMP" ]
then
 echo "Node $1 not found"
 exit 0
fi
# LASTFIELD is the last field in the node path e.g. "user1"
# ROOTNODE is the upper level of the node e.g. "config.users"
# NUMBER is the integer value extracted from LASTFIELD e.g. "1"
# TOTALNODE is the node name for the total e.g. "config.users.total"
# TOTAL is the value of the total number of items before deleting e.g. "3"
# NEWTOTAL is the modified total i.e. TOTAL-1
# CHECKTOTAL checks if TOTAL is the actual total items in .xml
LASTFIELD=${1##*.}
ROOTNODE=${1%.*}
NUMBER=`echo $LASTFIELD | sed 's/^[a-zA-Z]*//g'`
TOTALNODE=`echo ${1%.*} | sed 's/\(.*\)/\1.total/'`  
						

							215
Chapter 15: Advanced Configuration
TOTAL=`config -g $TOTALNODE | sed 's/.* //'`
NEWTOTAL=$[ $TOTAL -1 ]
# Make backup copy of config file
cp /etc/config/config.xml /etc/config/config.bak
echo "backup of /etc/config/config.xml saved in /etc/config/confi\
g.bak"
if [ -z $NUMBER ] # test whether a singular node is being \
#deleted e.g. config.sdt.hosts
then
 
 echo "deleting $1"
 config -d "$1" 
 
 echo Done
 exit 0
elif [ $NUMBER = $TOTAL ] # Test if only one item exists
then
 echo "only one item exists"
 # Deleting node
 echo "Deleting $1"
 config -d "$1"
 # Modifying item total.
 config -s "$TOTALNODE=0"
 echo Done
 exit 0  
						

							216
Chapter 15: Advanced Configuration
elif [ $NUMBER -lt $TOTAL ] # more than one item exists
then
 # Modify the users list so user numbers are sequential
 # by shifting the users into the gap one at a time...
 echo "Deleting $1"
 LASTFIELDTEXT=`echo $LASTFIELD | sed 's/[0-9]//g'`
 CHECKTOTAL=`config -g $ROOTNODE.$LASTFIELDTEXT$TOTAL`
 if [ -z "$CHECKTOTAL" ]
 then
    echo "WARNING: "$TOTALNODE" greater than number of items"
 fi
 COUNTER=1
 while [ $COUNTER != $((TOTAL-NUMBER+1)) ]
 do
  
    config -g $ROOTNODE.$LASTFIELDTEXT$((NUMBER+COUNTER)) \
   | while read LINE
  do
   config -s \
      "`echo "$LINE" | sed -e "s/$LASTFIELDTEXT$((NUMBER+ \
   COUNTER))/$LASTFIELDTEXT$((NUMBER+COUNTER-1))/" \
   -e 's/ /=/'`"
  done
  let COUNTER++
 done 
 # deleting last user
 config -d $ROOTNODE.$LASTFIELDTEXT$TOTAL
 # Modifying item total.
 config -s "$TOTALNODE=$NEWTOTAL"
 echo Done
 exit 0
else
 echo "error: item being deleted has an index greater than total items. I\
ncrease the total count variable."
 exit 0
fi  
						

							217
Chapter 15: Advanced Configuration
15.1.6  Power cycle any device upon a ping request failure
The ping-detect script is designed to run specified commands when a monitored host sto\
ps responding to ping requests. 
The first parameter taken by the ping-detect script is the hostname/ IP address of the device to ping. Any other par\
ameters are 
then regarded as a command to run whenever the ping to the host fails. ping-detect can run any number of commands. 
Below is an example using ping-detect to power cycle an RPC (PDU) outlet whenever a specific host fails t\
o respond to a ping 
request. The ping-detect is run from /etc/config/rc.local to make sure that the monitoring starts whenever the system boots. 
So if we assume we have a serially controlled RPC connected to port01 on\
 a Console Server and have a router powered by 
outlet 3 on the RPC (and the router has an internal IP address of 192.1\
68.22.2). The following instructions will show you 
how to continuously ping the router and when the router fails to respond\
 to a series of pings, the Console Server will send a 
command to RPC outlet 3 to power cycle the router, and write the current date/time to a file: 
• Copy the ping-detect script to /etc/config/scripts/ on the Console Server
• Open /etc/config/rc.local using vi
• Add the following line to rc.local:
/etc/config/scripts/ping-detect 192.168.22.2 /bin/bash -c "pmpower -l \
port01 -o 3 cycle && date" > /tmp/output.log & 
The above command will cause the ping-detect script to continuously ping\
 the host at 192.168.22.2 which is the router. If the 
router crashes it will no longer respond to ping requests. If this happe\
ns, the two commands pmpower and date will run. The 
output from these commands is sent to the file /tmp/output.log so that we have some kind of record. The ping-detect is also 
run in the background using the "&". 
Remember the rc.local script is only run by default when the system boots. You can manually run the rc.local script or the 
ping-detect script if desired.
The ping-detect script 
The above is just one example of using the ping-detect script. The idea of the script is to run any number of commands when 
a specific host stops responding to ping requests. Here are details of\
 the ping-detect script itself: 
#!/bin/sh
# Usage: ping-detect HOST [COMMANDS...]
# This script takes 2 types of arguments: hostname/IPaddress to ping, an\
d the commands to 
#  run if the ping fails 5 times in a row. This script can only take one host/IPaddress per 
# instance. Multiple independent commands can be sent to the script. The\
 commands will be
# run one after the other.
#
# PINGREP is the entire reply from the ping command
# LOSS is the percentage loss from the ping command
# $1 must be the hostname/IPaddress of device to ping
# $2... must be the commands to run when the pings fail.
COUNTER=0
TARGET="$1"
shift
# loop indefinitely:
while true
do
 # ping the device 10 times
 PINGREP=`ping -c 10 -i 1 "$TARGET" `
 #get the packet loss percentage
 LOSS=`echo "$PINGREP" | grep "%" | sed -e 's/.* \([0-9]*\)% .*/\1/'`
 if [ "$LOSS" -eq "100" ]
 then
    COUNTER=`expr $COUNTER + 1`
 else 
  COUNTER=0
   sleep 30s
 fi  
						

							218
Chapter 15: Advanced Configuration
 if [ "$COUNTER" -eq 5 ]
 then
   COUNTER=0
  "$@" 
   sleep 2s
 fi
done
15.1.7  Running custom scripts when a configurator is invoked 
A configurator is responsible for reading the values in /etc/config/config.xml and making the appropriate changes live. Some 
changes made by the configurators are part of the Linux configuratio\
n itself such as user passwords or ipconfig. 
Currently there are nineteen configurators each one responsible for a \
specific group of config e.g. the "users" configurator 
makes the user configurations in the config.xml file live. To see all the available configurators type the following from a 
command line prompt: 
# config 
When a change is made using the Management Console web GUI the appropria\
te configurator is automatically run. This 
can be problematic as if another user/administrator makes a change using\
 the Management Console the configurator could 
possibly overwrite any custom CLI/linux configurations you may have se\
t. 
The solution is to create a custom script that runs after each configu\
rator has run. So after each configurator runs it will check 
whether that appropriate custom script exists. You can then add any commands to the custom script and they will be invoked 
after the configurator runs. 
The custom scripts must be in the correct location:
/etc/config/scripts/config-post-
To create an alerts custom script:
# cd /etc/config/scripts
# touch config-post-alerts
# vi config-post-alerts 
This script could be used to recover a specific backup config or ove\
rwrite a config or make copies of config files etc.
15.1.8  Backing-up the configuration and restoring using a local USB stick
The /etc/scripts/backup-usb script been written to save and load custom configuration using a USB\
 flash disk. Before saving 
configuration locally, you must prepare the USB storage device for use. To do this, disconnect all USB storage devices except 
for the storage device you wish to use. 
Usage: /etc/scripts/backup-usb COMMAND [FILE] 
COMMAND:
check-magic -- check volume label
set-magic -- set volume label
save [FILE] -- save configuration to USB
delete [FILE] -- delete a configuration tarbal from USB
list -- list available config backups on USB
load [FILE] -- load a specific config from USB
load-default -- load the default configuration
set-default [FILE] -- set which file becomes the default 
The first thing to do is to check if the USB disk has a label:
 # /etc/scripts/backup-usb check-magic 
If this command returns "Magic volume not found", then run the following\
 command: 
# /etc/scripts/backup-usb set-magic 
To save the configuration: 
# /etc/scripts/backup-usb save config-20May   
						

							219
Chapter 15: Advanced Configuration
To check if the backup was saved correctly: 
# /etc/scripts/backup-usb list
If this command does not display "* config-20May" then there was an error saving the configuration. 
The set-default command takes an input file as an argument and renames\
 it to "default.opg". This default configuration 
remains stored on the USB disk. The next time you want to load the defau\
lt config, it will be sourced from the new default.opg 
file. To set a config file as the default:
# /etc/scripts/backup-usb set-default config-20May 
To load this default:
 # /etc/scripts/backup-usb load-default 
To load any other config file:
# /etc/scripts/backup-usb load {filename} 
The /etc/scripts/backup-usb script can be executed directly with various COMMANDS or called from other custom scripts you 
may create. However it is recommended that you do not customize the /etc/scripts/backup-usb script itself at all.
15.1.9  Backing-up the configuration off-box
If you do not have a USB on your Console Server you can back up the confi\
guration to an off-box file. Before backing up you 
need to arrange a way to transfer the backup off-box.  This could be via an NFS share, a Samba (Windows) share to USB 
storage or copied off-box via the network.  If backing up directly to off-box storage, make sure it is mounted.
/tmp is not a good location for the backup except as a temporary location bef\
ore transferring it off-box.  The /tmp directory will 
not survive a reboot.  The /etc/config directory is not a good place either, as it will not survive a restore.
Backup and restore should be done by the root user to ensure correct fi\
le permissions are set. The config command is used to 
create a backup tarball:
config -e 
The tarball will be saved to the indicated location. It will contain the\
 contents of the /etc/config/ directory in an uncompressed 
and unencrypted form.
Example nfs storage:
# mount -t nfs 192.168.0.2:/backups /mnt # config -e /mnt/b095.confi\
g # umount/mnt/
Example transfer off-box via scp:
# config -e /tmp/b095.config
# scp /tmp/b095.config 192.168.0.2:/backups
The config command is also used to restore a backup:
config -i 
This will extract the contents of the previously created backup to /tmp, and then synchronize the /etc/config directory with the 
copy in /tmp.
One problem that can crop up here is that there is not enough room in /tmp to extract files to. The following command will 
temporarily increase the size of /tmp:
  mount -t tmpfs -o remount,size=2048k tmpfs /var
If restoring to either a new unit or one that has been factory defaulted\
, it is important to make sure that the process 
generating SSH keys is either stopped or completed before restoring configuration.\
  If this is not done, then a mix of old and 
new keys may be put in place. 
As SSH uses these keys to avoid man-in-the-middle attacks, logging in may be\
 disrupted.  
						

							220
Chapter 15: Advanced Configuration
15.2 Advanced Portmanager
The portmanger program manages the Console Server serial ports. It routes network conn\
ection to serial ports, checks 
permissions, and monitors and logs all the data flowing to/from the po\
rts. 
15.2.1   Portmanager commands
pmshell
The pmshell command acts similar to the standard tip or cu commands, but all serial port access is directed via the 
portmanager.
Example: To connect to port 8 via the portmanager:
# pmshell -l port08
pmshell Commands:
Once connected, the pmshell command supports a subset of the '~' escape \
commands that tip/cu support. For SSH you 
must prefix the escape with an additional ‘~’ command (i.e. use\
 the ‘~~’ escape) 
Send Break: Typing the character sequence '~b' will generate a BREAK on the serial po\
rt (if you're doing this over ssh, 
you'll need to type "~~b")
History: Typing the character sequence '~h' will generate a history on the serial \
port.
Quit pmshell: Typing the character sequence '~.' will exit from pmshell.
Set RTS to 1 run the command:  pmshell --rts=1
Show all signals: # pmshell –signals 
DSR=1 DTR=1 CTS=1 RTS=1 DCD=0
Read a line of text from the serial port: # pmshell –getline
Note: For console servers running firmware v3.11.0 and above, pmshell contains a set of built-in key sequences to access 
the power menu, return to the serial port selection menu and more. Extra\
 controls (key sequences) can be added to the 
built-in set of key sequences and configured per serial port. All port\
s can function the same or you can selectively add control 
sequences to ports. The controls can differ from port to port for the sa\
me function. 
For example, you can configure pmshell so that when you are using serial port 2, pressing Ctrl+p can take you straight to the 
power menu for that port. 
The pmshell control commands are configured only via command line. 
A helper script will configure a control command on a range of serial \
ports to eliminate the task of entering the configuration 
command for each port. You will still need to use this script once per control function (see be\
low). There are six control 
functions. 
pmshell control functions and their built in key sequences:
 ~b - Generate BREAK - send a break to the console
 ~h - View history - see the traffic logs for the port - must have port l\
ogging enabled
 ~p - Power menu - open the power menu for the port - port must be configured\
 for an RPC
 ~m - Connect to port menu - go back to the serial port selection menu
 ~. - Exit pmshell - exit pmshell completely
  ~? - Show help message - shows the help message
Per Port Control Command Config Parameters:
 config.ports.portX.ctrlcode.break   - Generate BREAK
 config.ports.portX.ctrlcode.portlog - View History
 config.ports.portX.ctrlcode.power  - Power menu
 config.ports.portX.ctrlcode.chooser - Connect to port menu
 config.ports.portX.ctrlcode.quit   - Exit pmshell
 config.ports.portX.ctrlcode.help  - Show help message