<!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 Bcfg2 Server — 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="The Literal Configuration Specification" href="config-spec.html" />
<link rel="prev" title="The Bcfg2 Client" href="client.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="config-spec.html" title="The Literal Configuration Specification"
accesskey="N">next</a> |</li>
<li class="right" >
<a href="client.html" title="The Bcfg2 Client"
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-bcfg2-server">
<span id="architecture-server"></span><h1>The Bcfg2 Server<a class="headerlink" href="#the-bcfg2-server" title="Permalink to this headline">¶</a></h1>
<p>The Bcfg2 server is responsible for taking a network description and
turning it into a series of configuration specifications for particular
clients. It also manages probed data and tracks statistics for clients.</p>
<p>The Bcfg2 server takes information from two sources when generating
client configuration specifications. The first is a pool of metadata that
describes clients as members of an aspect-based classing system. That is,
clients are defined in terms of aspects of their behavior. The other is
a file system repository that contains mappings from metadata to literal
configuration. These are combined to form the literal configuration
specifications for clients.</p>
<div class="section" id="the-configuration-specification-construction-process">
<h2>The Configuration Specification Construction Process<a class="headerlink" href="#the-configuration-specification-construction-process" title="Permalink to this headline">¶</a></h2>
<p>As we described in the previous section, the client connects to the server
to request a configuration specification. The server uses the client’s
metadata and the file system repository to build a specification that
is tailored for the client. This process consists of the following steps:</p>
<ul>
<li><p class="first"><strong>Metadata Lookup</strong></p>
<p>The server uses the client’s IP address to initiate the metadata
lookup. This initial metadata consists of a (profile, image) tuple. If
the client already has metadata registered, then it is used. If not,
then default values are used and stored for future use. This metadata
tuple is expanded using some profile and class definitions also included
in the metadata. The end result of this process is metadata consisting
of hostname, profile, image, a list of classes, a list of attributes
and a list of bundles.</p>
</li>
<li><p class="first"><strong>Abstract Configuration Construction</strong></p>
<p>Once the server has the client metadata, it is used to create
an abstract configuration. An abstract configuration contains
all of the configuration elements that will exist in the final
specification <strong>without</strong> any specifics. All entries will be typed
(i.e. the tagname will be one of Package, Path, Action, etc) and will
include a name. These configuration entries are grouped into bundles,
which document installation time interdependencies.</p>
<p>Here is an example of an abstract configuration entry:</p>
<div class="highlight-xml"><div class="highlight"><pre><span class="nt"><Package</span> <span class="na">name=</span><span class="s">'openssh-server'</span><span class="nt">/></span>
</pre></div>
</div>
</li>
<li><p class="first"><strong>Configuration Binding</strong></p>
<p>The abstract configuration determines the structure of the client
configuration, however, it doesn’t yet contain literal configuration
information. After the abstract configuration is created, each
configuration entry must be bound to a client-specific value. The Bcfg2
server uses plugins to provide these client-specific bindings. The Bcfg2
server core contains a dispatch table that describes which plugins can
handle requests of a particular type. The responsible plugin is located
for each entry. It is called, passing in the configuration entry and
the client’s metadata. The behavior of plugins is explicitly undefined,
so as to allow maximum flexibility. The behaviours of the stock plugins
are documented elsewhere in this manual. Once this binding process
is completed, the server has a literal, client-specific configuration
specification. This specification is complete and comprehensive; the
client doesn’t need to process it at all in order to use it. It also
represents the totality of the configuration specified for the client.</p>
<p>Here is the entry from above once it has been bound to its literal
specification (In this case, using the Packages plugin).</p>
<div class="highlight-xml"><div class="highlight"><pre><span class="nt"><Package</span> <span class="na">name=</span><span class="s">"openssh-server"</span> <span class="na">version=</span><span class="s">"auto"</span> <span class="na">type=</span><span class="s">"deb"</span><span class="nt">/></span>
</pre></div>
</div>
</li>
</ul>
</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 Bcfg2 Server</a><ul>
<li><a class="reference internal" href="#the-configuration-specification-construction-process">The Configuration Specification Construction Process</a></li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<p class="topless"><a href="client.html"
title="previous chapter">The Bcfg2 Client</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="config-spec.html"
title="next chapter">The Literal Configuration Specification</a></p>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/architecture/server.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="config-spec.html" title="The Literal Configuration Specification"
>next</a> |</li>
<li class="right" >
<a href="client.html" title="The Bcfg2 Client"
>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
>
338
