pound man page on DragonFly
[printable version]
POUND(8) System Manager's Manual POUND(8)
NAME
pound - HTTP/HTTPS reverse-proxy and load-balancer
SYNOPSIS
pound [-v] [-c] [-V] [-f config_file] [-p pid_file]
DESCRIPTION
Pound is a reverse-proxy load balancing server. It accepts requests
from HTTP/HTTPS clients and distributes them to one or more Web
servers. The HTTPS requests are decrypted and passed to the back-ends
as plain HTTP.
If more than one back-end server is defined, Pound chooses one of them
randomly, based on defined priorities. By default, Pound keeps track of
associations between clients and back-end servers (sessions).
GENERAL PRINCIPLES
In general Pound needs three types of objects defined in order to func‐
tion: listeners, services and back-ends.
Listeners
A listener is a definition of how Pound receives requests from
the clients (browsers). Two types of listeners may be defined:
regular HTTP listeners and HTTPS (HTTP over SSL/TLS) listeners.
At the very least a listener must define the address and port to
listen on, with additional requirements for HTTPS listeners.
Services
A service is the definition of how the requests are answered.
The services may be defined within a listener or at the top
level (global). When a request is received Pound attempts to
match them to each service in turn, starting with the services
defined in the listener itself and, if needed, continuing with
the services defined at the global level. The services may
define their own conditions as to which requests they can
answer: typically this involves certain URLs (images only, or a
certain path) or specific headers (such as the Host header). A
service may also define a session mechanism: if defined future
requests from a given client will always be answered by the same
back-end.
Back-ends
The back-ends are the actual servers for the content requested.
By itself, Pound supplies no responses - all contents must be
received from a "real" web server. The back-end defines how the
server should be contacted.
Three types of back-ends may be defined: a "regular" back-end
which receives requests and returns responses, a "redirect"
back-end in which case Pound will respond with a redirect
response, without accessing any back-end at all, or an "emer‐
gency" back-end which will be used only if all other backends
are "dead".
Multiple back-ends may be defined within a service, in which
case Pound will load-balance between the available back-ends.
If a back-end fails to respond it will be considered "dead", in
which case Pound will stop sending requests to it. Dead back-
ends are periodically checked for availability, and once they
respond again they are "resurected" and requests are sent again
their way. If no back-ends are available (none were defined, or
all are "dead") then Pound will reply with "503 Service Unavail‐
able", without checking additional services.
The connection between Pound and the back-ends is always via
HTTP, regardless of the actual protocol used between Pound and
the client.
OPTIONS
Options available (see also below for configuration file options):
-v Verbose mode: error messages will be sent to stdout even if
Pound was configured to log to syslog. This applies only to
startup messages, before Pound puts itself in the background.
Normal operational messages will still go to syslog.
-V Print version: Pound will exit immediately after printing the
current version and configuration flags.
-c Check only: Pound will exit immediately after parsing the con‐
figuration file. This may be used for running a quick syntax
check before actually activating a server.
-f config_file
Location of the configuration file (see below for a full
description of the format). Default: /usr/local/etc/pound.cfg
-p pid_file
Location of the pid file. Pound will write its own pid into
this file. Normally this is used for shell scripts that control
starting and stopping of the daemon. Default:
/var/run/pound.pid
In general, any number of back-end servers may be specified. Use the
priority to affect the load distribution among unequal-performance
servers.
One (or more) copies of Pound should be started at boot time. Use "big
iron" if you expect heavy loads: while Pound is as light-weight as I
know how to make it, with a lot of simultaneous requests it will use
quite a bit of CPU and memory. Multiple CPUs are your friend.
CONFIGURATION FILE
Each line in the file is considered a complete configuration directive.
The directives are case-insensitive. Empty lines or lines starting in
'#' are ignored. There are three types of directives: global directives
(they affect the settings for the entire program instance), listener
directives (they define which requests Pound will listen for), and ser‐
vice directives (they affect only a specific group of requests).
GLOBAL DIRECTIVES
Global directives may appear anywhere within the configuration file,
though it is customary for them to be at the start. They may appear in
any order.
User "user_name"
Specify the user Pound will run as (must be defined in
/etc/passwd).
Group "group_name"
Specify the group Pound will run as (must be defined in
/etc/group).
RootJail "directory_path_and_name"
Specify the directory that Pound will chroot to at runtime.
Please note that OpenSSL requires access to /dev/urandom, so
make sure you create a device by that name, accessible from the
root jail directory. Pound may also require access to /dev/sys‐
log or similar.
Daemon 0|1
Have Pound run in the foreground (if 0) or as a daemon (if 1).
By default Pound runs as a daemon (detaches itself from the con‐
trolling terminal and puts itself in the background). By speci‐
fying this option you can force Pound to work like a regular
process. Useful for debugging or if you want to use something
like daemontools.
Threads nnn
How many worker threads Pound should use. Default: 128. Tune
this parameter to improve performance. If you set it too high,
Pound will use a lot memory, and some CPU will be wasted on con‐
text switches. If you set it too low requests may be served
with some delay. Experiment to find the optimal value for your
installation.
LogFacility value
Specify the log facility to use. value (default: daemon) must
be one of the symbolic facility names defined in syslog.h. This
facility shall be used for logging. Using a - for the facility
name causes Pound to log to stdout/stderr.
LogLevel value
Specify the logging level: 0 for no logging, 1 (default) for
regular logging, 2 for extended logging (show chosen backend
server as well), 3 for Apache-like format (Combined Log Format
with Virtual Host), 4 (same as 3 but without the virtual host
information) and 5 (same as 4 but with information about the
Service and BackEnd used). This value can be overridden for
specific listeners.
IgnoreCase 0|1
Ignore case when matching URLs (default: 0). This value can be
overridden for specific services.
DynScale 0|1
Enable or disable the dynamic rescaling code (default: 0). If
enabled Pound will periodically try to modify the back-end pri‐
orities in order to equalise the response times from the various
back-ends. This value can be overridden for specific services.
Alive value
Specify how often Pound will check for resurected back-end hosts
(default: 30 seconds). In general, it is a good idea to set this
as low as possible - it will find resurected hosts faster. How‐
ever, if you set it too low it will consume resources - so
beware.
Client value
Specify for how long Pound will wait for a client request
(default: 10 seconds). After this long has passed without the
client sending any data Pound will close the connection. Set it
higher if your clients time-out on a slow network or over-loaded
server, lower if you start getting DOS attacks or run into prob‐
lems with IE clients. This value can be overridden for specific
listeners.
TimeOut value
How long should Pound wait for a response from the back-end (in
seconds). Default: 15 seconds. This value can be overridden for
specific back-ends.
ConnTO value
How long should Pound wait for a connection to the back-end (in
seconds). Default: the TimeOut value. This value can be overrid‐
den for specific back-ends.
Grace value
How long should Pound continue to answer existing connections
after a receiving and INT or HUP signal (default: 30 seconds).
The configured listeners are closed immediately. You can bypass
this behaviour by stopping Pound with a TERM or QUIT signal, in
which case the program exits without any delay.
SSLEngine "name"
Use an OpenSSL hardware acceleration card called name. Available
only if OpenSSL-engine is installed on your system.
ECDHcurve "name"
Use the named curve for elliptical curve encryption (default:
prime256v1).
Control "/path/to/socket"
Set the control socket path. If not defined Pound does not lis‐
ten for any commands. The commands may be issued by using the
poundctl(8) program.
Include "/path/to/file"
Include the file as though it were part of the configuration
file.
Anonymise
Replace the last byte of the client address with 0 for logging
purposes. Default: log the client address in full.
HTTP Listener
An HTTP listener defines an address and port that Pound will listen on
for HTTP requests. All configuration directives enclosed between Lis‐
tenHTTP and End are specific to a single HTTP listener. At the very
least you must specify and address and a port for each listener. The
following directives are available:
Address address
The address that Pound will listen on. This can be a numeric IP
address, or a symbolic host name that must be resolvable at run-
time. This is a mandatory parameter. The address 0.0.0.0 may be
used as an alias for 'all available addresses on this machine',
but this practice is strongly discouraged, as it will interfere
with the rewriting mechanisms (see below).
Port port
The port number that Pound will listen on. This is a mandatory
parameter.
xHTTP value
Defines which HTTP verbs are accepted. The possible values are:
0 (default) accept only standard HTTP requests (GET, POST,
HEAD).
1 additionally allow extended HTTP requests (PUT, PATCH,
DELETE).
2 additionally allow standard WebDAV verbs (LOCK, UNLOCK,
PROPFIND, PROPPATCH, SEARCH, MKCOL, MOVE, COPY, OPTIONS, TRACE,
MKACTIVITY, CHECKOUT, MERGE, REPORT).
3 additionally allow MS extensions WebDAV verbs (SUBSCRIBE,
UNSUBSCRIBE, NOTIFY, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY,
BDELETE, CONNECT).
4 additionally allow MS RPC extensions verbs (RPC_IN_DATA,
RPC_OUT_DATA).
Client value
Override the global Client time-out value.
CheckURL "pattern to match"
Define a pattern that must be matched by each request sent to
this listener. A request that does not match is considered to be
illegal. By default Pound accepts all requests (i.e. the pat‐
tern is ".*"), but you are free to limit it to something more
reasonable. Please note that this applies only to the request
path - Pound will still check that the request is syntactically
correct.
Err414 "filename"
A file with the text to be displayed if an Error 414 occurs.
Default: "Request URI is too long.".
Err500 "filename"
A file with the text to be displayed if an Error 500 occurs.
Default: "An internal server error occurred. Please try again
later.".
Err501 "filename"
A file with the text to be displayed if an Error 501 occurs.
Default: "This method may not be used.".
Err503 "filename"
A file with the text to be displayed if an Error 503 occurs.
Default: "The service is not available. Please try again
later.".
MaxRequest nnn
Request maximal size. All requests will be limited to these many
bytes. If a request contains more data than allowed an error 414
is returned. Default: unlimited.
HeadRemove "header pattern"
Remove certain headers from the incoming requests. All
occurences of the matching specified header will be removed.
Please note that this filtering is done prior to other checks
(such as HeadRequire or HeadDeny), so you should not try to
check for these headers in later matches. Multiple directives
may be specified in order to remove more than one header, and
the header itself may be a regular pattern (though this should
be used with caution).
AddHeader "header: to add"
Add the defined header to the request passed to the back-end
server. The header is added verbatim. Use multiple AddHeader
directives if you need to add more than one header.
RewriteLocation 0|1|2
If 1 force Pound to change the Location: and Content-location:
headers in responses. If they point to the back-end itself or to
the listener (but with the wrong protocol) the response will be
changed to show the virtual host in the request. Default: 1
(active). If the value is set to 2 only the back-end address is
compared; this is useful for redirecting a request to an HTTPS
listener on the same server as the HTTP listener.
RewriteDestination 0|1
If 1 force Pound to change the Destination: header in requests.
The header is changed to point to the back-end itself with the
correct protocol. Default: 0.
LogLevel value
Override the global LogLevel value.
Service [ "name" ]
This defines a private service (see below for service definition
syntax). This service will be used only by this listener. The
service may be optionally named, with the name showing in the
poundctl listings.
HTTPS Listener
An HTTPS listener defines an address and port that Pound will listen on
for HTTPS requests. All configuration directives enclosed between Lis‐
tenHTTPS and End are specific to a single HTTPS listener. At the very
least you must specify and address, a port and a server certificate for
each listener. All directives defined for HTTP listeners are applicable
to HTTPS listeners as well. The following additional directives are
also available:
Cert "certificate file"
Specify the server certificate. The certificate file is the file
containing the certificate, possibly a certificate chain and the
signature for this server. This directive is mandatory for HTTPS
listeners.
Please note that multiple Cert directives are allowed if your
OpenSSL version supports SNI. In such cases, the first directive
is the default certificate, with additional certificates used if
the client requests them.
The ordering of the directives is important: the first certifi‐
cate where the CN matches the client request will be used, so
put your directives in the most-specific-to-least specific order
(i.e. wildcard certificates after host-specific certificates).
Cert directives must precede all other SSL-specific directives.
ClientCert 0|1|2|3 depth
Ask for the client's HTTPS certificate: 0 - don't ask (default),
1 - ask, 2 - ask and fail if no certificate was presented, 3 -
ask but do not verify. Depth is the depth of verification for a
client certificate (up to 9). The default depth limit is 9,
allowing for the peer certificate and additional 9 CA certifi‐
cates that must be verified.
Disable SSLv2|SSLv3|TLSv1|TLSv1_1|TLSv1_2
Disable the protocol and all lower protocols as well. This is
due to a limitation in OpenSSL, which does not support disabling
a single protocol. For example, Disable TLSv1 would disable
SSLv2, SSLv3 and TLSv1, thus allowing only TLSv1_1 and TLSv1_2.
Ciphers "acceptable:cipher:list"
This is the list of ciphers that will be accepted by the SSL
connection; it is a string in the same format as in OpenSSL
ciphers(1) and SSL_CTX_set_cipher_list(3).
SSLHonorCipherOrder 0|1
If this value is 1, the server will broadcast a preference to
use Ciphers in the order supplied in the Ciphers directive. If
the value is 0, the server will treat the Ciphers list as the
list of Ciphers it will accept, but no preference will be indi‐
cated. Default value is 0.
SSLAllowClientRenegotiation 0|1|2
If this value is 0, client initiated renegotiation will be dis‐
abled. This will mitigate DoS exploits based on client renego‐
tiation, regardless of the patch status of clients and servers
related to "Secure renegotiation". If the value is 1, secure
renegotiation is supported. If the value is 2, insecure renego‐
tiation is supported, with unpatched clients. This can lead to a
DoS and a Man in the Middle attack! The default value is 0.
CAlist "CAcert_file"
Set the list of "trusted" CA's for this server. The CAcert_file
is a file containing a sequence of CA certificates (PEM format).
The names of the defined CA certificates will be sent to the
client on connection.
VerifyList "Verify_file"
Set the CA (Certificate Authority). The Verify_file is a file
that contains the CA root certificates (in PEM format).
Please note: there is an important difference between the CAlist
and the VerifyList. The CAlist tells the client (browser) which
client certificates it should send. The VerifyList defines which
CAs are actually used for the verification of the returned cer‐
tificate.
CRLlist "CRL_file"
Set the CRL (Certificate Revocation List) file. The CRL_file is
a file that contains the CRLs (in PEM format).
NoHTTPS11 0|1|2
Behave like an HTTP/1.0 server for HTTPS clients. If this value
is 0 disable the check. If the value is 1 do not allow multiple
requests on SSL connections. If the value is 2 (default) disable
multiple requests on SSL connections only for MSIE clients.
Required work-around for a bug in certain versions of IE.
Service
A service is a definition of which back-end servers Pound will use to
reply to incoming requests. A service may be defined as part of a lis‐
tener (in which case it will be used only by that listener), or glob‐
ally (which makes it available to all listeners). Pound will always
try the private services in the order defined, followed by the global
ones.
All configuration directives enclosed between Service and End are spe‐
cific to a single service. The following directives are available:
URL "pattern"
Match the incoming request. If a request fails to match than
this service will be skipped and next one tried. If all services
fail to match Pound returns an error. You may define multiple
URL conditions per service, in which case all patterns must
match. If no URL was defined then all requests match. The match‐
ing is by default case-sensitive, but this can be overridden by
specifying IgnoreCase 1
IgnoreCase 0|1
Override the global IgnoreCase setting.
HeadRequire "pattern"
The request must contain at least on header matching the given
pattern. Multiple HeadRequire directives may be defined per
service, in which case all of them must be satisfied.
HeadDeny "pattern"
The request may not contain any header matching the given pat‐
tern. Multiple HeadDeny directives may be defined per service,
in which case all of them must be satisfied.
Please note: if the listener defined a HeadRemove directive, the
matching headers are removed before the service matching is
attempted.
DynScale 0|1
Enable or disable dynamic rescaling for the current service.
This value will override the value globally defined.
Disabled 0|1
Start Pound with this service disabled (1) or enabled (0). If
started as disabled, the service can be later enabled with
poundctl (8).
BackEnd
Directives enclosed between a BackEnd and the following End
directives define a single back-end server (see below for
details). You may define multiple back-ends per service, in
which case Pound will attempt to load-balance between them.
Redirect [code] "url"
This is a special type of back-end. Instead of sending the
request to a back-end Pound replies immediately with a redirect‐
ion to the given URL. You may define multiple redirectors in a
service, as well as mixing them with regular back-ends.
The address the client is redirected to is determined by the
actual url you specify: if it is a "pure" host (i.e. with no
path) then the client will be redirected to the host you speci‐
fied, with the original request path appended. If your url does
contain a path then the request path is ignored.
Examples: if you specified
Redirect "http://abc.example"
and the client requested http://xyz/a/b/c then it will be redi‐
rected to http://abc.example/a/b/c, but if you specified
Redirect "http://abc.example/index.html"
it will be sent to http://abc.example/index.html.
Technical note: in an ideal world Pound should reply with a "307
Temporary Redirect" status. Unfortunately, that is not yet sup‐
ported by all clients (in particular HTTP 1.0 ones), so Pound
currently replies by default with a "302 Found" instead. You may
override this behaviour by specifying the code to be used (301,
302 or 307).
Emergency
Directives enclosed between an Emergency and the following End
directives define an emergency back-end server (see below for
details). You may define only one emergency server per service,
which Pound will attempt to use if all backends are down.
Session
Directives enclosed between a Session and the following End
directives define a session-tracking mechanism for the current
service. See below for details.
BackEnd
A back-end is a definition of a single back-end server Pound will use
to reply to incoming requests. All configuration directives enclosed
between BackEnd and End are specific to a single service. The following
directives are available:
Address address
The address that Pound will connect to. This can be a numeric IP
address, or a symbolic host name that must be resolvable at run-
time. If the name cannot be resolved to a valid address, Pound
will assume that it represents the path for a Unix-domain
socket. This is a mandatory parameter.
Port port
The port number that Pound will connect to. This is a mandatory
parameter for non Unix-domain back-ends.
HTTPS The back-end is using HTTPS.
Cert "certificate file"
Specify the certificate that Pound will use as a client. The
certificate file is the file containing the certificate, possi‐
bly a certificate chain and the signature. This directive may
appear only after the HTTPS directive.
Disable SSLv2|SSLv3|TLSv1|TLSv1_1|TLSv1_2
Disable the protocol and all lower protocols as well. This is
due to a limitation in OpenSSL, which does not support disabling
a single protocol. For example, Disable TLSv1 would disable
SSLv2, SSLv3 and TLSv1, thus allowing only TLSv1_1 and TLSv1_2.
This directive may appear only after the HTTPS directive.
Ciphers "acceptable:cipher:list"
This is the list of ciphers that will be accepted by the SSL
connection; it is a string in the same format as in OpenSSL
ciphers(1) and SSL_CTX_set_cipher_list(3). This directive may
appear only after the HTTPS directive.
Priority val
The priority of this back-end (between 1 and 9, 5 is default).
Higher priority back-ends will be used more often than lower
priority ones, so you should define higher priorities for more
capable servers.
TimeOut val
Override the global TimeOut value.
ConnTO val
Override the global ConnTO value.
HAport [ address ] port
A port (and optional address) to be used for server function
checks. See below the "High Availability" section for a more
detailed discussion. By default Pound uses the same address as
the back-end server, but you may use a separate address if you
wish. This directive applies only to non Unix-domain servers.
Disabled 0|1
Start Pound with this back-end disabled (1) or enabled (0). If
started as disabled, the back-end can be later enabled with
poundctl (8).
Emergency
The emergency server will be used once all existing back-ends are
"dead". All configuration directives enclosed between Emergency and
End are specific to a single service. The following directives are
available:
Address address
The address that Pound will connect to. This can be a numeric IP
address, or a symbolic host name that must be resolvable at run-
time. If the name cannot be resolved to a valid address, Pound
will assume that it represents the path for a Unix-domain
socket. This is a mandatory parameter.
Port port
The port number that Pound will connect to. This is a mandatory
parameter for non Unix-domain back-ends.
Session
Defines how a service deals with possible HTTP sessions. All configu‐
ration directives enclosed between Session and End are specific to a
single service. Once a sessions is identified, Pound will attempt to
send all requests within that session to the same back-end server.
The following directives are available:
Type IP|BASIC|URL|PARM|COOKIE|HEADER
What kind of sessions are we looking for: IP (the client
address), BASIC (basic authentication), URL (a request parame‐
ter), PARM (a URI parameter), COOKIE (a certain cookie), or
HEADER (a certain request header). This is a mandatory parame‐
ter.
TTL seconds
How long can a session be idle (in seconds). A session that has
been idle for longer than the specified number of seconds will
be discarded. This is a mandatory parameter.
ID "name"
The session identifier. This directive is permitted only for
sessions of type URL (the name of the request parameter we need
to track), COOKIE (the name of the cookie) and HEADER (the
header name).
See below for some examples.
HIGH-AVAILABILITY
Pound attempts to keep track of active back-end servers, and will tem‐
porarily disable servers that do not respond (though not necessarily
dead: an overloaded server that Pound cannot establish a connection to
will be considered dead). However, every Alive seconds, an attempt is
made to connect to the dead servers in case they have become active
again. If this attempt succeeds, connections will be initiated to them
again.
In general it is a good idea to set this time interval as low as is
consistent with your resources in order to benefit from resurected
servers at the earliest possible time. The default value of 30 seconds
is probably a good choice.
The clients that happen upon a dead backend server will just receive a
503 Service Unavailable message.
The HAport parameter specifies an additional port (and optionally an
address) that is used only for viability checks: if this port is speci‐
fied in a BackEnd directive, Pound will attempt periodically (every
Alive seconds) to connect to this port. If the port does not respond
the server is considered dead. It never makes sense to have the HAport
identical to the main back-end port: this would only generate extra,
unncecessary activity (CPU, network traffic) for no good reason whatso‐
ever. The HAport is meant for applications that offer an additional
health monitoring port or for installations that wish to take servers
off-line in a controlled manner.
By default the address of the HAport health monitor is the same as that
of the back-end server. You may specify a different address though, for
example if you have a monitoring program running on another host.
HTTPS HEADERS
If a client browser connects to Pound via HTTPS and if it presents a
client certificate Pound adds the following headers to the request it
issues to the server:
X-SSL-Subject
Details about the certificate owner.
X-SSL-Issuer
Details about the certificate issuer (Certificate Authority).
X-SSL-notBefore
Starting date of certificate validity.
X-SSL-notAfter
Ending date of certificate validity.
X-SSL-serial
Certificate serial number (decimal).
X-SSL-cipher
The cipher currently in use.
X-SSL-certificate
The full client certificate (PEM-format multi-line)
It is the application's responsibility to actually use these headers -
Pound just passes this information without checking it in any way
(except for signature and encryption correctness).
SECURITY
In general, Pound does not read or write to the hard-disk. The excep‐
tions are reading the configuration file and (possibly) the server cer‐
tificate file(s) and error message(s), which are opened read-only on
startup, read, and closed, and the pid file which is opened on start-
up, written to and immediately closed. Following this there is no disk
access whatsoever, so using a RootJail directive is only for extra
security bonus points.
Pound tries to sanitise all HTTP/HTTPS requests: the request itself,
the headers and the contents are checked for conformance to the RFC's
and only valid requests are passed to the back-end servers. This is not
absolutely fool-proof - as the recent Apache problem with chunked
transfers demonstrated. However, given the current standards, this is
the best that can be done - HTTP is an inherently weak protocol.
ADDITIONAL NOTES
Pound uses the system log for messages (default facility LOG_DAEMON).
The format is very similar to other web servers, so that if you want to
use a log tool:
fgrep pound /var/log/messages | your_log_tool
Translating HTTPS to HTTP is an iffy proposition: no client information
is passed to the server itself (certificates, etc) and the backend
server may be misled if it uses absolute URLs. A patch for Zope is
included in the distribution to address this issue - for other Web
servers you are on your own. May the source be with you.
Pound deals with (and sanitizes) HTTP/1.1 requests. Thus even if you
have an HTTP/1.0 server, a single connection to an HTTP/1.1 client is
kept, while the connection to the back-end server is re-opened as nec‐
essary.
Pound attempts to resolve the names of the hosts that appear in various
requests and/or responses. That means it need a functioning resolver
of some kind (be it /etc/hosts, DNS or something else).
EXAMPLES
To translate HTTPS requests to a local HTTP server (assuming your net‐
work address is 123.123.123.123):
ListenHTTPS
Address 1.2.3.4
Port 443
Cert "/etc/pound/server.pem"
Service
BackEnd
Address 127.0.0.1
Port 80
End
End
End
To distribute the HTTP/HTTPS requests to three Web servers, where the
third one is a newer and faster machine:
ListenHTTP
Address 123.123.123.123
Port 80
End
ListenHTTPS
Address 1.2.3.4
Port 443
Cert "/etc/pound/server.pem"
End
Service
BackEnd
Address 192.168.0.10
Port 80
End
BackEnd
Address 192.168.0.11
Port 80
End
BackEnd
Address 192.168.0.12
Port 80
Priority 3
End
End
To separate between image requests and other Web content and send all
requests for a specific URL to a secure server:
ListenHTTP
Address 123.123.123.123
Port 80
End
# Images server(s)
Service
URL ".*.(jpg|gif)"
BackEnd
Address 192.168.0.12
Port 80
End
End
# redirect all requests for /forbidden
Service
Url "/forbidden.*"
Redirect "https://xyzzy.com"
End
# Catch-all server(s)
Service
BackEnd
Address 192.168.0.10
Port 80
End
BackEnd
Address 192.168.0.11
Port 80
End
Session
Type BASIC
TTL 300
End
End
Here is a more complex example: assume your static images (GIF/JPEG)
are to be served from a single back-end 192.168.0.10. In addition,
192.168.0.11 is to do the hosting for www.myserver.com with URL-based
sessions, and 192.168.0.20 (a 1GHz PIII) and 192.168.0.21 (800Mhz
Duron) are for all other requests (cookie-based sessions). The logging
will be done by the back-end servers. The configuration file may look
like this:
User "nobody"
Group "nogroup"
RootJail "/var/pound/jail"
Alive 60
LogLevel 0
# Main listening ports
ListenHTTP
Address 1.2.3.4
Port 80
Client 10
End
ListenHTTPS
Address 1.2.3.4
Port 443
Cert "/etc/pound/pound.pem"
Client 20
End
# Image server
Service
URL ".*.(jpg|gif)"
BackEnd
Address 192.168.0.10
Port 80
End
End
# Virtual host www.myserver.com
Service
URL ".*sessid=.*"
HeadRequire "Host:.*www.myserver.com.*"
BackEnd
Address 192.168.0.11
Port 80
End
Session
Type URL
ID "sessid"
TTL 120
End
End
# Everybody else
Service
BackEnd
Address 192.168.0.20
Port 80
Priority 5
End
BackEnd
Address 192.168.0.21
Port 80
Priority 4
End
Session
Type COOKIE
ID "userid"
TTL 180
End
End
FILES
/var/run/pound.nnn
this is where Pound will attempt to record its process id.
/usr/local/etc/pound.cfg
the default configuration file (the location may be changed when
compiling - see the F_CONF flag in the Makefile).
/usr/local/etc/pound/cert.pem
the certificate file(s) for HTTPS. The location must be defined
in the configuration file - this is only a suggestion. The file
must contain a PEM-encoded certificate, optionally a certificate
chain from a known Certificate Authority to your server certifi‐
cate and a PEM-encoded private key (not password protected). See
OpenSSL(1) for details. This file should be well protected, lest
someone gets your server private key.
AUTHOR
Written by Robert Segall, Apsis GmbH.
REPORTING BUGS
Report bugs to <roseg@apsis.ch>.
COPYRIGHT
Copyright © 2002-2010 Apsis GmbH.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
pound Jan 2010 POUND(8)
[top]
List of man pages available for DragonFly
Copyright (c) for man pages and the logo by the respective OS vendor.
For those who want to learn more, the polarhome community provides shell access and support.
[legal]
[privacy]
[GNU]
[policy]
[cookies]
[netiquette]
[sponsors]
[FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
|
|
Vote for polarhome
|
