SMF Manifests: XML descriptions of a service.

Within are contained details on how to start, stop, and refresh the service, a list of all dependancies and how they relate within a framework, contraints on whether this is a single instance only or can be run as multiple instances, the service name and its default state, and pointers to related documentation and information such as websites, man pages, and docs.

Methods: Scripts that preform the functions required by the manifest (starting a service, stopping it, and refreshing it). One script can do all these or you can use sepreate scripts. Furthermore, if you can start, stop or refresh with a single execution line you can simply call it in the Manifest rather than in a method script bypassing the need for method scripts all together. Milesontes: Think of a milestone as similar to a run-level. With SMF in Solaris10 instead of booting to single user via "boot -s" you can now instead "boot -m milestone=singleuser". While conceptually diffrent, milestones are implemented as manifests. Here is the twist, milestones are less rigid than the traditional run-level, so its a much looser grouping of services than was previously possible, therefore you could for instance create a database milestone that handled db related services which would start them all as a single grouping. Examples of default milestones include 'single-user" (rcS), "multi-user" (rc2), "multi-user-server" (rc3), "name-services" (start dns, ldap, nisplus and nis_client), "sys-config" (bare bones), and "network" (loopback and physical interfaces started).

Thats the 20 second overview anyawy. If you can start your service with a single exec line that'll never change then you don't even need a method script, however because the manifest is XML you have to import it into XML (using "svccfg import") which means that if you want to customize your execution line without using the svccfg tool a method is just the ticket, and beyond that you can add all the scripting logic and goodies you want into the method script providing some extra flexability. Anyway, thats why sometimes you'll see just manifests distributed alone and other times see a method along with it. When you start digging around, here are the places to check out and look for examples:

/lib/svc/method: System provided methods /var/svc/manifest: System provided manifests, including milestones. /etc/svc: SMF data thats all hands off. /var/svc/log: SMF logs

On with the cheat sheet. You'll always need an XML header. Comments can be added in normal XML fashion.
<?xml version="1.0"?> <!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

Define the service_bundle.

<service_bundle type='manifest' name='CSWmypkg:myserver'> Type => manifest (also optional for profile and archive Name => PKGname:appname

The service name and version.

<service name='network/myserver' type='service' version='1'> Name => Name to be refered, canonical name. Type => Type of service, service, restarter or milestone. Version => Integer Version for this service

Define the instance.

<instance name='default' enabled='false'> Name => canonical name for this instance of the service Enabled => Inital state of the instance.

Define the interface stability.

<stability value='Evolving' /> value => Interface Stability according to attributes(5): Stability Release Comments --------------------------------------------------------------------Standard Major (x.0) Actual or de facto. Stable Major (x.0) Incompatibilities are exceptional. Evolving Minor (x.y) Migration advice might accompany an incompatibility. Unstable Minor (x.y) Experimental or transitional: incompatibilities are common. External Micro (x.y.z) Not controlled by Sun: intrarelease incompatibilities are common. Obsolete Minor (x.y) Deprecated interface: likely to be removed in a future minor release.

Define your dependancies.

<dependency name='loopback' grouping='require_all' restart_on='error' type='service'> <service_fmri value='svc:/network/loopback:default'/> </dependency> name => Name of this dep. grouping => Relationship of the listed FMRIs to this service:

-> "require_all" : All listed FMRIs must be online. -> "require_any" : Any of the listed FMRIs must be online -> "exclude_all" : None of the FMRIs can be online. -> "optional_all" : Listed FMRIs are either online or unable to come online, either due to being disabled, misconfigured or unable to start due to deps. Restart_on => Type of event from the FMRI that this service should be restarted for, being: -> error : Hardware fault -> restart : Retarted if the dep is restarted. -> refresh : Restarted if the dep is restarted or refreshed for any reason. -> none : Nothing, never start the service to to a dep state change. type => Type of the dep, "service" or "path" delete => This dep should be deleted.

FMRI's are simple little fellows.

<service_fmri value='svc:/network/loopback:default'/> value => the FMRI

Define your methods, normally one each for "start", "stop", and "refresh".
<exec_method type='method' name='start' exec='/usr/bin/serverd' timeout_seconds='60' /> type => Type of method, "method" or "monitor" name => Name of execution method, a defined interface of the restarter. exec => A string identifying the action to take. timeout_seconds => Duration to wait for the method to complete. delete => If in the repo, the property group for this method should be remoed.

Perhaps even specify the restater, not needed.

<restarter> <service_fmri value='svc:/network/inetd:default' /> </restarter> Specifies the restarter for this service, by default svc.startd(1M)

Method contexts can be handy to setup the enviroment (or "context") in which your service runs.
<method_context> <method_credential user='root' group='root' /> <method_environment>

<envvar name="PATH" value="/bin:/opt/csw/bin" /> </method_environment> </method_context> envvar -> name: Env name value: Env value method_environment -> (continas multiple envvar tags) method_profile -> name method_credential -> user -> group -> supp_groups -> privileges -> limit_privileges

Example of inetd property groups.

<property_group name='inetd' type='framework'> <stability value='Evolving' /> <propval name='name' type='astring' value='telnet' /> <propval name='endpoint_type' type='astring' value='stream' /> <propval name='proto' type='astring' value='tcp6' /> <propval name='wait' type='boolean' value='false' /> <propval name='isrpc' type='boolean' value='false' /> </property_group>

Should it start by default?

<create_default_instance enabled='false' /> A flag element indicating that an otherwise empty default instance of this service (named "default") should be created at install, with its enabled property set as given.

Should there be one, and only one instance?

<single_instance /> A flag element, meaning only one instance can be started. [ Typically used with <create_default_instance> ]

There you go, some of my chopped up notes that might be handy. Mind you, this isn't official, just my scribbled notes that I thought might be helpful to someone or at least get ya fired up enought to dabble into SMF for yourself. If anyone finds this terribly useful I'll form it into a pretty LaTeX document at some point.

OTD Get the request. Determine the server pool to which the request must be routed. Choose one of the servers from the server pool using the specified load distribution algorithm. Configuration Collection of configurable elements that determine the runtime behavior of the OTD instance Typical configuration contains listeners (IP+port) on which OTD should listen for requests and info about the backend servers to which the requests need to be routed. Administration Node A host on which you can deploy OTD instances Administration Server

War/adm