Opengear ACM5000, Руководство пользователя

Страница: 301 / 335

Console Server & Router User Manual
301
15.11 Custom Development Kit (CDK)
As detailed in this manual customers can copy scripts, binaries and configuration files directly to the console server .
Opengear also freely provides a development kit which 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 e.g. 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 Opengear 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 Opengear CDK for the particular appliance you are working with from ftp://ftp.opengear.com/cdk and find further
information online at http://www.opengear.com/faq284.html
Note The CDK is free, however Opengear does not provide free technical support for systems modified using the CDK
and any changes are the responsibility of the user.
15.12 Scripts for Managing Slaves
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. However the
Master does not provide a fully consolidated view e.g. 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, as local logs only buffer 8K of data and don't persist
between reboots.
This script would e.g. parse each port log file line by line, 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. It's also possible to run this as a CGI 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
http://www.yolinux.com/TUTORIALS/LinuxTutorialCgiShellScript.html
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