G'Day Boyd,
On Tue, 18 Apr 2006, Boyd Adamson wrote:
> On 18/04/2006, at 1:22 AM, Brendan Gregg wrote:
[...]
> > 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
Ok, there is some logic in that that could be argued..
I'm still rather fond of having a single directory containing a delta
from the installed OS. How about,
/var/svc/manifest/site/local
/var/svc/manifest/site/oracle
/var/svc/manifest/site/veritas
...
So a "site/local" directory is for site-developed manifests, and 3rd party
apps can have their own directory.
> > 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.
No, but I do now. cheers! :)
[...]
> > 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).
Do you have any XML tools in mind?
[...]
> > 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
Hmm. they automatically get renamed. A persistant script may do the trick
- but where would we put a persistant script to keep SMF automatically
up-to-date, including after repository rebuild?
I know! /etc/rc3.d !!
/me ducks for cover :)
> > 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).
I only mentioned that they would be cool with a snapshot diff. Eg,
# svccfg
svc:> select system-log:default
svc:/system/system-log:default> diffsnap initial running
<something exciting here>
> Also, I'm not that happy with having system identity defining files
> in /var.
I guess the argument would be that /etc/svc/repository.db is authorative,
and the manifest and profile files are not. However, certainly with my
xml-site-customisations strategy, it makes it _seem_ like the manifest
files are authorative. I'd need to make it clear what was really
happening.
Although, the following quote from docs.sun.com adds a new dimension to
our understanding of this authorative repository.db,
"The repository is distributed among local memory and local
files. SMF is designed so that eventually, service data can be
represented in the network directory service."
I'd like to see network/physical served from a directory server! ;-)
Brendan
