Dissertaç ˜ao de Mestrado Mestrado em Engenharia Informática Jo ...
Dissertaç ˜ao de Mestrado Mestrado em Engenharia Informática Jo ...
Dissertaç ˜ao de Mestrado Mestrado em Engenharia Informática Jo ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Universida<strong>de</strong> Nova <strong>de</strong> Lisboa<br />
Faculda<strong>de</strong> <strong>de</strong> Ciências e Tecnologia<br />
Departamento <strong>de</strong> <strong>Informática</strong><br />
<strong>Dissertaç</strong>ão <strong>de</strong> <strong>Mestrado</strong><br />
<strong>Mestrado</strong> <strong>em</strong> <strong>Engenharia</strong> <strong>Informática</strong><br />
<strong>Jo</strong>ão André Martins (26464)<br />
Lisboa<br />
(2009)
Universida<strong>de</strong> Nova <strong>de</strong> Lisboa<br />
Faculda<strong>de</strong> <strong>de</strong> Ciências e Tecnologia<br />
Departamento <strong>de</strong> <strong>Informática</strong><br />
<strong>Dissertaç</strong>ão <strong>de</strong> <strong>Mestrado</strong><br />
SmART: An Application<br />
Reconfiguration<br />
Framework<br />
<strong>Jo</strong>ao Andre Martins (26464)<br />
Orientador: Prof. Doutor Hervé Paulino<br />
Co-orientador: Prof. Doutor <strong>Jo</strong>ão Lourenço<br />
Lisboa<br />
(2009)<br />
<strong>Dissertaç</strong>ão apresentada na Faculda<strong>de</strong> <strong>de</strong> Ciências<br />
e Tecnologia da Universida<strong>de</strong> Nova <strong>de</strong> Lisboa para<br />
a obtensão do Grau <strong>de</strong> Mestre <strong>em</strong> <strong>Engenharia</strong> In-<br />
formática.
To my family and friends, who supported me through the best and worst.
Summary<br />
Among the information technology sectors is the virtualization sector, which stands out by<br />
being a very active area, with many collaborations and advances. Virtualization’s benefits are<br />
plenty. Some of th<strong>em</strong> are the massive server consolidation, reduced cooling, structural and<br />
electrical costs and the isolation between virtual machines.<br />
Virtual appliance is a concept resulting from the advanc<strong>em</strong>ents on virtualization, and <strong>de</strong>-<br />
fines an alternative software distribution mo<strong>de</strong>l from those existing by then, such as the tradi-<br />
tional CD-ROM distribution, software as a service and hardware appliances. This mo<strong>de</strong>l allows<br />
customers to have their IT solution fully specified and optimized for the task it must perform.<br />
With the virtual appliance outbreak, many servers using different applications tend to<br />
gather on the same physical machine. The applications, in turn, may impl<strong>em</strong>ent plenty config-<br />
uration formats, from wi<strong>de</strong>ly adopted standards to proprietary formats. The configuration of<br />
these applications is typically carried by busy syst<strong>em</strong> administrators, who must <strong>de</strong>dicate some<br />
of their time coping such a vast configuration format range.<br />
This thesis contributes for the nourishing of the virtual appliance concept and proposes<br />
the creation of a tool which automatically configures applications insi<strong>de</strong> virtual appliances,<br />
regardless of the application being configured. The contributions on this area are, therefore,<br />
very rare, which elevates this dissertation to a pioneer of the area.<br />
The approach for the probl<strong>em</strong> of automatic application configuration explores the frequently<br />
found patterns in configuration files. Typically, those files use similar concepts, such as parame-<br />
ter <strong>de</strong>finitions, parameter blocks and comments. Besi<strong>de</strong>s this, only some files were found to im-<br />
pl<strong>em</strong>ent other concepts, although on a punctual basis. This dissertation proposes a framework<br />
for the automatic configuration of applications based on this characteristic. A configuration<br />
file is transformed to a structured and application-in<strong>de</strong>pen<strong>de</strong>nt language, like the eXten<strong>de</strong>d<br />
Markup Language, which is then modified and reverted to its original syntax.<br />
Keywords: Virtual appliance, automatic application configuration<br />
vii
Sumário<br />
Entre os sectores <strong>de</strong> tecnologias <strong>de</strong> informação, o sector da virtualização distingue-se por<br />
ser uma área muito activa, que conta com muitas colaborações e <strong>de</strong>senvolvimentos. As util-<br />
ida<strong>de</strong>s da virtualização são inúmeras. Entre elas estão a consolidação maciça <strong>de</strong> servidores,<br />
redução nos custos <strong>de</strong> arrefecimento, estruturais e <strong>de</strong> electricida<strong>de</strong> e o isolamento entre<br />
máquinas virtuais.<br />
Fruto dos avanços da virtualização é o conceito <strong>de</strong> virtual appliance, que <strong>de</strong>fine um mo<strong>de</strong>lo<br />
<strong>de</strong> distribuição <strong>de</strong> software alternativo aos até então existentes, tais como distribuição tradi-<br />
cional (CD-ROM), software as a service e hardware appliances. Este mo<strong>de</strong>lo permite aos clientes<br />
ter<strong>em</strong> a sua solução informática específica e optimizada para a tarefa que se propõe <strong>de</strong>s<strong>em</strong>pen-<br />
har.<br />
Com o surgimento das virtual appliances, muitos servidores que recorr<strong>em</strong> a diversas aplicações<br />
ten<strong>de</strong>m a juntar-se <strong>em</strong> máquinas físicas. As aplicações, por sua vez, po<strong>de</strong>m impl<strong>em</strong>entar vários<br />
formatos <strong>de</strong> configuração, <strong>de</strong>s<strong>de</strong> padrões amplamente adoptados a formatos <strong>de</strong> proprietário. A<br />
configuração <strong>de</strong>stas aplicações é tipicamente feita por administradores <strong>de</strong> sist<strong>em</strong>as ocupados,<br />
que têm assim necessida<strong>de</strong> <strong>de</strong> canalisar o seu t<strong>em</strong>po para lidar com a varieda<strong>de</strong> <strong>de</strong> formatos<br />
<strong>de</strong> configuração.<br />
Esta dissertação vai no encontro dos avanços no ramo das virtual appliances, propondo a<br />
criação <strong>de</strong> uma ferramenta que faça a configuração automática <strong>de</strong> aplicações, in<strong>de</strong>pen<strong>de</strong>n-<br />
t<strong>em</strong>ente da aplicação <strong>em</strong> causa. São muito poucos os contributos nesta área, pelo que esta<br />
dissertação po<strong>de</strong> ser consi<strong>de</strong>rada pioneira na área.<br />
A abordag<strong>em</strong> para o probl<strong>em</strong>a da configuração automática <strong>de</strong> aplicações explora os padrões<br />
recorrentes <strong>em</strong> ficheiros <strong>de</strong> configuração <strong>de</strong> aplicações. Tipicamente, estes ficheiros imple-<br />
mentam conceitos s<strong>em</strong>elhantes, como <strong>de</strong>finições <strong>de</strong> parâmetros, blocos <strong>de</strong> parâmetros e co-<br />
mentários, existindo ainda outros ficheiros que impl<strong>em</strong>entam padrões próprios, tratando-se,<br />
no entanto, <strong>de</strong> casos pontuais. Esta dissertação propõe uma framework baseada nesta carac-<br />
terística, on<strong>de</strong> um ficheiro <strong>de</strong> configuração é transformado para uma linguag<strong>em</strong> estruturada e<br />
in<strong>de</strong>pen<strong>de</strong>nte da aplicação, como a eXten<strong>de</strong>d Markup Language (XML), e que <strong>de</strong>pois <strong>de</strong> alter-<br />
ado é revertido na sua síntaxe original.<br />
Palavras-chave: Virtual appliance, configuração automática <strong>de</strong> aplicações<br />
ix
Contents<br />
1 Introduction 1<br />
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1<br />
1.2 Probl<strong>em</strong> Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3<br />
1.2.1 Pre-installation Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
1.2.2 Post-installation Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
1.2.3 Application Configuration in General . . . . . . . . . . . . . . . . . . . . . 4<br />
1.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
1.3 Probl<strong>em</strong> Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8<br />
1.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8<br />
1.5 Document Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
2 State of the Art and Related Work 11<br />
2.1 Virtual Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11<br />
2.1.1 Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12<br />
2.1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
2.1.3 Open Virtual Machine Format . . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
2.1.4 Virtual Appliances in Real Life . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
2.2 Automatic Configuration of Applications . . . . . . . . . . . . . . . . . . . . . . . 15<br />
2.2.1 Thin Crust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16<br />
2.2.2 SmartFrog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16<br />
2.3 Automatic Recognition of Configuration Files . . . . . . . . . . . . . . . . . . . . . 16<br />
2.3.1 SableCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17<br />
2.3.2 JavaCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18<br />
2.4 Representation of Configuration Files in a Generic Syntax . . . . . . . . . . . . . . 18<br />
3 An application reconfiguration framework 21<br />
3.1 Architectural Requir<strong>em</strong>ents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22<br />
3.2 Automatic Application Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 24<br />
3.3 Original to Generic syntax Converter . . . . . . . . . . . . . . . . . . . . . . . . . . 24<br />
3.3.1 Component Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25<br />
3.3.2 Original to Generic Syntax Converter Operation Scenarios . . . . . . . . . 31<br />
3.4 Generic to Original syntax Converter . . . . . . . . . . . . . . . . . . . . . . . . . . 33<br />
xi
CONTENTS<br />
3.5 Modifying the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34<br />
3.6 External Parser Addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34<br />
4 An Impl<strong>em</strong>entation 37<br />
4.1 Programming Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37<br />
4.2 Parser Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38<br />
4.3 Generic Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
4.4 Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
4.4.1 Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
4.4.2 Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41<br />
4.4.3 ParsingData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41<br />
4.4.4 CompilationData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42<br />
4.5 Original to Generic syntax Converter . . . . . . . . . . . . . . . . . . . . . . . . . . 43<br />
4.5.1 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43<br />
4.5.2 Configuration File Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44<br />
4.5.3 Parser Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44<br />
4.5.4 Grammar Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45<br />
4.5.5 Co<strong>de</strong> Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45<br />
4.5.6 Tentative Grammar Repository . . . . . . . . . . . . . . . . . . . . . . . . . 45<br />
4.6 Generation of Original Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46<br />
4.7 Generic to Original Syntax Converter . . . . . . . . . . . . . . . . . . . . . . . . . 48<br />
5 Framework Evaluation 51<br />
5.1 Functional Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
5.2 Operational Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53<br />
5.2.1 INI-like Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 54<br />
5.2.2 Apache-like Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . 56<br />
5.2.3 XML-like Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . 56<br />
5.2.4 Parsing the Generated XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 58<br />
5.3 Performance Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63<br />
6 Integration with VIRTU 67<br />
6.1 Project Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67<br />
6.2 VIRTU Top-Level Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68<br />
6.3 VIRTU Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70<br />
6.3.1 Data and Resources Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70<br />
6.3.2 Processing Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72<br />
6.3.3 Presentation Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73<br />
6.3.4 Other Notable Sectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74<br />
6.4 SmART integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74<br />
6.4.1 SmART Original to Generic syntax Converter . . . . . . . . . . . . . . . . 76<br />
6.4.2 SmART Generic to Original syntax Converter . . . . . . . . . . . . . . . . 77<br />
xii
CONTENTS<br />
6.4.3 Parser Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77<br />
6.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77<br />
7 Conclusion and Future work 79<br />
7.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80<br />
A Appendix - Architecture 83<br />
A.1 OGC sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83<br />
B Appendix - Evaluation 85<br />
B.1 MySQL Configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85<br />
B.2 Apache Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89<br />
B.3 Eclipse Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120<br />
B.4 Performance Validation File 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139<br />
B.5 Performance Validation File 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140<br />
B.6 Performance Validation File 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143<br />
xiii
List of Figures<br />
2.1 Virtual appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12<br />
2.2 Physical unit running four VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12<br />
3.1 SmART Work Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25<br />
3.2 Components overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26<br />
3.3 Partial and totally parsed configuration file stages . . . . . . . . . . . . . . . . . . 29<br />
3.4 Interactions on the successful file recognition scenario . . . . . . . . . . . . . . . . 32<br />
3.5 Interactions on the failed file recognition scenario . . . . . . . . . . . . . . . . . . 33<br />
4.1 Recognition of a configuration file by two parsers . . . . . . . . . . . . . . . . . . 40<br />
4.2 Graphical representation of ParsingData . . . . . . . . . . . . . . . . . . . . . . . . 42<br />
4.3 List of TGRNo<strong>de</strong>s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46<br />
5.1 Parsing the generated XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63<br />
6.1 VIRTU Ass<strong>em</strong>bly Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69<br />
6.2 VIRTU Logical View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70<br />
6.3 VIRTU Architectural Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71<br />
6.4 SmART integration points with VIRTU . . . . . . . . . . . . . . . . . . . . . . . . . 75<br />
A.1 Original to generic syntax converter sequence diagram . . . . . . . . . . . . . . . 84<br />
xv
List of Tables<br />
3.1 Presentation Layer Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25<br />
3.2 Logic Layer Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26<br />
3.3 Data Layer Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26<br />
5.1 Elapsed times for parser compilation in JavaCC . . . . . . . . . . . . . . . . . . . 65<br />
xvii
List of Listings<br />
1.1 Apache configuration file excerpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5<br />
1.2 Eclipse configuration file excerpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
1.3 MySQL configuration file excerpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
1.4 PostgreSQL configuration file excerpt . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
1.5 Mantis configuration file excerpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
3.1 User Interface proposed interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27<br />
3.2 Configuration File Parser proposed interface . . . . . . . . . . . . . . . . . . . . . 28<br />
3.3 Co<strong>de</strong> Generator proposed interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 29<br />
3.4 Grammar Compiler proposed interface . . . . . . . . . . . . . . . . . . . . . . . . 30<br />
3.5 Parser Repository proposed interface . . . . . . . . . . . . . . . . . . . . . . . . . . 30<br />
3.6 Tentative Grammar Repository proposed interface . . . . . . . . . . . . . . . . . . 31<br />
3.7 Printer proposed interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33<br />
3.8 External Parser Proposed Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 35<br />
4.1 No<strong>de</strong> interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38<br />
4.2 Parser data structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
4.3 InternalParser data structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
4.4 ExternalParser data structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41<br />
4.5 Grammar data structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41<br />
4.6 ParsingData data structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42<br />
4.7 CompilationData data structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43<br />
4.8 Example Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47<br />
4.9 Example FStr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48<br />
4.10 Apache parameter with a single value . . . . . . . . . . . . . . . . . . . . . . . . . 48<br />
4.11 Apache parameter with multiple values . . . . . . . . . . . . . . . . . . . . . . . . 48<br />
4.12 XML el<strong>em</strong>ent with a single subel<strong>em</strong>ent . . . . . . . . . . . . . . . . . . . . . . . . 49<br />
4.13 XML el<strong>em</strong>ent with multiple el<strong>em</strong>ents . . . . . . . . . . . . . . . . . . . . . . . . . 49<br />
5.1 MySQL configuration file snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54<br />
5.2 MySQL block in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55<br />
5.3 MySQL comment in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55<br />
5.4 MySQL special instruction in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 55<br />
5.5 MySQL Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56<br />
5.6 Apache configuration file snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57<br />
xix
LIST OF LISTINGS<br />
5.7 Apache parameter with a single value in XML . . . . . . . . . . . . . . . . . . . . 57<br />
5.8 Apache parameter with multiple values in XML . . . . . . . . . . . . . . . . . . . 57<br />
5.9 Apache block in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58<br />
5.10 Apache nested block in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59<br />
5.11 Apache comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59<br />
5.12 Apache Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60<br />
5.13 Eclipse configuration file snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60<br />
5.14 Eclipse <strong>em</strong>pty block in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60<br />
5.15 Eclipse block with parameters in XML . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
5.16 Eclipse nested blocks in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
5.17 Eclipse comment in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62<br />
5.18 Eclipse Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62<br />
G:/etc/mysql/my.cnf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85<br />
G:/home/citanul/workspace/conf2xml blox/src/httpd.conf . . . . . . . . . . . . . . 89<br />
G:/home/citanul/workspace/conf2xml xml/src/workbench.xml . . . . . . . . . . . 120<br />
G:/home/citanul/SACT/performance/pg i<strong>de</strong>nt.conf . . . . . . . . . . . . . . . . . . . 139<br />
G:/home/citanul/SACT/performance/pg hba.conf . . . . . . . . . . . . . . . . . . . . 140<br />
G:/home/citanul/SACT/performance/postgresql.conf . . . . . . . . . . . . . . . . . . 143<br />
xx
1<br />
Introduction<br />
This dissertation presents a framework for the automatic configuration of applications in vir-<br />
tual appliances. This framework, entitled Smart Application Reconfiguration Tool (SmART),<br />
configures any kind of application by transforming the application’s configuration files into a<br />
generic structure, <strong>de</strong>ttached from the configuration file original syntax. This abstraction allows<br />
for a configurator to traverse configuration files in original syntax from any application and<br />
modify th<strong>em</strong> to reflect a <strong>de</strong>sired behaviour on the target application. As soon as the configura-<br />
tor manages to apply the changes, the information in the configuration files on generic syntax<br />
is used to reproduce th<strong>em</strong> in their original syntax. This framework is very innovative on the<br />
grounds that it approaches the area of automatic application configuration, an area which ben-<br />
efits from few contributions and currently does not offer many solutions for that en<strong>de</strong>avour.<br />
This chapter is structured on the following way: Section 1.1 explains the motivation for the<br />
resolution of the probl<strong>em</strong>, Section 1.2 <strong>de</strong>fines the probl<strong>em</strong> to be solved, Section 1.3 reveals how<br />
that probl<strong>em</strong> can be solved, Section 1.4 enumerates the contributions of this dissertation for the<br />
probl<strong>em</strong> solution and Section 1.5 presents the organization of the r<strong>em</strong>ain<strong>de</strong>r of this dissertation.<br />
1.1 Motivation<br />
The virtualization area is a very hot and fast-moving area of Information Technology (IT). Al-<br />
though virtualization is not an entirely new concept, only recently it has been noticed, <strong>de</strong>vel-<br />
oped and studied carefully and in <strong>de</strong>pth, so it is prone to more advanc<strong>em</strong>ents and should be<br />
consi<strong>de</strong>red as a mainstream software <strong>de</strong>ployment mo<strong>de</strong>l for the future [VMw].<br />
Despite the term and i<strong>de</strong>as of virtualization being quite old (1960’s), only recently it has<br />
been given increased attention [Sin04]. Companies which recur to IT services are increasingly<br />
aware of virtualization due to the crucial changes it brings along. Virtualization makes it pos-<br />
1
1. INTRODUCTION 1.1. Motivation<br />
sible to gather several un<strong>de</strong>rutilized servers into fewer ones (possibly just a single server) by<br />
virtualizing the hardware where each server runs. This reduces not only the companies’ electri-<br />
cal bills, but also cooling, space and hardware costs. Virtualization brings along other benefits<br />
such as the fast replication and/or migration of virtual machines (VMs), which allows for high<br />
availability of the services provi<strong>de</strong>d by the VMs.<br />
But not only the final users of virtualization woke up to the trend. Some IT giants such as<br />
Intel, AMD and Microsoft already entered the virtualization market, with different solutions<br />
such as hardware-assisted virtualization or hypervisor based virtualization. This huge trend<br />
also got into the consumers market, with popular solutions such as VMware Workstation or<br />
Microsoft Virtual PC, and even in the gaming market. Anyone who runs games on MAME<br />
or WINE is using virtualization technology. Currently, there are a lot of virtualization solu-<br />
tions in the market. These inclu<strong>de</strong> VMware [VMw09], XenSource [Cit09], Microsoft [Mic09a],<br />
Sun [Mic09c], Parallels [Par09] products, and so on.<br />
With the advanc<strong>em</strong>ent of virtualization technology, the new Virtual Appliance (VA) concept<br />
<strong>em</strong>erged. VAs came to change the way of looking to software <strong>de</strong>ployment. Unlike the existing<br />
software <strong>de</strong>ployment mo<strong>de</strong>ls, presented ahead in Section 2.1, such as the traditional CD-ROM<br />
way, Software as a Service or Hardware Appliances, VAs allow the costumers to have their<br />
own IT platform, fully optimized for the task being and completely un<strong>de</strong>r their domain. The<br />
blending of virtualization benefits with VAs’ performance is bringing software <strong>de</strong>ployment to<br />
a new level.<br />
This shift in the IT sector motivated project VIRTU [Sol09a] which is a collective effort by<br />
the consortium composed of Evolve Space Solutions, Universida<strong>de</strong> Nova <strong>de</strong> Lisboa, Universi-<br />
da<strong>de</strong> <strong>de</strong> Coimbra, HP Labs and the European Space Agency. The project’s goal is to <strong>de</strong>velop an<br />
open-source vendor-in<strong>de</strong>pen<strong>de</strong>nt virtualization platform, including support for the manage-<br />
ment and configuration of applications.<br />
There are currently two <strong>em</strong>erging opportunities on the IT market. On one si<strong>de</strong>, virtualiza-<br />
tion has changed the way in which companies <strong>de</strong>ploy software, on the other hand, application<br />
configuration is still mostly a manual task. VIRTU exploits these opportunities by <strong>de</strong>fining a<br />
virtualization tool which manages application stacks. In other words, VIRTU allows for the<br />
creation of optimized virtual machines ass<strong>em</strong>bled with existing applications which can be au-<br />
tomatically configured.<br />
VIRTU project’s use cases range from software testing in complex distributed syst<strong>em</strong>s, in-<br />
cluding the European Space Operations Center’s Mission Control Syst<strong>em</strong> (MCS) and Ground<br />
Syst<strong>em</strong> Tests and Validation infrastructure (GSTVi), to IT infrastructural manag<strong>em</strong>ent, like Por-<br />
tugal Telecom’s Application Service Provi<strong>de</strong>r or Novabase’s Enterprise Applications Environ-<br />
ment. VIRTU also makes it possible for a customer to have its solution self-provisioned within<br />
his domain, but also to maintain different application versions to achieve legacy compatibility.<br />
The advent of virtual appliances makes it possible to gather hundreds, or thousands of<br />
applications on the same machine. This results in many different ways to represent configu-<br />
rations, which, in turn, makes the manag<strong>em</strong>ent of those configurations complicated and time-<br />
consuming.<br />
2
1. INTRODUCTION 1.2. Probl<strong>em</strong> Description<br />
This dissertation proposes the creation of a tool, entitled Smart Application Reconfiguration<br />
Tool (SmART), that is able to configure any application, regardless of how it represents its con-<br />
figuration. This tool was <strong>de</strong>veloped on the context of VIRTU project, which is a virtualization<br />
platform for the creation and manag<strong>em</strong>ent of VAs.<br />
1.2 Probl<strong>em</strong> Description<br />
The probl<strong>em</strong> of automatic application configuration is caused by software applications which<br />
<strong>em</strong>ploy different means of representing their configurations. In some cases, it was noticed that<br />
the same application impl<strong>em</strong>ented different configuration formats from one version to another.<br />
This lack of standardization reveals that the configuration aspects of the applications are put<br />
in the backburner by application <strong>de</strong>velopers. Currently, the solutions on the field of automatic<br />
configuration of applications are seldom. This work goes in a way as to explore the mentioned<br />
opportunity.<br />
VAs may have different formats and may contain all sorts of applications, so it would be<br />
very helpful if a tool could configure any kind of application insi<strong>de</strong> a VA. For this matter, it is<br />
essential that the tool interprets each configuration file in<strong>de</strong>pen<strong>de</strong>ntly of the application being<br />
configured, rather than having a limited set of known configurations and trying to match th<strong>em</strong><br />
with the configuration file.<br />
Besi<strong>de</strong>s the differences in the representation of configurations between two disparate ap-<br />
plications, once can also i<strong>de</strong>ntify divergent configurations in the same applications. Typically,<br />
whenever an application is upgra<strong>de</strong>d, so are its configuration files, even if the differences in<br />
both situations come down to one or two extra lines containing new parametrizable el<strong>em</strong>ents<br />
than before. This motivates the abstraction from the configuration representation, which will<br />
allow any application to be configured based on what settings it <strong>de</strong>fines, not how they are<br />
<strong>de</strong>fined.<br />
Two ways to configure applications in VAs can be i<strong>de</strong>ntified. The first sets up the config-<br />
uration files before the application is installed on the VA, whereas the second searches for the<br />
configuration files in the VA and changes th<strong>em</strong>. Given the fact that the we are <strong>de</strong>aling with text<br />
configuration files which need to be read and parsed in both approaches, applications whose<br />
configuration files are in the binary format may require special parsers. This is often the case<br />
in closed-source applications.<br />
An example of the typical usage of this tool is the case where many VAs containing the<br />
same applications (e.g., webserver) need to be <strong>de</strong>ployed on an intranet. Although these VAs<br />
have the same software, their configurations must be different (e.g., machine name, IP address,<br />
etc.). Following is a brief <strong>de</strong>scription of both approaches and the way in which each approach<br />
<strong>de</strong>als with the example case.<br />
3
1. INTRODUCTION 1.2. Probl<strong>em</strong> Description<br />
1.2.1 Pre-installation Configuration<br />
Before the application is installed on a VA, there are two el<strong>em</strong>ents: the application installation<br />
package and the VA. In or<strong>de</strong>r to configure an application prior to its installation, the configura-<br />
tion files must be read, parsed and changed, to reflect the <strong>de</strong>sired settings, outsi<strong>de</strong> the VA. After<br />
the configuration file is properly modified, the application package must be reconstructed to<br />
be ready for installation.<br />
This approach has two significant limitations. First, whenever a different configuration for<br />
another VA is required, a new package containing that configuration must be built. This results<br />
in the proliferation of packages for the same applications, differing only on their configuration<br />
files.<br />
Also, since this approach <strong>de</strong>als with uninstalled packages, it does not allow the same VA<br />
to be configured more than once. If an application is to be configured again, the process goes<br />
back to the beginning and the application has to be re-installed.<br />
1.2.2 Post-installation Configuration<br />
On the post-installation configuration, the configuration file is retrieved from an already built<br />
VA. The file is then parsed, changed outsi<strong>de</strong> the VA and will later replace the ol<strong>de</strong>r version<br />
insi<strong>de</strong> the VA. Getting the configuration file from insi<strong>de</strong> the VA may be the toughest part of the<br />
process because it requires knowledge of the VA format, as well as the software insi<strong>de</strong> it. For<br />
instance, in Fedora Core Linux distributions the Apache HTTP Server configuration files are<br />
usually stored in the /etc/httpd/ directory whereas in Ubuntu Linux distributions they are<br />
located at /etc/apache2/.<br />
In the example case, only one t<strong>em</strong>plate VA, containing the applications, must be built. It is<br />
then replicated enough times to match the <strong>de</strong>sired number of VAs. After all VAs are created,<br />
their applications can be configured with the tool any number of times without the need to<br />
reinstall the application. This clears the need of having to proceed with multiple installations.<br />
1.2.3 Application Configuration in General<br />
One way to treat different applications equally is to look for similarities in their structure. The<br />
fact is that the majority of configuration files are represented similarly. Although the formats<br />
or the languages of the configuration files tend to differ, different configuration files end up by<br />
impl<strong>em</strong>enting the same concepts, or patterns. The majority, if not all configuration files, use<br />
the notion of parameter to represent the setting of a value to an application variable.<br />
An analysis is now carried to find out what patterns are expected to be found in config-<br />
uration files by SmART. This analysis focuses the applications of some VIRTU project usage<br />
scenarios. These applications inclu<strong>de</strong>:<br />
• Apache<br />
• Eclipse<br />
4
1. INTRODUCTION 1.2. Probl<strong>em</strong> Description<br />
Listing 1.1: Apache configuration file excerpt<br />
# ServerRoot: The top of the directory tree un<strong>de</strong>r which the server’s<br />
# configuration, error, and log files are kept.<br />
ServerRoot "@@ServerRoot@@"<br />
Allow from all<br />
<br />
<br />
#<br />
# If you wish httpd to run as a different user or group, you must run<br />
# httpd as root initially and it will switch.<br />
User da<strong>em</strong>on<br />
Group da<strong>em</strong>on<br />
<br />
<br />
!inclu<strong>de</strong>dir /etc/mysql/conf.d/<br />
• MySQL<br />
• PostgreSQL<br />
• Mantis<br />
Following are presented some configuration file excerpts of the presented applications.<br />
Each excerpt is analysed to i<strong>de</strong>ntify the commonly found patterns in each of th<strong>em</strong>.<br />
Apache<br />
The patterns in the Apache HTTP Server [Fou09a] configuration files (Listing 1.1) are parameters<br />
formed as id - separator - value, where the separator is a space character and the value may have<br />
multiple instances; comments, which are text lines starting with the ‘#’ character; and blocks,<br />
which are sets of patterns <strong>de</strong>limited by a hea<strong>de</strong>r and a footer. Besi<strong>de</strong>s these patterns, there<br />
are also special instructions, which start with a ‘!’ character, followed by a command key and<br />
further arguments.<br />
Eclipse<br />
The Eclipse [Fou09b] configuration files (Listing 1.2) are in a format similar to the eXtensible<br />
Markup Language (XML) format [Con03]. It mainly contains el<strong>em</strong>ents and blocks. The blocks<br />
may be <strong>em</strong>pty or may contain other blocks. In case the blocks are <strong>em</strong>pty, they are represented<br />
solely by a tag, whereas if a block contains other blocks, it is <strong>de</strong>limited by a starting and an<br />
ending tag. Additionally, a block may contain attributes, corresponding to parameters.<br />
Being XML, it also supports comments, of the form .<br />
5
1. INTRODUCTION 1.2. Probl<strong>em</strong> Description<br />
Listing 1.2: Eclipse configuration file excerpt<br />
<br />
<br />
<br />
<br />
[mysqld]<br />
#<br />
# * Basic Settings<br />
#<br />
Listing 1.3: MySQL configuration file excerpt<br />
user = mysql<br />
pid-file = /var/run/mysqld/mysqld.pid<br />
socket = /var/run/mysqld/mysqld.sock<br />
port = 3306<br />
MySQL<br />
The MySQL [Mic09b] configuration files (Listing 1.3) are in a format similar to the INI file<br />
format (ahead in Section 1.3). A MySQL configuration file impl<strong>em</strong>ents parameters formed as id<br />
- separator - value, where the separator is the ‘=’ character; comments which are text lines starting<br />
with the ‘#’ character; and blocks i<strong>de</strong>ntified by an initial hea<strong>de</strong>r and which may contain multiple<br />
parameters and/or comments.<br />
PostgreSQL<br />
The PostgreSQL [Gro09b] configuration files (Listing 1.4) are an amalgam of parameters and<br />
comments. A parameter is formed as id - separator - value, where the separator is the ‘=’ charac-<br />
ter and the value may be a keyword or a string <strong>de</strong>limited by the apostrophe character as the<br />
value. A comment may appear anywhere in the file and is i<strong>de</strong>ntified by the ‘#’ character. Unlike<br />
the previous examples, the PostgreSQL configuration files do not impl<strong>em</strong>ent the block pattern,<br />
although there se<strong>em</strong>s to be a followed convention in which a set of parameters is prece<strong>de</strong>d by a<br />
comment, which is similar to a block.<br />
Mantis<br />
The Mantis PHP Bug Tracker [Gro09a] configuration file (Listing 1.5) impl<strong>em</strong>ents parameters of<br />
the form $ - key - separator - value, where the separator is the ‘=’ character and the value is a<br />
keyword or a string <strong>de</strong>limited by apostrophes or quotes. It also impl<strong>em</strong>ents comments, which<br />
are text lines that start with the ‘#’ character.<br />
6
1. INTRODUCTION 1.2. Probl<strong>em</strong> Description<br />
Listing 1.4: PostgreSQL configuration file excerpt<br />
#-----------------------------------------------<br />
# CLIENT CONNECTION DEFAULTS<br />
#-----------------------------------------------<br />
datestyle = ’iso, mdy’<br />
timezone = unknown # actually, <strong>de</strong>faults to TZ<br />
#timezone_abbreviations = ’Default’<br />
# --- database variables ---------<br />
Listing 1.5: Mantis configuration file excerpt<br />
# set these values to match your setup<br />
$g_hostname = "localhost";<br />
$g_db_username = "mantisdbuser";<br />
$g_webmaster_<strong>em</strong>ail = ’webmaster@example.com’;<br />
$g_allow_file_upload = ON;<br />
1.2.4 Conclusion<br />
The VIRTU project usage scenarios also allowed us to conclu<strong>de</strong> that overall, configuration files<br />
either follow three formats:<br />
• Apache-like format;<br />
• INI-like format;<br />
• XML-like format.<br />
The Apache-like format is characterized by <strong>de</strong>fining parameters as key/value pairs separated<br />
by spaces or a similar character, blocks <strong>de</strong>limited by a hea<strong>de</strong>r and a footer, containing other<br />
patterns, and comments.<br />
The INI-like format <strong>de</strong>fines parameters as key/value pairs separated by an equal, space or a<br />
similar character, blocks <strong>de</strong>limited by a hea<strong>de</strong>r and comments.<br />
The XML-like format <strong>de</strong>fines blocks as XML el<strong>em</strong>ents <strong>de</strong>limited by a hea<strong>de</strong>r and a footer, if<br />
they contain other blocks, or a single tag if they do not contain other blocks, parameters as XML<br />
attributes contained in an XML tag, and comments.<br />
SmART should provi<strong>de</strong> built-in support for these three configuration file categories, seen<br />
as most of the configuration files fit in one of these categories. However, the tool must also be<br />
extensible to support new configuration file formats.<br />
7
1. INTRODUCTION 1.3. Probl<strong>em</strong> Approach<br />
1.3 Probl<strong>em</strong> Approach<br />
Section 1.2 i<strong>de</strong>ntified two ways to configure applications in virtual appliances: pre and post-<br />
installation. The pre-installation approach has no outstanding requir<strong>em</strong>ent and operates by<br />
generating as many application packages as different required configurations for that applica-<br />
tion, and does not allow for the re-configuration of an application in a practical fashion (i.e.,<br />
without resorting to that application re-installation). On the other hand, the post-installation<br />
approach requires previous knowledge of the software running insi<strong>de</strong> the VA but, contrary<br />
to the previous approach, each different configuration only requires a new configuration file<br />
version, and allows for the practical re-configuration of an application. Given the benefits and<br />
drawbacks of each approach, the post-installation approach requir<strong>em</strong>ent was found tolerable<br />
and moreover, allows for better functionality than the pre-installation approach and, therefore,<br />
SmART will follow this discipline.<br />
The adopted approach operates by conducting a lexical analysis on an application’s con-<br />
figuration files with the aim of extracting the relevant information for that application con-<br />
figuration from th<strong>em</strong>. This raises a significant requir<strong>em</strong>ent which says that the configuration<br />
files must be in text format. A consequent implication of this requir<strong>em</strong>ent is that special for-<br />
mats, like the Windows OS registry or binary files, may not be configurable using the approach.<br />
However, there exist <strong>de</strong>dicated parsers for the treatment of those formats and these can be used<br />
by the framework to provi<strong>de</strong> support for the mentioned kinds of formats.<br />
Still in the scope of the applications supported by SmART, Section 1.2.3 conclu<strong>de</strong>d that, at a<br />
conceptual level, the structure of the configuration files expected to be found more regularly by<br />
the tool can be reduced to three types: INI-like, XML-like and Apache-like. These three types were<br />
already presented and impl<strong>em</strong>ent three patterns: parameters, comments and blocks, besi<strong>de</strong>s<br />
the patterns specific to a certain application. One way of tackling this probl<strong>em</strong> is to reduce<br />
the configuration files of any application to a generic structure, <strong>de</strong>ttached from its application<br />
specifics, which contains the relevant el<strong>em</strong>ents for its application configuration. This structure<br />
can then be modified without any knowledge of the application to which it belongs. Once<br />
altered, that structure is again converted to a configuration file in its original syntax, containing<br />
the applied modifications.<br />
1.4 Contributions<br />
This dissertation contributions for the automatic application configuration are:<br />
• I<strong>de</strong>ntification of commonalities amidst configuration files structures;<br />
• Proposal of a framework for the rebuilding of configuration files of an application;<br />
• Impl<strong>em</strong>entation of the proposed framework;<br />
• Provision of the VIRTU project with a state-of-the-art and innovative tool for application<br />
reconfiguration, in<strong>de</strong>pen<strong>de</strong>nt of its vendor.<br />
8
1. INTRODUCTION 1.5. Document Organization<br />
1.5 Document Organization<br />
The rest of the dissertation is structured as follows: the next chapter covers the state of the art of<br />
the related subjects to this thesis, Chapter 3 <strong>de</strong>scribes the proposed architecture of the SmART<br />
tool, Chapter 4 explains the tool impl<strong>em</strong>entation <strong>de</strong>cisions, Chapter 5 provi<strong>de</strong>s the validation<br />
process carried to the tool, Chapter 6 approaches the integration of SmART with the VIRTU<br />
virtualization platform, and Chapter 7 reveals the final consi<strong>de</strong>rations about this thesis.<br />
9
2<br />
State of the Art and Related Work<br />
This section aims at presenting the state of the art in automatic application configuration, as<br />
well as studying the tools which may be used to tackle the probl<strong>em</strong> i<strong>de</strong>ntified in Chapter 1.<br />
To better un<strong>de</strong>rstand the outlines of the probl<strong>em</strong>, this section starts by explaining the con-<br />
text of this dissertation. Namely, the virtual appliances th<strong>em</strong>e is explored with the purpose of<br />
making it more natural.<br />
Afterwards, the existing techniques to <strong>de</strong>al with the probl<strong>em</strong> are analysed. There is, never-<br />
theless, a particularity regarding this part. As previsouly mentioned in Chapter 1, the configu-<br />
ration of applications is still mostly a manual task. As such, the existing references consi<strong>de</strong>rably<br />
relevant to this th<strong>em</strong>e are very few. Therefore, this dissertation consists on one of the first con-<br />
tributions for the probl<strong>em</strong> of automatic configuration of applications.<br />
Finally, the adopted concepts and tools to mitigate the probl<strong>em</strong> are analysed. The automatic<br />
file recognition th<strong>em</strong>e is studied by i<strong>de</strong>ntifying two parser generators and <strong>de</strong>scribing th<strong>em</strong>.<br />
Finally, it is seen how the file can be represented in an abstract, in<strong>de</strong>pen<strong>de</strong>nt from its original<br />
language, way.<br />
2.1 Virtual Appliances<br />
A Virtual Appliance (VA) is a minimal virtual machine (VM, Section 2.1.1) composed of pre-<br />
configured and pre-installed applications plus an optimized operating syst<strong>em</strong> called Just<br />
Enough Operating Syst<strong>em</strong> (JeOS) (Figure 2.1). VAs are normally created to perform a specific<br />
task in the most effective way, therefore they only contain the essential and necessary resources<br />
for the execution of that task, contrary to the regular VM where all of the kernel OS features are<br />
present, even those whose use is seldom.<br />
11
2. STATE OF THE ART AND RELATED WORK 2.1. Virtual Appliances<br />
2.1.1 Virtualization<br />
Virtual Appliance<br />
JeOS<br />
Virtualization Layer<br />
Physical Hardware<br />
Figure 2.1: Virtual appliance<br />
Virtualization is a very broad term and refers to something which does not exist physically<br />
but appears to exist. Think of it in the context of virtual reality. With virtual m<strong>em</strong>ory, for<br />
example, computer software gains access to more m<strong>em</strong>ory than is physically installed, via<br />
the background swapping of data to disk storage. Similarly, virtualization techniques can be<br />
applied to other IT infrastructure layers such as networks, storage, laptop or server hardware,<br />
operating syst<strong>em</strong>s and applications.<br />
The concept of platform virtualization refers to the technique for hiding the physical char-<br />
acteristics of computing resources from the way in which other syst<strong>em</strong>s, applications or end<br />
users interact with those resources. In other words, virtualization allows multiple logical com-<br />
puting units to run on a single physical computing unit, like in the Figure 2.2. This is done with<br />
the aid of a software layer (alias virtualization layer, virtualization manager, virtual machine<br />
monitor or hypervisor) which provi<strong>de</strong>s the illusion of a “real” machine to multiple instances of<br />
“virtual machines”.<br />
Virtualization Layer<br />
Computational Unit<br />
Figure 2.2: Physical unit running four VMs<br />
12
2. STATE OF THE ART AND RELATED WORK 2.1. Virtual Appliances<br />
The virtualization concept goes back to the 1960s when corporate mainframes were in a<br />
severe un<strong>de</strong>rutilization state [oV08]. By then, some IBM research personnel were working on<br />
the CP-40 OS <strong>de</strong>signed to run on the Syst<strong>em</strong>/360 time-sharing syst<strong>em</strong>. It was the first OS to<br />
completely virtualize a syst<strong>em</strong> (namely Syst<strong>em</strong>/360) so that other S/360 OSes could be tested<br />
and executed. This syst<strong>em</strong> paved the way for virtualization as known nowadays and concepts<br />
pioneered by CP-40 are still actual, like the case where an abstraction layer catches traps and<br />
simulates th<strong>em</strong>. Curiously, CP-40 is still supported by IBM mainframes (Syst<strong>em</strong> z10). Presently,<br />
mainframes came to suffer from the same un<strong>de</strong>rutilization probl<strong>em</strong> and so virtualization is en<br />
vogue once again.<br />
2.1.2 Motivation<br />
Nowadays, <strong>de</strong>ployment via download or DVD <strong>de</strong>fines the typical software distribution mo<strong>de</strong>l.<br />
Despite its simplicity, this mo<strong>de</strong>l features limitations such as <strong>de</strong>ployment and configuration<br />
complexity. Other flaws that might be pointed are the huge number of application versions to<br />
maintain, which leads to IT resources draining; having to cope with a myriad of hardware plat-<br />
forms, which leads to intensive time-consuming testings; In<strong>de</strong>pen<strong>de</strong>nt Service Vendors (ISVs)<br />
might see their revenues <strong>de</strong>creased since if the customer is content with the product, he will<br />
only upgra<strong>de</strong> when a groundbreaking feature comes out; and so forth.<br />
As a response to these challenges, some alternative <strong>de</strong>ployment mo<strong>de</strong>ls arose. Such is the<br />
case of Software as a Service (SaaS), hardware appliances and virtual appliances.<br />
Software as a Service (SaaS)<br />
This approach consists on providing a service by hosting a software application that customers<br />
over the Internet can use. In this way, the need for install and configure on the customer’s<br />
computer is eliminated, so probl<strong>em</strong>s as software maintenance and support are no longer cus-<br />
tomer’s responsibility but software vendor. The revenue becomes different: customers pay<br />
when they want to use the service, rather than having a single expense when purchasing the<br />
application.<br />
However, this will turn the application vendor into a service provi<strong>de</strong>r that has to maintain<br />
its infrastructure. Also, given the variety of existing open-source solutions and the inexpensive<br />
hardware, it appeals economically to the customer to keep the application running un<strong>de</strong>r its<br />
control.<br />
Hardware Appliances<br />
Another approach to software distribution is the creation of hardware appliances bundling<br />
the application with hardware capable of running it. The customer just needs to plug in the<br />
appliance and turn it on. This approach also clears the need for the customer to install and<br />
configure the application, but this forces the application vendor to enter a different market, the<br />
hardware market.<br />
13
2. STATE OF THE ART AND RELATED WORK 2.1. Virtual Appliances<br />
Virtual Appliances<br />
The existing hardware virtualization techniques allow the leveraging of the hardware appli-<br />
ances advantages without the hardware requir<strong>em</strong>ent. The virtual appliance vendor packs in<br />
a set of required applications with a JeOS on a virtual machine that can be executed on the<br />
vast majority of existing hypervisors given the appearance of virtualization format standards<br />
(OVF). The <strong>de</strong>ployment of the appliance is simple and the appliance comes pre-configured.<br />
The appliance vendors are able to customize the applications and guest OS as much as they<br />
want, thus leading to unseen efficiency. Updates are vendor’s responsibility and just require<br />
him to address the flaws i<strong>de</strong>ntified in the former version, produce an upgra<strong>de</strong>d VA and <strong>de</strong>ploy<br />
it in the customer’s hardware. Manag<strong>em</strong>ent is ma<strong>de</strong> dramatically simpler by the use of man-<br />
ag<strong>em</strong>ent tools created by the appliance vendors [Sta07]. Moreover, VAs supply customers with<br />
all the benefits of virtualization: increased hardware use, reduction of physical resources, etc.<br />
2.1.3 Open Virtual Machine Format<br />
The Open Virtual Machine Format (OVF) is a joint effort of various virtualization solution ven-<br />
dors such as XenSource, VMware and Microsoft as a part of the Distributed Manag<strong>em</strong>ent Task<br />
Force Inc. It consists on an open, secure, portable, efficient and extensible format for packaging<br />
and distribution of VMs [VX]. With OVF, VMs which are created on one platform can also be<br />
managed and used on other platforms, providing platform in<strong>de</strong>pen<strong>de</strong>nce, although it enables<br />
platform-specific enhanc<strong>em</strong>ents to be captured.<br />
OVF differs from other formats such as VMware’s VMDK and Microsoft’s VHD since these<br />
are run-time VM images. Although they are currently used for VM transportation, they do not<br />
address probl<strong>em</strong>s such as multi-tiered VMs consisting of multiple in<strong>de</strong>pen<strong>de</strong>nt VMs, or VMs<br />
with multiple disks.<br />
Another important aspect in the scope of OVF is its integrity. OVF was <strong>de</strong>signed so that<br />
the VM configures itself, without the need for the virtualization platform where it is installed<br />
to recognize the VM’s file syst<strong>em</strong>. This is particularly useful since it allows VMs to run on any<br />
OS and virtualization platform which supports the OVF format.<br />
OVF is extr<strong>em</strong>ely useful in the Virtual Appliance case since it provi<strong>de</strong>s essential foundations<br />
for VA’s such as efficiency, portability, ease of use and distribution, etc.<br />
An OVF package can be stored as a single file using the TAR format un<strong>de</strong>r the .ova extension<br />
(open virtual appliance or application). It consists of the following [DMT08]:<br />
• one OVF <strong>de</strong>scriptor file (<strong>de</strong>scriptor file or .ovf file) containing the package metadata and<br />
its contents;<br />
• zero or one OVF manifest file (manifest file or .mf file) containing the SHA-1 digests of<br />
individual files in the package;<br />
• zero or one certification file (certification file or .cert file) containing the OVF package<br />
signature digest along with the base64-enco<strong>de</strong>d X.509 certificate.<br />
14
2. STATE OF THE ART AND RELATED WORK 2.2. Automatic Configuration of Applications<br />
• zero or more disk images files<br />
• zero or more additional resource files, such as ISO images<br />
OVF specification v1.0.0 has been released on Sept<strong>em</strong>ber, 2008 and is prone to intensive<br />
<strong>de</strong>velopment.<br />
2.1.4 Virtual Appliances in Real Life<br />
A good example of an application of virtual appliances is the Amazon Elastic Compute Cloud [Ama09],<br />
also known as Amazon EC2. It is a service which allows customers to rent hosted computing<br />
capacity in or<strong>de</strong>r to run their applications. The customers can create a VA comprised by appli-<br />
cations, libraries, data and associated configuration settings or use a pre-constructed image and<br />
then upload it in the Amazon Machine Image format to the Amazon storage service, Amazon<br />
Simple Storage Service (S3). VAs provi<strong>de</strong> the means for elastic computing by enabling a fast<br />
and efficient way for service expansion.<br />
Whereas previously SaaS solutions failed to succeed due to the lack of control of the ser-<br />
vice from the customer and the maintenance costs involved, Amazon EC2 uses multiple Xen<br />
hypervisor no<strong>de</strong>s so that customers can build VAs containing their applications and host th<strong>em</strong><br />
outsi<strong>de</strong> their domain. In this way, the vendor is able to provi<strong>de</strong> the service <strong>de</strong>sired by the<br />
customer without the need to maintain the solution, focusing on keeping a secure, reliable, ef-<br />
ficient and inexpensive environment for the VAs to run on. On the other hand, the customers<br />
now have the control over their services and may update th<strong>em</strong> any time necessary without hav-<br />
ing to wait for the vendor. Furthermore, customers are only billed for what they consume (i.e.,<br />
instance uptime or data transferred), opposed to paying an established fee even if the service<br />
usage is low or non-existant.<br />
2.2 Automatic Configuration of Applications<br />
To the best of our knowledge, our approach is the first to exploit the similarities among con-<br />
figuration files to allow for automatic, vendor-in<strong>de</strong>pen<strong>de</strong>nt and on-the-fly application recon-<br />
figuration. Similar existing projects, such as AutoBash [SAF07] or Chronus [WCG04], take on<br />
automatic application configuration as a way to assist the r<strong>em</strong>oval of configuration bugs. Auto-<br />
Bash <strong>em</strong>ploys the causality support within the Linux kernel to track and un<strong>de</strong>rstand the actions<br />
performed by a user on an application and then recurs to a speculative execution to rollback<br />
a process, if it moved from a correct to an incorrect state. Chronus, on the other hand, uses a<br />
virtual machine monitor to impl<strong>em</strong>ent rollback, at the expense of an entire computer syst<strong>em</strong>.<br />
It also focuses a more limited probl<strong>em</strong>: finding the exact moment when an application ceased<br />
to work properly.<br />
Two other projects, better related to this work, are Thin Crust [Cru08] and<br />
SmartFrog [GGL + 09]. Both projects aim at automatic application configuration, but take a<br />
different approach than ours. Following is a brief summary of both.<br />
15
2. STATE OF THE ART AND RELATED WORK 2.3. Automatic Recognition of Configuration Files<br />
2.2.1 Thin Crust<br />
Thin Crust is an open-source set of tools and meta-data for the creation of VAs. It features<br />
three key components: Appliance Operating Syst<strong>em</strong> (AOS), Appliance Creation Tool (ACT)<br />
and Appliance Configuration Engine (ACE). The AOS is a minimal OS built from a Fedora<br />
Kickstart file 1 , which can be cut down to just the required packages to run an appliance. The<br />
user may download a ready-to-run AOS image or may create his own through the ACT. The<br />
ACE is ran at VA boot time and loads the appliance recipe. The appliance recipe contains VA<br />
metadata and the modules used by the VA. If it does not match the appliance configuration,<br />
the latter is changed to reflect the changes. Finally, Thin Crust supports VMware, KVM and<br />
EC2 (see Section 2.1.4) by providing conversion tools from and to the mentioned formats.<br />
2.2.2 SmartFrog<br />
SmartFrog (Smart Framework for Object Groups) is a framework for the creation of<br />
configuration-based syst<strong>em</strong>s. Its objective is to make the <strong>de</strong>sign, <strong>de</strong>ployment and manag<strong>em</strong>ent<br />
of distributed component-based syst<strong>em</strong>s simpler and more robust. It <strong>de</strong>fines a language to<br />
<strong>de</strong>scribe component configurations and a runtime environment to activate and manage those<br />
components.<br />
One of the major causes for the probl<strong>em</strong>s in large distributed syst<strong>em</strong>s <strong>de</strong>sign is i<strong>de</strong>ntified<br />
by SmartFrog as the ad-hoc way in which such syst<strong>em</strong>s are <strong>de</strong>signed. This results in application<br />
configuration data scattered by the syst<strong>em</strong>, often causing its repetition.<br />
In SmartFrog, there is the notion of a SmartFrog component and a SmartFrog syst<strong>em</strong>, which is<br />
composed by various such components. A SmartFrog component is constituted by three parts:<br />
the lifecycle manager, which applies a configuration on a component; configuration data, which<br />
<strong>de</strong>fines the behaviour of a component; and the managed component, which may be a piece of<br />
software impl<strong>em</strong>enting any functionality-specific interface. Each component is monitorized by<br />
its lifecycle manager and must report any failure to the other components of the syst<strong>em</strong>. The<br />
components can also be distributed on a network.<br />
2.3 Automatic Recognition of Configuration Files<br />
The lexical analysis of the file with the objective of producing that same file in a different struc-<br />
ture provi<strong>de</strong>s a way for the tool to abstract itself from each configuration file language specifics,<br />
refining the configuration file down to just the essential for configuration (i.e., the el<strong>em</strong>ents<br />
nee<strong>de</strong>d to modify the application settings, such as parameter keys and attributes). The lexi-<br />
cal analysis of a file is accomplished by a parser, which recognizes the file original syntax and<br />
produces a version of the same file in a different structure.<br />
Configuration file parsers are produced by grammar compilers (or parser generators). A<br />
grammar compiler reads a grammar that recognizes a certain configuration file language and<br />
1<br />
16
2. STATE OF THE ART AND RELATED WORK 2.3. Automatic Recognition of Configuration Files<br />
compiles it, resulting in the generation of a parser for a specific configuration file language.<br />
Following are presented some parser generators:<br />
2.3.1 SableCC<br />
SableCC [GH98] is an object-oriented framework that generates compilers, or parsers, in the<br />
Java programming language. This framework is based on two fundamental <strong>de</strong>sign <strong>de</strong>cisions.<br />
Firstly, the framework uses object-oriented techniques to automatically build a strictly-typed<br />
abstract syntax tree that matches the grammar of the compiled language and simplifies <strong>de</strong>bug-<br />
ging. Secondly, the framework generates tree-walker classes using an exten<strong>de</strong>d version of the<br />
visitor <strong>de</strong>sign pattern which enables the impl<strong>em</strong>entation of actions on the no<strong>de</strong>s of the abstract<br />
syntax tree using inheritance.<br />
SableCC specification files do not contain any action co<strong>de</strong>. Instead, SableCC generates an<br />
object-oriented framework in which actions can be ad<strong>de</strong>d by <strong>de</strong>fining new classes containing<br />
the action co<strong>de</strong>. This leads to a shorter <strong>de</strong>velopment cycle, allowing for the rapid prototyping<br />
of SmART.<br />
Given a grammar, SableCC’s produces a set of packages, namely:<br />
• analysis: contains different tree walkers (e.g., <strong>de</strong>pth first, reversed);<br />
• lexer: contains the el<strong>em</strong>ents nee<strong>de</strong>d for the lexical analysis of the grammar;<br />
• no<strong>de</strong>: classes containing no<strong>de</strong> representations;<br />
• parser: contains the parser class.<br />
None of the automatically produced classes ought to be modified. Instead, all of the user<br />
generated co<strong>de</strong> should be put in classes extending those created by SableCC. By doing this,<br />
every time a probl<strong>em</strong> arises (e.g., error in a grammar), it can be easily located and corrected by<br />
modifying only a small portion of the co<strong>de</strong>. Another aspect of discussible importance is that<br />
SableCC is distributed un<strong>de</strong>r the GNU Lesser General Public License.<br />
Notwithstanding, SableCC also reveals some significant shortcomings. SableCC does not<br />
support error productions. In other words, when a generated parser comes upon an unrecog-<br />
nizable token in a configuration file, it does not allow the parse to advance further beyond that<br />
token, consequently halting the parse on that position. Since error productions are a common<br />
feature on parser generators, this lackage was not noticed upon the choice. This, in turn, sev-<br />
ered the ability to produce multiple recognized file blocks to just one. The parsing statistics<br />
also become unreliable, since a parser might not recognize the first token a configuration file<br />
and recognize the rest of the file, but without error productions, parsing will inevitably stop in<br />
the beginning of the file and that parser will be reported to have parsed 0% of the file, when in<br />
fact it would manage to parse nearly 100% of the file.<br />
17
2. STATE OF THE ART AND RELATED WORK 2.4. Representation of Configuration Files in a Generic Syntax<br />
2.3.2 JavaCC<br />
The Java Compiler Compiler (JavaCC) [Pro09] is a tool that reads a grammar specification and<br />
converts it to a Java program that can recognize matches to the grammar. In addition to the<br />
parser generator itself, JavaCC provi<strong>de</strong>s other standard capabilities related to parser generation<br />
such as tree building, actions, <strong>de</strong>bugging, etc.<br />
JavaCC generates top-down parsers (i.e., start at the root of the <strong>de</strong>rivation tree, picks a pro-<br />
duction and tries to match the input tokens [oM]), <strong>de</strong>clares the lexical and grammar specifica-<br />
tions in one file, making grammars easier to read and maintain, supports s<strong>em</strong>antic lookahead,<br />
uses the Exten<strong>de</strong>d Backus-Naur Form (i.e., operators *, + and ?) and supports error recovery in<br />
two forms: shallow recovery and <strong>de</strong>ep recovery. In shallow recovery, if an input token does not<br />
match any production, it is possible to move to the next <strong>de</strong>sired token (e.g., s<strong>em</strong>icolon). Deep<br />
recovery is similar to the shallow recovery, but also allows to recover from an error insi<strong>de</strong> a<br />
production, which is impossible resorting to shallow recovery alone.<br />
2.4 Representation of Configuration Files in a Generic Syntax<br />
The concept of generic syntax refers to a language-in<strong>de</strong>pen<strong>de</strong>nt syntax used in the process of<br />
automatic application configuration. The generic syntax is used to abstract the configuration<br />
files from their original languages. When a configuration file is represented in a generic syntax,<br />
another in<strong>de</strong>pen<strong>de</strong>nt entity which recognizes that syntax is able to manipulate the file without<br />
having knowledge of what the original syntax was, or what application uses that file. The cho-<br />
sen generic syntax must provi<strong>de</strong> a practical way to traverse and manipulate files. Furthermore,<br />
it must be wi<strong>de</strong>ly supported and well documented. Its software license must also allow it to be<br />
used freely.<br />
Consi<strong>de</strong>ring the prievous requir<strong>em</strong>ents, the chosen syntax was the eXtensible Markup Lan-<br />
guage (XML) since it is a broadly adopted and supported standard. XML allows for the struc-<br />
turing of configuration files in a way that makes th<strong>em</strong> easily manipulable and traversable.<br />
Some available impl<strong>em</strong>entations of XML parsers were i<strong>de</strong>ntified in many programming<br />
languages. The criteria to choose from an XML parser impl<strong>em</strong>entation inclu<strong>de</strong>s factors such as<br />
the programming languages it is available on and what it allows the user to do resulting data<br />
structure from the parse.<br />
Since the programming language used to <strong>de</strong>velop the tool is going to be Java, two major<br />
XML parser impl<strong>em</strong>entations in Java were consi<strong>de</strong>red: the Simple API for XML (SAX) and the<br />
Domain Object Mo<strong>de</strong>l (DOM). Following is a brief <strong>de</strong>scription of both.<br />
Simple API for XML<br />
The Simple API for XML (SAX) is an Application Programming Interface (API) for XML in Java,<br />
although it is available in many other programming languages. It is event-driven: it reads from<br />
a stream and reacts when processing instructions, el<strong>em</strong>ents, comments and text.<br />
18
2. STATE OF THE ART AND RELATED WORK 2.4. Representation of Configuration Files in a Generic Syntax<br />
Being event-oriented, SAX does not impl<strong>em</strong>ent a representation of the document in m<strong>em</strong>-<br />
ory and, therefore, m<strong>em</strong>ory accesses are seldom in quantity. This leads to some m<strong>em</strong>ory in<strong>de</strong>-<br />
pen<strong>de</strong>nce and fairly good m<strong>em</strong>ory consumption ratings, also excelling in large files parsing.<br />
SAX parses in an uni-directional way since it does not allow previously read data to be read<br />
again, without restarting the parser. This consists on a probl<strong>em</strong> when a whole XML document<br />
must be in m<strong>em</strong>ory in or<strong>de</strong>r to be properly parsed, as SAX requires the user to start the parsing<br />
again to get values previously obtained.<br />
Domain Object Mo<strong>de</strong>l<br />
DOM is a cross-platform and language-in<strong>de</strong>pen<strong>de</strong>nt interface for creating and manipulating<br />
XML documents in m<strong>em</strong>ory. It is a World Wi<strong>de</strong> Web Consortium (W3C) standard.<br />
It loads an XML document to m<strong>em</strong>ory and allows for dynamic access to it, allowing for<br />
bi-directional parsing. DOM represents an XML document in m<strong>em</strong>ory in a tree-like structure.<br />
Furthermore, it is very well supported in many programming languages, including Java.<br />
Since DOM keeps a document in m<strong>em</strong>ory after it is parsed, a drawback is the time spent<br />
to parse a big file on the grounds that many m<strong>em</strong>ory allocation requests might sum up to a<br />
consi<strong>de</strong>rable time.<br />
19
3<br />
An application reconfiguration<br />
framework<br />
Chapter 1 i<strong>de</strong>ntified the probl<strong>em</strong> of automatic application configuration, along with the con-<br />
cept of pattern in a configuration file, whereas Chapter 2 studied the existing tools and tech-<br />
nologies that can help to mitigate the probl<strong>em</strong>. Using that knowledge, this chapter presents the<br />
framework for automatic application configuration, the major contribution of this dissertation.<br />
In truth, the proposed framework reconfigures applications (possibly fresh installations or<br />
<strong>de</strong>ployments of an application) instead of configuring th<strong>em</strong> at <strong>de</strong>ployment time, but for the<br />
sake of clarity, the probl<strong>em</strong> will be addressed in the r<strong>em</strong>ain<strong>de</strong>r of the dissertation as the auto-<br />
matic configuration of applications. The proposed framework requires three steps to config-<br />
ure an application automatically: conversion from original to generic syntax, file modification<br />
and conversion back to original syntax. Only the first and third belong to the scope of this<br />
work. The configuration resorts to the lexical and syntatic analysis of the configuration file and<br />
subsequent production of a data structure which is equivalent to the original file. After the<br />
data-structure is properly modified, it is reconverted back to the original file form.<br />
We start by i<strong>de</strong>ntifying the functional and non-functional requir<strong>em</strong>ents of the tool in Sec-<br />
tion 3.1, Section 3.2 provi<strong>de</strong>s a broad view over the solution proposal, Sections 3.3 and 3.4 <strong>de</strong>tail<br />
the required components in each step and their interfaces, Section 3.5 approaches the file mod-<br />
ification part by proposing some ways to modify the intermediate file in generic syntax and<br />
providing some information about the generic syntax and Section 3.6 <strong>de</strong>als with the support<br />
for file formats not recognizable by the framework.<br />
21
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.1. Architectural Requir<strong>em</strong>ents<br />
3.1 Architectural Requir<strong>em</strong>ents<br />
Before approaching the proposal of a framework for the automatic application configuration,<br />
the tool requir<strong>em</strong>ents must be i<strong>de</strong>ntified. This section presents the functionalities which the<br />
tool is expected to provi<strong>de</strong>, in the form of use cases. A use case <strong>de</strong>fines a goal-oriented set<br />
of interactions between external actors and the tool. Following is a list of functional and non-<br />
functional requir<strong>em</strong>ents:<br />
1. The user must be able to convert a configuration file syntax from its original syntax to<br />
a generic one, in<strong>de</strong>pen<strong>de</strong>ntly of the application.<br />
Description: The user must be able to try parsing the configuration file with the available<br />
parsers.<br />
Non-functional requir<strong>em</strong>ents:<br />
Performance: The generated file with the generic syntax must be as simple as possible.<br />
2. The user must be able to <strong>de</strong>fine grammars for configuration file languages.<br />
Description: If there are no suitable parsers for a given configuration file, the user must<br />
be able to <strong>de</strong>fine a grammar that recognizes the new configuration file language.<br />
Non-functional requir<strong>em</strong>ents:<br />
Usability: The grammar <strong>de</strong>finition syntax should be a broadly adopted one.<br />
Usability: To ease the parser generation process, the user must be able to iterate through<br />
the previously built grammars so as to rollback any change ma<strong>de</strong> on a grammar.<br />
3. The user must be able to produce a parser from a grammar.<br />
Description: When the user builds a grammar for a new configuration file language, there<br />
must be a means to compile that grammar in or<strong>de</strong>r to generate a parser.<br />
Non-functional requir<strong>em</strong>ents:<br />
Usability: The user must be able to add parsers built outsi<strong>de</strong> the tool.<br />
4. The user must have access to the parser compilation trace.<br />
Description: When a grammar is compiled, the user should be able to check on the parser<br />
compilation trace to see if it was successfully compiled or whether any error persists in<br />
the grammar <strong>de</strong>claration.<br />
22
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.1. Architectural Requir<strong>em</strong>ents<br />
Non-functional requir<strong>em</strong>ents:<br />
Usability: The error messages must clearly i<strong>de</strong>ntify the source of the error.<br />
5. The user must receive information relative to the grammar fitness with a given config-<br />
uration file.<br />
Description: When the user att<strong>em</strong>pts at parsing a configuration file with a given parser,<br />
he/she must be informed if the parsing was successful or not, as well as the quantity of<br />
file recognized by that parser.<br />
Non-functional requir<strong>em</strong>ents:<br />
Usability: The sections of the configuration file that were parsed and those that were not<br />
must be clearly i<strong>de</strong>ntified.<br />
6. The user must be able to store a functional parser generated by the tool, in or<strong>de</strong>r to be<br />
used on later tool runs.<br />
Description: When the user checks a new parser to parse a configuration file entirely,<br />
he/she must be able to store it in a repository so it can be reused.<br />
Non-functional requir<strong>em</strong>ents:<br />
Security: The user must be able to see the parsing outcome in or<strong>de</strong>r to check if the parser<br />
is in<strong>de</strong>ed operating as inten<strong>de</strong>d to.<br />
7. The user must be able to reconvert a configuration file syntax from generic syntax to<br />
the original one.<br />
Description: Given a configuration file in generic syntax, the user must be able to convert<br />
it into its original syntax, keeping its functionality unharmed.<br />
8. File conversion must not eliminate comments.<br />
Description: On the original to generic syntax conversion, the comments should be stored<br />
in or<strong>de</strong>r to show up in the final file.<br />
9. The user must be able to halt the tool execution at some point and continue the config-<br />
uration process later.<br />
Description: In the middle of the configuration process (i.e., right after the original to<br />
generic syntax conversion), the administrator should be able to halt the execution flow,<br />
have the necessary data stored, such as the file in the generic syntax or the tentative<br />
23
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.2. Automatic Application Configuration<br />
parsers, and continue from the same state later.<br />
10. The user must be able to manually <strong>de</strong>lete parsers from the parser repository.<br />
Description: The user must be able to manually <strong>de</strong>lete parsers from the parser repository<br />
so that the user may intervene if the parser repository becomes to big, or if a certain parser<br />
becomes obsolete.<br />
3.2 Automatic Application Configuration<br />
Having i<strong>de</strong>ntified the requir<strong>em</strong>ents for the tool, it is now possible to tackle a possible solution<br />
for the probl<strong>em</strong>. This section presents a framework which is the solution proposal for the<br />
automatic configuration of applications.<br />
The application configuration files are read by the tool, which parses th<strong>em</strong> in or<strong>de</strong>r to con-<br />
vert their syntax from the original to a generic, application-in<strong>de</strong>pen<strong>de</strong>nt, one. This allows for<br />
the configuration files to be manipulated and altered in the same way, for any application,<br />
through an agent which recognizes the generic syntax.<br />
Being in generic syntax, the file can be efficiently modified by an agent which operates on<br />
that kind of syntax, such as an automated script. Ensuing the file modification, the tool is<br />
responsible to do the inverse conversion, back to the file original form. Once the file has been<br />
converted to the generic syntax, the characteristics of the original syntax have been aprehen<strong>de</strong>d<br />
and can be used to reconvert the file back to its original syntax.<br />
The configuration process (Figure 3.1) can be divi<strong>de</strong>d into three main stages:<br />
1. Configuration file extraction;<br />
2. Original to generic syntax conversion;<br />
3. File modification;<br />
4. Generic to original syntax conversion.<br />
The second stage is accomplished through an Original to Generic syntax Converter (OGC)<br />
and the fourth by a Generic to Original syntax Converter (GOC). This dissertation points ways<br />
in which OGC and GOC might evolve. The first and third stages are not on the original work<br />
scope and therefore are not tackled in <strong>de</strong>tail. Nevertheless, Section 3.5 approaches the file<br />
modification area superficially, hinting at some possible ways of <strong>de</strong>aling with the subject and<br />
i<strong>de</strong>ntifying possible operational constraints.<br />
3.3 Original to Generic syntax Converter<br />
The Original to Generic syntax Converter (OGC) is structured like a three-tier<br />
architecture [Ram00]. The three-tier architecture consists of a software <strong>de</strong>sign pattern which<br />
24
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.3. Original to Generic syntax Converter<br />
!!""#$%&'$()*<br />
+$)&,$-.<br />
!/()0$12,&'$()*<br />
0$#-.<br />
!""#$%&'$()*0$#-.<br />
?<br />
5,$1$)&#*'(*1-)-,$%*<br />
.3)'&4*%()6-,'-, !/()0$12,&'$()*0$#-*<br />
!/()0$12,&'$()*0$#-*<br />
$)*(,$1$)&#*.3)'&4<br />
<<br />
$)*1-)-,$%*.3)'&4<br />
7$#-*8(9$0$%&'$()<br />
=<br />
Figure 3.1: SmART Work Flow<br />
;-)-,$%*'(*(,$1$)&#*<br />
.3)'&4*%()6-,'-, !!""#$%&'$()*<br />
!:(9$0$-9*<br />
%()0$12,&'$()*0$#-*<br />
$)*1-)-,$%*.3)'&4<br />
><br />
+$)&,$-.<br />
!:(9$0$-9*0$#-*$)*<br />
(,$1$)&#*.3)'&4<br />
!""#$%&'$()*0$#-.<br />
Component Description<br />
User Interface The User Interface makes the link between the user and the<br />
tool. It can be thought of as a command interpreter, which<br />
reacts to user or<strong>de</strong>rs by calling other tool components. Additionally,<br />
it is used to simplify some otherwise complex<br />
tasks, such as building grammars for configuration files.<br />
Table 3.1: Presentation Layer Components<br />
<strong>de</strong>fines three inter-related tiers, each with its own responsibilities. In this work context, the<br />
tiers are:<br />
Presentation Layer. Contains the presentation logic, including simple control and user input<br />
validation.<br />
Logic Layer. Contains the processing logic and the data access.<br />
Storage Layer. Provi<strong>de</strong>s the data storage.<br />
In this topology, each layer is modifiable without interfering with the others, increasing<br />
modularity.<br />
The three-tier architecture is <strong>de</strong>picted in Figure 3.2. However, the OGC does not follow a<br />
strict three-tier architecture, as later on, it is seen that some components on the presentation<br />
layer interact with those on the storage layer.<br />
The components <strong>em</strong>ployed by the OGC are now briefly <strong>de</strong>scribed. Table 3.1 presents the<br />
components used by the Presentation Layer, Table 3.2 contains the <strong>de</strong>scription of the Logic<br />
Layer components and Table 3.3 introduces the components used by the Data Layer.<br />
3.3.1 Component Description<br />
This section provi<strong>de</strong>s a <strong>de</strong>scription for each component required by OGC. First, the task of each<br />
component is briefly analysed and then, the operations of each component are more thoroughly<br />
25
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.3. Original to Generic syntax Converter<br />
Presentation Layer<br />
User<br />
Interface<br />
Logical Layer<br />
Configuration<br />
File Parser<br />
Storage Layer<br />
Parser<br />
Repository<br />
Grammar<br />
Compiler<br />
Tentative<br />
Grammar<br />
Repository<br />
Presentation Layer<br />
Co<strong>de</strong><br />
Generator<br />
Figure 3.2: Components overview<br />
Logical Layer<br />
Storage Layer<br />
Component Description<br />
Configuration File Parser The Configuration File Parser recognizes the diversity of<br />
configuration files and parses th<strong>em</strong> in or<strong>de</strong>r to change their<br />
structure to an application-in<strong>de</strong>pen<strong>de</strong>nt one;<br />
Co<strong>de</strong> Generator The Co<strong>de</strong> Generator reads the parsed output from the Configuration<br />
File Parser and generates the generic syntax of<br />
the file;<br />
Grammar Compiler The Grammar Compiler is the component which generates<br />
new parsers from grammars.<br />
Table 3.2: Logic Layer Components<br />
Component Description<br />
Parser Repository The Parser Repository is a parser database which holds all<br />
the functional parsers generated to the date;<br />
Tentative Grammar<br />
Repository<br />
The Tentative Grammar Repository stores the grammars<br />
built by the user on the process of creating a new parser<br />
for a configuration file language.<br />
Table 3.3: Data Layer Components<br />
26
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.3. Original to Generic syntax Converter<br />
Listing 3.1: User Interface proposed interface<br />
interface UI {<br />
void processFiles(String[] fileNames);<br />
void submitGrammar();<br />
byte[] getTentativeGrammar();<br />
void approveParser();<br />
boolean importParser();<br />
void haltSession();<br />
void recoverSession();<br />
}<br />
<strong>de</strong>scribed. The interfaces that every component should impl<strong>em</strong>ent are also presented, in a<br />
Java-like syntax. Enforcing every component to impl<strong>em</strong>ent an interface not only allows any<br />
component to be completely r<strong>em</strong>a<strong>de</strong> without having any effect on other components, it also<br />
aids the integration process of SmART with other tools.<br />
User Interface<br />
The User Interface (UI, Listing 3.1) is the tool’s front-end, through which the user interacts with<br />
the tool. It is invoked by the user and receives an array of configuration file locations at boot<br />
time, although it only processes one at a time.<br />
For each file, UI summons the Configuration File Parser to make an att<strong>em</strong>pt at<br />
parsing a configuration file with the parsers in the Parser Repository. Two outcomes are<br />
possible: either a parser manages to recognize the totality of a file or none does.<br />
The first case is the i<strong>de</strong>al case, where at least one of the parsers in the Parser Repository<br />
manages to fully recognize the configuration file. In this situation, UI displays the representa-<br />
tion of the generic syntax, as returned by the Configuration File Parser, to let the user<br />
validate the generated structure. At this point, the configuration file in generic syntax is stored<br />
in m<strong>em</strong>ory, so UI must save it to a file to let file modification take place.<br />
The second case, where the configuration file was not completely parsed by any available<br />
parser, requires user intervention. If the file could not be totally recognized by any parser,<br />
another parser which recognizes this new language must be generated. For this en<strong>de</strong>avour,<br />
UI provi<strong>de</strong>s the user with a friendly interface which allows him to <strong>de</strong>fine a new grammar<br />
that recognizes the configuration file language. The user must also be allowed to build a new<br />
grammar from an existing one. This is useful in the case where a parser managed to parse a<br />
configuration file almost entirely. In this case, the new parser might be ready just by tuning an<br />
existing one, instead of having to build it from scratch.<br />
As soon as a grammar is <strong>de</strong>fined, the user triggers its compilation with the Grammar<br />
Compiler’s submitGrammar call. Any grammar compilation errors should be displayed to<br />
the user. To ease parser generation, the user must have access to the previously tested gram-<br />
mars. This allows for the rollback of changes in grammars in an easy way. To accomplish<br />
this, every time the user submits a new grammar, UI sends it to the Tentative Grammar<br />
27
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.3. Original to Generic syntax Converter<br />
Listing 3.2: Configuration File Parser proposed interface<br />
interface CFP {<br />
Map doParse(String fileName);<br />
ParsingData doParse(String fileName, Parser parser);<br />
}<br />
Repository. Then, the user can fetch the previsouly built grammars through the<br />
getTentativeGrammar call.<br />
The parsers generated by the Grammar Compiler must be validated by the user to check<br />
if the new parser is able to parse the configuration file, or if the generic syntax produced by the<br />
parser is in<strong>de</strong>ed the <strong>de</strong>sired one. UI must handle this information and show it to the user in<br />
a user-friendly optic (e.g., graphically). Then, if the user approves the parser, he can summon<br />
the approveParser method to store the parser with the r<strong>em</strong>aining parsers in the Parser<br />
Repository. Finally, UI stores the generic syntax in m<strong>em</strong>ory on a file.<br />
Besi<strong>de</strong>s the presented basic functionality, UI offers some more utilities to the user. Namely,<br />
the importParser method allows the importation of external parsers if the user is already<br />
in possession of a functional parser for a new configuration file. Additionally, the user may<br />
suspend the tool’s execution and resume it later through the haltSession method. This<br />
method stores the tentative grammars to disk, as well as other volatile data in m<strong>em</strong>ory, such as<br />
the produced file in generic syntax, if it was already produced. The recoverSession method<br />
obtains all the stored data to resume a previously saved session.<br />
Configuration File Parser<br />
The Configuration File Parser (CFP, Listing 3.2) can either parse a configuration file with every<br />
parser in the database or just with a single one. The parsers analyse the configuration files in<br />
their original syntax, <strong>de</strong>clared in a grammar which <strong>de</strong>fines the tokens and productions of that<br />
syntax, and produce the abstract syntax tree (AST) of the file.<br />
The ASTs generated by the parsers must follow the typing indicated in Section 1.3. There-<br />
fore, no<strong>de</strong>s composing an AST are either parameters, blocks, comments or no<strong>de</strong>s corresponding<br />
to new patterns. By assuring that the ASTs are typed in such a way, it is possible to conceive a<br />
uniform Co<strong>de</strong> Generator, which is able to traverse the AST of any application. Furthermore,<br />
strictly typed ASTs guarantee that the generic syntax is constant for every application. In other<br />
words, the generic syntax will be composed of el<strong>em</strong>ents like parameters, blocks, comments and<br />
specials, which is a standard recognized by the file modification agent.<br />
CFP may iterate the available parsers in the Parser Repository and att<strong>em</strong>pt to parse<br />
the input file with each one of th<strong>em</strong>. Alternatively, CFP may also be called to parse a file with a<br />
newly generated parser if the file was not entirely recognized with any of the existing parsers.<br />
When a parser is tested, it returns the configuration file intervals which were recognized,<br />
along with the AST of each interval. The ASTs are sent to the Co<strong>de</strong> Generator to be con-<br />
verted into generic syntax, in or<strong>de</strong>r to help the user analyse and validate the output produced<br />
28
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.3. Original to Generic syntax Converter<br />
,()&/.#*+0+456<br />
,()&/.#*+0+<br />
123<br />
,()&/.#*+7+<br />
123<br />
,()&/.#*+7+456<br />
!"#$%&'()*%"#+,%-. !"#$%&'()*%"#+,%-.<br />
,%-.+456<br />
Figure 3.3: Partial and totally parsed configuration file stages<br />
Listing 3.3: Co<strong>de</strong> Generator proposed interface<br />
interface CG {<br />
Document doTranslate(List ast);<br />
}<br />
,%-.+123<br />
by a parser. If a file has been completely recognized, the interval returned by the parser is the<br />
same as the overall original file length and the only returned AST will correspond to the whole<br />
file. The stages of the file in both scenarios are <strong>de</strong>picted in Figure 3.3. Since the CFP tests a file<br />
with every parser in the Parser Repository, it returns a map of every parser and the data<br />
regarding the parsing att<strong>em</strong>pt with that parser. On the other hand, if the CFP tests a file with a<br />
single parser, it returns the parsing data with that parser.<br />
Co<strong>de</strong> Generator<br />
The Co<strong>de</strong> Generator (CG, Listing 3.3) traverses the ASTs created by the parsers and produces<br />
the generic syntax for a configuration file or a configuration file fragment. Besi<strong>de</strong>s that, CG<br />
must also capture the properties of the configuration file original syntax and save th<strong>em</strong> in the<br />
generic syntax in or<strong>de</strong>r to ease the opposite conversion process, from generic to original syntax.<br />
CG is able to correctly traverse any AST, provi<strong>de</strong>d that this follows the typing <strong>de</strong>scribed in<br />
Section 1.3, with parameters, comments, blocks and other types meanwhile <strong>de</strong>fined. Moreover,<br />
the generic syntax produced by CG must be the same for any kind of configuration file so as to<br />
<strong>de</strong>tach the Original to Generic syntax Converter from the Generic to Original syntax Converter.<br />
More consi<strong>de</strong>rations on the generic syntax produced by CG can be found in Section 3.6.<br />
Grammar Compiler<br />
To allow the generation of new parsers for the recognition of new configuration file languages,<br />
the Grammar Compiler (GC, Listing 3.4) was created. GC produces parsers from user-built<br />
29
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.3. Original to Generic syntax Converter<br />
Listing 3.4: Grammar Compiler proposed interface<br />
interface GC {<br />
CompilationData doCompile(byte[] grammar);<br />
}<br />
Listing 3.5: Parser Repository proposed interface<br />
interface PR {<br />
Parser storeParser(ParserID parserID, ParserInt parser, byte[]<br />
grammar);<br />
Parser importParser(ParserID parserID, ParserInt parser);<br />
Iterator getIterator();<br />
void <strong>de</strong>leteParser(String parserID);<br />
void saveState();<br />
}<br />
grammars. For this, CG may make use of an outsi<strong>de</strong> parser generator, such as Bison [FSF08],<br />
SableCC [GH98], JavaCC [Pro09], etc., by invoking it whenever a grammar is received. Also,<br />
when a grammar is not valid, CG must return an error message containing information about<br />
the probl<strong>em</strong>.<br />
Parser Repository<br />
The Parser Repository (PR, Listing 3.5) is a parser database which manages the parsers used<br />
by the tool to that date. It maintains a map of ParserID, which is the parser name and must<br />
uniquely i<strong>de</strong>ntify it, and Parser, used to call a given parser. PR provi<strong>de</strong>s a number of func-<br />
tionalities to the user. These functionalities are now enumerated.<br />
The parsers generated by the Grammar Compiler may be stored by the PR if the user has<br />
approved th<strong>em</strong>. The storeParser method saves a parser in the database, given its name,<br />
which uniquely i<strong>de</strong>ntifies it, the parser and its grammar <strong>de</strong>finition.<br />
If a user possesses an already built parser for a new configuration file, it is possible to im-<br />
port that parser into the tool. The importParser method saves an external parser in the<br />
database. The importation of external parsers is, nevertheless, conditioned by a pre-<strong>de</strong>fined in-<br />
terface which forces external parsers to impl<strong>em</strong>ent an invocable method. This matter is further<br />
discussed in Section 3.6.<br />
Besi<strong>de</strong>s inserting parsers into the database, it is also possible to obtain an iterator for the<br />
existing parsers in the parser repository through the getIterator method, to <strong>de</strong>lete a parser<br />
from the database with the <strong>de</strong>leteParser method and to save the state of the database by<br />
calling the saveState method.<br />
30
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.3. Original to Generic syntax Converter<br />
Listing 3.6: Tentative Grammar Repository proposed interface<br />
interface TentativeGrammarRepository {<br />
Grammar store(GrammarID grammarID, byte[] grammar);<br />
Grammar next();<br />
Grammar prev();<br />
Grammar get(int grammarNumber);<br />
void discard(int grammarNumber);<br />
void discardAll();<br />
void saveState();<br />
}<br />
Tentative Grammar Repository<br />
To respond to the architectural non-functional requir<strong>em</strong>ent which says that the user must be<br />
able to iterate through the previsouly tested grammars, the Tentative Grammar Repository<br />
(TGR, Listing 3.6) was conceived. TGR is a database which maintains a list of the grammars,<br />
functional or not, created by the user so far, in the process of building a new parser. Each<br />
grammar in the database knows what grammar was built before and after it.<br />
To store a grammar, the store method receives a GrammarID with the grammar name and<br />
a byte array containing the grammar <strong>de</strong>claration.<br />
The grammars are retrievable in two ways. The user can obtain grammars on an undo/redo<br />
fashion using the next and prev methods, which return the grammar built immediately be-<br />
fore or after. However, if the user <strong>de</strong>sires to get a specific grammar in time, it can be obtained<br />
using the grammar serial number which is unique to each grammar.<br />
The discard and discardAll methods <strong>de</strong>lete grammars from the database. The discard<br />
method discards a grammar and those based on it, while the discardAll method discards<br />
every grammar in the database.<br />
Finally, the state of the database can be saved, with the saveState, whenever the tool ex-<br />
ecution is halted.<br />
3.3.2 Original to Generic Syntax Converter Operation Scenarios<br />
Depending on whether a parser for a configuration file exists in the Parser Repository,<br />
OGC may have two different execution scenarios. For a clearer perception of the architecture<br />
and to give a better insight on the interactions between components, both scenarios are now<br />
briefly summarized.<br />
Consi<strong>de</strong>ring that there is a parser for a given configuration file in the database, the original<br />
to generic conversion unfolds as follows (Figure 3.4):<br />
1. The User Interface calls the Configuration File Parser to parse the configu-<br />
ration file;<br />
31
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.3. Original to Generic syntax Converter<br />
Presentation Layer<br />
User<br />
Interface<br />
Logical Layer<br />
Configuration<br />
File Parser<br />
Storage Layer<br />
Parser<br />
Repository<br />
Co<strong>de</strong><br />
Generator<br />
Presentation Layer<br />
Logical Layer<br />
Storage Layer<br />
Figure 3.4: Interactions on the successful file recognition scenario<br />
2. The Configuration File Parser gets the parsers from the Parser Repository<br />
and tests the configuration file with all of th<strong>em</strong>. By assumption, at least one parser is<br />
able to parse the configuration file entirely, therefore, at least one valid AST for the entire<br />
configuration file is produced;<br />
3. The Configuration File Parser sends the generated ASTs to the Co<strong>de</strong> Generator<br />
and returns User Interface the generic syntax of the file for each parser;<br />
4. Finally, the User Interface chooses a valid file in generic syntax and stores it to disk.<br />
On the other hand, if a configuration file is new to the tool, the process requires more com-<br />
ponents to operate. The previous process is performed normally until step 2, where no parser<br />
was found to be able to parse the configuration file by the User Interface. Afterwards, the<br />
action flow is as follows:<br />
1. The user must build a grammar through the User Interface so that the Grammar<br />
Compiler generates a parser from it. If a grammar <strong>de</strong>claration is not valid or if the<br />
generated parser still cannot parse the configuration file, another grammar must be built<br />
until the configuration file is parsed;<br />
2. Meanwhile, every grammar produced by the user is stored in the Tentative Grammar<br />
Repository for the user to easily rollback any change ma<strong>de</strong> to a grammar;<br />
3. When a parser successfully recognizes a configuration file, the user has the last word as<br />
he may approve or disapprove the structure produced by that parser;<br />
4. If the user does not approve of a parser, another one must naturally be generated;<br />
32
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.4. Generic to Original syntax Converter<br />
Presentation Layer<br />
User Interface<br />
Logical Layer<br />
Configuration<br />
File Parser<br />
Co<strong>de</strong><br />
Generator<br />
Storage Layer<br />
Tentative<br />
Parser<br />
Repository<br />
Grammar<br />
Repository<br />
Presentation Layer<br />
Grammar<br />
Compiler<br />
Logical Layer<br />
Storage Layer<br />
Figure 3.5: Interactions on the failed file recognition scenario<br />
interface Printer {<br />
void print(String file);<br />
}<br />
Listing 3.7: Printer proposed interface<br />
5. If a parser is approved, it is stored in the Parser Repository and the Tentative<br />
Grammar Repository may be <strong>em</strong>ptied.<br />
Afterwards, the course of action returns to normal: the AST produced by the parser is sent<br />
to the Co<strong>de</strong> Generator and the resulting file in generic syntax is stored to disk by the User<br />
Interface. The interactions between components on this process are <strong>de</strong>picted in Figure 3.5.<br />
Annex A.1 is a sequence diagram showing how components interact with each other, and<br />
in what or<strong>de</strong>r.<br />
3.4 Generic to Original syntax Converter<br />
The conversion from generic syntax back to the original one is accomplished solely by one<br />
component, the Printer (Listing 3.7).<br />
The Printer is able to convert files in generic syntax to any configuration file format. It<br />
does so by using the information on the file’s original syntax, captured by the Co<strong>de</strong> Generator<br />
in Section 3.3.<br />
The outcome of the Printer is the modified file in its original syntax, which r<strong>em</strong>ains 100%<br />
functional and is ready to be re-merged with the other application files, causing the application<br />
to become configured.<br />
33
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.5. Modifying the Configuration File<br />
3.5 Modifying the Configuration File<br />
Despite not being part of this work, some possible ways to <strong>de</strong>al with the configuration file<br />
modification th<strong>em</strong>e were i<strong>de</strong>ntified.<br />
In the presence of a configuration file, structured in an XML document, one can either man-<br />
ually modify it, using a regular text editor or a similar XML editor, or automatically modify it,<br />
<strong>em</strong>ploying an XML script which applies the changes to a configuration file without the need<br />
for any user intervention.<br />
The first way does not ask for any special requir<strong>em</strong>ent, other than having a text editor at<br />
hand, and therefore, consists on the easiest way to modify a configuration file in XML. On the<br />
other hand, the second way requires a script to be previously built. This script may, neverthe-<br />
less, be reusable and also allows for a completely automatic application configuration process.<br />
However, one must first know how the generic syntax is structured in or<strong>de</strong>r to build a script<br />
that operates on it.<br />
Therefore, it is very important that all the files in generic syntax follow the same structure<br />
and nomenclature, regardless of their original format. For example, assuming there is a script<br />
which goes through an entire configuration file searching for the block “Network” to change<br />
the “address” parameter value to “192.168.0.100”, it is vital that every file in generic syntax rep-<br />
resents block parameter patterns in the same way (i.e., a generic syntax el<strong>em</strong>ent called “Block”<br />
with a “value” el<strong>em</strong>ent assigned to it) so that the script recognizes those patterns when it sees<br />
th<strong>em</strong>. The same goes for anyone who wants to manually make that change. The person who<br />
applies the modification should not be obliged to know multiple generic syntaxes for various<br />
configuration file languages, but rather a homogeneous syntax which might slightly diverge<br />
from language to language, <strong>de</strong>pending on that language idiosyncrasies.<br />
3.6 External Parser Addition<br />
In response to the non-functional requir<strong>em</strong>ent in Section 3.1 which says that the user must be<br />
able to add parsers built outsi<strong>de</strong> the tool, Section 3.3.1 indicates that the Parser Repository<br />
impl<strong>em</strong>ents the importParser method. This utility is especially useful when the user wants<br />
to configure applications whose configuration files cannot be parsed by parsers created by<br />
the chosen parser generator (e.g., binary files) or if the user already possesses a parser for a<br />
configuration file.<br />
Nevertheless, in or<strong>de</strong>r for an external parser to be ad<strong>de</strong>d to the tool, it must impl<strong>em</strong>ent<br />
the interface <strong>de</strong>fined in Listing 3.8. This interface solely <strong>de</strong>fines one method, which is the one<br />
called by the Configuration File Parser when parsing a file with an external parser.<br />
Furthermore, the method must return the parsing statistics and the parsed blocks in generic<br />
syntax.<br />
34
3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.6. External Parser Addition<br />
Listing 3.8: External Parser Proposed Interface<br />
interface ExternalParserInterface {<br />
public ParsingData parse(String fileName);<br />
}<br />
35
4<br />
An Impl<strong>em</strong>entation<br />
Chapter 3 approached the application configuration framework by i<strong>de</strong>ntifying the require-<br />
ments to be met and <strong>de</strong>fining a tool workflow and component architecture. This chapter <strong>de</strong>-<br />
scribes the impl<strong>em</strong>entation of that framework, <strong>de</strong>veloped in the context of this thesis.<br />
First, impl<strong>em</strong>entation <strong>de</strong>cisions of several or<strong>de</strong>rs are presented. Section 4.1 presents the<br />
adopted programming language, Section 4.2 presents the adopted parser generator and Sec-<br />
tion 4.3 presents the adopted generic syntax format. Then, Section 4.4 shows the impl<strong>em</strong>enta-<br />
tion of the created data structures in terms of the motivation for their use and their functionality.<br />
Afterwards, Section 4.5 presents the <strong>de</strong>tails of the Original to Generic syntax Converter com-<br />
ponent impl<strong>em</strong>entation, Section 4.6 shows how the files in generic syntax are printed back to<br />
original syntax and last, Section 4.7 displays the Generic to Original syntax Converter compo-<br />
nent impl<strong>em</strong>entation.<br />
4.1 Programming Language<br />
As it is well known, programming languages differ from each other not only in terms of sup-<br />
ported programming paradigms, but also expressive power, documentation, popularity, etc.<br />
Among the requir<strong>em</strong>ents that the programming language was expected to meet, two had a<br />
special weight in the time of <strong>de</strong>cision: the chosen programming language should be object-<br />
oriented due to the modular nature of the tool and high-level to easily and quickly provi<strong>de</strong><br />
programming tools such as data types, data structures, etc.<br />
Given the previous consi<strong>de</strong>rations, the <strong>de</strong>cision fell on the Java 1 programming language,<br />
consi<strong>de</strong>ring it supports the object-oriented programming paradigm, among many other pro-<br />
gramming paradigms, is high-level and its API (Application Programming Interface) is well<br />
1 http://java.sun.com/<br />
37
4. AN IMPLEMENTATION 4.2. Parser Generator<br />
interface No<strong>de</strong> {<br />
void translate();<br />
}<br />
Listing 4.1: No<strong>de</strong> interface<br />
documented. Moreover, a great number of parser generators provi<strong>de</strong> support for this pro-<br />
gramming language.<br />
4.2 Parser Generator<br />
The choice of a parser generator took into account the two parsers studied earlier in Section 2.3,<br />
SableCC and JavaCC.<br />
SableCC is <strong>de</strong>fined by automatically generating all no<strong>de</strong>s of an AST from a grammar, im-<br />
pl<strong>em</strong>enting a fairly simple and intuitive grammar <strong>de</strong>finition interface and strictly separating<br />
all the user-generated co<strong>de</strong> from the parser generator-generated co<strong>de</strong>.<br />
On the other hand, JavaCC makes it possible for the insertion of Java co<strong>de</strong> in the gram-<br />
mar <strong>de</strong>finition, which may cause the grammar <strong>de</strong>finition interface a bit more complex. Unlike<br />
SableCC, JavaCC does not automatically generate the no<strong>de</strong>s of the AST, leaving that task to the<br />
user. The separation of parser generator and user-generated co<strong>de</strong> is relative and <strong>de</strong>pends on<br />
the <strong>de</strong>gree of <strong>de</strong>tachment <strong>de</strong>fined in the grammar.<br />
Initially, SableCC’s characteristics led us to consi<strong>de</strong>r it as the best option, since it allowed<br />
for the rapid prototyping of the tool. However, after used and tested, its mechanics were found<br />
to be more complex over time consi<strong>de</strong>ring that, by having each parser creating its own AST, it<br />
requires specific walkers for each AST. The direct impact that this characteristic had on SmART<br />
is that for each different configuration file type is a different grammar, which leads to a different<br />
AST, which leads to one AST walker for each configuration file type. Adversely, since JavaCC<br />
requires the no<strong>de</strong>s of the AST to be manually <strong>de</strong>fined, it is possible to conceive a structure<br />
where every no<strong>de</strong> in it impl<strong>em</strong>ents a method that can be called by the structure walker (see<br />
Listing 4.1). In this way, only one walker is required for any kind of configuration file, which<br />
is able to visit the AST of any configuration file type and produce the file in generic syntax by<br />
calling the method <strong>de</strong>fined in the interface of Listing 4.1.<br />
Another severe limitation of SableCC is that it currently does not offer the error recovery<br />
functionality, whereas JavaCC provi<strong>de</strong>s two types of error recovery: shallow and <strong>de</strong>ep error<br />
recovery. Error recovery consists on continuing the parsing of a configuration file even after<br />
an unrecognized token has been found. This allows for better accuracy when calculating the<br />
fitness of a parser with a configuration file.<br />
Given the previous consi<strong>de</strong>rations, the initial beliefs in SableCC were turned in favour of<br />
JavaCC.<br />
38
4. AN IMPLEMENTATION 4.3. Generic Syntax<br />
interface Parser {<br />
String getParserID();<br />
}<br />
interface InternalParser {<br />
Method getParseMethod();<br />
byte[] getGrammarDefinition();<br />
}<br />
4.3 Generic Syntax<br />
Listing 4.2: Parser data structure<br />
Listing 4.3: InternalParser data structure<br />
Section 2.4 indicated that the chosen format for the representation of the configuration files<br />
in generic syntax would be XML (eXten<strong>de</strong>d Markup Language). Furthermore, that Section<br />
saw that there are two XML parser impl<strong>em</strong>entations for the Java programming language,<br />
DOM [W3S09] and SAX [Pro04]. It was seen that the first keeps a tree in m<strong>em</strong>ory, representing<br />
the XML document, while the second is event-driven.<br />
By balancing the benefits and drawbacks of each parser, DOM was preferred to SAX on<br />
account of representing an XML document in m<strong>em</strong>ory as a tree structure. This allows for a<br />
quick transition of an AST to a DOM tree.<br />
4.4 Data Structures<br />
This section presents the data structures created to cope with various aspects regarding the<br />
passing of data between components. For each data structure, an interface is revealed and an<br />
explanation on the data structure functionality and the methods <strong>de</strong>clared in the interface is<br />
presented.<br />
4.4.1 Parser<br />
Parser objects are used as references for the parsers used by the tool. This impl<strong>em</strong>entation<br />
consi<strong>de</strong>rs that the parsers are i<strong>de</strong>ntified by their name and, therefore, the ParserID field<br />
consists on a String instead. However, the Parser class cannot be instanciated since it is<br />
an abstract class. To distinguish the internal parsers, built by the tool, and external parsers,<br />
built outsi<strong>de</strong> the tool and imported by a user, two classes extending Parser were created:<br />
InternalParser and ExternalParser. The two classes are now explained.<br />
39
4. AN IMPLEMENTATION 4.4. Data Structures<br />
InternalParser<br />
'()*+,-#".+()&/+0%<br />
!"#$%#&!<br />
!"#$%#&"<br />
Figure 4.1: Recognition of a configuration file by two parsers<br />
InternalParser (Listing 4.3) objects represent parsers generated by the tool, through the<br />
Grammar Compiler. An InternalParser object contains a pointer to the parse method<br />
and the grammar used to construct the parser.<br />
Regarding the parse method, the latter is invoked resorting to the Java reflex API and re-<br />
turns a list of No<strong>de</strong> objects (Listing 4.1) due to be transformed to XML by the<br />
Co<strong>de</strong> Generator.<br />
Concerning the grammar used for the generation of the InternalParser, it is kept with<br />
the parser in or<strong>de</strong>r to aid users on the generation of new parsers. Consi<strong>de</strong>r the case where a<br />
user tries to configure a file which is new to the tool and two parsers are stored. The result of<br />
the parsing att<strong>em</strong>pt is <strong>de</strong>picted in Figure 4.1.<br />
In the example, two parsers are tested on a configuration file with 100 lines. The first parser,<br />
α, manages to recognize the file from line 0 to 59 and then from line 70 to 99, resulting in a 90%<br />
of parsed file. On the other hand, parser β recognized 20% of the file, from line 50 to 69.<br />
In this situation, the user who would build the new parser for the file might want to access<br />
the grammar of the parser α, since it parsed almost the entire file, and base the new parser on<br />
the old instead of starting from scratch. Also, seen as the second parser recognized the part of<br />
the file that the first did not, the user might want to check the grammar of the second parser.<br />
40
4. AN IMPLEMENTATION 4.4. Data Structures<br />
Listing 4.4: ExternalParser data structure<br />
interface ExternalParser {<br />
ExternalParserInterface getParseMethod();<br />
}<br />
interface Grammar {<br />
int getSerialNumber();<br />
String getGrammarID();<br />
byte[] getGrammarDefinition();<br />
}<br />
ExternalParser<br />
Listing 4.5: Grammar data structure<br />
ExternalParser objects are used to represent parsers built outsi<strong>de</strong> the tool. Since these<br />
parsers might not be built with the parser generator used by the tool, there is no knowledge of<br />
the content they produce when parsing a file. Therefore, an ExternalParser has an attribute<br />
of the ExternalParserInterface type, which contains the invocable method <strong>de</strong>clared in<br />
Listing 3.8 to parse a file and return the file in generic XML.<br />
4.4.2 Grammar<br />
Grammar objects (Listing 4.5) stand for tentative grammars. They are created in the User<br />
Interface and stored the Tentative Grammar Repository when a new grammar is built.<br />
A Grammar contains a serial number, which is used by the Tentative Grammar<br />
Repository to have a means of i<strong>de</strong>ntifying each grammar, since the name of all the tenta-<br />
tive grammars for a parser tends to be equal because it represents the name of the parser being<br />
built. In this impl<strong>em</strong>entation, the getGrammarID returns the grammar name in a String.<br />
The grammar name is used to name the Grammar, but also to name the parser which it was<br />
used to generate, as already mentioned. Finally, a Grammar also contains an attribute for the<br />
grammar <strong>de</strong>claration, accessible through the getGrammarDefinition method.<br />
4.4.3 ParsingData<br />
ParsingData objects (Listing 4.6) contain pieces of a configuration file, in generic syntax, and<br />
information regarding the parsing of that file with a parser and are returned by the<br />
Configuration File Parser.<br />
Although the ParsingData objects do not contain any reference to the corresponding<br />
parser, they always refer to the parsing result of a parser. This relation is explicit when the<br />
Configuration File Parser returns objects of this kind. When a single parser is tested,<br />
the return is a ParsingData object, obviously referring to the parse with the tested parser.<br />
41
4. AN IMPLEMENTATION 4.4. Data Structures<br />
interface ParsingData {<br />
boolean wasParsed();<br />
int getParsingDone();<br />
List getParsedBlocks();<br />
void dump(String fileName);<br />
}<br />
Listing 4.6: ParsingData data structure<br />
ParsingData<br />
boolean<br />
parsed<br />
int<br />
parsePercentage<br />
List<br />
blocks<br />
Block<br />
int<br />
startPosition<br />
int<br />
endPosition<br />
XML block<br />
Figure 4.2: Graphical representation of ParsingData<br />
Whenever multiple parsers are tested, the return is a map of the tested parsers and their<br />
ParsingData.<br />
By having a ParsingData contain the parts of a file recognized by a parser, the case where<br />
a file is completely parsed is a special case of when a file is not totally parsed, consi<strong>de</strong>ring<br />
that in the first case, a ParsingData will only contain one part, which is the whole parsed file.<br />
However, a parser may return only one part of a file but not recognize it entirely. Therefore,<br />
additional control is required to check if a file was well parsed or not. The wasParsed method<br />
tells whether a file was entirely recognized, or not.<br />
In case a file was not completely parsed, its parsing statistics are logged. This is an indicator<br />
of how fit the parser was found to be with the given configuration file and can be measured in<br />
terms of percentage of parsed file.<br />
Additionally, the ParsingData objects also contain a list of Block objects. A Block object<br />
has no relation with the block pattern, but rather contains the generic syntax of a parsed file part<br />
as well as the positions of the first and last character that Block represents. The representation<br />
of a ParsingData object, and the contained Block object, is shown in Figure 4.2.<br />
Whenever the file is due to get modified in or<strong>de</strong>r to be configured, or the user halts the tool<br />
execution, the dump method is called in or<strong>de</strong>r to store the blocks in a given file in persistent<br />
storage.<br />
4.4.4 CompilationData<br />
CompilationData objects (Listing 4.7) are produced by the Grammar Compiler to send in-<br />
formation regarding the compilation of a grammar to the User Interface. A<br />
CompilationData object tells if a grammar was successfully compiled in the wasCompiled<br />
42
4. AN IMPLEMENTATION 4.5. Original to Generic syntax Converter<br />
interface CompilationData {<br />
boolean wasCompiled();<br />
String getErrorMessage();<br />
String getParserLocation();<br />
}<br />
Listing 4.7: CompilationData data structure<br />
method. If the compilation en<strong>de</strong>d without any occurred error, the parser location is given by<br />
the getParserLocation method. Alternatively, if an error ocurred during the compilation,<br />
it is accessible through the getErrorMessage method.<br />
4.5 Original to Generic syntax Converter<br />
After the components required in the Original to Generic syntax Converter were i<strong>de</strong>ntified and<br />
the behaviour of each one was <strong>de</strong>scribed, their impl<strong>em</strong>entation took place. Following is shown<br />
how the components i<strong>de</strong>ntified in Section 3.3 were impl<strong>em</strong>ented.<br />
4.5.1 User Interface<br />
The User Interface is passed multiple configuration file locations upon its invocation by<br />
the user. The parsing of multiple configuration files is sequential, or, in other words, UI config-<br />
ures one file at a time and only when that file is configured should the next file configuration<br />
start.<br />
To configure a file, UI sends its location to the Configuration File Parser in or<strong>de</strong>r<br />
to parse it with every available parser. The Configuration File Parser returns a map of<br />
ParsingData objects which tells if the parsing was successful with any parser, as well as the<br />
percentage of parsed file, the parsed file blocks in generic syntax and the position of the first<br />
and last characters of the corresponding block.<br />
When a file is successfully parsed, the corresponding AST is sent to Co<strong>de</strong> Generator and<br />
the returned file in XML is placed in a t<strong>em</strong>porary file fol<strong>de</strong>r, with the same name as the original<br />
configuration file, plus the suffix “.xml”.<br />
If a file was not entirely parsed, UI displays the parts of the file which were recognized<br />
by the parser with the best configuration file parse percentage and the grammar used on the<br />
respective parser. Then, UI prompts the user for a file containing a grammar to be com-<br />
piled and sends the grammar to Grammar Compiler. The Grammar Compiler returns a<br />
CompilationData object which tells whether there was any error compiling the grammar. If<br />
an error ocurred, the user must alter the grammar in the file to correct the error(s) and then<br />
trigger another grammar compilation until the grammar is successfully compiled.<br />
When a grammar is successfully compiled, UI att<strong>em</strong>pts to parse the configuration file<br />
with the newly generated parser by invoking the Configuration File Parser’s doParse<br />
method which tests a file with a single parser. If the file was still not entirely recognized, the<br />
43
4. AN IMPLEMENTATION 4.5. Original to Generic syntax Converter<br />
user must alter the grammar to recognize the text parts which failed to be parsed, until a parser<br />
which recognizes the whole file is generated.<br />
The initial plan was for a graphical interface to be launched whenever a file could not be<br />
parsed by any parser in the database. This interface would display useful information to the<br />
user such as the graphical representation of the configuration file in XML, grammar navigator<br />
and highlighted configuration file based on its parsed and not parsed parts. UI would also<br />
allow the user to <strong>de</strong>fine a grammar without having to manually program it, resorting to the<br />
selection of configuration file pieces and assigning meanings to th<strong>em</strong>, in an interactive way.<br />
However, the impl<strong>em</strong>entation of the graphical interface will only take place during the inte-<br />
gration of the tool with VIRTU.<br />
4.5.2 Configuration File Parser<br />
When the Configuration File Parser is summoned for the first time, it initiates the<br />
Parser Repository.<br />
The doParse(String fileName) method calls the doParse(String fileName,<br />
Parser parser) method for every available parser in the Parser Repository and logs<br />
the resulting ParsingData objects in a map, where the entry key is the used Parser. This<br />
method returns the map generated in this way.<br />
The doParse(String fileName, Parser parser) method, in turn, treats a config-<br />
uration file with a parser at a time. If parser is an InternalParser, its parse method is<br />
invoked using the Java reflex API and the return, a list of No<strong>de</strong> objects (Listing 4.1), is sent<br />
to the Co<strong>de</strong> Generator to be passed to generic XML. Thrown exceptions during parse time<br />
mean that a file was not entirely recognized. The exceptions caught at parsing time contain<br />
the position where the recognized block starts and ends. These exceptions are analysed to re-<br />
trieve that information. The percentage of recognized file is calculated based on the limits of<br />
every parsed block. In the end, a ParsingData object containing the parsing percentage, the<br />
recognized blocks, characterized by their start and end points, together with the XML of the<br />
respective blocks, is returned.<br />
4.5.3 Parser Repository<br />
The Parser Repository holds a map of Parser objects corresponding to the available<br />
parsers. When PR is initiated, it gets the last saved state by loading the parser map to m<strong>em</strong>ory.<br />
The storeParser method creates a Parser object from a string containing the name<br />
of the parser, and the ExternalParserInterface which contains the parser. An optional<br />
grammarFile can be passed, in case the user wants to merge the grammar with the Parser<br />
so that it is available in the future. If the grammarFile argument is not null, the grammar<br />
must be stored in the grammar directory, with the same name as the parser. The Parser is<br />
then inserted in the Parser map. The importParser does a similar job in inserting a parser<br />
in the database, but for external parsers.<br />
PR also impl<strong>em</strong>ents methods for getting the parser map iterator, getIterator and to<br />
44
4. AN IMPLEMENTATION 4.5. Original to Generic syntax Converter<br />
<strong>de</strong>lete a parser from the repository, <strong>de</strong>leteParser, which consists on <strong>de</strong>leting the map entry<br />
with the parser name in argument.<br />
4.5.4 Grammar Compiler<br />
The Grammar Compiler is impl<strong>em</strong>ented as a class which receives a grammar <strong>de</strong>finition and<br />
produces a parser from it. After JavaCC generates the parser classes, these must be compiled<br />
before the Parser Repository is able to load th<strong>em</strong>.<br />
In the end, the Grammar Compiler returns a CompilationData object, which tells that<br />
a grammar failed to compile if an exception was caught, or that it compiled successfully other-<br />
wise.<br />
4.5.5 Co<strong>de</strong> Generator<br />
The Co<strong>de</strong> Generator traverses structures composed of no<strong>de</strong>s impl<strong>em</strong>enting the interface <strong>de</strong>-<br />
fined in Listing 4.1 and invokes the method <strong>de</strong>fined the interface upon visiting each no<strong>de</strong> in<br />
or<strong>de</strong>r to generate the generic XML of the pattern associated to that no<strong>de</strong>. The reason why every<br />
no<strong>de</strong> in structure impl<strong>em</strong>ents that interface was already explained in Section 4.2 and consists<br />
on forcing each no<strong>de</strong> of the AST to impl<strong>em</strong>ent a method which can be called by CG. In this way,<br />
the information on how to print the no<strong>de</strong>s to generic XML is stored in the no<strong>de</strong>s and CG gains<br />
the ability to successfully traverse ASTs of any configuration files.<br />
On an early stage of the tool, the co<strong>de</strong> that generates the generic XML of a no<strong>de</strong> in the<br />
AST must be generated manually, for new patterns. However, with the creation of a graphi-<br />
cal interface for the <strong>de</strong>finition of grammars for new types of configuration files in the User<br />
Interface, it should be possible to use the information received from the user to automati-<br />
cally generate that co<strong>de</strong>.<br />
CG is responsible for logging the <strong>de</strong>tails of each configuration file language, such as the<br />
used <strong>de</strong>limiters on patterns, or how a pattern is formatted. For this, CG resorts to a Metadata<br />
special field, which stores the information regarding the <strong>de</strong>limiters used by the patterns, and<br />
another FStr special field to log how each pattern is formatted. Details regarding the generation<br />
of original syntax <strong>de</strong>tails are further <strong>de</strong>scribed in Section 4.6. A set of functions to manipulate<br />
the Metadata and the FStr fields are provi<strong>de</strong>d.<br />
The generic XML must be the same for every configuration file types, following a structure<br />
similar to the presented in Section 1.3, with blocks, comments, parameters and other special ele-<br />
ments. This is important since the generic XML document might become unrecognizable to the<br />
configurator which modifies it if the user <strong>de</strong>ci<strong>de</strong>s, for example, to <strong>de</strong>note blocks by “blockx”.<br />
The configurator will afterwards find a “blockx”, when in fact its operation was <strong>de</strong>fined on a<br />
“block”.<br />
4.5.6 Tentative Grammar Repository<br />
The Tentative Grammar Repository impl<strong>em</strong>ents a linked list of TGRNo<strong>de</strong> objects. A<br />
TGRNo<strong>de</strong> represents a tentative grammar in TGR and contains a TGRNo<strong>de</strong> prev attribute with<br />
45
4. AN IMPLEMENTATION 4.6. Generation of Original Syntax<br />
!"#$%&'<br />
)*++<br />
(<br />
!"#$%&'<br />
,<br />
!"#$%&'<br />
-<br />
)*++<br />
Figure 4.3: List of TGRNo<strong>de</strong>s<br />
!"#$%&'<br />
!"#$%&'<br />
the grammar where the current was based on and a TGRNo<strong>de</strong> list next containing the gram-<br />
mars based on the current. An example is represented in Figure 4.3.<br />
To allow the user to traverse all the built grammars, the prev and next methods resort to<br />
each grammar serial number to iterate the grammars backwards/forwards. Each method may<br />
also return null if no grammar was built before/after the current one, respectively. The get<br />
method receives an integer representing the <strong>de</strong>sired grammar serial number and returns the<br />
respective Grammar.<br />
The discard method <strong>de</strong>letes a grammar from the database, and every grammar based on<br />
that one. The discardAll <strong>em</strong>pties the list of tentative grammars. To save the state of the<br />
database, the gramar list is stored to disk.<br />
4.6 Generation of Original Syntax<br />
The generation of original syntax consists on printing a file on generic syntax back to its original<br />
syntax by means of a Printer component. When a file is transposed from its original syntax,<br />
say INI, to the generic syntax (XML), the language-specific <strong>de</strong>tails, like the ‘[’ and ‘]’ hea<strong>de</strong>r<br />
<strong>de</strong>limiters, are discar<strong>de</strong>d to allow for application-in<strong>de</strong>pen<strong>de</strong>nt configuration. Furthermore, the<br />
format of each pattern is also lost. Only the relevant information for the configuration process,<br />
such as parameter keys and values, is kept.<br />
When the printer tries to print the file in generic syntax back to its original form, it will<br />
46<br />
/<br />
.<br />
)*++<br />
)*++
4. AN IMPLEMENTATION 4.6. Generation of Original Syntax<br />
<br />
<br />
[<br />
]<br />
<br />
<br />
Listing 4.8: Example Metadata<br />
not know what application is being configured at that moment. Therefore, it cannot <strong>de</strong>termine<br />
what <strong>de</strong>limiters to print on a given pattern (e.g., INI “[]” or XML block <strong>de</strong>limiters), or how to<br />
print th<strong>em</strong> (e.g., INI single hea<strong>de</strong>r or XML hea<strong>de</strong>r and footer). So, to print a file to its original<br />
syntax, there should be enough information regarding the original syntax, in the generic syntax,<br />
for the Printer.<br />
One way to know what <strong>de</strong>limiters should be print is to store th<strong>em</strong> in a field in the be-<br />
ginning of the file in generic syntax. As the pattern <strong>de</strong>limiters are immutable throughout the<br />
configuration file (i.e., comments always start with # in an Apache configuration file), infor-<br />
mation regarding th<strong>em</strong> can be unified in a special Metadata field in the beginning of the file.<br />
This makes it possible for the Printer to query Metadata to know what to print on a certain<br />
pattern.<br />
The format of a pattern is of great importance as well. The same pattern might have differ-<br />
ent formats in two different configuration file languages. For instance, an INI block has only<br />
one block hea<strong>de</strong>r, whereas an XML block (i.e., el<strong>em</strong>ent) has a hea<strong>de</strong>r and a footer. Again, since<br />
the Printer does not know what application it is configuring at the moment, it does not know<br />
whether to print a pattern one way or the other.<br />
To solve this probl<strong>em</strong>, a format string which <strong>de</strong>scribes how a pattern looks like is associated<br />
with each pattern, forming an FStr field. In this way, the Printer gets the FStr from a pattern<br />
and prints it accordingly. A format string may be composed of the following:<br />
%a.name The value of the attribute named name in the current el<strong>em</strong>ent is printed;<br />
%e The value of the current el<strong>em</strong>ent is printed;<br />
%m.name The value of the el<strong>em</strong>ent named name in Metadata is printed;<br />
%c The format string is in the next child of the current el<strong>em</strong>ent;<br />
%s A space is printed;<br />
%n A new line is printed;<br />
Let’s consi<strong>de</strong>r the following hea<strong>de</strong>r in an INI configuration file:<br />
[Engine]<br />
The corresponding Metadata is <strong>de</strong>picted in Listing 4.8 and the FStr will look like Listing 4.9.<br />
47
4. AN IMPLEMENTATION 4.7. Generic to Original Syntax Converter<br />
<br />
<br />
%m.LBra%a.name%m.RBra%n<br />
<br />
..(other patterns)..<br />
<br />
ServerType standalone<br />
Listing 4.9: Example FStr<br />
Listing 4.10: Apache parameter with a single value<br />
Note that in the example, the FStr is assigned to the Engine block and not to the block<br />
pattern. This happens because there are cases where the same pattern has different formats in<br />
a configuration file language. For example, a parameter in an Apache configuration file might<br />
have one (Listing 4.10) or multiple values (Listing 4.11), or an XML el<strong>em</strong>ent might have one<br />
(Listing 4.12) or multiple sub-el<strong>em</strong>ents (Listing 4.13), which leads to multiple format strings.<br />
Therefore, FStr cannot be factorized in a single field, like Metadata.<br />
4.7 Generic to Original Syntax Converter<br />
The Generic to Original syntax Converter contains two classes, PrinterMain and Printer.<br />
The first is used to interact with the user, while the second contains methods for the interpreta-<br />
tion and printing of the file in generic syntax (i.e., XML). Following is a <strong>de</strong>eper explanation of<br />
both classes.<br />
The PrinterMain class impl<strong>em</strong>ents a main method which receives the location of the XML<br />
file in argument. It imports the XML document from the file to m<strong>em</strong>ory using the Java XML<br />
parsing API. Then, PrinterMain sends the document pointer and a stream to the Printer and<br />
the latter prints the final configuration file in original syntax to the stream in argument.<br />
The Printer class manages the printing of XML el<strong>em</strong>ents insi<strong>de</strong> an XML file. It impl<strong>em</strong>ents<br />
a single visible method, print.<br />
The print method is called by PrinterMain to print the entire XML document into a con-<br />
figuration file in its original syntax. It receives a stream and a No<strong>de</strong>List object as arguments.<br />
No<strong>de</strong>List refers to a DOM interface for the representation of lists of No<strong>de</strong> objects, whereas<br />
each No<strong>de</strong> object stands for XML components, such as el<strong>em</strong>ents, attributes or text no<strong>de</strong>s. Since<br />
the XML standard <strong>de</strong>fines XML documents as having a single root no<strong>de</strong>, PrinterMain calls<br />
Listing 4.11: Apache parameter with multiple values<br />
DirectoryIn<strong>de</strong>x in<strong>de</strong>x.html in<strong>de</strong>x.htm in<strong>de</strong>x.shtml<br />
<strong>de</strong>fault.htm <strong>de</strong>fault.html in<strong>de</strong>x.php<br />
48
4. AN IMPLEMENTATION 4.7. Generic to Original Syntax Converter<br />
<br />
<br />
<br />
Listing 4.12: XML el<strong>em</strong>ent with a single subel<strong>em</strong>ent<br />
Listing 4.13: XML el<strong>em</strong>ent with multiple el<strong>em</strong>ents<br />
<br />
<br />
<br />
<br />
the print method with the root no<strong>de</strong>’s children, which is, in turn, a No<strong>de</strong>List.<br />
The first el<strong>em</strong>ent in the XML files generated by the tool is always Metadata, containing the<br />
information about the original syntax. This el<strong>em</strong>ent aids the printing process and is not part of<br />
the final configuration file, therefore it must not be printed. The r<strong>em</strong>ain<strong>de</strong>r of the el<strong>em</strong>ents are<br />
then printed. XML el<strong>em</strong>ents generated by the tool always contain an FStr field, corresponding<br />
to the format string of that el<strong>em</strong>ent, explained in Section 4.6. All el<strong>em</strong>ents in the document<br />
are visited and printed according to their format string. If the current el<strong>em</strong>ent has other child<br />
no<strong>de</strong>s, they must be printed as well.<br />
49
5<br />
Framework Evaluation<br />
Chapter 3 presented the proposed application configuration framework and Chapter 4 covered<br />
the process of impl<strong>em</strong>enting the framework. This chapter provi<strong>de</strong>s us with the validation of<br />
the tool, carried after the impl<strong>em</strong>entation phase had ceased.<br />
First, Section 5.1 shows the functional validation of the tool by explaining how the require-<br />
ments i<strong>de</strong>ntified in Section 3.1 are met. Then, Section 5.2 presents the operational validation<br />
by checking the integrity of the tool and examining the configuration process step by step. Fi-<br />
nally, Section 5.3 provi<strong>de</strong>s the performance validation by testing the tool behaviour in different<br />
scenarios (i.e., configuration of a very big and very small configuration file).<br />
5.1 Functional Validation<br />
In Section 3.1, some functional and non-functional requir<strong>em</strong>ents of the tool were i<strong>de</strong>ntified.<br />
This section presents the ways in which these requir<strong>em</strong>ents are met.<br />
1. The user must be able to convert a configuration file syntax from its original syntax to<br />
a generic one, in<strong>de</strong>pen<strong>de</strong>ntly of the application.<br />
The user is able to summon the tool from a terminal and pass it multiple configuration file<br />
locations. The tool, in turn, produces abstract trees for the configuration files, and then the<br />
configuration files in a structured, generic format.<br />
Non-functional requir<strong>em</strong>ents:<br />
Performance: The generated file with the generic syntax must be as simple as possible.<br />
The information regarding the original syntax is factorized by the co<strong>de</strong> generator in a Meta-<br />
data field.<br />
2. The user must be able to <strong>de</strong>fine grammars for configuration file languages.<br />
51
5. FRAMEWORK EVALUATION 5.1. Functional Validation<br />
After the user submits a number of files to the tool, they are processed and, if not fully<br />
recognized, the user is able to manually <strong>de</strong>fine a grammar, or pass the tool a file containing the<br />
grammar for the generation of new parser.<br />
Non-functional requir<strong>em</strong>ents:<br />
Usability: The grammar <strong>de</strong>finition syntax should be a broadly adopted one.<br />
JavaCC grammar interpreter supports the Exten<strong>de</strong>d Backus-Naur Form and allows Java<br />
co<strong>de</strong>, for more commodity.<br />
Usability: To ease the parser generation process, the user must be able to iterate through the previ-<br />
ously built grammars so as to roll back any change ma<strong>de</strong> on a grammar.<br />
Every time the user tries a newly created parser on a configuration file, the grammar used<br />
for it is stored in a repository and can be recovered at any time.<br />
3. The user must be able to produce a parser from a grammar.<br />
As soon as the user finishes <strong>de</strong>claring a grammar, the latter is passed to the tool, which<br />
compiles it on an external parser generator.<br />
Non-functional requir<strong>em</strong>ents:<br />
Extensibility: The user must be able to add parsers built outsi<strong>de</strong> the tool to support other configura-<br />
tion file paradigms (e.g., Windows registry files, binary files, etc.).<br />
The parser repository impl<strong>em</strong>ents the importParser method which allows the user to<br />
store an external parser. However, the parser must impl<strong>em</strong>ent the interface presented in List-<br />
ing 3.8.<br />
4. The user must have access to the parser compilation trace.<br />
When a grammar is compiled, its compilation trace is shown in case there any error ocurred,<br />
or a success message is displayed, otherwise.<br />
Non-functional requir<strong>em</strong>ents:<br />
Usability: The error messages must clearly i<strong>de</strong>ntify the source of the error.<br />
The error messages contain the source of the compilation error.<br />
5. The user must receive information relative to the grammar fitness with a given config-<br />
uration file.<br />
Any time a parser is tested with a configuration file, the percentage of parsed file with that<br />
parser is displayed.<br />
Non-functional requir<strong>em</strong>ents:<br />
Usability: The sections of the configuration file that were parsed and those that were not must be<br />
clearly i<strong>de</strong>ntified.<br />
When a parser is tested with a configuration file, the regions of the file recognized by it are<br />
highlighted in a graphical environment.<br />
6. The user must be able to store a functional parser generated by the tool, in or<strong>de</strong>r to be<br />
used on later tool runs.<br />
52
5. FRAMEWORK EVALUATION 5.2. Operational Validation<br />
The user can trigger a storeParser command, which stores a parser in the parser reposi-<br />
tory <strong>de</strong>finitively.<br />
Non-functional requir<strong>em</strong>ents:<br />
Security: The user must be able to see the parsing outcome in or<strong>de</strong>r to check if the parser is in<strong>de</strong>ed<br />
operating as inten<strong>de</strong>d to.<br />
The graphical user interface displays a user-friendly representation of the generic syntax so<br />
the user can confirm that the parser is in<strong>de</strong>ed operating in the inten<strong>de</strong>d way.<br />
7. The user must be able to reconvert a configuration file syntax from the generic syntax<br />
to the original one.<br />
The user is able to summon the tool and pass it a tool-generated XML file to be converted<br />
into the original syntax, keeping its functionality.<br />
8. File conversion must not eliminate comments<br />
The built-in parsers preserve the comments of the original file. For new parsers, their gram-<br />
mars must cont<strong>em</strong>plate the comments and not ignore th<strong>em</strong>.<br />
9. The user must be able to halt the tool execution at any point and continue the config-<br />
uration process later.<br />
When the user halts the tool execution, the parser repository and tentative grammar repos-<br />
itory states are stored in or<strong>de</strong>r to be recovered later. If a valid version of the configuration file<br />
has been produced before the user halted the execution, the file is stored and can be recovered<br />
later.<br />
10. The user must be able to manually <strong>de</strong>lete parsers from the parser repository.<br />
The parser repository impl<strong>em</strong>ents the <strong>de</strong>lete method which allows the user to <strong>de</strong>lete an<br />
existing parser from the database, given its name.<br />
5.2 Operational Validation<br />
This section presents some tests carried on the tool, using various configuration file types,<br />
with the objective of specifying the configuration file intermediate states and <strong>de</strong>termining the<br />
validity of the final configuration file, produced by the tool.<br />
The framework provi<strong>de</strong>s built-in support for three major configuration file categories, i<strong>de</strong>n-<br />
tified in Section 1.3:<br />
• Files composed of parameter blocks <strong>de</strong>limited only by a hea<strong>de</strong>r, and comments (i.e., INI-<br />
like);<br />
• Files composed of parameters, blocks <strong>de</strong>limited by a hea<strong>de</strong>r and a footer and comments<br />
(i.e., Apache-like);<br />
53
5. FRAMEWORK EVALUATION 5.2. Operational Validation<br />
1 [mysqldump]<br />
2 quick<br />
3 quote-names<br />
4 max_allowed_packet = 16M<br />
5<br />
Listing 5.1: MySQL configuration file snippet<br />
6 # The MySQL database server configuration file.<br />
7<br />
8 !inclu<strong>de</strong>dir /etc/mysql/conf.d/<br />
• Files composed of blocks <strong>de</strong>limited by dynamic hea<strong>de</strong>rs and footers, and comments (i.e.,<br />
XML-like).<br />
Three tests were conducted, one with a file of each category. All the tests were ran on a<br />
syst<strong>em</strong> with the Intel Pentium Dual T3200 processor, 2 GB DDR2 main m<strong>em</strong>ory and Ubuntu<br />
Linux 9.04 operating syst<strong>em</strong>.<br />
Each test consisted on configuring an application by invoking SmART with the application<br />
configuration file. The configuration files were converted in XML and then converted back to<br />
their original format. Between the tests, the file was not modified, since Section 3.2 showed<br />
that file modification is not part of this dissertation scope.<br />
Due to the consi<strong>de</strong>rable length of each file, the tested configuration files are not integrally<br />
displayed in this section. Instead, they can be found in the appendix section of this dissertation<br />
(Chapter B). The examples refer to parts of the configuration file which were handpicked to<br />
display the tool behaviour in the presence of each pattern impl<strong>em</strong>ented by the file.<br />
To check the differences between the original and final file, the diff 1 UNIX utility was used.<br />
diff is a file comparison utility that shows the differences between two text files, in terms of<br />
different lines. Whenever lines from both files differ, the result shows the divergent lines of the<br />
original configuration file, and then those from the generated configuration file.<br />
5.2.1 INI-like Configuration Files<br />
This test consisted on configuring the MySQL database manag<strong>em</strong>ent syst<strong>em</strong>. The MySQL con-<br />
figuration file format is a slightly altered version of the INI format, but is still recognized<br />
by the tool. The configuration file (Listing 5.1) impl<strong>em</strong>ents parameters with zero or one as-<br />
signed values, contained in blocks <strong>de</strong>limited by a static hea<strong>de</strong>r (lines 1-4), comments (line<br />
6) and special instructions (line 8). The complete configuration file is in Annex B.1. The<br />
file containing the co<strong>de</strong> generated by the tool for this configuration file is found at http:<br />
//www-asc.di.fct.unl.pt/˜jml/SmART/ini.xml.<br />
The tool produced the following XML for the block (Listing 5.2), comment (Listing 5.3) and<br />
special instruction (Listing 5.4):<br />
The Metadata generated by the tool is represented on Figure 5.5.<br />
1 http://www.gnu.org/software/diffutils/diffutils.html<br />
54
5. FRAMEWORK EVALUATION 5.2. Operational Validation<br />
Listing 5.2: MySQL block in XML<br />
<br />
%m.start%a.name%m.end%n%c%c%c%c<br />
<br />
%e%n<br />
quick<br />
<br />
<br />
%e%n<br />
quote-names<br />
<br />
<br />
%e%m.equal%e%n<br />
max_allowed_packet<br />
16M<br />
<br />
<br />
%n<br />
<br />
<br />
Listing 5.3: MySQL comment in XML<br />
<br />
%m.start%e%n<br />
The MySQL database server configuration file.<br />
<br />
Listing 5.4: MySQL special instruction in XML<br />
<br />
%m.start%e%n<br />
inclu<strong>de</strong>dir /etc/mysql/conf.d/<br />
<br />
55
5. FRAMEWORK EVALUATION 5.2. Operational Validation<br />
<br />
<br />
#<br />
<br />
<br />
=<br />
<br />
<br />
[<br />
]<br />
<br />
<br />
!<br />
<br />
<br />
Listing 5.5: MySQL Metadata<br />
The file was re-converted to its original syntax. diff showed that the differences between<br />
the original and generated files resume to a few absent spaces from the first to the second. This<br />
happens since the parser ignores the space characters outsi<strong>de</strong> strings. As MySQL ignores the<br />
spaces in configuration files, the file functionality is maintained.<br />
5.2.2 Apache-like Configuration Files<br />
This test consisted on configuring the Apache HTTP server. The Apache configuration file<br />
(Listing 5.6) impl<strong>em</strong>ents parameters with a single value (line 1), parameters with multiple val-<br />
ues (lines 3-4), blocks (lines 6-8), nested blocks (10-14) and comments (line 16). The complete<br />
configuration file is in Annex B.2. The file containing the co<strong>de</strong> generated by the tool for this con-<br />
figuration file is found at http://www-asc.di.fct.unl.pt/˜jml/SmART/blox.xml.<br />
The tool produced the following XML for the parameter with a single value (Listing 5.7),<br />
parameter with multiple values (Listing 5.8), block (Listing 5.9), nested (Listing 5.10) and com-<br />
ment (Listing 5.11):<br />
The Metadata generated by the tool is represented on Figure 5.12.<br />
The file was re-converted to its original syntax. diff showed that the differences between<br />
the original and generated files are some absent new lines and tabulations. Once again, this is<br />
due to the parser which ignores some new lines and tabulations. However, this does not affect<br />
in any way the functionality of the new file, so the result is valid.<br />
5.2.3 XML-like Configuration Files<br />
This test consisted on configuring the Eclipse workbench. The Eclipse workbench configura-<br />
tion (Listing 5.13) file is originally on XML format and impl<strong>em</strong>ents <strong>em</strong>pty el<strong>em</strong>ents/blocks<br />
(line 1), el<strong>em</strong>ents with attributes/blocks containing parameters (line 3-4), nested blocks (lines<br />
56
5. FRAMEWORK EVALUATION 5.2. Operational Validation<br />
1 ServerType standalone<br />
2<br />
Listing 5.6: Apache configuration file snippet<br />
3 DirectoryIn<strong>de</strong>x in<strong>de</strong>x.html in<strong>de</strong>x.htm in<strong>de</strong>x.shtml <strong>de</strong>fault.htm<br />
4 <strong>de</strong>fault.html in<strong>de</strong>x.php<br />
5<br />
6 <br />
7 MIMEMagicFile /usr/local/apache/conf/magic<br />
8 <br />
9<br />
10 <br />
11 <br />
12 Options In<strong>de</strong>xes MultiViews<br />
13 <br />
14 <br />
15<br />
16 # httpd.conf -- Apache HTTP server configuration file<br />
Listing 5.7: Apache parameter with a single value in XML<br />
<br />
%e%m.equal%e<br />
ServerType<br />
standalone<br />
<br />
Listing 5.8: Apache parameter with multiple values in XML<br />
<br />
%e%m.equal%e%m.equal%e%m.equal%e%m.equal%e%m.equal%e%m.<br />
equal%e<br />
DirectoryIn<strong>de</strong>x<br />
in<strong>de</strong>x.html<br />
in<strong>de</strong>x.htm<br />
in<strong>de</strong>x.shtml<br />
<strong>de</strong>fault.htm<br />
<strong>de</strong>fault.html<br />
in<strong>de</strong>x.php<br />
<br />
57
5. FRAMEWORK EVALUATION 5.2. Operational Validation<br />
Listing 5.9: Apache block in XML<br />
<br />
%c%c%c%c%c<br />
<br />
%m.start%a.name%m.end<br />
<br />
<br />
%n<br />
<br />
<br />
%e%m.equal%e<br />
MIMEMagicFile<br />
/usr/local/apache/conf/magic<br />
<br />
<br />
%n<br />
<br />
<br />
%m.start%a.name%m.end<br />
<br />
<br />
6-8) and comments (line 10). The complete configuration file is in Annex B.3. The file contain-<br />
ing the co<strong>de</strong> generated by the tool for this configuration file is found at http://www-asc.<br />
di.fct.unl.pt/˜jml/SmART/xml.xml.<br />
The tool produced the following XML for the <strong>em</strong>pty block (Listing 5.14), block containing<br />
parameters (Listing 5.15), nested blocks (Listing 5.16) and comments (Listing 5.17):<br />
The Metadata generated by the tool is represented on Listing 5.18.<br />
Then, the file was re-converted to its original syntax. diff showed that the differences be-<br />
tween the original and generated files are some extra new lines in the generated file. This is due<br />
to the original file having a dual criteria for new lines. In some places, an XML tag is followed<br />
by a new line, where in other places they are not.<br />
Still, the tool is able to recognize the whole file, and it produces a file which is completely<br />
functional and well <strong>de</strong>fined.<br />
5.2.4 Parsing the Generated XML<br />
In or<strong>de</strong>r to make sure that the XML file generated by the tool was in<strong>de</strong>ed valid, an experiment<br />
was carried: parsing the file generated by the tool. Beforehand, the tool should be able to parse<br />
the generated XML file since it is able to parse files res<strong>em</strong>blant to XML.<br />
First, OGC (Original to Generic syntax Converter) was called to parse a configuration file.<br />
From this parse resulted the file xml1. Then, OGC was called again to parse xml1 into xml2.<br />
Then, GOC (Generic to Original syntax Converter) was called to print xml2 into xml3, and<br />
finally GOC was called again to print xml3 into the final file. This is <strong>de</strong>picted in Figure 5.1.<br />
58
5. FRAMEWORK EVALUATION 5.2. Operational Validation<br />
Listing 5.10: Apache nested block in XML<br />
<br />
%c%c%c%c<br />
<br />
%m.start%a.name%m.end<br />
<br />
<br />
%n<br />
<br />
<br />
%c%c%c%c%c<br />
<br />
%m.start%a.name%m.end<br />
<br />
<br />
%n<br />
<br />
<br />
%e%m.equal%e%m.equal%e<br />
Options<br />
In<strong>de</strong>xes<br />
MultiViews<br />
<br />
<br />
%n<br />
<br />
<br />
%m.start%a.name%m.end<br />
<br />
<br />
<br />
%m.start%a.name%m.end<br />
<br />
<br />
Listing 5.11: Apache comment<br />
<br />
%m.start%e%m.end<br />
# httpd.conf -- Apache HTTP server configuration file<br />
<br />
59
5. FRAMEWORK EVALUATION 5.2. Operational Validation<br />
<br />
<br />
#<br />
\n<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
1 <br />
2<br />
Listing 5.12: Apache Metadata<br />
Listing 5.13: Eclipse configuration file snippet<br />
3 <br />
5<br />
6 <br />
7 <br />
8 <br />
9<br />
10 <br />
Listing 5.14: Eclipse <strong>em</strong>pty block in XML<br />
<br />
%m.start%a.name%m.end<br />
<br />
60
5. FRAMEWORK EVALUATION 5.2. Operational Validation<br />
Listing 5.15: Eclipse block with parameters in XML<br />
<br />
%m.start%a.name%s%c%s%c%s%c%s%c%m.end<br />
<br />
%e%m.equal%e<br />
id<br />
"org.eclipse.ui.workbench.file"<br />
<br />
<br />
%e%m.equal%e<br />
it<strong>em</strong>Type<br />
"typeToolBarContribution"<br />
<br />
<br />
%e%m.equal%e<br />
x<br />
"104"<br />
<br />
<br />
%e%m.equal%e<br />
y<br />
"30"<br />
<br />
<br />
Listing 5.16: Eclipse nested blocks in XML<br />
<br />
%c%c%c<br />
<br />
%m.start%a.name%m.end<br />
<br />
<br />
%m.start%a.name%s%c%m.end<br />
<br />
%e%m.equal%e<br />
x<br />
"196"<br />
<br />
<br />
<br />
%m.start%a.name%m.end<br />
<br />
<br />
61
5. FRAMEWORK EVALUATION 5.2. Operational Validation<br />
<br />
%m.start%e%m.end<br />
this is a comment<br />
<br />
Listing 5.17: Eclipse comment in XML<br />
Listing 5.18: Eclipse Metadata<br />
<br />
<br />
<br />
<br />
<br />
=<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
62
5. FRAMEWORK EVALUATION 5.3. Performance Validation<br />
!"#$#%&'(<br />
)#'*<br />
+,'-<br />
+,'.<br />
0<br />
0<br />
+,'/<br />
Figure 5.1: Parsing the generated XML<br />
)#%&'()#'*<br />
Before the test, xml1 was expected to be equal to xml3 and the original file to be equal to<br />
the final file. diff showed that xml1 was exactly equal to xml3 and that the original file only<br />
differed from final in the sense that only a few new lines were omitted from the original file,<br />
analogously to the test in Section 5.2.3. Still, the final file r<strong>em</strong>ains recognizable by XML parsers,<br />
since they also ignore new lines. Moreover, the tool was shown to produce valid XML files<br />
since it is capable of parsing th<strong>em</strong> over again.<br />
5.3 Performance Validation<br />
This section studies how the tool behaves in the presence of configuration files with different<br />
sizes. Despite not having been <strong>de</strong>signed to excel performance-wise, obtained performance<br />
results by the tool might turn out to be interesting.<br />
The tested configuration files are from PostgreSQL and are all recognized by an INI-like<br />
parser. These are:<br />
• file α with 1,4 KB (Annex B.4)<br />
• file β with 3,5 KB (Annex B.5)<br />
• file γ with 16,6 KB (Annex B.6)<br />
These files were selected to verify if there is any relation between the file size and the time<br />
it takes to configure each one. The final results are represented as the sum of two times: the<br />
63
5. FRAMEWORK EVALUATION 5.3. Performance Validation<br />
time to convert the file into generic XML, step 1, and the time to convert the file from XML into<br />
its original syntax, step 2.<br />
File α:<br />
Step 1: 0,143 s<br />
Step 2: 0,073 s<br />
Total time: 0,216 s<br />
File β:<br />
Step 1: 0,191 s<br />
Step 2: 0,086 s<br />
Total time: 0,277 s<br />
File γ:<br />
Step 1: 0,463 s<br />
Step 2: 0,262 s<br />
Total time: 0,725 s<br />
This test shows that for short configuration files, the elapsed times to convert a file to XML<br />
and back to its original format are similar. An interpretation of these results might be that the<br />
configuration work done by the tool is very small, whereas the majority of the elapsed time<br />
was spent doing computational tasks such as m<strong>em</strong>ory allocations, etc. However, as the files<br />
become bigger, so does the time to convert th<strong>em</strong>, although in a disproportionate way. γ is<br />
almost 5 times bigger than β, nevertheless, γ only takes 2.5 times more than β to be converted<br />
in both ways.<br />
Taking into account the average file size of VIRTU’s use case application configuration files,<br />
which is nearly 20KB, we can also conclu<strong>de</strong> that the time spent to configure a configuration file<br />
is sustainable. Nevertheless, the tool may require consi<strong>de</strong>rable amounts of time to carry certain<br />
tasks, like parser creation. During impl<strong>em</strong>entation, we realised that some parsers took a while<br />
to compile while others were compiled almost instantly. Following is an analysis to the JavaCC<br />
parser generator which, in spite of approaching el<strong>em</strong>ents that fall out of this dissertation scope,<br />
aims at comprehending the impact of the parser generation process in the tool’s performance.<br />
In this analysis, we compile the three parsers that the tool supports by <strong>de</strong>fault and present the<br />
elapsed times for each (Table 5.1).<br />
An interpretation of the obtained times might tell us that the nee<strong>de</strong>d time to compile a<br />
parser is also sustainable. However, the compiled parsers are not too complex and basing<br />
any conclusion exclusively on these timings may be misleading. To assess more accurately the<br />
64
5. FRAMEWORK EVALUATION 5.3. Performance Validation<br />
INI Apache XML<br />
0,270s 0,280s 0,300s<br />
Table 5.1: Elapsed times for parser compilation in JavaCC<br />
required time for parser generation tasks, we compiled a parser which recognizes a more com-<br />
plex language, the Java language, and the elapsed time was 0,550s. This allows us to conclu<strong>de</strong><br />
that, even for fairly complex languages, the parser generation time is very bearable. Nonethe-<br />
less, these timings refer to the JavaCC parser generator, as we also generated some parsers<br />
with SableCC and, although most parsers took as long as JavaCC’s to compile, parsers for very<br />
complex languages can take up to minutes to compile.<br />
65
6<br />
Integration with VIRTU<br />
The last chapter validated the framework, <strong>de</strong>fined in Chapter 3, in terms of how it met the<br />
requir<strong>em</strong>ents, its functionality and also its performance. We now find SmART suitable to be<br />
integrated with the VIRTU virtualization platform.<br />
This chapter <strong>de</strong>scribes how SmART can be integrated within the VIRTU tool. First, Sec-<br />
tion 6.1 gives the background of the VIRTU project, together with the motivation for its creation<br />
and a brief <strong>de</strong>scription. Then, Section 6.2 presents the VIRTU workflow with the objective of<br />
giving a better perspective of the operations allowed by the tool. The VIRTU architecture is<br />
<strong>de</strong>tailed in Section 6.3, with the <strong>de</strong>scription of each component and its interactions with the<br />
other components. Finally, the localization of the integration, both in the workflow and in the<br />
architecture, is indicated and explained in Section 6.4.<br />
6.1 Project Description<br />
A consortium of enterprises and universities, composed of Evolve Space Solutions, Universi-<br />
da<strong>de</strong> Nova <strong>de</strong> Lisboa, Universida<strong>de</strong> <strong>de</strong> Coimbra, HP Labs and the European Space Agency,<br />
fun<strong>de</strong>d by QREN/ADI, came together to <strong>de</strong>velop a virtualization platform known as project<br />
VIRTU.<br />
In Section 2.1.1 we saw that virtualization is a technology for the abstraction of computing<br />
syst<strong>em</strong>s which has recently received a consi<strong>de</strong>rable number of contributions, <strong>de</strong>spite having<br />
<strong>em</strong>erged for the first time several years ago. The changes that virtualization allows for in the<br />
IT sector, such as the consolidation of many servers into a single physical machine and the<br />
resulting lowering of hardware, cooling, power consumption and facility costs, short syst<strong>em</strong><br />
maintenance time, great isolation level between virtual machines, etc., have revolutionized the<br />
way IT-recurring companies look at software and hardware <strong>de</strong>ployment.<br />
67
6. INTEGRATION WITH VIRTU 6.2. VIRTU Top-Level Analysis<br />
Aware of this market shift, Evolve Space Solutions proposed VIRTU, a platform for the<br />
creation and manag<strong>em</strong>ent of virtual machines. Before that, the GoVI virtualization tool was<br />
<strong>de</strong>veloped for the European Space Agency in or<strong>de</strong>r to <strong>de</strong>al with some outstanding probl<strong>em</strong>s<br />
in their IT infrastructure, such as the large number of un<strong>de</strong>rutilized machines, great <strong>de</strong>mand<br />
for isolation and a myriad of different hardware platforms. The <strong>de</strong>velopment on VIRTU ini-<br />
tially took on the GoVI infrastructure as a starting point, but eventually evolved to become an<br />
in<strong>de</strong>pen<strong>de</strong>nt project, <strong>de</strong>ttached from the former.<br />
VIRTU explores interoperability between virtualization solutions, such as Xen [Cit09] or<br />
VMware [VMw09]. One way to achieve portability of VMs among different virtualization plat-<br />
forms is to resort to virtualization standards. Open Virtual Machine Format (see Section 2.1.3),<br />
which is being <strong>de</strong>veloped by the biggest virtualization players, is one of such standards and<br />
VIRTU might evolve to support it.<br />
Another big opportunity in the virtualization area is the fact that application configuration<br />
is still largely a manual task. The complexity of configuring a syst<strong>em</strong> with manifold applica-<br />
tions, <strong>em</strong>ploying different configuration formats, can be frightening for a syst<strong>em</strong> administrator.<br />
This complexity is only magnified when <strong>de</strong>aling with a huge syst<strong>em</strong>, composed of hundreds,<br />
or even thousands of such syst<strong>em</strong>s. To ease the syst<strong>em</strong> maintenance bur<strong>de</strong>n, VIRTU proposes<br />
the generic automatic application configuration or, in other words, the ability to configure any<br />
application, regardless of its vendor or configuration representation, on the most autonomous<br />
and automatic manner.<br />
The framework presented by this dissertation, SmART, is the Universida<strong>de</strong> Nova <strong>de</strong> Lisboa<br />
contribution for project VIRTU. Once SmART was completed, it was integrated with the whole<br />
VIRTU tool.<br />
6.2 VIRTU Top-Level Analysis<br />
The VIRTU tool [Sol09b] impl<strong>em</strong>ents the concept of Ass<strong>em</strong>bly Instance, which refers to<br />
one, or a set of virtual machines that the users will use and manage directly. An Ass<strong>em</strong>bly<br />
Instance results from the instantiation of an Ass<strong>em</strong>bly Configuration, which contains<br />
the information used to generate one VM, or a set of VMs. To each VM in an Ass<strong>em</strong>bly<br />
Configuration corresponds a Virtual Machine Configuration and when an<br />
Ass<strong>em</strong>bly Configuration is instanced, its VM Configurations are also instanced into<br />
VM Instances. Each Virtual Machine Configuration is a combination of Building<br />
Blocks and Publication Files. A Building Block is a t<strong>em</strong>plate el<strong>em</strong>ent, such as<br />
an operating syst<strong>em</strong>, application or virtual machine, whereas a Publication File con-<br />
tains the <strong>de</strong>sired configuration of a Building Block. In or<strong>de</strong>r to re-use previously existing<br />
Ass<strong>em</strong>bly Configurations, it is also possible for Ass<strong>em</strong>bly Configurations to con-<br />
tain other Ass<strong>em</strong>bly Configurations. The VIRTU Ass<strong>em</strong>bly Configuration mo<strong>de</strong>l is<br />
<strong>de</strong>picted in Figure 6.1.<br />
The configuration of an Ass<strong>em</strong>bly Instance is carried at the level of its VM Instances.<br />
Insi<strong>de</strong> a VM Instance resi<strong>de</strong>s a process which is ran at every VM boot and, for each<br />
68
6. INTEGRATION WITH VIRTU 6.2. VIRTU Top-Level Analysis<br />
34(<br />
)*+,-./012-*+<br />
6/-&7-+.(<br />
6&*89<br />
:/%&-812-*+(<br />
;-&#<br />
!""#$%&'(<br />
)*+,-./012-*+<br />
34(<br />
)*+,-./012-*+<br />
6/-&7-+.(<br />
6&*89<br />
:/%&-812-*+(<br />
;-&#<br />
5(5(5<br />
5(5(5<br />
6/-&7-+.(<br />
6&*89<br />
:/%&-812-*+(<br />
;-&#<br />
Figure 6.1: VIRTU Ass<strong>em</strong>bly Configuration<br />
34(<br />
)*+,-./012-*+<br />
Publication File, checks a flag that tells if that Publication File was altered since the<br />
last boot. If not, no action is taken for that Building Block. Otherwise, if a Publication<br />
File is in<strong>de</strong>ed different, it means the Building Block associated to that Publication<br />
File has altered variables or different operating mo<strong>de</strong>s and, consequently, the configuration<br />
files for that Building Block must be rebuilt. This rebuilding is done by the process itself<br />
and once it is finished, the flag is reset.<br />
The actors in the VIRTU tool can be administrators or users. Each role is allowed to perform<br />
different actions that may be divi<strong>de</strong>d in two categories: virtual machine manag<strong>em</strong>ent and user<br />
manag<strong>em</strong>ent.<br />
An administrator has the permission to manage (i.e., create, edit and <strong>de</strong>lete) the tool’s<br />
Building Blocks and Publication Files, to construct Ass<strong>em</strong>bly Configurations,<br />
to accept Ass<strong>em</strong>bly Instance requests from the user and <strong>de</strong>ploy those Ass<strong>em</strong>bly<br />
Instances and to manage the running Instances, with the option of halting their execution.<br />
The administrator may also create and manage the users of the tool.<br />
On the other hand, the actions available to users are to configure Publication Files,<br />
to request Ass<strong>em</strong>bly Instances, to use the virtual machines and control their lifecycle, to<br />
share Ass<strong>em</strong>bly Instances with other users and to organize th<strong>em</strong>. Beyond that, the user<br />
may also change his password.<br />
On a broad view, VIRTU may be divi<strong>de</strong>d into a handful of logical modules. This division<br />
aims at increasing agility and flexibility in the maintenance and optimization of the syst<strong>em</strong><br />
resources. A sch<strong>em</strong>e containing the modules is shown in Figure 6.2.<br />
The VIRTU Configuration Database stores all information regarding the tool, such as<br />
user accounts, the locations of the available Building Blocks, Ass<strong>em</strong>bly<br />
69
6. INTEGRATION WITH VIRTU 6.3. VIRTU Architecture<br />
34567<br />
8#$9/1+":%/#$)<br />
;:%: ?'"@'" 34567<br />
?'"@'" .,#2A)<br />
;:%:-%#"'<br />
B2,/=-')<br />
3/'C-<br />
34567)<br />
D==,/2:%/#$<br />
?'"@'"<br />
E'<<br />
!"#$%&'$()*#(+,'-)<br />
Figure 6.2: VIRTU Logical View<br />
3*)4$-%:$2'-<br />
?'"@/2'-<br />
3/"%+:,/F:%/#$<br />
?'"@/2'-<br />
Configurations and Instances and users reports and suggestions. The VIRTU Block<br />
Datastore is the physical storage for the available Building Blocks. The VIRTU<br />
Application Server provi<strong>de</strong>s access to the tool for users and administrators, together with<br />
the processing logic. The Virtualization Services is where the virtualization is handled.<br />
It contains the virtualization servers and the existing virtual machines. Finally, the Eclipse<br />
Views and Web Front-End are interfaces used to allow interaction with the user through an<br />
application or a typical web browser.<br />
6.3 VIRTU Architecture<br />
The VIRTU tool arcitecture is structured in a three-tier architecture, as <strong>de</strong>picted in Figure 6.3.<br />
Following is <strong>de</strong>scription of each layer and the respective components.<br />
6.3.1 Data and Resources Layer<br />
The Data and Resources Layer provi<strong>de</strong>s the storage utility for the syst<strong>em</strong> and hosts the<br />
syst<strong>em</strong>’s virtualization layer. It is composed by the Block Datastore, the Configuration<br />
Database and Virtualization Services.<br />
Block Datastore<br />
The Block Datastore is an abstraction for the physical storage of the Building Blocks<br />
. It may have multiple instances and can be distributed over different physical locations. It<br />
allows Building Blocks from another syst<strong>em</strong> to be uploa<strong>de</strong>d, to create, modify and <strong>de</strong>lete<br />
70<br />
B?.
6. INTEGRATION WITH VIRTU 6.3. VIRTU Architecture<br />
0,()(%#"#1*%$."/(,<br />
0,*-())1%2$."/(,<br />
F)(,<br />
G"%"2(=(%#<br />
!"#"$"%&$'()*+,-()$."/(,<br />
D4*-E$<br />
!"#")#*,(<br />
3-415)($61(7)<br />
8,*%#9(%&<br />
*%?12+,"#*,<br />
>*%?12+,"#1*%$<br />
!"#";")(<br />
:(;<br />
8,*%#9(%&<br />
*%#,*44(,<br />
61,#+"41@"#1*%$<br />
A(,B1-()<br />
Figure 6.3: VIRTU Architectural Design<br />
0,*-())1%2$H%#(,?"-()$."/(,<br />
3C#(,%"4$<br />
1%#(,?"-()<br />
3C#(,%"4$<br />
6. INTEGRATION WITH VIRTU 6.3. VIRTU Architecture<br />
It provi<strong>de</strong>s a number of features for the manag<strong>em</strong>ent of the tool information by interact-<br />
ing with other components. The User Manag<strong>em</strong>ent performs user (creation, edition, <strong>de</strong>le-<br />
tion), password (change) and role (set user, administrator) manag<strong>em</strong>ent on it, the Ass<strong>em</strong>bly<br />
Configurator uses it to manage the available Publication Files, Building Blocks,<br />
VM Configurations and Ass<strong>em</strong>bly Configurations and, finally, the Ass<strong>em</strong>bly<br />
Controller accesses the Ass<strong>em</strong>bly Instances in run-time from it.<br />
Virtualization Services<br />
The Virtualization Services contain the syst<strong>em</strong>’s virtualization layer which provi<strong>de</strong>s<br />
the virtualization foundations for the running virtual machines, together with each virtual ma-<br />
chine instance hosted by the tool. It provi<strong>de</strong>s the basic VM operations such as start, stop, pause,<br />
create, <strong>de</strong>lete, etc., and the support to configure and install applications at first-run time.<br />
6.3.2 Processing Layer<br />
The Processing Layer is where all the tool operations are ran and the tool workflow is<br />
impl<strong>em</strong>ented and managed.<br />
User Manag<strong>em</strong>ent<br />
The User Manag<strong>em</strong>ent is the component which controls the user-oriented operations. It han-<br />
dles operations like login checking, password changes, role attributions and creation/<strong>de</strong>le-<br />
tion of users. The access to the User Manag<strong>em</strong>ent is provi<strong>de</strong>d by the Eclipse Views<br />
Front-End and the External Interfaces, in case of a stand-alone application or a web-<br />
service access, respectively. The effects of the operations are reflected in the Configuration<br />
Database, un<strong>de</strong>r the user related tables.<br />
Ass<strong>em</strong>bly Configurator<br />
The Ass<strong>em</strong>bly Configurator allows the administrators to create, edit or <strong>de</strong>lete Ass<strong>em</strong>bly<br />
Configurations and the Building Blocks and Publication Files that compose<br />
those Ass<strong>em</strong>blies. As for the user, he may search through the existing Ass<strong>em</strong>bly<br />
Configurations, request instances of some of th<strong>em</strong> and edit Publication Files asso-<br />
ciated to those instances. Finally, the Ass<strong>em</strong>bly Configurator also reports bugs to the ad-<br />
ministrator.<br />
The access to the Ass<strong>em</strong>bly Configurator is provi<strong>de</strong>d by the Eclipse Views Front<br />
-End and the External Interfaces. The Ass<strong>em</strong>bly Configurator interacts with the<br />
Configuration Database to manage the Ass<strong>em</strong>bly <strong>de</strong>finitions and the Block Datastore<br />
to manage the Building Blocks.<br />
72
6. INTEGRATION WITH VIRTU 6.3. VIRTU Architecture<br />
Ass<strong>em</strong>bly Controller<br />
The Ass<strong>em</strong>bly Controller allows the administrator to control Ass<strong>em</strong>bly Instances in<br />
run-time and accept or <strong>de</strong>cline user requests for new Ass<strong>em</strong>bly Instances, as well as <strong>de</strong>lete<br />
the existing ones. The user may, in turn, request new Ass<strong>em</strong>bly Instances, share<br />
Instances with other users and organize th<strong>em</strong>, access the Instances (i.e., through R<strong>em</strong>ote<br />
Desktop) and control th<strong>em</strong>.<br />
Interaction with the user resorts to the Eclipse Views Front-End and the External<br />
Interfaces. The Ass<strong>em</strong>bly Controller accesses the Configuration Database to<br />
get any Ass<strong>em</strong>bly Instance state on any time, the Block Datastore to request physical<br />
Building Block <strong>de</strong>ployment and the Virtualization Services to perform basic VM<br />
manag<strong>em</strong>ent operations.<br />
External Interfaces<br />
The External Interfaces allow the interaction of the tool with other existing infrastruc-<br />
tures. It <strong>de</strong>fines a set of components for the communication with the Processing Layer<br />
. The External Interfaces interactions cover every component in the Processing<br />
Layer since this is the component which allows the integration with third-party el<strong>em</strong>ents.<br />
The User Manag<strong>em</strong>ent is used for password, login and role manag<strong>em</strong>ent, the Ass<strong>em</strong>bly<br />
Configurator is used for the manag<strong>em</strong>ent of Ass<strong>em</strong>bly Configurations, the Ass<strong>em</strong>bly<br />
Controller is used for VM lifecycle manag<strong>em</strong>ent and r<strong>em</strong>ote connection operations and<br />
the Web Front-End and the External Applications are used to allow the access to the<br />
tool from a web-browser or a third-party infrastructure.<br />
6.3.3 Presentation Layer<br />
The Presentation Layer contains the el<strong>em</strong>ents which allow the interaction with users and<br />
administrators.<br />
Eclipse Views Front-End<br />
The Eclipse Views Front-End provi<strong>de</strong>s access to the tool through a stand-alone appli-<br />
cation, based on the Eclipse RCP, which supplies views and perspectives corresponding the<br />
functionalities available to users and administrators. This component interacts with all other<br />
components in the Processing Layer to reflect the users’ and administrators’ requests.<br />
Web Front-End<br />
The Web Front-End objective is to allow interaction with the tool by means of a regular web<br />
browser, requiring no special applications to be installed in or<strong>de</strong>r to communicate with the<br />
tool and allowing access from <strong>de</strong>vices other than typical computers, such as smart-phones<br />
or thin-clients. Unlike Eclipse Views Front-End which communicates directly with the<br />
73
6. INTEGRATION WITH VIRTU 6.4. SmART integration<br />
Processing Layer, the Web Front-End uses the External Interfaces component as<br />
an interface to the tool.<br />
6.3.4 Other Notable Sectors<br />
Apart from the presented layers and components, VIRTU makes use of other sectors that are not<br />
inclu<strong>de</strong>d in the tool architecture, but their relevance is consi<strong>de</strong>rable enough for the integration<br />
of SmART with VIRTU.<br />
The VIRTU tool <strong>em</strong>ploys some third-party software which is also integrated with the tool,<br />
as is the case of MySQL for the provision of a relational database manag<strong>em</strong>ent syst<strong>em</strong> or Eclipse<br />
for the linkage of Java objects to the database. These components are COTS (Commercial, off-<br />
the-shelf), software built by other entities which can be integrated with the objective of quickly<br />
providing functionalities to the tool, possibly saving time by r<strong>em</strong>oving the need to build those<br />
functionalities from scratch, but at the cost of some integration work. VIRTU keeps these third-<br />
party components in a CVS (Concurrent Versions Syst<strong>em</strong>) repository, from where they can be<br />
accessed.<br />
Another important data sector is located insi<strong>de</strong> the virtual machines created by the tool.<br />
This sector hosts the first-run and configuration scripts which are ran automatically by each<br />
virtual machine so that they get the required data from the tool autonomously.<br />
6.4 SmART integration<br />
The VIRTU workflow and architecture were <strong>de</strong>scribed in the previous sections. Using that<br />
knowledge, this section <strong>de</strong>scribes how SmART fits in the VIRTU workflow and the where-<br />
abouts of the SmART component plac<strong>em</strong>ent in the VIRTU architecture. The integration takes<br />
on both SmART major components, the Original to Generic syntax Converter (OGC) and the<br />
Generic to Original syntax Converter (GOC, see Section 3.2), and <strong>em</strong>ploys th<strong>em</strong> on separate<br />
VIRTU components. OGC is used in the creation of configuration file t<strong>em</strong>plates when adding<br />
new Building Blocks to VIRTU while GOC is used by the virtual machines to generate config-<br />
uration files from t<strong>em</strong>plates.<br />
In the VIRTU workflow, SmART will be called for the first time when an administrator adds<br />
new Building Blocks. As it was seen in Section 6.3.1, these can either be applications, oper-<br />
ating syst<strong>em</strong>s or virtual machines. In this case, a Publication File needs to be associated<br />
to that Building Block. For this en<strong>de</strong>avour, SmART is used to transpose the Building<br />
Block configuration files, whose parameterization is relevant, into XML documents, generat-<br />
ing a Publication File. This Publication File is then stored in the Configuration<br />
Database, from where it is obtained when its usage is required (i.e., when a user requires<br />
the instantiation of an Ass<strong>em</strong>bly Configuration composed by that Building Block).<br />
There might be the case where one or more configuration files of an application are unknown<br />
to the tool. If such is the occasion, the administrator must <strong>de</strong>fine a grammar which recognizes<br />
the new configuration file in or<strong>de</strong>r to build a parser for it. In the end, a new Building<br />
74
6. INTEGRATION WITH VIRTU 6.4. SmART integration<br />
!"#$%&'()*)+,-,./+&0-1)(<br />
F/+:.36(-,./+&<br />
A.@)&'-(*)(<br />
?2@.9*)&!.);*<br />
A(/+,8)+5<br />
%*)(&"+,)(:-2)<br />
!"#$%&'(/2)**.+3&0-1)(<br />
D**)EC@1&F/+:.36(-,/(<br />
F/5)&<br />
G)+)(-,/(<br />
F/+:.36(-,./+&<br />
4-,-C-*)<br />
'-(*)(&<br />
#)9/*.,/(1<br />
!"#$%&4-,-&-+5&#)*/6(2)*&0-1)(<br />
G(-EE-(&<br />
F/E9.@)(<br />
B)C<br />
A(/+,8)+5<br />
%*)(&"+,)(:-2)<br />
$)+,-,.>)&<br />
G(-EE-(&<br />
#)9/*.,/(1<br />
'-(*)(&<br />
G)+)(-,/(<br />
Figure 6.4: SmART integration points with VIRTU<br />
'(.+,)(
6. INTEGRATION WITH VIRTU 6.4. SmART integration<br />
• Parser Repository;<br />
• Co<strong>de</strong> Generator;<br />
• Grammar Compiler;<br />
• Tentative Grammar Repository.<br />
and the GOC is composed by Printer and PrinterMain.<br />
As previously mentioned, the two components perform disparate functions. The sub-<br />
components in OGC will be merged with the Ass<strong>em</strong>bly Configuration creation<br />
part whereas GOC will integrate the configuration file generation part. Following is <strong>de</strong>eper<br />
explanation of the integration of the SmART components in the VIRTU tool.<br />
6.4.1 SmART Original to Generic syntax Converter<br />
SmART Parser Repository<br />
The lowest level integration will be that of the Parser Repository. After the parsers are<br />
created, they are inserted in the Configuration Database. This calls for the alteration of<br />
the relational database by adding parser-related relations to it and the alteration of VIRTU DB<br />
in or<strong>de</strong>r for the latter to support the necessary database operations for the creation, edition<br />
and <strong>de</strong>letion of parsers. The concept of Parser Repository will, therefore, refer to a set of<br />
database relations which can be accessed by other components through the VIRTU DB software<br />
layer.<br />
SmART Processing Layer and Tentative Grammar Repository<br />
Most of SmART’s core will be integrated with the VIRTU Ass<strong>em</strong>bly Configurator. Namely,<br />
SmART OGC’s Configuration File Parser, Co<strong>de</strong> Generator, Grammar Compiler<br />
and also Tentative Grammar Repository are due to be located un<strong>de</strong>r the Ass<strong>em</strong>bly<br />
Configurator. The reason for the localization of this merge is, as it was seen earlier in this<br />
section, the fact that SmART OGC is only accessed by the VIRTU tool on the process of creating<br />
new Ass<strong>em</strong>bly Configurations.<br />
In this way, the normal SmART workflow r<strong>em</strong>ains unchanged, apart from some small ad-<br />
justments. For instance, the Configuration File Parser will now receive parse requests<br />
from the VIRTU Presentation Layer and get the parsers by issuing parser queries to the<br />
Data Layer, by means of VIRTU DB. The Co<strong>de</strong> Generator will r<strong>em</strong>ain intact, since it only<br />
interacts with the Configuration File Parser. The Grammar Compiler will now ac-<br />
cess the parser generator from the VIRTU third-party software sector. As for the Tentative<br />
Grammar Repository, its integration with the VIRTU tool was found to be more suitable<br />
to the VIRTU Processing Layer, opposed to the SmART Storage Layer, since it will not<br />
store permanently any grammar, but rather act as a grammar browser, which saves the final<br />
76
6. INTEGRATION WITH VIRTU 6.5. Summary<br />
grammars with the corresponding parsers and discards the rest. Besi<strong>de</strong>s that, the Tentative<br />
Grammar Repository will now interact with the Eclipse Views and the Web Front-<br />
Ends.<br />
SmART User Interface<br />
The User Interface will be integrated in the Presentation Layer with the Eclipse<br />
Views Front-End and the Web Front-End, so as to provi<strong>de</strong> a way for the administrator<br />
to perform the tasks of creating the Publication Files, when new Building Blocks<br />
are ad<strong>de</strong>d to VIRTU, and building new grammars when parsers capable of recognizing the<br />
configuration files of the Building Blocks do not exist in the database.<br />
6.4.2 SmART Generic to Original syntax Converter<br />
As for Printer and PrinterMain, they will form an autonomous process in the boot sector<br />
of each virtual machine, which transforms a Publication File on a configuration file, if<br />
that Publication File modification flag is set.<br />
6.4.3 Parser Generator<br />
Much like in SmART, the Parser Generator component will be consi<strong>de</strong>red as third-party<br />
software, therefore, this component will resi<strong>de</strong> as an external package in the third-party soft-<br />
ware repository. It is accessed solely by the Grammar Compiler.<br />
6.5 Summary<br />
At the time of elaboration of this dissertation, the integration of SmART with VIRTU was only<br />
commencing. This chapter presents the result of project meetings where we analysed ways in<br />
which both tools can be merged, from the point of view of the VIRTU tool. The taken approxi-<br />
mation consists on joining the SmART components with the existing VIRTU ones.<br />
By merging the prototype of a framework on a bigger tool whose <strong>de</strong>velopment is well un-<br />
<strong>de</strong>r way, the adaptation of some prototype components should be expected. This is the case of<br />
the SmART Parser Repository, which will be tranformed from a simple list of parsers into<br />
a set of relations in the VIRTU Configuration Database. This adaptation is not straight-<br />
forward though, as with most of the available parser generators, the produced parsers will<br />
consist on a set of Java classes. The classes that compose the parser can be stored in the data-<br />
base without any hassle, nevertheless, they cannot be executed from there. Three alternatives<br />
for the execution of the parser classes were i<strong>de</strong>ntified: to copy the classes locally to a t<strong>em</strong>porary<br />
fol<strong>de</strong>r and execute th<strong>em</strong>; to copy the classes to m<strong>em</strong>ory and run th<strong>em</strong> from there; to execute<br />
a database method which allows the parser classes to be ran from the database. After the<br />
project meeting, another solution for this probl<strong>em</strong> was i<strong>de</strong>ntified, which consists on gathering<br />
the parser classes in a .JAR container [Mic09d] and storing the packages in the database. In this<br />
77
6. INTEGRATION WITH VIRTU 6.5. Summary<br />
way, each class in the package knows the exact location of the others and is always able to call<br />
th<strong>em</strong>.<br />
There are still two components left to impl<strong>em</strong>ent: the graphical interface for the User<br />
Interface and the configurator.<br />
The first consists on a graphical interface which allows the administrator to <strong>de</strong>fine new<br />
grammars, in a practical and efficient way. It should provi<strong>de</strong> the administrator with func-<br />
tionalities such as configuration file syntax highlight, new pattern <strong>de</strong>finition, etc. The SmART<br />
prototype offers the necessary functionalities for the impl<strong>em</strong>entation of this component, there-<br />
fore, the r<strong>em</strong>aining work consists on <strong>de</strong>signing the graphical interface and linking it with the<br />
other SmART components.<br />
The impl<strong>em</strong>entation of the configurator involves the <strong>de</strong>sign of an interface from where the<br />
user can alter the configuration file parameters. This interface should also generate a script<br />
which recognizes the XML generic syntax. That script is used to traverse a Publication File,<br />
applying the required changes as it comes upon the right parameters, consequently generating<br />
a new Publication File containing the <strong>de</strong>sired parameterization.<br />
Apart from the previous consi<strong>de</strong>rations, the integration process should unfold in a seam-<br />
less way, providing the VIRTU tool with the ability to automatically configure applications,<br />
regardless of their vendors.<br />
78
7<br />
Conclusion and Future work<br />
The concepts of virtualization and, more particularly, virtual appliance, rose to significant im-<br />
portance in the last few years. Virtualization allows for the consolidation of many un<strong>de</strong>ruti-<br />
lized servers into fewer machines, increased infrastructural utilization, easy replication and<br />
replication of virtual machines, among many other benefits. Virtual appliances are a conse-<br />
quence of the virtualization advanc<strong>em</strong>ents and refer to VMs composed solely of a minimal OS<br />
and a set of applications, optimized to perform a specific computational task.<br />
The VIRTU project is a collective effort by a consortium of enterprises and universities,<br />
whose objective is to <strong>de</strong>velop a platform for the creation and manag<strong>em</strong>ent of virtual appliances.<br />
Nowadays, the offering of virtualization solutions is increasing each day, but the configuration<br />
of virtual appliances is still a mainly manual task. Since a single machine tends to garner<br />
many VAs, configuring th<strong>em</strong> in an effective way has become a probl<strong>em</strong>. VIRTU tries to exploit<br />
this opportunity by offering on-<strong>de</strong>mand configuration of applications, in<strong>de</strong>pen<strong>de</strong>ntly of their<br />
vendor.<br />
This thesis tackles the probl<strong>em</strong> of automatic configuration of applications, regardless of<br />
their vendors, in virtual appliances. The automatic configuration of applications is important<br />
since it allows for the reduction of required time to configure applications. It assumes a special<br />
importance if we consi<strong>de</strong>r a business scenario, where much time is wasted in configuration du-<br />
ties. A hurdle for the application configuration, regardless of the vendor, is that nowadays, ap-<br />
plications already represent their configurations on wi<strong>de</strong>ly adopted standards, although many<br />
of those standards exist and the majority of the applications resort to vendor-specific formats.<br />
The aim of this work consists on creating a framework that allows the abstraction of the used<br />
formats, allowing for the configuration process to be the same for every application, as well as<br />
automating that process from it results the least human interaction.<br />
At first, two possible ways to <strong>de</strong>al with this subject were approached: configure the appli-<br />
79
7. CONCLUSION AND FUTURE WORK 7.1. Future Work<br />
cation pre or post installation on the virtual appliance. Configuring the application before its<br />
installation on the virtual appliance consists on altering the configuration file in the applica-<br />
tion package and then install it on the virtual appliance. This approach was seen to lead to<br />
package redundancy, since the number of required different configuration will equate to the<br />
number of application packages to be installed. Moreover, in case of further configurations of<br />
an application, this approach requires a package to be re-installed on another VA.<br />
A better approach is the configuration post installation. In this approach, an application<br />
configuration file is extracted from insi<strong>de</strong> a VA and configured by the tool, only to be merged<br />
with the VA in the end of the configuration process. Although this approach requires knowl-<br />
edge of the application location, it allows for easy configuration of any number of virtual ap-<br />
pliances and, additionally, it does not force an application to be reinstalled in case of a recon-<br />
figuration.<br />
The Smart Application Reconfiguration Tool (SmART) is the contribution of this thesis for<br />
the automatic configuration of applications probl<strong>em</strong>. It processes the configuration files of the<br />
applications, applying a series a transformations on each file with the aim of abstracting th<strong>em</strong><br />
from their original formats and eventually converting th<strong>em</strong> back to their formats.<br />
One way to <strong>de</strong>al with the probl<strong>em</strong> is to take advantage of the patterns oftenly found in<br />
configuration files. A study conducted on the applications most likely to be encountered by<br />
the tool showed that the configuration files resort only to the concepts of parameter setting,<br />
parameter block and comment, whereas other patterns occur in a punctual way.<br />
After the <strong>de</strong>velopment phase had ceased, the tool was submitted to some tests so as to val-<br />
idate it. SmART was found to meet all the requir<strong>em</strong>ents i<strong>de</strong>ntified in the requir<strong>em</strong>ent analysis<br />
phase. Then, the configuration of some applications was <strong>de</strong>tailed. It shows the intermediate<br />
states of the configuration file and, in the end, the configuration file reproduced by the tool is<br />
shown to be functional.<br />
With the concept proved and having <strong>de</strong>veloped a functional prototype, the integration of<br />
the SmART tool with the VIRTU tool procee<strong>de</strong>d. This process is inten<strong>de</strong>d to provi<strong>de</strong> VIRTU<br />
with the ability to automatically configure applications, regardless of their vendors. To com-<br />
pl<strong>em</strong>ent this dissertation with reliable information about VIRTU, we spent two weeks with<br />
the Evolve team. The integrational process only started on the final term of the elaboration of<br />
the dissertation. Therefore, we can only offer a suggestion of how to execute the integration<br />
process, meanwhile i<strong>de</strong>ntifying the possible obstacles that might occur.<br />
7.1 Future Work<br />
Initially, the tool was thought to impl<strong>em</strong>ent a graphical interface for the grammar <strong>de</strong>finition<br />
process to become more natural to the user. However, in the end there was not enough time to<br />
study a graphical framework and, therefore, this feature was not impl<strong>em</strong>ented, although the<br />
current impl<strong>em</strong>entation allows the user to <strong>de</strong>fine a grammar. Nevertheless, this dissertation<br />
explains in <strong>de</strong>tail what utilities the interface must offer, and how they can be accomplished.<br />
Another suggestion for a future improv<strong>em</strong>ent on the tool is for it to infer the meanings of<br />
80
7. CONCLUSION AND FUTURE WORK 7.1. Future Work<br />
different patterns in new configuration file languages on its own, using grammar inference.<br />
Grammar inference [Hon], also known as automata induction, grammar induction and auto-<br />
matic language acquisition, is a field of research with the purpose of learning grammars and<br />
languages from data. It can be applied on the fields of syntatic pattern recognition, adaptative<br />
intelligent agents, diagnosis, computational biology, syst<strong>em</strong>s mo<strong>de</strong>lling, prediction, natural<br />
language acquisition, data mining and knowledge discovery. According to [PH01], it is possi-<br />
ble to learn grammars from simple examples, like sparse configuration files.<br />
There is active work on this subject, namely the GenParse project, which is a collaboration<br />
among the University of Alabama-Birmingham, U.S.A. and the University of Maribor, Slove-<br />
nia. It aims at easing the <strong>de</strong>velopment of Domain-Specific Languages and also at <strong>de</strong>veloping<br />
renovation tools for legacy syst<strong>em</strong>s. It makes use of the Genetic Programming paradigm to<br />
infer Context-Free Grammars.<br />
81
A.1 OGC sequence diagram<br />
A<br />
Appendix - Architecture<br />
83
A. APPENDIX - ARCHITECTURE A.1. OGC sequence diagram<br />
interaction OGC Sequence[ OGC Sequence ]<br />
alt<br />
: User : UI<br />
: CFP : PR<br />
: CG : GC<br />
: TGR<br />
[at least 1 parsed]<br />
[else]<br />
loop<br />
[reDoParse=OK]<br />
loop<br />
1: start(fileNames=file)<br />
8: successfulParse<br />
opt<br />
[ ]<br />
[reDoCompile=OK]<br />
11: submitGrammar()<br />
19: storeParser()<br />
22: successfulParse<br />
2: doParse(file=file)<br />
loop<br />
[all parsers tested]<br />
7: reDoParse<br />
15: doParse(file=file, parser=parser)<br />
18: reDoParse<br />
3: getIterator()<br />
4: parse<br />
5: doTranslate(parsingdata="pd")<br />
13: reDoCompile<br />
16: parse<br />
6: reDoTranslate<br />
12: doCompile(grammar=grammar)<br />
20: store(name=name, file=file, grammar=grammar)<br />
9: get(serialNumber=number)<br />
10: prev()<br />
14: store(grammarName=name, grammar=grammar)<br />
17: doTranslate(parsingdata=pd)<br />
21: discardAll()<br />
Figure A.1: Original to generic syntax converter sequence diagram<br />
84
B.1 MySQL Configuration file<br />
#<br />
# The MySQL database server configuration file.<br />
#<br />
# You can copy this to one of:<br />
# - "/etc/mysql/my.cnf" to set global options,<br />
# - "˜/.my.cnf" to set user-specific options.<br />
#<br />
B<br />
Appendix - Evaluation<br />
# One can use all long options that the program supports.<br />
# Run program with --help to get a list of available options and with<br />
# --print-<strong>de</strong>faults to see which it would actually un<strong>de</strong>rstand and use.<br />
#<br />
# For explanations see<br />
# http://<strong>de</strong>v.mysql.com/doc/mysql/en/server-syst<strong>em</strong>-variables.html<br />
# This will be passed to all mysql clients<br />
# It has been reported that passwords should be enclosed with ticks/<br />
quotes<br />
# escpecially if they contain "#" chars...<br />
# R<strong>em</strong><strong>em</strong>ber to edit /etc/mysql/<strong>de</strong>bian.cnf when changing the socket<br />
location.<br />
[client]<br />
port = 3306<br />
85
B. APPENDIX - EVALUATION B.1. MySQL Configuration file<br />
socket = /var/run/mysqld/mysqld.sock<br />
# Here is entries for some specific programs<br />
# The following values assume you have at least 32M ram<br />
# This was formally known as [safe_mysqld]. Both versions are<br />
currently parsed.<br />
[mysqld_safe]<br />
socket = /var/run/mysqld/mysqld.sock<br />
nice = 0<br />
[mysqld]<br />
#<br />
# * Basic Settings<br />
#<br />
#<br />
# * IMPORTANT<br />
# If you make changes to these settings and your syst<strong>em</strong> uses<br />
apparmor, you may<br />
# also need to also adjust /etc/apparmor.d/usr.sbin.mysqld.<br />
#<br />
user = mysql<br />
pid-file = /var/run/mysqld/mysqld.pid<br />
socket = /var/run/mysqld/mysqld.sock<br />
port = 3306<br />
basedir = /usr<br />
datadir = /var/lib/mysql<br />
tmpdir = /tmp<br />
skip-external-locking<br />
#<br />
# Instead of skip-networking the <strong>de</strong>fault is now to listen only on<br />
# localhost which is more compatible and is not less secure.<br />
bind-address = 127.0.0.1<br />
#<br />
# * Fine Tuning<br />
#<br />
key_buffer = 16M<br />
max_allowed_packet = 16M<br />
thread_stack = 128K<br />
86
B. APPENDIX - EVALUATION B.1. MySQL Configuration file<br />
thread_cache_size = 8<br />
# This replaces the startup script and checks MyISAM tables if nee<strong>de</strong>d<br />
# the first time they are touched<br />
myisam-recover = BACKUP<br />
#max_connections = 100<br />
#table_cache = 64<br />
#thread_concurrency = 10<br />
#<br />
# * Query Cache Configuration<br />
#<br />
query_cache_limit = 1M<br />
query_cache_size = 16M<br />
#<br />
# * Logging and Replication<br />
#<br />
# Both location gets rotated by the cronjob.<br />
# Be aware that this log type is a performance killer.<br />
#log = /var/log/mysql/mysql.log<br />
#<br />
# Error logging goes to syslog. This is a Debian improv<strong>em</strong>ent :)<br />
#<br />
# Here you can see queries with especially long duration<br />
#log_slow_queries = /var/log/mysql/mysql-slow.log<br />
#long_query_time = 2<br />
#log-queries-not-using-in<strong>de</strong>xes<br />
#<br />
# The following can be used as easy to replay backup logs or for<br />
replication.<br />
# note: if you are setting up a replication slave, see README.Debian<br />
about<br />
# other settings you may need to change.<br />
#server-id = 1<br />
#log_bin = /var/log/mysql/mysql-bin.log<br />
expire_logs_days = 10<br />
max_binlog_size = 100M<br />
#binlog_do_db = inclu<strong>de</strong>_database_name<br />
#binlog_ignore_db = inclu<strong>de</strong>_database_name<br />
#<br />
# * InnoDB<br />
#<br />
87
B. APPENDIX - EVALUATION B.1. MySQL Configuration file<br />
# InnoDB is enabled by <strong>de</strong>fault with a 10MB datafile in /var/lib/mysql<br />
/.<br />
# Read the manual for more InnoDB related options. There are many!<br />
# You might want to disable InnoDB to shrink the mysqld process by<br />
circa 100MB.<br />
#skip-innodb<br />
#<br />
# * Fe<strong>de</strong>rated<br />
#<br />
# The FEDERATED storage engine is disabled since 5.0.67 by <strong>de</strong>fault in<br />
the .cnf files<br />
# shipped with MySQL distributions (my-huge.cnf, my-medium.cnf, and<br />
#<br />
so forth).<br />
skip-fe<strong>de</strong>rated<br />
#<br />
# * Security Features<br />
#<br />
# Read the manual, too, if you want chroot!<br />
# chroot = /var/lib/mysql/<br />
#<br />
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca<br />
#<br />
".<br />
# ssl-ca=/etc/mysql/cacert.p<strong>em</strong><br />
# ssl-cert=/etc/mysql/server-cert.p<strong>em</strong><br />
# ssl-key=/etc/mysql/server-key.p<strong>em</strong><br />
[mysqldump]<br />
quick<br />
quote-names<br />
max_allowed_packet = 16M<br />
[mysql]<br />
#no-auto-rehash # faster start of mysql but no tab completition<br />
[isamchk]<br />
key_buffer = 16M<br />
88
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
#<br />
# * NDB Cluster<br />
#<br />
# See /usr/share/doc/mysql-server-*/README.Debian for more<br />
#<br />
information.<br />
# The following configuration is read by the NDB Data No<strong>de</strong>s (ndbd<br />
processes)<br />
# not from the NDB Manag<strong>em</strong>ent No<strong>de</strong>s (ndb_mgmd processes).<br />
#<br />
# [MYSQL_CLUSTER]<br />
# ndb-connectstring=127.0.0.1<br />
#<br />
# * IMPORTANT: Additional settings that can overri<strong>de</strong> those from this<br />
file!<br />
# The files must end with ’.cnf’, otherwise they’ll be ignored.<br />
#<br />
!inclu<strong>de</strong>dir /etc/mysql/conf.d/<br />
B.2 Apache Configuration File<br />
##<br />
## httpd.conf -- Apache HTTP server configuration file<br />
##<br />
#<br />
# Based upon the NCSA server configuration files originally by Rob<br />
#<br />
McCool.<br />
# This is the main Apache server configuration file. It contains the<br />
# configuration directives that give the server its instructions.<br />
# See for <strong>de</strong>tailed information<br />
about<br />
# the directives.<br />
#<br />
# Do NOT simply read the instructions in here without un<strong>de</strong>rstanding<br />
# what they do. They’re here only as hints or r<strong>em</strong>in<strong>de</strong>rs. If you are<br />
unsure<br />
89
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# consult the online docs. You have been warned.<br />
#<br />
# After this file is processed, the server will look for and process<br />
# /usr/local/apache/conf/srm.conf and then /usr/local/apache/conf/<br />
access.conf<br />
# unless you have overrid<strong>de</strong>n these with ResourceConfig and/or<br />
# AccessConfig directives here.<br />
#<br />
# The configuration directives are grouped into three basic sections:<br />
# 1. Directives that control the operation of the Apache server<br />
process as a<br />
# whole (the ’global environment’).<br />
# 2. Directives that <strong>de</strong>fine the parameters of the ’main’ or ’<strong>de</strong>fault<br />
’ server,<br />
# which responds to requests that aren’t handled by a virtual<br />
host.<br />
# These directives also provi<strong>de</strong> <strong>de</strong>fault values for the settings<br />
# of all virtual hosts.<br />
# 3. Settings for virtual hosts, which allow Web requests to be sent<br />
to<br />
# different IP addresses or hostnames and have th<strong>em</strong> handled by<br />
the<br />
# same Apache server process.<br />
#<br />
# Configuration and logfile names: If the filenames you specify for<br />
many<br />
# of the server’s control files begin with "/" (or "drive:/" for<br />
Win32), the<br />
# server will use that explicit path. If the filenames do *not*<br />
begin<br />
# with "/", the value of ServerRoot is prepen<strong>de</strong>d -- so "logs/foo.log"<br />
# with ServerRoot set to "/usr/local/apache" will be interpreted by<br />
the<br />
# server as "/usr/local/apache/logs/foo.log".<br />
#<br />
### Section 1: Global Environment<br />
#<br />
# The directives in this section affect the overall operation of<br />
Apache,<br />
# such as the number of concurrent requests it can handle or where it<br />
90
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# can find its configuration files.<br />
#<br />
#<br />
# ServerType is either inetd, or standalone. Inetd mo<strong>de</strong> is only<br />
supported on<br />
# Unix platforms.<br />
#<br />
ServerType standalone<br />
#<br />
# ServerRoot: The top of the directory tree un<strong>de</strong>r which the server’s<br />
# configuration, error, and log files are kept.<br />
#<br />
# NOTE! If you intend to place this on an NFS (or otherwise network)<br />
# mounted filesyst<strong>em</strong> then please read the LockFile documentation<br />
# (available at );<br />
# you will save yourself a lot of trouble.<br />
#<br />
ServerRoot "/usr/local/apache"<br />
#<br />
# The LockFile directive sets the path to the lockfile used when<br />
Apache<br />
# is compiled with either USE_FCNTL_SERIALIZED_ACCEPT or<br />
# USE_FLOCK_SERIALIZED_ACCEPT. This directive should normally be left<br />
at<br />
# its <strong>de</strong>fault value. The main reason for changing it is if the logs<br />
# directory is NFS mounted, since the lockfile MUST BE STORED ON A<br />
LOCAL<br />
# DISK. The PID of the main server process is automatically appen<strong>de</strong>d<br />
to<br />
# the filename.<br />
#<br />
#LockFile /usr/local/apache/logs/httpd.lock<br />
#<br />
# PidFile: The file in which the server should record its process<br />
# i<strong>de</strong>ntification number when it starts.<br />
#<br />
91
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
PidFile /usr/local/apache/logs/httpd.pid<br />
#<br />
# ScoreBoardFile: File used to store internal server process<br />
information.<br />
# Not all architectures require this. But if yours does (you’ll know<br />
because<br />
# this file will be created when you run Apache) then you *must*<br />
ensure that<br />
# no two invocations of Apache share the same scoreboard file.<br />
#<br />
ScoreBoardFile /usr/local/apache/logs/httpd.scoreboard<br />
#<br />
# In the standard configuration, the server will process httpd.conf (<br />
this<br />
# file, specified by the -f command line option), srm.conf, and<br />
access.conf<br />
# in that or<strong>de</strong>r. The latter two files are now distributed <strong>em</strong>pty, as<br />
it is<br />
# recommen<strong>de</strong>d that all directives be kept in a single file for<br />
simplicity.<br />
# The commented-out values below are the built-in <strong>de</strong>faults. You can<br />
have the<br />
# server ignore these files altogether by using "/<strong>de</strong>v/null" (for Unix<br />
) or<br />
# "nul" (for Win32) for the arguments to the directives.<br />
#<br />
#ResourceConfig conf/srm.conf<br />
#AccessConfig conf/access.conf<br />
#<br />
# Timeout: The number of seconds before receives and sends time out.<br />
#<br />
Timeout 300<br />
#<br />
# KeepAlive: Whether or not to allow persistent connections (more<br />
than<br />
# one request per connection). Set to "Off" to <strong>de</strong>activate.<br />
#<br />
92
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
KeepAlive On<br />
#<br />
# MaxKeepAliveRequests: The maximum number of requests to allow<br />
# during a persistent connection. Set to 0 to allow an unlimited<br />
amount.<br />
# We recommend you leave this number high, for maximum performance.<br />
#<br />
MaxKeepAliveRequests 100<br />
#<br />
# KeepAliveTimeout: Number of seconds to wait for the next request<br />
from the<br />
# same client on the same connection.<br />
#<br />
KeepAliveTimeout 15<br />
#<br />
# Server-pool size regulation. Rather than making you guess how many<br />
# server processes you need, Apache dynamically adapts to the load it<br />
# sees --- that is, it tries to maintain enough server processes to<br />
# handle the current load, plus a few spare servers to handle<br />
transient<br />
# load spikes (e.g., multiple simultaneous requests from a single<br />
# Netscape browser).<br />
#<br />
# It does this by periodically checking how many servers are waiting<br />
# for a request. If there are fewer than MinSpareServers, it creates<br />
# a new spare. If there are more than MaxSpareServers, some of the<br />
# spares die off. The <strong>de</strong>fault values are probably OK for most sites.<br />
#<br />
MinSpareServers 10<br />
MaxSpareServers 25<br />
#<br />
# Number of servers to start initially --- should be a reasonable<br />
ballpark<br />
# figure.<br />
#<br />
StartServers 10<br />
93
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
#<br />
# Limit on total number of servers running, i.e., limit on the number<br />
# of clients who can simultaneously connect --- if this limit is ever<br />
# reached, clients will be LOCKED OUT, so it should NOT BE SET TOO<br />
LOW.<br />
# It is inten<strong>de</strong>d mainly as a brake to keep a runaway server from<br />
taking<br />
# the syst<strong>em</strong> with it as it spirals down...<br />
#<br />
MaxClients 150<br />
#<br />
# MaxRequestsPerChild: the number of requests each child process is<br />
# allowed to process before the child dies. The child will exit so<br />
# as to avoid probl<strong>em</strong>s after prolonged use when Apache (and maybe the<br />
# libraries it uses) leak m<strong>em</strong>ory or other resources. On most syst<strong>em</strong>s<br />
, this<br />
# isn’t really nee<strong>de</strong>d, but a few (such as Solaris) do have notable<br />
leaks<br />
# in the libraries. For these platforms, set to something like 10000<br />
# or so; a setting of 0 means unlimited.<br />
#<br />
# NOTE: This value does not inclu<strong>de</strong> keepalive requests after the<br />
initial<br />
# request per connection. For example, if a child process<br />
handles<br />
# an initial request and 10 subsequent "keptalive" requests, it<br />
# would only count as 1 request towards this limit.<br />
#<br />
MaxRequestsPerChild 0<br />
#<br />
# Listen: Allows you to bind Apache to specific IP addresses and/or<br />
# ports, in addition to the <strong>de</strong>fault. See also the <br />
# directive.<br />
#<br />
Listen 80<br />
#Listen 12.34.56.78:80<br />
#<br />
94
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# BindAddress: You can support virtual hosts with this option. This<br />
directive<br />
# is used to tell the server which IP address to listen to. It can<br />
either<br />
# contain "*", an IP address, or a fully qualified Internet domain<br />
name.<br />
# See also the and Listen directives.<br />
#<br />
#BindAddress *<br />
#<br />
# Dynamic Shared Object (DSO) Support<br />
#<br />
# To be able to use the functionality of a module which was built as<br />
a DSO you<br />
# have to place corresponding ‘LoadModule’ lines at this location so<br />
the<br />
# directives contained in it are actually available _before_ they are<br />
used.<br />
# Please read the file README.DSO in the Apache 1.3 distribution for<br />
more<br />
# <strong>de</strong>tails about the DSO mechanism and run ‘httpd -l’ for the list of<br />
already<br />
# built-in (statically linked and thus always available) modules in<br />
your httpd<br />
# binary.<br />
#<br />
# Note: The or<strong>de</strong>r in which modules are loa<strong>de</strong>d is important. Don’t<br />
change<br />
# the or<strong>de</strong>r below without expert advice.<br />
#<br />
# Example:<br />
# LoadModule foo_module libexec/mod_foo.so<br />
#<br />
#LoadModule php4_module libexec/libphp4.so<br />
#<br />
# Exten<strong>de</strong>dStatus controls whether Apache will generate "full" status<br />
# information (Exten<strong>de</strong>dStatus On) or just basic information (<br />
Exten<strong>de</strong>dStatus<br />
95
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# Off) when the "server-status" handler is called. The <strong>de</strong>fault is Off<br />
#<br />
.<br />
#Exten<strong>de</strong>dStatus On<br />
### Section 2: ’Main’ server configuration<br />
#<br />
# The directives in this section set up the values used by the ’main’<br />
# server, which responds to any requests that aren’t handled by a<br />
# <strong>de</strong>finition. These values also provi<strong>de</strong> <strong>de</strong>faults for<br />
# any containers you may <strong>de</strong>fine later in the file.<br />
#<br />
# All of these directives may appear insi<strong>de</strong> containers,<br />
# in which case these <strong>de</strong>fault settings will be overrid<strong>de</strong>n for the<br />
# virtual host being <strong>de</strong>fined.<br />
#<br />
#<br />
# If your ServerType directive (set earlier in the ’Global<br />
Environment’<br />
# section) is set to "inetd", the next few directives don’t have any<br />
# effect since their settings are <strong>de</strong>fined by the inetd configuration.<br />
# Skip ahead to the ServerAdmin directive.<br />
#<br />
#<br />
# Port: The port to which the standalone server listens. For<br />
# ports < 1023, you will need httpd to be run as root initially.<br />
#<br />
Port 80<br />
## SSL Support<br />
##<br />
## When we also provi<strong>de</strong> SSL we have to listen to the<br />
## standard HTTP port (see above) and to the HTTPS port<br />
##<br />
<br />
Listen 443<br />
<br />
96
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
#<br />
# If you wish httpd to run as a different user or group, you must run<br />
# httpd as root initially and it will switch.<br />
#<br />
# User/Group: The name (or #number) of the user/group to run httpd as<br />
.<br />
# . On SCO (ODT 3) use "User nouser" and "Group nogroup".<br />
# . On HPUX you may not be able to use shared m<strong>em</strong>ory as nobody, and<br />
the<br />
# suggested workaround is to create a user www and use that user.<br />
# NOTE that some kernels refuse to setgid(Group) or s<strong>em</strong>ctl(IPC_SET)<br />
# when the value of (unsigned)Group is above 60000;<br />
# don’t use Group nobody on these syst<strong>em</strong>s!<br />
#<br />
User apache<br />
Group apache<br />
#<br />
# ServerAdmin: Your address, where probl<strong>em</strong>s with the server should be<br />
# e-mailed. This address appears on some server-generated pages,<br />
such<br />
# as error documents.<br />
#<br />
ServerAdmin webmaster@here.com<br />
#<br />
# ServerName allows you to set a host name which is sent back to<br />
clients for<br />
# your server if it’s different than the one the program would get (i<br />
.e., use<br />
# "www" instead of the host’s real name).<br />
#<br />
# Note: You cannot just invent host names and hope they work. The<br />
name you<br />
# <strong>de</strong>fine here must be a valid DNS name for your host. If you don’t<br />
un<strong>de</strong>rstand<br />
# this, ask your network administrator.<br />
# If your host doesn’t have a registered DNS name, enter its IP<br />
address here.<br />
# You will have to access it by its address (e.g., http<br />
://123.45.67.89/)<br />
97
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# anyway, and this will make redirections work in a sensible way.<br />
#<br />
# 127.0.0.1 is the TCP/IP local loop-back address, often named<br />
localhost. Your<br />
# machine always knows itself by this address. If you use Apache<br />
strictly for<br />
# local testing and <strong>de</strong>velopment, you may use 127.0.0.1 as the server<br />
#<br />
name.<br />
ServerName www.here.com<br />
#<br />
# DocumentRoot: The directory out of which you will serve your<br />
# documents. By <strong>de</strong>fault, all requests are taken from this directory,<br />
but<br />
# symbolic links and aliases may be used to point to other locations.<br />
#<br />
DocumentRoot "/var/www/html"<br />
#<br />
# Each directory to which Apache has access, can be configured with<br />
respect<br />
# to which services and features are allowed and/or disabled in that<br />
# directory (and its subdirectories).<br />
#<br />
# First, we configure the "<strong>de</strong>fault" to be a very restrictive set of<br />
# permissions.<br />
#<br />
<br />
Options FollowSymLinks<br />
AllowOverri<strong>de</strong> None<br />
<br />
#<br />
# Note that from this point forward you must specifically allow<br />
# particular features to be enabled - so if something’s not working<br />
as<br />
# you might expect, make sure that you have specifically enabled it<br />
# below.<br />
#<br />
98
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
#<br />
# This should be changed to whatever you set DocumentRoot to.<br />
#<br />
<br />
#<br />
# This may also be "None", "All", or any combination of "In<strong>de</strong>xes",<br />
# "Inclu<strong>de</strong>s", "FollowSymLinks", "ExecCGI", or "MultiViews".<br />
#<br />
# Note that "MultiViews" must be named *explicitly* --- "Options All"<br />
# doesn’t give it to you.<br />
#<br />
#<br />
Options Inclu<strong>de</strong>s FollowSymLinks MultiViews<br />
# This controls which options the .htaccess files in directories can<br />
# overri<strong>de</strong>. Can also be "All", or any combination of "Options", "<br />
FileInfo",<br />
# "AuthConfig", and "Limit"<br />
#<br />
#<br />
AllowOverri<strong>de</strong> All<br />
# Controls who can get stuff from this server.<br />
#<br />
Or<strong>de</strong>r allow,<strong>de</strong>ny<br />
Allow from all<br />
<br />
#<br />
# UserDir: The name of the directory which is appen<strong>de</strong>d onto a user’s<br />
home<br />
# directory if a ˜user request is received.<br />
#<br />
<br />
UserDir public_html<br />
<br />
#<br />
# Control access to UserDir directories. The following is an example<br />
# for a site where these directories are restricted to read-only.<br />
99
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
#<br />
<br />
AllowOverri<strong>de</strong> All<br />
Options MultiViews In<strong>de</strong>xes SymLinksIfOwnerMatch Inclu<strong>de</strong>sNoExec<br />
# <br />
# Or<strong>de</strong>r allow,<strong>de</strong>ny<br />
# Allow from all<br />
# <br />
# <br />
# Or<strong>de</strong>r <strong>de</strong>ny,allow<br />
# Deny from all<br />
# <br />
<br />
#<br />
# DirectoryIn<strong>de</strong>x: Name of the file or files to use as a pre-written<br />
HTML<br />
# directory in<strong>de</strong>x. Separate multiple entries with spaces.<br />
#<br />
<br />
DirectoryIn<strong>de</strong>x in<strong>de</strong>x.html in<strong>de</strong>x.htm in<strong>de</strong>x.shtml <strong>de</strong>fault.htm<br />
<br />
#<br />
<strong>de</strong>fault.html in<strong>de</strong>x.php<br />
# AccessFileName: The name of the file to look for in each directory<br />
# for access control information.<br />
#<br />
AccessFileName .htaccess<br />
#<br />
# The following lines prevent .htaccess files from being viewed by<br />
# Web clients. Since .htaccess files often contain authorization<br />
# information, access is disallowed for security reasons. Comment<br />
# these lines out if you want Web visitors to see the contents of<br />
# .htaccess files. If you change the AccessFileName directive above,<br />
# be sure to make the corresponding changes here.<br />
#<br />
# Also, folks tend to use names such as .htpasswd for password<br />
100
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# files, so this will protect those as well.<br />
#<br />
<br />
<br />
#<br />
Or<strong>de</strong>r allow,<strong>de</strong>ny<br />
Deny from all<br />
# CacheNegotiatedDocs: By <strong>de</strong>fault, Apache sends "Pragma: no-cache"<br />
with each<br />
# document that was negotiated on the basis of content. This asks<br />
proxy<br />
# servers not to cache the document. Uncommenting the following line<br />
disables<br />
# this behavior, and proxies will be allowed to cache the documents.<br />
#<br />
#CacheNegotiatedDocs<br />
#<br />
# UseCanonicalName: (new for 1.3) With this setting turned on,<br />
whenever<br />
# Apache needs to construct a self-referencing URL (a URL that refers<br />
back<br />
# to the server the response is coming from) it will use ServerName<br />
and<br />
# Port to form a "canonical" name. With this setting off, Apache<br />
will<br />
# use the hostname:port that the client supplied, when possible.<br />
This<br />
# also affects SERVER_NAME and SERVER_PORT in CGI scripts.<br />
#<br />
UseCanonicalName On<br />
#<br />
# TypesConfig <strong>de</strong>scribes where the mime.types file (or equivalent) is<br />
# to be found.<br />
#<br />
<br />
TypesConfig /usr/local/apache/conf/mime.types<br />
<br />
101
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
#<br />
# DefaultType is the <strong>de</strong>fault MIME type the server will use for a<br />
document<br />
# if it cannot otherwise <strong>de</strong>termine one, such as from filename<br />
extensions.<br />
# If your server contains mostly text or HTML documents, "text/plain"<br />
is<br />
# a good value. If most of your content is binary, such as<br />
applications<br />
# or images, you may want to use "application/octet-stream" instead<br />
to<br />
# keep browsers from trying to display binary files as though they<br />
are<br />
# text.<br />
#<br />
DefaultType text/plain<br />
#<br />
# The mod_mime_magic module allows the server to use various hints<br />
from the<br />
# contents of the file itself to <strong>de</strong>termine its type. The<br />
MIMEMagicFile<br />
# directive tells the module where the hint <strong>de</strong>finitions are located.<br />
# mod_mime_magic is not part of the <strong>de</strong>fault server (you have to add<br />
# it yourself with a LoadModule [see the DSO paragraph in the ’Global<br />
# Environment’ section], or recompile the server and inclu<strong>de</strong><br />
mod_mime_magic<br />
# as part of the configuration), so it’s enclosed in an <br />
container.<br />
# This means that the MIMEMagicFile directive will only be processed<br />
if the<br />
# module is part of the server.<br />
#<br />
<br />
MIMEMagicFile /usr/local/apache/conf/magic<br />
<br />
#<br />
# HostnameLookups: Log the names of clients or just their IP<br />
addresses<br />
# e.g., www.apache.org (on) or 204.62.129.132 (off).<br />
102
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# The <strong>de</strong>fault is off because it’d be overall better for the net if<br />
people<br />
# had to knowingly turn this feature on, since enabling it means that<br />
# each client request will result in AT LEAST one lookup request to<br />
the<br />
# nameserver.<br />
#<br />
HostnameLookups Off<br />
#<br />
# ErrorLog: The location of the error log file.<br />
# If you do not specify an ErrorLog directive within a <br />
# container, error messages relating to that virtual host will be<br />
# logged here. If you *do* <strong>de</strong>fine an error logfile for a <<br />
VirtualHost><br />
# container, that host’s errors will be logged there and not here.<br />
#<br />
ErrorLog /usr/local/apache/logs/error_log<br />
#<br />
# LogLevel: Control the number of messages logged to the error_log.<br />
# Possible values inclu<strong>de</strong>: <strong>de</strong>bug, info, notice, warn, error, crit,<br />
# alert, <strong>em</strong>erg.<br />
#<br />
LogLevel warn<br />
#<br />
# The following directives <strong>de</strong>fine some format nicknames for use with<br />
# a CustomLog directive (see below).<br />
#<br />
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i<br />
\"" combined<br />
LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
LogFormat "%{Referer}i -> %U" referer<br />
LogFormat "%{User-agent}i" agent<br />
#<br />
# The location and format of the access logfile (Common Logfile<br />
Format).<br />
# If you do not <strong>de</strong>fine any access logfiles within a <br />
103
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# container, they will be logged here. Contrariwise, if you *do*<br />
# <strong>de</strong>fine per- access logfiles, transactions will be<br />
# logged therein and *not* in this file.<br />
#<br />
CustomLog /usr/local/apache/logs/access_log common<br />
#<br />
# If you would like to have agent and referer logfiles, uncomment the<br />
# following directives.<br />
#<br />
#CustomLog /usr/local/apache/logs/referer_log referer<br />
#CustomLog /usr/local/apache/logs/agent_log agent<br />
#<br />
# If you prefer a single logfile with access, agent, and referer<br />
information<br />
# (Combined Logfile Format) you can use the following directive.<br />
#<br />
#CustomLog /usr/local/apache/logs/access_log combined<br />
#<br />
# Optionally add a line containing the server version and virtual<br />
host<br />
# name to server-generated pages (error documents, FTP directory<br />
listings,<br />
# mod_status and mod_info output etc., but not CGI generated<br />
documents).<br />
# Set to "EMail" to also inclu<strong>de</strong> a mailto: link to the ServerAdmin.<br />
# Set to one of: On | Off | EMail<br />
#<br />
ServerSignature On<br />
#This directive controls whether Server response hea<strong>de</strong>r field which<br />
is<br />
#sent back to clients inclu<strong>de</strong>s a <strong>de</strong>scription of the generic OS-type<br />
of the<br />
#server as well as information about compiled-in modules.<br />
#ServerTokens Prod[uctOnly] only available in versions later than<br />
1.3.12<br />
104
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# Server sends (e.g.): Server: Apache<br />
#ServerTokens Min[imal]<br />
# Server sends (e.g.): Server: Apache/1.3.0<br />
#ServerTokens OS<br />
# Server sends (e.g.): Server: Apache/1.3.0 (Unix)<br />
#ServerTokens Full (or not specified)<br />
# Server sends (e.g.): Server: Apache/1.3.0 (Unix) PHP/3.0 MyMod<br />
/1.2<br />
ServerTokens Prod<br />
# EBCDIC configuration:<br />
# (only for mainframes using the EBCDIC co<strong>de</strong>set, currently one of:<br />
# Fujitsu-Si<strong>em</strong>ens’ BS2000/OSD, IBM’s OS/390 and IBM’s TPF)!!<br />
# The following <strong>de</strong>fault configuration assumes that "text files"<br />
# are stored in EBCDIC (so that you can operate on th<strong>em</strong> using the<br />
# normal POSIX tools like grep and sort) while "binary files" are<br />
# stored with i<strong>de</strong>ntical octets as on an ASCII machine.<br />
#<br />
# The directives are evaluated in configuration file or<strong>de</strong>r, with<br />
# the EBCDICConvert directives applied before EBCDICConvertByType.<br />
#<br />
# If you want to have ASCII HTML documents and EBCDIC HTML documents<br />
# at the same time, you can use the file extension to force<br />
# conversion off for the ASCII documents:<br />
# > AddType text/html .ahtml<br />
# > EBCDICConvert Off=InOut .ahtml<br />
#<br />
# EBCDICConvertByType On=InOut text/* message/* multipart/*<br />
# EBCDICConvertByType On=In application/x-www-form-urlenco<strong>de</strong>d<br />
# EBCDICConvertByType On=InOut application/postscript mo<strong>de</strong>l/vrml<br />
# EBCDICConvertByType Off=InOut */*<br />
#<br />
# Aliases: Add here as many aliases as you need (with no limit). The<br />
format is<br />
# Alias fakename realname<br />
#<br />
<br />
#<br />
105
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# Note that if you inclu<strong>de</strong> a trailing / on fakename then the<br />
server will<br />
# require it to be present in the URL. So "/icons" isn’t aliased<br />
in this<br />
# example, only "/icons/". If the fakename is slash-terminated,<br />
then the<br />
# realname must also be slash terminated, and if the fakename<br />
omits the<br />
# trailing slash, the realname must also omit it.<br />
#<br />
Alias /icons/ "/usr/local/apache/icons/"<br />
Alias /icons/ "/var/www/icons/"<br />
<br />
Options In<strong>de</strong>xes MultiViews<br />
AllowOverri<strong>de</strong> None<br />
Or<strong>de</strong>r allow,<strong>de</strong>ny<br />
Allow from all<br />
<br />
#<br />
# ScriptAlias: This controls which directories contain server<br />
scripts.<br />
# ScriptAliases are essentially the same as Aliases, except that<br />
# documents in the realname directory are treated as applications<br />
and<br />
# run by the server when requested rather than as documents sent<br />
to the client.<br />
# The same rules about trailing "/" apply to ScriptAlias<br />
directives as to<br />
# Alias.<br />
#<br />
# ScriptAlias /cgi-bin/ "/usr/local/apache/cgi-bin/"<br />
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"<br />
#<br />
# "/var/www/cgi-bin" should be changed to whatever your ScriptAliased<br />
# CGI directory exists, if you have that configured.<br />
#<br />
106
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
<br />
AllowOverri<strong>de</strong> None<br />
Options ExecCGI<br />
Or<strong>de</strong>r allow,<strong>de</strong>ny<br />
Allow from all<br />
<br />
#<br />
# "/usr/local/apache/cgi-bin" should be changed to whatever your<br />
ScriptAliased<br />
# CGI directory exists, if you have that configured.<br />
#<br />
# <br />
# AllowOverri<strong>de</strong> None<br />
# Options None<br />
# Or<strong>de</strong>r allow,<strong>de</strong>ny<br />
# Allow from all<br />
# <br />
<br />
# End of aliases.<br />
#<br />
# Redirect allows you to tell clients about documents which used to<br />
exist in<br />
# your server’s namespace, but do not anymore. This allows you to<br />
tell the<br />
# clients where to look for the relocated document.<br />
# Format: Redirect old-URI new-URL<br />
#<br />
#<br />
# Directives controlling the display of server-generated directory<br />
#<br />
listings.<br />
<br />
#<br />
# FancyIn<strong>de</strong>xing is whether you want fancy directory in<strong>de</strong>xing or<br />
#<br />
standard<br />
107
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
In<strong>de</strong>xOptions FancyIn<strong>de</strong>xing<br />
#<br />
# AddIcon* directives tell the server which icon to show for<br />
different<br />
# files or filename extensions. These are only displayed for<br />
# FancyIn<strong>de</strong>xed directories.<br />
#<br />
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip<br />
AddIconByType (TXT,/icons/text.gif) text/*<br />
AddIconByType (IMG,/icons/image2.gif) image/*<br />
AddIconByType (SND,/icons/sound2.gif) audio/*<br />
AddIconByType (VID,/icons/movie.gif) vi<strong>de</strong>o/*<br />
AddIcon /icons/binary.gif .bin .exe<br />
AddIcon /icons/binhex.gif .hqx<br />
AddIcon /icons/tar.gif .tar<br />
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv<br />
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip<br />
AddIcon /icons/a.gif .ps .ai .eps<br />
AddIcon /icons/layout.gif .html .shtml .htm .pdf<br />
AddIcon /icons/text.gif .txt<br />
AddIcon /icons/c.gif .c<br />
AddIcon /icons/p.gif .pl .py<br />
AddIcon /icons/f.gif .for<br />
AddIcon /icons/dvi.gif .dvi<br />
AddIcon /icons/uuenco<strong>de</strong>d.gif .uu<br />
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl<br />
AddIcon /icons/tex.gif .tex<br />
AddIcon /icons/bomb.gif core<br />
AddIcon /icons/back.gif ..<br />
AddIcon /icons/hand.right.gif README<br />
AddIcon /icons/fol<strong>de</strong>r.gif ˆˆDIRECTORYˆˆ<br />
AddIcon /icons/blank.gif ˆˆBLANKICONˆˆ<br />
#<br />
# DefaultIcon is which icon to show for files which do not have<br />
an icon<br />
# explicitly set.<br />
108
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
#<br />
DefaultIcon /icons/unknown.gif<br />
#<br />
# AddDescription allows you to place a short <strong>de</strong>scription after a<br />
file in<br />
# server-generated in<strong>de</strong>xes. These are only displayed for<br />
FancyIn<strong>de</strong>xed<br />
# directories.<br />
# Format: AddDescription "<strong>de</strong>scription" filename<br />
#<br />
#AddDescription "GZIP compressed document" .gz<br />
#AddDescription "tar archive" .tar<br />
#AddDescription "GZIP compressed tar archive" .tgz<br />
#<br />
# ReadmeName is the name of the README file the server will look<br />
for by<br />
# <strong>de</strong>fault, and append to directory listings.<br />
#<br />
# Hea<strong>de</strong>rName is the name of a file which should be prepen<strong>de</strong>d to<br />
# directory in<strong>de</strong>xes.<br />
#<br />
# If MultiViews are amongst the Options in effect, the server<br />
will<br />
# first look for name.html and inclu<strong>de</strong> it if found. If name.html<br />
# doesn’t exist, the server will then look for name.txt and<br />
inclu<strong>de</strong><br />
# it as plaintext if found.<br />
#<br />
ReadmeName README<br />
Hea<strong>de</strong>rName HEADER<br />
#<br />
# In<strong>de</strong>xIgnore is a set of filenames which directory in<strong>de</strong>xing<br />
should ignore<br />
# and not inclu<strong>de</strong> in the listing. Shell-style wildcarding is<br />
#<br />
permitted.<br />
In<strong>de</strong>xIgnore .??* *˜ *# HEADER* README* RCS CVS *,v *,t<br />
109
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
<br />
# End of in<strong>de</strong>xing directives.<br />
#<br />
# Document types.<br />
#<br />
<br />
#<br />
# AddEncoding allows you to have certain browsers (Mosaic/X 2.1+)<br />
uncompress<br />
# information on the fly. Note: Not all browsers support this.<br />
# Despite the name similarity, the following Add* directives have<br />
nothing<br />
# to do with the FancyIn<strong>de</strong>xing customization directives above.<br />
#<br />
AddEncoding x-compress Z<br />
AddEncoding x-gzip gz tgz<br />
#<br />
# AddLanguage allows you to specify the language of a document.<br />
You can<br />
# then use content negotiation to give a browser a file in a<br />
language<br />
# it can un<strong>de</strong>rstand.<br />
#<br />
# Note 1: The suffix does not have to be the same as the language<br />
# keyword --- those with documents in Polish (whose net-standard<br />
# language co<strong>de</strong> is pl) may wish to use "AddLanguage pl .po" to<br />
# avoid the ambiguity with the common suffix for perl scripts.<br />
#<br />
# Note 2: The example entries below illustrate that in quite<br />
# some cases the two character ’Language’ abbreviation is not<br />
# i<strong>de</strong>ntical to the two character ’Country’ co<strong>de</strong> for its country,<br />
# E.g. ’Danmark/dk’ versus ’Danish/da’.<br />
#<br />
# Note 3: In the case of ’ltz’ we violate the RFC by using a<br />
three char<br />
# specifier. But there is ’work in progress’ to fix this and get<br />
# the reference data for rfc1766 cleaned up.<br />
110
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
#<br />
# Danish (da) - Dutch (nl) - English (en) - Estonian (ee)<br />
# French (fr) - German (<strong>de</strong>) - Greek-Mo<strong>de</strong>rn (el)<br />
# Italian (it) - Korean (kr) - Norwegian (no)<br />
# Portugese (pt) - Lux<strong>em</strong>bourgeois* (ltz)<br />
# Spanish (es) - Swedish (sv) - Catalan (ca) - Czech(cz)<br />
# Polish (pl) - Brazilian Portuguese (pt-br) - Japanese (ja)<br />
# Russian (ru)<br />
#<br />
AddLanguage da .dk<br />
AddLanguage nl .nl<br />
AddLanguage en .en<br />
AddLanguage et .ee<br />
AddLanguage fr .fr<br />
AddLanguage <strong>de</strong> .<strong>de</strong><br />
AddLanguage el .el<br />
AddLanguage he .he<br />
AddCharset ISO-8859-8 .iso8859-8<br />
AddLanguage it .it<br />
AddLanguage ja .ja<br />
AddCharset ISO-2022-JP .jis<br />
AddLanguage kr .kr<br />
AddCharset ISO-2022-KR .iso-kr<br />
AddLanguage no .no<br />
AddLanguage pl .po<br />
AddCharset ISO-8859-2 .iso-pl<br />
AddLanguage pt .pt<br />
AddLanguage pt-br .pt-br<br />
AddLanguage ltz .lu<br />
AddLanguage ca .ca<br />
AddLanguage es .es<br />
AddLanguage sv .se<br />
AddLanguage cz .cz<br />
AddLanguage ru .ru<br />
AddLanguage zh-tw .tw<br />
AddLanguage tw .tw<br />
AddCharset Big5 .Big5 .big5<br />
AddCharset WINDOWS-1251 .cp-1251<br />
AddCharset CP866 .cp866<br />
AddCharset ISO-8859-5 .iso-ru<br />
AddCharset KOI8-R .koi8-r<br />
111
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
AddCharset UCS-2 .ucs2<br />
AddCharset UCS-4 .ucs4<br />
AddCharset UTF-8 .utf8<br />
# LanguagePriority allows you to give prece<strong>de</strong>nce to some<br />
languages<br />
# in case of a tie during content negotiation.<br />
#<br />
# Just list the languages in <strong>de</strong>creasing or<strong>de</strong>r of preference. We<br />
have<br />
# more or less alphabetized th<strong>em</strong> here. You probably want to<br />
#<br />
change this.<br />
<br />
LanguagePriority en da nl et fr <strong>de</strong> el it ja kr no pl pt pt-br<br />
<br />
#<br />
ru ltz ca es sv tw<br />
# AddType allows you to tweak mime.types without actually editing<br />
it, or to<br />
# make certain files to be certain types.<br />
#<br />
# For example, the PHP 3.x module (not part of the Apache<br />
#<br />
distribution - see # http://www.php.net) will typically use<br />
:<br />
#AddType application/x-httpd-php3 .php3<br />
#AddType application/x-httpd-php3-source .phps<br />
#<br />
# And for PHP 4.x, use:<br />
#<br />
AddType application/x-httpd-php .php<br />
#AddType application/x-httpd-php-source .phps<br />
AddType application/x-tar .tgz<br />
AddType application/x-ica .ica<br />
#<br />
# AddHandler allows you to map certain file extensions to "<br />
handlers",<br />
112
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# actions unrelated to filetype. These can be either built into<br />
the server<br />
# or ad<strong>de</strong>d with the Action command (see below)<br />
#<br />
# If you want to use server si<strong>de</strong> inclu<strong>de</strong>s, or CGI outsi<strong>de</strong><br />
# ScriptAliased directories, uncomment the following lines.<br />
#<br />
# To use CGI scripts:<br />
#<br />
#AddHandler cgi-script .cgi<br />
#<br />
# To use server-parsed HTML files<br />
#<br />
AddType text/html .shtml<br />
AddHandler server-parsed .shtml<br />
#<br />
# Uncomment the following line to enable Apache’s send-asis HTTP<br />
file<br />
# feature<br />
#<br />
#AddHandler send-as-is asis<br />
#<br />
# If you wish to use server-parsed imag<strong>em</strong>ap files, use<br />
#<br />
AddHandler imap-file map<br />
#<br />
# To enable type maps, you might want to use<br />
#<br />
#AddHandler type-map var<br />
<br />
# End of document types.<br />
#<br />
# Action lets you <strong>de</strong>fine media types that will execute a script<br />
whenever<br />
113
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# a matching file is called. This eliminates the need for repeated<br />
URL<br />
# pathnames for oft-used CGI file processors.<br />
# Format: Action media/type /cgi-script/location<br />
# Format: Action handler-name /cgi-script/location<br />
#<br />
#<br />
# MetaDir: specifies the name of the directory in which Apache can<br />
find<br />
# meta information files. These files contain additional HTTP hea<strong>de</strong>rs<br />
# to inclu<strong>de</strong> when sending the document<br />
#<br />
#MetaDir .web<br />
#<br />
# MetaSuffix: specifies the file name suffix for the file containing<br />
the<br />
# meta information.<br />
#<br />
#MetaSuffix .meta<br />
#<br />
# Customizable error response (Apache style)<br />
# these come in three flavors<br />
#<br />
# 1) plain text<br />
#ErrorDocument 500 "The server ma<strong>de</strong> a boo boo.<br />
# n.b. the single leading (") marks it as text, it does not get<br />
#<br />
output<br />
# 2) local redirects<br />
#ErrorDocument 404 /missing.html<br />
# to redirect to local URL /missing.html<br />
#ErrorDocument 404 /cgi-bin/missing_handler.pl<br />
# N.B.: You can redirect to a script or a document using server-si<strong>de</strong><br />
#<br />
-inclu<strong>de</strong>s.<br />
# 3) external redirects<br />
#ErrorDocument 402 http://some.other_server.com/subscription_info.<br />
html<br />
114
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# N.B.: Many of the environment variables associated with the<br />
original<br />
# request will *not* be available to such a script.<br />
#<br />
# Customize behaviour based on the browser<br />
#<br />
<br />
#<br />
# The following directives modify normal HTTP response behavior.<br />
# The first directive disables keepalive for Netscape 2.x and<br />
browsers that<br />
# spoof it. There are known probl<strong>em</strong>s with these browser<br />
impl<strong>em</strong>entations.<br />
# The second directive is for Microsoft Internet Explorer 4.0b2<br />
# which has a broken HTTP/1.1 impl<strong>em</strong>entation and does not<br />
properly<br />
# support keepalive when it is used on 301 or 302 (redirect)<br />
#<br />
responses.<br />
BrowserMatch "Mozilla/2" nokeepalive<br />
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgra<strong>de</strong>-1.0 force-<br />
#<br />
response-1.0<br />
# The following directive disables HTTP/1.1 responses to browsers<br />
which<br />
# are in violation of the HTTP/1.0 spec by not being able to grok<br />
a<br />
# basic 1.1 response.<br />
#<br />
BrowserMatch "RealPlayer 4\.0" force-response-1.0<br />
BrowserMatch "Java/1\.0" force-response-1.0<br />
BrowserMatch "JDK/1\.0" force-response-1.0<br />
<br />
# End of browser customization directives<br />
#<br />
115
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# Allow server status reports, with the URL of http://servername/<br />
server-status<br />
# Change the ".your_domain.com" to match your domain to enable.<br />
#<br />
#<br />
# SetHandler server-status<br />
# Or<strong>de</strong>r <strong>de</strong>ny,allow<br />
# Deny from all<br />
# Allow from .your_domain.com<br />
#<br />
#<br />
# Allow r<strong>em</strong>ote server configuration reports, with the URL of<br />
# http://servername/server-info (requires that mod_info.c be loa<strong>de</strong>d).<br />
# Change the ".your_domain.com" to match your domain to enable.<br />
#<br />
#<br />
# SetHandler server-info<br />
# Or<strong>de</strong>r <strong>de</strong>ny,allow<br />
# Deny from all<br />
# Allow from .your_domain.com<br />
#<br />
#<br />
# There have been reports of people trying to abuse an old bug from<br />
pre-1.1<br />
# days. This bug involved a CGI script distributed as a part of<br />
Apache.<br />
# By uncommenting these lines you can redirect these attacks to a<br />
logging<br />
# script on phf.apache.org. Or, you can record th<strong>em</strong> yourself, using<br />
the script<br />
# support/phf_abuse_log.cgi.<br />
#<br />
#<br />
# Deny from all<br />
# ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi<br />
#<br />
#<br />
# Proxy Server directives. Uncomment the following lines to<br />
116
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# enable the proxy server:<br />
#<br />
#<br />
# ProxyRequests On<br />
# <br />
# Or<strong>de</strong>r <strong>de</strong>ny,allow<br />
# Deny from all<br />
# Allow from .your_domain.com<br />
# <br />
#<br />
# Enable/disable the handling of HTTP/1.1 "Via:" hea<strong>de</strong>rs.<br />
# ("Full" adds the server version; "Block" r<strong>em</strong>oves all outgoing<br />
Via: hea<strong>de</strong>rs)<br />
# Set to one of: Off | On | Full | Block<br />
#<br />
# ProxyVia On<br />
#<br />
# To enable the cache as well, edit and uncomment the following<br />
lines:<br />
# (no cacheing without CacheRoot)<br />
#<br />
# CacheRoot "/usr/local/apache/proxy"<br />
# CacheSize 5<br />
# CacheGcInterval 4<br />
# CacheMaxExpire 24<br />
# CacheLastModifiedFactor 0.1<br />
# CacheDefaultExpire 1<br />
# NoCache a_domain.com another_domain.edu joes.garage_sale.com<br />
#<br />
# End of proxy directives.<br />
### Section 3: Virtual Hosts<br />
#<br />
# VirtualHost: If you want to maintain multiple domains/hostnames on<br />
your<br />
117
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
# machine you can setup VirtualHost containers for th<strong>em</strong>. Most<br />
configurations<br />
# use only name-based virtual hosts so the server doesn’t need to<br />
worry about<br />
# IP addresses. This is indicated by the asterisks in the directives<br />
#<br />
below.<br />
# Please see the documentation at <br />
# for further <strong>de</strong>tails before you try to setup virtual hosts.<br />
#<br />
# You may use the command line option ’-S’ to verify your virtual<br />
host<br />
# configuration.<br />
#<br />
# Use name-based virtual hosting.<br />
#<br />
#NameVirtualHost *<br />
NameVirtualHost 192.168.0.100:80<br />
#<br />
# VirtualHost example:<br />
# Almost any Apache directive may go into a VirtualHost container.<br />
# The first VirtualHost section is used for requests without a known<br />
# server name.<br />
#<br />
#<br />
# ServerAdmin webmaster@dummy-host.example.com<br />
# DocumentRoot /www/docs/dummy-host.example.com<br />
# ServerName dummy-host.example.com<br />
# ErrorLog logs/dummy-host.example.com-error_log<br />
# CustomLog logs/dummy-host.example.com-access_log common<br />
#<br />
<br />
ServerAdmin webmaster@domain1.com<br />
DocumentRoot /var/www/html/domain1.com<br />
ServerName www.domain1.com<br />
118
B. APPENDIX - EVALUATION B.2. Apache Configuration File<br />
ErrorLog /var/log/httpd/domain1.com-error_log<br />
CustomLog /var/log/httpd/domain1.com-access_log combined<br />
<br />
<br />
##<br />
## SSL Virtual Host Context<br />
##<br />
<br />
ServerAdmin webmaster@domain1.com<br />
DocumentRoot /var/www/html/domain1.com<br />
ServerName www.domain1.com<br />
ErrorLog /var/log/httpd/domain1.com-error_log<br />
CustomLog /var/log/httpd/domain1.com-access_log combined<br />
SSLEngine on<br />
#next line is a fix for page not found error with php<br />
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown<br />
downgra<strong>de</strong>-1.0 force-response-1.0<br />
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+<br />
SSLv2:+EXP:+eNULL<br />
SSLCertificateFile /usr/local/apache/conf/ssl.crt/www.domain1.com<br />
.crt<br />
SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/www.domain1.<br />
com.key<br />
<br />
<br />
<br />
ServerAdmin webmaster@domain2.com<br />
DocumentRoot /var/www/html/domain2.com/<br />
ServerName domain2.com<br />
ServerAlias www.domain2.com domain2-variant.com www.domain2-<br />
variant.com<br />
ErrorLog /var/log/httpd/domain2.com-access_log combined<br />
CustomLog /var/log/httpd/domain2.com-access_log combined<br />
<br />
119
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
B.3 Eclipse Configuration File<br />
<br />
<br />
<br />
blabla<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
120
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
121
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
122
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
linktypehierarchytoeditor="0"/><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
124
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
125
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
126
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
127
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />




<br />
<br />
<br />
<br />

<br />
128
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
<br />
<br />
<br />


<br />
<br />
<br />
<br />
<br />


<br />
<br />
<br />
<br />
<br />
<br />

<br />
<br />
<br />
<br />
<br />
<br />


B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
activePageID="org.eclipse.ui.views.ContentOutline" expan<strong>de</strong>d="2"<br />
appearance="2">
<br />
<br />

<br />
<br />
<br />
<br />
&#<br />
x0A;
<br />
<br />
<br />
<br />

<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
130
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />


<<br />
fol<strong>de</strong>r activePageID="org.tigris.subversion.subclipse.ui.repository<br />
.RepositoriesView" expan<strong>de</strong>d="2" appearance="2">
<br />
<br />

<br />
<br />
<br />
<br />
<br />
131
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />


<br />
<br />
<br />
<br />
<br />
<br />


<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
no<strong>de</strong>/Switchable.java"/><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
133
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
134
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
135
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
136
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
137
B. APPENDIX - EVALUATION B.3. Eclipse Configuration File<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
138
B. APPENDIX - EVALUATION B.4. Performance Validation File 1<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
B.4 Performance Validation File 1<br />
# PostgreSQL I<strong>de</strong>nt Authentication Maps<br />
# ====================================<br />
#<br />
# Refer to the PostgreSQL Administrator’s Gui<strong>de</strong>, chapter "Client<br />
# Authentication" for a complete <strong>de</strong>scription. A short synopsis<br />
# follows.<br />
#<br />
# This file controls PostgreSQL i<strong>de</strong>nt-based authentication. It maps<br />
# i<strong>de</strong>nt user names (typically Unix user names) to their corresponding<br />
# PostgreSQL user names. Records are of the form:<br />
#<br />
# MAPNAME IDENT-USERNAME PG-USERNAME<br />
#<br />
# (The uppercase quantities must be replaced by actual values.)<br />
#<br />
139
B. APPENDIX - EVALUATION B.5. Performance Validation File 2<br />
# MAPNAME is the (otherwise freely chosen) map name that was used in<br />
# pg_hba.conf. IDENT-USERNAME is the <strong>de</strong>tected user name of the<br />
# client. PG-USERNAME is the requested PostgreSQL user name. The<br />
# existence of a record specifies that IDENT-USERNAME may connect as<br />
# PG-USERNAME. Multiple maps may be specified in this file and used<br />
# by pg_hba.conf.<br />
#<br />
# This file is read on server startup and when the postmaster<br />
receives<br />
# a SIGHUP signal. If you edit the file on a running syst<strong>em</strong>, you<br />
have<br />
# to SIGHUP the postmaster for the changes to take effect. You can<br />
use<br />
# "pg_ctl reload" to do that.<br />
# Put your actual configuration here<br />
# ----------------------------------<br />
#<br />
# No map names are <strong>de</strong>fined in the <strong>de</strong>fault configuration. If all<br />
i<strong>de</strong>nt<br />
# user names and PostgreSQL user names are the same, you don’t need<br />
# this file. Instead, use the special map name "sameuser" in<br />
# pg_hba.conf.<br />
# MAPNAME IDENT-USERNAME PG-USERNAME<br />
B.5 Performance Validation File 2<br />
# PostgreSQL Client Authentication Configuration File<br />
# ===================================================<br />
#<br />
# Refer to the "Client Authentication" section in the<br />
# PostgreSQL documentation for a complete <strong>de</strong>scription<br />
# of this file. A short synopsis follows.<br />
#<br />
# This file controls: which hosts are allowed to connect, how clients<br />
# are authenticated, which PostgreSQL user names they can use, which<br />
# databases they can access. Records take one of these forms:<br />
#<br />
# local DATABASE USER METHOD [OPTION]<br />
140
B. APPENDIX - EVALUATION B.5. Performance Validation File 2<br />
# host DATABASE USER CIDR-ADDRESS METHOD [OPTION]<br />
# hostssl DATABASE USER CIDR-ADDRESS METHOD [OPTION]<br />
# hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTION]<br />
#<br />
# (The uppercase it<strong>em</strong>s must be replaced by actual values.)<br />
#<br />
# The first field is the connection type: "local" is a Unix-domain<br />
socket,<br />
# "host" is either a plain or SSL-encrypted TCP/IP socket, "hostssl"<br />
is an<br />
# SSL-encrypted TCP/IP socket, and "hostnossl" is a plain TCP/IP<br />
#<br />
socket.<br />
# DATABASE can be "all", "sameuser", "samerole", a database name, or<br />
# a comma-separated list thereof.<br />
#<br />
# USER can be "all", a user name, a group name prefixed with "+", or<br />
# a comma-separated list thereof. In both the DATABASE and USER<br />
fields<br />
# you can also write a file name prefixed with "@" to inclu<strong>de</strong> names<br />
from<br />
# a separate file.<br />
#<br />
# CIDR-ADDRESS specifies the set of hosts the record matches.<br />
# It is ma<strong>de</strong> up of an IP address and a CIDR mask that is an integer<br />
# (between 0 and 32 (IPv4) or 128 (IPv6) inclusive) that specifies<br />
# the number of significant bits in the mask. Alternatively, you can<br />
write<br />
# an IP address and netmask in separate columns to specify the set of<br />
#<br />
hosts.<br />
# METHOD can be "trust", "reject", "md5", "crypt", "password", "gss",<br />
"sspi",<br />
# "krb5", "i<strong>de</strong>nt", "pam" or "ldap". Note that "password" sends<br />
passwords<br />
# in clear text; "md5" is preferred since it sends encrypted<br />
#<br />
passwords.<br />
# OPTION is the i<strong>de</strong>nt map or the name of the PAM service, <strong>de</strong>pending<br />
#<br />
on METHOD.<br />
141
B. APPENDIX - EVALUATION B.5. Performance Validation File 2<br />
# Database and user names containing spaces, commas, quotes and other<br />
special<br />
# characters must be quoted. Quoting one of the keywords "all", "<br />
sameuser" or<br />
# "samerole" makes the name lose its special character, and just<br />
match a<br />
# database or username with that name.<br />
#<br />
# This file is read on server startup and when the postmaster<br />
receives<br />
# a SIGHUP signal. If you edit the file on a running syst<strong>em</strong>, you<br />
have<br />
# to SIGHUP the postmaster for the changes to take effect. You can<br />
use<br />
# "pg_ctl reload" to do that.<br />
# Put your actual configuration here<br />
# ----------------------------------<br />
#<br />
# If you want to allow non-local connections, you need to add more<br />
# "host" records. In that case you will also need to make PostgreSQL<br />
listen<br />
# on a non-local interface via the listen_addresses configuration<br />
parameter,<br />
# or via the -i or -h command line switches.<br />
#<br />
# DO NOT DISABLE!<br />
# If you change this first entry you will need to make sure that the<br />
# database<br />
# super user can access the database using some other method.<br />
# Noninteractive<br />
# access to all databases is required during automatic maintenance<br />
# (custom daily cronjobs, replication, and similar tasks).<br />
#<br />
# Database administrative login by UNIX sockets<br />
local all postgres i<strong>de</strong>nt sameuser<br />
142
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
# TYPE DATABASE USER CIDR-ADDRESS METHOD<br />
# "local" is for Unix domain socket connections only<br />
local all all i<strong>de</strong>nt sameuser<br />
# IPv4 local connections:<br />
host all all 127.0.0.1/32 md5<br />
# IPv6 local connections:<br />
host all all ::1/128 md5<br />
B.6 Performance Validation File 3<br />
# -----------------------------<br />
# PostgreSQL configuration file<br />
# -----------------------------<br />
#<br />
# This file consists of lines of the form:<br />
#<br />
# name = value<br />
#<br />
# (The "=" is optional.) Whitespace may be used. Comments are<br />
introduced with<br />
# "#" anywhere on a line. The complete list of parameter names and<br />
allowed<br />
# values can be found in the PostgreSQL documentation.<br />
#<br />
# The commented-out settings shown in this file represent the <strong>de</strong>fault<br />
values.<br />
# Re-commenting a setting is NOT sufficient to revert it to the<br />
<strong>de</strong>fault value;<br />
# you need to reload the server.<br />
#<br />
# This file is read on server startup and when the server receives a<br />
SIGHUP<br />
# signal. If you edit the file on a running syst<strong>em</strong>, you have to<br />
SIGHUP the<br />
# server for the changes to take effect, or use "pg_ctl reload".<br />
Some<br />
# parameters, which are marked below, require a server shutdown and<br />
restart to<br />
# take effect.<br />
143
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
#<br />
# Any parameter can also be given as a command-line option to the<br />
server, e.g.,<br />
# "postgres -c log_connections=on". Some paramters can be changed at<br />
run time<br />
# with the "SET" SQL command.<br />
#<br />
# M<strong>em</strong>ory units: kB = kilobytes MB = megabytes GB = gigabytes<br />
# Time units: ms = milliseconds s = seconds min = minutes h =<br />
hours d = days<br />
#------------------------------------------------------------------------------<br />
# FILE LOCATIONS<br />
#------------------------------------------------------------------------------<br />
# The <strong>de</strong>fault values of these variables are driven from the -D<br />
command-line<br />
# option or PGDATA environment variable, represented here as<br />
ConfigDir.<br />
data_directory = ’/var/lib/postgresql/8.3/main’<br />
hba_file = ’/etc/postgresql/8.3/main/pg_hba.conf’<br />
i<strong>de</strong>nt_file = ’/etc/postgresql/8.3/main/pg_i<strong>de</strong>nt.conf’<br />
# If external_pid_file is not explicitly set, no extra PID file is<br />
written.<br />
external_pid_file = ’/var/run/postgresql/8.3-main.pid’<br />
#------------------------------------------------------------------------------<br />
# CONNECTIONS AND AUTHENTICATION<br />
#------------------------------------------------------------------------------<br />
# - Connection Settings -<br />
144
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
#listen_addresses = ’localhost’ # what IP address(es) to<br />
listen on;<br />
port = 5432<br />
max_connections = 100<br />
# comma-separated list of<br />
addresses;<br />
# <strong>de</strong>faults to ’localhost’,<br />
’*’ = all<br />
# (change requires restart)<br />
# Note: Increasing max_connections costs ˜400 bytes of shared m<strong>em</strong>ory<br />
per<br />
# connection slot, plus lock space (see max_locks_per_transaction).<br />
You might<br />
# also need to raise shared_buffers to support more connections.<br />
#superuser_reserved_connections = 3 # (change requires restart)<br />
unix_socket_directory = ’/var/run/postgresql’<br />
#unix_socket_group = ’’ # (change requires restart)<br />
#unix_socket_permissions = 0777 # begin with 0 to use octal<br />
notation<br />
# (change requires restart)<br />
#bonjour_name = ’’ # <strong>de</strong>faults to the computer<br />
name<br />
# - Security and Authentication -<br />
#authentication_timeout = 1min # 1s-600s<br />
ssl = true<br />
# (change requires restart)<br />
#ssl_ciphers = ’ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH’ # allowed SSL<br />
ciphers<br />
#password_encryption = on<br />
#db_user_namespace = off<br />
# Kerberos and GSSAPI<br />
# (change requires restart)<br />
#krb_server_keyfile = ’’ # (change requires restart)<br />
#krb_srvname = ’postgres’ # (change requires restart,<br />
Kerberos only)<br />
#krb_server_hostname = ’’ # <strong>em</strong>pty string matches any<br />
keytab entry<br />
145
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
# (change requires restart,<br />
Kerberos only)<br />
#krb_caseins_users = off # (change requires restart)<br />
#krb_realm = ’’ # (change requires restart)<br />
# - TCP Keepalives -<br />
# see "man 7 tcp" for <strong>de</strong>tails<br />
#tcp_keepalives_idle = 0 # TCP_KEEPIDLE, in seconds;<br />
# 0 selects the syst<strong>em</strong><br />
<strong>de</strong>fault<br />
#tcp_keepalives_interval = 0 # TCP_KEEPINTVL, in seconds;<br />
# 0 selects the syst<strong>em</strong><br />
<strong>de</strong>fault<br />
#tcp_keepalives_count = 0 # TCP_KEEPCNT;<br />
# 0 selects the syst<strong>em</strong><br />
<strong>de</strong>fault<br />
#------------------------------------------------------------------------------<br />
# RESOURCE USAGE (except WAL)<br />
#------------------------------------------------------------------------------<br />
# - M<strong>em</strong>ory -<br />
shared_buffers = 24MB<br />
#t<strong>em</strong>p_buffers = 8MB # min 800kB<br />
#max_prepared_transactions = 5 # can be 0 or more<br />
# (change requires restart)<br />
# Note: Increasing max_prepared_transactions costs ˜600 bytes of<br />
shared m<strong>em</strong>ory<br />
# per transaction slot, plus lock space (see<br />
max_locks_per_transaction).<br />
#work_m<strong>em</strong> = 1MB # min 64kB<br />
#maintenance_work_m<strong>em</strong> = 16MB # min 1MB<br />
#max_stack_<strong>de</strong>pth = 2MB # min 100kB<br />
# - Free Space Map -<br />
146
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
max_fsm_pages = 153600<br />
#max_fsm_relations = 1000 # min 100, ˜70 bytes each<br />
# - Kernel Resource Usage -<br />
#max_files_per_process = 1000 # min 25<br />
# (change requires restart)<br />
# (change requires restart)<br />
#shared_preload_libraries = ’’ # (change requires restart)<br />
# - Cost-Based Vacuum Delay -<br />
#vacuum_cost_<strong>de</strong>lay = 0 # 0-1000 milliseconds<br />
#vacuum_cost_page_hit = 1 # 0-10000 credits<br />
#vacuum_cost_page_miss = 10 # 0-10000 credits<br />
#vacuum_cost_page_dirty = 20 # 0-10000 credits<br />
#vacuum_cost_limit = 200 # 1-10000 credits<br />
# - Background Writer -<br />
#bgwriter_<strong>de</strong>lay = 200ms # 10-10000ms between rounds<br />
#bgwriter_lru_maxpages = 100 # 0-1000 max buffers written/<br />
round<br />
#bgwriter_lru_multiplier = 2.0 # 0-10.0 multipler on buffers<br />
scanned/round<br />
#-----------------------------------------------------------------------------<br />
# WRITE AHEAD LOG<br />
#-----------------------------------------------------------------------------<br />
fsync = on<br />
synchronous_commit = on<br />
commit_<strong>de</strong>lay = 0<br />
commit_siblings = 1<br />
# - Settings -<br />
147
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
#fsync = on # turns forced<br />
synchronization on or off<br />
#synchronous_commit = on # immediate fsync at commit<br />
#wal_sync_method = fsync # the <strong>de</strong>fault is the first<br />
option<br />
# supported by the operating<br />
syst<strong>em</strong>:<br />
# open_datasync<br />
# fdatasync<br />
# fsync<br />
# fsync_writethrough<br />
# open_sync<br />
#full_page_writes = on # recover from partial page<br />
writes<br />
#wal_buffers = 64kB # min 32kB<br />
# (change requires restart)<br />
#wal_writer_<strong>de</strong>lay = 200ms # 1-10000 milliseconds<br />
#commit_<strong>de</strong>lay = 0 # range 0-100000, in<br />
microseconds<br />
#commit_siblings = 5 # range 1-1000<br />
# - Checkpoints -<br />
#checkpoint_segments = 3 # in logfile segments, min 1,<br />
16MB each<br />
#checkpoint_timeout = 5min # range 30s-1h<br />
#checkpoint_completion_target = 0.5 # checkpoint target duration,<br />
0.0 - 1.0<br />
#checkpoint_warning = 30s # 0 is off<br />
# - Archiving -<br />
#archive_mo<strong>de</strong> = off # allows archiving to be done<br />
# (change requires restart)<br />
#archive_command = ’’ # command to use to archive a logfile<br />
segment<br />
#archive_timeout = 0 # force a logfile segment switch<br />
after this<br />
# time; 0 is off<br />
148
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
#-----------------------------------------------------------------------------<br />
# QUERY TUNING<br />
#-----------------------------------------------------------------------------<br />
# - Planner Method Configuration -<br />
#enable_bitmapscan = on<br />
#enable_hashagg = on<br />
#enable_hashjoin = on<br />
#enable_in<strong>de</strong>xscan = on<br />
#enable_mergejoin = on<br />
#enable_nestloop = on<br />
#enable_seqscan = on<br />
#enable_sort = on<br />
#enable_tidscan = on<br />
# - Planner Cost Constants -<br />
#seq_page_cost = 1.0 # measured on an arbitrary<br />
scale<br />
#random_page_cost = 4.0 # same scale as above<br />
#cpu_tuple_cost = 0.01 # same scale as above<br />
#cpu_in<strong>de</strong>x_tuple_cost = 0.005 # same scale as above<br />
#cpu_operator_cost = 0.0025 # same scale as above<br />
#effective_cache_size = 128MB<br />
# - Genetic Query Optimizer -<br />
#geqo = on<br />
#geqo_threshold = 12<br />
#geqo_effort = 5 # range 1-10<br />
#geqo_pool_size = 0 # selects <strong>de</strong>fault based on<br />
effort<br />
#geqo_generations = 0 # selects <strong>de</strong>fault based on<br />
effort<br />
#geqo_selection_bias = 2.0 # range 1.5-2.0<br />
# - Other Planner Options -<br />
149
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
#<strong>de</strong>fault_statistics_target = 10 # range 1-1000<br />
#constraint_exclusion = off<br />
#from_collapse_limit = 8<br />
#join_collapse_limit = 8 # 1 disables collapsing of<br />
explicit<br />
# JOIN clauses<br />
#------------------------------------------------------------------------------<br />
# ERROR REPORTING AND LOGGING<br />
#------------------------------------------------------------------------------<br />
### EMANUEL<br />
#log_<strong>de</strong>stination = ’syslog’<br />
#silent_mo<strong>de</strong> = on<br />
#log_min_duration_stat<strong>em</strong>ent = 0<br />
#log_duration = off<br />
#log_stat<strong>em</strong>ent = ’none’<br />
#syslog_i<strong>de</strong>nt = ’<strong>em</strong>anuel’<br />
#log_line_prefix = ’%u %d %t ’<br />
# - Where to Log -<br />
#log_<strong>de</strong>stination = ’st<strong>de</strong>rr’ # Valid values are<br />
combinations of<br />
# This is used when logging to st<strong>de</strong>rr:<br />
# st<strong>de</strong>rr, csvlog, syslog and<br />
eventlog,<br />
# <strong>de</strong>pending on platform.<br />
csvlog<br />
# requires logging_collector<br />
to be on.<br />
#logging_collector = off # Enable capturing of st<strong>de</strong>rr<br />
and csvlog<br />
150
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
# into log files. Required to<br />
be on for<br />
# csvlogs.<br />
# These are only used if logging_collector is on:<br />
# (change requires restart)<br />
#log_directory = ’pg_log’ # directory where log files<br />
are written,<br />
# can be absolute or relative<br />
to PGDATA<br />
#log_filename = ’postgresql-%Y-%m-%d_%H%M%S.log’ # log file<br />
name pattern,<br />
# can inclu<strong>de</strong> strftime()<br />
escapes<br />
#log_truncate_on_rotation = off # If on, an existing log file<br />
of the<br />
# same name as the new log<br />
file will be<br />
# truncated rather than<br />
appen<strong>de</strong>d to.<br />
# But such truncation only<br />
occurs on<br />
# time-driven rotation, not<br />
on restarts<br />
# or size-driven rotation.<br />
Default is<br />
# off, meaning append to<br />
existing files<br />
# in all cases.<br />
#log_rotation_age = 1d # Automatic rotation of<br />
logfiles will<br />
# happen after that time. 0<br />
to disable.<br />
#log_rotation_size = 10MB # Automatic rotation of<br />
logfiles will<br />
# These are relevant when logging to syslog:<br />
#syslog_facility = ’LOCAL0’<br />
151<br />
# happen after that much log<br />
output.<br />
# 0 to disable.
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
#syslog_i<strong>de</strong>nt = ’postgres’<br />
# - When to Log -<br />
#client_min_messages = notice # values in or<strong>de</strong>r of<br />
<strong>de</strong>creasing <strong>de</strong>tail:<br />
# <strong>de</strong>bug5<br />
# <strong>de</strong>bug4<br />
# <strong>de</strong>bug3<br />
# <strong>de</strong>bug2<br />
# <strong>de</strong>bug1<br />
# log<br />
# notice<br />
# warning<br />
# error<br />
#log_min_messages = notice # values in or<strong>de</strong>r of<br />
<strong>de</strong>creasing <strong>de</strong>tail:<br />
# <strong>de</strong>bug5<br />
# <strong>de</strong>bug4<br />
# <strong>de</strong>bug3<br />
# <strong>de</strong>bug2<br />
# <strong>de</strong>bug1<br />
# info<br />
# notice<br />
# warning<br />
# error<br />
# log<br />
# fatal<br />
# panic<br />
#log_error_verbosity = <strong>de</strong>fault # terse, <strong>de</strong>fault, or verbose<br />
messages<br />
#log_min_error_stat<strong>em</strong>ent = error # values in or<strong>de</strong>r of<br />
<strong>de</strong>creasing <strong>de</strong>tail:<br />
152<br />
# <strong>de</strong>bug5<br />
# <strong>de</strong>bug4<br />
# <strong>de</strong>bug3<br />
# <strong>de</strong>bug2
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
# <strong>de</strong>bug1<br />
# info<br />
# notice<br />
# warning<br />
# error<br />
# log<br />
# fatal<br />
# panic (effectively off)<br />
#log_min_duration_stat<strong>em</strong>ent = 0 # -1 is disabled, 0 logs all<br />
stat<strong>em</strong>ents<br />
# and their durations, > 0<br />
logs only<br />
# stat<strong>em</strong>ents running at least<br />
this time.<br />
#silent_mo<strong>de</strong> = off # DO NOT USE without syslog<br />
or<br />
# - What to Log -<br />
#<strong>de</strong>bug_print_parse = off<br />
#<strong>de</strong>bug_print_rewritten = off<br />
#<strong>de</strong>bug_print_plan = off<br />
#<strong>de</strong>bug_pretty_print = off<br />
#log_checkpoints = off<br />
#log_connections = off<br />
#log_disconnections = off<br />
#log_duration = off<br />
#log_hostname = off<br />
log_line_prefix = ’%t’<br />
153<br />
# logging_collector<br />
# (change requires restart)<br />
# special values:<br />
# %u = user name<br />
# %d = database name<br />
# %r = r<strong>em</strong>ote host and port<br />
# %h = r<strong>em</strong>ote host<br />
# %p = process ID<br />
# %t = timestamp without<br />
milliseconds
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
# %m = timestamp with<br />
milliseconds<br />
# %i = command tag<br />
# %c = session ID<br />
# %l = session line number<br />
# %s = session start<br />
timestamp<br />
# %v = virtual transaction<br />
ID<br />
# %x = transaction ID (0 if<br />
none)<br />
# %q = stop here in non-<br />
session<br />
# processes<br />
# %% = ’%’<br />
# e.g. ’ ’<br />
#log_lock_waits = off # log lock waits >=<br />
<strong>de</strong>adlock_timeout<br />
#log_stat<strong>em</strong>ent = ’none’ # none, ddl, mod, all<br />
#log_t<strong>em</strong>p_files = -1 # log t<strong>em</strong>porary files equal<br />
or larger<br />
# than specified size;<br />
# -1 disables, 0 logs all<br />
t<strong>em</strong>p files<br />
#log_timezone = unknown # actually, <strong>de</strong>faults to TZ<br />
environment<br />
# setting<br />
#------------------------------------------------------------------------------<br />
# RUNTIME STATISTICS<br />
#------------------------------------------------------------------------------<br />
# - Query/In<strong>de</strong>x Statistics Collector -<br />
#track_activities = on<br />
#track_counts = on<br />
#update_process_title = on<br />
154
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
# - Statistics Monitoring -<br />
#log_parser_stats = off<br />
#log_planner_stats = off<br />
#log_executor_stats = off<br />
#log_stat<strong>em</strong>ent_stats = off<br />
#-----------------------------------------------------------------------------<br />
# AUTOVACUUM PARAMETERS<br />
#-----------------------------------------------------------------------------<br />
#autovacuum = on # Enable autovacuum<br />
subprocess? ’on’<br />
# requires track_counts to<br />
also be on.<br />
#log_autovacuum_min_duration = -1 # -1 disables, 0 logs all<br />
actions and<br />
# their durations, > 0 logs<br />
only<br />
# actions running at least<br />
that time.<br />
#autovacuum_max_workers = 3 # max number of autovacuum<br />
subprocesses<br />
#autovacuum_naptime = 1min # time between autovacuum<br />
runs<br />
#autovacuum_vacuum_threshold = 50 # min number of row updates<br />
before<br />
# vacuum<br />
#autovacuum_analyze_threshold = 50 # min number of row updates<br />
before<br />
# analyze<br />
#autovacuum_vacuum_scale_factor = 0.2 # fraction of table size<br />
before vacuum<br />
#autovacuum_analyze_scale_factor = 0.1 # fraction of table size<br />
before analyze<br />
#autovacuum_freeze_max_age = 200000000 # maximum XID age before<br />
forced vacuum<br />
155
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
# (change requires restart)<br />
#autovacuum_vacuum_cost_<strong>de</strong>lay = 20 # <strong>de</strong>fault vacuum cost <strong>de</strong>lay<br />
for<br />
# autovacuum, -1 means use<br />
# vacuum_cost_<strong>de</strong>lay<br />
#autovacuum_vacuum_cost_limit = -1 # <strong>de</strong>fault vacuum cost limit<br />
for<br />
# autovacuum, -1 means use<br />
# vacuum_cost_limit<br />
#------------------------------------------------------------------------------<br />
# CLIENT CONNECTION DEFAULTS<br />
#------------------------------------------------------------------------------<br />
# - Stat<strong>em</strong>ent Behavior -<br />
#search_path = ’"$user",public’ # sch<strong>em</strong>a names<br />
#<strong>de</strong>fault_tablespace = ’’ # a tablespace name, ’’ uses<br />
the <strong>de</strong>fault<br />
#t<strong>em</strong>p_tablespaces = ’’ # a list of tablespace names,<br />
’’ uses<br />
#check_function_bodies = on<br />
#<strong>de</strong>fault_transaction_isolation = ’read committed’<br />
#<strong>de</strong>fault_transaction_read_only = off<br />
#session_replication_role = ’origin’<br />
# only <strong>de</strong>fault tablespace<br />
#stat<strong>em</strong>ent_timeout = 0 # 0 is disabled<br />
#vacuum_freeze_min_age = 100000000<br />
#xmlbinary = ’base64’<br />
#xmloption = ’content’<br />
# - Locale and Formatting -<br />
datestyle = ’iso,mdy’<br />
#timezone = unknown # actually, <strong>de</strong>faults to TZ<br />
environment<br />
156<br />
# setting
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
#timezone_abbreviations = ’Default’ # Select the set of available<br />
time zone<br />
# abbreviations. Currently,<br />
there are<br />
# Default<br />
# Australia<br />
# India<br />
# You can create your own<br />
file in<br />
# share/timezonesets/.<br />
#extra_float_digits = 0 # min -15, max 2<br />
#client_encoding = sql_ascii # actually, <strong>de</strong>faults to<br />
database<br />
# encoding<br />
# These settings are initialized by initdb, but they can be changed.<br />
lc_messages = ’en_US.UTF-8’<br />
lc_monetary = ’en_US.UTF-8’<br />
lc_numeric = ’en_US.UTF-8’<br />
lc_time = ’en_US.UTF-8<br />
# <strong>de</strong>fault configuration for text search<br />
<strong>de</strong>fault_text_search_config = ’pg_catalog.english’<br />
# - Other Defaults -<br />
#explain_pretty_print = on<br />
#dynamic_library_path = ’$libdir’<br />
#local_preload_libraries = ’’<br />
#-----------------------------------------------------------------------------<br />
# LOCK MANAGEMENT<br />
#-----------------------------------------------------------------------------<br />
#<strong>de</strong>adlock_timeout = 1s<br />
#max_locks_per_transaction = 64 # min 10<br />
157<br />
# (change requires restart)
B. APPENDIX - EVALUATION B.6. Performance Validation File 3<br />
# Note: Each lock table slot uses ˜270 bytes of shared m<strong>em</strong>ory, and<br />
there are<br />
# max_locks_per_transaction * (max_connections +<br />
max_prepared_transactions)<br />
# lock table slots.<br />
#------------------------------------------------------------------------------<br />
# VERSION/PLATFORM COMPATIBILITY<br />
#------------------------------------------------------------------------------<br />
# - Previous PostgreSQL Versions -<br />
#add_missing_from = off<br />
#array_nulls = on<br />
#backslash_quote = safe_encoding # on, off, or safe_encoding<br />
#<strong>de</strong>fault_with_oids = off<br />
#escape_string_warning = on<br />
#regex_flavor = advanced # advanced, exten<strong>de</strong>d, or<br />
basic<br />
#sql_inheritance = on<br />
#standard_conforming_strings = off<br />
#synchronize_seqscans = on<br />
# - Other Platforms and Clients -<br />
#transform_null_equals = off<br />
#------------------------------------------------------------------------------<br />
# CUSTOMIZED OPTIONS<br />
#------------------------------------------------------------------------------<br />
#custom_variable_classes = ’’ # list of custom variable<br />
class names<br />
158
Bibliography<br />
[Ama09] Amazon. Amazon elastic compute cloud (amazon ec2). World Wi<strong>de</strong> Web, http:<br />
//aws.amazon.com/ec2/, 2009.<br />
[Cit09] Citrix. Xen source: Open source virtualization. World Wi<strong>de</strong> Web, http://www.<br />
xensource.com, 2009.<br />
[Con03] World Wi<strong>de</strong> Web Consortium. Extensible markup language. World Wi<strong>de</strong> Web,<br />
http://www.w3.org/XML/, 2003.<br />
[Cru08] Thin Crust. Thin crust main page. World Wi<strong>de</strong> Web, http://www.thincrust.<br />
net/, 2008.<br />
[DMT08] DMTF. Open virtualization format specificiation. World Wi<strong>de</strong> Web, http://<br />
www.dmtf.org/standards/published_documents/DSP0243_1.0.0.pdf,<br />
Sept<strong>em</strong>ber 2008.<br />
[Fou09a] The Apache Software Foundation. Apache homepage. World Wi<strong>de</strong> Web, http:<br />
//www.apache.org/, 2009.<br />
[Fou09b] The Eclipse Foundation. Eclipse homepage. World Wi<strong>de</strong> Web, http://www.<br />
eclipse.org/, 2009.<br />
[Fou09c] The Eclipse Foundation. Rich client platform. World Wi<strong>de</strong> Web, http://wiki.<br />
eclipse.org/in<strong>de</strong>x.php/Rich_Client_Platform, 2009.<br />
[FSF08] Inc. Free Software Foundation. Bison - gnu parser generator. World Wi<strong>de</strong> Web,<br />
http://www.gnu.org/software/bison/, 2008.<br />
[GGL + 09] Patrick Goldsack, Julio Guijarro, Steve Loughran, Alistair Coles, Andrew Farrell,<br />
Antonio Lain, Paul Murray, and Peter Toft. The smartfrog configuration manage-<br />
ment framework. SIGOPS Oper. Syst. Rev., 43(1):16–25, 2009.<br />
[GH98] Etienne M. Gagnon and Laurie J. Hendren. Sablecc, an object-oriented compiler<br />
framework. Technology of Object-Oriented Languages, International Conference on,<br />
0:140, 1998.<br />
159
BIBLIOGRAPHY<br />
[Gro09a] Mantis PHP Bug Tracker Development Group. Mantis bug tracker homepage.<br />
World Wi<strong>de</strong> Web, http://www.mantisbt.org/, 2009.<br />
[Gro09b] PostgreSQL Global Development Group. Postgresql homepage. World Wi<strong>de</strong> Web,<br />
http://www.postgresql.org/, 2009.<br />
[Hon] Vasant Honavar. Automata induction, grammar inference, and language acqui-<br />
sition. World Wi<strong>de</strong> Web, http://www.cs.iastate.edu/˜honavar/ailab/<br />
projects/grammar.html.<br />
[Mic09a] Microsoft. Microsoft virtualization. World Wi<strong>de</strong> Web, http://www.microsoft.<br />
com/virtualization/<strong>de</strong>fault.mspx, 2009.<br />
[Mic09b] Sun Microsyst<strong>em</strong>s. Mysql homepage. World Wi<strong>de</strong> Web, http://www.mysql.<br />
com/, 2009.<br />
[Mic09c] Sun Microsyst<strong>em</strong>s. Sun virtualization. World Wi<strong>de</strong> Web, http://www.sun.com/<br />
solutions/virtualization/in<strong>de</strong>x.jsp, 2009.<br />
[Mic09d] Sun Microsyst<strong>em</strong>s. Using jar files. World Wi<strong>de</strong> Web, http://java.sun.com/<br />
<strong>de</strong>veloper/Books/javaprogramming/JAR/basics/, 2009.<br />
[oM] University of Maryland. Lecture: Top-down parsers. http://www.cs.umd.edu/<br />
class/fall2002/cmsc430/lec4.pdf.<br />
[oV08] History of Virtualization. Vmware. World Wi<strong>de</strong> Web, http://www.vmware.com/<br />
technology/history.html, 2008.<br />
[Par09] Parallels. Parallels homepage. World Wi<strong>de</strong> Web, http://www.parallels.com/,<br />
2009.<br />
[PH01] Rajesh Parekh and Vasant G. Honavar. Learning dfa from simple examples. Mach.<br />
Learn., 44(1-2):9–35, 2001.<br />
[Pro04] Sax Project. Sax. World Wi<strong>de</strong> Web, http://www.saxproject.org/, 2004.<br />
[Pro09] JavaCC Project. Javacc homepage. World Wi<strong>de</strong> Web, https://javacc.<strong>de</strong>v.<br />
java.net/, 2009.<br />
[Ram00] Ariel Ortiz Ramirez. Three-tier architecture. 2000.<br />
[SAF07] Ya-Yunn Su, Mona Attariyan, and Jason Flinn. Autobash: improving configuration<br />
manag<strong>em</strong>ent with operating syst<strong>em</strong> causality analysis. SIGOPS Oper. Syst. Rev.,<br />
41(6):237–250, 2007.<br />
[Sin04] Amit Singh. An introduction to virtualization. http://www.kernelthread.<br />
com/publications/virtualization/, 2004.<br />
160
BIBLIOGRAPHY<br />
[Sol09a] Evolve Space Solutions. Virtu product line. World Wi<strong>de</strong> Web, http:<br />
//www.evolve.pt/in<strong>de</strong>x.php?option=com_content&view=article&id=<br />
82&It<strong>em</strong>id=85, 2009.<br />
[Sol09b] Evolve Space Solutions. Virtu software <strong>de</strong>sign document, 2009.<br />
[Sta07] James Staten. The case for virtual appliances, Nov<strong>em</strong>ber 2007.<br />
[VMw] VMware. Vmware virtualization. http://www.vmware.com/technology/<br />
virtualization.html.<br />
[VMw09] VMware. Vmware home page. World Wi<strong>de</strong> Web, http://www.vmware.com,<br />
2009.<br />
[VX] Vmware and Xensource. The open virtual machine format whitepaper for ovf spec-<br />
ification. White Paper, Version 0.9.<br />
[W3S09] W3Schools. Xml dom tutorial. World Wi<strong>de</strong> Web, http://www.w3schools.com/<br />
dom/<strong>de</strong>fault.asp, 2009.<br />
[WCG04] Andrew Whitaker, Richard S. Cox, and Steven D. Gribble. Configuration <strong>de</strong>bugging<br />
as search: finding the needle in the haystack. In OSDI’04: Proceedings of the 6th<br />
conference on Symposium on Opearting Syst<strong>em</strong>s Design & Impl<strong>em</strong>entation, pages 6–6,<br />
Berkeley, CA, USA, 2004. USENIX Association.<br />
161