Thursday September 16, 2004

SMF/Predictive Self Healing Overview: Part 2

Continuing on with the overview, we're going to cover how services actually get on your Solaris machine, a few more basic concepts, and give a brief outline of what system administration is like under SMF.  For those of you just joining, part 1 of the overview is here.

Manifests

An SMF manifest is an XML file describing a service.  All of the manifests in the system are stored in /var/svc/manifest, under categorical subdirectories.  If you're not planning on converting any of your custom services over to the SMF model, you won't ever need to edit these files, but they can be a helpful reference.

On boot, svc.configd looks in the manifest directory, and if there are any new manifests, it imports them into the repository.  This can also be done manually by the administrator, as I'll describe in later sections.  The entire system is run using information in the repository, not the manifests, they're simply a delivery mechanism of the descriptions of services.  An active system is administered using SMF's command line tools, which I'll briefly outline at the end of this post.

In order to create an SMF service, a user need simply to create an XML file describing it, and import it.  We've labored to make these manifests incredibly simple to use.  In most cases, all you need to do is determine what your service depends on, and how to start and stop it, cut and paste that into an XML file, and you're finished.  For a few minutes of work, you get all the benefits of SMF, including parallel booting of your service, dynamic dependency checking, and automatic restarting on failure.  I'll be dedicating an entire post later on to the process of converting a service to SMF, since it's critical that users understand how simple it can be.  This leads us to:

Compatibility

Take a deep breath, and read this a few times:

          *Everything still works*

Most users of Solaris have their pet scripts and services that they've carefully honed over time, and don't want to part with.  While we'd like you to take advantage of the benefits of SMF and convert your services, you by no means have to.  All of the scripts in /etc/rc*.d continue to be executed on run-level transitions, just like you're used to.

If you look at the states I mentioned in my previous post, you'll see one called legacy_run.  This way, you can use the SMF observational tools to observe your "legacy" services as well as those that have been converted to SMF.  Any service with the state of legacy_run means that it was a script in an /etc/rc*.d directory that was run upon successful transition to a run level.

On the development end, we've converted a great number of the standard Solaris services already.  Once you install Solaris 10, you'll notice that the /etc/init.d and /etc/rc*.d directories are a lot more empty than they used to be.  However, if you upgrade a machine, your pet scripts and services will still be there, and usually still run without a hitch.

Administrative Interfaces

Ah, the heart and soul of it.  We've put a lot of time and effort into making the administration of a Solaris machine with SMF as painless as possible.  Once you start to play with our tools and see what's really possible, I think you'll be a convert as well.  No longer will you have to be grepping for processes in lists, wondering if they're running or not, hunting for configuration files, et cetera.  Administration of SMF services is all done through a central interface, allowing you to observe the state of services, their dependencies, their properties, and make changes to your services quite easily.

The SMF CLI tools are as follows:

• inetadm - observe and configure services that are controlled by inetd.
• svcadm - service administration, including enabling, disabling, and restarting services
• svccfg - manipulate the contents of the repository, usually properties in a service
• svcprop - observe property values in a read-only manner.  outputs are formalized for easy use in shell scripts.
• svcs - observe the state of all the service instances on the system, and detailed views of their dependencies, processes, etc.

Each of these are so commonly used and important that I'll be dedicating a post to each of them in the coming days, including real-world examples from administering my own personal Solaris 10 desktop.

There's also a set of programming interfaces in a library called libscf that developers can use to interact with the repository.  There's two levels to this library, the really nitty-gritty "low level", for those of you who will need to arbitrate transactions, and develop delegated restarters, and the "high level" interface, which provides convenience functions, such as reading a single property value, or enabling a service.

I plan to move on from here to descriptions and examples of the administrative tools, and then how to convert a legacy service to SMF.  As always, any requests or questions should be posted to the comments section, or emailed to me.