BAC Support Tools and Advanced Concepts

This chapter contains information on, and explains the use of, tools that help you maintain Broadband Access Center (BAC) as well as speed and improve the installation, deployment, and use of this product.

For a list of other tools that are supported in this release, see BAC Tools, page 9-4.

Note This section contains examples of tool use. In many cases, the tool filenames include a path specified as BPR_HOME. This indicates the default installation directory location.

Using the deviceExport.sh Tool

You can obtain information about devices by using the device export tool, which retrieves device information from the BAC system and exports it to a flat file. This file can, in turn, be used to import data into an external application.

The deviceExport.sh tool, located at the BPR_HOME/rdu/bin directory, exports device information from the backup snapshot of the RDU database to a Comma Separated Value (CSV) format file.

Note You can use the device export tool only on the backup database; the tool does not export device information from the live RDU database.

You must provide a list of device properties that are to be exported in the control file. The control file is an XML file which defines the fields required for export. The tool provides an option to generate a sample control file, which you can edit to configure which properties to export. You can generate the list of properties predefined in BAC and available for export by running the deviceExport.sh -samplectrl command. (For sample control output, see Example 18-2.)

The CSV format is used widely to exchange data between applications. Keep the following rules in mind about a CSV format file:

•

If a field contains white space, a comma, or a line separator, it is enclosed by double quotes ("). If a field contains double-quotes, repeat the character twice to escape it; for instance, "file name" becomes ""file name"".

•

If a field is a list, it converts into a formatted string with each item separated by comma; for instance, a node list outputs as "node1, node2, node3".

•

If a field is a map, it is converted into a long string. The key and data is separated by a comma; for instance, a map output looks like: "(key1, data1)(key2, data2)(key3, data3)".

•

If the field value is null or does not exist, the output is an empty string followed by a comma.

74:7b:7b:f0:e7:80,admin,true,2,"node1,node2,node3","(prop1,value1)(prop2,value2)",,,

Syntax Description

# ./deviceExport.sh [-help] [-samplectrl] controlfile backupdir outputdir

•

controlfile—Identifies the path to the control file, which defines the fields required for export.

•

backupdir—Identifies the path to the directory, which contains backed-up database files that are to be used as data source. (To back up your database, use the backupDb.sh tool; see Backup and Recovery.)

•

outputdir—Identifies the target location for the output files. If the directory does not exist, a new directory is created.

•

samplectrl—Generates the sample control file, which contains the supported properties and device types, in the current directory. The control file is an XML file that contains the supported properties and device types. You can remove unwanted properties or choose to export only certain types of devices by editing the XML file. See Example 18-2 for output of a sample control file.

# ./deviceExport.sh -samplectrl

<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE CONTROLFILE SYSTEM "device-export-control.dtd">

<!--SAMPLE CONTROL FILE-->

<CONTROLFILE>

    <!--Start of field list(REQUIRED)

        The field list specifies the device properties that will be exported.

        All supported standard fields are listed below. Remove unwanted

        fields by deleting the line that contains the field name. Customer

        defined properties are not listed but can be added to the list.

-->

    <FIELDLIST>

        <FIELD>GenericObjectKeys.OID_REVISION_NUMBER</FIELD>

        <FIELD>DeviceDetailsKeys.DEVICE_TYPE</FIELD>

        <FIELD>DeviceDetailsKeys.OWNER_ID</FIELD>

        <FIELD>DeviceDetailsKeys.NODE_DETAILS</FIELD>

        <FIELD>DeviceDetailsKeys.DEVICE_ID</FIELD>

        <FIELD>DeviceDetailsKeys.FQDN</FIELD>

        <FIELD>DeviceDetailsKeys.HOST</FIELD>

        <FIELD>DeviceDetailsKeys.DOMAIN</FIELD>

        <FIELD>DeviceDetailsKeys.IS_IN_REQUIRED_PROV_GROUP</FIELD>

        <FIELD>DeviceDetailsKeys.IS_REGISTERED</FIELD>

        <FIELD>DeviceDetailsKeys.IS_PROVISIONED</FIELD>

        <FIELD>DeviceDetailsKeys.PROV_GROUP</FIELD>

        <FIELD>DeviceDetailsKeys.CLASS_OF_SERVICE</FIELD>

        <FIELD>DeviceDetailsKeys.CLASS_OF_SERVICE_SELECTED</FIELD>

        <FIELD>DeviceDetailsKeys.PROPERTIES</FIELD>

        <FIELD>DeviceDetailsKeys.PROPERTIES_DETECTED</FIELD>

        <FIELD>DeviceDetailsKeys.PROPERTIES_SELECTED</FIELD>

        <FIELD>DeviceDetailsKeys.REASON</FIELD>

        <FIELD>DeviceDetailsKeys.EXPLANATION</FIELD>

        <FIELD>DeviceDetailsKeys.CONFIGURATION_REVISION</FIELD>

        <FIELD>DeviceDetailsKeys.FIRMWARE_CONFIGURATION_REVISION</FIELD>

        <FIELD>DeviceDetailsKeys.REPORTED_IP_ADDRESS</FIELD>

        <FIELD>DeviceDetailsKeys.SOURCE_IP_ADDRESS</FIELD>

        <FIELD>DeviceDetailsKeys.ROUTABLE_IP_ADDRESS</FIELD>

        <FIELD>DeviceDetailsKeys.DEVICE_FAULTS</FIELD>

        <FIELD>DeviceDetailsKeys.PENDING_ON_CONNECT_OPERATION_IDS</FIELD>

        <FIELD>DeviceDetailsKeys.PASSWORD_IS_PROTECTED</FIELD>

        <FIELD>IPDeviceKeys.HOME_PROV_GROUP</FIELD>

        <FIELD>IPDeviceKeys.CPE_PASSWORD</FIELD>

        <FIELD>IPDeviceKeys.CONNECTION_REQUEST_USERNAME</FIELD>

        <FIELD>IPDeviceKeys.CONNECTION_REQUEST_PASSWORD</FIELD>

    </FIELDLIST>

    <!--End of field list-->

</CONTROLFILE>

Note The DOCTYPE CONTROLFILE SYSTEM references a .dtd file, device-export-control.dtd, which is used for XML validation. The file is installed in the BPR_HOME/rdu/bin directory.

# ./deviceExport.sh control.xml rdu-backup-20061227-145538 /data/rduexport

Starting exporting devices...

Using backup database in /tmp/rdu-backup-20061227-145538

Device export finished in 28m11s.

Note

The exported file is generated in the specified directory; in the above example, in the /data/rduexport directory. You do not need to specify the full path to the directory.

Following a successful export from the BAC backup database, the Device Export tool creates a device file, which contains the list of device records that are successfully exported from the BAC backup database. The filename is bac-device-details-yyyyMMdd-HHmmss.csv:

Using the disk_monitor.sh Tool

Monitoring available disk space is an important system administration task. You can use a number of custom written scripts or commercially available tools to do so. The disk_monitor.sh tool is a sample tool to accomplish this.

The disk_monitor.sh tool, located in the BPR_HOME/rdu/sample/tools directory, sets threshold values for one or more file systems. When these thresholds are surpassed, an alert is generated through the Solaris syslog facility, at 60-second intervals, until additional disk space is available.

Note Cisco recommends that, at a minimum, you use the disk_monitor.sh script to monitor the BPR_DATA and BPR_DBLOG directories.

Syntax Description

# ./disk_monitor.sh file system-directory x

•

file system-directory—Identifies any directory in a file system to monitor.

•

x—Identifies the percentage threshold applied to the specified file system.

Assume that you want to be notified when a file system (/var/CSCObpr, for example) with database logs reaches 80% of its capacity. Enter the command:

# ./disk_monitor.sh /var/CSCObac 80&

When the database logs disk space reaches 80% capacity, an alert is sent to the syslog file:

Dec 7 8:16:03 perf-u80-1 BPR: [ID 702911 local6.warning] File system /var/bpr usage is 81% 
(threshold is 80%)

Note Make sure to configure Solaris to this on start-up, so that it is started after system reboot automatically.

Table Of Contents