As I was making the jump from v1.6 to v1.9.1, and having to redo all of
my patches against pound, I figured it better for me to post these for
the benefit of others, and additionally so that some (hopefully) could
be incorporated into the mainstream so I wouldn't have to keep my own
changes.
So, here they are, use as you wish, YMMV, yadda yadda.
I didn't muck around in the configure script at all, so some of the
patches will kludge this by adding libs to Makefile.in, or defines there
as well. If included in the main codebase those would obviously need to
be fixed by someone who can read configure files; it just hurts my head
too much.
The patches are at:
https://mgmt.k12system.com/~mrwizard/pound/
They need to be applied in order, since that's how I built them. Here
they are in order:
pound-1.9.1-nodaemon.patch.gz
Provides a configuration directive called NoDaemon, which makes
the daemon stay in the foreground instead of forking. Also, added a
setsid() call, so regardless, it disassociates from the parent process.
(might not be portable)
I find it useful, especially when I want to run a pound instance
(with one config) as a daemon, and another via supervise (daemontools)
in the foreground.
pound-1.9.1-linuxcaps.patch.gz
Trivial patch to pound.c, so that after setuid()'s and
setgid()'s happen, the capabilities set of the process is explicitly set
to empty. This is the default for non-root users, but if you've enabled
a true POSIX capability model (re: http://killa.net/infosec/caps/) then
pound will end up with a full inheritable set, which means if, by some
magic of setuid executables, or something, that the uid gets back to 0,
full capabilities will be reinstated.
By dropping the inheritable set with a properly modified init or
kernel, even if the UID somehow returns to 0, there will be no process
capabilities. (well, actually those in cap-bound, which in my case, is
nothing)
It shouldn't break anything, it's in a define (which is on by
default and not configure'd) and it's likely Linux specific.
pound-1.9.1-sessioninfo_statistics_and_logging.patch.gz
This one adds a couple items to Group and Session structures.
It'll track how many requests hit each backend, each group, etc. It'll
track hits/misses against the session database as well, so you can track
new requests vs. returning requests. It also allows you to assign a
GroupName to each group, and institutes loglevel 5 which populates the
user entry of the CLF and adds the groupname and backend information in
two preceeding fields. I think it also lays the groundwork for the
later authtypes patch, but degrades gracefully.
Starting to get a little more radical.... :)
pound-1.9.1-authtypes.patch.gz
Adds support for different AuthTypes so that when a request
comes in that is authenticated, it can track that user in the session
state and in the logfiles. I've implemented HTTP Basic Auth and
Coldfusion <cflogin> style authorization, so that log files can track
user names of sessions passing through pound.
pound-1.9.1-redirects.patch.gz
This allows redirects to be properly rewritten even if no Host:
directive is passed on the request line. (in which case it will use the
IP) It also handles pound running on non-standard ports... It'll
redirect correctly. Works well with RewriteRedirect 2, but does include
functionality not included in RewriteRedirect 2.
Should apply without any of the others.
pound-1.9.1-listenstatus.patch.gz
Most radical patch. This allows you to define status sockets,
in addition to http and https sockets. You can define a HTTP or Text
socket. The text socket will dump out the existing groups, sessions,
and backends with status information, alive information, etc. It really
helps to be able to see what sessions are active now, and whether or not
a backend is currently flagged as dead or alive.
The HTTP one looks a lot prettier. It'll wait for a client
request but it throws the data in the bitbucket and returns a static
page. If you don't like my CSS, change it. :-P
Eventually I'd like to be able to send commands to pound... My current
brainstorm is the ability to disable a backend from new sessions, but
allow existing sessions to complete. (Until they timeout) That way, if
I have an issue with a server where I know I'm going to need a reboot,
and conditions will be degraded until I can, I can just disable new
connections and when they all expire, reboot the server. Then, I can
set the backend to receive connections again.
It's a long term idea. Not for now. Peruse, discuss, give me feedback,
and I'd love to see some (or all) of this appear in the mainstream code.
Thanks!
Joe Gooch
K12 Systems, Inc.
|
