Filter
Top Products
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