Sophie

Sophie

distrib > Fedora > 17 > i386 > media > updates > by-pkgid > b50d8ee6d7871fcc13c0677a9364ed59 > files > 486

bcfg2-doc-1.3.0-1.fc17.noarch.rpm



<!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>Probes &mdash; 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="Plugins" href="../index.html" />
    <link rel="next" title="current-kernel" href="current-kernel.html" />
    <link rel="prev" title="Plugin Roles" href="../plugin-roles.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="current-kernel.html" title="current-kernel"
             accesskey="N">next</a> |</li>
        <li class="right" >
          <a href="../plugin-roles.html" title="Plugin Roles"
             accesskey="P">previous</a> |</li>
	<li><a href="../../../index.html">home</a> |&nbsp;</li>
	<!--<li><a href="../../../search.html">search</a> |&nbsp;</li>-->
	<li><a href="../../../help/index.html">help</a> |&nbsp;</li>
	<li><a href="../../../contents.html">documentation </a> &raquo;</li>

          <li><a href="../../../contents.html" >Bcfg2 documentation 1.3.0</a> &raquo;</li>
          <li><a href="../../index.html" >The Bcfg2 Server</a> &raquo;</li>
          <li><a href="../index.html" accesskey="U">Plugins</a> &raquo;</li> 
      </ul>
    </div>
  

    <div class="document">
      <div class="documentwrapper">
        <div class="bodywrapper">
          <div class="body">
            
  <div class="section" id="probes">
