G'Day Folks,
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.
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.
...
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,
#
# 2. Manifest import. Application directories first, then
# site-specific manifests.
#
nonsite_dirs=`/usr/bin/find /var/svc/manifest/* -name site -prune -o -type d \
-print -prune`
[...]
(Phwaorr - it's not every day you see -prune get used! :-)
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.
The following is more discussion on both adding and customising from the
site directory,
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.
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.
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,
cd /var/svc/manifest
cp system/system-log.xml site
vi site/system-log.xml
xmllint --noout site/system-log.xml
svccfg validate site/system-log.xml
svccfg import site/system-log.xml
svcadm refresh system-log
svcadm restart system-log
svcs -lp 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.
Advantages of xml-site-customisations,
1. /var/svc/manifest/site contains ALL additions and changes
2. The XML file provides easy multi-server rollouts
3. A diff will highlight changes from the original XML [1]
4. If a mistake is made, it is easy to reimport
5. If the repository.db is corrupt, no changes are lost when
regenerating it, as the source remains. [2]
6. A sysadmin can always recursive-grep /var/svc/manifest to find
things when troubleshooting. [3]
Disadvantages of xml-site-customisations,
1. Potential for more mistakes when using vi than svccfg.
2. Sun updating manifest files (in patches?) will conflict with
the svccfg versions. [4]
[1] maybe we need a snapshot "diff" subcommand.
[2] ok, there are other ways around the corrupt repository.db problem
which are generally fine - such as restore_repository. (I wish "svccfg
archive > /tmp/all.xml" was another option - but importing an entire
archive seems broken).
[3] ok, you can "svccfg archive > /tmp/all.xml; vi /tmp/all.xml" then use
vi's search capability (which is better than grep's single-line view).
[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
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.
Listing the svccfg-site-customisations advantages over the previous list,
1. sort of, just in different formats
2. yes (just not XML)
3. yes (and don't need diff)
4. sort of, it takes a few more steps
5. not quite, need to remember to reapply scripts
6. yes
with an additional,
7. modifications won't be trashed by patching.
I could write the suggested receipe(s) to make this work, which will be
slightly more convoluted than the xml-site-customisations method; but this
email is getting too long.. :)
...
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.
I like the everything is XML mentality, as do others I've spoken to. I
could understand arguing for direct svccfg customisations, to avoid
patching woes... I think it's best I hear what you guys think!
cheers,
Brendan
[Sydney, Australia]
