73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
-
+
-
+
-
+
-
-
+
+
-
+
-
-
-
+
+
-
-
-
+
-
-
-
-
-
+
-
+
+
+
+
+
+
+
+
+
+
-
-
-
+
+
+
+
|
<li><a id="cgi" href="any/cgi.md">CGI</a>
<li>Socket listener
<li><a id="standalone" href="any/none.md">Stand-alone HTTP server</a>
<li><a id="scgi" href="any/scgi.md">SCGI</a>
</ol>
<p>All of these methods can serve either a single repository or a
directory containing repositories named "<tt>*.fossil</tt>".</p>
directory hierarchy containing mulitiple repositories.</p>
<p>You are not restricted to using a single method. The same Fossil
<p>You are not restricted to a single server setup. The same Fossil
repository can be served using two or more of the above techniques at
the same time. These methods use clean, well-defined, standard
interfaces (CGI, SCGI, and HTTP) which allow you to easily migrate from
one method to another to accommodate changes in hosting providers or
one method to another in response to changes in hosting providers or
administrator preferences.</p>
<h3>CGI</h3>
<p>Most ordinary web servers can <a href="any/cgi.md">run Fossil as a
CGI script</a>. This method is known to work with Apache,
<tt>lighttpd</tt>, and <a
href="any/althttpd.md"><tt>althttpd</tt></a>. The Fossil server
administrator places a <a href="/help?cmd=cgi">short CGI script</a> in
the web server's document hierarchy, and when a client requests the URL
that corresponds to that script, the script runs Fossil to generate the
the web server's document hierarchy and when a client requests the URL
that corresponds to that script, Fossil runs and generates the
response.</p>
<p>CGI is a good choice for merging Fossil into an existing web site,
particularly on hosts that have CGI set up for you already and won't let
particularly on hosts that have CGI set up and working.
you modify the web server configuration further. The Fossil <a
href="../selfhost.wiki">self-hosting repositories</a> are implemented
with CGI underneath <tt>althttpd</tt>.</p>
<p>Only slightly more complicated is the socket listener method.
Instead of letting Fossil run in the background continuously to handle
HTTP requests from clients, you configure a socket listener daemon to
run a <a href="/help?cmd=http"><tt>fossil http</tt></a> command on each
HTTP hit. That Fossil instance handles only that one hit and then shuts
back down, letting the socket listener go back to waiting for the next
hit. This scheme is known to work with <a id="inetd"
href="any/inetd.md"><tt>inetd</tt></a>, <a id="xinetd"
href="debian/service.md"><tt>systemd</tt></a>.</p>
href="debian/service.md"><tt>systemd</tt></a>
can be configured to invoke the the
<a href="/help?cmd=http"><tt>fossil http</tt></a> command to handle
each incoming HTTP request. The "<tt>fossil http</tt>" command reads
the HTTP request off of standard input, computes an appropriate
reply, and writes the reply on standard output. There is a separate
invocation of the "<tt>fossil http</tt>" command for each HTTP request.
The socket listener daemon takes care of relaying content to and from
the client, and (in the case of <a href="any/stunnel.md">stunnel</a>)
handling TLS decryption and encryption.
<h3>Stand-alone HTTP Server</h3>
<p>This is the <a href="any/none.md">easiest method</a>.
A stand-alone server uses the <a
href="/help?cmd=server"><tt>fossil server</tt></a> command to run a
process that listens for incoming HTTP requests on a socket and then
dispatches a copy of itself to deal with each incoming request. You can
expose Fossil directly to the clients in this way or you can interpose a
<a href="https://en.wikipedia.org/wiki/Reverse_proxy">reverse proxy</a>
layer between the clients and Fossil.</p>
<h3>SCGI</h3>
<p>The Fossil standalone server can also run <a href="any/scgi.md">in
SCGI mode</a> — <a href="/help/server"><tt>fossil server --scgi</tt></a>
— instead of <a href="any/none.md">HTTP mode</a>, which allows it to
<p>The Fossil standalone server can also handle <a href="any/scgi.md">SCGI</a>.
When the <a href="/help/server"><tt>fossil server</tt></a> command is
run with the extra <tt>--scgi</tt> option, it listens for incoming
SCGI requests rather than HTTP requests. This allows Fossil to
respond to requests from web servers <a href="debian/nginx.md">such as
nginx</a> that don't support CGI. SCGI is a simpler protocol to proxy
than HTTP, since the HTTP doesn't have to be re-interpreted in terms of
the proxy's existing HTTP implementation, but it's more complex to set
up because you also have to set up an SCGI-to-HTTP proxy for it. It is
worth taking on this difficulty only when you need to integrate Fossil
into an existing web site already being served by an SCGI-capable web
|
230
231
232
233
234
235
236
237
238
239
240
241
242
243
|
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
|
+
|
<h2 id="more">Further Details</h2>
<ul>
<li><a id="chroot" href="../chroot.md" >The Server Chroot Jail</a>
<li><a id="loadmgmt" href="../loadmgmt.md" >Managing Server Load</a>
<li><a id="bkofc" href="../backoffice.md" >The Backoffice</a>
<li><a id="tls" href="../ssl.wiki" >Securing a Repository with TLS</a>
<li><a id="ext" href="../serverext.wiki">CGI Server Extensions</a>
<li><a id="about" href="../aboutcgi.wiki" >How CGI Works In Fossil</a>
<li><a id="sync" href="../sync.wiki" >The Fossil Sync Protocol</a>
</ul>
</div>
|