| Netra CT Server System Administration Guide |    
|
| Netra CT Server System Administration Guide |
|
| C H A P T E R 2 |
|
Configuring Your System |
This chapter assumes you have already installed the Solaris OS and the required patches on your Netra CT system.
You configure the Netra CT system primarily through the alarm card command-line interface (CLI). The alarm card CLI enables system-level configuration, administration, and management that includes the CPU nodes, I/O boards, the alarm card, power supplies, and fan trays. The alarm card CLI interface can be used both locally and remotely.
You configure the alarm card first, then the CPU boards, then the system-wide applications.
This chapter includes the following sections:
When you initially access the alarm card, you must do so over serial port COM1 (console), using an ASCII terminal or the Tip program.
When you first access the alarm card, log in with the default user account of netract and the password suncli1. This account is set to full authorization (permissions). This account can not be deleted; however, you should change the password on this account for security purposes, before your Netra CT server is operational.
The next sections provide information on configuring the alarm card serial and Ethernet ports, and setting up user accounts and passwords using the alarm card command-line interface. For more information on using the alarm card command-line interface, refer to Chapter 3.
After you configure the serial and Ethernet ports, you can access and configure the alarm card over:
To use the console on a rear-access Netra CT server, connect a cable to the rear serial port on the alarm card (the front ports are disabled on a rear-access system).
The alarm card has two serial ports, COM1 and COM2. COM1 is configured for the console; you can not change this port. You can configure COM2 using the following CLI commands:
You must be logged in to the alarm card with a user account that has full permissions.
When you specify the port number (port_num), use 2 to reference serial port COM2.
|
Set the mode of the specified serial port to tty or none. The default for COM2 is none, that is, no services are available on this port.
Valid values for the baud rate are 1200, 4800, 9600, 19200, 38400, and 56000. The default is 9600.
Valid values for the parity bit are none, odd, or even. The default is odd.
Valid values for the stop bit are 1 or 2. The default is 1.
6. Set the serial data bit number:
Valid values for the number of data bits are 7 or 8. The default is 8.
7. Set the serial hardware handshake:
Valid values for the hardware handshake are true or false. The default is false.
The alarm card has two Ethernet ports, ENET1 and ENET2. You configure these ports using the following CLI commands:
You must be logged in to the alarm card with a user account that has full permissions.
When you specify the port number (port_num), use 1 or 2, depending on which port you are referencing.
Any one of the Ethernet ports can be configured for failover to the other port. Refer to "Set the IP mode," below, for instructions.
You must reset the alarm card for any changes to take effect.
|
Choose the IP mode according to the services available in the network (rarp or config) or to configure the port for failover (standby). The default for ENET1 is rarp; the default for ENET2 is none, that is, no services are available on this port. You must reset the alarm card for the changes to take effect.
Any one of the Ethernet ports can be configured for failover. To do this, set the IP mode to standby on one port, and set the IP mode to rarp or config on the other port. If the port configured for rarp or config fails, the network traffic will be switched over to the port configured for standby. For example:
In this example, ENET2 is set to standby. If ENET1 fails, all network traffic is switched over to ENET2.
The default is 0.0.0.0. This command is only used if the ipmode is set to config. You must reset the alarm card for the changes to take effect.
The default is 0.0.0.0. This command is only used if the ipmode is set to config. You must reset the alarm card for the changes to take effect.
Set the IP gateway of Ethernet port 1. The default is 0.0.0.0. You must reset the alarm card for the changes to take effect.
User accounts are set up using the alarm card command-line interface. The default user account is netract and the password is suncli1. This account is set to full authorization (permissions). This account can not be deleted; however, you should change the password on this account for security purposes, before your Netra CT server is operational.
The alarm card supports 16 accounts with passwords.
|
3. Add a password for that user:
By default, new accounts are created with read-only permission. Permission levels can be changed using the userperm command; refer to CLI Commands for more information about permissions and the userperm command.
A different type of alarm card user account is used solely with the Managed Object Hierarchy (MOH) Remote Method Invocation (RMI) interface. Refer to MOH Configuration and RMI for more information.
The username field has a maximum length of 16 characters; it must contain at least one lowercase alphabetic character, and the first character must be alphabetic.
Valid characters for username include:
Passwords have the following restrictions:
A field-replaceable unit (FRU) is a module or component that can typically be replaced in its entirety as part of a field service repair operation.
The Netra CT system FRUs include:
All FRUs contain FRU ID (identification) information that includes FRU manufacturing and configuration data. This information can be displayed through the alarm card CLI (see TABLE 2-3).
In addition, you enter certain FRU ID information, through the alarm card CLI, that is stored in the midplane. (Note that you can also enter FRU ID information through the MOH application; refer to the Netra CT Server Developer's Guide for instructions.) FRU ID information includes:
Some of this information is used by the MOH application to audit board insertions and prevent misconfigurations, and to display information; some is used by the MCNet interface.
The format of the information to be specified is:
FRU ID information can be displayed using the CLI showfru command; see Displaying Netra CT Server FRU ID Information for more information.
TABLE 2-1 shows the FRU ID information that can be specified with the CLI setfru command.
Changes to FRU fields through the CLI setfru command require you to completely power the system off and on for the changes to take effect. To avoid powering the system off and on several times, enter all necessary FRU ID information at once, then power the system off and on.
The next several sections describe the configurations you can set by entering FRU ID information.
Netra CT server base configurations of rear access with diskful or diskless access are set at the factory. Each of these base configurations supports any one of the functional configurations shown in TABLE 2-2.
There is no default functional configuration on the Netra CT server; you set the functional configuration using the alarm card CLI. The functional configuration information is used by the MOH application to audit board insertions and prevent misconfigurations. The functional configuration can be changed at any time if desired using the alarm card CLI.
|
2. Set the functional configuration for the Netra CT server:
Refer to TABLE 2-1 for allowable information for each variable. For example, if you want to set the functional configuration to hosted, enter the following:
3. Completely power off and on the system:
a. Press the system power button on the system status panel and release it to go through a graceful soft power-down; wait for the system power LED to go off.
b. Push the locking mechanism on the power supplies up (unlocked) to power down; wait for the green LEDs on the power supplies to go off; then push the locking mechanism on the power supplies down (locked) to power up.
Note: on the Netra CT 810 server, push the locking mechanism on both power supplies up and then down at the same time.
c. Press the system power button on the system status panel and release it to power on the server.
You can specify the type of board that is allowed in a given chassis slot using the alarm card CLI. The slot usage information is used by the MOH application to audit board insertions and prevent misconfigurations. You can also specify the boot device for the slot, that is, the path to the device the board in the slot will boot from. When the board is powered on, the FRU boot device information overwrites the entry in the OpenBoot PROM boot-device NVRAM configuration variable on that board. The chassis slot information can be changed at any time if desired using the alarm card CLI.
By default, slots are configured to accept any cPCI FRU unless you specifically set an allowable plug-in for a specific slot. The exceptions are for a Netra CT 810 server, the alarm card must be in slot 8 and the host CPU must be in slot 1; for a Netra CT 410 server, the alarm card must be in slot 1 and the host CPU must be in slot 3.
To set allowable plug-ins for a particular slot, you need the vendor name and the part number of the board. This FRU ID information can be displayed using the CLI showfru command; see Displaying Netra CT Server FRU ID Information for more information.
An exception is the rear transition card for the Netra CP2500 CPU board; to set the allowable plug-in for a Netra CP2500 CPU board rear transition card, you need its part number only.
|
2. Set the acceptable FRUs for the slot:
Refer to TABLE 2-1 for allowable information for each variable. For example, if you want to set chassis slot 5 to allow only a Sun Microsystems (vendor 003E) particular CPU board (part number 595-5769-03), enter the following:
3. Set the boot device for the slot:
Refer to TABLE 2-1 for allowable information for each variable. For example, if you want to set chassis slot 5 to boot from a device on the network, enter the following:
where boot_device_list is the alias(es) specifying the boot devices (limit is 25 bytes), for example, disk net.
4. Completely power off and on the system:
a. Press the system power button on the system status panel and release it to go through a graceful soft power-down; wait for the system power LED to go off.
b. Push the locking mechanism on the power supplies up (unlocked) to power down; wait for the green LEDs on the power supplies to go off; then push the locking mechanism on the power supplies down (locked) to power up.
Note: on the Netra CT 810 server, push the locking mechanism on both power supplies up and then down at the same time.
c. Press the system power button on the system status panel and release it to power on the server.
|
To clear any prior setting for a chassis slot, enter the following:
MCNet provides a communication channel over the cPCI midplane. It can be used to communicate between the alarm card, the host CPU board, and satellite CPU boards. It appears as any other generic Ethernet port in the Solaris OS. MCNet is configured by default on Solaris (host CPU and satellite CPUs) and on the alarm card. MCNet is used by the MOH and PMS applications.
The IP address of the MCNet interfaces on the CPU boards is formed as follows: The midplane FRU ID field MCNetIPSubnet contains the value IP_subnet_address.slot_number. The default IP subnet address is 0xc0a80d (192.168.13) and the default IP subnet mask is 0xffffff00 (255.255. 255.0). When you power on the Netra CT server, and if you have not made any changes for the MCNet interface in the midplane FRU ID, the IP address of a board installed in slot 2 will be configured to 192.168.13.2; if you then move that board to slot 4, the IP address for that board will be configured to 192.168.13.4.
The IP address of the MCNet interface on the alarm card is always the midplane FRU ID field MCNetIPSubnet value IP_subnet_address.8. This is the case for the alarm card in the Netra CT 810 server and in the Netra CT 410 server.
|
2. Set the FRU ID for the MCNet interface:
Refer to TABLE 2-1 for allowable information for each variable. You must set both the MCNet IP subnet address and the subnet mask in hexadecimal format. For example, to set the subnet address to 192.168.16 and the subnet mask to 255.255.255.0, enter the following:
hostname cli> setfru midplane 1 MCNetIPSubnet 0xc0a810 hostname cli> setfru midplane 1 MCNetIPSubnetMask 0xffffff00 |
3. Completely power off and on the system:
a. Press the system power button on the system status panel and release it to go through a graceful soft power-down; wait for the system power LED to go off.
b. Push the locking mechanism on the power supplies up (unlocked) to power down; wait for the green LEDs on the power supplies to go off; then push the locking mechanism on the power supplies down (locked) to power up.
Note: on the Netra CT 810 server, push the locking mechanism on both power supplies up and then down at the same time.
c. Press the system power button on the system status panel and release it to power on the server.
After you boot the Solaris OS, you can check to see that MCNet has been configured by using the ifconfig -a command. You should see output for the mcn0 interface similar to the following:
To test for actual communication, use the ping -s command. You should see output similar to the following:
After you configure the MCNet interface, you can check to see that it has been configured by using the CLI shownetwork command. You should see output similar to the following:
You can use the FRU fields Location, Cust_Data, and User_Label to enter any customer-specific information about your system. These are optional entries; by default, there is no information stored in these fields. Information entered in the Location field is displayed through the MOH application.
You might want to use the Location FRU field to enter specific, physical location information for your system. For example, you might enter the number on the chassis label, to indicate the location of the system.
|
2. Specify other FRU ID information for the Netra CT server:
Refer to TABLE 2-1 for allowable information for each variable. For example, if you want to set the location information to reflect a chassis label that reads 12345-10-20, enter the following:
3. Completely power off and on the system:
a. Press the system power button on the system status panel and release it to go through a graceful soft power-down; wait for the system power LED to go off.
b. Push the locking mechanism on the power supplies up (unlocked) to power down; wait for the green LEDs on the power supplies to go off; then push the locking mechanism on the power supplies down (locked) to power up.
Note: on the Netra CT 810 server, push the locking mechanism on both power supplies up and then down at the same time.
c. Press the system power button on the system status panel and release it to power on the server.
FRU ID information entered during the manufacturing process and through the alarm card CLI setfru command can be displayed using the showfru command.
TABLE 2-3 shows the FRU ID information that can be displayed with the CLI showfru command. Use the FRU field to specify the information you want.
|
Refer to TABLE 2-3 for allowable information for each variable. For example, if you want to display the part number FRU ID information for fan tray 1, enter the following:
Use the FRU target slot to display information for the alarm card, the CPU boards, and the I/O boards; the FRU slot instance can be 1, 2, 3, 4, 5, 6, 7, or 8 for a Netra CT 810 and 1, 2, 3, 4, or 5 for a Netra CT 410 (slots are numbered starting from the left). For example, to display part number FRU ID information for the alarm card in a Netra CT 810 server, enter the following:
The supported configuration is to run the same version of the Solaris OS on all CPU boards in a chassis. You should verify that you can log in to the CPU boards. Any Solaris configuration needed for your environment should be done, such as modifying OpenBoot PROM variables. Refer to the Solaris documentation, the OpenBoot PROM documentation, or to the specific CPU board documentation if you need additional information.
Although various combinations of cPCI boards, including the Netra CP2140, the Netra CP2160, the Netra CP2500, and cPCI I/O cards, are allowed in the Netra CT 810 and 410 servers, power capability limits the maximum number of CP2500 boards in either server to three. Refer to the Netra CT Server Upgrade Guide or to the Netra CT Server Service Manual for information on system power capability and configurations.
Current platform and CPU board information can be displayed with the uname and prtpicl Solaris commands, as shown in TABLE 2-4.
|
The CPU board in the host slot is either a Netra CP2140 or a Netra CP2500. |
|||
The alarm card must be present in the system to power on the host CPU board. Once the host CPU board is powered on, the alarm card and the host CPU board can be rebooted independently. The host CPU board can be rebooted while the alarm card is resetting; however, if you do this simultaneously, you also need to reboot any satellite boards so the host CPU board MOH agent can manage them using MCNet.
The Managed Object Hierarchy (MOH) is an application that runs on the alarm card, the host CPU, and satellite CPUs. It monitors the field-replaceable units (FRUs) in your system.
The MOH application requires the Solaris 9 OS, and additional Netra CT platform-specific Solaris patches that contain packages shown in TABLE 2-5.
|
Alarm card firmware package that includes the Netra CT management agent |
Download Solaris patch updates from the web site: http://www.sunsolve.sun.com. For current patch information, refer to the Netra CT Server Release Notes.
Install the patch updates using the patchadd command. After these packages are installed, they reside in the default installation directory, /opt/SUNWnetract/mgmt2.0/bin. To verify the packages are installed, use the pkginfo command:
The Netra High Availability Suite may be used to provide enhanced services for customer high-availability applications. It is required to use certain monitoring capabilities of the MOH application, such as monitoring nfs and tftp daemons. The Netra HA Suite is ordered and shipped separately from the Netra CT server.
Once the MOH application is running, MOH agents on the alarm card and on CPU boards interface with your Simple Network Management Protocol (SNMP) or Remote Method Invocation (RMI) application to discover network elements, monitor the system, and provide status messages.
Refer to the Netra CT Server Software Developer's Guide for information on writing applications to interface with the MOH application.
The MOH application is started automatically on the alarm card.
You must start the MOH application as root on the CPU boards using the ctmgx start command:
If you installed the Solaris patches in a directory other than the default directory, specify that path instead.
Options that can be specified with ctmgx start when you start the MOH application include:
By default, SNMP and RMI applications have read-write access to MOH agents on the alarm card and on CPU boards. The next sections describe how to configure MOH to control SNMP and RMI access on the alarm card and CPU boards.
By default, SNMP applications have read-write access to the Netra CT server MOH agents. If you want to control which applications communicate with the MOH agents, you must configure the alarm card and CPU board SNMP interfaces. This configuration provides additional security by controlling who has access to the agent.
The SNMP interface uses an SNMP access control list (ACL) to control:
An SNMP community is a group of IP addresses of devices supporting SNMP. It helps define where information is sent. The community name identifies the group. An SNMP device or agent may belong to more than one SNMP community. An SNMP device or agent will not respond to requests originating from IP addresses that do not belong to one of its communities.
On the alarm card, you enter ACL information using the CLI snmpconfig command. A limit of 20 communities can be specified. For each community, a limit of five IP addresses can be specified. The ACL information is stored in the alarm card flash memory.
|
2. Enter SNMP ACL information with the snmpconfig command:
where community is the name of a group that the MOH agent on the alarm card supports, and ip_addr is the IP address of a device supporting an SNMP management application. For example, to add read-only access (the default) for the community trees, to add read-write access for the community birds, and to add a trap for the community lakes, enter the following:
hostname cli> snmpconfig add access trees ip_addr ip_addr ip_addr hostname cli> snmpconfig add access birds readwrite ip_addr hostname cli> snmpconfig add trap lakes ip_addr |
You can use the snmpconfig command to show or delete existing ACL information. For example, to show the ACL access and trap information entered in Step 2 above, enter the following:
On CPU boards, ACL information is stored in a configuration file in the Solaris OS.
The format of this file is specified in the JDMK documentation. An ACL file template that is part of the JDMK package is installed by default in
/opt/SUNWjdmk/jdmk4.2/1.2/etc/conf/template.acl.
An example of a configuration file is:
acl = { { communities = trees access = read-only managers = oak, elm } { communities = birds access = read-write managers = robin } } trap = { { trap-community = lakes hosts = michigan, mead } } |
In this example, oak, elm, robin, michigan, and mead are hostnames. If this is the ACL file specified, when the MOH starts, a coldStart trap will be sent to michigan and mead. Management applications running on oak and elm can read (get) information from MOH, but they cannot write (set) information. Management applications running on robin can read (get) and write (set) information from MOH.
The ACL file can be stored anywhere on your system. When you start the MOH application and you want to use an ACL file you created, you specify the complete path to the file.
Refer to the JDMK documentation (http://www.sun.com/documentation) for more information on ACL file format.
|
2. Create a configuration file in the format of a JDMK ACL configuration file.
3. As root, start the MOH application.
If you installed the Solaris patches in a directory other than the default directory, specify that path instead.
The MOH application starts and reads the configuration file using one of these methods, in this order:
If the ACL cannot be determined after these steps, SNMP applications will have read-write access and MOH will send the coldStart trap to the local host only.
By default, RMI applications have read-write access to the Netra CT server MOH agents. If you want to control which applications communicate with the MOH agents, you must configure the alarm card and host CPU board interfaces for RMI. This configuration provides additional security by authenticating who has access to the agent.
To authenticate which RMI applications can access the MOH agents on the alarm card and on the host CPU board, the following configuration is needed:
If MOH security for RMI was enabled but becomes disabled on the alarm card (for example, if the alarm card is being reset or hot-swapped), security will be disabled on the host CPU board as well; a security exception occurs and no access is given.
|
3. Add a password for that user:
Restrictions on the alarm card MOH user name and MOH user password are the same as for the alarm card user name and user password; see Username Restrictions and Password Restrictions.
By default, new MOH user accounts are created with read-only permission. Permission levels can be changed using the mohuserperm command; valid permissions for the mohuserperm command are r (read only) and rw (read and write).
The mohuserdel command is available to delete an MOH user; the mohusershow command can be used to show information for a particular MOH user name or for all MOH user names.
|
1. Verify that RMI programs you want to access the alarm card MOH agent contain a valid alarm card MOH user name and password, with appropriate permissions.
3. Set the setmohsecurity option to true:
The RMI authentication takes effect immediately. Any modification to the alarm card MOH user names and passwords also takes effect immediately. If the MOH application is running on the host CPU board, you must stop and restart it for the changes to take effect.
|
2. Log in to the host CPU board.
3. As superuser, start the MOH application.
The Processor Management Service (PMS) is a management application that provides support for high-availability services and applications, such as the Netra High Availability Suite. It provides both local and remote monitoring and control of a cluster of CPU boards.
You use the alarm card PMS CLI commands to control PMS services, such as fault detection/notification, and fault recovery. The recovery administration is described in Using the PMS Application for Recovery and Control of CPU Boards. You can also use the PMS API to configure partner lists (tables of alarm card and CPU board information relating to connectivity and addressing; the alarm card and the CPU boards in a partner list must be in the same system). Refer to the pms API man pages, installed by default in /opt/SUNWnetract/mgmt2.0/man, for more information on partner lists.
|
1. Log in as superuser to the server that has the Solaris patches installed (see Software Required).
2. Create a Solaris script to start, stop, and restart PMS, as follows:
4. Start, stop, or restart the PMS application by typing one of the following:
where filename is the name of the file in which you saved the script.
You can also save this script in the /etc/rc* directory of your choice to have PMS automatically start at boot time.
This script starts PMS in the available state (start -e force_avail).
On CPU boards, PMS's internal timer service uses a default interval of 0.1 seconds as the time tick interval. You can adjust the tick interval to a number from 0.1 seconds to 2.0 seconds by using the -t option. For example, to start PMS with a tick interval of 1.0 seconds, use the command pmsd start -e force_avail -t 1.
Keeping the default interval value may lead to a large number of voluntary context switches in the system. You can check the effect of increasing the -t option to various intervals by looking at the output from the prstat command; the column labeled VCX contains the number of voluntary context switches received by the operating system from an application. An example of prstat output, with the -t option set to 1, is:
The PMS daemon (pmsd) starts automatically on the alarm card. However, you can manually stop and restart the PMS daemon on the alarm card, specifying these optional parameters:
You specify the port number for pmsd using the parameter port_num.
You specify the state in which to start pmsd using the parameter server_admin_state. This parameter may be set to force_unavail (force pmsd to start in the unavailable state); force_avail (force pmsd to start in the available state); or vote_avail (start pmsd in the available state, but only if all conditions have been met to make it available; if all the conditions have not been met, pmsd will not become available).
You specify whether to reset persistent storage to the default values on the alarm card using the -d option. Data in persistent storage remains across reboots or power on and off cycles. If you do not specify -d, pmsd is started using its existing persistent storage configuration; if you specify -d, the persistent storage configuration is reset to the defaults for pmsd. The -d option would typically be specified only to perform a bulk reset of persistent storage during initial system bring up or if corruption occurred.
|
2. Stop the PMS daemon with the stop command:
where port_num is the port number of the currently running pmsd you want to stop. The default is port 10300.
|
2. Start the PMS daemon with the start command:
where port_num is the port number for pmsd to listen on, server_admin_state can be force_unavail, force_avail, or vote_avail, and -d resets the persistent storage to the defaults for pmsd.
The pmsd slotaddressset command is used to set the IP address by which the alarm card controls and monitors a CPU board in a particular slot. The command establishes the connection between pmsd running on the alarm card and pmsd running on a CPU board. The alarm card and the CPU board must be in the same system.
You specify the slot number of the CPU board and the IP address to be configured. The default IP address for all slots is 0.0.0.0; therefore, control is initially disabled.
|
2. Set the IP address with the slotaddressset command:
where slot_num can be a slot number from 1 to 8, and ip_addr is the IP address to be configured.
The pmsd slotaddressshow -s slot_num|all command can be used to print IP address information for the specified slot or all slots. If the IP address information is not 0.0.0.0 for a given slot, PMS is configured to manage the CPU board in this slot using this IP address.
You can use the PMS CLI application to enable local CPU boards to remotely monitor and control CPU boards in the same system or in other Netra CT systems. One use for this capability is in a high availability environment. For example, if a high availability application fails on a controlled CPU board, PMS notifies the controlling CPU board of the failure, and the controlling CPU board (through a customer application) notifies another controlled CPU board to start the same high availability application.
The pmsd slotrndaddressadd command is used to configure a local CPU board to control and monitor another CPU board by specifying the IP addresses and slot information for the CPU board to be controlled, using the parameters shown in TABLE 2-7.
Each local CPU board can control and monitor 16 local or remote CPU boards. Each local CPU board being managed must have already had its IP address set using the pmsd slotaddressset command.
|
2. Add the address information with the slotrndaddressadd command:
where -s slot_num is the slot number in the same system of the local CPU board you want to use to control other local or remote CPU boards, and all specifies all slots containing CPU boards in the local system; -n ip_addr is the IP address of the CPU board to be controlled; -d ip_addr is the IP address of the alarm card in the system of the CPU board to be controlled; and -r slot_num is the slot number of the CPU board to be controlled.
When you add address information with the slotrndaddressadd command, an index number is automatically assigned to the information. You can see index numbers by using the slotrndaddressshow command and use the index numbers to delete address information with the slotrndaddressdelete command, described below.
The pmsd slotrndaddressdelete -s slot_num|all -i index_num|all command can be used to delete address information from the controlling CPU board. The -s slot_num|all parameter specifies whether the address information will be deleted on a single slot number or on all slots containing CPU boards in the local system. The -i index_num|all parameter specifies whether the address information will be deleted for a single address entry or for all address entries; index_num can be 1 to 16. Before using this command, it is advisable to print the current address information using the pmsd slotrndaddressshow command, so you know the index number to use.
The pmsd slotrndaddressshow -s slot_num|all -i index_num|all command can be used to print address information. The -s slot_num|all parameter specifies whether the address information will be printed for a single slot number or for all slots containing CPU boards in the local system; index_num can be 1 to 16. The -i index_num|all parameter specifies whether the address information will be printed for a single address entry or for all address entries.
| Netra CT Server System Administration Guide | 819-2743-10 |
|
Copyright © 2007, Sun Microsystems, Inc. All Rights Reserved.
To Configure the Alarm Card Serial Ports
Runtime Java Dynamic Management Kit (JDMK) package