Faster Web Applications with SCGI

Speed up your Web applications with SCGI.
Installing SCGI

You need two components: the Python classes for building SCGI applications and a module for your Web server to make it “speak SCGI” to the applications. If you use Red Hat package management (RPM), you can install these using yum install python-scgi apache2-mod_scgi; users of Debian's apt can use apt-get install python-scgi libapache2-mod-scgi.

You also can install either component by hand. The Apache module requires a C compiler and Apache's apxs script. Some distributions keep apxs in a separate development package rather than installing it as part of the regular Apache package.

Assuming you now have those components, next download the source tarball scgi-1.12.tar.gz, and run the commands shown in Listing 1.

Test Run

Now, let's make sure it all works. The Python package is a module with some classes, and normally, you'd write your application as a program that imports that module. For debugging, however, you also can run it as a standalone application. When it receives a request from the Web server, it simply prints the request's details as a text page. Perfect for a first test—no coding required!

Find the scgi_server.py module on your system. It should be installed in /usr/lib/python2.4/site-packages/scgi (the 2.4 may be 2.3 or 2.5 on your system). Then, run the module:

cd /usr/lib/python2.4/site-packages/scgi
python scgi_server.py

This listens for requests from the Web server on a TCP port on your system, using port 4000 by default. You can make it listen on a different port by passing the desired port number as a command-line argument, such as:

python /usr/lib/python2.4/site-packages/scgi/scgi_server.py 63000

The module keeps running until you kill it, so start it in a separate shell. Remember, you don't need to run an SCGI server as root or even under the Web server's identity.

Now that the SCGI application is waiting for requests, pick a location on your Web site to delegate to the application. Let's say you want it to answer all requests for “/scgitest” on this server. Write an Apache configuration snippet, as shown in Listing 2, to a new file in /etc/apache2/conf.d.

The SCGI server doesn't really need to run on the same machine as the Web server, as you can see here. Simply make sure that the SCGI server's port is properly firewalled, so that only your Web server can reach it! That way, your application can be sure that all CGI parameters have been validated by the Web server first. If an attacker could connect directly to your SCGI application, you wouldn't be able to trust that information. The CGI parameter AUTHENTICATED_USER, for instance, tells your application that the request comes from a particular logged-in user. You can believe that only if you hear it from a properly configured Web server.

Make Apache reload its configuration with sudo /etc/init.d/apache2 reload. Your server should now serve a new location, /scgitest, that simply prints your request's CGI parameters when you access it. Verify this by looking it up in a browser. If your server's address is example.org, point your browser at http://example.org/scgitest. You should see a page that looks like Listing 3.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix