Alan Maguire writes:
> the only approach i can think of is to have -R commands essentially
> "record" the dladm commands invoked using that option, and "replay" them
> in order on first reboot post-upgrade/install, when the repository is
> available. one way of doing this is through appending such commands
> to /var/svc/profile/upgrade - this is a project-private interface so using
> it would require a contract i believe.
OK; I guess that can be made to work somewhat, as long as nobody is
expecting to do any sort of fetch-type operation with -R. (It's
write-only memory.)
> i think that we also need to distinguish between -R alternate root commands
> that occur when the repository is available - e.g. where we'd like to
> modify
> the datalink configuration in a whole-root nonglobal zone from the global
> zone - and when it is not (install/upgrade). in the former case, i suppose
> we'd need to set the alternate root for the (available) repository, so that
> operations are carried out on the appropriate repository.
That one's easy to simplify: for security reasons, we don't support
using the "-R" option in a command to refer to any non-global zone
(whole root or otherwise).
The problem is that, from the point of view of the global zone, a
non-global zone has been booted at least once has effectively
arbitrary and non-trustworthy contents. For instance, someone could
replace files in /etc with absolute ("/etc/foo") symlinks. If you
refer to them without being _inside_ the non-global zone, you'll
actually be modifying the global zone's files.
I think modifying the contents of a zone that's been booted at least
once means entering the zone.
> > The reason I ask is that I'm looking into how bridging should fit into
> > this configuration scheme, and I'm torn between the better
> > functionality of the plain text files currently used by dladm and the
> > SMF-based design it looks like Clearview and NWAM are headed towards.
> >
> >
> do you have any specifics on the data you'll be storing? is it
> per-datalink? i'm also wondering if you require multivalued
> properties, and if so is ordering of those values important?
I have some per-datalink information, such as default vlan id, but
also some that's per-bridge-instance, such as STP configuration.
There's some information that could go either way, such as assignment
of links to bridges, but that I'm leaning towards having as attributes
of bridges rather than as attributes of links.
("Bridge instances" are new objects in this area.)
> > Should I assume that the previously committed "-R" feature is going
> > away?
> >
> >
> hmm, i think we'll still need to support jumpstart-driven datalink
> configuration.
Probably so ... which is why I asked. ;-}
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
