On 18/04/2006, at 1:22 AM, Brendan Gregg wrote: > 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, > <snip>
> <snip> > 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. I agree, although it could be argued that "site" should be for truly site-developed manifests, while ones that ship with 3rd party apps should go elsewhere > 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 You know you can in effect combine these last two steps with xmllint --valid --noout site/brendan.xml don't you? The error messages are more helpful than svccfg validate, too. > 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 > > <snip proposal for editing manifests then re-importing rather than > using svccfg> > > 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] This is one of my pet peeves. If Solaris is going to start shipping human-editable xml config files there we need xml tools of the same or better level than those we have for more traditional text files. XML diff seems a notable example. (it's possible to have textual changes to an xml file that are not significant to xml). > 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] > > <snip> > > 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. Something like this could leverage the existing smf upgrade code. See http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/svc/ milestone/manifest-import#497 Since it runs at manifest import time it could help with #5 below > 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. > > You don't mention snapshots (which you get with svccfg). Also, I'm not that happy with having system identity defining files in /var.
