James Carlson wrote:
> 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.)
>
>
good point.
>> 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.
>
>
understood. are there other edge cases where -R <altroot> might
be used in a non-?install/upgrade? environment i wonder? i can't
think of any offhand.
>>> 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.)
>
so there would be an SMF instance for each bridge instance?
one thing we will have to think about is the effects of link
rename - if the link name is a property of the bridge instance,
we will have to ensure that renames are propogated to bridge
instances also (unless we use linkids to identify associated
datalinks, but i believe the intent is to expose linkids as little
as possible). thanks!
alan
