Home > Articles > Operating Systems, Server > Solaris

  • Print
  • + Share This
Like this article? We recommend

Default SC SMS Software Configuration

This section discusses the additional software which must be installed on a Sun Fire 15K SC. Specifically, this section covers the configuration of System Management Services (SMS) software.

SC Solaris OE SMS Packages

A Sun Fire 15K SC is based on Solaris 8 OE 10/01 (update 6) using the SUNWCall Solaris OE installation cluster.

The System Management Services (SMS) software, which is required on an SC, is critical for configuring the SC. It resides on the SC and oversees all SC operations. The entire SMS software bundle is comprised of the following fifteen packages:

application SUNWSMSdf   System Management Services Data Files
application SUNWSMSjh   System Management Services On-Line Javahelp
application SUNWSMSlp   System Management Services LPOST object files
application SUNWSMSmn   System Management Services On-Line Manual Pages
application SUNWSMSob   System Management Services OpenBoot PROM
application SUNWSMSod   System Controller Open Boot Prom
application SUNWSMSop   System Management Services Core Utilities
application SUNWSMSpd   System Controller Power On Self Test
application SUNWSMSpo   System Management Services POST Utilities
application SUNWSMSpp   System Management Services picld(1M) Plug-in Module
application SUNWSMSr    System Management Services, (Root)
application SUNWSMSsu   System Management Services User Environment
application SUNWufu    User Flash PROM Device Driver Header File
application SUNWufrx    User Flash PROM Device Driver (Root) (64-bit)
application SUNWscdvr   Sun Fire 15000 System Controller drivers

The preceding packages are specific to Sun Fire 15K SCs.

SC SMS Accounts and Security

The following are users added to the /etc/passwd file by SMS:

# grep sms /etc/passwd
sms-codd:x:10:2:SMS Capacity On Demand Daemon::
sms-dca:x:11:2:SMS Domain Configuration Agent::
sms-dsmd:x:12:2:SMS Domain Status Monitoring Daemon::
sms-dxs:x:13:2:SMS Domain Server::
sms-efe:x:14:2:SMS Event Front-End Daemon::
sms-esmd:x:15:2:SMS Environ. Status Monitoring Daemon::
sms-fomd:x:16:2:SMS Failover Management Daemon::
sms-frad:x:17:2:SMS FRU Access Daemon::
sms-osd:x:18:2:SMS OBP Service Daemon::
sms-pcd:x:19:2:SMS Platform Config. Database Daemon::
sms-tmd:x:20:2:SMS Task Management Daemon::
sms-svc:x:6:10:SMS Service User:/export/home/sms-svc:/bin/csh

Of the twelve preceding accounts, only one is actually used to administer the system. The sms-svc account is the default account for the administration of the Sun Fire 15K system. All of the other accounts provide privileges for the daemons they are associated with. These accounts should never be used to log into the system and can be secured in the same fashion as system accounts which are never used. These accounts are used for the daemons running the SC as described in the SC SMS Daemons section.

The following are the newly added SMS specific /etc/shadow contents:

# grep sms /etc/shadow 

All of the preceding accounts added, including the sms-svc account, are initially locked by having 'NP' as the encrypted password entry.


The password for the sms-svc user should be set, on both SCs, immediately after installation of the SMS software or first power on of the Sun Fire 15K system.

The following are entries added to the /etc/group file by SMS:

# grep sms /etc/group
platsvc ::17:sms-svc

At first glance the preceding entries seem to be a tremendous number of group additions, but they are simply the groundwork to allow delegation of administrative capabilities for the frame, and each of the 18 domains a Sun Fire 15K system is capable of supporting. This allows for separation of the administrative privileges and operator privileges for each domain and the entire frame. The SMS Security chapter in the System Management Services (SMS) 1.1 Administrator Guide referenced in the Bibliography has detailed descriptions of which commands require which group's privileges for execution.

SC SMS Daemons

The SMS-specific daemons can be broken up into three separate types. These three types are each listed below with sample ps output.

First, there are the platform or core SMS daemons which run on both the main and spare SC:

root   8108  1 0 17:53:04 ?    0:01 mld
root   8123  1 0 17:53:05 ?    31:35 hwad
root   8126  1 0 17:53:05 ?    0:00 mand
sms-frad 331  1 0 12:41:21 ?    0:00 frad
root   8132  1 0 17:53:06 ?    0:03 fomd

