System Configuration Project

System Configuration Project

What's New

• New System Configuration Framework completed in build 171.

Project Overview

Background

The legacy Solaris installer uses the system configuration parameters specified by the user to configure the system in the installation environment and then copies the configured files to the installed disk (alternate root).  This method puts the responsibility on the installer to know how to configure each of the software components where configuration has been specified, and the installer must also track of all the changes happening with the configuration files. This results in a model where what is able to be configured is highly restricted by the installer capabilities. 

In the OpenSolaris installation architecture, one of the design principles we're aiming to adhere to is the separation of installation and configuration.  The installer will be responsible only for the installation of the software, and configuration will be the responsibility of the software components themselves.  This approach eases the requirement on the installer to have specific knowledge on each configuration piece, or even inclusion of the software components in the installation environment. The software components will not be required to provide a special interface to configure their software in an alternate root either. Ideally, configuration happens in the environment of the installed system, where the software will be actually running.

Problem Statement

Provide a method for setting system configuration parameters on an installed system that is extensible, easy to use, consistent, and produces repeatable results.

Scope

System Configuration project will cover following scenarios:

• Automated Installer
• Interactive installers (GUI, Text Installer)
• Zones
• Preinstalled images
• Replication

In order to avoid design and code duplication, cooperation with other teams is planned to address requirements of particular scenario.

Automated Installer

Requirements

• mechanism for applying system configuration has to be extensible - support for new parameter does not require changes in the installer
• allow for syntactic and semantic validation of provided parameters
• allow for dynamic determination of parameters on client side
• Initially, following set of configuration parameters will be supported:
  • user account, root password
  • network configuration (hostname, static IP, DNS naming service)
  • timezone
  • keyboard layout
  • locale
  • terminal type

Constraints

Target system will be configured by applying SMF profile which will define set of SMF properties carrying information about desired system configuration. Configuration will take effect during first boot when SMF properties will be processed by related SMF services.

Solution

For purposes of Automated Installer, configuration of system to be installed will be specified in form of set of configuration parameters provided in file called System Configuration Manifest. Automated Installer will obtain set of system configuration parameters from System Configuration Manifest, install OpenSolaris on a system and setup the system with those parameters.
Since all system configuration parameters will be in form of SMF properties and system configuration will be carried out by applying appropriate SMF profile to the installed system, it is being proposed that format of SC manifest matches SMF profile to be applied to the installed system. 

That will allow:

• Automated Installer to directly use System Configuration manifest as SMF profile to be applied to target system when feasible. Minimum interaction would be needed - e.g. manifest would be only syntactically validated.
• to introduce support for new configuration parameters without need to modify the installer
• if desired, to involve Automated Installer (by designing necessary plug-ins) in processing System Configuration manifest for purposes of
  • semantic validation
  • dynamic modification of desired configuration parameters

Based on proposed solution, System Configuration manifest will have following characteristics:

• it will be provided in form of one XML DTD document containing all system configuration parameters
• it will validate against following schema: /usr/share/lib/xml/dtd/service_bundle.dtd.1
• all system configuration properties will be in format of SMF properties for one of SMF services delivered to target system during installation process

Dependencies

Network configuration

• ENH 6923163 - Automated Install requires mechanism for configuring static IP addresses - integrated into build 146
• ENH 6923168 - Automated Install requires a mechanism for configuring name services for clients - integrated into build 146

Keyboard layout configuration

• ENH 6944480 - move keyboard configuration from /etc/default/kbd to SMF - integrated into build 145

Naming services

• ENH 6959149 - Move Name Service configuration to SMF

Early Manifest Import

Early Manifest Import project - integrated into build 137

Resources

Documentation

• Getting started with new SMF based System Configuration manifest

Design specifications

• System Configuration SMF Service - design specification v0.4
• System Configuration Interactive Tool - design specification v0.3
• Moving nodename(4) and defaultdomain(4) configuration to svc:/system/identity smf(5) properties - design specification v0.4
• System Unconfiguration Design Doc - design specification v0.5
• System Configuration profiles support in AI - design specification

Design notes

