On Tue, Jul 31, 2007 at 11:15:32AM -0700, Michael Shapiro wrote: > > > Tomas Zeman wrote: > > > Hi Mike, > > > > > > On Sun, Jul 29, 2007 at 06:33:59PM -0700, Michael Shapiro wrote: > > >> The top-level question to ask is whether plug-in configuration is (a) > > >> intended > > >> as tunables for administrators or (b) really only for developers or for > > >> the > > >> "I'm a Solaris OEM" level of customization. For example, for fmd(1M), I > > >> have > > >> a set of plug-ins, but the architecture is entirely oriented around (b). > > >> Therefore, for fmd, plug-in delivery and config is handled entirely > > >> outside SMF. > > >> If your answer is more (a), then property groups is likely the best > > >> approach > > >> because you have to control the plug-in namespace anyway, so you can just > > >> mirror that namespace in the property group layout. > > > > > > Yes, plugin configuration is (a), intended for administrators. I expect > > > they'll > > > be enabling/disabling plugins and changing their configuration as per site > > > policy. > > > > and eventually 3rd party plugins are expected to be developed and > > shipped separately to Solaris as well. Once we open up the plugin API. > > Based on what you've said, I'd suggest defining a module namespace with > a 1:1 mapping to the property group namespace, and some means of publishing > the properties into SMF as part of the module delivery. One design choice
Yes, that's the intention: each plugin has its own property group of type SUNW,audit_plugin (allowing 3rd party plugins). > here is whether you permit developer-defined properties, which would require > you to do something like deliver an XML fragment (<property_group> decls) > with each module that you slurp in to set up the SMF groups, or whether you > have a standard set of properties defined by the framework. I'd encourage As for now, all plugins will have some properties common (like eg. 'enabled' so that an admin can switch on/off the plugin as needed). Unfortunately each plugin has different configuration properties and these could be handled in either way: - all of them in a unified list called 'attributes' (like in the initial proposal) - or having them eg. p_ prefix recognized by the auditd passing the values to each plugin upon initialization While the first approach unifies properties for each plugin, the second seems more logical and easier to administer. Eg: svccfg -s ... setprop binfile/attributes = 'p_minfree=20' as opposed to simpler and more intuitive: svccfg -s ... setprop binfile/p_minfree = 20 > you to limit the amount you expose to administrators initially. The design > center should be that people can enable auditing without setting knobs. -tomas