Verifying CIM Models of Apache Web-Server Congurations

Carsten Sinz Amir Khosravizadeh Wolfgang Kuchlin

Symbolic Computation Group, WSI for Computer Science
University of Tubingen, Germany
sinz,kuechlin
@informatik.uni-tuebingen.de
Abstract
We show how conguration properties of the Apache
Web-server can be formally veried, so that an installation
is safe with respect to both universal and site specic local constraints. Our approach starts from an existing semiformal component model of the Web-server in the Common
Information Model (CIM) standard. Hence our approach is
applicable also to the verication of other systems for which
a CIM model exists.

1. Introduction
For todays complex software systems, development
does not end at the manufacturers side but extends to the
clients side, because standard software products must frequently be congured after delivery to meet particular needs
or policies. Hence, software verication and validation are
no longer conned to the traditional software development
process but must extend to the conguration phase at the
client site. For the particular example treated in this paper,
a formal verication of a Web-server can not be considered
complete if it does not extend to particular installations, i.e.
congurations, of the product. A awed Web-server conguration may cause malfunctions just as if the software itself
were awed, and may constitute a serious security breach,
even if the product as such were perfect.
Thus, the problem of verifying and validating particular
system congurations is at least as important as that of traditional software verication. It is even more important in the
sense that, in general, product (re-)conguration by the customer occurs much more frequently than product completion by the manufacturer, and because traditional software
quality assurance methods hardly extend to the conguration phase at the clients site. For the Apache Web-server
the Netcraft survey (http://www.netcraft.com/survey) has
determined over 13,000,000 installations as of July 2003,
all of which have been congured individually to meet each
sites demands.

Proceedings of the Third International Conference On Quality Software (QSIC03)

0-7695-2015-4/03 $ 17.00 2003 IEEE

Viktor Mihajlovski
Linux Technology Center (LTC)
IBM Lab. Boblingen, Germany
[email protected]

In this paper we attempt a rst step towards an ideal scenario where a congurable software product is delivered together with an expert system containing conguration constraints, such that, based on formal methods, the client can
check a concrete conguration against the manufacturers set of universal formal conguration constraints;
set up site specic local conguration constraints that
can be checked automatically;
suggest possible actions of repair to bring a awed installation back into compliance with the established
constraints;
contain a constraint editor which helps both manufacturer and client in setting up non-contradictory constraints which are actually satisable.

The advantages of building on formal methods include

that constraints can be concisely and precisely formulated
and represented, that there are precise notions of when constraints are actually satised, that highly tuned implementations of general purpose reasoning methods such as Boolean
satisability checking can be employed, and that abstract
high-level reasoning methods such as rst order resolution
are available to reason about the consistency of constraints
independent of concrete congurations.
However, it is not easy to bring formal methods to bear
on practical application problems, because usually a signicant gap must be bridged between the abstract formal
method and the concrete application [16]. In particular, a
formal model of the application (a system theory [17]) must
be constructed, the constraints must be formulated as theorems of the system theory, and efcient reasoning methods
must exist to formally prove the theorems. For something
as complex as the Apache Web-server, building the system
theory can be a daunting task in itself because it requires
intimate knowledge of both the application and of formal
logic. Moreover, the system theory must be kept consistent
with a continuously changing application, because other-

wise the theorems which are proved hold only of the model
and not of the real application.
In our previous work, we could successfully bridge the
formalization gap in two applications. One is an industrial
information system used for the conguration of motor cars
[10]. There, propositional logic formulae are used in rules
that control order modication and checking. The other was
the verication of an expert system that is part of a larger
system management application [15, 16]. This expert system contains situation-action rules which we modeled using
PDL (Propositional Dynamic Logic, [8]).
For our present work, an important part of our success
is due to the use of a semi-formal intermediate model of
the Apache Web-server formulated in terms of the Common Information Model (CIM) standard [3]. Starting from
the CIM model of Apache, it was feasible to build a faithful formal model of constraints and to feed real system values via CIM-based software into the variables of our constraints formulae. From a practical point of view, the existence of CIM and its usefulness outside of formal verication is extremely important, because industry hardly ever
builds abstract models for formal verication purposes only.
In the case of the CIM standard, it has been developed and
is being used to provide abstract system management interfaces to complex systems. A CIM interface presents an
object-oriented view of the underlying system and provides
abstract interfaces to retrieve and manipulate conguration
data. Hence, the system manufacturer maintains a faithful
CIM model of the implemented system independent of any
formal verication, because it greatly aids in investigating
and manipulating the conguration of a system without resorting to implementation details.
It is the core of our approach to hook into the CIM model
and start the formal modeling from there. Using CIM software, we can feed real system values into our abstract constraints sets and we can even attempt to repair a conguration under the control of our expert system. Moreover, since
our methodology is built on CIM, our work is not particular
to the Apache Web-server but can be applied in principle to
other systems for which a CIM model exists.

2. Common Information Model (CIM)

CIM is an object-oriented data model for systemmanagement purposes that aims at unifying several specialpurpose data models (such as DMI, SNMP, CMIP) into a
single consistent model, and creating a general framework
for construction of truly interoperable management applications. It was designed in the late 90s as an industry-wide
standard and is maintained by the Distributed Management
Task Force (DTMF), of which all major soft- and hardware
manufacturers are members. The goal is to provide a conceptual view of all (physical and logical) components of a

Proceedings of the Third International Conference On Quality Software (QSIC03)

0-7695-2015-4/03 $ 17.00 2003 IEEE

system, regardless of manufacturer, architecture, or operating system. As an information model, CIM focuses on
standardizing data-semantics and uniform interfaces, and is
independent of any encoding and protocol considerations.
The Web Based Enterprise Management (WBEM) Initiative
is dening additional standards for CIM implementation interoperability (like operational semantics and communication protocols).
Any hardware or software system component is called a
managed element and is represented as an instance of a CIM
class. Instances contain properties (name/value pairs) describing units of data. All properties are accessible through
uniform getter/setter-operations. Some of the properties
may be declared as key properties, with the intended meaning that each CIM object is uniquely identiable among its
other class members by these properties.
A collection of class denitions that describe managed
elements (in a particular environment) is called a Schema.
Schemas have a framework character and are designed to be
extensible. CIM Schemas are represented by UML (Unied Modeling Language) Diagrams, or MOF les. MOF
(Managed Object Format) is a declarative language similar
to CORBAs IDL (Interface Denition Language). All CIM
Schemas have to satisfy special restrictions given by the
CIM Meta-Schema. The most signicant restriction is the
use of association classes to model relationships between
objects. Thereby, composition or any kind of reference
within a class is strictly avoided, thus preventing anomalies
caused by complex class relations. Aggregations are just
special association classes. Most of the association classes
of the CIM core are abstract and thus have to be rened.
CIM Schemas belong to one of the levels Core Model,
Common Model, and Extension, depending on their level
of specicity: the Core Model contains only a small number of very general classes as an abstract description of
components and relationships that are found in most environments. These classes are inherited by the more specic classes in the Common Model that includes a series of
domain-specic, but platform-independent classes like System and Network. The most specic classes are gathered in
Extension Schemas derived from the Common Model. Sophisticated design patterns like the Composite Pattern [7]
are used in all layers. A main aspect in designing CIM
Schemas is their real world usability, i.e. the completeness
with respect to the use case scenarios.
The concrete information of the application is gathered
by a set of provider applications and delivered to a CIM
Object Manager (CIMOM), where it can then be accessed
and modied by client applications communicating with the
CIMOM using standardized XML-mappings [4], and utilizing HTTP as transport protocol.
The CIM classes relevant for our work are the Conguration and the Setting classes together with their associations,

as dened by the CIM Core Schema. While there are already some small-scale examples in the literature of device
conguration management using CIM, there has not been
any real software example yet. The reason for this might
be that real software congurations possess a considerably
larger number of options and parameters, and therefore give
rise to a much more complex CIM modeling effort (see the
next section for an example).
The work presented in this paper results from a collaboration of our research group at the University of
Tubingen with the IBM Linux Technology Center (LTC)
Systems Management Group located at the IBM laboratory at Boblingen, Germany, which has developed the CIM
model for (part of) the Apache Web-server conguration.
is maintaining In the Open Source Project SBLIM the IBM
LTC provides CIM models and instrumentation for Linux
Systems Management [9].

3. Apache Web-Server Conguration

3.1. Apache Conguration Basics
A device driver (e.g. for a printer) may have a handful
of parameters specifying some options (paper format, resolution, etc). Highly developed software is much more exible. In an Apache conguration le there can be more than
200 different so-called directives. A directive is the Apache
synonym for the textual representation of a conguration
option. The Apache Web-server is designed as a modular
program, and can thus be extended by about 40 different
modules, each of them providing additional conguration
options or directives. For any modules directives to get
activated, the related module has to be loaded. Moreover,
some modules and directives are obsolete and should not be
used anymore, e.g. for security reasons. The complexity
of the conguration process of the Apache Web-server is
also reected by the large number of books about this Webserver (see, e.g. [11]), and the considerable portion that
these books spend on conguration issues and the related
question of security.
The multiplicity of options and the evolutionary character of the application also result in complex interdependencies between the options: Apache allows for running several Virtual Hosts on the same server, which allows, e.g.,
running Web-servers for multiple companies on the same
machine. Each of them may (or must) have its own Document Root (the place where the Web pages and other content
is stored), its own (Virtual) Address and Port (to allow distinct access to each virtual host), and other resources and
properties (e.g. log les).
The document root gives a directory in the le system,
under which the document tree is stored. Any directory
inside a document tree (i.e., any directory potentially vis-

Proceedings of the Third International Conference On Quality Software (QSIC03)

0-7695-2015-4/03 $ 17.00 2003 IEEE

ible to the outside world) may contain an .htaccess le in

which the directorys owner species access limitations to
that directory and its subdirectories as well as some indexing and representation policies. To this purpose, .htaccessles contain additional directives. These may override the
general policies specied in the main conguration le by
the system administrator, or other directives in some parent
directory. For security reasons and to prevent miscongurations, an additional set of directives in the servers main
conguration can specify which directives are allowed in
which .htaccess-les. Now, if a directive in an .htaccessle tries to modify le access in a way that is not allowed
by the servers main conguration, Apache will not deliver
any data from that directory and any of its subdirectories.
Most directives have a one line, parameter/value structure. However, there is also a small number of XMLalike directive pairs, making up scopes or contexts,
like <VirtualHost> </VirtualHost> or <Directory> </Directory>. All directives enclosed between such a pair are said to belong to this context. In the
Apache documentation all directives are accompanied by
annotations determining in which scopes (or contexts) they
may appear.
There are some obvious shortcomings in the original
conguration data format as far as automated management
and verication purposes are concerned: The relevant data
are distributed over several les at different locations, and
it is hard for a management or verication system to get an
integrated overview of the whole system. A special-purpose
verication program working directly on all the conguration les would have to deal with access issues, format- and
syntax-checks and much more besides its real task, the semantically motivated checks. In addition, such a system
could hardly be used for verifying other conguration data
(in another format) or different constraints without major
rewritings. In contrast, using a CIM-based conguration
model as an abstraction layer between the real conguration
and the verifying program leads to a great degree of exibility and abstraction on the veriers side. CIM shares these
advantages with other high-level data description languages
like, e.g., the ontology language OWL [14]. However, CIM
gradually evolves into a quasi-standard for system management.

3.2. Apache Conguration with CIM

In our CIM model, access to the conguration data of the
Apache Web-server is made available through the Apache
HTTP Service class. This class is the entry point to all
other CIM classes related to Apache server conguration.
For increased manageability and structuring, conguration
directives are in a rst step grouped according to the Webservers entities they belong to. So there is a distinction

between directives pertinent to the whole server, to only a

virtual host, or merely to a directory. These groups of conguration options are further split up, e.g. into directives
valid only for a certain Apache module. In this way, the
whole unstructured set of conguration options is hierarchically organized into smaller managed CIM elements, as
is shown in Figure 1.

class Apache HttpHostConfiguration :

CIM Configuration
[Key] String Name;

;
class Apache HttpServerProperties :
Apache HttpServerSetting
[Key] String ConfigName;
String BindAddress;
String CoreDumpDirectory;
uint16 MaxClients;
uint32 MaxRequestsPerChild;
int16 MaxSpareServers;
int16 MinSpareServers;
...

ManagedSystem
Element

Configuration

CIM-Core

ManagedElement

Setting

*
Server
Configuration

Service

Apache

Logical
Element

*
Host
Configuration

Directory
Configuration

Apache
HTTPService

HTTPServer
Setting

HTTPListen
Setting

HTTPServer
Properties

HTTPServer
Module

HTTPHost
Setting

HTTPHost
Properties

Override
Policy

HTTPDirectory
Setting

HTTPDirectory
CoreSetting

Figure 1. CIM Classes for Apache Conguration.

The primary classes to hold conguration information
for managed elements of the Apache HTTP Service are descendants of CIMs Setting class. So there are, e.g., classes
containing properties of a virtual host (HTTP Host Properties), or for overriding access policies for directories (Override Policy). To group settings into larger managed elements, Congurations are employed. Several Apache specic conguration classes (Server Conguration, Host Conguration and Directory Conguration) are derived from
CIMs core conguration class. These conguration classes
do not directly contain any Apache directives, but are containers for instances of the appropriate setting classes. Congurations themselves may also be part of larger congurations, reecting the structure of the elements managed
by Apache. So we end up with a hierarchical, tree-like
structure, where Directory Congurations are components
of Host Congurations that are unied by Server Congurations.
Looking at the real conguration devices (mainly les)
of an Apache Web-server, we can say that the server conguration approximately maps to the httpd.conf le, host
congurations to <VirtualHost> directives and directory congurations to <Directory> directives.
Excerpts from two Apache CIM classes in their MOF
representation may illustrate how the directives of a Webserver conguration are structured and distributed over CIM
classes:

Proceedings of the Third International Conference On Quality Software (QSIC03)

0-7695-2015-4/03 $ 17.00 2003 IEEE

;

Note that aggregations are not stored within classes, but

are modeled using additional association classes. So, in our
example, we do not see any properties reecting associated
settings in the HTTP Host Conguration class.
Instantiation of the Apache specic classes of Figure 1
with concrete instances of a server conguration leads to
a hierarchical conguration tree. This tree is generated by
the aggregation relation of the relevant classes of the CIM
model. It consists of two kinds of nodes: setting nodes
and conguration nodes. In this tree the inner nodes represent congurations whereas the leaves represent settings.
A schematic example of such a tree is shown in Figure 2.
ServerConfiguration
SC1

S1
S2

HostConf.
H1

HostConf.
H2
S3a
P

DirectoryConf.
D1

S5a
Q

S6a

DirectoryConf.
D2

S5b
Q

HostConf.
H3

S3c
P
S4

S3b
P

DirectoryConf.
D3

DirectoryConf.
D4

S5c
Q

S5d
Q

DirectoryConf.
D5

S5e
Q

DirectoryConf.
D6

S5f
Q

S6b

Figure 2. Example Hierarchy of Conguration

and Setting Instances.
In our example, Web-server SC1 is congured to possess
three virtual hosts (H1-H3). These hosts are in turn congured by directives contained in the setting classes S3a, S3b,
S3c and S4. For each host further directory congurations
are present. So, host H1 has an additional directory conguration consisting of the setting classes S5a and S6a.
The tree structure captures an additional semantics of
the Web-server conguration, concerned with the correlation between instances of setting classes and managed elements: A setting S associated with a managed element E

is supposed to be relevant for all descendant nodes of element E, too. Thus, in our example, the directives of setting
S3a are also valid for directory conguration D1, whereas
they are irrelevant for host congurations H2 and H3, or
directory congurations D2 through D6. The semantical
structure can be reproduced by traversing the part/wholerelations (CongurationComponent and SettingContext association classes in CIM) between these nodes. Each conguration node can be considered generating a causally
closed semantical context for constraint evaluation. In specifying and verifying constraints describing interdependencies between different settings, it is crucial to consider the
relevant settings only.
Some constraints also require some kind of horizontal
navigation in this tree, allowing selection of all present instances of a particular class. This can be seen as a form
of quantication over conguration instances. Using the
WBEM API, quantication over objects can be accomplished using the class name, whereas addressing a special
object requires additional knowledge of its key values.

4. Apache Conguration Constraints

There is a vast range of possible syntactical and structural errors in a conguration le that can be recognized
and remedied in the early stage of transformation of the
conguration le into CIM classes. However, there are
other, mainly semantic errors that cannot be treated by lexical analysis alone. Some examples may illustrate the kind
of conditions we have to deal with:
The ServerRoot directive must be specied exactly
once in the server conguration.
Apache allows for setting a minimum and maximum number of spare servers via directives MinSpareServers and MaxSpareServers. We want to make
MinSpareServers and
sure that MaxSpareServers
that MinSpareServers 1.
When several virtual hosts are running on the same
server, each of them must have its own unique ServerName.
For security and privacy reasons it is strongly recommended that the log les of all virtual hosts are not
visible to the outside world. For example, the ErrorLog le should not be located in DocumentRoot or a
subdirectory thereof.
All virtual servers should have their own log les.

Some of these constraints may be hard constraints, in the

sense that they are indispensable for a correct functioning of
the Web-server. Other constraints may recommend sensible
values (soft constraints) that are appropriate for most Webserver installations but that are not enforced. Additionally,

Proceedings of the Third International Conference On Quality Software (QSIC03)

0-7695-2015-4/03 $ 17.00 2003 IEEE

there may be site-specic local constraints that reect the

companys (or site maintainers) security policy, user accessibility rights and other features. Part of such constraints
can stem from the Apache documentation itself [1], others
may have to be collected and specied by Web-server administrators or other personnel.
Using the CIM model as a starting point for modeling
and checking such constraints offers the advantage of having a semi-formal basis on which the constraint modeling
language can be built. Thus, a separation between constraint modeling and low-level conguration processing is
achieved.

5. Constraint Checking the CIM Model

Given a powerful and generally applicable system model
like CIM, new perspectives on verication tasks arise,
concerning, e.g., consistency of site-specic policy rules,
checking of individual congurations, or computation of
implied constraints. Combining CIMs powerful data model
with the exibility and generality of a formal constraintbased expert systems seems particularly promising.
The language to formulate the constraints has to reect
both CIM peculiarities (handling of classes, instances, properties and the structural relations between them) as well
as basic logical concepts known from, e.g., Boolean logic
and other general non-logical concepts such as arithmetic
or string processing.

5.1. Syntax
We will now present our CIM constraint language,

, which is partly inuenced by Description Logic
[BMNP03] and partly resembles variable-free predicate
logic. The language of
consists of three kinds of expressions: v-expressions, a-expressions and f-expressions.
V-expressions represent arbitrary nite sets of property values (numbers, strings,


), a-expressions are the atomic
propositions of our language, and f-expressions constitute
formulae. These expressions are recursively dened as follows:
v-expressions (denoted by s,t,


):
 

where  is a class name and  a
property name.
 
 


   where  is a class name and
 


  are property names.

where  is an arbitrary property
value constant (string, number, etc).
   


  
where  is a  -ary (interpreted)
function and  


  are vexpressions.

a-expressions:

    



where is a  -ary (interpreted) predicate and
    
are v-expressions.

where  is a natural number and  a
class name.
where  is a natural number,  a class
name and  a property name.

f-expressions (denoted by F,G,    ):

Boolean logic expressions built from connectives ,
, , true, false, , , and auxiliary symbols and

, using a-expressions as atoms.

  where  is a class name and  an f-expression.

For the context operator   we will also need to have

access to the aggregational (tree-)structure of the whole set
of CIM instances. We therefore use the following notations:

empty set otherwise),


 
: delivers the direct descendants of instance
 in the aggregation tree.

