Managing Application Configuration Data with CIM

Managing Application Configuration Data with CIM Viktor Mihajlovski <mihajlov@de.ibm.com> IBM Linux Technology Center, Systems Management Introduction The configuration of software, regardless whether it falls into the category of system software, middleware or application software, is a major contributor to the complexity in large enterprise environments. The root of the problem is - as nearly always - missing interoperability caused by diversity. The diversity encompasses various aspects like configuration data location and format and also semantical information. In order to change the configuration of a system or some software it is necessary to know where to look for the configuration data and what to change in order to achieve the desired result. Sometimes one software component needs another software component to be configured in a particular way which could require a different skill profile. Finally, different versions of a particular software (with differing capabilities and configuration options) might coexist in a networked environment. Systems like Windows feature a common configuration repository (Registry, Active Directory) that solves the location and format issue. That helps a lot for certain situations but is not sufficient as there's still no semantical information available (other than perhaps some written documentation). Another (maybe more severe) problem is that this requires "legacy" applications to rewrite their configuration component to make use of the central configuration repository. Especially multi-platform components (like Apache HTTPD, Mozilla) don't do that. They feature their own (usually complex) configuration file instead (at least as long as there's no multi-platform configuration repository). There are good reasons to propose CIM as an approach to tackle this problem. First of all it offers the conceptual underpinning to model the configuration data and second it leads the way to implementations (based on WBEM and CIMOMs) enabling for a unique way to access this data. The clear advantage of WBEM based configuration management is that it's not proprietary, that it's platform-independent and does not require legacy or multi-platform applications to forsake their configuration data. While the CIM classes dealing with configuration do not yet really solve the semantical issues (through common data models for special categories of software) they sure do prepare the ground for it, as we will outline later in this document. Settings and Configurations We strongly recommend that you read the DMTF White paper on the CIM Core Model, especially the chapter about Settings and Configurations (Chapter 16) to have a certain understanding of the concepts presented therein. As the prefix CIM_ is a little bit bulky, it is regularly omitted for the classes CIM_Setting, CIM_Configuration and CIM_Service. Settings in the CIM Core Model designate configurable items for a CIM_ManagedElement (the root class for nearly all CIM classes - including Setting). A setting usually contains (and groups) properties with close relationship. IP address and network mask would be a April 9, 2002 Page 1 of 6

meaningful setting of a network adapter, as they are closely tied together. Configurations are used to aggregate multiple Settings for a CIM_ManagedElement. Settings and Configurations can be associated to all derivations of CIM_ManagedElement. We've mentioned the network adapter as an example for Logical Device. While not being principally different, we are more interested in software configuration (well, device configuration is in fact device driver configuration which could be considered as a form of software). Therefore, we need to identify the CIM class to which (Software) Configuration and Settings apply. The class we have chosen is Service, which might be a little surprising, so we will explain the rationale behind it. Service as the Configuration Owner The Service class is denoted as the class representing the information needed to manage function in CIM models. This notion makes it more suitable for anchoring configuration data than CIM_SoftwareElement from the Application Model, which might be another class that could be considered. However, the Software Element is designed to support deployment rather than configuration, so it deals with more concrete items like files making up a package and requirements against other Software Elements (existence, version). Examples of Software Elements would be RPMs or Installshield Packages. Another difficulty with Software Elements would be that you can have multiple logical functional instances based on one installation (e.g., run multiple HTTP servers on one system). Usually there's a connection between a Software Element and a Service, i.e. the executables needed by (or implementing) the function. It is represented by the association class CIM_SoftwareElementServiceImplementation. Note also that Services do not only describe things like daemons or servers (although these will be the most common to deal with in large installations): it's really about function and each e-mail client or word processing program provides - function. The Model and How to Get There Before we can make configuration data accessible via a CIMOM and appropriate instrumentation (more about that later), we have to conceive a data model for the configuration data based on the CIM Model. Not necessarily a surprise, this will possibly be the hardest part. Mostly, because there are no predefined schemas, which means that we will have to figure out exactly what is to be configured and how it's done. Further, we should keep in mind that a very important aspect of CIM is interoperability, which makes modeling even harder, as it may require some additional abstraction. We will put this issue aside for now, and pick it up later. As you have probably read in the DMTF White paper on the Core Model, Settings do not represent the current operational data of a Service (in this case). Those things (as far as being a matter of interest and being observable) are best represented by properties in the Service itself. Settings are representing items from the configuration repository (e.g., config file) of the application and usually it is necessary to (re)start (or notify) the Service in order to apply the Settings, i.e. make them effective. So one possible approach - although not particularly helpful - would be to map all the configuration items in (let's say) a config file to Setting instances, or to properties of one single Setting instance. This would work for the most simple cases only, since many configuration files tend to have structure or hierarchy (some even recursive and of arbitrary depth) and a variable number of distinct, similar or equal items. However, all the basics and composition mechanism are there to design a hierarchical data model for Application Configuration. Settings can be aggregated via Configurations and April 9, 2002 Page 2 of 6

Configurations can be nested from other Configurations. Therefore, the modeling task will be mainly to find out a suitable mapping. As always an example will help best to illustrate this. Note: the section below is still incomplete and adding a few pictures will help. This is a document still in progress! Apache Configuration Configuring the Apache web server can be quite a challenge. There's a high number (>200) of so-called directives to define the behavior of the HTTP daemon, some of them interdependent. This example is also interesting in that, even if configuration tools are used by the administrator, it doesn't relieve her or him from understanding the way Apache is working and how the configuration file is being interpreted. This is also true for the modeler: in order to come up with a semantically correct data model it is necessary to understand the operational concepts. This document is not an Apache configuration tutorial (nor is it intended to be one) therefore it will be incomplete and oversimplified in many things. We hope nevertheless it will serve the purpose to shed some light on the "black art of modeling". One property of configuration directives is the context in which they appear and for which they apply. The available contexts are Server, Virtual host, Directory and Location, where the context can be nested in this order (e.g., Directory can be specified in Virtual Host and Server, but not in Location). Further, directives are being implemented by modules, that can either be statically bound to the server executable or be loaded dynamically if needed. There's a one-to-one relationship between a directive and the implementing module. The core module is mandatory and required to be present. Finally, directives can be grouped logically by functional area, thus identifying possibly meaningful Setting classes. Taking this all together, Settings have to contain only properties for directives that are implemented by the same module are valid in the same context are functionally related (a matter of taste sometimes) Context Scoping Usually the directives allowed for an inner context can be also specified for the enclosing one (with few exceptions). These directives are inherited by (or propagated to) the inner directives, if not specified or overridden there. Server Configuration The outermost context is the Server context. It is represented by the Apache_HTTPServerConfiguration class and aggregates all the Settings for a Server (basically the global settings for the daemon). Currently there are only two Setting classes available. Apache_HTTPModule defining whether a module is present and active and Apache_HTTPServerSetting containing properties for all the directives valid for the Server context and implemented by the Core module. Virtual Host The Virtual Host context is used to introduce a sub-server listening to a separate address. Modeling is not yet complete for virtual hosts. Directory/Location These contexts are used to configure the (virtual) server behavior on a per directory/file name base. Not yet completed. Modules April 9, 2002 Page 3 of 6

Each Apache module is represented by an instance of Apache_HTTPModule. Other Settings can depend on the existence of certain Modules. Nearly all of the base settings depend on the Core module. BTW: This could be probably be modeled by a special CIM_Dependency association. We don't do that currently as we would rather model the fact that certain Setting types are dependent on a Module type. The pure instance dependency seems to be rather pointless for real world scenarios. Implementing the Model Once the configuration model has been completed, it will be necessary to write instrumentation code (in form of CIMOM providers) implementing the data model by mapping the configuration repository data to and from the CIM objects. Unless the repository is accessible via a nice API, this means parsing (or scanning) configuration files and rewriting them upon configuration changes. Depending on the format and complexity of the configuration files, this will be more or less effort and the use of tools like generated parsers or scanners might be beneficial, although they usually do not help when it comes to file updates. Further, it will be necessary to transform and map the parsed/scanned data to instances of Settings and Configurations. Using conventional technology, this will have to be handcrafted too. In the next section we discuss a more advanced approach for (complex) configuration file access. Using the Parser/Modifier to Access Configuration Files Many of the configuration files have simple syntactical structures that can be expressed via regular expressions or context free grammars, making them suitable to be processed by a generated scanner or parser. The syntax description for a configuration file can easily be extended to add support for syntactical correct modification of the respective text file 1 to the parser. A parser/modifier generated from a syntactical description like an annotated context free grammar transforms the textual representation of the configuration file into an internal abstract syntax tree (AST). This AST can be accessed by a program (e.g., a generic CIMOM provider for text file access) and offers functions to navigate and modify the tree structure. The modified AST can then be transformed into text and written back to the configuration file. In order to exploit a parser/modifier it is necessary to have mapping rules between nodes in the AST and instances and properties in a CIM Schema. Once these mapping rules are established, a generic CIMOM provider can be written to perform the actual mapping by invoking the parser/modifier and by operating upon the AST. The figure below shows how a generic 1 This approach is successfully being used within zos Managed Systems Infrastructure for Setup, where the Java based Parser Generator JavaCC is used for this purpose. April 9, 2002 Page 4 of 6

provider for text file access would work. Generic Provider CIM Instances Parser/Modifier AST config file Mapping Rules The question on how and where to specify the mapping is still open. It could be a part of the syntax description, a separate description format (e.g., XML) or an extension to the Schema (e.g., additional special-purpose qualifiers). Beyond Applications Although being very specifically geared towards, some of the concepts will also apply to the persistent configuration of other system components, namely devices. The real challenge here is that - at least in the Linux area - no standards exist where and how the configuration data for an Ethernet adapter is stored. This is typically defined by the distributor and we can find at least two schemes today (it's probably more). This should however not discourage us, since devices (in contrast to applications) have usually well defined data models, which was the hard part to get (you remember). So it's becoming "only" a question of the providers. With appropriate instrumentation for the respective distributions, it will be possible to manage persistent device configurations regardless of the distribution. That's were the strengths of CIM start to show (if we only had that instrumentation already). Thoughts on Interoperability As we have already mentioned, the CIM models for devices are far more developed and interoperable than those for applications. For instance it is possible to manage a network adapter regardless whether it's Ethernet or Tokenring (e.g., can set the IP address and net mask). This is possible since CIM offers an object-oriented model and thus allows to define generic base classes as well as specialized classes by subclassing. It is obvious that software also falls into categories. If we take the Apache web server as an example we could create a model for it by subclassing from a hypothetical Web Server class (or more precise classes necessary to describe the server and the configuration). April 9, 2002 Page 5 of 6

It is also clear that certain settings are pertinent to all Web Servers, like address, document root directory, etc. Even more advanced features like virtual servers/hosts can be found with other Web Servers. Now, in the absence of more abstract base models for applications what can be done to avoid ending up with a data model that's not interoperable? First of all, we don't have the final answer. Taking into consideration other implementations of software in the given category might help to create the necessary abstractions. Discussions within DMTF work groups seem also to be a reasonable way to get some feedback. April 9, 2002 Page 6 of 6