Quoth Brendan Gregg on Tue, Apr 18, 2006 at 01:22:59AM +1000:
> I've started creating a site to demonstrate some great features of SMF.
> I think SMF is fantastic. The state of SMF documentation, however, is
> different. 13 months after Solaris 10 FCS, the System Administration
> Guide on docs.sun.com does not cover how to add an SMF service (not even
> a link to the bigadmin article or the blueprint); instead it covers how
> to add an rc script.
Are you talking about writing a manifest from scratch? I think we'd
prefer that that go into the developer documentation. Installing
a manifest which you have obtained from a developer, though, should be
covered.
> SMF is certainly better documented than many other areas of Solaris 10,
> however as having the greatest impact on day-to-day administration, it
> needs to be. I hope I can help out by contributing something.
Great! Are you aware of Bernd Schemmer's FAQ, at
http://home.arcor.de/bnsmb/public/htdocs/My_Little_SMF_FAQ.html
? There's talk of bringing it into the SMF community.
> I'm emailing about the /var/svc/manifest/site directory. Documentation
> describes this as a "site local" directory then goes no further.
>
> I'm wondering if "site" is intended to be the location for both adding
> manifests (no suprise there), and customising copies of system manifests.
> I'm encouraged by some code in /lib/svc/method/manifest-import,
...
> So, why would order matter unless we expect the same manifest file to
> appear in both? (such that site is applied last, as it contains our
> customised version). ... I may be reading far to much into this.
Unfortunately you're reading too much into it. The site directory is
intended to be a home for site-specific services, not for service
customizations. smf(5) says
Site-specific services should be named with a
category beginning with 'site'.
That is pretty bare-bones. I can file a bug against it. Also the
documentation which
> describes this as a "site local" directory then goes no further.
Which documentation were you speaking about?
> 1. Adding services
>
> If I add a service manifest to Solaris, "site" looks like an ideal
> location. The bigadmin article (sdev_intro) doesn't cover this, and the
> blueprint (819-5150) puts in under /var/svc/manifest/service. Hmm.
> I would think that "site" makes more sense, as it is obvious to the next
> admin (or Sun support staff) what was added to a system.
Indeed. I'll see if we can fix those (it's probably too late for the
blueprint).
> An add-service recipe would be something like,
>
> cd /var/svc/manifest
> cp system/system-log.xml site/brendan.xml
> vi site/brendan.xml
> xmllint --noout site/brendan.xml
> svccfg validate site/brendan.xml
> svccfg import site/brendan.xml
> svcadm enable brendan
> svcs -lp brendan
>
> Assuming system-log.xml makes for a suitable template to copy and turn
> into our new "brendan" service, or whatever.
Looks good.
> 2. Changing services
>
> The documentation does discuss creating an XML file when adding services.
> This is, of course, handy - as that file could be created on one server
> then distributed to many.
>
> Documentation then points to running svccfg in its interactive interface
> mode to make changes, eg, "Changes to existing system services should be
> made using svccfg.". (I'm assuming editing the XML files then using svccfg
> to reimport them doesn't qualify as "made using svccfg" ;-)
>
> (now the bit you aren't going to like!)
>
> Instead of that, here is a suggested recipe for changing services, for
> example changing system-log,
...
> So, no interactive svccfg at all. I'm copying the original system-log.xml
> to "site" where it can be customised. The final XML file can be easily
> rolled out on multiple servers. Had I made many changes in svccfg, I would
> have to automate them in a script file for rollout (exporting to XML
> then reimporting on another server isn't quite the same, I'll get to that
> in a moment).
>
> Lets call this method xml-site-customisations. The Sun recommended
> interactive svccfg method would be svccfg-customisations.
...
> [4] This is the bit you are really not going to like:
>
> So, it appears that one of the great features of SMF is upgrade conflict
> resolution. Customisations using svccfg are "sticky", reimporting updated
> manifest files won't overwrite them. So finally we have a solution to the
> patch-destroyed-my-changes problem! Yay, thank you!! :-D
>
> ... and now I'm side-stepping this wonderful feature. :-O
Not only are you side-stepping it, but you're setting yourself up for
regression. By svccfg import'ing your customized manifest, svccfg
thinks it is official. So if a patch updates the original manifest,
manifest-import will rerun svccfg import on it, which will "upgrade"
from your manifest to the new one, which of course has no customizations
relative to itself, and will end up replacing your customizations with
the properties from the updated manifest.
> In order to keep it, we would need to modify our services by writing
> svccfg script files, and keep them under "site" without an xml extension.
> This could be called svccfg-site-customisations, as a copy of the svccfg
> customisations lives in site.
...
> Please share any thoughts on,
>
> svccfg-customisations # interactive. no automation or diffs.
> xml-site-customisations # everything is XML. easy, obvious.
> svccfg-site-customisations # svccfg scripts. all advantages, complex.
We recognize that service customization from files is necessary. (I
like to use JumpStart as the canonical example.) So we're formulating
a project to officially support it. It looks like we'll allow you to
create a "profile" of "change manifests" which can be applied and backed
out. I think we'll also need a tool which can capture the current state
of the repository and compare the repository against such a capture.
How does that sound? I'd estimate that a design document (which would
be published here) is on the order of a month away, though if there's
a lot of interest we might begin sooner by publishing requirements and
such.
In the meantime, though, I think scripts which make customizations with
svccfg is the best practice. (Though I'm not sure that they should be
kept in /var/svc/manifest/site .)
David
