SPARC® Enterprise M4000/M5000/M8000/M9000 Servers Administration Guide Manual Code C120-E331-03EN Part No.
Copyright 2007 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, U.S.A. All rights reserved. FUJITSU LIMITED provided technical input and review on portions of this material. Sun Microsystems, Inc. and Fujitsu Limited each own or control intellectual property rights relating to products and technology described in this document, and such products, technology and this document are protected by copyright laws, patents and other intellectual property laws and international treaties.
Copyright 2007 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, Etats-Unis. Tous droits réservés. Entrée et revue tecnical fournies par FUJITSU LIMITED sur des parties de ce matériel. Sun Microsystems, Inc. et Fujitsu Limited détiennent et contrôlent toutes deux des droits de propriété intellectuelle relatifs aux produits et technologies décrits dans ce document.
Contents Preface 1. xvii Introduction to Server Software and Configuration XSCF Firmware 1 Solaris OS Software Software Services 2 3 Preparing for System Configuration Information Needed Related Information Access Control 5 5 7 About Access Control 7 Logging in to the System XSCF User Accounts XSCF Passwords Privileges 4 4 Initial Configuration Tasks 2.
▼ To Add an XSCF User Account ▼ To Create a Password for an XSCF User 14 ▼ To Configure an XSCF Password Policy 14 ▼ To Assign Privileges to an XSCF User ▼ To Display the Version of Installed Firmware Related Information 3.
▼ To Set the Service Processor’s DNS Name Server ▼ To Enable or Disable Use of an LDAP Server for Authentication and Privilege Lookup 33 ▼ To Configure the Service Processor as an LDAP Client ▼ To Set the NTP Configuration ▼ To Display the NTP Configuration ▼ To Set the Timezone, Daylight Saving Time, Date, and Time Locally on the Service Processor 35 ▼ To Create a USM User Known to the SNMP Agent 36 ▼ To Display USM Information for the SNMP Agent 37 ▼ To Create a VACM Group ▼ To Create
Overview of Steps for Domain Configuration Domain Configuration Example Domain Communication DSCP Network 51 52 54 55 Accessing a Domain Console from the Service Processor Logging in Directly to a Domain 55 DVD Drive or Tape Drive Assignment Backup and Restore Operations Dynamic Reconfiguration 55 56 56 XSCF Shell Procedures for Domain Configuration To Specify the XSB Mode ▼ To Set Up a Domain Component List ▼ To Assign an XSB to a Domain ▼ To Power On a Domain ▼ To Display System Board S
▼ To Enable or Disable Writing of Audit Records to the Audit Trail ▼ To Configure an Auditing Policy ▼ To Display Whether Auditing is Enabled Or Disabled ▼ To Display Current Auditing Policy, Classes, or Events Related Information 6.
XSCF Shell Procedures for Using COD ▼ To Install a COD License 79 ▼ To Delete a COD License 80 ▼ To Reserve Licenses for Allocation 81 ▼ To Increase or Decrease Headroom 82 ▼ To Disable Headroom ▼ To Display COD Information ▼ To Display COD License Status ▼ To Display Usage Statistics for COD Resources Related Information A.
Figures FIGURE 2-1 Location of the Operator Panel MODE Switch on a Midrange Server 12 FIGURE 2-2 Operator Panel on a High-end Server FIGURE 3-1 Relationship of the Service Processor and the DSCP Network to the Domains FIGURE 4-1 A Physical System Board in Uni-XSB Mode on an M4000 Midrange Server FIGURE 4-2 A Physical System Board in Uni-XSB Mode on a High-End Server FIGURE 4-3 A Physical System Board in Quad-XSB Mode on a Midrange Server 48 FIGURE 4-4 A Physical System Board in Quad-XSB Mode
xii SPARC Enterprise Mx000 Servers Administration Guide • April 2007
Tables TABLE 1-1 Software Services 3 TABLE 2-1 User Privileges TABLE 3-1 XSCF Network Interfaces 20 TABLE 3-2 LDAP LDIF File Attributes 22 TABLE 3-3 XSCF and Domain Time Synchronization TABLE 4-1 Boards, Domains, and Domain ID Numbers TABLE 4-2 Resource Assignment in Quad-XSB Mode on an M4000 Midrange Server 50 TABLE 4-3 Resource Assignment in Quad-XSB Mode on an M5000 Midrange Server 50 TABLE 4-4 Resource Assignment in Quad-XSB Mode on a High-end Server TABLE A-1 LSB Numbers and St
xiv SPARC Enterprise Mx000 Servers Administration Guide • April 2007
Code Samples CODE EXAMPLE 3-1 LDAP Schema 22 CODE EXAMPLE 3-2 Sample LDAP LDIF File Attributes CODE EXAMPLE 3-3 Sample ntp.
xvi SPARC Enterprise Mx000 Servers Administration Guide • April 2007
Preface The SPARC Enterprise M4000/M5000/M8000/M9000 Servers Administration Guide describes the system configuration procedures, which focuses on the initial settings of the SPARC Enterprise M4000/M5000/M8000/M9000 servers. This document describes the settings of service processors which embedded in the SPARC Enterprise M4000/M5000/M8000/M9000 servers and also refers to the settings of the SolarisTM Operating System, accompanied by the service processors settings.
■ “Fujitsu Welcomes Your Comments” on page xxv Audience This manual is intended for users, who administrate SPARC Enterprise M4000/M5000/M8000/M9000 servers (hereinafter referenced to as XSCF user).
This appendix contains information on mapping device path names. Glossary and Index ■ Glossary The glossary explains the terms used in this manual ■ Index The index provides keywords and corresponding reference page numbers so that the reader can easily search for items in this manual as necessary. SPARC Enterprise Mx000 Servers Documentation The manuals listed below are provided for reference.
Book Titles Manual Codes SPARC Enterprise M4000/M5000 Servers Service Manual C120-E352 SPARC Enterprise M8000/M9000 Servers Service Manual C120-E330 External I/O Expansion Unit Installation and Service Manual C120-E329 SPARC Enterprise M4000/M5000/M8000/M9000 Servers RCI Build Procedure C120-E361 SPARC Enterprise M4000/M5000/M8000/M9000 Servers Administration Guide C120-E331 SPARC Enterprise M4000/M5000/M8000/M9000 Servers XSCF User’s Guide C120-E332 SPARC Enterprise M4000/M5000/M8000/M9000 Se
■ Remote maintenance service Book Title Manual Code Enhanced Support Facility User's Guide for REMCS C112-B067 4. Provided in system Man page of the XSCF Note – The man page can be referenced on the XSCF Shell, and it provides the same content as the SPARC Enterprise M4000/M5000/M8000/M9000 Servers XSCF Reference Manual. 5. Documentation and Supporting on the Web The latest information about other documents and the supporting of the SPARC Enterprise series are provided on the website. a.
7. Information on Using the RCI function The manual does not contain an explanation of the RCI build procedure. For information on using the RCI function, refer to the SPARC Enterprise M4000/M5000/M8000/M9000 Servers RCI Build Procedure and the SPARC Enterprise M4000/M5000/M8000/M9000 Servers RCI User’s Guide available on the website. Abbreviated References to Other Documents In this manual, the following abbreviated titles may be used when referring to a systems manual.
Models The model names used in this manual are as follows. Server class Model name Midrange SPARC Enterprise M4000 SPARC Enterprise M5000 High-end SPARC Enterprise M8000 SPARC Enterprise M9000 Text Conventions This manual uses the following fonts and symbols to express specific types of information.
Prompt Notations The following prompt notations are used in this manual. Shell Prompt Notations XSCF XSCF> C shell machine-name% C shell super user machine-name# Bourne shell and Korn shell $ Bourne shell and Korn shell super user # OpenBoot PROM ok Syntax of the Command Line Interface (CLI) The command syntax is described below. Command syntax The command syntax is as follows: ■ ■ ■ ■ ■ A variable that requires input of a value must be enclosed in <>.
Software License The function to explain in this manual uses the softwares of GPL,LGPL and others. For the information of the license, see Appendix E, "Software License Condition" in SPARC Enterprise M4000/M5000/M8000/M9000 Servers XSCF User’s Guide Fujitsu Welcomes Your Comments We would appreciate your comments and suggestions to improve this document.
xxvi SPARC Enterprise Mx000 Servers Administration Guide • April 2007
Reader's Comment Form Preface xxvii
FOLD AND TAPE NO POSTAGE NECESSARY IF MAILED IN THE UNITED STATES BUSINESS REPLY MAIL FIRST-CLASS MAIL PERMIT NO 741 SUNNYVALE CA POSTAGE WILL BE PAID BY ADDRESSEE FUJITSU COMPUTER SYSTEMS AT TENTION ENGINEERING OPS M/S 249 1250 EAST ARQUES AVENUE P O BOX 3470 SUNNYVALE CA 94088-3470 FOLD AND TAPE xxviii SPARC Enterprise Mx000 Servers Administration Guide • April 2007
CHAPTER 1 Introduction to Server Software and Configuration This chapter provides an overview of the SPARC® Enterprise M4000/M5000/M8000/M9000 server (hereafter referred to as the SPARC Enterprise Mx000 server) software and configuration.
■ ■ XSCF Web, a browser-based graphical user interface XSCF Shell, a terminal-based command-line interface You can access the XSCF firmware by logging in to the XSCF command shell. This document includes instructions for using the XSCF interface as part of the initial system configuration. For more information about the XSCF firmware, refer to Chapter 2 and to the SPARC Enterprise M4000/M5000/M8000/M9000 Servers XSCF User’s Guide.
Software Services TABLE 1-1 contains an overview of software services and networks that are part of a SPARC Enterprise Mx000 server, and where they are documented. TABLE 1-1 Software Services Service Description Access control Access control includes logging in to the system, user accounts, passwords, privileges, and XSCF firmware control. Refer to Chapter 2.
TABLE 1-1 Software Services (Continued) Service Description Fault management No initial configuration is needed. • Domain fault management includes CPU, memory, and I/O (PCI/PCIe) nonfatal errors. All nonfatal errors are reported to the Solaris OS, which will attempt to take faulty CPUs offline or to retire faulty memory pages. Fatal errors are generally handled by the Service Processor.
■ The number of domains in your system. By default, there is one domain and its domain number is 0 (zero). The number of domains could be different from the default if you specified another number of domains when you ordered your system. ■ Firmware version information if you are upgrading the XSCF firmware. ■ Information for optional services that you are going to use, such as Lightweight Directory Access Protocol (LDAP) information for authentication.
Resource Information Solaris OS documentation collection Solaris OS, including fault management Service Manual Hot-replacement operations, fault management External I/O Expansion Unit Installation and Service Manual PCI card chassis Note – man pages available on the Service Processor are followed by (8), for example, version(8); they are also available in the SPARC Enterprise M4000/M5000/M8000/M9000 Servers XSCF Reference Manual.
CHAPTER 2 Access Control Access control is a way of granting access to the system functions or components only to those users who have been authenticated by the system and who have appropriate privileges. Access control depends on the proper configuration of the general security services provided by the SPARC Enterprise Mx000 server.
Logging in to the System There are two entities that can be logged in to on the system, a Service Processor and a Solaris domain. You initially log in to the Service Processor using a serial connection from a terminal device. A terminal device can be an ASCII terminal, a workstation, or a PC. For details on serial port connections, see the Installation Guide for your server or the SPARC Enterprise M4000/M5000/M8000/M9000 Servers XSCF User’s Guide.
operations each XSCF user is allowed to perform. On its own, a user account has no privileges. To obtain permission to run XSCF commands and access system components, a user must have privileges. You can set up the Service Processor to use an LDAP server for authentication instead. To use LDAP, the Service Processor must be set up as an LDAP client. For information about setting up the Service Processor to use the LDAP service, refer to “LDAP Service” on page 21.
The system provides the predefined privileges shown in TABLE 2-1. These are the only privileges allowed in a SPARC Enterprise Mx000 server. You cannot define additional privileges. TABLE 2-1 User Privileges Privilege Capabilities none None. When the local privilege for a user is set to none, that user has no privileges, even if privileges for that user are defined in LDAP. Setting a user’s local privilege to none prevents the user’s privileges from being looked up in LDAP.
The domainadm, domainmgr, and domainop privileges must include the domain number, numbers, or range of numbers to associate with a particular user account. A user can have multiple privileges, and a user can have privileges on multiple domains. User privileges are authenticated locally by default. You can set up the Service Processor to use an LDAP server for authentication instead. For information about setting up the Service Processor to use the LDAP service, refer to “LDAP Service” on page 21.
▼ To Log in Initially to the XSCF Console This procedure can be used for initial login or for lost password access. 1. Log in to the XSCF console with the default login name from a terminal device connected to the Service Processor1. You must have physical access to the system. serial port log-in prompt: default You are prompted to toggle the Operator Panel MODE switch (keyswitch) on the front of the system.
FIGURE 2-2 Operator Panel on a High-end Server You must toggle the MODE switch within one minute of the login prompt or the login process times out. 2. Toggle the MODE switch using one of two methods, as follows: ■ If the switch is in the Service position, turn it to the Locked position, leave it there for at least five seconds, and then turn it back to the Service position. Press the Enter key.
▼ To Add an XSCF User Account When you add a new user account, the account has no password, and cannot be used for logging in until the password is set or Secure Shell public key authentication is enabled for the user. 1. Log in to the XSCF console with useradm privileges. 2. Type the adduser command: XSCF> adduser user where user is the user name you want to add. If you do not specify a User ID (UID) number with the -u UID option, one is automatically assigned, starting from 100. 3.
2. Type the setpasswordpolicy command: XSCF> setpasswordpolicy option where option can be one or more of the options described in the setpasswordpolicy(8) man page. 3. Verify that the operation succeeded by typing the showpasswordpolicy command. ▼ To Assign Privileges to an XSCF User 1. Log in to the XSCF console with useradm privileges. 2.
2. Type the version command: XSCF> version -c xcp The XCP version number is displayed. Command output example is: XSCF> version -c xcp XSCF#0(Active) XCP0 (Current): 1020 ...
CHAPTER 3 System Configuration This chapter describes how to initially configure system services and internal networks that enable communication between the components of your SPARC Enterprise Mx000 server. This chapter contains these sections: ■ ■ ■ About System Services XSCF Shell Procedures for System Configuration Related Information About System Services A SPARC Enterprise Mx000 server uses various services to enable communication between its components.
DSCP Network Between a Service Processor and a Domain The Domain to Service Processor Communications Protocol (DSCP) service provides a secure TCP/IP- and PPP-based communication link between the Service Processor and each domain. Without this link, the Service Processor cannot communicate with the domains. The Service Processor requires one IP address dedicated to the DSCP service on its side of the link, and one IP address on each domain’s side of the link.
DSCP includes its own security measures that prohibit a compromised domain from compromising other domains or the Service Processor. The DSCP should only be configured when there are no domains running. If you change the DSCP configuration while a domain is active, you have to power off the domain before the Service Processor can communicate with it. Refer to Chapter 4 for more information on domains. In a typical DSCP configuration, you enter a network address and netmask using the setdscp command.
TABLE 3-1 lists the XSCF network interfaces.
Domain Name Service The Domain Name Service (DNS) allows computers on a network to communicate with each other by using centrally maintained DNS names instead of locally stored IP addresses. If you configure the Service Processor to use the DNS service, it “joins” the DNS community and can communicate with any other computer on the network through its DNS server. There are no defaults for this service.
■ Whether Transport Layer Security (TLS) is to be used 3. Verify that the LDAP service is working. On the LDAP server, you create an LDAP schema with privilege properties. The schema contains the following: CODE EXAMPLE 3-1 LDAP Schema attributetype ( 1.3.6.1.1.1.1.40 NAME ’spPrivileges’ DESC ’Service Processor privileges’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) objectclass ( 1.3.6.1.1.1.2.
If the LDAP client is configured and enabled on the Service Processor, lookups are first performed locally, and then through the LDAP server. If no privileges are specified for a user, the setprivileges command deletes any local privilege data for that user. Subsequently, the user’s privileges will be looked up in LDAP, if LDAP privilege lookup is enabled. If the none privilege is specified for a user, that user will not have any privileges, regardless of privilege data in LDAP.
If the domain and the Service Processor are using the same time source (for example, the Service Processor), one benefit is that events logged in the Solaris OS and on the Service Processor can be correlated based on their timestamp; if the domain uses a different server as the NTP server, the Service Processor and domain times may drift, and correlating log files could become difficult. Every NTP server and every NTP client must have an ntp.conf file, in /etc/inet/ntp.conf.
■ ■ Power status Environmental status The Service Processor SNMP agent can supply system information and fault event information using public MIBs. SNMP managers, for example, a third-party manager application, use any Service Processor network interface with the SNMP agent port to communicate with the agent. The SNMP agent supports concurrent access from multiple users through SNMP managers. By default, the SNMP agent uses version 3 (v3) of the SNMP protocol.
This section does not cover all the optional services and settings for the Service Processor that you might want to set up and use at a later date. For example, you can set up mirrored memory mode on the Service Processor using the setupfru command. Refer to the SPARC Enterprise M4000/M5000/M8000/M9000 Servers XSCF User’s Guide for information on day-to-day administration and management tasks.
abnormality in the air temperature, such as the CPU temperature, can still be detected. The server temperature limits are set to protect the domain hardware, so this command is logically used before powering on any domain.
▼ To Configure the DSCP Network 1. Log in to the XSCF console with platadm or fieldeng privileges. 2. Type the setdscp command. You can use one of two methods, as follows: ■ Use the setdscp command with the -y -i address -m netmask options: XSCF> setdscp -y -i address -m netmask For example: XSCF> setdscp -y -i 10.1.1.0 -m 255.255.255.0 ■ Use the setdscp command with no options (interactive mode). You are prompted to enter all the DSCP IP addresses sequentially.
▼ To Display DSCP Network Configuration 1. Log in to the XSCF console with platadm, platop, or fieldeng privileges, or domainadm, domainop, or domainmgr privileges for a specific domain. 2. Type the showdscp command: XSCF> showdscp Command output example for a DSCP network of 10.1.1.0 and a DSCP netmask of 255.255.255.0 is: XSCF> showdscp DSCP Configuration: Network: 10.1.1.0 Netmask: 255.255.255.0 Location XSCF Domain #00 Domain #01 Domain #02 Domain #03 ... ▼ Address 10.1.1.1 10.1.1.2 10.1.1.3 10.1.
a. To set the network interface, netmask, and IP address: XSCF> setnetwork interface [-m addr] address where interface specifies the network interface to be set, -m addr specifies the netmask address of the network interface, and address specifies the IP address of the network interface. If the -m option is omitted, the netmask corresponding to the IP address is set. Refer to TABLE 3-1 for valid interface names.
2. Type the setroute command: XSCF> setroute -c [add|del] -n address [-m address] [-g address] interface where -c specifies whether to add or delete routing information, -n address specifies the IP address to which routing information is forwarded, -m address specifies the netmask address to which routing information is forwarded, -g address specifies the gateway address, and interface specifies the network interface to be set with routing information. Refer to TABLE 3-1 for valid interface names.
2. Type the shownetwork command: XSCF> shownetwork -a | interface where -a displays information for all XSCF network interfaces, and interface displays information for a specific XSCF network interface name, in the format xscf#x-y. Command output example for the XSCF Unit #0, LAN#1 is: XSCF> shownetwork xscf#0-lan#1 Link encap:Ethernet HWaddr 00:00:00:12:34:56 inet addr:192.168.10.11 Bcast:192.168.10.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ...
3. To verify the operation, type the showhostname command. XSCF> showhostname -a | xscfu where -a displays the host names for all XSCF Units, and xscfu displays information for a specific XSCF Unit, either xscf#0 or xscf#1. ▼ To Set the Service Processor’s DNS Name Server 1. Log in to the XSCF console with platadm privileges. 2. Type the setnameserver command, followed by one or more IP addresses separated by a comma: XSCF> setnameserver ip_address 3.
▼ To Configure the Service Processor as an LDAP Client Make sure you have added an LDAP privileges schema to the LDAP server, and attributes for each user on the LDAP server. Refer to CODE EXAMPLE 3-1 and CODE EXAMPLE 3-2 for information. 1. Log in to the XSCF console with useradm privileges. 2.
3. Reset the Service Processor with the rebootxscf command to make the settings effective: XSCF> rebootxscf 4. To verify the operation, type the showntp command. XSCF> showntp -a ▼ To Display the NTP Configuration 1. Log in to the XSCF console. 2. Type the showntp command: XSCF> showntp -a | -l | address where the -a option displays all the NTP servers configured for use, the -l option displays time synchronization information, and address is the IP address of an NTP server to display information for.
b. To set the timezone: XSCF> settimezone -c settz -s timezone where timezone is the timezone you want to set. For more information on the settimezone command, including setting Daylight Saving Time, refer to the settimezone(8) man page or to the Reference Manual. 3. To verify the operation, type the showtimezone command. XSCF> showtimezone 4. Type the setdate command: XSCF> setdate -s date where date is the date and time you want to set.
■ To add a new user, use the create argument: XSCF> setsnmpusm create -a authentication_protocol [-p authentication_password] [-e encryption_password] user where authentication_protocol is either MD5 or SHA, authentication_password is the authentication password (must be equal to or greater than 8 characters), encryption_password is the encryption password, and user is the user name to be known to the agent for subsequent SNMP communication.
▼ To Create a VACM Group 1. Log in to the XSCF console with platadm privileges. 2. Type the setsnmpvacm command: XSCF> setsnmpvacm creategroup -u username groupname where username is a valid user name known to the SNMP agent, and groupname is the name of the group to create for the specified user for view access. 3. To verify the operation, type the showsnmpvacm command. ▼ To Create a VACM View 1. Log in to the XSCF console with platadm privileges. 2.
▼ To Display VACM Information for the SNMP Agent 1. Log in to the XSCF console with platadm or platop privileges. 2. Type the showsnmpvacm command: XSCF> showsnmpvacm Command output example is: XSCF> showsnmpvacm Groups Groupname ============= admin Username ============= jsmith, bob Views View ============= all_view Subtree ======= .
2.
2. Type the showsnmp command: XSCF> showsnmp Command output example is: XSCF> showsnmp Agent Status: Agent Port: System Location: System Contact: System Description: Enabled 161 Unknown Unknown Unknown Trap Hosts: Hostname -------host1 Port ---162 SNMP V1/V2c: ▼ Type ---v3 Community String Username Auth Protocol ---------------- -------- -----------n/a user1 SHA None To Enable or Disable the Service Processor HTTPS Service 1. Log in to the XSCF console with platadm privileges. 2.
▼ To Enable or Disable the Service Processor Telnet Service 1. Log in to the XSCF console with platadm privileges. 2. Optionally, display the current status of the Service Processor Telnet Service: XSCF> showtelnet 3. Type the settelnet command: XSCF> settelnet -c function where function is either enable or disable. The Telnet service starts immediately after being enabled, and stops immediately after being disabled. ▼ To Configure the Service Processor SMTP Service 1.
2. Optionally, display the current status of the Service Processor SSH Service: XSCF> showssh 3. Type the setssh command: XSCF> setssh -c function where function is either enable or disable. You must generate a host public key to use SSH. ▼ To Generate a Host Public Key for SSH Service 1. Log in to the XSCF console with platadm privileges. 2.
Related Information For additional information on this chapter’s topics, see: Resource Information man pages showdscp(8), setdscp(8), shownetwork(8), setnetwork(8), applynetwork(8), showhostname(8), sethostname(8), setroute(8), showroute(8), setdate(8), showdate(8), showntp(8), setntp(8), xntpd(1M), ntpq(1M), ntpdate(1M), setnameserver(8), shownameserver(8), sethostname(8), showhostname(8), showlookup(8), setlookup(8), showldap(8), setldap(8), showsnmp(8), setsnmp(8), setsnmpusm(8), setsnmpvacm(8), shows
CHAPTER 4 Domain Configuration This chapter describes how to set up and manage domains with XSCF firmware. On your server, by default from the factory, there is one domain with the Solaris OS installed, and its Domain Identification Number (DID) is 0 (zero).
Domains and System Boards A domain is an independent system resource that runs its own copy of the Solaris OS. Domains divide a system’s total resources into separate units that are not affected by each other’s operations. Domains can be used for different types of processing; for example, one domain can be used to test new applications, while another domain can be used for production purposes.
Uni-XSB mode (1 physical system board with 4 CPUs, 32 DIMMs, and I/O) CMU CPU Memory - 8 DIMMs I/O device CPU Memory - 8 DIMMs I/O device CPU Memory - 8 DIMMs I/O device CPU Memory - 8 DIMMs I/O device FIGURE 4-2 ■ IOU A Physical System Board in Uni-XSB Mode on a High-End Server Quad-XSB ■ ■ A PSB logically divided and configured into four XSBs Each of the four XSBs contains one-quarter of the total board resources: 1 CPU, 8 DIMMs, and I/O. On a midrange server, only two XSBs have I/O.
Quad-XSB mode (1 physical system board divided into 2 domains, each with 1 CPU, 8 DIMMs, and I/O) CMU IOU XSB00-0 CPU Memory - 8 DIMMs I/O device XSB00-1 CPU Memory - 8 DIMMs I/O device XSB00-2 CPU Memory - 8 DIMMs XSB00-3 CPU Memory - 8 DIMMs FIGURE 4-3 A Physical System Board in Quad-XSB Mode on a Midrange Server Quad-XSB mode (1 physical system board divided into 4 domains, each with 1 CPU, 8 DIMMs, and I/O) CMU IOU XSB00-0 CPU Memory - 8 DIMMs I/O device XSB00-1 CPU Memory - 8
The number of domains allowed depends on which midrange or high-end server model you have. The default is one domain and the maximum number of domains is 24. Each domain is identified with a domain ID number, with the default domain as #0. TABLE 4-1 shows the maximum number of system boards, the maximum number of domains, and the domain ID number range by server model.
The Solaris OS is installed on a per-domain basis. In the configuration shown in FIGURE 4-5, there would be three Solaris images, one for each domain. The OS image is installed on internal disks. The internal disks are available only for the first (top) I/O device and the third (third from top) I/O device. The second and fourth I/O devices do not have the capability to have internal hard disks.
In TABLE 4-4, the XSB board number xx is in the range of 00-15; the IOU board number xx is the IOU board number corresponding to the XSB board number. For example, XSB 00-0 has IOU#00-PCI#0.
Note – If you create a new domain, you have to install the Solaris OS on the domain. Refer to the Solaris OS documentation collection for instructions. Domain configuration typically includes these steps: 1. Log in to the XSCF console with appropriate privileges. 2. Specify the XSB mode, either Uni-XSB or Quad-XSB, using the setupfru command. 3. Set up information for a domain (the DCL), using the setdcl command. The DCL identifies the potential resources for a domain. 4.
XSCF> addboard -c assign -d 0 00-0 00-2 XSB#00-0 will be assigned to DomainID 0. Continue?[y|n] :y XSB#00-2 will be assigned to DomainID 0.
04 05 06 07 08 09 10 11 12 13 14 15 - XSCF> poweron -d 1 DomainIDs to power on:1 Continue? [y|n] :y 01 :Powered on XSCF> showboards -a XSB ---00-0 00-1 00-2 00-3 DID(LSB) -------00(00) 01(00) 00(01) 01(01) Assignment ----------Assigned Assigned Assigned Assigned Pwr ---y y y y Conn ---y y y y Conf ---n n n n Test ------Passed Passed Passed Passed Fault ------Normal Normal Normal Normal XSCF> console -d 0 Connect to Domain#00?[y|n] :y {0} ok Domain Communication Domain communication includes: ■ ■
DSCP Network The DSCP network establishes a link, using IP addresses, between the Service Processor and each domain. This link enables communication between the Service Processor and domains, and the secure transfer of information. Each domain must have its own IP address, and the Service Processor must have its own IP address. DSCP is optimized to securely exchange control data such as error reports, fault events, and time synchronization, between each domain and the Service Processor.
Backup and Restore Operations For domain backup and restore operations, refer to your backup software documentation for instructions. The Solaris OS documentation collection also contains information on backup and restore operations. Dynamic Reconfiguration Dynamic reconfiguration allows you to add or remove PSBs from system domains without stopping the Solaris OS.
▼ To Set Up a Domain Component List 1. Log in to the XSCF console with platadm privileges. 2. Type the setdcl command: XSCF> setdcl -d domain_id -a lsb=xsb where domain_id is the domain you are setting the DCL for; lsb is the LSB number; and xsb is the XSB number. 3. Verify the operation with the showdcl command. ▼ To Assign an XSB to a Domain 1. Log in to the XSCF console with platadm privileges or domainadm privileges for a specific domain. 2.
2. Type the poweron command: XSCF> poweron -d domain_id where domain_id is the domain you want to power on. Only a user with platadm or fieldeng privileges can use the -a option to turn on power to all domains. 3. Verify the domain is powered on by opening a console to it, with the console command. Refer to “To Access a Domain From the XSCF Console” on page 58. ▼ To Display System Board Status 1.
▼ To Attach a DVD or Tape Drive While the Solaris OS Is Running (M8000/M9000 Servers) 1. If the Volume Management Daemon (vold) is running, stop the daemon: # /etc/init.d/volmgt stop 2. Log in to the XSCF console with platadm privileges. 3. Type the cfgdevice command: a. To check the status of current drives: XSCF> cfgdevice -l b. To attach a drive: XSCF> cfgdevice -c attach -p port_no where port_no is the port number in the specified domain where the device is to be attached.
2. Detach the drive by typing the cfgadm command: # cfgadm -c unconfigure Ap_Id where Ap_Id is the attachment point of the controller. For example, if the drive is connected to controller c0, you would type: # cfgadm -c unconfigure c0::dsk/c0t4d0 # cfgadm -c unconfigure c0::rmt/0 3. Log in to the XSCF console with platadm privileges. 4. Type the cfgdevice command: a. To check the status of current drives: XSCF> cfgdevice -l b.
Related Information For additional information on this chapter’s topics, see: Resource Information man pages setupfru(8), showfru(8), setdcl(8), showdcl(8), addboard(8), moveboard(8), deleteboard(8), showboards(8), xntpd(1M), showdevices(8), showconsolepath(8), console(8), sendbreak(8), poweron(8), poweroff(8), reset(8), cfgdevice(8), cfgadm(1M), setdomainmode(8) Solaris OS documentation collection Solaris OS installation; NTP; domains; backup operations SPARC Enterprise M4000/M5000/M8000/M9000 Server
62 SPARC Enterprise Mx000 Servers Administration Guide • April 2007
CHAPTER 5 Audit Configuration A SPARC Enterprise Mx000 server can have multiple domains. Those domains must be as secure as if they were running on physically separate servers. To help ensure that level of security, XSCF firmware provides the audit measures described in this chapter.
Audit Records Audit records are stored in audit files on a 4-megabyte file system on the Service Processor. You cannot change the size reserved for the audit files, but you can transfer the files manually to remote storage at any time. You can also configure auditing for automatic transfers. Audit files are stored in binary format, although you can export them to XML. The audit file system switches storage between two partitions.
■ Changes to the time The minimum data recorded for each event includes: ■ ■ ■ ■ Date and time of the event Type of event Who caused the event Outcome of the event (success or failure) Audit Classes Audit classes are categories for grouping and sorting audit events. The SPARC Enterprise Mx000 server provides a predefined set of audit classes, for example, login events and service-related events. You cannot define additional audit classes or change the events in a class.
XSCF Shell Procedures for Auditing This section describes these tasks: ■ ■ ■ ■ ▼ To To To To Enable or Disable Writing of Audit Records to the Audit Trail Configure an Auditing Policy Display Whether Auditing is Enabled Or Disabled Display Current Auditing Policy, Classes, or Events To Enable or Disable Writing of Audit Records to the Audit Trail 1. Log in to the XSCF console with auditadm privileges. 2.
▼ To Display Whether Auditing is Enabled Or Disabled 1. Log in to the XSCF console with auditadm privileges. 2. Type the showaudit command: XSCF> showaudit Auditing: enabled ▼ To Display Current Auditing Policy, Classes, or Events 1. Log in to the XSCF console with auditadm privileges. 2.
68 SPARC Enterprise Mx000 Servers Administration Guide • April 2007
CHAPTER 6 Log Archiving Facility You can set up the Service Processor to automatically archive its log data on a remote host. This chapter contains these sections: ■ ■ ■ ■ About Log Archiving Solaris OS Procedures for Log Archiving XSCF Shell Procedures for Log Archiving Related Information About Log Archiving The persistent storage space on a Service Processor is limited. A portion of this space is set aside for logs, such as audit logs and error logs.
All connections established through log archiving are encrypted. The log archiving feature provides the ability to use an RSA public key to authenticate the archive host. You manage this public key on the Service Processor. By default, log archiving is disabled. To use log archiving, you set up an archive host, and then enable log archiving on the Service Processor. When enabled, log archiving periodically uses the secure copy program (scp) to transfer new log data to the archive host.
As shown in FIGURE 6-1, (1) Before enabling log archiving, create an archive directory on the archive host. There should be a separate archive directory for each system that uses the archive host. The directory permissions should be set so that only authorized users can access its contents. (2) You configure the log archiving feature. (3) As new data accumulates in logs, log archiving polls log files at fixed intervals to determine when new data needs to be archived.
Solaris OS Procedures for Log Archiving ▼ To Configure the Log Archive Host 1. Select a user account on the server that will be used as the archive host that the Service Processor will use to log in. 2. Log in to the archive host and create an archive directory. 3. Set the permissions of the archive directory as desired. The Service Processor login account must have read, write, and execute (rwx) permissions.
3. Type the setarchiving enable command: XSCF> setarchiving enable After tests indicate the archive host is set up correctly, log archiving is enabled effective immediately. If the tests fail, you receive an error message that log archiving was not enabled, and the reason why. ▼ To Disable Log Archiving 1. Log in to the XSCF console with platadm privileges. 2. Type the setarchiving command: XSCF> setarchiving disable ▼ To Display Log Archiving Configuration and Status 1.
Related Information For additional information on this chapter’s topics, see: Resource Information man pages setarchiving(8), showarchiving(8), showlogs(8), snapshot(8) SPARC Enterprise M4000/M5000/M8000/M9000 Servers XSCF User’s Guide Logs; saving logs to a USB device 74 SPARC Enterprise Mx000 Servers Administration Guide • April 2007
CHAPTER 7 Capacity on Demand This chapter describes how to manage system resources with the Capacity on Demand (COD) feature of your server. This chapter contains these sections: ■ ■ ■ About Capacity on Demand XSCF Shell Procedures for Using COD Related Information For information on ordering and purchasing COD licenses, refer to the COD User’s Guide for your server. About Capacity on Demand Capacity on Demand is an option that allows you to purchase spare processing resources (CPUs) for your server.
COD Boards A COD board is a system board that has been configured at the factory for COD capability. COD boards come in the same configurations as standard system boards. The number of CPUs per COD board depends on the SPARC Enterprise Mx000 server configuration that you purchased. COD boards are subject to the same limitations for mixed architectures and CPU speeds as system boards.
Although a COD license can be used by any COD processor, it cannot be moved from one server to another. A COD license is limited to the processors on a specific server. If those processors are moved to another server, the license becomes invalid. License Installation A license key is comprised of text lines, which can be added to the COD license database. A single license key can grant access to multiple RTUs, as specified when the key is generated.
License allocation does not change during a Service Processor reboot or failover. All licenses remain allocated to their resources. You can reserve COD licenses for specific domains by using the setcod command. After power on, reserved licenses are first allocated to their domains, and then remaining licenses are allocated on a first-come, first-served basis to the remaining resources.
License Violations A license violation occurs if more resources are in use than are currently licensed on the server. These events can cause a license violation: ■ The license database is lost or corrupted while the system is running. This state is detected on the subsequent reboot. This situation can be remedied by reentering the missing license keys, using the addcodlicense command. ■ You delete COD licenses with the force option (deletecodlicense -f) while the server is still using those licenses.
1. Log in to the XSCF console with platadm privileges. 2. Type the addcodlicense command: XSCF> addcodlicense license-signature where license-signature is the complete COD license key. For example: XSCF> addcodlicense \ 01:84000000:104:0301010100:3:00000000:xxxxxxxxxxxxxxx 3. Verify that the license key was added to the license database by typing the showcodlicense -r command. The COD RTU license key that you added should be listed in the showcodlicense output.
4. Verify that the license key was removed from the license database by typing the showcodlicense -r command. The COD RTU license key that you deleted should not be listed in the showcodlicense output. See “To Display COD License Status” on page 84. ▼ To Reserve Licenses for Allocation You need to reserve licenses only if you want to make sure a specific number of COD licenses are allocated to a particular domain. 1. Log in to the XSCF console with platadm privileges. 2. Type the setcod command.
The following prompts are displayed, in order: PROC PROC PROC PROC RTUs RTUs RTUs RTUs reserved reserved reserved reserved for for for for domain domain domain domain 0 1 2 3 (6 (6 (4 (4 MAX) MAX) MAX) MAX) [0]: [2]: [0]: [0]: b. Enter the number of licenses reserved for each domain. The currently reserved number appear in parentheses. Do not exceed the number of available licenses. To leave a reservation unchanged, press Return. 3. Verify the allocation with the showcod command.
3. Verify the headroom quantity is correct by typing the showcod command. For example, if you entered 4 as the headroom number, the output would be similar to: XSCF> showcod Chassis HostID: 80d88800 PROC RTUs installed: 8 PROC Headroom Quantity: 4 ... ▼ To Disable Headroom 1. Log in to the XSCF console with platadm privileges. 2. Type the setcod command and a headroom number of zero: XSCF> setcod 0 3. Verify that the headroom is disabled by typing the showcod command.
2. Type the showcod command. The output displays the server’s Chassis HostID, number of licenses (PROC RTUs installed), headroom quantity, and number of licenses reserved for each domain.
2. Type the showcodlicense command. The output displays the resource description, license version number, expiration date, number of licenses, and license status. For example: XSCF> showcodlicense Description ----------PROC Ver --01 Expiration ---------NONE Count ----8 Status -----GOOD To display license information in raw key format, use the -r option.
2. Type the showcodusage command. The output displays a summary of license usage by resource type and for each domain.
Related Information For additional information on this chapter’s topics, see: Resource Information man pages setcod(8), showboards(8), showcodusage(8), showcodlicense(8), showcod(8), addcodlicense(8), deletecodlicense(8) COD User’s Guide Ordering COD licenses; additional COD procedures Service Manual Physical component removal; FRUs Chapter 7 Capacity on Demand 87
88 SPARC Enterprise Mx000 Servers Administration Guide • April 2007
APPENDIX A Mapping Device Path Names This appendix describes how to map device path names to physical system devices. It contains these sections: ■ ■ ■ Device Mapping and Logical System Board Numbers CPU Mapping I/O Device Mapping Device Mapping and Logical System Board Numbers The physical address represents a physical characteristic that is unique to the device. Examples of physical addresses include the bus address and the slot number. The slot number indicates where the device is installed.
An LSB has four processors as a maximum (when a Uni-XSB is assigned to the LSB); therefore, an LSB needs 16 processor IDs. Note that 32 IDs are assigned for future expansion. TABLE A-1 shows the relationship between LSB numbers and starting processor (“proc”) numbers, in hexidecimal/decimal format. The Solaris prtdiag command provides the LSB numbers and CPU chip numbers in decimal format for components that are part of the domain.
CPU Numbering Examples This section contains examples of CPU numbering, using the output of the showboards command on the Service Processor, and the output of the prtdiag command on a domain.
I/O Device Mapping I/O device paths are dictated by which LSB the I/O unit is assigned to. The M4000 and M5000 servers have only one I/O controller on the I/O unit (IOU). For an XSB in Uni-XSB mode, all I/O is on XSB#xx-0. For an XSB in Quad-XSB mode, internal resources, the PCI-X slot, and two PCIe slots are on XSB#xx-0, and two PCIe slots are on XSB#xx-1. The M8000 and M9000 servers have two I/O controllers; therefore, each XSB can have two PCIe slots assigned to it.
I/O Device Mapping on the M4000 and M5000 Servers TABLE A-3 shows the device mapping on a midrange server. In the device path, x is LSB-dependent, and is assigned a value as shown in TABLE A-2.
TABLE A-5 Internal Devices and Device Paths on the M5000 Server XSB 01-0/IOU 1 Accessible Internal Device (M5000) Device Physical Location OpenBoot PROM Device Path Network Port 0 IOU /pci@x0,600000/pci@0/pci@8/pci@0/network@2 Network Port 1 IOU /pci@x0,600000/pci@0/pci@8/pci@0/network@2,1 HD2 System /pci@x0,600000/pci@0/pci@8/pci@0/scsi@1/disk@0 HD3 System /pci@x0,600000/pci@0/pci@8/pci@0/scsi@1/disk@1 I/O Device Mapping on the M8000 and M9000 Servers TABLE A-6 shows the device mapping on
Internal Devices on the M8000 and M9000 Servers The IOUA is a PCIe Host Bus Adapter that provides access to internal devices when installed at specific locations. The IOUA contains two 1Gb Ethernet ports on the card (“on-board”). When the IOUA is installed at specific locations, it also provides access to storage located on the IOU, as well as platform DVD/DAT resources at the locations shown in TABLE A-7. In the PCIe device path, x is LSB-dependent, and is assigned a value as shown in TABLE A-2.
TABLE A-7 Internal Devices and Device Paths on a High-end Server (Continued) PCIe Slot UniXSB* QuadXSB† OpenBoot PROM PCIe Device Path‡ IOU Slot 5 xx-0 xx-2 pci@x5,700000 IOU Slot 6 xx-0 xx-3 pci@x6,600000 IOU Slot 7 xx-0 xx-3 pci@x7,700000 OpenBoot PROM IOUA HBA On-board, IOU, and Platform Accessible Devices§ .../pci@0,1/network@1 (IOUA HBA On-board BGE Port 0) .../pci@0,1/network@1,1 (IOUA HBA On-board BGE Port 1) ...
SPARC Enterprise M5000 Server sample output: # cfgadm -s "select=class(pci)" Ap_Id Type iou#0-pci#0 unknown iou#0-pci#1 unknown iou#0-pci#2 unknown iou#0-pci#3 unknown iou#0-pci#4 unknown iou#1-pci#0 unknown iou#1-pci#1 unknown iou#1-pci#2 unknown iou#1-pci#3 unknown iou#1-pci#4 unknown TABLE A-8 Receptacle empty empty empty empty empty empty empty empty empty empty Occupant Condition unconfigured unknown unconfigured unknown unconfigured unknown unconfigured unknown unconfigured unknown unconfigured unk
SPARC Enterprise M9000 Server sample output: # cfgadm -s "select=class(pci)" Ap_Id Type iou#0-pci#0 unknown iou#0-pci#1 unknown iou#0-pci#2 unknown iou#0-pci#3 unknown iou#0-pci#4 unknown iou#0-pci#5 unknown iou#0-pci#6 unknown iou#0-pci#7 unknown iou#3-pci#0 unknown iou#3-pci#1 unknown iou#3-pci#2 unknown iou#3-pci#3 unknown TABLE A-9 Receptacle empty empty empty empty empty empty empty empty empty empty empty empty Occupant Condition unconfigured unknown unconfigured unknown unconfigured unknown unconf
Glossary audit audit class audit event audit file The collection of data about the use of system resources. Auditing provides a record of security-related system events. A grouping of audit events. Audit classes provide a way to select a group of events to audit. A security-related system action that is audited. Events are grouped into classes. An audit log where audit records are stored. audit policy A set of auditing options that an administrator can enable or disable.
domain A set of one or more system boards that acts as a separate system capable of booting the operating system and running an operating system independently of any other domains. Domains that share a system are characteristically independent of each other. Each domain is based on the logical system board that is assigned to it. Further, each domain is electrically isolated into hardware partitions, which ensures that any failure in one domain does not affect the other domains in the server.
field-replaceable unit (FRU) FRU hostid I/O unit (IOU) Lightweight Directory Access Protocol (LDAP) log log archive logical system board (LSB) LSB A part that can be replaced by field engineers when servicing the server. See field-replaceable unit (FRU). Unique system identifier. The I/O unit, which is common to midrange and high-end servers, monitors I/O events and supports PCIe. Further, the midrange server supports PCI-X cards. The PCI cards must first be inserted in a PCI cassette.
XSB XSCF 102 See eXtended system board (XSB). See eXtended System Control Facility (XSCF).
Index A addboard command, 52, 57 addcodlicense command, 79, 80 adduser command, 14 altitude, 26 applynetwork command, 20, 31 auditing, 63 to 67 B back up, domain, 56 C Capacity on Demand, see COD certificate, 26, 34, 41 cfgadm command, 4, 55, 59, 60, 96 cfgdevice command, 55, 59, 60 Chassis HostID, 77 clock, 23 COD, 75 to 87 boards, 76 headroom, 78, 79, 80, 82, 83, 84 license database, 77 license violation, 79 right-to-use (RTU) licenses, 76 to 87 commands addboard, 52, 57 addcodlicense, 79, 80 adduser,
showarchiving, 71, 73 showaudit, 66, 67 showboards, 57, 58, 86, 91 showcod, 82, 83, 84 showcodlicense, 80, 81, 85 showcodusage, 86 showdate, 36 showdcl, 57 showdscp, 19, 24, 28, 29 showfru, 56 showhttps, 41 showldap, 34 showlookup, 33 shownetwork, 30, 31, 32 showntp, 35 showpasswordpolicy, 15 showsmtp, 26, 42 showsnmp, 40, 41 showsnmpusm, 37 showsnmpvacm, 38, 39 showssh, 43 showtelnet, 42 showtimezone, 36 showuser, 14, 22 snapshot, 71 telnet, 55 version, 16 console access to a domain, 55, 58 escape characte
CPU, 89 I/O device, 89 memory, 26, 46, 50 MIB, 25, 38 mirrored memory mode, 26 MODE switch, 12 N netmask, 4, 19 NTP, 3, 23 to 24, 34 to 35, 52 ntp.
showlookup command, 33 shownetwork command, 30, 31, 32 showntp command, 35 showpasswordpolicy command, 15 showsmtp command, 26, 42 showsnmp command, 40, 41 showsnmpusm command, 37 showsnmpvacm command, 38, 39 showssh command, 43 showtelnet command, 42 showtimezone command, 36 showuser command, 14, 22 SMTP, 3, 26 snapshot command, 71 SNMP, 3, 24 to 25, 36 to 41 Solaris OS, 2, 8, 46, 50, 52, 55, 56 SSH, 3, 8, 14, 26, 42, 55, 71 syslog function, 71 XSCF network, 20 T tape drive, 55 Telnet, 3, 26, 42 telnet c
