Black Box 1102 Manuale Utente

1101 and 1102 Secure Device Servers 

                                                724-746-5500   |   blackbox.com                   

 

    

160 

        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 

"$$

##$#

 

')#''



%&

 
As detailed in this manual, customers can copy scripts, binaries, and configuration files directly to the console server.  
 
Black Box also freely provides a development kit that allows changes to be made to the software in console server firmware image. The customer 
can use the CDK to: 
 
generate a firmware image without certain programs, such as telnet, which may be banned by company policy. 
 
generate an image with new programs, such as custom Nagios plug-in binaries or company specific binary utilities. 
 
generate an image with custom defaults, for example, it may be required that the console server be configured to have a specific default serial port 
profile which is reverted to even in event of a factory reset. 
place configuration files into the firmware image, which cannot then be modified e.g. # /bin/config –-set= tools update the configuration files in 
/etc/config which are read/write, whereas the files in /etc are read only and cannot be modified. 
 
The CDK essentially provides a snapshot of the Black Box build process (taken after the programs have been compiled and copied to a temporary 
directory romfs) just before the compressed file systems are generated. You can obtain a copy of the Black Box CDK for the particular appliance you 
are working with from Black Box 
 

NOTE: The CDK is free. 
 

')#'(





 
When the console servers are cascaded the Master is in control of the serial 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. The Master does not provide a fully consolidated view, for example, 
Status: Active Users only displays those users active on the Master’s ports and 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, because local logs only buffer 8K of data and don’t persist between reboots. 
 
This script would, for example, parse each port log file line by linee. Each time it sees  'LOGIN: username', it adds 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. 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 
There’s a useful tutorial on creating a bash script CGI at 

"$$#! #$  $ #

 

 
Similarly, the Master does maintain 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 connected  
- Note the end of the Slaves' names will be truncated, so the first 5 characters must be unique 
 
Alternatively, you can write a custom CGI script as described above. The currently connected Slaves can be determined by running: ls 
/var/run/cascade and the configured slaves can be displayed by running: config -g config.cascade.slaves