- Platform Configuration
- Platform and Domain Administration
- Platform Security
- Error Analysis and Diagnosis
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Platform and Domain Administration
The SC has a administration scheme in which operations affecting the entire system are administered through a platform shell and operations affecting separate domains are administered through a domain shell.
This section contains general descriptions of administering the SC and detailed descriptions of the following topics:
"Monitoring Through the Serial Port, syslog, and SNMP"
"Setting Up Information Recording and Logging"
You can access multiple platform shells simultaneously. The platform shell can view the status of any component within the system and can also control its allocation. One example of how the platform shell is used to manage the entire system is through access control lists (ACLs). You can set up ACLs by using the setupplatform -p acl command. You can also use the ACLs to restrict domain access to resources.
While the platform shell manages and administers overall system resources, domain specific operations, such as the turning of the virtual keyswitch, are controlled by the domain shell. The domain shell can only access resources specified in the ACL set up for it by the platform shell, and only one shell per domain can be active at any time. The ACL restricts the domain shell so that it views only the resources that the domain is currently using, resources that are allocated to the domain, or any resources that are unassigned on the platform and are available to the domain according to the ACL.
One advantage to this setup is that you can restrict the access to the platform shell (and administration of the overall system resources) to a group of administrators, who are separate from a group of administrators for the domains. You can control access to platform and domain shells by using passwords that you can set and change by using the password command on the SC. From the platform shell, you can set or change the platform and domain shell passwords. From a domain shell, you can change only the password of the particular domain. Because the platform has additional privileges, its password should be different from those selected for the domains.
Monitoring Through the Serial Port, syslog, and SNMP
Administration of a Sun Fire server is designed to be performed primarily through the SC, which can be accessed in two ways: RS-232 serial port and 10/100BASE-T Ethernet. Both ports should remain available at all times, and you should monitor the platform console and all of the domain consoles.
After the initial platform setup, the serial port performs an important role in the administration of the Sun Fire server. The system in the event of a network outage and the location where the system outputs platform and SC error messages to the serial port. While output is buffered (up to 4 kilobytes) and can be directed to a syslog host if a network is configured, you should continuously monitor the serial port output either with a logging terminal server or by connecting the serial port to an MSP, which can capture the terminal output with a mechanism such as script(1) in the Solaris? Operating Environment (Solaris OE). This mechanism provides additional error detection and information in the event of a failure. Finally, network connectivity to the SC will be lost during firmware updates because the SC is rebooted. Thus, serial port access is critical to monitor the progress of the update procedure and for diagnostics, should a problem arise.
For routine tasks, the preferred method of accessing the SC is the Ethernet interface. In addition to providing multiple high-speed shell connections, the Ethernet interface on the SC enables you to set up syslog(3) and SNMP messages to be sent to a designated administration platform. The Ethernet interface is required for performing firmware updates on the system and for saving and restoring the SC configuration information. You should enable and configure both syslog and SNMP facilities; however, you should record system consoles by using a mechanism such as script(1M) because not all of the messages can be logged with syslog or SNMP.
Note
SNMP should not be enabled unless a Sun MC server has been configured to support the system.
Setting Up Information Recording and Logging
You should perform the setup of information recording and logging during the initial platform setup. Although you can also make these changes at other times, you should set up syslog(3) to record the information to a central location so that information can be quickly located in the event of a problem and to prevent the SC message buffer from being overwritten.
Because the SC message buffer is in volatile memory, messages can be lost if the SC loses power. The SC maintains a 4 kilobyte ring buffer for messages from each domain and the platform. It also maintains an additional buffer to record particular failure messages for retrieval by authorized service personnel.
When setting up the platform or domain using the setupplatform or setupdomain, respectively, you are prompted for a syslog(3) log host. You can supply a syslog(3) log host by using an IP address or hostname, as well as a facility level.
Note
For older firmware, you will not see the Log Facility prompt, as shown in the following example of how to set up log host. The syntax for the log hostname is hostname:facility (for example, mysysloghost:local0).
The following shows an example of how to set up the log host.
heslab-16-sc0:SC> setupplatform -p loghost Loghosts -------- Loghost [10.1.63.251]: loghost_name Log Facility [local0]: heslab-16-sc0:SC> heslab-16-sc0:B> setupdomain -p loghost Loghosts -------- Loghost [ ]: loghost_name Log Facility [local0]: local1 heslab-16-sc0:B>
Corresponding changes need to be made to the /etc/syslog.conf file on the syslog(3) host or on the MSP. You can find further information on the configuration of syslog(3)) in the Solaris OE system administration guides in the Solaris OE System Administrator AnswerBook2? collection.
Based on the number of systems and syslog(3) devices that a single syslog(3) host will be monitoring, you should establish a convention to maximize use of the limited number of syslog(3) facilities. There are only eight syslog(3) facilities available for users in the Solaris OE, so it is likely that an administrator will quickly run out of unique syslog(3) facilities. Organization of message logging is important to enable administrators to quickly find the desired information. A good way to organize syslog(3) logging is to assign the local0 facility to all platform messages and then assign local1-4 to domains A through D, respectively. The syslog(3) facility in the Solaris 8 OE identifies each syslog(3) entry with the originating hostname and syslog(3) facility. This identification makes it easy to quickly separate messages coming from different hosts.
When setting up the platform, you can configure the SC to interface with the latest versions of the Sun MC software through SNMP. This improves the monitoring and administration capabilities of the platform. It is strongly recommended that the default community strings be changed during installation for security reasons. The following values for platform and domain public and private community strings are set by default.
Platform Public: P-public Platform Private: P-private Domain A Public: A-public Domain A Private: A-private Domain B Public: B-public Domain B Private: B-private Domain C Public: C-public Domain C Private: C-private Domain D Public: D-public Domain D Private: D-private
SNMP must be enabled on the platform by using the setupplatform command before SNMP can be enabled on any of the domains. The following shows an example of the setupplatform command.
heslab-16:SC> setupplatform -p snmp SNMP ---- Platform Description [Sun Fire 3800]: Platform Contact [email_address]: Platform Location [Lab]: Enable SNMP Agent? [no]: yes Trap Hosts [ ]: 10.1.221.11 Public Community String []: P-public Private Community String []: P-private
For more information on how to set up SNMP, refer to the security articles by Alex Noordergraaf at the Sun BluePrints Online website at:
http://www.sun.com/blueprints/
The following shows an example of the setupdomain command.
heslab-16:A> setupdomain -p snmp SNMP ---- Domain Description [test]: Domain Contact [email_address]: Trap Hosts [ ]: 10.1.221.11 Public Community String [ ]: A-public Private Community String [ ]: A-private heslab-16:A>
The port for the Trap Hosts value can be entered in the form of hostname:port in firmware 5.13.0, or higher. Do not change the port setting unless specifically instructed to do so for the installation of other software on the trap host. To find additional information on configuring the Sun MC software, refer to the Sun MC software documentation at the following site:
In addition to setting up syslog(3) and SNMP, you should monitor domain console sessions in a manner similar to that described for the platform and the serial port connection. While the SC has a buffer for each domain shell's messages, the SC will not send domain console messages or error messages generated by the Solaris OE (such as panic strings) to an external log host. Therefore, if you do not constantly monitor the domain consoles, critical messages and valuable diagnostic information could be lost in the event of a failure. With multiple domains to monitor, you should access the domain shells through the Ethernet port because it allows multiple connections.