<span id="server-plugins-probes-index"></span><h1>Probes<a class="headerlink" href="#probes" title="Permalink to this headline">¶</a></h1>
<p>At times you need to gather information from a client machine before you
can generate its configuration. For example, if some of your machines
have both a local scratch disk and a system disk while others only have
the system disk, you would want to know this information to correctly
generate an <cite>/etc/auto.master</cite> autofs config file for each type. Here
we will look at how to do this.</p>
<p>First, create a <tt class="docutils literal"><span class="pre">Probes</span></tt> directory in our toplevel repository
location:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">mkdir</span> <span class="o">/</span><span class="n">var</span><span class="o">/</span><span class="n">lib</span><span class="o">/</span><span class="n">bcfg2</span><span class="o">/</span><span class="n">Probes</span>
</pre></div>
</div>
<p>This directory will hold any small scripts we want to use to grab
information from client machines.  These scripts can be in any scripting
language; the shebang line (the <tt class="docutils literal"><span class="pre">#!/usr/bin/env</span> <span class="pre">some_interpreter_binary</span></tt>
line at the very top of the script) is used to determine the script&#8217;s
interpreter.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Bcfg2 uses python mkstemp to create the Probe scripts on the
client. If your /tmp directory is mounted <strong>noexec</strong>, you will
likely need to modify the <span class="target" id="index-0"></span><tt class="xref std std-envvar docutils literal"><span class="pre">TMPDIR</span></tt> environment variable so
that the bcfg2 client creates the temporary files in a directory
from which it can execute.</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="versionadded">
<span class="versionmodified">New in version 1.3.0.</span></p>
<p class="last">A probe script must exit with a return value of 0.  If it exits
with a non-0 return value, the client will abort its run.  This
behavior can be disabled by setting <tt class="docutils literal"><span class="pre">exit_on_probe_failure</span> <span class="pre">=</span> <span class="pre">0</span></tt>
in the <tt class="docutils literal"><span class="pre">[client]</span></tt> section of <tt class="docutils literal"><span class="pre">bcfg2.conf</span></tt>.</p>
</div>
<p>Now we need to figure out what exactly we want to do.  In this case,
we want to hand out an <tt class="docutils literal"><span class="pre">/etc/auto.master</span></tt> file that looks like:</p>
<div class="highlight-python"><pre>/software  /etc/auto.software --timeout 3600
/home      /etc/auto.home --timeout 3600
/hometest  /etc/auto.hometest --timeout 3600
/nfs       /etc/auto.nfs --timeout 3600
/scratch   /etc/auto.scratch --timeout 3600</pre>
</div>
<p>for machines that have a scratch disk. For machines without an extra disk,
we want to get rid of that last line:</p>
<div class="highlight-python"><pre>/software  /etc/auto.software --timeout 3600
/home      /etc/auto.home --timeout 3600
/hometest  /etc/auto.hometest --timeout 3600
/nfs       /etc/auto.nfs --timeout 3600</pre>
</div>
<p>So, from the Probes standpoint we want to create a script that counts
the number of SCSI disks in a client machine. To do this, we create a
very simple <tt class="docutils literal"><span class="pre">Probes/scratchlocal</span></tt> script:</p>
<div class="highlight-bash"><div class="highlight"><pre>grep -c Vendor /proc/scsi/scsi
</pre></div>
</div>
<p>Running this on a node with <em>n</em> disks will return the number <em>n+1</em>, as
it also counts the controller as a device. To differentiate between the
two classes of machines we care about, we just need to check the output
of this script for numbers greater than 2. We do this in the template.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This example uses <a class="reference internal" href="../generators/cfg.html#server-plugins-generators-cfg-cheetah"><em>Cheetah Templates</em></a>,
but Cheetah templates are <strong>not</strong> required in order for Probes to
operate properly.</p>
</div>
<p>For the template we will want to create a <tt class="docutils literal"><span class="pre">Cfg/etc/auto.master</span></tt>
directory to hold the template of the file in question. Inside of this
template we will need to check the result of the Probe script that got
run and act accordingly. The
<tt class="docutils literal"><span class="pre">Cfg/etc/auto.master/auto.master.cheetah</span></tt> file looks like:</p>
<div class="highlight-python"><pre>/software  /etc/auto.software --timeout 3600
/home      /etc/auto.home --timeout 3600
/hometest  /etc/auto.hometest --timeout 3600
/nfs       /etc/auto.nfs --timeout 3600
#if int($self.metadata.Probes["scratchlocal"]) &gt; 2
/scratch   /etc/auto.scratch --timeout 3600
#end if</pre>
</div>
<p>Any Probe script you run will store its output in
<tt class="docutils literal"><span class="pre">$self.metadata.Probes[&quot;scriptname&quot;]</span></tt>, so we get to our
<cite>scratchlocal</cite> script&#8217;s output as seen above.  (See <a class="reference internal" href="#handling-probe-output">Handling Probe
Output</a>, below, for more information on how this is done.)  Note that
we had to wrap the output in an <cite>int()</cite> call; the script output is
treated as a string, so it needs to be converted before it can be
tested numerically.</p>
<p>With all of these pieces in place, the following series of events will
happen when the client is run:</p>
<ol class="arabic simple">
<li>Client runs</li>
<li>Server hands down our <tt class="docutils literal"><span class="pre">scratchlocal</span></tt> probe script</li>
<li>Client runs the <tt class="docutils literal"><span class="pre">scratchlocal</span></tt> probe script and hands its output
back up to the server</li>
<li>Server generates <tt class="docutils literal"><span class="pre">/etc/auto.master</span></tt> from its template, performing
any templating substitutions/actions needed in the process.</li>
<li>Server hands <tt class="docutils literal"><span class="pre">/etc/auto.master</span></tt> down to the client</li>
<li>Client puts file contents in place.</li>
</ol>
<p>Now we have a nicely dynamic <tt class="docutils literal"><span class="pre">/etc/auto.master</span></tt> that can gracefully
handle machines with different numbers of disks. All that&#8217;s left to do
is to add the <tt class="docutils literal"><span class="pre">/etc/auto.master</span></tt> to a Bundle:</p>
<div class="highlight-xml"><div class="highlight"><pre><span class="nt">&lt;Path</span> <span class="na">name=</span><span class="s">&#39;/etc/auto.master&#39;</span><span class="nt">/&gt;</span>
</pre></div>
</div>
<div class="section" id="handling-probe-output">
<h2>Handling Probe Output<a class="headerlink" href="#handling-probe-output" title="Permalink to this headline">¶</a></h2>
<p>Bcfg2 stores output from probes in the <tt class="docutils literal"><span class="pre">Probes</span></tt> property of a
client&#8217;s metadata object.  To access this data in
<a class="reference internal" href="../generators/cfg.html#server-plugins-generators-cfg-genshi"><em>Genshi Templates</em></a>, for instance, you could
do:</p>
<div class="highlight-python"><pre>${metadata.Probes['script-name']}</pre>
</div>
<p>This is not the full output of the probe; any lines that start with
&#8220;group:&#8221; have been stripped from the output.  The data is a
string-like object that has some interesting and salient features:</p>
<ul class="simple">
<li>If the data is a valid XML document, then
<tt class="docutils literal"><span class="pre">metadata.Probes['script-name'].xdata</span></tt> will be an
<tt class="docutils literal"><span class="pre">lxml.etree._Element</span></tt> object representing the XML data.</li>
<li>If the data is a valid JSON document, and either the Python <tt class="docutils literal"><span class="pre">json</span></tt>
or <tt class="docutils literal"><span class="pre">simplejson</span></tt> module is installed, then
<tt class="docutils literal"><span class="pre">metadata.Probes['script-name'].json</span></tt> will be a data structure
representing the JSON data.</li>
<li>If the data is a valid YAML document, and either the Python <tt class="docutils literal"><span class="pre">yaml</span></tt>
or <tt class="docutils literal"><span class="pre">syck</span></tt> module is installed, then
<tt class="docutils literal"><span class="pre">metadata.Probes['script-name'].yaml</span></tt> will be a data structure
representing the YAML data.</li>
</ul>
<p>If these conditions are not met, then the named properties will be
<tt class="docutils literal"><span class="pre">None</span></tt>.  In all other fashions, the probe data objects should act
like strings.</p>
</div>
<div class="section" id="host-and-group-specific-probes">
<h2>Host- and Group-Specific probes<a class="headerlink" href="#host-and-group-specific-probes" title="Permalink to this headline">¶</a></h2>
<p>Bcfg2 has the ability to alter probes based on client hostname and group
membership. These files work similarly to files in Cfg.</p>
<p>If multiple files with the same basename apply to a client, the most
specific one is used. Only one instance of a probe is served to a given
client, so if a host-specific version and generic version apply, only
the client-specific one will be used.</p>
<p>If you want to to detect information about the client operating system,
the <a class="reference internal" href="ohai.html#server-plugins-probes-ohai"><em>Ohai</em></a> plugin can help.</p>
</div>
<div class="section" id="data-storage">
<span id="server-plugins-probes-data-storage"></span><h2>Data Storage<a class="headerlink" href="#data-storage" title="Permalink to this headline">¶</a></h2>
<p class="versionadded">
<span class="versionmodified">New in version 1.3.0.</span></p>
<p>The Probes plugin stores the output of client probes locally on the
Bcfg2 server in order to ensure that probe data and groups are
available on server startup (rather than having to wait until all
probes have run every time the server is restarted) and to
<a class="reference internal" href="../../bcfg2-info.html#server-bcfg2-info"><em>bcfg2-info</em></a> and related tools.  There are
two options for storing this data: <tt class="docutils literal"><span class="pre">Probes/probed.xml</span></tt>, a plain XML
file stored in the Bcfg2 specification; or in a database.</p>
<p>Advantages and disadvantages of using the database:</p>
<ul class="simple">
<li>The database is easier to query from other machines, for instance if
you run <tt class="docutils literal"><span class="pre">bcfg2-info</span></tt> or <tt class="docutils literal"><span class="pre">bcfg2-test</span></tt> on a machine that is not
your Bcfg2 server.</li>
<li>The database allows multiple Bcfg2 servers to share probe data.</li>
<li>The database is likely to handle probe data writes (which happen on
every client run) more quickly, since it can only write the probes
whose data has changed.</li>
<li>The database is likely to handle probe data reads (which happen only
on server startup) more slowly, since it must query a database
rather than the local filesystem.  Once the data has been read in
initially (from XML file or from the database) it is kept in memory.</li>
</ul>
<p>To use the database-backed storage model, set <tt class="docutils literal"><span class="pre">use_database</span></tt> in the
<tt class="docutils literal"><span class="pre">[probes]</span></tt> section of <tt class="docutils literal"><span class="pre">bcfg2.conf</span></tt> to <tt class="docutils literal"><span class="pre">true</span></tt>.  You will also
need to configure the <a class="reference internal" href="../../database.html#server-database"><em>Global Database Settings</em></a>.</p>
<p>The file-based storage model is the default, although that is likely
to change in future versions of Bcfg2.</p>
</div>
<div class="section" id="other-examples">
<h2>Other examples<a class="headerlink" href="#other-examples" title="Permalink to this headline">¶</a></h2>
<div class="toctree-wrapper compound">
<ul>
<li class="toctree-l1"><a class="reference internal" href="current-kernel.html">current-kernel</a></li>
<li class="toctree-l1"><a class="reference internal" href="group.html">group</a></li>
<li class="toctree-l1"><a class="reference internal" href="vserver.html">vserver</a></li>
<li class="toctree-l1"><a class="reference internal" href="grub-serial-order.html">grub-serial-order</a></li>
<li class="toctree-l1"><a class="reference internal" href="manufacturer.html">manufacturer</a></li>
<li class="toctree-l1"><a class="reference internal" href="producttype.html">producttype</a></li>
<li class="toctree-l1"><a class="reference internal" href="serial-console-speed.html">serial-console-speed</a></li>
</ul>
</div>
</div>
<div class="section" id="other-probing-plugins">
<h2>Other Probing plugins<a class="headerlink" href="#other-probing-plugins" title="Permalink to this headline">¶</a></h2>
<div class="toctree-wrapper compound">
<ul>
<li class="toctree-l1"><a class="reference internal" href="ohai.html">Ohai</a><ul>
<li class="toctree-l2"><a class="reference internal" href="ohai.html#client-prerequisites">Client prerequisites</a></li>
<li class="toctree-l2"><a class="reference internal" href="ohai.html#server-prerequisites">Server prerequisites</a></li>
<li class="toctree-l2"><a class="reference internal" href="ohai.html#setup">Setup</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="fileprobes.html">FileProbes</a><ul>
<li class="toctree-l2"><a class="reference internal" href="fileprobes.html#configuration">Configuration</a></li>
</ul>
</li>
</ul>
</div>
</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="#">Probes</a><ul>
<li><a class="reference internal" href="#handling-probe-output">Handling Probe Output</a></li>
<li><a class="reference internal" href="#host-and-group-specific-probes">Host- and Group-Specific probes</a></li>
<li><a class="reference internal" href="#data-storage">Data Storage</a></li>
<li><a class="reference internal" href="#other-examples">Other examples</a><ul>
</ul>
</li>
<li><a class="reference internal" href="#other-probing-plugins">Other Probing plugins</a><ul>
</ul>
</li>
</ul>
</li>
</ul>

  <h4>Previous topic</h4>
  <p class="topless"><a href="../plugin-roles.html"
                        title="previous chapter">Plugin Roles</a></p>
  <h4>Next topic</h4>
  <p class="topless"><a href="current-kernel.html"
                        title="next chapter">current-kernel</a></p>
  <h3>This Page</h3>
  <ul class="this-page-menu">
    <li><a href="../../../_sources/server/plugins/probes/index.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="current-kernel.html" title="current-kernel"
             >next</a> |</li>
        <li class="right" >
          <a href="../plugin-roles.html" title="Plugin Roles"
             >previous</a> |</li>
	<li><a href="../../../index.html">home</a> |&nbsp;</li>
	<!--<li><a href="../../../search.html">search</a> |&nbsp;</li>-->
	<li><a href="../../../help/index.html">help</a> |&nbsp;</li>
	<li><a href="../../../contents.html">documentation </a> &raquo;</li>

          <li><a href="../../../contents.html" >Bcfg2 documentation 1.3.0</a> &raquo;</li>
          <li><a href="../../index.html" >The Bcfg2 Server</a> &raquo;</li>
          <li><a href="../index.html" >Plugins</a> &raquo;</li> 
      </ul>
    </div>
    <div class="footer">
        &copy; 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>