Secondly, there are the SMS daemons that only run on the main SC:

sms-pcd  393   1 0 12:41:43 ?    0:03 pcd
sms-tmd  402   1 0 12:41:43 ?    0:00 tmd
sms-dsmd 405   1 0 12:41:44 ?    0:00 dsmd
sms-esmd 414   1 0 12:41:45 ?    0:05 esmd
sms-osd  419   1 0 12:41:46 ?    0:00 osd
root   8218  1 0 17:53:33 ?    0:00 kmd
sms-efe  475   1 0 12:41:47 ?    0:00 efe
sms-codd 483   1 0 12:41:48 ?    0:00 codd

Lastly, there are the SMS daemons which communicate to the domains:

sms-dxs 4428  291 0 13:14:31 ?    0:00 dxs -d A
sms-dca 4429  291 0 13:14:31 ?    0:00 dca -d A


The listing of services above is a sample of the services that may be encountered. Depending on how many domains are in use, more SMS daemons will be running for each of those domains.

These SMS daemons are started by /etc/rc2.d/S99sms based on its startup daemon (ssd) configuration file in /etc/opt/SUNWSMS/SMS1.1/startup/ssd_start.

Each of these SMS daemons is briefly described below:

  • dca (Domain Configuration Administration) – supports remote Dynamic Reconfiguration (DR) by facilitating communication between applications and the dcs daemon running on the domain. A separate instantiation of the dca daemon is executed on the SC for each domain running Solaris OE.

  • dsmd (Domain Status Monitoring Daemon) – monitors domain state, CPU reset conditions, and the Solaris OE heartbeat for up to 18 domains. This daemon notifies the dxs daemon and Sun Management Center software for all changes.

  • dxs (Domain X Server) – provides a variety of software support for a running domain including DR, Hot-Pluggable PCI I/O Assembly (HPCI) support, domain driver requests and events, in addition to virtual console support. One dxs daemon is started on the SC for each running domain.

  • efe (Event Front End) – receives notification of events from various SMS daemons and forwards them on to subscribed clients. With SMS 1.1, the only client that can subscribe is Sun Management Center 3.0 software.

  • esmd (Environmental Status Monitoring Daemon) – provides monitoring of the environment conditions of the Sun Fire 15K system including system cabinet conditions and fan tray and power supply temperatures. One instance of the esmd is run on the main SC.

  • fomd (Failover Management Daemon) – is the center of the SC failover mechanism through its ability to detect faults on remote and local SC, and take appropriate action. One instance of fomd will be run on the main SC. This daemon uses RPC services on the SC and is the reason why rpcbind is not disabled.

  • frad (FRU Access Daemon) – is the field replaceable unit (FRU) access daemon for SMS. It is the mechanism by which access is provided to the SEEPROMs, within the Sun Fire 15K frame, to which the SC has access. The frad is run locally on the main and spare SCs.

  • hwad (Hardware Access Daemon) – implements hardware access for SMS daemons which is used by the daemons to control, access, configure, and monitor hardware. The hwad is run on the main SC.

  • kmd (Key Management Daemon) – is used to manage the secure socket communication between the SC and domains. One instance of kmd is run on the main SC.

  • mand (Management Network Daemon) – supports the Management Network (MAN). The role played by the mand daemon is specified by fomd. Similar to kmd, one instance of mand is executed on the main SC.

  • mld (Message Logging Daemon) – accepts the output of all SMS daemons and processes and logs those messages based on its configuration files. One instance of the mld is executed on the main SC.

  • osd (OpenBoot PROM Support Daemon) – supports the OpeBoot_ PROM process running on a domain through the mailbox that resides on the domain. When the domain OpenBoot PROM writes requests to the mailbox, the osd daemon executes those requests. Only the main SC is responsible for booting domains; correspondingly, one instance of the osd is run on the main SC.

  • pcd (Platform Configuration Database Daemon) – is responsible for managing and controlling access to platform and domain configuration information. As with osd the pcd is only executed on the main SC.

  • tmd (Task Management Daemon) – implements task management services for the SMS software such as scheduling. Currently, this daemon is used by setkeyswitch, and other daemons, to schedule Hardware Power-On Self Test (HPOST) invocations. The main SC is responsible for these types of events, so one instance of tmd is run on the main SC.

Additional information on each of these daemons can be obtained in the SMS Administration and Reference guides listed in the Bibliography.

  • + Share This
  • 🔖 Save To Your Account