Research on moving /etc/default/init to SMF properties
Research on moving nodename(4) to SMF property
Legacy sysidtool(1M) framework - how it works

PSARCs

• PSARC 2007/393 converting /etc/default/{nfs,autofs} to SMF properties (integrated into build 147)
• PSARC 2009/306 Brussels II - ipadm and libipadm
• PSARC 2010/152 SMF Site Profile Directory (integrated into build 141)
• PSARC 2010/157 SMF networking type extensions (integrated into build 141)
• PSARC 2010/164 interfaces for basic install network configuration (integrated into build 146)
• PSARC 2010/183 Kernel Keyboard Configuration in SMF (integrated into build 145)
• PSARC 2010/222 Relaxed Type Requirements for SMF Profiles (integrated into build 143)
• PSARC 2010/223 System Configuration -- nodename (integrated into build 153)

Meeting minutes

02/22/2010 - zones requirements discussed
03/01/2010 - zones and process of unconfiguration

Tools

• scconv.ksh - Korn shell script for converting old format of System Configuration manifest to the new one (introduced in build 144)
• zone-install-sc.ksh - Korn shell script for configuring freshly installed non-global zone in non-interactive way by means of new System Configuration framework
• zone-scit.ksh - Korn shell script for configuring freshly installed non-global zone in interactive way by means of new System Configuration framework

Templates for System Configuration manifests

• static_network.xml - static network configuration

Related bugs

• 4585 - Automated Installer needs support for setting keyboard layout from AI manifest
• 5549 - sysidtool(1M) and sys-unconfig(1M) should be removed from OpenSolaris livecd and installer
• 7850 - RFE would like support for static network instead of nwam config
• 10667 - AI need to have LOCALE support
• 10781 - RFE - AI Needs to Support DNS Name Service Configuration for Clients 
• 10783 - RFE - AI Needs an advanced client manifest mechanism
• 13737 - Automated Installer needs support for setting terminal type from AI manifest
• 14669 - B132 - sysidcfg does not recognize kbd layouts
• 15678 - /etc/default/kbd is to be obsoleted by 6944480, installers need to be accommodated
• 15723 - Teach AI to use new SMF based System Configuration framework for configuring user and root accounts
• 6998550 - AI needs a way to specify NIS or LDAP name service
• 6998974 - Deliver System Configuration Interactive Tool
• 7003817 - New system unconfiguration

Related Projects

• Brussels - unified network link configuration
• Enhanced SMF Profiles
• ipkg(5) branded zones(5)
• Visual Panels

TBE (To Be Explored)

There are a lot of areas related to system configuration which will have to be explored. The idea is to capture those areas along with comments/thoughts/ideas why people think particular area should be addressed and how the problem might be approached. The vision is that the issues captured here will be transmuted in design specifications once the requirements are fully identified and the areas carefully explored.

Scalability of non-interactive configuration

In case of non-interactive system configuration scenario, configuration parameters are specified in form of XML file called System Configuration Manifest. As some of parameters might be unique for each client to be deployed (e.g. nodename), in current implementation we would need to create and maintain separate System Configuration Manifest for each client. That does not seem practical and maintainable in enterprise environment with large number of clients.
There are couple of suggestions to be investigated.

• If we allow applying more than one profile, we could separate common settings from client specific configuration. The installers would then deliver a directory of profile fragments and let SMF assemble them on boot. The problem here is that whenever one single fragment is changed, all dependent manifests have to be regenerated and re-added.
• SMF services could be taught to obtain particular configuration parameter by querying the appropriate database and dynamically fill it in at the first boot (e.g. nodename).
• At the first opportunity, user could be prompted to manually reconfigure the parameter. For instance, one could set a site-wide initial root password, but pre-expire it, so the password has to be changed on first login.

Protecting sensitive information

As System Configuration manifest might contain sensitive date (encrypted passwords), it has to be assured that they can be accessed only by authorized consumers. As currently there is no authorization step during process of obtaining System Configuration manifests by client, any entity which has access to AI server can downloaded and explore the manifest.

Contacts

Please feel free to share your comments/questions/concerns related to this project on caiman-discuss@opensolaris.org public mailing list