So, for the aggregation tree structure of Figure 2, we get

(in extracts, assuming that host conguration H1 is named
Host 1):
 
  


5.2. Semantics
All expressions of our language are interpreted with respect to a set of instances of CIM classes, where each
instance has properties according to its class denition, and
each property has a value matching the propertys type (always including the value NULL, denoting an undened
value; see also [3], Sec. 4.11.6).
By  we (intuitively) want to denote the set of values occurring under property  of any instance of class
 ;      
 selects all tuples
    


that occur under properties       
of an instance of class  ;

denotes an arbitrary value constant; 
    


denotes

application of function  to the sets of values
    

;
the expression
    


is true, if the values
    


are in relation ;
 is true, if there are at least  different instances of class  ;
 is true, if there are
at least  instances of class  , for which property  is
dened; and   is true, if formula  is true in evaluation context  (determined by class name  , for details
see below). We will also use the abbreviations  resp.
 instead of the a-expressions  and  , and
 as short form of the formula
make use of the notation
  
 (and similar for  ). Among the
relations, we always assume the equality predicate  to be
present, and use the relation symbol  as abbreviation for
the negation of the equality predicate. Moreover, we will
use the notation 

     

 as a short equivalent
for  
    

.
Before giving examples on the use of our language ,
we will give a precise denition of its semantics. We will
dene the truth of a- and f-expressions model-theoretically.
To refer to a class instances properties we will use some
(meta-language) auxiliary functions. For an instance , we
dene:

