> From: Casper.Dik at Sun.COM
> Date: Tue, 19 May 2009 10:09:26 +0200
> 
> >We want to configure Solaris for readonly boot using a ZFS snapshot for
> >the boot image.  While this is similar to other uses, we want to make
> >those system files that must be writeable have no persistence beyond
> >reboot; only user data and perhaps /var would retain modifications past
> >a boot.  Those system files that need to be writeable would be
> >instantiated by creation of a root clone at boottime.
> >
> >Persistant reconfiguration would require the creation of a new boot image:
> >    a)  clone the current boot image to create an updateable image,
> >    b)       make modifications to the update clone,
> >    c)       take a snapshot of the update clone, and
> >    d)       designate that snapshot as the replacement bootfs.
> >
> >However, using current mechanisms, updates of SMF-controlled
> >configuration would require a reboot during step b) using the update
> >clone, so that svccfg and svcadm operations could update the SMF
> >repository.  In order to make this boot unnecessary, a natural solution
> >would seem to be to use the functionality currently restricted to the
> >buildtime executables svccfg-native and config-native, perhaps through
> >a svccfg -R option.  Is this a reasonable approach or would this rope
> >be too easily tangled into a noose?
> 
> You modify a different repository by using the following environment 
> variables:
> 
>         SVCCFG_REPOSITORY=$altroot/etc/svc/repository.db
>         SVCCFG_DTD=$altroot/usr/share/lib/xml/dtd/service_bundle.dtd.1
>         export SVCCFG_REPOSITORY SVCCFG_DTD

We're looking for interfaces that an administrator could use.  While
manipulating those environment variable works, it seems inadqequate on
a couple of counts.

    1)  It doesn't appear to be a public interface.  While its use in
        modifying miniroot environments is documented, there's no
        mention of those environment settings in svccfg(1).  Is that
        deliberate, or just overlooked?

    2)  It doesn't extend to svcadm or svcprop.  Users would likewise
        expect to use those commands for their effects in enabling,
        disabling, and querying services in an alternate repository.
        While svccfg could perform the corresponding repository
        manipulations, users would have to translate from the form
        commonly used for direct administration.

> Of course, the svccfg must be compatible with the other environment.

We wouldn't expect that to be an issue, since we'd expect to be
manipulating a clone of the current system.  The question is how to
translate administrator experience with SMF in preparing a new boot
image.

                                -JZ

Reply via email to