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">
<service_bundle type='manifest' name='CSWmypkg:myserver'> Type => manifest (also optional for profile and archive Name => PKGname:appname
-> "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.
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.
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
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