Topic: Troubles getting started with Apache24+fcgd and mod_perl

[ted.byers]

I have been using Apache's httpd for quite a while, but now I am working on making some of my scripts faster. I am interested in mod_perl, and FastCGI (for which I understand the mod_fcgid is Apache's FastCGI module - or have I misunderstood because of the confusion among the various resources I found on the web?). Anyway, as I am working on 64 bit windows (Windows 7 on my workstation and Windows Server 2008 on the server), I downloaded the 64 bit build of Apache's httpd server (with the latest version of openssl), along with the various 64 bit builds of the modules I am interested in including mod_fcgid.

I could not find a 64 bit build of mod_perl. Is there one? If not, is it hard to build (I have the enterprise edition of MS VS 2010).

I followed the instructions I found in the text files in the modules I downloaded, copying the module binaries to the modules subdirectory and making the changes specified in httpd.conf. The server started fine, but the scripts do not run.

At the end of the section loads a few modules, I added the following:

[glsmith]

mod_fcgid doesn't handle perl scripts on windows. No one has figured out why not yet.

mod_perl last I looked was not building on Apache 2.4 yet, it's been in the process, I just haven't checked in for awhile to see where they are with that.

This
[Thu Jan 03 16:30:01.859347 2013] [ssl:warn] [pid 9376:tid 508] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache]
Is as the hint suggests, you need to configure SSLSessionCache

[Thu Jan 03 16:30:32.394225 2013] [mpm_winnt:warn] [pid 11900:tid 1116] (OS 64)The specified network name is no longer available. : AH00341: winnt_accept: Asynchronous AcceptEx failed.
This annoying one is the AcceptFilter. To fix in httpd.conf in global context;
AcceptFilter http none
AcceptFilter https none


I have mod_fastcgi built for Apache 2.4 in both x86 & x64 ... I'll find and post a link to them soon. I can get a script similar to that working with mod_fastcgi.

[ted.byers]

Thanks. I appreciate it.

I look forward to seeing the links to your 64 bit build of FastCGI. When you post it, would you also mind posting the relevant entries in httpd.conf?

Thanks,

Ted

[glsmith]

https://www.apachehaus.net/modules/mod_fastcgi/

One thing I found out again (when testing the x64 module) is, the CGI::Fast in ActivePerl requires the FCGI package, which is not included in the install. It must be loaded from the Package Manager.

[ted.byers]

Thank you for this. I am almost there, I think.

One problem remains, as far as I know.

I have copied your .so file to my modules directory, and load it right at the end of the section where all other modules are loaded. And, I have the following cgi-bin and fastcgi-bin directory entries. I do not understand why they aren't working.

# the following is identical to the configuration of the same path on another server where all my CGI scripts work (some of which I want to refactor to run using FastCGI).
<Directory "c:/Apache24/cgi-bin">
AllowOverride None
Options None
Require all granted
</Directory>

#the following is new, based on my guesses as to what may be needed, in turn based on my reading of the directory specifications documentation
<Directory "c:/Apache24/fastcgi-bin">
SetHandler fastcgid-script
Options +ExecCGI
Order allow,deny
Allow from all
</Directory>

c:/Apache24/fastcgi-bin is a directory I added, and where I was planning to put my fastcgi scripts. Alas, on this new server, where I am testing FastCGI before I deploy to the other server, I get a 403 error: Access denied. Here is the entry from the error log:

[Sun Jan 06 16:56:20.040471 2013] [fastcgi:notice] [pid 12172:tid 576] FastCGI: process manager initialized
[Sun Jan 06 16:57:21.704801 2013] [authz_core:error] [pid 12172:tid 1108] [client ::1:41963] AH01630: client denied by server configuration: C:/Apache24/fastcgi-bin/fcgitest.fcgi

The cgi problem is different. Instead of executing the printenv.pl script as a CGI script, the workstation opens a Windows commandline terminal, and executes the script there, getting the same output I'd get if I executed the script from the commandline.

