James Carlson wrote: > I've been looking through the various discussions in NWAM and > Clearview related to storing parameters in SMF, and there's one bit of > detail that I haven't seen discussed yet. > > The current dladm user interface has a "-R" option for most of the > subcommands that set and show parameters (though, oddly, not all). > This option relies on the fact that, since dladm itself defines the > private file formats, it can treat them as roughly "Committed Private" > -- meaning that they don't change incompatibly in format between > versions, and reading and writing an alternate root is "safe." > > This isn't true for SMF. There's no "-R" for svccfg, and you have to > be running the same patch level of Solaris to read or write the > repository. There's no guarantee of stability of the database, other > than that the system will somehow upgrade itself -- presumably doing a > conversion after reboot. > > So, how will that "-R" feature (intended for jumpstart and upgrade > scenarios, I'd assume) be accomodated in this new world? > > good question! the SMF repository is unavailable during upgrade/jumpstart install, so modification of SMF-stored data directly at that time isn't feasible i believe.
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. 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. > 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? > 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. alan
