A large SMF/FMA putback to Opensolaris
Last night a really large putback found it’s way into the codebase: It centers around the Fault Management Architecture of Solaris. A lot of new features found their way in Opensolaris. For example smtp-notify:
smtp-notify is a small, lightweight daemon that is fully managed by the Service Management Facility (SMF). It uses the interfaces delivered in libfmevent to subscribe to both software and FMA problem lifecycle events. Upon receipt of an event, it produces an email notification based on a set of notification preferences which are stored in the SMF service configuration repository.
snmp-notify will generate one of two types of SNMP traps, based on the event class. For FMA events (list.* events), snmp-notify will generate the existing sunFmProblemTrap trap as defined in /etc/net-snmp/snmp/mibs/SUN-FM-MIB.mib. For software events (swevent.*), snmp-notify will generate a sunSweventTrap trap as defined in /etc/net-snmp/snmp/mibs/SUN-SWEVENT-MIB.mib.
Furthermore there are lot of other changes, for example a way to configure the notifications in the SMF repository or the definition of FMA events for instance state transitions (eg. a service going online or offline or in maintainance state).
As SMF is running in each zone on it’s own, the fmd (the fault management daemon) had to be enabled to run in non-global zones as well. This was introduced by PSARC 2010/225:
This RFE will enable fmd and associated SMF services in a non-global Solaris zone. The set of fmd plugins delivered into a zone will be restricted to those that are relevant - the hardware-oriented modules, particularly, will not be delivered in a non-global zone. The first consumer of the fmd service in a non-global Solaris zone will be SMF; this will work with fmd to achieve snmp and email notifications of instance state transitions.