- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
Looking at Apache 2.0 Alpha 4 Page 2
Now we know what piped logs, both reliable and not, can do for sites running Apache. But what is the difference between the two? Reliable piped logs try to ensure that the log process is always running. It is unusual for a piped log process to die unexpectedly because it is usually a very small program that performs only one function. However, if a log process does die, an Apache installation that takes advantage of reliable piped logs will restart it. Unfortunately, reliable piped logs are not available on all platforms supported by Apache. If Apache does support reliable piped logs on a platform, it will be compiled in by default. To determine if a platform is supported, run Apache with the command line argument -V. This will output all of the options that have been compiled into Apache. Search for the line "-D HAVE_RELIABLE_PIPED_LOG".
The final question is how to configure Apache to use either piped or reliable piped logs. In the configuration file, find the log that should be piped through an external program then simply replace the name of the log file with a command such as:
"| log_program program_arguments"
The "|" tells Apache this will be a piped log and the commands that follow tell Apache what program to use and how to start it. There is one security problem with piped logs that administrators should be aware of: the log program will be run as the user that started the web server. For most servers this is the root user. For this reason, great care must be taken when writing a logging program to ensure that there are no buffer overflows or other weaknesses that can be exploited.
A New Way to Run CGI Scripts & Programs
CGI programs allow sites to run external programs to produce the results for a request. CGI's are used on most sites on the web and are a very common way to produce dynamic data. Apache has always provided support for CGI programs through the mod_cgi module. When a CGI request is received, the child process that accepts that request creates a new process and runs the CGI. The data output from the CGI program is then sent back to the client as the response to the original request. This works fine with Apache 1.3, but it has serious performance implications with Apache 2.0.
On some Unix systems, when a threaded process forks to create a child process, all of the threads are created in the child process and then all but one is killed. This is obviously not very good for performance. When Apache 2.0 is configured to use threaded child processes, this problem is instantly encountered when running CGI's. To solve this performance problem, Apache 2.0 provides two CGI modules. The first is mod_cgi, which should be used either on non-Unix platforms or on Unix with the prefork MPM1. The second is mod_cgid, which should be used for all threaded MPM's on Unix.
Mod_cgid avoids the performance problem by creating a new CGI daemon process. Before any of the child process are started in the parent Apache process, the mod_cgid module creates a new process, which will become the CGI daemon. This process creates a Unix domain socket to communicate with the Apache child processes. When a child process gets a CGI request, it will send the request to the CGI daemon. The CGI daemon will then create a new process to run the CGI program. This process will be set up to communicate directly with the child process that originally received the request. As the CGI process outputs the response, it will be sent to the child process, which forwards it along to the client. Because the CGI daemon process is a single threaded process, Apache can avoid the performance problems that the original mod_cgi causes.