File mod_backdoor.txt of Package apache2-debugging-modules

Overview Repositories Revisions Requests Users Attributes Meta

File mod_backdoor.txt of Package apache2-debugging-modules (Revision 5c78204af98e25bee71c8ea1aed263e6)

Currently displaying revision 5c78204af98e25bee71c8ea1aed263e6 , Show latest

The main purpose of mod_backdoor is to provide a relatively
fail-safe way to send requests to the web server when overall
there are serious web server problems.  It is "Plan B" for when
something is wrong with the web server but a request for
mod_status or any test request is not being processed.

Perhaps all your web server threads are blocked waiting on an
application server to respond?  Sneak in through the back door
and get a mod_status report and see if that is the case.  (Check
the URLs and look for 'W' as the state.)

Perhaps something very fundamental, such as an accept mutex,
has broken, and all your web server threads are idle with no
work to do?  Sneak in through the back door and get a mod_status
report and see if that could be the case.  (Check for a
diminishing number of active connections.)

Another purpose of mod_backdoor is for a simple module/core server
debugging environment alongside the processes and threads created
by the normal MPM.  If you send a request through the back door,
there is no question which process/thread will handle it, because
mod_backdoor has only one, and you can have your debugger waiting.
Also, because the mod_backdoor daemon process is not threaded, any
problems your platform has debugging threaded processes will not
be a problem.  And if this system is being actively accessed, it
is helpful that controlling the mod_backdoor daemon process with 
a debugger won't affect threads in the real MPM processes.

PROBLEMS:

1) mod_backdoor can't currently handle a restart of the server;
   if that happens, the daemon will exit, an error message will
   be written to the log, and the back door will be unavailable
2) mod_backdoor uses the last scoreboard slot, even if some other
   thread is using it; to avoid clobbering that last slot, make 
   sure that ThreadsPerChild is less than ThreadLimit or 
   MaxClients/ThreadsPerChild is less than ServerLimit

To compile/install mod_backdoor, perform the following operations:

# apxs -c mod_backdoor.c
# apxs -i mod_backdoor.la

To enable mod_backdoor, add something like the following to your 
conf file:

loadmodule backdoor_module modules/mod_backdoor.so
<IfModule mod_backdoor.c>
BackdoorAddress 127.0.0.1:65535
</IfModule>

Although the controls below are redundant with the BackdoorAddress
shown above, it may be useful as an example.  You could specify 
0.0.0.0:port for BackdoorAddress then use mod_access directives 
to control which clients can use the back door.

<VirtualHost 127.0.0.1:65535>
<location />
order deny,allow
allow from 127.0.0.1
deny from all
</location>
</VirtualHost>

If firewall rules are used to forbid access to the back door,
mod_backdoor will remain useful to permitted clients in more
situations since the back door won't be overrun with requests
that are simply going to be rejected.

It may be useful to disable any complex security (such as 
mechanisms that may hang when external servers are unreachable)
on the back door virtual host (provided you implement alternate 
restrictions) so that the back door can be used to view mod_status
pages and check basic web server operation even when access to
security servers is blocked.

Places

File mod_backdoor.txt of Package apache2-debugging-modules (Revision 5c78204af98e25bee71c8ea1aed263e6)

Places