Paul, I'm running a fossil server behind an Apache reverse proxy quite happily. I've been meaning to add something to the wiki cookbook about this but just haven't got around to it yet.
I'm doing this because: 1. I want a fossil UI to be always on and available via my web server 2. I want the fossil server to run as a different user account than the web server processes 3. I don't want to use any suid programs (i.e. suExec) My apache web server is setup so that: http://my_server_name/fossil Is reverse proxied to the fossil server process that is running as a daemon on a separate port http://my_server_name/anything-other-than-fossil-here Serves up whatever else would normally be served on my server. To make this work (I'm running on Darwin which is very Unix like) you need to do these two things (the examples assume you have a bash shell): 1. Start your fossil server daemon running with a shell script like this #!/bin/sh export SCRIPT_NAME=/fossil fossil server -P 8000 full_path_to_fossil_respository_here & If you want to start the fossil server in its own process group, add this line: set -m at the beginning of the script and add this line: disown at the end and you probably want to redirect fossil input, output and error to /dev/null as well so the final script to do all of this would look like (adding nohup also to make it immune to SIGHUP): #!/bin/bash set -m export SCRIPT_NAME=/fossil nohup fossil server -P 8000 full_path_to_fossil_respository_here \ </dev/null >/dev/null 2>&1 & disown # this is a bashism 2. Add this configuration section to your Apache configuration ProxyPass /fossil http://machine_your_fossil_server_is_running_on: 8000 ProxyPreserveHost On # ProxyPreserveHost is required since fossil inspects the Host value # and without it fossil-generated links will point directly to fossil # instead of the Apache server 3. Access your fossil server like this: http://machine_apache_is_running_on/fossil 4. Optionally add a firewall rule to limit connections to the fossil server to only those coming from the Apache server machine (be nice if fossil had a loopback-only setting similar to postfix's to bind its socket listener to only localhost IPv4/IPv6 interfaces). If you want your fossil URL to look like http://some_machine/foo/bar/ scm you need would change the above example lines for starting your fossil server and setting your Apache configuration as follows: SCRIPT_NAME=/foo/bar/scm ProxyPass /foo/bar/scm http:// machine_your_fossil_server_is_running_on:8000 Similarly you can change the port the fossil server runs on just as easily. It turns out that since fossil already handles running from an arbitrary web location as a cgi script, it quite happily will still use that arbitrary location when running as a server if you provide it via SCRIPT_NAME. I wish there was functionality something like this though: fossil server -P 8000 --ext .fsl path_to_directory_containing_.fsl_repositories Where a single fossil server could serve up multiple fossil repositories. You would just point it to the parent directory and tell it what repository extension to look for and then it would insert an additional element into the URL using the base name of the fossil repository minus the extension. So if you had these repositories on your system: /some/directory/repository1.fsl /some/directory/repository2.fsl And started the fossil server like this: fossil server -P 8080 --ext .fsl /some/directory Then you could access repository1.fsl like this: http://localhost:8080/repository1 and repository2.fsl like this: http://localhost:8080/repository2 and as a bonus you could get a list of available repositories with this: http://localhost:8080/ (And, of course, still use the SCRIPT_NAME trick to change the URL location if you like.) I believe a relatively simple Perl or Python server script could use the fossil http command to implement the multiple repository server relatively easily since the SCRIPT_NAME technique also works with the fossil http command. Hmmm, I might just have to write that script later today. Kyle On Jan 28, 2010, at 04:00, Paul Ruizendaal wrote: > It may be subtler and easier than I first thought: > > Fossil already uses the host information from the Host: header, not > from > its own IP. When in CGI mode, it already relocates all its absolute > references to include the prefix of the cgi script location. > > When running as server Fossil does not do the above relocation but > keeps > everyting based at root ('/'), regardless of the path in the request > uri. > Is there a reason that makes fossil CGI style relocation a bad idea > for a > fossil running in server mode? > > Paul > > ====== > > I just tried to put Fossil (running as server) behind a reverse proxy > (home grown, but similar to "Pound"). > > That doesn't work very well, because Fossil prefixes all paths in its > output with a full baseURL (as seen by Fossil). The client can't use > that > as the reverse proxy maps an entirely different prefix to the Fossil > server > instance. I think the html/css output by Fossil should use relative > paths, > not absolute paths. > > Next to the above, also the 301 Redirect repsonses have the wrong > url, but > that is as per the http RFC: it is a reasonable job for a reverse > proxy to > rewrite the Location: header of a 301 response. > > Before I attempt this rather massive patch: Richard, any remarks? > > Paul _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
