Item1315: FastCGIEngineContrib needs more docco
for starters, there is no info telling the admin how to confirm that their requests are indeed using fastcgi.
next up, "We assume the webserver is configured to recognize files with .fcgi extension to be FastCGI scripts" is pretty useless, especially as telling the admin how to confirm or set it would take about the same length sentence. (and appears to be untrue too...)
I get the feeling that using mod_actions and not having fastcgi configured will result in a perfectly functional cgi setup - but how will the admin (especially the majority that have trouble with apache to begin with) know.
need to point to a set of howtos on how to confirm mod_fastcgi is installed & how to install it - turns out centos doesn't have it in rpmforge - its a trivial set of step to make happen, but
also, given the overload of choices, there needs to be clear reasons for choosing one or the other - if a user has to use .htacces, by choose mod_rewite / mod_action etc. similarly for mod_fastcgi and mod_fcgid.
I'm sure i'll think of more - hope i record them
interesting. using the mod_action setup, I get rendered topics, but i'm not sure if its actually working. with the mod_rewrite, I just get a 500 error, with nothing in the error.log file - and I can't see anything in the doc telling me where to go next.
gee, what a naf top i'm using - mod-action spawns 'view' scripts, mod_rewrite spawns 'perl's
and now that I've used the non-htaccess setup, I'm not sure that either of the htaccess settings worked - the docco needs a way for the admin to know
- I would suggest that there is a context
or something (and similarly for the other engines)
doesn't mention howto restart the fastcgi-processes, just that there might be a problem - really need something more deterministic.
- on testing further "e.g. if you're using 3 processes, the next 3 requests after the update will not be affected. The update will take effect on the requests made after the initial 3)" is not true. so more instructions and some indicator is needed. (looks like it took 6-7 requests before it noticed the changed code, and in another case - pseudo-installed link, it never noticed.)
- and then, if you're developing and bounce them too fast, you get "" has failed to remain running for 30 seconds given 3 attempts, its restart interval has been backed off to 600 seconds" :/
- 18 Mar 2009
The "We assume the webserver is configured to recognize files with .fcgi extension to be FastCGI scripts" statement is true in many shared hosting environments. If you have access to httpd.conf, then you have to setup this, but if you have such access then It's better to use
On the "How can I check if it's installed and working?" question, I totally agree and it's pretty easy to solve
On the "How to install fastcgi on environment X"... well, I assume that upstream fastcgi sites are in charge of that. But I can add some links, like the one you provided
On the mod_fastcgi vs mod_fcgid I just prefer mod_fastcgi because it supports external servers and mod_fcgid implementation of dynamic servers is strange (this is almost all I can tell from the experiments I did). But I agree: some background is needed. I'll search something about
On the "how to start fastcgi processes" what I can say is: kill all of them and the webserver will spawn brand new ones, or you can restart the whole webserver... the info about how long it takes to the auto-restart feature to work is only about changes in
. Code changes are unnoticed
. And that number is from the tests I did with my machine (probably it depends if you're using mod_fastcgi or mod_fcgid and what version...).
- 13 Apr 2009
Having been on a wild good chase, (a goose which is still loose). I would like to make some observations which may help in improving the documentation.
Note that I have to date failed to get even a very simple perl script working using fastcgi on my Windows XP Pro machine at home. The story below will explain the maze I have been working thru and the dead-ends I have come up against.
One issue is the necessary user requirements to be able to install this engine
- Server access rights
- Level of knowledge
- Tools available/willing to use
- Time available
As I'm installing this on my own PC, there are no access problems I have full admin rights. There may be access rights I have not set-up properly, but nothing I have read indicates that this an issue under Windows (or at least following standard procedures nothing needs to be done).
My level of knoweldge is mixed, my primary experience is as programmer on mainframes including systems programming and I have written extensively in C and assembler. I have also done work on ARM based machines in C and assembler. I have also worked to some degree on Windows and Linux, but my knowledge is more limited. From the mainframe perspective, I have been the guy to come to at the end of the support chain, because I will get to the root cause and (given the time) fix the problem - somehow!
This mixture of knowledge could well be part of the problem, I'm almost certainly making assumptions that are just wrong, of course I do not know which ones are wrong yet!
I'm working on Windows baceause that's what my company will support, indeed the position has relaxed to allow Apache rather than IIS.
Installing the basic Foswiki via the
was of course a doddle, and very low user requirements. The effort not only into
, and to a degree the docs made this so. Well done to all concerned.
Installing various plug-ins was also easy via configure, even those that required installing separate binaries (graphviz and HTML2PDF).
Then we come to FastCGI
, OK it's a brave new (eventually fast) world, and some extra work is expected, but what exactly does that entail and how much time is involved?
I initially plumped for mod_fcgid. Why did I do this? Did I prefer the ease of configuration? Greater future flexibility? None of those, simply that when I went looking on the web I found
on www.apachelounge.com. This was easy simply snuggled inside a zip file and it wasn't very hard to copy that into the apache modules folder, this may have been a mistake, but it looked right and my first priority was a fast Foswiki. Secondary was which of the two was best, that's a project for another day. To reinforce this choice, I could not find
anywhere - at least not ready to run, more about
, so I've installed this, but nothing works. I raise a Support.Question198 and try out the reply, still no success. I realise that I did not install
perl module from CPAN - DOH! I decide to try a small FCGI perl program - to eliminate unecessary details. Still no sucess. (I notice here that the Apache config generator and the FastCGI support page both provide config generators - shouldn't there be just one?)
At this point I starting to search the web for answers, what do I find?
- Mixed references to
- References to
- References to
- Lots of alternative apache configurations (granted often not perl, but fastcgi and apache and anyway I'm looking for clues)
- References to compile options and dll manifests
- I was avoiding having to compile anything
- How long would it take to install the relevant toolset(s)?
- Would this not raise a plethora of other support questions?
- The comments I saw related to a version of VC++ I did not have (I have Vis Studio 2003)
- Mixed compilers and run times could be the cause
- Compiling myself without upgrading may well excerbate this problem
- Apachelounge was reassuring in that it used the same (up to date) compiler for
mod_fcgid.so as used by the latest build of apache.) (Q to self, the Foswiki
msi of apache was sourced from where? Was this built using the same toolset as
- Full access to server
- Good technical experience but with key gaps
- Not really looking to compile etc on Windows
- Time available, not enough to dig that deep - I need to install a fast Foswiki fast
- I would immensely enjoy getting into the intricacies of all this, but that's another project
In the above it's worth pointing out Windows as the target - on linux I would simply have tried the commands to compile etc expecting them to be pre-loaded.
It is still not clear to me whether or not
, although I strongly suspect
of being a support library for writing in C/C++ in the same way as
is for perl. However,
has the right sort of name, plus when searching for info certainly brings up windows references. The questions are:
- Is this
dll just a red herring and not at all relevant?
- If required, is it used in conjunction with or stand alone from
mod_fgcid.so=/=mod_fastcgi.so? I suspect the former, but I really do not know?
recently, however I could not find it ready to go. Lot's of searches came up with comments like simply copy
into the apache modules directory. The author's know what they mean by 'copy', it's all too obvious. I suspect it means grab the source, use the provided makefiles or MS Studio projects and build it yourself - but again, maybe I did not find the right web-site for this. The www.fastcgi.com website does provide access to directories with the
ready to run but not a
. The page which purports to provide Install instructions appears to have a heading followed by an empty section followed by a heading with details of one known install problem. The empty install section was not particularly helpful :-;.
In general, my impression of the fastcgi related sites out there was that some very good work has been done, but some web-sites needed some refactoring and missing details provided. Part of the 'problem' appeared to me to be that the work is stable - not much call for enhancements or bug-fixing.
I appreciate that you are not responsible for the myriads of other web-sites with various FastCGI
comments out there. Nor do you want to create a complete treatise here on FastCGI
and how to install all the various bits. However, some general guidelines with some clear do's and dont's and red-herrings eliminated would be great.
I apologise if the above sounds like a rant - I really love this software and it helps us quite a bit already. I also see even greater ways it can help us going forward (especially if faster). However, the frustration gave me the energy to write all the above which I hope will help.
- 16 Aug 2009
Sorry again for the delay. I tried a lot today to make FastCGIEngineContrib work on Windows XP, unsuccessfully. After many tries (I reproduced your steps and got the same errors... tried both
) I used the Dependency Walker
software and realized that both
(provided by apache) and it depends on
. None of these two are available on XP. After a quick google search I suspect those dlls are available only on Vista/server 2003/Server 2008.
I got FastCGIEngineContrib working on 2k3 a long time ago, but I can't test it again now.
If I get enough time, I'll perform more tests and try FastCGI on Win2k3.
Thanks for your time on this and congratulations by the rich
- 18 Aug 2009
I finally have mod_fastcgi working on Windows XP/Apache.
The key reference is here:
The specific problem is that the 'stable' 2.4.6 does not work for Win32. The snapshot binary
provided within this link (which is an
like 2.4.6) makes all the difference. The configuration as generated by foswiki's Apache config generator seems to be correct as-is.
Note that the hacking around process to attempt both fastcgi flavours may mean something else is required. Nonetheless, I am fairly confident that this snapshot (2.4.7 according to notes) mod_fastcgi is the solution in and of itself.
The author of this article states that he was unable to get mod_fcgid working on Win32. For me any FastCGI will do. I need to support 100 users or so and I do not need to manage my fastcgi server pool as tightly as others. I assume server management issues are the main pros/cons between the two flavours. That's an area I have no knowledge about.
From a Foswiki perspective it may be important to establish a stable place from which to download a Win32 binary
of mod_fastcgi as above. Not everyone on Windows will be looking to compile the sources from fastcgi.com themselves.
- 07 Sep 2009
Remind Note: Add instructions about how to install
. (See Support/Question368
- 28 Dec 2009
This has been stalled for a year and it is not specific.
And at the same time others have added a lot of documentation about installation incl myself. I am closing this
- 26 Oct 2010
and i am reopening it because many of the valuable suggestions sven started this topic with have not been realized as documentation. and, i have some documentation fixes to check in. i am closing Item6087
- 27 Oct 2010