• Why Cherokee?Feature overview.
• RequirementsHardware and software requirements.
• DownloadWhere and how to download Cherokee.
• InstallationInstallation instructions.
• Upgrading CherokeeUpgrading from a previous release?
• Running CherokeeBasic steps to run Cherokee.

• WalkthroughOverview and walkthrough.
• HomeMain section.
• StatusServer status information.
• GeneralGeneral settings.
• Virtual serversServer definition.
• Information SourcesDefining information sources.
• AdvancedAdvanced tweaking. Not for the faint of heart.
• WizardsConfiguration assistants for many known scenarios.

• AuthenticationHow to set up authenticated resources.
• Cross compilationHow to cross compile Cherokee.
• DBSlayerHow to set up DBSlayer MySQL balancing.
• Embedding CherokeeCherokee on embedded devices.
• MaintenanceSeamlessly switching to maintenance mode.
• Managing logsSeamless log rotation.
• Optimizing CherokeeRecommendations and tweaks.
• RedirectionsCommon redirection examples.
• SSL/TLS, certsSecure connection tips.
• HTTPS acceleratorSSL Offloading with Cherokee.
• StreamingHow to stream Audio and Video with Cherokee.
• PHPHow to run PHP apps with Cherokee.
• Ruby on RailsHow to run Ruby on Rails apps with Cherokee.
• DjangoHow to run Django apps with Cherokee.
• ColdFusionHow to run ColdFusion apps with Cherokee.
• DrupalHow to run Drupal on Cherokee.
• WordpressHow to run Wordpress on Cherokee.
• AlfrescoHow to run Alfresco on Cherokee.
• ASP.NETHow to run ASP.NET apps with Mono and Cherokee.
• GlassFishHow to run Java apps with Cherokee.
• JoomlaHow to run Joomla on Cherokee.
• KumbiaHow to run Kumbia apps with Cherokee.
• LiferayHow to run Liferay on Cherokee.
• MailmanHow to run Mailman on Cherokee.
• MoodleHow to run Moodle on Cherokee.
• NagiosHow to run Nagios with Cheroke.
• phpBBHow to run phpBB on Cherokee.
• phpMyAdminHow to run phpMyAdmin on Cherokee.
• SugarCRMHow to run SugarCRM on Cherokee.
• Concrete5How to run Concrete5 on Cherokee.
• SymfonyHow to run Symfony apps with Cherokee.
• TracHow to run Trac on Cherokee.
• ZendHow to run Zend apps with Cherokee.
• uWSGISetting up Cherokee for uWSGI.
• HTTP to HTTPSHow to redirect all traffic from HTTP to HTTPS.
• Restricting traffic by IPHow to restrict traffic based on incoming IP.
• Domain matchingMatching domains and subdomains with Cherokee.

• HandlersConnection handling modules.
• ValidatorsAuthentication mechanisms.
• EncodersCompression and filtering.
• LoggersLogging mechanisms.
• BalancersLoad balancing strategies.

• FAQList of Frequently Asked Questions.
• Front-line CacheSpecifics of the Caching subsystem.
• System TuningTweaking the OS for maximum performance.
• Cherokee GoodiesInteresting Cherokee features.
• Usage graphsInformation on the several graphs available.
• SignalsSignals supported by Cherokee.
• CommunityMore information sources.
• Common errorsSome typical production errors and their cause.
• Man pagesDetails about each program bundled with Cherokee.

• QuickstartWhere to start?
• DebuggingResources available to debug Cherokee.
• cherokee.confInternal configuration specs.
• Quality AssuranceSome info about QA in Cherokee.
• CTKDive into the Cherokee Toolkit.

• Introduction to DevelopmentHow to build a package.

Configuration

Index → Configuration

Information Sources

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.

This section shows the configured information sources (Known sources), the usage of sources by every defined rule in your virtual servers (Source usage) and allows the addition and edition of sources.

There are two possible settings as information sources:

1. Remote: 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.

2. Local: 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 Interpreter 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 Spawning timeout 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.

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 cherokee-admin will simply hide whatever options do not apply.

PHP information source

Warning

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 stdout and stderr 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.

Tip

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.

Unix Sockets

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 host:port.

For instance an entry such as /var/tmp/socket-tmp.1 should get everything to simply work if that was a correct path.

Further insight

This is the list of currently supported balancing strategies:

• Round Robin

• IP Hash

And these are the handlers that use balancing:

• Reverse HTTP proxy

• FastCGI

• SCGI

• uWSGI

• MySQL bridge