<!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" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Language" content="en-us" />
<meta name="ROBOTS" content="ALL" />
<meta http-equiv="imagetoolbar" content="no" />
<meta name="MSSmartTagsPreventParsing" content="true" />
<meta name="Keywords" content="cherokee web server httpd http" />
<meta name="Description" content="Cherokee is a flexible, very fast, lightweight Web server. It is implemented entirely in C, and has no dependencies beyond a standard C library. It is embeddable and extensible with plug-ins. It supports on-the-fly configuration by reading files or strings, TLS/SSL (via GNUTLS or OpenSSL), virtual hosts, authentication, cache friendly features, PHP, custom error management, and much more." />
<link href="media/css/cherokee_doc.css" rel="stylesheet" type="text/css" media="all" />
</head>
<body>
<h2 id="_a_href_index_html_index_a_8594_a_href_config_html_configuration_a"><a href="index.html">Index</a> → <a href="config.html">Configuration</a></h2>
<div class="sectionbody">
</div>
<h2 id="_information_sources">Information Sources</h2>
<div class="sectionbody">
<div class="paragraph"><p>Every information source to be used by the web server is configured
only once in this section. After that, any virtual server will be able
to use as many as desired without having to set up the same thing over
and over again for every one of the configured servers.</p></div>
<div class="paragraph"><p>This section shows the configured information sources (<em>Known
sources</em>), the usage of sources by every defined rule in your virtual
servers (<em>Source usage</em>) and allows the addition and edition of
sources.</p></div>
<div class="paragraph"><p>There are two possible settings as <strong>information sources</strong>:</p></div>
<div class="olist arabic"><ol class="arabic">
<li>
<p>
<strong>Remote</strong>: Cherokee will simply dispatch the request to the specified
host. As many hosts as needed can be added, and Cherokee will simply
apply the balancing strategy to which the information source is
assigned among them. If for any reason the requests made to these
hosts could not be performed, the processes would simply fail.
</p>
</li>
<li>
<p>
<strong>Local</strong>: As before, many hosts can be specified (despite the name,
the selection is not limited to the localhost). This works the same
way as the previous option. But in this case, if a request cannot be
responded then, instead of failing directly, the command specified
in the field <tt>Interpreter</tt> would be launched before reconnecting to
try again. The most common use of this would be launching the
service that should handle the request, but it is a flexible
mechanism that in theory could allow you to reroute the information
to allow you to serve SSH sessions via your webserver or any other
neat tricks you can think of. If this field is specified then the
parameter <tt>Spawning timeout</tt> can also be specified. If this limit is
exceeded and the interpreter has not yet been launched, Cherokee
will give up. The default value is 3 seconds.
</p>
</li>
</ol></div>
<div class="paragraph"><p>Note that because of Cherokee’s flexibility and modularity, sometimes
and depending of the situation one or the other setting might not
make much sense. In such occasions <tt>cherokee-admin</tt> will simply hide
whatever options do not apply.</p></div>
<div class="imageblock">
<div class="content">
<img src="media/images/admin_info_sources.png" alt="media/images/admin_info_sources.png" />
</div>
<div class="image-title">PHP information source</div>
</div>
<div class="admonitionblock" id="daemonization">
<table><tr>
<td class="icon">
<div class="title">Warning</div>
</td>
<td class="content">Do not provide daemonizing options as part of the command to launch a
given interpreter.
Cherokee’s auto-spawning mechanism is very useful, since it can
re-launch a local interpreter if for whatever reason the process had
died unexpectedly. The launched interpreter is automatically
daemonized, and <tt>stdout</tt> and <tt>stderr</tt> are conveniently handled in
accordance to any logging setting you might have configured. Beware:
some applications accept a parameter to daemonize themselves, but
using such parameter will most likely interfere with Cherokee, so you
are advised against that. There is no need for such parameters,
stderr/stdout redirections, background-launching, etc.</td>
</tr></table>
</div>
<div class="admonitionblock">
<table><tr>
<td class="icon">
<div class="title">Tip</div>
</td>
<td class="content">The information about source usage allows you to see which information
sources are currently in use in whatever rule configured along your
list of virtual servers. This is intended as a tool to let you know
whether you can or cannot safely remove an information source from
your list. When you do so, the source is also removed from the rule.
For instance, if your PHP rule was balancing among two information
sources, by deleting one of the sources in this section you would also
be deleting it in the corresponding rule entry. Now the PHP rule would
balance only with one information source. This is perfectly safe. The
problem arises whenever you want to completely exhaust the list of
sources being balanced. Since every balancer (a generic balancer or a
FastCGI balancer, for example) needs at least one information source,
the rule would be broken and Cherokee would fail to start. This is
prevented by disabling the deletion of the last source of any rule. To
eliminate such sources you will have to manually fix the rule by
either setting up alternative information sources or by completely
eliminating the rule.</td>
</tr></table>
</div>
<h3 id="unix_sockets">Unix Sockets</h3><div style="clear:left"></div>
<div class="paragraph"><p>Note that information sources can be addressed by host:port or directly
through Unix sockets. You only have to specify a full path to the
socket instead of the <tt>host:port</tt>.</p></div>
<div class="paragraph"><p>For instance an entry such as <tt>/var/tmp/socket-tmp.1</tt> should get
everything to simply work if that was a correct path.</p></div>
<h3 id="further_insight">Further insight</h3><div style="clear:left"></div>
<div class="paragraph"><p>This is the list of currently supported balancing strategies:</p></div>
<div class="ulist"><ul>
<li>
<p>
<a href="modules_balancers_round_robin.html">Round Robin</a>
</p>
</li>
<li>
<p>
<a href="modules_balancers_ip_hash.html">IP Hash</a>
</p>
</li>
</ul></div>
<div class="paragraph"><p>And these are the handlers that use balancing:</p></div>
<div class="ulist"><ul>
<li>
<p>
<a href="modules_handlers_proxy.html">Reverse HTTP proxy</a>
</p>
</li>
<li>
<p>
<a href="modules_handlers_fcgi.html">FastCGI</a>
</p>
</li>
<li>
<p>
<a href="modules_handlers_scgi.html">SCGI</a>
</p>
</li>
<li>
<p>
<a href="modules_handlers_uwsgi.html">uWSGI</a>
</p>
</li>
<li>
<p>
<a href="modules_handlers_dbslayer.html">MySQL bridge</a>
</p>
</li>
</ul></div>
</div>
<div id="footer">
<div id="footer-text">
</div>
</div>
</body>
</html>
