Quoth David Finberg on Fri, May 04, 2007 at 09:29:03AM -0400: > On Thu, 3 May 2007, David Bustos wrote: > >The project will introduce new options and subcommands to the existing > >SMF commands. Attempts to use them on SMF systems preceding the project > >will fail. > > Right, but will there be an way to determine if the syntax is bad, or the > command is failing for another reason? If svccfg audit foo returns 1 > when both verify is unsupported and when foo is not the current state, > that's hard to tell apart.
The SMF tools fail with exit code 2 on syntax errors. > Consider something like the Solaris Security Toolkit. After Enhanced > Profiles, we could just write a new profile, and install it on the system, > and audit against it, etc. Before, we have more complicated logic to > disable services, check their state, etc. When we are running, it would > be nice to be able to tell which logic we should use, rather than trying > to hardcode the logic choice to a Solaris release and worry about > backporting later. I see what you're saying, but I don't like the idea of a "svccfg features" command which prints a bunch of keywords that correspond to features. If there's no better way, then I suppose we'll have to, but I'd like to avoid it if possible. > If there is a new command to install profiles, then that would be fine, > since I assume it's name would be at least evolving. But if it's all done > with new suboptions that's hard to distinguish from a script typically. I don't anticipate needing a separate command. Some of the existing profiles will be replaced, though, so you could test for the new paths. David
