Item1283: Foswiki:Support.ApacheConfigGenerator fails to generate a ScriptAlias line

The Foswiki:Support.ApacheConfigGenerator generated only an Alias line when it should have generated a ScriptAlias. Threw me for a bit of a loop.

-- JohnKern - 14 Mar 2009

It is Gilmar that keeps on changing the ScriptAlias to Alias and I keep on reverting it.

Stop it Gilmar! Naughtly boy.

It does not work for all of us. I also have trouble with it.

ScriptAlias works. And we have used that for years. Well proven method.

-- KennethLavrsen - 14 Mar 2009

According to apache docs:

The ScriptAlias directive has the same behavior as the Alias directive, except that in addition it marks the target directory as containing CGI scripts that will be processed by mod_cgi's cgi-script handler. URLs with a case-sensitive (%-decoded) path beginning with URL-path will be mapped to scripts beginning with the second argument, which is a full pathname in the local filesystem.

A request for http://myserver/cgi-bin/foo would cause the server to run the script /web/cgi-bin/foo. This configuration is essentially equivalent to:

Alias /cgi-bin/ /web/cgi-bin/
<Location /cgi-bin>
SetHandler cgi-script
Options +ExecCGI
</Location>

So, these settings are exactly the same:

ScriptAlias /bin /var/www/foswiki/bin

and

Alias /bin /var/www/foswiki/bin

<Directory /var/www/foswiki/bin>
    SetHandler cgi-script
    Options +ExecCGI
</Directory>

Please, notice that the generated config does have the SetHandler and Options, so it works correctly (regardless the runtime engine chosen). The problem with ScriptAlias is that it is CGI-specific.

I really don't know why the generated config (without ScriptAlias) always worked for me (with both Apache 1.3 and 2.x) and not for others. Probably not all the generated config is used, specially the SetHandler and Options directives.

Anyway, I'll not change that topic again. Probably I'll include a generator in each runtime engine contrib.

-- GilmarSantosJr - 14 Mar 2009

If at all possible, I believe it would be better to continue to have a single Apache config generator topic, to reduce potential confusion among admin users (they would have to know which config generator to use given their specific deployment environment). -- IsaacLin - 14 Mar 2009

There is a pretty simple solution to this issue - each engine type's stuff goes into a (or set of, for re-use) hidden STARTSECTION{"engine-type"} block, and users start the apache cfg by selecting which engine.

Please use the power of Foswiki

-- SvenDowideit - 15 Mar 2009

FWIW, I do observe that the line that made it into my .conf file was:

    
   Options ExecCGI FollowSymLinks

instead of what you say works:

    
   Options +ExecCGI 

-- JohnKern - 16 Mar 2009

The FollowSymlinks is needed in at least two cases

• You are a Foswiki developer using the pseudo-install script to symlink extensions to the core.
• You have your data and pub directories outside the Foswiki tree and symlink webs. I do this myself so I can run multiple versions of Foswiki. At the moment at work I have both a TWiki 4.2.2 and a Foswiki 1.0.X beta running in parallel (with different URLs) so that in the transition phase people can fall back if we run into a nasty new bug. This is also useful if you want to help the community testing beta versions before a new release.

With respect to ScriptAlias vs Alias. I cannot tell why some people have problems but several have reported problems.

Using the already existing conditions the ApacheConfigGenerator can be changed so the Alias is used for non-CGI and the ScriptAlias is used with CGI.

At one point of time our ApacheConfigGenerator becomes a true horror of IF and MAYBE and then it may be better to split up in 2 or 3 different topics and replace current ApacheConfigGenerator by an index topic. But if someone does that one day remember that YOU are a geek (who ever you are) and your target group contains people that are not. So please explain carefully which way to go if you are just a plain normal beginner setting up a Foswiki for the first time (standard CGI - no fancy stuff).

I personally think the generator is getting too smart for its own good now.

-- KennethLavrsen - 16 Mar 2009

Hi JohnKern, apache documentation states that when you prefix an option with a +, then you're adding that option to the existing set. If you don't, then you replace the set by that ones you're specifying. Maybe the FollowSymLinks is a must in your environment. Please test with: Options +ExecCGI +FollowSymLinks and with Options ExecCGI. I expect the first to work and the second to not work.

Which apache version are you using? Which Operating System and version? (If linux, which distro and version?)

Kenneth, I missed the several reports about ScriptAlias and I'm afraid there were another errors in each case... maybe people didn't adjust Options correctly or maybe they are using buggy apache versions

I just changed ApacheConfigGenerator, so it generates ScriptAlias for CGI and Alias for other engines.

-- GilmarSantosJr - 16 Mar 2009

I have one foswiki on Windows Apache2.2.6 running with Strawberry perl (as downloaded v1.0.0.2) which needed ScriptAlias to run. I have another running on the same computer and Apache, but with cygwin which has ScriptAlias (probably because foswiki_httpd_conf.txt did.) I expect I will be dropping the Strawberry version partially because I'm making progress with the cygwin. I may try it again in a rev or two while upgrading from my remaining TWiki. They are both in production so I don't quite have a good testing environment yet.

-- JohnKern - 17 Mar 2009

Thanks for your feedback, John!

I'll test Apache 2.2.6 on Windows (are you using 2003? 2008? XP? Vista?), but I could make foswiki run with:

Alias /bin "C:/Foswiki/bin"
Alias /pub "C:/Foswiki/pub"
<Directory "C:/Foswiki/bin">
    Options ExecCGI
    SetHandler cgi-script
</Directory>

I used Apache 2.2.11 and both ActiveState and Strawberry perl (5.10.0) on Windows 2003.

-- GilmarSantosJr - 17 Mar 2009