System configuration

A system configuration (SC) in systems engineering defines the computers, processes, and devices that compose the system and its boundary. More generally, the system configuration is the specific definition of the elements that define and/or prescribe what a system is composed of.

Alternatively, the term "system configuration" can be used to relate to a model (declarative) for abstract generalized systems. In this sense, the usage of the configuration information is not tailored to any specific usage, but stands alone as a data set. A properly-configured system avoids resource-conflict problems, and makes it easier to upgrade a system with new equipment.

Sample configuration

The following is a basic SC XML System Configuration:

 <system_configuration>
   <site name="MyHouse" >
     <hosts>
       <host_ref name="host1"/>
     </hosts>
   </site>
   <group name="mysql" gid="500"/>
   <user name="mysql" uid="500">
     <groups>
       <group_ref name="mysql"/>
     </groups>
   </user>
   <host name="host1" >
     <users>
       <user_ref name="mysql">
     </users>
     <profiles>
       <profile_ref name="workstation"/>
     </profiles>
   </host>
   <profile name="workstation" >
     <components>
       <component_ref name="user-setup" >
       <component_ref name="mysql-db" >
     </components>
   </profile>
   <component name="user-setup">
   </component>
   <component name="mysql-db">
   </component>
 </system_configuration>

Description: This provides information about a single "site" (MyHouse) and specifies that there is one host with user-setup and mysql-db components. The host must have an account on it for a user named mysql, with appropriate parameters. Notice that the configuration schema requires no XML tags that are Windows- or UNIX-specific. It simply presents data as standalone information – with no pretense for how the data is to be used.

This is the hallmark for a good system configuration model.

Further extensions

The above model can be extended. For example, the user could have more attributes like "preferences" and "password". The components could depend on other components. Properties can be defined that are passed into sub-elements. The extensions can be endless (WATCHOUT: complexity) and must be managed and well-thought-out to prevent "breaking" the idea of the system configuration.

Usage

The usage for the model in practical terms falls into several categories: documentation, deployment & operations.

Documentation

One use of the configuration is to simply record what a system is. This documentation could in turn become quite extensive, thus complicating the data model. It is important to distinguish between configuration data and descriptive data. Of course comments can be applied at any level, even in most tools, however the bloating of the data can reduce its usefulness. For example, the system configuration is not a place to record historical changes, or descriptions of design and intent for the various elements. The configuration data is simply to be "what it is" or "what we want it to be", hAS AN UPLOAD for file for ok.

Deployment

Deployment involves interpreting a configuration data set and acting on that data to realize the configure the system accordingly. This may simply be a validation of what's there to confirm that the configuration is in effect.

Examples include a Perl library launched from the command line to read the configuration and begin launching processes on the local or remote hosts to install components. Also while the system is running, there may be a SystemConfiguration service that provides an interface (i.e. CORBA IDL interfaces) for other system applications to use to access the configuration data, and perform deployment-like actions.

Operations

When the system is in operation, there may be uses for the configuration data by specific kinds of services in the system. For example, a Secnager may access the configuration to acquire the MD5 passwords for the user accounts that are allowed to log in to hosts remotely. A system monitor service (see: system monitoring) may use the data to determine "what to monitor" and "how to monitor" the system elements. A PresentationManager might use the data to access menu-items and views based on user access privileges.

References

<system_configuration>

  <site name="MyHouse" >
    <hosts>
      <host_ref name="host1"/>
    </hosts>
  </site>
  <group name="mysql" gid="500"/>
  <user name="mysql" uid="500">
    <groups>
      <group_ref name="mysql"/>
    </groups>
  </user>
  <host name="host1" >
    <users>
      <user_ref name="mysql">
    </users>
    <profiles>
      <profile_ref name="workstation"/>
    </profiles>
  </host>
  <profile name="workstation" >
    <components>
      <component_ref name="user-setup" >
      <component_ref name="mysql-db" >
    </components>
  </profile>
  <component name="user-setup">
  </component>
  <component name="mysql-db">
  </component>
</system_configuration>