the CIM class that  is an instance of,

  
: the set of properties dened for instance ,

 
: the value assigned to property of instance
.

:

Proceedings of the Third International Conference On Quality Software (QSIC03)

0-7695-2015-4/03 $ 17.00 2003 IEEE


  
: delivers the set of parent nodes of instance
 (i.e. a singleton set, if  is not the root node, and the

  
 

  
 


 
  

We can now dene the precise semantics of expressions

in  ( for v-expressions,  for a-expressions, and 
for f-expressions):

 
 
 

 
  

  



  

 
 


 


 
  
  


  
  







  
 






 
 






 



  
 
 




 



 
 

 



 
  

  
 

 
  
if  is atomic
   
  
  

..
.

   
  
  

  

 



 

 

In these denitions we denote by boldface letters the

constants, functions resp. relations of the concrete domain.
), taken from an extension of
The counting quantiers (
predicate logic, are true, if there are at least  different values fullling the condition following the operator. So a for
 can be translated to       
 

mula (









 f.a.   
. The modication of
the set of considered instances in the denition of the context operator  ,  
, is dened over the aggregation tree
structure using auxiliary functions  
and   
:

 
  

 
 
  






 



  



  



 



 

 

if  
 
otherwise

Considering node H1 of our example of Figure 2, we

obtain



 
 
     and
  

 
 
  and thus


 
 
     
 
 
Therefore, 


is a set containing (among others) all in-

3. Each virtual host has its own unique server name. Here
we used an additional unary function, , computing
the cardinality of its argument set, and the key property
Name of class HostConguration.
4. The error log should not be stored in directory DocumentRoot or a subdirectory thereof. Here we used a
binary predicate on sets of strings (isPrexOf) returning true, if all elements of the rst set are prexes of
all elements of the second set. The context operator
assures that these sets are singletons.
5. The address/port pair of each virtual host must be an
address/port the Web-server is listening to (see [1]).
6. A conguration name and PID le must be specied
for the Web-server.

5.4. Constraint Evaluation

stances of setting classes relevant for node H1, which justies our denition of the context operator via function  .
Now, as usual, a formula is said to be satised by a set of
instances  , if   
 .
Note that all non-logical functions and predicates exclusively take set-valued arguments. This enables a wide variety of functions being uniformly and naturally denable. A
comparison operator , ranging over sets of natural numbers, may, e.g., be dened as

  


 



Set-containment, as another example, can be dened directly. But there are further possibilities, e.g.
in dening vary-adic operators. That way, sum- or
minimum/maximum-operators can be dened, and statements such as      
can be expressed. This
allows the formulation of complex, but common dependencies.

5.3. Examples
Turning back to Apache conguration, we now want to
give some examples on how to use the constraint specication language   . In Figure 3 we give formal variants of part of the specication stated in natural language
in Section 4 above, as well as some examples taken from
the Apache documentation [1]. These are to be understood
as follows:
1. Property ServerRoot is dened exactly once.
2. For each server conguration, the MinSpareServer and
MaxSpareServer properties are set as mentioned in
Section 4. Here we also used the comparison operator  and its converse  as dened above.

Proceedings of the Third International Conference On Quality Software (QSIC03)

0-7695-2015-4/03 $ 17.00 2003 IEEE

Constraint sets, such as those of the last section have to

be evaluated in order to check whether or not they hold for a
concrete conguration. We therefore implemented CIMVerier, a prototypical constraint checker. This verier uses a
variant of our language   , called ConQuery, in which all
logical operators have a textual representation. CIMVerier
is a Java client that employs the CIM and WBEM infrastructure to access the Apache conguration data. Constraints
are checked sequentially by evaluating the constraints in an
innermost fashion, using Java Reection to evaluate userdened predicates and functions.
In case of a violated constraint a simple yes/no answer
is often not enough to locate an error, and assistance of the
constraint verication system to guide the user can be of
great help. So we implemented a mechanism to nd possible conguration errors by identifying properties that are
set to a wrong value with highest probability. Therefore, we
assume that the values of all parameters of a violated constraint are responsible for the failure with equal probability.
Then we can proceed as follows: Let       
be the set of violated constraints, and   
the number of occurrences of parameter  in constraint 
. We then
compute for each parameter  occurring in  its weight,

 






 







where 

  

denotes the total number

of properties occurring in constraint 
. The parameter with

highest weight  
is then assumed to be most likely responsible for the constraint violation.

6. Conclusions, Related and Future Work

We presented a verication approach for Apache Webserver congurations. The verication is based on an


















  



 







 






  



 


  
 




     

 

 
 



  

!
    

 "##
    ! 

  ! 
"##
 ! 





 





#$%

Figure 3. Formalization of some Consistency Properties in .

object-oriented semi-formal CIM model of the conguration data and a specialized constraint specication language. Our extensible specication language reects typical constructs found in CIM and currently allows formulation of constraints containing predicates and functions over
numbers, sets and strings. We also implemented a prototypical constraint evaluator based on Java Reection and the
WBEM infrastructure. This implementation facilitates error recovery by computing weights for probably faulty conguration settings.
Representative for other work on formal verication of
(semi-formal) UML-diagrams we want to mention DupuyChessa and du Bousquets validation of UML models [6]
and Meyer and Souqui`eres formalization based on the
specication language B [12]. In contrast to their work,
we do not use a powerful specication language using full
predicate logic, but restrict our specication language to
a variable-free logic that resembles Description Logic [2],
which potentially offers advantages for automated theorem
proving tasks. Dong et al. present an approach to specify
Semantic Web Services using Z in order to nd errors in the
ontology [5]. Work on validation and integrity checking of
XML data can also be found in the literature [13].
Future work may include the application of automatic
theorem proving methods to CIM verication using .
This would offer additional possibilities, e.g. in checking the consistency constraints by themselves, in automatic
completion of partially specied congurations, and in automatic error correction. Moreover, a complexity theoretic
analysis of our specication language  and a comparison with current description logics could be of interest.

References
[1] The Apache Software Foundation. Apache HTTP Server
Version 1.3 Documentation, 2002. http://httpd.
apache.org/docs.
[2] F. Baader, D. McGuinness, P. Nardi, and P. Patel-Schneider,
editors. The Description Logic Handbook. Cambridge University Press, 2003.
[3] Distributed Management Task Force, Inc. Common Information Model Specication, 1999. http://www.dmtf.
org/standards/documents/CIM/DSP0004.pdf.

Proceedings of the Third International Conference On Quality Software (QSIC03)

0-7695-2015-4/03 $ 17.00 2003 IEEE

[4] Distributed Management Task Force, Inc. CIM Operations over HTTP, 2002. http://www.dmtf.org/
standards/documents/WBEM/DSP200.html.
[5] J. Dong, J. Sun, and H. Wang. Z Approach to Semantic Web.
In International Conference on Formal Engineering Methods (ICFEM02), pages 156167. Springer-Verlag, 2002.
[6] S. Dupuy-Chessa and L. du Bousquet. Validation of UML
models thanks to Z and Lustre. In Proc. of the Intl. Symp.
on Formal Methods Europe (FME 2001), pages 254258,
Berlin, Germany, 2001. Springer-Verlag.
[7] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design
Patterns. Addison Wesley, 1995.
[8] D. Harel, D. Kozen, and J. Tiuryn. Dynamic Logic. MIT
Press, 2000.
[9] IBM Linux Technology Center. Standards Based Linux Instrumentation for Manageability, 2000. http://oss.
software.ibm.com/sblim.
[10] W. Kuchlin and C. Sinz. Proving consistency assertions for
automotive product data management. J. Automated Reasoning, 24(12):145163, Feb. 2000.
[11] B. Laurie and P. Laurie. Apache: The Denitive Guide (3rd
Edition). OReilly & Associates, 2002.
[12] E. Meyer and J. Souqui`eres. A systematic approach to transform OMT diagrams to a B specication. In Proc. of the
World Congress on Formal Methods in the Development
of Computing Systems (FM99), pages 875896, Toulouse,
France, 1999. Springer-Verlag.
[13] C. Nentwich, W. Emmerich, and A. Finkelstein. Static consistency checking for distributed specications. In Proc. of
the 16th IEEE Intl. Conf. on Automated Software Engineering (ASE01), pages 115125, Coronado Bay, CA, 2001.
IEEE Computer Society.
[14] Web Ontology Language (OWL) Reference Version 1.0,
2002. W3C Working Draft 12 November 2002. Latest version available at http://www.w3.org/TR/owl-ref.
[15] C. Sinz, T. Lumpp, and W. Kuchlin. Towards a verication
of the rule-based expert system of the IBM SA for OS/390
automation manager. In Proceedings of the 2nd Asia-Pacic
Conference on Quality Software (APAQS 2001), pages 367
374, Hong Kong, Dec. 2001. IEEE Computer Society.
[16] C. Sinz, T. Lumpp, J. Schneider, and W. Kuchlin. Detection
of dynamic execution errors in IBM System Automations
rule-based expert system. Information and Software Technology, 44(14):857873, Nov. 2002.
[17] R. Waldinger and M. Stickel. Proving properties of rulebased systems. Intl. J. Software Engineering and Knowledge
Engineering, 2(1):121144, 1992.