<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>The Literal Configuration Specification — Bcfg2 1.3.0 documentation</title>
<link rel="stylesheet" href="../_static/default.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../',
VERSION: '1.3.0',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<script type="text/javascript" src="../_static/sidebar.js"></script>
<link rel="shortcut icon" href="../_static/favicon.ico"/>
<link rel="top" title="Bcfg2 1.3.0 documentation" href="../index.html" />
<link rel="up" title="Detailed Bcfg2 Architecture" href="index.html" />
<link rel="next" title="Design Considerations" href="design.html" />
<link rel="prev" title="The Bcfg2 Server" href="server.html" />
<link rel="stylesheet" href="../_static/bcfg2.css" type=""/>
</head>
<body>
<div style="text-align: left; padding: 10px 10px 15px 15px">
<a href="../index.html"><img src="../_static/bcfg2_logo.png" border="0" alt="sampledoc"/></a>
</div>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="../genindex.html" title="General Index"
accesskey="I">index</a></li>
<li class="right" >
<a href="../py-modindex.html" title="Python Module Index"
>modules</a> |</li>
<li class="right" >
<a href="design.html" title="Design Considerations"
accesskey="N">next</a> |</li>
<li class="right" >
<a href="server.html" title="The Bcfg2 Server"
accesskey="P">previous</a> |</li>
<li><a href="../index.html">home</a> | </li>
<!--<li><a href="../search.html">search</a> | </li>-->
<li><a href="../help/index.html">help</a> | </li>
<li><a href="../contents.html">documentation </a> »</li>
<li><a href="../contents.html" >Bcfg2 documentation 1.3.0</a> »</li>
<li><a href="index.html" accesskey="U">Detailed Bcfg2 Architecture</a> »</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body">
<div class="section" id="the-literal-configuration-specification">
<span id="architecture-config-spec"></span><h1>The Literal Configuration Specification<a class="headerlink" href="#the-literal-configuration-specification" title="Permalink to this headline">¶</a></h1>
<p>Literal configuration specifications are served to clients by the
Bcfg2 server. This is a differentiating factor for Bcfg2; all other
major configuration management systems use a non-literal configuration
specification. That is, the clients receive a symbolic configuration that
they process to implement target states. We took the literal approach
for a few reasons:</p>
<ul class="simple">
<li>A small list of configuration element types can be defined, each of
which can have a set of defined semantics. This allows the server to
have a well-formed model of client-side operations. Without a static
lexicon with defined semantics, this isn’t possible. This allows the
server, for example, to record the update of a package as a coherent
event.</li>
<li>Literal configurations do not require client-side processing. Removing
client-side processing reduces the critical footprint of the tool.
That is, the Bcfg2 client (and the tools it calls) need to be
functional, but the rest of the system can be in any state. Yet,
the client will receive a correct configuration.</li>
<li>Having static, defined element semantics also requires that all
operations be defined and implemented in advance. The implementation
can maximize reliability and robustness. In more ad-hoc setups, these
operations aren’t necessarily safely implemented.</li>
</ul>
<div class="section" id="the-structure-of-specifications">
<h2>The Structure of Specifications<a class="headerlink" href="#the-structure-of-specifications" title="Permalink to this headline">¶</a></h2>
<p>Configuration specifications contain some number of clauses. Two types
of clauses exist. Bundles are groups of inter-dependent configuration
entities. The purpose of bundles is to encode installation-time
dependencies such that all new configuration is properly activated
during reconfiguration operations. That is, if a daemon configuration
file is changed, its daemon should be restarted. Another example of
bundle usage is the reconfiguration of a software package. If a package
contains a default configuration file, but it gets overwritten by an
environment-specific one, then that updated configuration file should
survive package upgrade. The purpose of bundles is to describe services,
or reconfigured software packages. Independent clauses contain groups
of configuration entities that aren’t related in any way. This provides a
convenient mechanism that can be used for bulk installations of software.</p>
<p>Each of these clauses contains some number of configuration entities. A
number of configuration entities exist including Path, Package, Service,
etc. Each of these correspond to the obvious system item. Configuration
specifications can get quite large; many systems have specifications
that top one megabyte in size. An example of one is included in an
appendix. These configurations can be written by hand, or generated by
the server.</p>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<h3><a href="../index.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">The Literal Configuration Specification</a><ul>
<li><a class="reference internal" href="#the-structure-of-specifications">The Structure of Specifications</a></li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<p class="topless"><a href="server.html"
title="previous chapter">The Bcfg2 Server</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="design.html"
title="next chapter">Design Considerations</a></p>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/architecture/config-spec.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="../search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="../genindex.html" title="General Index"
>index</a></li>
<li class="right" >
<a href="../py-modindex.html" title="Python Module Index"
>modules</a> |</li>
<li class="right" >
<a href="design.html" title="Design Considerations"
>next</a> |</li>
<li class="right" >
<a href="server.html" title="The Bcfg2 Server"
>previous</a> |</li>
<li><a href="../index.html">home</a> | </li>
<!--<li><a href="../search.html">search</a> | </li>-->
<li><a href="../help/index.html">help</a> | </li>
<li><a href="../contents.html">documentation </a> »</li>
<li><a href="../contents.html" >Bcfg2 documentation 1.3.0</a> »</li>
<li><a href="index.html" >Detailed Bcfg2 Architecture</a> »</li>
</ul>
</div>
<div class="footer">
© Copyright 2009-2013, Narayan Desai.
Last updated on Mar 20, 2013.
Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
</div>
</body>
</html>
distrib
>
Fedora
>
17
>
i386
>
media
>
updates
>
by-pkgid
>
b50d8ee6d7871fcc13c0677a9364ed59
>
files
>
334
