FastCGI: Persistent Applications for Your Web Server
Unless you know you need to recompile the Perl binary, you can skip down to the “Compiling FCGI.pm” section. If, however, you do need to recompile Perl, it's helpful to know a few things.
To begin the Perl compilation process, unpack and build sfio; the README will tell how. You'll also have to update your $PATH to include one of the newly created subdirectories; this is somewhat unusual, but required.
Second, build, test and install Perl. It can take awhile to work through Larry Wall's Configure script, but there are a few items for which you should not choose the default answer:
To the question “Directories to use for library searches”, answer $* $sfio/lib (where $sfio is the directory in which you unpacked sfio). The default answer to the next question, “Any additional libraries?”, should now include -lsfio.
To the question “Any additional cc flags?”, answer $* -I$sfio/include.
To the question “Any additional ld flags (not including libraries)?”, answer $* -L$sfio/lib.
To the question “Use the experimental PerlIO abstraction layer?” answer yes.
To the question “perl5 can use the sfio library, but it is experimental. You seem to have sfio available, do you want to try using it?”, answer yes.
I've never had trouble re-compiling Perl in this way, but the fastcgi-developers mailing list archive (available from http://www.findmail.com/list/fastcgi-developers/) has plenty of messages from people who have. A fairly complete set of directions for recompiling Perl with sfio can be found at http://fastcgi.idle.com/fcgi2.0b2.1/doc/fcgi-perl.htm.
Regardless of whether you had to recompile Perl, you'll need to unpack, build, test and install FCGI.pm according to the instructions provided with the source code. You can be fairly sure you're on the right track if FCGI.pm passes make test.
Before dealing with the Apache distribution, unpack the mod_fastcgi source code. Read the INSTALL file, which details the two ways to configure, compile, and install Apache. The first, the Apache Autoconf-style Interface (APACI), is new to version 1.3. The second is the tried-and-true manual configuration we all know and love. Then unpack Apache's source code and configure it for the FastCGI interface:
Copy or move the mod_fastcgi distribution directory to <apache_dir>/src/modules/fastcgi.
Configure Apache using either APACI or the manual method as detailed in the mod_fastcgi INSTALL file. I'm pretty accustomed to dealing with the Configuration file, so I usually do it the old way.
If you're using Apache 1.2.x or 1.3.x and you're not running out of RAM, try uncommenting the line containing mod_rewrite. This is a tremendous extension to Apache that allows it to parse incoming URLs as regular expressions. See the sidebar, “Health and Beauty the Rewrite Way”, for my line of reasoning in this regard.
Apache gets all of its runtime directives from three files found in $apache/conf: access.conf, httpd.conf and srm.conf. Following the suggestion given by Ben and Peter Laurie in Apache: the Definitive Guide, I put all directives in httpd.conf and don't use the other two files. If you use all three files, the configuration changes will occur in srm.conf.
Before doing any configuration, you'll need to read the documentation included with the mod_fastcgi source code. The docs/mod_fastcgi.html document is somewhat dated, but still very useful for getting you started. No author is listed, but I'd gladly buy him or her a beer for putting together a truly excellent resource, and thereby making my job much simpler.
Let me also say that you should have more than a passing familiarity with httpd.conf before altering it. Take a good look at the documentation that comes with the source code or buy yourself a copy of the Lauries' book.
The FastCGI configuration directives (see sidebar “Configuring Apache for FastCGI”) allow you to accomplish two essential tasks.
First, define the local pathway to the FastCGI applications using the AppClass directive and/or the remote connection host and port number via ExternalAppClass. AppClass is responsible for starting and managing processes that run locally.
Second, associate your FastCGI applications with the proper handler or MIME type so that dealings with these files are handled by mod_fastcgi. Associate the handler “fastcgi-script” with a file or files based on location (SetHandler) or file extension (AddHandler). Alternately, you can associate the MIME type
with a file or files based on location (ForceType) or file extension (AddType).
Note that your FastCGI applications cannot go into the normal CGI directory specified by ScriptAlias. Apache's way of assigning priorities leads it to attempt to handle any and all files in the CGI directory with the standard CGI module, which won't work with FastCGI applications.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- LiveCode Ltd.'s LiveCode
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide