An SMF Manifest Cheatsheet

10 May '05 - 04:39 by benr

I've been hacking around a lot with SMF, both for the sake of just playing with it to learn but also as I'm working on other projects that I now can quickly SMF'ize. In doing so I wanted a little cheat sheet with all the possible options avalible to me in the manifests. Being XML its all in the DTD but I need something slightly more readable (no offence Tim).

Before we get to the cheat sheet, lets review SMF for anyone who's not yet spent alittle time playing with it. SMF (aka: Project Greenline) is composed of the following:

  • 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=single-user". 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.


- - C O M M E N T S - -

I’m one poor operator. But Solaris10 is interested and studied.
I will refer to information here because settled information on SMF is a little.
I want to do honestly though it doesn’t live quite well.

The pardon though it is thought that it is strange English. It is not too a forte.

shouichi tatsukami (Email) (URL) - 27 May '05 - 00:27

THANKYOUTHANKYOUTHANKYOU

All I needed to know to get started with smf in about a page. If only Sun provided something like this.

Ray - 16 July '05 - 15:34

I like your website alot…its lots of fun… you have to help me out with mine…

dale (Email) (URL) - 12 June '06 - 22:44

I just don’t have anything to say right now. I haven’t been up to anything recently, but it’s not important. I’ve just been sitting around waiting for something to happen, but shrug.

RuleZ023 (Email) (URL) - 12 June '06 - 23:25

I just don’t have much to say these days, but so it goes. Today was a total loss. I guess it doesn’t bother me.

RuleZ023 (Email) (URL) - 13 June '06 - 12:48

Hi you have a nice homepage

Molli (Email) (URL) - 13 June '06 - 12:49

Hello and congratulations!

damion (Email) (URL) - 13 June '06 - 13:57

I haven’t gotten anything done today. I feel like a fog, but what can I say? I’ve just been letting everything wash over me lately, not that it matters. Shrug.

RuleZ023 (Email) (URL) - 13 June '06 - 15:17

Hope you come back soon!!

shaniqua (Email) (URL) - 13 June '06 - 17:07

Your pictures are great.

Molli (Email) (URL) - 13 June '06 - 23:51

Personal information





Remember your information?
Comment

Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.


^M