In both cases, I must have missed something, but I do not yet know what. In the case of the FastCGI directory configuration, I must have missed something related to permissions, and in the case of CGI I must have missed something that would tell the server that anything in the cgi-bin directory is supposed to be executed as a CGI script by either Perl or PHP (both of which are in my system's path). mod_cgi IS loaded on both machines.

In the alias_module section, I have the following:

ScriptAlias /cgi-bin/ "c:/Apache24/cgi-bin/"
ScriptAlias /fcgi-bin/ "c:/Apache24/fcgi-bin/"
ScriptAlias /fastcgi-bin/ "c:/Apache24/fastcgi-bin/"

What am I likely to have missed?

Thanks

Ted

[glsmith]

Well, I don't know. I never use ScriptAlias as I like a separate cgi-bin directory per vhost.

One thing I do see,

# 2.4 style
Require all granted

#2.2 style
Order allow,deny
Allow from all

Even if you are using mod_access_compat, I've found I can not use both styles in the config, one or the other will win and the looser 403s which is usually the least used style. So that might explain the 403. Use 2.4 style throughout. There becomes no need to load mod_access_compat then either (if you have it loaded).

That in itself might be mucking up the other.

[ted.byers]

Thanks.

I can see your logic for using a separate cgi-bin directory for each vhost, but that is something I don't have to worry about as I do not have multiple vhosts on this serveer, and where I do, the intent is to use the domain name that applies to the vhost to identify the 'site' the user visited so distinct branding can readily be applied to the same codebase. That is, in my rare cases where it is useful to have multiple vhosts, the htdocs and cgi-bin directories are shared, and the only diference the user would see in visiting the one or the other is in the branding (logo and colour scheme), and of course the data displayed (which is determined from the user's credentials.

Switching the permissions to be entirely 2.4 style solved the 403 error problem. Now, though, the server displays the content of the fastcgi script rather than executing it. This behaviour is similar to what I am getting with my cgi scripts, except with the latter, I am prompted for a decision whether to open or save the file, and selecting open runs it in a windows terminal. In both cases, the server is failing to execute the script.

The configuration for that directory is now:


<Directory "c:/Apache24/fastcgi-bin">
SetHandler fastcgid-script
Options +ExecCGI
Require all granted
</Directory>

BTW: I checked mod_access_compat because you mentioned it, and it is being loaded.

I have both server-info and server-status loaded, and can show their content, if that would be useful, but their output is rather long, so I wouldn't want to display it all unless it would be useful, as that would waste space and possibly be distracting.

Thanks

Ted

[glsmith]

[ted.byers]

Thanks.

Correcting that copy/paste error in my conf file now has FastCGI working. Thanks loads. At least now I can run some tests to see which of my current cgi scripts will benefit the most by being refactored to run as a FastCGI script.

Alas, my cgi-bin directory is configured in the same way that yours is configured (and, in fact, the same way that another server I work with is configured), but instead of executing the cgi scripts on this server, it prompts me to open or save the file. I do not understand this. How can my other server, and your server, have the cgi scripts executed, and display the results of that execution, but on this server it just sends the file to be opened or saved locally, when their respective cgi-bin directories are identically configured?

Thanks again.

Ted

[glsmith]

I have no idea, but what happens if you add SetHandler cgi-script to the cgi-bin <Directory> container?

[ted.byers]

Nothing changes if I add the SetHandler statement.

[ted.byers]

Here is a report of an experiment I just completed. I expanded the httpd-2.4.3-win64.zip archive into a new directory, and changed nothing, except for the paths to reflect the location of this new directory. In this directory tree, there are no additional modules and the configuration is unchanged except for the paths.

The result, pages in the htdocs are displayed as expected, but printenv.pl in cgi-bin is not executed. Rather, the prompt to either open or save client side is displayed.

Is there a chance that the contents of this archive are broken in a way that breaks cgi-bin?

Tomorrow, I will create an archive of the Apache directory tree on my other server, and download it and install it on my workstation and see if it works right here. If it does, I will install FastCGI to the local copy and see how well that works.

Thanks

Ted