Can Caddy be used with Redmine via FastCGI? (not yet, but there's a workaround)

I’m trying to get Redmine working with Caddy.

The first approach - which works - is to run Ruby’s “WebRick” test server on some port, and then have Caddy proxy to that. This is what I’m doing now - with Redmine started manually that way. It runs fine, although Webrick is grabbing more and more RAM (over 1.5 GB by now).

But the recommended way is to run things via FastCGI. Redmine offers a Ruby script for this, called “dispatch.fcgi”.

FWIW, I already have php7.0-fpm set up and in use for another site, also behind Caddy, running on port 9000.

And that’s where I’m getting stuck. If I set up fastcgi on Caddy for the Redmine site, I assume it has to point to another instance of fastcgi on another port? If I point it to port 9000, then it’ll complain with “Access denied” when I use dispatch.fcgi as rewrite rule for everything. If I add “.fcgi” as allowed suffix in fpm’s www.conf, alongside the default .php, then I get the dispatch.fcgi served as plain text, instead of it being launched to set up an fcgi process.

My question - I think - is: how does Caddy’s fastcgi “endpoint” parameter tie into Redmine’s dispatch.fcgi script? Who should launch that? If I launch dispatch.fcgi manually, it sits there, waiting for commands on its stdin.

Confused’ly yours,

Looks like you might want cgi. You can use it to point to a script file, as opposed of fastcgi which points to a server port or unix socket.

Thanks for the tip - but wouldn’t that launch the script on every request? The dispatch.fcgi code is intended to be launched once and then accepts successive requests, IIUC.

PS. I’ve also posted on Redmine’s forum, just now.

I believe it will launch the script every time, yes.

What does that script listen to after launching? Does it bind to a port at all?

Unfortunately, there’s no new listening port opened in netstat when I run dispatch.fcgi manually.

For lack of a better solution, I’ll continue to run Redmine as server with Caddy as proxy to it, and restart it periodically to keep its RAM use in check:

0 3 * * * /usr/sbin/service redmine restart

It’s a hack, but hey … it kinda-sorta-works.

For a better solution, you could run Redmine under Thin and proxy to it:

Most of the information I found on doing this is pretty sparse and from 2011/2012, so this might not work for new versions of Redmine. However, it’s probably worth trying.

OK, so going over it again, their Apache example uses Options ExecCGI and here’s their example .htaccess. It’s rewriting requests other than index.html or {uri}.html directly to dispatch.fcgi, and it’s flagged that file to be executed as a script on request.

It’s really looking more and more to me like dispatch.fcgi is run every time it’s requested, especially because I can’t really see how the rails app is expected to listen to continued requests if not via port or socket and I’m not seeing that behaviour anywhere in the Apache config.

An essentially direct equivalent of their Apache config (i.e. Options +ExecCGI, plus AddHandler for the .fcgi ext, plus the included rewrite) is this untested Caddyfile: {
  cgi *.fcgi {match}.fcgi
  rewrite {
    to {path} {path}.html {path}/ /dispatch.fcgi

Hm… isn’t FastCGI supposed to be CGI-without-the-per-request-process-launches? I’m clueless how, but my guess would that the .fcgi triggers some kind of keeping-the-session open mechanism… somewhere.

It would probably help to get advice from someone more familiar with Redmine or RoR, but I haven’t received an answer on the Redmine forum yet. The restart workaround appears to be working, I’m hesitant to change that server setup a.t.m.

(with apologies for the late reply)

I don’t know Ruby, but what I do know about Apache is telling me that in their Apache setup, they run the dispatch.fcgi script again every time, for each request. I’m open to being wrong about that, but I don’t know how.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.