Re: [fossil-users] Fossil behind reverse proxy
Hi Kyle,
Thanks for your extensive reply. I was going through the code and had
stumbled upon the SCRIPT_NAME trick when your mail came in and confirmed
that it was indeed possible. In the default admin setup, the logo path
needed to be fixed from '/logo' to '$baseurl/logo', but then it works
fully. I can confirm that it also works on Linux and Windows, not just
Darwin. For folks not using Apache it would be good if your below 'how to'
could mention that the reverse proxy needs to strip the baseurl of the uri
it forwards to the Fossil server (i.e.: '/fossil/index' must be forwarded
as '/index').
However, this is a hack that works by accident. It works because 'server'
and 'cgi' share code paths and the 'server' code flow reads part of the CGI
environment even though it shouldn't. Can you imagine the configuration
headache if one had an unrelated SCRIPT_NAME environment variable and
wasn't aware of this feature... Also, the hack fixes the baseUrl to one
defined prefix. Access to a fossil server setup using this hack becomes
unusable from the web if accessed directly as well, nor can multiple
baseurl's be mapped to a single fossil server instance. Whilst I'm quite
happy that the hack fixes my immediate problem, I think a better engineered
solution is preferrable.
First of all, I note that baseUrl relocation in server mode works without
problem as you have established and I can confirm from short experience; so
we are not entering a mine field, it seems. First I thought along the lines
that you point out in your how-to. Later I thought that we should not
overload Fossil with options, especially as everybody will want something a
little different. Instead, it should be the reverse proxy that does all the
work IMHO.
How about using request headers for this? The reverse proxy could add two
custom headers to the forwared request (similar to X-Forwarded-For):
- X-Fossil-Baseurl
- X-Fossil-Repository
Fossil would only look at these when in server mode. The first would
specify the baseurl that is used to relocate all references in html/css
output, and in redirect responses. If no such header exists, it is root
('/'). The first is sufficient for reverse proxying. The second would
specify the repository to use for that request only. If no such header
exists, it is the repository specified on the command line. This would take
care of your generalised repository access.
This would work very well with my own (soon to be published, GPL'ed)
reverse proxy. It would also work very well with Lighttpd, using its
mod_magnet module. Would it be workable with Apache too? (I'm not familiar
with Apache configuration).
Paul
On Thu, 28 Jan 2010 11:53:36 -0800, Kyle McKay mack...@gmail.com wrote:
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 21
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-users] Repository-dependant cookies
Hello I'm hosting more than one repository on a single machine. I have to logon everytime, when i change in my browser from one to another repository. Would it be possible to have a Login-Cookie for every repository? I think the Cookie-name should have a repository-dependend part. Thanks Wolfgang ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Repository-dependant cookies
I can't answer your question, but you can run each server on a different port. Stephen On Saturday, January 30, 2010, rat...@stumvolls.de wrote: Hello I'm hosting more than one repository on a single machine. I have to logon everytime, when i change in my browser from one to another repository. Would it be possible to have a Login-Cookie for every repository? I think the Cookie-name should have a repository-dependend part. Thanks Wolfgang ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- -- Stephen De Gabrielle stephen.degabrie...@acm.org Telephone +44 (0)20 85670911 Mobile+44 (0)79 85189045 http://www.degabrielle.name/stephen ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Repository-dependant cookies
On Jan 30, 2010, at 8:24 AM, rat...@stumvolls.de rat...@stumvolls.de wrote: Hello I'm hosting more than one repository on a single machine. I have to logon everytime, when i change in my browser from one to another repository. Would it be possible to have a Login-Cookie for every repository? I think the Cookie-name should have a repository-dependend part. That is the way it is currently implemented. I host about 2 dozen repositories on http://www.sqlite.org (examples: http://www.sqlite.org/src , http://www.sqlite.org/docsrc, http://www.sqlite.org/br3317) and my browser (Firefox) keeps separate cookies for each. Are you saying this does not work for you? Thanks Wolfgang ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users D. Richard Hipp d...@hwaci.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Repository-dependant cookies
On Jan 30, 2010, at 12:33 PM, rat...@stumvolls.de rat...@stumvolls.de wrote: Hello again Here are some more informations about my configuration: * Server OS: Windows Home Server(Windows 2003 based) * running two different fossil repositories on ports 8000 and 8001(Fossil version [a3c97c9063] 2010-01-21 20:53:59) * client OS: XP prof. * Browser: Firefox 2 If i switch between the repositories, the current login becomes invalid. I opened the cookie-dialog of firefox. There i can see One cookie from my server, named fossil_login_ I guess firefox 2 sends to same cookie to port 8001 as it sends to port 8000. as if localhost:8000 and localhost:8001 were the same website. If you switch to running a webserver (on port 80, say) and run your repositories as CGI scripts, the names of each CGI script will be appended (as hex) to the login cookie name and this problem will go away. It is not clear to me what (if anything) we ought do to Fossil to make it easier to work around this. There was another recent request for the ability to serve multiple repositories off of the same TCP port without using a web server. The current syntax to launch a stand-alone server is: fossil server REPOSITORYFILE Suppose we expanded this to allow multiple repositories to be named on the command-line. So if you had a directory full of repositories, you could do: fossil server *.fossil Suppose the names of the repositories files are abc.fossil, def.fossil, ghi.fossil and so forth. Then to reach each repository, visit: http://localhost/abc http://localhost/def http://localhost/ghi And so forth. If this functionality were implemented, then the cookie names would be fossil_login_2F616263, fossil_login_2F646566, and fossil_login_2F676869. Since the cookie names are different, you could log onto all repositories all at once. If no repository is specified in the URL (if you enter http://localhost/) what should it do? Show an error? Return a list of repositories? Choose the first one named? Perhaps the syntax should be: fossil server --directory FOLDER_HOLDING_REPOSITORIES In that case, fossil is able to serve any fossil repository in the named directory. The particular repository chosen by the path in the URL. With this syntax, new repositories can be added to the site without having to restart the server - simply move files into the appropriate folder. We still have the problem of what to do with an unknown path. I think the problem is, that there is no 'repository-extension' behind the last underscore. The test_env-information, given by one of the servers is: g.zBaseURL = http://DELETED BY ME:8000 g.zTop = GATEWAY_INTERFACE = CGI/1.0 HTTP_COOKIE = fossil_login_=1%2F5A300CEC00A1528DAE8F21FD975FE6742534E95E2D2443872E HTTP_HOST = DELETED BY ME:8000 HTTP_USER_AGENT = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 (.NET CLR 3.5.30729) PATH_INFO = /test_env QUERY_STRING = REMOTE_ADDR = DELETED BY ME REQUEST_METHOD = GET REQUEST_URI = /test_env fossil_login_ = DELETED BY ME Maybe this information helps. Feel free to contact me, if you need further information. Wolfgang ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users D. Richard Hipp d...@hwaci.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Repository-dependant cookies
2010/1/31 D. Richard Hipp d...@hwaci.com There was another recent request for the ability to serve multiple repositories off of the same TCP port without using a web server. The current syntax to launch a stand-alone server is: fossil server REPOSITORYFILE Suppose we expanded this to allow multiple repositories to be named on the command-line. So if you had a directory full of repositories, you could do: fossil server *.fossil Suppose the names of the repositories files are abc.fossil, def.fossil, ghi.fossil and so forth. Then to reach each repository, visit: http://localhost/abc http://localhost/def http://localhost/ghi And so forth. If this functionality were implemented, then the cookie names would be fossil_login_2F616263, fossil_login_2F646566, and fossil_login_2F676869. Since the cookie names are different, you could log onto all repositories all at once. If no repository is specified in the URL (if you enter http://localhost/) what should it do? Show an error? Return a list of repositories? Choose the first one named? Perhaps the syntax should be: fossil server --directory FOLDER_HOLDING_REPOSITORIES In that case, fossil is able to serve any fossil repository in the named directory. The particular repository chosen by the path in the URL. With this syntax, new repositories can be added to the site without having to restart the server - simply move files into the appropriate folder. We still have the problem of what to do with an unknown path. I like these ideas a *lot*, Richard. As in I like all of them. For just quickly sharing a specific repository you use the single-file version (the default as now). If you want to share specific repositories but not all of them, the multiple repositories on the command line is perfect. If you want to host many repositories and expand/contract them as needed without restarting the server your directory syntax is perfect. If you enter just the root there's arguments for two approaches: 1. The open approach is to list all the accessible repos. 2. The more security-semi-conscious approach would be to assume someone hitting the root isn't authorized to access any repository and thus should gets flipped the bird, metaphorically. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil behind reverse proxy
On Jan 30, 2010, at 04:00, Paul Ruizendaal wrote: Hi Kyle, In the default admin setup, the logo path needed to be fixed from '/logo' to '$baseurl/logo', but then it works fully. I didn't need to do that. Must have been fixed in later versions of fossil. That would be a bug for the cgi command as well. My new repositories already had that correct without needing to edit anything. I can confirm that it also works on Linux and Windows, not just Darwin. For folks not using Apache it would be good if your below 'how to' could mention that the reverse proxy needs to strip the baseurl of the uri it forwards to the Fossil server (i.e.: '/fossil/index' must be forwarded as '/index'). That is standard behavior for a reverse proxy as the proxy machine the requests are being sent to has absolutely no knowledge of where it's being mapped into the other machine's web space or even that it's being used as a proxy in the first place (unless it starts inspecting X-Forwarded-... and/or Via headers). Normally in this situation, however, you would expect that content coming from the proxy machine would have to be inspected and have any contained links rewritten to match the other machine's web space (mod_proxy_html can do this http://apache.webthing.com/mod_proxy_html/ ) and indeed I had it working using mod_poxy_html when I realized it wasn't necessary. I prefer to avoid the extra overhead of inspecting the content since it's not necessary if you set SCRIPT_NAME (with the proviso that you mention below that you can no longer access it directly if you do this). However, this is a hack that works by accident. It works because 'server' and 'cgi' share code paths and the 'server' code flow reads part of the CGI environment even though it shouldn't. Yes but unless the current fossil architecture is changed it will keep working. It's also fortunate that SCRIPT_NAME is used when constructing the login cookie -- but again, for the cgi command to keep working it needs to. Can you imagine the configuration headache if one had an unrelated SCRIPT_NAME environment variable and wasn't aware of this feature... I was a bit surprised that SCRIPT_NAME was used even when the GATEWAY_INTERFACE environment variable is not set. Probably SCRIPT_NAME should only be used if GATEWAY_INTERFACE is CGI/1.0 or later. But even then that would just mean you needed to set that variable together with SCRIPT_NAME to use the hack. Also, the hack fixes the baseUrl to one defined prefix. Access to a fossil server setup using this hack becomes unusable from the web if accessed directly as well, nor can multiple baseurl's be mapped to a single fossil server instance. Whilst I'm quite happy that the hack fixes my immediate problem, Yes, me too. I think a better engineered solution is preferrable. Undocumented behavior has a bad habit of breaking or going away -- a documented solution is preferred. How about using request headers for this? The reverse proxy could add two custom headers to the forwared request (similar to X-Forwarded-For): - X-Fossil-Baseurl - X-Fossil-Repository Fossil would only look at these when in server mode. Or in http mode. The first would specify the baseurl that is used to relocate all references in html/ css output, and in redirect responses. Using the SCRIPT_NAME hack and running in server mode, you do have to make sure that Location: redirects get corrected -- as you say, a reverse proxy can be expected to do this -- this is never necessary when running in cgi mode. It might be a bit of a challenge to catch all the redirects unless you hack it by prepending SCRIPT_NAME to the value stuffed into REQUEST_URI by the source in server and http modes. This line in cgi.c (in the cgi_handle_http_request function): cgi_setenv(REQUEST_URI, zToken); would need to change to set REQUEST_URI to the contents of SCRIPT_NAME concatenated to zToken instead of what it does now. That would make the SCRIPT_NAME hack produce correct redirects and I believe make a SCRIPT_NAME hack running server be directly accessible. Something like this but without the memory leak or double getenv call: cgi_setenv(REQUEST_URI, mprintf(%s%s, (getenv(SCRIPT_NAME)? getenv(SCRIPT_NAME):), zToken)); This would work very well with my own (soon to be published, GPL'ed) reverse proxy. It would also work very well with Lighttpd, using its mod_magnet module. Would it be workable with Apache too? (I'm not familiar with Apache configuration). The updated Apache 2 configuration to reverse proxy a fossil server running like this: export SCRIPT_NAME=/fos fossil server -P 8080 /path/to/some/fossil/repository is this: RewriteEngine On RewriteRule ^/fos$ /fos/ [PT] ProxyPreserveHost On ProxyPass /fos/ http://machine_running_fossil_server:8080/ Location /fos/ ProxyPassReverse / RequestHeader set
Re: [fossil-users] Repository-dependant cookies
On Sunday 31 January 2010 05:21:13 D. Richard Hipp wrote: Suppose we expanded this to allow multiple repositories to be named on the command-line. So if you had a directory full of repositories, you could do: fossil server *.fossil Suppose the names of the repositories files are abc.fossil, def.fossil, ghi.fossil and so forth. Then to reach each repository, visit: http://localhost/abc http://localhost/def http://localhost/ghi I also like this idea a lot -- it would make my life easier. But -- how does this work for a CGI-based server? I'm having trouble figuring out how it should be set-up... -- Sending me something private? Use my GPG public key: AD29415D ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
