<!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>