* Sowmini Varadhan <Sowmini.Varadhan at sun.com> [2009-10-01 01:51]: > > http://opensolaris.org/os/project/caiman/auto_install/system_config_design.txt. > > > > Please review and give your feedback. > > > > Thanks, > > Sundar > > Hi, > > thanks for sharing this doc- I'm cc-int networking-discuss, where we > are also looking at various improvements to Configuration..some > questions whose answers are not clear to me from reading the document > above.. > > Regarding option (c) which seems to be the favored approach- > most of solaris cannot be configured using smf today, e.g., things like > user account, root passwd etc are not smf properties, but rather, they > are stored in flat files. Taking the user account as an example, > one adds a new user to the live system using useradd(1m) and this results > in modifications to several files in /etc. > > How does the proposed design envision this happening with smf? passwd(4), and the other tables accessed via the name service switch, aren't likely analogous to the configuration you're considering. Name service tables have different performance characteristics than system administrative configuration, in addition to the wider variety of backends potentially involved. For these tables, initial configuration is a special case affecting only a few reserved entries.
A more relevant example might be something like coreadm(1M) and its service, svc:/system/coreadm. This service moved from a private configuration file to a property group earlier in the development release. > Moreover, there's the question of input validation. An application like > useradd(1m) is capable of doing semantic validation of the input data > that is specific to the task being performed. How can a general framework > like SMF provide the same level of input validation? General restrictions on property values and semantics is covered by PSARC/2008/350, SMF Template Extensions. Integrated in Build 102. Delivery of property updates in a bundled form--suitable for an automated installation context, for instance--is covered by PSARC/2009/371, Allow Property Modification in SMF profiles. Integrated in Build 119. Avoiding smf(5) in administrative configuration means that a project will have to provide RBAC integration, means of offline configuration modification, access and modification APIs, and present costs to teams and customers attempting to layer management software (like an installer, in this instance). - Stephen
