/
dev_cherokee.conf.txt
577 lines (493 loc) · 20.3 KB
/
dev_cherokee.conf.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
== link:index.html[Index] -> link:dev.html[Development info]
////
Outdated. Most changes since January 2009 are trivial, and not much
content has been added since.
////
Development: cherokee.conf
--------------------------
[[introduction]]
Introduction
~~~~~~~~~~~~
Cherokee's configuration system is based on an internal text file
format that the average user should not know about. This configuration
file is read by the server and modified by the administration
interface, so unless you are a Cherokee developer or a really
advanced user, the following format description will not be very
interesting to you.
The default location for Cherokee configuration files is
``/etc/cherokee``, but this may vary based on distribution or
installation parameters.
If you are completely sure about what you are doing, you can modify it
by hand. We recommend you not to do so, since everything can be
handled from link:other_bundle_cherokee-admin.html[cherokee-admin] and a lot
of security measures and consistency checks are made to ensure you end
up with a well formed `cherokee.conf` file.
Having said that, let's proceed to describe the configuration file format. It
is basically a text file that contains a tree where nodes
contain values.
Let's see a basic example::
+
----
server!bind!1!port = 80
server!keepalive = 1
----
Most of the modules and plug-ins read a piece of the tree to
configure themselves. It provides extremely flexible configuration
capabilities for the price of a fairly complex text file. However, I
would like to point out again that users should never read of modify the
configuration file by hand, so it is a format that only developers
should know about.
The following blocks will summarize the configuration keys that the
current Cherokee release handles:
[[server]]
Server
~~~~~~
The server configuration keys define some of the server-wide
properties, such as the user under which the server ought to run if it
is run as root or whether to use keep-alive connections.
[options="header"]
|====================================================================
|**Key** |**Type** |**Description**
|server!bind!#!port |Number |Listen to a TCP port. '#' is a sequential number since many ports can be listened at once.
|server!bind!#!tls |Bool |on\|off: whether the listened port '#' is for HTTPS.
|server!max_fds |Number |Max open file descriptors
|server!listen_queue |Number |Length of the listen queue
|server!thread_number |Number |Number of threads
|server!sendfile_min |Number |Minimum file size of using sendfile
|server!sendfile_max |Number |Maximum file size of using sendfile
|server!max_connection_reuse |Number |How many connections to reuse
|server!ipv6 |Bool |Whether to use IPv6
|server!timeout |Number |Connections timeout
|server!log_flush_lapse |Number |Time between log flushes
|server!nonces_cleanup_lapse |Number |Time between Nonces clean ups
|server!keepalive |Bool |Allow keepalive connections
|server!keepalive_max_requests |Number |How many keepalive reqs per connection
|server!unix_socket |Path |Listen to a Unix socket
|server!panic_action |Path |Path to cherokee-panic
|server!chroot |Bool |Whether to use chroot
|server!pid_file |Path |PID file
|server!listen |IP |Listen NIC
|server!poll_method |String |Which poll method it should use
|server!server_tokens |String |"Server identification: minor, minimal, os, full"
|server!thread_policy |String |"Thread policy: fifo, rr, other"
|server!user |String/Number |Change effective user
|server!group |String/Number |Change effective group
|server!module_dir |Path |Path to the plug-in directory
|server!module_deps |Path |Path to the plug-in inter-dependencies files
|====================================================================
``server!server_tokens`` parameters
[cols="20%,80%",options="header"]
|=====================================
|Value |Description
|Product |Cherokee
|Minor |Cherokee/1.0
|Minimal |Cherokee/1.0.0
|OS |Cherokee/1.0.0 (UNIX)
|Full |Cherokee/1.0.00 b5077 (UNIX)
|=====================================
``server!thread_policy`` parameters
[cols="20%,80%",options="header"]
|=====================================
|Value |Description
|fifo |First in first out
|rr |Round Robin
|other |By default in Linux
|=====================================
[[virtual_server]]
Virtual Server
~~~~~~~~~~~~~~
A virtual server contains the information related to one or more
domains under the same configuration. In a Cherokee server there must
be at least one virtual server named ``default``, and there is no
maximum number.
The prefix of this type of entry is ``vserver``, and by far, it is the
most common type of entry.
Virtual servers are stored in a numbered list. The starting number
does not really matter. What matters is that the list will be
interpreted in an orderly fashion to prioritize some virtual servers
over others, which can be of use depending on the way these are
defined. The only precaution to take is making sure there are no
repeated priorities, since the behavior in these cases in undefined.
[cols="40%,10%,50%",options="header"]
|===================================================================
|**Key** |**Type** |**Description**
|vserver!1!nick = default |String |The name of the Virtual Server
|vserver!1!document_root |Path |Document Root path
|vserver!1!user_dir |String |Users' web directory (for ~ requests)
|vserver!1!domain! ``id`` |String |"Domain name, admits wildcards"
|vserver!1!error_handler |String |Defines the error handler module
|vserver!1!directory_index |List |String list: Directory indexes
|vserver!1!ssl_certificate_file |Path |TLS/SSL certificate file
|vserver!1!ssl_certificate_key_file |Path |TLS/SSL certificate key file
|vserver!1!ssl_ca_list_file |Path |TLS/SSL CA list file
|===================================================================
Besides these configuration keys there are a few other more complex
that needs further explanation:
Defining a virtual server behavior
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A virtual server behavior is basically defined by a rule list, which
includes a number of rules against which each request will be checked.
There are a number of rules types, each one checking a different
aspect of the request. The most usual rule types are the ones that
checks the request URI: directories, extensions, regular expressions
and headers.
All the rule types accept the same configuration sub-properties.
However, the ``match`` property must be present in all the cases. It
specifies which is the rule type and its properties.
The general syntax is::
+
`vserver ! order ! rule ! priority ! match`
The rule types plug-ins shipped within a standard Cherokee release
include:
*Directory*::
The directory specifies how to handle its contents.
+
Example: an entry with priority 20, setting the properties for the
*icons* directory of the default virtual host would be represented
by:
+
----
vserver!1!nick = default
vserver!1!rule!20!match!type = directory
vserver!1!rule!20!match!directory = /icons
----
*Extension*::
It specifies a list of extensions and how they should be handled.
+
Eg: the JPG extensions is:
+
----
vserver!1!rule!30!match!type = extensions
vserver!1!rule!30!match!extensions = jpg,jpeg
----
*Requests*::
When a request matches a regular expression entry, it uses its configuration.
+
Eg: requests beginning with 'a' and PHP extension:
+
-----
vserver!1!rule!40!match!type = request
vserver!1!rule!40!match!request = ^a.*\.php$
----
*Header*::
It tries to match a regular expression against a certain header
entry.
+
Eg: check whether the Referer header matches a specific host:
+
----
vserver!1!rule!50!match!type = header
vserver!1!rule!50!match!header = Referer
vserver!1!rule!50!match!match = .+\.example\.com
----
*Default*::
This rules matches every request. There must be a default rule
configured at the end of the rule list to handle the requests that
did not match any other rule. The end of the list means the smallest
priority value in relative terms. It doesn't have to be `1`
necessarily.
+
Eg: Default rule for the 'default' virtual server:
+
----
vserver!1!rule!1!match = default
vserver!1!rule!1!handler = common
vserver!1!rule!1!handler!iocache = 0
----
+
The ``!encoder`` configuration entry allows to configure encoding
plug-ins. Each entry applies to a specific rule.
[cols="20%,80%",options="header"]
|=============================================================
|Parameter |Description
|deflate |deflate encoder. 0\|1 to define disabled\|enabled.
|gzip |zip encoder. 0\|1 to define disabled\|enabled.
|=============================================================
Example::
+
----
vserver!1!rule!100!encoder!deflate = 1
vserver!1!rule!100!encoder!gzip = 1
vserver!1!rule!100!match = extensions
vserver!1!rule!100!match!extensions = html
----
+
The following parameters are concatenated with any of the previous
kinds of entry:
[cols="20%,10%,70%",options="header"]
|===================================================================
|**Key** |**Type** |**Description**
|priority |Number |Priority in the rules list
|directory_root |Path |Special Directory Root for the request
|allow_from |List |List of IP/Domain allowed to access the resource
|handler |String |Handler (module) that handles the request
|auth |String |Validator (module) that protects the resource
|only_secure |Bool |Allow only secure (https) connections
|===================================================================
The ``auth`` entry deserves a little more attention,
actually. Accepted validator modules are `htdigest, htpasswd, ldap,
mysql, pam, plain`. It restricts the access to some of the objects
accessed by the web server based on a number of properties that are
defined at its child properties:
[cols="10%,10%,80%",options="header"]
|============================================================
|**Key** |**Type** |**Description**
|auth!methods |List |Allowed methods (basic & digest)
|auth!realm |String |Realm of the resource
|auth!users |List |List of allowed users
|============================================================
Some validators have extra configuration keys.
.htdigest, htpasswd, plain
[cols="20%,10%,70%",options="header"]
|====================================================================
|**Key** |**Type** |**Description**
|auth!passwdfile |String |Full path to the passwords' file. htdigest\|htpasswd\|plain
|====================================================================
.mysql
[cols="20%,10%,70%",options="header"]
|====================================================================
|**Key** |**Type** |**Description**
|auth!host |String |MySQL host.
|auth!database |String |Database name.
|auth!user |String |Database user.
|auth!passwd |String |Database password.
|auth!port |Number |Port number of the service.
|auth!query |String |SQL query to match users/passwords. Replace your username for '${user}'.
|auth!use_md5_passwd |Bool |Encrypt the passwords with MD5.
|===================================================================
.ldap
[cols="20%,10%,70%",options="header"]
|====================================================================
|**Key** |**Type** |**Description**
|auth!server |String |IP or hostname of the LDAP server.
|auth!port |Number |Port number of the service.
|auth!base_dn |String |Base distinguished name.
|auth!bind_dn |String |User
|auth!bind_pw |String |Password
|auth!filter |String |LDAP search filter.
|auth!tls |Bool |Indicates TLS based integrity
|auth!ca_file |String |Cert file. Must be provided if TLS is enabled.
|====================================================================
.authlist
[cols="20%,10%,70%",options="header"]
|====================================================================
|**Key** |**Type** |**Description**
|auth |String |name of the validator module: authlist
|auth!list!#!password |String |Password for entry number #
|auth!list!#!user |String |User for entry number #
|====================================================================
[[examples]]
Here are a few examples about how this notation works:
- The default virtual server uses the "common" handler as default
choice for its root directory:
+
----
vserver!1!nick = default
vserver!1!rule!10!directory!/!handler = common
----
- The \*.example.com and \*.examples.org domains are restricted to be
accessed from the local loop interface, and have to be handled as a
FastCGI:
+
----
vserver!5!nick = example
vserver!5!domains!1 = *.example.com
vserver!5!domains!2 = *.example.org
vserver!5!rule!10!directory!/!handler = fcgi
vserver!5!rule!10!directory!/!priority = 1
vserver!5!rule!10!directory!/!allow_from = 127.0.0.1,::1
----
- Rules can be defined that return custom errors using the
link:modules_handlers_custom_error.html[HTTP error] handler: `custom
error`.
+
----
vserver!10!rule!100!handler = custom_error
vserver!10!rule!100!handler!error = 400
----
- ISO images should be handled as files and are protected by a
htdigest file using only Digest authentication:
+
----
vserver!1!nick = default
vserver!1!rule!100!extensions!iso,ISO!handler = file
vserver!1!rule!100!extensions!iso,ISO!auth = htdigest
vserver!1!rule!100!extensions!iso,ISO!auth!realm = My secret isos
vserver!1!rule!100!extensions!iso,ISO!auth!methods = digest
vserver!1!rule!100!extensions!iso,ISO!auth!passwdfile = /var/passwd/isos.htdigest
----
- Authenticated directory with `htpasswd` validator:
+
----
vserver!10!rule!500!auth = htpasswd
vserver!10!rule!500!auth!methods = basic
vserver!10!rule!500!auth!passwdfile = /var/www/passwd.htpasswd
vserver!10!rule!500!auth!realm = secret
vserver!10!rule!500!match = directory
vserver!10!rule!500!match!directory = /auth
vserver!10!rule!500!match!final = 0
vserver!10!rule!500!only_secure = 0
----
- Same example, using `mysql` validator:
+
----
vserver!10!rule!500!auth = mysql
vserver!10!rule!500!auth!database = auth_users
vserver!10!rule!500!auth!host = localhost
vserver!10!rule!500!auth!methods = basic,digest
vserver!10!rule!500!auth!passwd = db_passwd
vserver!10!rule!500!auth!port = 3306
vserver!10!rule!500!auth!query = SELECT password FROM auth_users WHERE username= '${user}'
vserver!10!rule!500!auth!realm = secret
vserver!10!rule!500!auth!use_md5_passwd = 1
vserver!10!rule!500!auth!user = db_user
vserver!10!rule!500!match = directory
vserver!10!rule!500!match!directory = /auth
vserver!10!rule!500!match!final = 0
vserver!10!rule!500!only_secure = 0
----
- Same thing with `ldap` validator:
+
----
vserver!10!rule!500!auth = ldap
vserver!10!rule!500!auth!base_dn = Example DN
vserver!10!rule!500!auth!bind_dn = Directory Manager
vserver!10!rule!500!auth!bind_pw = secretpassword
vserver!10!rule!500!auth!methods = basic
vserver!10!rule!500!auth!port = 389
vserver!10!rule!500!auth!realm = secret
vserver!10!rule!500!auth!server = ldap.example.com
vserver!10!rule!500!auth!tls = 0
vserver!10!rule!500!match = directory
vserver!10!rule!500!match!directory = /auth
vserver!10!rule!500!match!final = 0
vserver!10!rule!500!only_secure = 0
----
[[logs]]
Logs
~~~~
The log files are defined as properties inside the Virtual Server
hierarchy under a ``logger`` entry with the following properties:
[cols="20%,10%,70%",options="header"]
|========================================================
|**Key** |**Type** |**Description**
|logger |String |Output format (validator name)
|logger!access |Node |Defines the access log file
|logger!error |Node |Defines the error log file
|========================================================
and then, both access and error accept a number of parameters
depending on its property ``type`` which specifies where the logging
information will be written. It can be either:
[options="header"]
|========================================================
|**Logger writer Type** |**Description**
|file |Write a file
|syslog |Use the system logging mechanism
|stderr |Use the standard output
|exec |Execute a program with each line
|========================================================
If either ``file`` or ``exec`` is used, there is an additional
parameter that has to be set. In the case of file, a sub-property
named ``filename`` and for exec ``command``.
Examples:
- Apache format logs to the regular files:
+
----
vserver!1!nick = default
vserver!1!logger = combined
vserver!1!logger!access!type = file
vserver!1!logger!access!filename = /var/log/cherokee.access.log
vserver!1!logger!error!type = file
vserver!1!logger!error!filename = /var/log/cherokee.error.log
----
[[information_sources]]
Information sources
~~~~~~~~~~~~~~~~~~~
They follow the format: ``source ! {source number} ! {key}``
[cols="20%,20%,60%",options="header"]
|===========================================================
|**Key** |**Type** |**Description**
|nick |String |Alias to identify the source
|env |String |Variable to be set in the environment
|host |String |host:port or path to unix socket
|interpreter |String |command to launch the service if any
|type |Type |`host` \| `interpreter`
|timeout |Number |spawning timeout specified in seconds
|=============================================================
Examples:
- PHP configured for FastCGI through Unix socket
+
----
source!1!env!PHP_FCGI_CHILDREN = 5
source!1!host = /tmp/cherokee-php.sock
source!1!interpreter = /usr/bin/php-cgi -b /tmp/cherokee-php.sock
source!1!nick = php
source!1!type = interpreter
----
- Or via `host:port` as remote host:
+
----
source!1!host = localhost:1234
source!1!interpreter = /usr/bin/php-cgi -b /tmp/cherokee-php.sock
source!1!type = host
----
[[balancers]]
Balancers
~~~~~~~~~
The balancers must define the information sources to be used. For the
ones defined in the examples above, using round robin from within the
FastCGI handler, the following example would apply.
Example::
+
----
vserver!10!rule!600!handler = fcgi
vserver!10!rule!600!handler!balancer = round_robin
vserver!10!rule!600!handler!balancer!source!1 = 1
vserver!10!rule!600!match = extensions
vserver!10!rule!600!match!extensions = php
vserver!10!rule!600!match!final = 1
----
[[inclusion]]
Inclusion of Configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~
Sometimes it is nice to break out your configuration into several logical files
to be more modular as well as more organized. You can use the ``include``
configuration to accomplish this.
Here is an example::
+
----
include = /etc/cherokee/advanced.conf
----
or even, it is possible to specify a directory to include all of its files::
+
----
include = /etc/cherokee/mods-enabled/
----
[[reverse_proxy]]
Reverse Proxy
~~~~~~~~~~~~~
The reverse proxy , like everything in Cherokee, is modular. It is
configured as any other of the modules that use load balancers.
You need to define a balancing strategy, the information source to be
used by the balancer and, optionally, any expression matches that you
might wish to rewrite in the headers before relaying the connection.
This is a basic example:
----
server!bind!1!port = 1234
# The proxy configuration
vserver!1!nick = default
vserver!1!document_root = /tmp
vserver!1!rule!1!match = default
vserver!1!rule!1!handler = proxy
vserver!1!rule!1!handler!header_hide!1 = server
vserver!1!rule!1!handler!balancer = round_robin
vserver!1!rule!1!handler!balancer!source!1 = 1
# URL rewrite
vserver!1!rule!1!handler!rewrite_request!1!regex = ^/(.+).png$
vserver!1!rule!1!handler!rewrite_request!1!substring = /$1.jpg
vserver!1!rule!1!handler!rewrite_request!2!regex = ^/test/(.+)$ /$1.jpg
vserver!1!rule!1!handler!rewrite_request!2!substring = /test.php?$1
# The information source
source!1!type = host
source!1!host = localhost:9090
----