| SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers Administration Guide |    
|
| C H A P T E R 3 |
|
System Configuration |
This chapter describes how to initially configure system services and internal networks that enable communication between the components of your server.
This chapter contains these sections:
Your server uses various services to enable communication between its components. See Preparing for System Configuration for an overview of initial service configuration.
These sections provide details on system services:
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. The DSCP service is a point-to-point link between the Service Processor and each domain. FIGURE 3-1 illustrates this relationship.
FIGURE 3-1 Relationship of the Service Processor and the DSCP Network to the Domains
DSCP service is not configured by default. You configure and use the service by specifying IP addresses for the Service Processor and the domains. The IP addresses should be nonroutable addresses on the network.
The setdscp command provides an interactive mode that displays a prompt for each DSCP setting you can configure:
In a system with redundant Service Processors, the standby Service Processor does not communicate with the domains. In the event of a failover, the newly active Service Processor assumes the IP address of the failed-over Service Processor.
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. See Chapter 4 for more information on domains.
In a typical DSCP configuration, you enter a network address and netmask using the setdscp command. The system then configures the Service Processor IP address and any domain IP addresses according to this formula: the Service Processor gets an IP address that is the network address +1; and each domain gets an IP address that is the Service Processor IP address, + the domain ID, +1. For example, if you enter 10.1.1.0 for the network address, and 255.255.255.0 for the netmask, the showdscp command displays output similar to the following:
XSCF> showdscp DSCP Configuration: Network: 10.1.1.0 Netmask: 255.255.255.0 Location Address XSCF 10.1.1.1 Domain #00 10.1.1.2 Domain #01 10.1.1.3 Domain #02 10.1.1.4 Domain #03 10.1.1.5 ... |
This scenario minimizes the range of IP addresses needed for DSCP.
The XSCF network configurable settings include the IP address for the active Service Processor, IP address for the standby Service Processor, gateway address, netmask, and network route.
TABLE 3-1 lists the XSCF network interfaces.
|
Interface between XSCF Units (ISN: Inter SCF Network); high-end server only |
||
On a high-end server, one Service Processor is configured as active and the other is configured as standby. The XSCF network between the two Service Processors allows them to exchange system management information and, in case of failover, to change roles. When the XSCF unit is configured with redundancy, ISN addresses must be in the same network subnet.
Optionally, a takeover IP address can be set up, which is hosted on the currently active Service Processor. External clients can use this takeover IP address to connect to whichever Service Processor is active. Selection of a takeover IP address does not affect failover.
When you set or change the information related to the XSCF network, including the Service Processor host name, DNS domain name, DNS server, IP address, netmask, or routing information, you must make the changes effective in XSCF and reset the Service Processor. This is done with the applynetwork and rebootxscf commands.
You configure the XSCF network with these commands:
Once you have configured the XSCF network, it requires no day-to-day management.
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. To configure the Service Processor to use DNS, you must specify the Service Processor host name, and the DNS server name and IP address.
You can configure the Service Processor DNS service with these commands:
On a server with dual Service Processors, the domain name is common for both Service Processors. A host name can be specified for each Service Processor. Setting a different host name for each Service Processor does not disable failover.
Once you have configured the Service Processor to use the DNS service, it does not require day-to-day management.
The LDAP service stores user authentication and privilege settings on a server so that individual computers on the network do not have to store the settings.
By default, the Service Processor stores user passwords and privileges locally. Account information for users who have access to the Service Processor are stored on the Service Processor itself. (Authentication and privilege lookups for the server’s domains are provided by the Oracle Solaris OS.)
However, if you want to have authentication and privilege lookups performed by an LDAP server, you can set up the Service Processor to be an LDAP client.
The general process for setting up the Service Processor as an LDAP client is:
2. Providing the LDAP server configuration information:
3. Verifying that the LDAP service is working.
On the LDAP server, you create an LDAP schema with privilege properties. The schema contains the following:
You also add the following required attributes for each user on the LDAP server, as shown in TABLE 3-2.
|
The user ID number on the Service Processor. The uidnumber must be greater than 100. Use the showuser command to display UIDs. |
See the Oracle Solaris OS documentation collection for more information on LDAP servers.
If the LDAP client is configured and enabled on the Service Processor, lookups are first performed locally, and then through the LDAP server. If you execute the setprivileges command for a user without specifying privileges, the 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 you specify privilege as none, that user will have no privileges, regardless of privilege data in LDAP.
These commands manage the Service Processor LDAP service:
Note that passwords stored in the LDAP repository must use either UNIX crypt or MD5 encryption schemes.
Once you have configured the Service Processor to use the LDAP service, it does not require day-to-day management.
The XCP 1091 release introduced support for the Active Directory and LDAP/SSL features. Some changes to these features were introduced in the XCP 1092 release.
For information about Active Directory and LDAP/SSL, see the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide.
The Network Time Protocol (NTP) provides the correct timestamp for all systems on a network by synchronizing the clocks of all the systems. NTP service is provided by an NTP daemon.
To use the NTP service, the Service Processor can be set up as an NTP client, using the services of a remote NTP server. The Service Processor also can be set up as an NTP server, as can an external resource.
| Note - Check the Product Notes for your server, which may contain important information about using the XSCF as NTP server. |
TABLE 3-3 shows how the time is synchronized.
When domains are powered on, they synchronize their clocks to the NTP server.
If the domain and the Service Processor are using the same time source, one benefit is that events logged in the Oracle Solaris OS and on the Service Processor can be correlated based on their timestamp. If the domain and Service Processor use different NTP servers, their times may drift, and correlating log files could become difficult. If you connect a domain to an NTP server other than the one used by the Service Processor, be sure both are high-rank NTP servers that provide the same degree of accuracy.
The XSCF can be used as NTP server only for domains on the same platform.
Every NTP server and every NTP client must have an ntp.conf file, in /etc/inet/ntp.conf. The Service Processor has a default ntp.conf file. If you are using NTP, you must create an ntp.conf file on each domain.
If you are using the Service Processor as the NTP server for the domains, create an ntp.conf file on each domain similar to the following:
where ip_address is the IP address you configured for the Service Processor on the DSCP network. To display the Service Processor’s IP address, use the showdscp -s command.
If you are using an external NTP server for the domains, see the xntpd(1M) man page or to the Oracle Solaris OS documentation collection for information on creating the ntp.conf file for each domain.
A Simple Network Management Protocol (SNMP) agent can be configured and enabled on the Service Processor. The Service Processor SNMP agent monitors the state of the system hardware and domains, and exports the following information to an SNMP manager:
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. SNMP v3 is secure, requiring an authentication protocol, authentication password, and encryption password. The valid authentication protocols are MD5 and SHA (secure hash algorithm). You can also configure your server to accept earlier SNMP versions 1 and 2.
The SNMP agent includes the v3 utilities for user management, the User Security Model (USM), and for view access control, the View Access Control Model (VACM). You can change the configuration of SNMP agent traps, USM user accounts, and VACM information.
Initial SNMP v3 configuration includes:
1. Creating USM user information
2. Creating VACM access control information (group, view, and access)
Using VACM requires a basic knowledge of SNMP and MIBs. See the Solaris System Management Agent Administration Guide and to the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide for information.
5. Setting up your SNMP manager application to communicate with the Service Processor SNMP agent based on the configuration you used for the agent, namely, user, port, and trap information.
The SNMP agent is active only on the active Service Processor. In the event of failover, the SNMP agent is restarted on the newly active Service Processor.
This section describes HTTPS, Telnet, SMTP, and SSH services, and altitude settings.
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 using the setupfru command. See the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide for information on day-to-day administration and management tasks.
Hypertext Transfer Protocol (HTTP) over an authenticated/encrypted connection allows you to use the XSCF web browser securely. This is called the HTTPS service. Authentication is provided with a certificate authority and private keys. To use the HTTPS service, you must enable it, and provide an optional port number. The default port is 443. To enable HTTPS service, use the sethttps command.
Telnet service is disabled by default on the Service Processor. To enable it, use the settelnet command. Telnet provides an alternative for those sites that do not have ssh.
Simple Mail Transfer Protocol (SMTP) service is controlled by these commands:
The authentication mechanisms allowed by the mail server are pop, smtp-auth, or none (the default). The SMTP authentications supported are plain and login.
SSH service is disabled by default. To enable it, use the setssh command. A host public key is required for SSH service.
The altitude for your server is set to 0 meters by default. To set it for the actual altitude of your server, use the setaltitude command. Executing this command causes the server to adjust the temperature thresholds it uses to protect the system so it can more accurately detect any abnormality in the intake air temperature. However, even if you do not set the altitude, any abnormality in air temperature, such as CPU temperature, can still be detected. As server temperature limits are set to protect domain hardware, execute the setaltitude command before powering on any domain. See setaltitude(8).
| Note - A modification of the altitude value takes effect only after you subsequently execute the rebootxscf command and reset XSCF. See rebootxscf(8). |
This section describes these procedures:
| Note - You can use the setupplatform(8) command rather than the following procedures to perform network installation tasks. For more information, see the setupplatform(8) man page. |
|
1. Log in to the XSCF console with platadm or fieldeng privileges.
You can use one of two methods, as follows:
You are prompted to enter all the DSCP IP addresses sequentially. A command output example of this interactive mode is:
a. For each prompt, press the Enter key to accept the displayed value, or type a new value followed by the Enter key.
b. To save your changes, enter Y. To cancel the changes, enter N.
3. Verify the operation with the showdscp command.
|
1. Log in to the XSCF console with platadm, platop, or fieldeng privileges, or domainadm, domainop, or domainmgr privileges for a specific domain.
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 Address XSCF 10.1.1.1 Domain #00 10.1.1.2 Domain #01 10.1.1.3 Domain #02 10.1.1.4 Domain #03 10.1.1.5 ... |
|
Settings to configure the XSCF network must be applied to XSCF, and the Service Processor must be reset, before the settings become effective. See To Set Or Reset the XSCF Network.
1. Log in to the XSCF console with platadm privileges.
2. Type the setnetwork command:
a. To set the network interface, netmask, and IP 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. See TABLE 3-1 for valid interface names.
The following example sets the IP address and netmask for the interface XSCF-LAN#0 on XSCF Unit 1 in a high-end server:
b. To enable the specified network interface:
where -c specifies whether to enable or disable the specified network interface, and interface specifies the network interface to be enabled.
| Note - When the XSCF unit is configured with redundancy, ISN addresses must be in the same network subnet. |
For additional information on the setnetwork command, including specifying takeover IP addresses, see the setnetwork(8) man page or to the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide.
3. Verify the operation with the shownetwork command.
|
Settings to configure the XSCF network must be applied to XSCF, and the Service Processor must be reset, before the settings become effective. See To Set Or Reset the XSCF Network.
1. Log in to the XSCF console with platadm privileges.
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. See TABLE 3-1 for valid interface names.
For additional information on the setroute command, including specifying takeover IP addresses, see the setroute(8) man page or to the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide.
|
When you set or change the Service Processor host name, DNS domain name, DNS server, IP address, netmask, or routing information, the settings must be applied to XSCF, and the Service Processor must be reset, before the settings become effective.
1. Log in to the XSCF console with platadm privileges.
2. Type the applynetwork command:
The applynetwork command displays the information that has been set for the XSCF network, and asks you to apply the settings.
3. Execute the rebootxscf command to make the settings effective:
4. Verify the operation with the shownetwork command.
|
1. Log in to the XSCF console.
2. Type the shownetwork command:
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 ... |
|
1. Log in to the XSCF console with platadm privileges.
2. Type the sethostname command:
a. To set the Service Processor host name:
where xscfu can be xscf#0 (XSCF Unit 0) or xscf#1 (XSCF Unit 1 in a high-end server); hostname is the host name to be set for the specified Service Processor (XSCF Unit).
b. To set the Service Processor domain name:
3. To verify the operation, type the showhostname command.
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.
|
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:
3. To verify the operation, type the shownameserver command.
|
| Note - See LDAP Service and Active Directory and LDAP/SSL. |
1. Log in to the XSCF console with useradm privileges.
2. Type the setlookup command:
The -a option sets the authentication lookup to either local or in LDAP; the -p option sets the privileges lookup to either local or in LDAP. When local is specified, lookup is only done locally; when ldap is specified, lookup is first done locally, then in LDAP if not found locally.
3. To verify the operation, type the showlookup command.
|
| Note - See LDAP Service and Active Directory and LDAP/SSL. |
Make sure you have added an LDAP privileges schema to the LDAP server, and attributes for each user on the LDAP server. See EXAMPLE 3-1 and EXAMPLE 3-2 for information.
1. Log in to the XSCF console with useradm privileges.
where bind is the bind name, baseDN is the base Distinguished Name, certchain is an LDAP server certificate chain, -p sets the password to use when binding to the LDAP server (you are prompted for the password), servers sets the primary and secondary LDAP servers and ports, user tests the server connection and password for the specified user, and timeout is the maximum amount of time allowed for an LDAP search before search results are returned. For more information on LDAP, see the setldap(8) man page, to the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide, and to the Oracle Solaris OS documentation collection.
3. To verify the operation, type the showldap command.
|
If you are using NTP, an ntp.conf file must be created on the domains. See Time Synchronization and NTP Service for information. This section describes how to set the XSCF as an NTP client.
1. Log in to the XSCF console with platadm privileges.
where address is the IP address of the NTP server.
3. Reset the Service Processor with the rebootxscf command to make the settings effective:
4. To verify the operation, type the showntp command.
|
If you are using NTP, an ntp.conf file must be created on the domains. See Time Synchronization and NTP Service for information. This section describes how to set the XSCF as an NTP server.
| Note - Check the Product Notes for your server, which may contain important information about using the XSCF as NTP server. |
1. Log in to the XSCF console with platadm privileges.
where stratum_no is the stratum value for the NTP server. The default value is 5.
3. Reset the Service Processor with the rebootxscf command to make the settings effective:
4. To verify the operation, type the showntp command.
|
1. Log in to the XSCF console.
where the -a option displays all the NTP servers configured for use, the -l option displays time synchronization information, address is the IP address of the NTP server for which information is to be displayed, and the -s option displays the stratum value of the NTP server.
|
1. Log in to the XSCF console with platadm or fieldeng privileges.
2. Type the settimezone command:
a. To display the timezones that you can set:
where timezone is the timezone you want to set. For more information on the settimezone command, including setting Daylight Saving Time, see the settimezone(8) man page or to the Reference Manual.
3. To verify the operation, type the showtimezone command.
where date is the date and time you want to set. For more information on the setdate command, see the setdate(8) man page or to the Reference Manual.
5. After specifying the date, you are prompted to reset the Service Processor, so that the date and time become effective. Type Y to reset the Service Processor.
6. To verify the operation, type the showdate command.
|
A USM user known to the SNMP agent is not required to have a regular user account on the Service Processor.
1. Log in to the XSCF console with platadm privileges.
2. Type the setsnmpusm command.
You can use one of two methods to add USM users, as follows:
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. If you do not specify the passwords, you are prompted to enter them.
where clone_user is a valid user name known to the SNMP agent, and user is the user name to be created with the same settings as the valid clone_user. Use the setsnmpusm password command to change either or both passwords for the cloned user, if desired.
3. To verify the operation, type the showsnmpusm command.
|
1. Log in to the XSCF console with platadm or platop privileges.
2. Type the showsnmpusm command:
|
1. Log in to the XSCF console with platadm privileges.
2. Type the setsnmpvacm command:
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.
|
1. Log in to the XSCF console with platadm privileges.
2. Type the setsnmpvacm command:
where OID_subtree is the MIB OID subtree for the view (values start at .1 for the entire MIB tree, and can be limited to certain portions of the tree by using the optional OID_Mask), and viewname is the name of the view to create for the SNMP agent exported MIB information. View access is read-only for the agent.
3. To verify the operation, type the showsnmpvacm command.
|
1. Log in to the XSCF console with platadm privileges.
2. Type the setsnmpvacm command:
where viewname is a valid SNMP agent view, and groupname is a valid SNMP agent group name.
3. To verify the operation, type the showsnmpvacm command.
|
1. Log in to the XSCF console with platadm or platop privileges.
2. Type the showsnmpvacm command:
|
1. Log in to the XSCF console with platadm privileges.
XSCF> setsnmp addv3traphost -u username -r authentication_protocol {-n engine_id | -i} [-a authentication_password] [-e encryption_password] [-p trap_port] traphost |
where username is a user known to the SNMP agent, authentication_protocol is either MD5 or SHA, engine_id is the identifier of the local agent sending the trap, which must match the engine_id expected by the host, -i asks for acknowledgement from the receiving host, authentication_password is the authentication password (must be equal to or greater than 8 characters), encryption_password is the encryption password, trap_port is the listening port for the SNMP agent (the default is 161), and traphost is the host name where the SNMP manager application is running.
If you do not specify the passwords, you are prompted to enter them.
3. To verify the operation, type the showsnmp command.
For additional options with the setsnmp command, including information on configuring your system to accept SNMP version 1 or 2 traps, see the setsnmp(8) man page.
|
1. Log in to the XSCF console with platadm privileges.
3. To verify the operation, type the showsnmp command.
Make sure that your SNMP manager application can communicate with the Service Processor SNMP agent based on the configuration you used for the agent, namely, user, port, and trap information.
|
1. Log in to the XSCF console with platadm or platop privileges.
|
1. Log in to the XSCF console with platadm privileges.
2. Optionally, display the current status of the Service Processor HTTPS Service:
where function is either enable or disable. The HTTPS service starts immediately after being enabled, and stops immediately after being disabled.
For additional options with the sethttps command, including information on certificates and private keys, see the sethttps(8) man page or to the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide.
|
1. Log in to the XSCF console with platadm privileges.
2. Optionally, display the current status of the Service Processor Telnet Service:
3. Type the settelnet command:
where function is either enable or disable. The Telnet service starts immediately after being enabled, and stops immediately after being disabled.
|
1. Log in to the XSCF console with platadm privileges.
2. Optionally, display the current status of the Service Processor SMTP Service:
You are prompted to enter the name of the SMTP mail server to be used, the port number to be used (default is port 25), the authentication mechanism (default is none) and the Reply Address. You must specify a valid email address.
|
1. Log in to the XSCF console with platadm privileges.
2. Optionally, display the current status of the Service Processor SSH Service:
where function is either enable or disable. You must generate a host public key to use SSH.
|
1. Log in to the XSCF console with platadm privileges.
For additional options with the setssh command, including information on adding or deleting user public keys, see the setssh(8) man page or to the SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide.
|
1. Log in to the XSCF console with fieldeng privileges.
2. Type the setaltitude command:
where value is a unit of meters. The unit of meters is rounded off to the nearest hundred meters.
3. To verify the operation, type the showaltitude command.
For additional information on this chapter’s topics, see:
| SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers Administration Guide | E21618-01 |
|
Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
To Configure the DSCP Network