Fossil SCM
Further improvements to server documentation. No code changes.
Commit
b91754ab851581f0286a43b53f6e1975a41f2630
Parent
902135f747ecc6d…
4 files changed
+2
-2
+2
-2
+18
-50
+82
-87
+2
-2
| --- www/embeddeddoc.wiki | ||
| +++ www/embeddeddoc.wiki | ||
| @@ -103,12 +103,12 @@ | ||
| 103 | 103 | <blockquote><pre> |
| 104 | 104 | #!/usr/bin/fossil |
| 105 | 105 | repository: /fossil/fossil.fossil |
| 106 | 106 | </pre></blockquote> |
| 107 | 107 | |
| 108 | -This is one of three ways to set up a | |
| 109 | -<a href="quickstart.wiki#serversetup">fossil web server</a>. | |
| 108 | +This is one of four ways to set up a | |
| 109 | +<a href="./server.wiki">fossil web server</a>. | |
| 110 | 110 | |
| 111 | 111 | The "<b>/trunk/</b>" part of the URL tells fossil to use |
| 112 | 112 | the documentation files from the most recent trunk check-in. |
| 113 | 113 | If you wanted to see an historical version of this document, |
| 114 | 114 | you could substitute the name of a check-in for "<b>/trunk/</b>". |
| 115 | 115 |
| --- www/embeddeddoc.wiki | |
| +++ www/embeddeddoc.wiki | |
| @@ -103,12 +103,12 @@ | |
| 103 | <blockquote><pre> |
| 104 | #!/usr/bin/fossil |
| 105 | repository: /fossil/fossil.fossil |
| 106 | </pre></blockquote> |
| 107 | |
| 108 | This is one of three ways to set up a |
| 109 | <a href="quickstart.wiki#serversetup">fossil web server</a>. |
| 110 | |
| 111 | The "<b>/trunk/</b>" part of the URL tells fossil to use |
| 112 | the documentation files from the most recent trunk check-in. |
| 113 | If you wanted to see an historical version of this document, |
| 114 | you could substitute the name of a check-in for "<b>/trunk/</b>". |
| 115 |
| --- www/embeddeddoc.wiki | |
| +++ www/embeddeddoc.wiki | |
| @@ -103,12 +103,12 @@ | |
| 103 | <blockquote><pre> |
| 104 | #!/usr/bin/fossil |
| 105 | repository: /fossil/fossil.fossil |
| 106 | </pre></blockquote> |
| 107 | |
| 108 | This is one of four ways to set up a |
| 109 | <a href="./server.wiki">fossil web server</a>. |
| 110 | |
| 111 | The "<b>/trunk/</b>" part of the URL tells fossil to use |
| 112 | the documentation files from the most recent trunk check-in. |
| 113 | If you wanted to see an historical version of this document, |
| 114 | you could substitute the name of a check-in for "<b>/trunk/</b>". |
| 115 |
+2
-2
| --- www/index.wiki | ||
| +++ www/index.wiki | ||
| @@ -91,14 +91,14 @@ | ||
| 91 | 91 | for all network communications, meaning that it works fine from behind |
| 92 | 92 | restrictive firewalls. The protocol is |
| 93 | 93 | [./stats.wiki | bandwidth efficient] to the point that Fossil can be |
| 94 | 94 | used comfortably over a dial-up internet connection. |
| 95 | 95 | |
| 96 | - 6. <b>CGI and SCGI Enabled</b> - | |
| 96 | + 6. <b>CGI/SCGI Enabled</b> - | |
| 97 | 97 | No server is required to use fossil. But a |
| 98 | 98 | server does make collaboration easier. Fossil supports four different |
| 99 | - yet simple [./quickstart.wiki#serversetup | server configurations]. | |
| 99 | + yet simple [./server.wiki | server configurations]. | |
| 100 | 100 | The most popular is a 2-line CGI script. This is the approach |
| 101 | 101 | used by the [./selfhost.wiki | self-hosting fossil repositories]. |
| 102 | 102 | |
| 103 | 103 | 7. <b>Robust & Reliable</b> - |
| 104 | 104 | Fossil stores content using an [./fileformat.wiki | enduring file format] |
| 105 | 105 |
| --- www/index.wiki | |
| +++ www/index.wiki | |
| @@ -91,14 +91,14 @@ | |
| 91 | for all network communications, meaning that it works fine from behind |
| 92 | restrictive firewalls. The protocol is |
| 93 | [./stats.wiki | bandwidth efficient] to the point that Fossil can be |
| 94 | used comfortably over a dial-up internet connection. |
| 95 | |
| 96 | 6. <b>CGI and SCGI Enabled</b> - |
| 97 | No server is required to use fossil. But a |
| 98 | server does make collaboration easier. Fossil supports four different |
| 99 | yet simple [./quickstart.wiki#serversetup | server configurations]. |
| 100 | The most popular is a 2-line CGI script. This is the approach |
| 101 | used by the [./selfhost.wiki | self-hosting fossil repositories]. |
| 102 | |
| 103 | 7. <b>Robust & Reliable</b> - |
| 104 | Fossil stores content using an [./fileformat.wiki | enduring file format] |
| 105 |
| --- www/index.wiki | |
| +++ www/index.wiki | |
| @@ -91,14 +91,14 @@ | |
| 91 | for all network communications, meaning that it works fine from behind |
| 92 | restrictive firewalls. The protocol is |
| 93 | [./stats.wiki | bandwidth efficient] to the point that Fossil can be |
| 94 | used comfortably over a dial-up internet connection. |
| 95 | |
| 96 | 6. <b>CGI/SCGI Enabled</b> - |
| 97 | No server is required to use fossil. But a |
| 98 | server does make collaboration easier. Fossil supports four different |
| 99 | yet simple [./server.wiki | server configurations]. |
| 100 | The most popular is a 2-line CGI script. This is the approach |
| 101 | used by the [./selfhost.wiki | self-hosting fossil repositories]. |
| 102 | |
| 103 | 7. <b>Robust & Reliable</b> - |
| 104 | Fossil stores content using an [./fileformat.wiki | enduring file format] |
| 105 |
+18
-50
| --- www/quickstart.wiki | ||
| +++ www/quickstart.wiki | ||
| @@ -285,72 +285,40 @@ | ||
| 285 | 285 | mistake. Undo and redo only work for changes that have |
| 286 | 286 | not yet been checked in using commit and there is only a single |
| 287 | 287 | level of undo/redo.</p> |
| 288 | 288 | |
| 289 | 289 | |
| 290 | -<a name="serversetup"></a> | |
| 291 | 290 | <h2>Setting Up A Server</h2> |
| 292 | 291 | |
| 293 | - <p>The easiest way to set up a server is:</p> | |
| 292 | + <p>Fossil can act as a stand-alone web server using one of these | |
| 293 | + commands:</p> | |
| 294 | 294 | |
| 295 | 295 | <blockquote> |
| 296 | - <b>[/help/server | fossil server]</b> <i>repository-filename</i> | |
| 296 | + <b>[/help/server | fossil server]</b> <i>repository-filename</i><br> | |
| 297 | + <b>[/help/ui | fossil ui]</b> <i>repository-filename</i> | |
| 297 | 298 | </blockquote> |
| 298 | 299 | |
| 299 | - <p>Or</b> | |
| 300 | - | |
| 301 | - <blockquote> | |
| 302 | - <b>[/help/ui | fossil ui]</b> <i>repository-filename</i> | |
| 303 | - </blockquote> | |
| 300 | + <p>The <i>repository-filename</i> can be omitted when these commands | |
| 301 | + are run from within an open check-out, which a particularly useful | |
| 302 | + shortcut for the <b>fossil ui</b> command. | |
| 304 | 303 | |
| 305 | 304 | <p>The <b>ui</b> command is intended for accessing the web interface |
| 306 | 305 | from a local desktop. The <b>ui</b> command binds to the loopback IP |
| 307 | 306 | address only (and thus makes the web interface visible only on the |
| 308 | 307 | local machine) and it automatically start your web browser pointing at the |
| 309 | 308 | server. For cross-machine collaboration, use the <b>server</b> command, |
| 310 | - which binds on all IP addresses and does not try to start a web browser. | |
| 311 | - You can omit the <i>repository-filename</i> if you are within | |
| 312 | - a checked-out local tree. The <b>server</b> uses port 8080 by default | |
| 313 | - but you can specify a different port using the <b>-port</b> option.</p> | |
| 314 | - | |
| 315 | - <p>The same commands can be used with the --scgi option to run | |
| 316 | - [./scgi.wiki | SCGI] from Nginx, if desired.</p> | |
| 317 | - | |
| 318 | - <p>Command-line servers like this are useful when two people want | |
| 319 | - to share a repository on temporary or ad-hoc basis. For a more | |
| 320 | - permanent installation, you should use either the CGI server or the | |
| 321 | - inetd server. | |
| 322 | - <a name="cgiserver"></a> | |
| 323 | - To use the CGI server, create a CGI script that | |
| 324 | - looks something like this:</p> | |
| 325 | - | |
| 326 | - <blockquote><b> | |
| 327 | - #!/usr/local/bin/fossil<br> | |
| 328 | - repository: /home/proj1/repos1.fossil | |
| 329 | - </b></blockquote> | |
| 330 | - | |
| 331 | - <p>Adjust the paths in this CGI script to match your installation | |
| 332 | - and make sure both repository file and the directory that contains it | |
| 333 | - are readable and writable by the user that CGI scripts run as. | |
| 334 | - Then point clients at the CGI script. That's all there is to it!</p> | |
| 335 | - | |
| 336 | - <a name="inetdserver"></a> | |
| 337 | - <p>You can also run fossil from inetd or xinetd. For an inetd | |
| 338 | - installation, make an entry in /etc/inetd.conf that looks something | |
| 339 | - like this:</p> | |
| 340 | - | |
| 341 | - <blockquote><b> | |
| 342 | - 80 stream tcp nowait.1000 root /usr/bin/fossil \<br> | |
| 343 | - /usr/bin/fossil http /home/proj1/repos1.fossil | |
| 344 | - </b></blockquote> | |
| 345 | - | |
| 346 | - <p>Adjust the paths to suit your installation, of course. Notice that | |
| 347 | - fossil runs as root. This is not required - you can run it as an | |
| 348 | - unprivileged user. But it is more secure to run fossil as root. | |
| 349 | - When you do run fossil as root, it automatically puts itself in a | |
| 350 | - chroot jail in the same directory as the repository, then drops | |
| 351 | - root privileges prior to reading any information from the socket.</p> | |
| 309 | + which binds on all IP addresses and does not try to start a web browser.</p> | |
| 310 | + | |
| 311 | + <p>Servers are also easily configured as: | |
| 312 | + <ul> | |
| 313 | + <li>[./server.wiki#inetd|inetd/xinetd] | |
| 314 | + <li>[./server.wiki#cgi|CGI] | |
| 315 | + <li>[./server.wiki#scgi|SCGI] | |
| 316 | + </ul> | |
| 317 | + | |
| 318 | + <p>The the [./selfhost.wiki | self-hosting fossil repositories] use | |
| 319 | + CGI. | |
| 352 | 320 | |
| 353 | 321 | <a name="proxy"></a> |
| 354 | 322 | <h2>HTTP Proxies</h2> |
| 355 | 323 | |
| 356 | 324 | <p>If you are behind a restrictive firewall that requires you to use |
| 357 | 325 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -285,72 +285,40 @@ | |
| 285 | mistake. Undo and redo only work for changes that have |
| 286 | not yet been checked in using commit and there is only a single |
| 287 | level of undo/redo.</p> |
| 288 | |
| 289 | |
| 290 | <a name="serversetup"></a> |
| 291 | <h2>Setting Up A Server</h2> |
| 292 | |
| 293 | <p>The easiest way to set up a server is:</p> |
| 294 | |
| 295 | <blockquote> |
| 296 | <b>[/help/server | fossil server]</b> <i>repository-filename</i> |
| 297 | </blockquote> |
| 298 | |
| 299 | <p>Or</b> |
| 300 | |
| 301 | <blockquote> |
| 302 | <b>[/help/ui | fossil ui]</b> <i>repository-filename</i> |
| 303 | </blockquote> |
| 304 | |
| 305 | <p>The <b>ui</b> command is intended for accessing the web interface |
| 306 | from a local desktop. The <b>ui</b> command binds to the loopback IP |
| 307 | address only (and thus makes the web interface visible only on the |
| 308 | local machine) and it automatically start your web browser pointing at the |
| 309 | server. For cross-machine collaboration, use the <b>server</b> command, |
| 310 | which binds on all IP addresses and does not try to start a web browser. |
| 311 | You can omit the <i>repository-filename</i> if you are within |
| 312 | a checked-out local tree. The <b>server</b> uses port 8080 by default |
| 313 | but you can specify a different port using the <b>-port</b> option.</p> |
| 314 | |
| 315 | <p>The same commands can be used with the --scgi option to run |
| 316 | [./scgi.wiki | SCGI] from Nginx, if desired.</p> |
| 317 | |
| 318 | <p>Command-line servers like this are useful when two people want |
| 319 | to share a repository on temporary or ad-hoc basis. For a more |
| 320 | permanent installation, you should use either the CGI server or the |
| 321 | inetd server. |
| 322 | <a name="cgiserver"></a> |
| 323 | To use the CGI server, create a CGI script that |
| 324 | looks something like this:</p> |
| 325 | |
| 326 | <blockquote><b> |
| 327 | #!/usr/local/bin/fossil<br> |
| 328 | repository: /home/proj1/repos1.fossil |
| 329 | </b></blockquote> |
| 330 | |
| 331 | <p>Adjust the paths in this CGI script to match your installation |
| 332 | and make sure both repository file and the directory that contains it |
| 333 | are readable and writable by the user that CGI scripts run as. |
| 334 | Then point clients at the CGI script. That's all there is to it!</p> |
| 335 | |
| 336 | <a name="inetdserver"></a> |
| 337 | <p>You can also run fossil from inetd or xinetd. For an inetd |
| 338 | installation, make an entry in /etc/inetd.conf that looks something |
| 339 | like this:</p> |
| 340 | |
| 341 | <blockquote><b> |
| 342 | 80 stream tcp nowait.1000 root /usr/bin/fossil \<br> |
| 343 | /usr/bin/fossil http /home/proj1/repos1.fossil |
| 344 | </b></blockquote> |
| 345 | |
| 346 | <p>Adjust the paths to suit your installation, of course. Notice that |
| 347 | fossil runs as root. This is not required - you can run it as an |
| 348 | unprivileged user. But it is more secure to run fossil as root. |
| 349 | When you do run fossil as root, it automatically puts itself in a |
| 350 | chroot jail in the same directory as the repository, then drops |
| 351 | root privileges prior to reading any information from the socket.</p> |
| 352 | |
| 353 | <a name="proxy"></a> |
| 354 | <h2>HTTP Proxies</h2> |
| 355 | |
| 356 | <p>If you are behind a restrictive firewall that requires you to use |
| 357 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -285,72 +285,40 @@ | |
| 285 | mistake. Undo and redo only work for changes that have |
| 286 | not yet been checked in using commit and there is only a single |
| 287 | level of undo/redo.</p> |
| 288 | |
| 289 | |
| 290 | <h2>Setting Up A Server</h2> |
| 291 | |
| 292 | <p>Fossil can act as a stand-alone web server using one of these |
| 293 | commands:</p> |
| 294 | |
| 295 | <blockquote> |
| 296 | <b>[/help/server | fossil server]</b> <i>repository-filename</i><br> |
| 297 | <b>[/help/ui | fossil ui]</b> <i>repository-filename</i> |
| 298 | </blockquote> |
| 299 | |
| 300 | <p>The <i>repository-filename</i> can be omitted when these commands |
| 301 | are run from within an open check-out, which a particularly useful |
| 302 | shortcut for the <b>fossil ui</b> command. |
| 303 | |
| 304 | <p>The <b>ui</b> command is intended for accessing the web interface |
| 305 | from a local desktop. The <b>ui</b> command binds to the loopback IP |
| 306 | address only (and thus makes the web interface visible only on the |
| 307 | local machine) and it automatically start your web browser pointing at the |
| 308 | server. For cross-machine collaboration, use the <b>server</b> command, |
| 309 | which binds on all IP addresses and does not try to start a web browser.</p> |
| 310 | |
| 311 | <p>Servers are also easily configured as: |
| 312 | <ul> |
| 313 | <li>[./server.wiki#inetd|inetd/xinetd] |
| 314 | <li>[./server.wiki#cgi|CGI] |
| 315 | <li>[./server.wiki#scgi|SCGI] |
| 316 | </ul> |
| 317 | |
| 318 | <p>The the [./selfhost.wiki | self-hosting fossil repositories] use |
| 319 | CGI. |
| 320 | |
| 321 | <a name="proxy"></a> |
| 322 | <h2>HTTP Proxies</h2> |
| 323 | |
| 324 | <p>If you are behind a restrictive firewall that requires you to use |
| 325 |
+82
-87
| --- www/server.wiki | ||
| +++ www/server.wiki | ||
| @@ -1,75 +1,76 @@ | ||
| 1 | 1 | <title>How To Configure A Fossil Server</title> |
| 2 | -<nowiki> | |
| 3 | -<p>This guide is intended to help guide you in setting up a Fossil server.</p> | |
| 4 | - | |
| 2 | +<p>A server is not necessary to use Fossil, but it does help in collaborating with | |
| 3 | +peers. This article is a guide for setting up a Fossil server.</p> | |
| 4 | +<h2>Overview</h2><blockquote> | |
| 5 | +There are basically four ways to set up a Fossil server: | |
| 6 | +<ol> | |
| 7 | +<li>A stand-alone server | |
| 8 | +<li>Using inetd or xinetd | |
| 9 | +<li>[https://en.wikipedia.org/wiki/Common_Gateway_Interface|CGI] | |
| 10 | +<li>[http://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface|SCGI] | |
| 11 | +</ol> | |
| 12 | +Each of these can serve either a single repository, or a directory hierarchy | |
| 13 | +containing many repositories with names ending in ".fossil". | |
| 14 | +</blockquote> | |
| 15 | +<a name="standalone"></a> | |
| 5 | 16 | <h2>Standalone server</h2><blockquote> |
| 6 | -The easiest way to set up a Fossil server is to use the <tt>server</tt> or | |
| 7 | -<tt>ui</tt> command. Assuming the repository you are interested in serving is | |
| 8 | -in the file "<tt>repo.fossil</tt>", you can use either of these commands to | |
| 9 | -start Fossil as a server: | |
| 17 | +The easiest way to set up a Fossil server is to use either the | |
| 18 | +[/help/server|server] or the [/help/ui|ui] commands: | |
| 10 | 19 | <ul> |
| 11 | -<li><b>fossil server repo.fossil</b> | |
| 12 | -<li><b>fossil ui repo.fossil</b> | |
| 20 | +<li><b>fossil server</b> <i>REPOSITORY</i> | |
| 21 | +<li><b>fossil ui</b> <i>REPOSITORY</i> | |
| 13 | 22 | </ul> |
| 14 | - | |
| 15 | 23 | <p> |
| 16 | -Both of these commands start a Fossil server on port 8080 on the local machine, | |
| 17 | -which can be accessed with the URL: <tt>http://localhost:8080/</tt> using any | |
| 18 | -handy web browser. The difference between the two commands is that "ui", in | |
| 19 | -addition to starting the Fossil server, also starts a web browser and points it | |
| 20 | -to the URL mentioned above, and the "ui" command binds to | |
| 21 | -the loopback IP address only (127.0.0.1) so that the "ui" command cannot be | |
| 24 | +The <i>REPOSITORY</i> argument is either the name of the repository file, or | |
| 25 | +a directory containing many repositories. | |
| 26 | +Both of these commands start a Fossil server, usually on TCP port 8080, though | |
| 27 | +a higher numbered port might also be used if 8080 is already occupied. You can | |
| 28 | +access these using URLs of the form <b>http://localhost:8080/</b>, or if | |
| 29 | +<i>REPOSITORY</i> is a directory, URLs of the form | |
| 30 | +<b>http://localhost:8080/</b><i>repo</i><b>/</b> where <i>repo</i> is the base | |
| 31 | +name of the repository file without the ".fossil" suffix. | |
| 32 | +The difference between "ui" and "server" is that "ui" will | |
| 33 | +also start a web browser and points it | |
| 34 | +to the URL mentioned above, and "ui" command binds to | |
| 35 | +the loopback IP address (127.0.0.1) only so that the "ui" command cannot be | |
| 22 | 36 | used to serve content to a different machine. |
| 23 | 37 | </p> |
| 24 | - | |
| 25 | 38 | <p> |
| 26 | 39 | If one of the commands above is run from within an option checkout, |
| 27 | -then the repository name can be omitted and the checkout is used as | |
| 40 | +then the <i>REPOSITORY</i> argument can be omitted and the checkout is used as | |
| 28 | 41 | the repository. |
| 29 | 42 | </p> |
| 30 | - | |
| 31 | -<p> | |
| 32 | -Instead of a single repository, the commands above can specify a | |
| 33 | -directory that contains multiple Fossil repositories named with the | |
| 34 | -".fossil" suffix. In this case, the request URL should begin with | |
| 35 | -the base name of the particular repository that is desired. | |
| 36 | -</p> | |
| 37 | - | |
| 38 | -<p> | |
| 39 | -Additional notes: | |
| 40 | -<ol> | |
| 41 | -<li>The option "--port NNN" will start the server on port | |
| 42 | -"NNN" instead of 8080. | |
| 43 | -<li>If port 8080 is already being used (perhaps by another Fossil server), then | |
| 44 | -Fossil will use the next available port number. | |
| 45 | -<li>The "server" and "ui" commands are an excellent options | |
| 46 | -for quickly sharing with coworkers on a small network. | |
| 47 | -<li>This deployment scenario does not require special "root" or | |
| 48 | -"administrator" access in order to share the repository. | |
| 49 | -</ol> | |
| 43 | +<p> | |
| 44 | +Both commands have additional command-line options that can be used to refine | |
| 45 | +their behavior. See the [/help/server|online documentation] for an overview. | |
| 50 | 46 | </p> |
| 51 | 47 | </blockquote> |
| 52 | - | |
| 53 | -<h2>Fossil as an ''inetd'' service</h2><blockquote> | |
| 48 | +<a name="inetd"></a> | |
| 49 | +<h2>Fossil as an inetd/xinetd service</h2><blockquote> | |
| 54 | 50 | <p> |
| 55 | -Modify your <tt>/etc/inetd.conf</tt> (on Linux, modify as appropriate for | |
| 56 | -your platform) so it contains a line like this: | |
| 51 | +A Fossil server can be launched on-demand by inetd or xinetd using | |
| 52 | +the [/help/http|fossil http] command. To launch Fossil from inetd, modify | |
| 53 | +your inetd configuration file (typically "/etc/inetd.conf") to contain a | |
| 54 | +line something like this: | |
| 57 | 55 | <blockquote> |
| 58 | 56 | <pre> |
| 59 | -12345 stream tcp nowait.1000 root /path-to/fossil /path-to/fossil http /other-path-to/repository | |
| 57 | +12345 stream tcp nowait.1000 root /usr/bin/fossil /usr/bin/fossil http /home/fossil/repo.fossil | |
| 60 | 58 | </pre> |
| 61 | 59 | </blockquote> |
| 62 | 60 | In this example, you are telling "inetd" that when an incoming connection |
| 63 | -on port "12345" happens, it should launch the binary "/path-to/fossil". | |
| 61 | +appears on port "12345", that it should launch the binary "/usr/bin/fossil" | |
| 62 | +program with the arguments shown. | |
| 64 | 63 | Obviously you will |
| 65 | -need to modify the "path-to" parts as appropriate for your particular setup. | |
| 64 | +need to modify the pathnames parts as appropriate for your particular setup. | |
| 65 | +The final argument is either the name of the fossil repository to be served, | |
| 66 | +or a directory containing multiple repositories. | |
| 66 | 67 | </p> |
| 67 | 68 | <p> |
| 68 | -If you system is running xinetd, then a typical configuration will be | |
| 69 | -held an a separate file (often named "/etc/xinetd.d/http-alt") that might | |
| 70 | -look something like this:</p> | |
| 69 | +If you system is running xinetd, then the configuration is likely to be | |
| 70 | +in the file "/etc/xinetd.conf" or in a subfile of "/etc/xinetd.d". | |
| 71 | +An xinetd configuration file will appear like this:</p> | |
| 71 | 72 | <blockquote> |
| 72 | 73 | <pre> |
| 73 | 74 | service http-alt |
| 74 | 75 | { |
| 75 | 76 | port = 591 |
| @@ -82,14 +83,16 @@ | ||
| 82 | 83 | </pre> |
| 83 | 84 | </blockquote> |
| 84 | 85 | <p> |
| 85 | 86 | The xinetd example above has Fossil configured to serve multiple |
| 86 | 87 | repositories, contained under the "/home/fossil/repos/" directory. |
| 87 | -All repositories should be named with a ".fossil" suffix. | |
| 88 | -In such a setup, the first element of the request URI should be the | |
| 89 | -name of the repository relative to the /home/fossil/repos/ directory | |
| 90 | -and without the ".fossil" suffix. | |
| 88 | +</p> | |
| 89 | +<p> | |
| 90 | +In both cases notice that Fossil was launched as root. This is not required, | |
| 91 | +but if it is done, then Fossil will automatically put itself into a chroot | |
| 92 | +jail for the user who owns the fossil repository before reading any information | |
| 93 | +off of the wire. | |
| 91 | 94 | </p> |
| 92 | 95 | <p> |
| 93 | 96 | Using inetd or xinetd is a more complex setup |
| 94 | 97 | than the "standalone" server, but it has the |
| 95 | 98 | advantage of only using system resources when an actual connection is |
| @@ -97,82 +100,76 @@ | ||
| 97 | 100 | not (automatically) run. It has the disadvantage of requiring "root" access |
| 98 | 101 | and therefore may not normally be available to lower-priced "shared" servers |
| 99 | 102 | on the internet. |
| 100 | 103 | </p> |
| 101 | 104 | </blockquote> |
| 102 | - | |
| 103 | 105 | <h2>Fossil as CGI</h2><blockquote> |
| 104 | 106 | <p> |
| 105 | -This is the most flexible and most likely to be widely usable of these | |
| 106 | -deployment scenarios. In order for it to work, you must have the | |
| 107 | -ability to install "CGI scripts" on the server you are interested in using. | |
| 107 | +A Fossil server can also be run from an ordinary web server as a CGI program. | |
| 108 | +This feature allows Fossil to be seamlessly integrated into a larger website. | |
| 109 | +CGI is how the [./selfhost.wiki | self-hosting fossil repositories] are | |
| 110 | +implemented. | |
| 108 | 111 | </p> |
| 109 | -</blockquote> | |
| 110 | - | |
| 111 | -<h3>One script per repository</h3><blockquote> | |
| 112 | 112 | <p> |
| 113 | -Create a script (let's call it 'repo') in your CGI directory which has content | |
| 114 | -like this: | |
| 113 | +To run Fossil as CGI, create a CGI script (here called "repo") in the CGI directory | |
| 114 | +of your web server and having content like this: | |
| 115 | 115 | <blockquote><pre> |
| 116 | -#!/path-to/fossil | |
| 117 | -repository: /path-to-repo/repository | |
| 116 | +#!/usr/bin/fossil | |
| 117 | +repository: /home/fossil/repo.fossil | |
| 118 | 118 | </pre></blockquote> |
| 119 | 119 | </p> |
| 120 | 120 | <p> |
| 121 | +As always, adjust your paths appropriately. | |
| 121 | 122 | It may be necessary to set permissions properly, or to modify an ".htaccess" |
| 122 | -file or other server-specific things like that. Consult with your server | |
| 123 | -provider if you need that sort of assistance. | |
| 123 | +file or other server-specific things like that. Consult the documentation | |
| 124 | +for your particular server. | |
| 124 | 125 | </p> |
| 125 | 126 | <p> |
| 126 | 127 | Once the script is set up correctly, and assuming your server is also set |
| 127 | 128 | correctly, you should be able to access your repository with a URL like: |
| 128 | -<tt>http://mydomain.org/cgi-bin/repo</tt> (assuming the "repo" script is | |
| 129 | +<b>http://mydomain.org/cgi-bin/repo</b> (assuming the "repo" script is | |
| 129 | 130 | accessible under "cgi-bin", which would be a typical deployment on Apache |
| 130 | 131 | for instance). |
| 131 | 132 | </p> |
| 132 | -</blockquote> | |
| 133 | - | |
| 134 | -<h3>Serving multiple repositories with one script</h3><blockquote> | |
| 135 | 133 | <p> |
| 136 | -This scenario is almost identical to the previous one. However, here we | |
| 137 | -will assume you have multiple repositories, in one directory. | |
| 138 | -(Call the directory 'fossils'). All repositories served, in this case, must | |
| 139 | -use the ".fossil" filename suffix. | |
| 140 | -As before, create a script (again, 'repo'): | |
| 134 | +To server multiple repositories from a directory using CGI, use the "directory:" | |
| 135 | +tag in the CGI script rather than "repository:". You might also want to add | |
| 136 | +a "notfound:" tag to tell where to redirect if the particular repository requested | |
| 137 | +by the URL is not found: | |
| 141 | 138 | <blockquote><pre> |
| 142 | -#!/path-to/fossil | |
| 143 | -directory: /path-to-repo/fossils | |
| 139 | +#!/usr/bin/fossil | |
| 140 | +directory: /home/fossil/repos | |
| 144 | 141 | notfound: http://url-to-go-to-if-repo-not-found/ |
| 145 | 142 | </pre></blockquote> |
| 146 | 143 | </p> |
| 147 | 144 | <p> |
| 148 | -Once deployed, a URL like: <tt>http://mydomain.org/cgi-bin/repo/XYZ</tt> | |
| 149 | -will serve up the repository "fossils/XYX.fossil" (if it exists). This | |
| 150 | -makes serving multiple projects on one server pretty painless. | |
| 145 | +Once deployed, a URL like: <b>http://mydomain.org/cgi-bin/repo/XYZ</b> | |
| 146 | +will serve up the repository "/home/fossil/repos/XYX.fossil" (if it exists). | |
| 151 | 147 | </p> |
| 152 | 148 | </blockquote> |
| 153 | 149 | |
| 154 | 150 | <h2>Fossil as SCGI</h2><blockquote> |
| 155 | 151 | |
| 156 | 152 | <p> |
| 157 | 153 | The [/help/server|fossil server] command, described above as a way of |
| 158 | -starting a stand-alone web server, can be used for SCGI. Simply add | |
| 154 | +starting a stand-alone web server, can also be used for SCGI. Simply add | |
| 159 | 155 | the --scgi command-line option and the stand-alone server will interpret |
| 160 | 156 | and respond to the SimpleCGI or SCGI protocol rather than raw HTTP. This can |
| 161 | -be used in combination with a webserver (such as Nginx) that does not | |
| 162 | -support CGI. A typical Nginx configuration to support SCGI with Fossil | |
| 163 | -would look something like this: | |
| 157 | +be used in combination with a webserver (such as [http://nginx.org|Nginx]) | |
| 158 | +that does not support CGI. A typical Nginx configuration to support SCGI | |
| 159 | +with Fossil would look something like this: | |
| 164 | 160 | <blockquote><pre> |
| 165 | 161 | location ~ ^/demo_project/ { |
| 166 | 162 | include scgi_params; |
| 167 | 163 | scgi_pass localhost:9000; |
| 168 | 164 | scgi_param SCRIPT_NAME "/demo_project"; |
| 169 | 165 | } |
| 170 | 166 | </pre></blockquote> |
| 171 | 167 | <p> |
| 172 | -Note that Fossil requires either the PATH_INFO or the SCRIPT_NAME variable | |
| 173 | -in order to function properly, but Nginx provides neither by default. | |
| 168 | +Note that Fossil requires the SCRIPT_NAME variable | |
| 169 | +in order to function properly, but Nginx provides does not provide this | |
| 170 | +variable by default. | |
| 174 | 171 | So it is necessary to provide the SCRIPT_NAME parameter in the configuration. |
| 175 | 172 | Failure to do this will cause Fossil to return an error. |
| 176 | 173 | </p> |
| 177 | 174 | <p> |
| 178 | 175 | All of the features of the stand-alone server mode described above, |
| @@ -233,7 +230,5 @@ | ||
| 233 | 230 | host the server yourself, in which case you will need to allocate |
| 234 | 231 | resources to deal with administration issues. |
| 235 | 232 | </p> |
| 236 | 233 | |
| 237 | 234 | </blockquote> |
| 238 | - | |
| 239 | -</nowiki> | |
| 240 | 235 |
| --- www/server.wiki | |
| +++ www/server.wiki | |
| @@ -1,75 +1,76 @@ | |
| 1 | <title>How To Configure A Fossil Server</title> |
| 2 | <nowiki> |
| 3 | <p>This guide is intended to help guide you in setting up a Fossil server.</p> |
| 4 | |
| 5 | <h2>Standalone server</h2><blockquote> |
| 6 | The easiest way to set up a Fossil server is to use the <tt>server</tt> or |
| 7 | <tt>ui</tt> command. Assuming the repository you are interested in serving is |
| 8 | in the file "<tt>repo.fossil</tt>", you can use either of these commands to |
| 9 | start Fossil as a server: |
| 10 | <ul> |
| 11 | <li><b>fossil server repo.fossil</b> |
| 12 | <li><b>fossil ui repo.fossil</b> |
| 13 | </ul> |
| 14 | |
| 15 | <p> |
| 16 | Both of these commands start a Fossil server on port 8080 on the local machine, |
| 17 | which can be accessed with the URL: <tt>http://localhost:8080/</tt> using any |
| 18 | handy web browser. The difference between the two commands is that "ui", in |
| 19 | addition to starting the Fossil server, also starts a web browser and points it |
| 20 | to the URL mentioned above, and the "ui" command binds to |
| 21 | the loopback IP address only (127.0.0.1) so that the "ui" command cannot be |
| 22 | used to serve content to a different machine. |
| 23 | </p> |
| 24 | |
| 25 | <p> |
| 26 | If one of the commands above is run from within an option checkout, |
| 27 | then the repository name can be omitted and the checkout is used as |
| 28 | the repository. |
| 29 | </p> |
| 30 | |
| 31 | <p> |
| 32 | Instead of a single repository, the commands above can specify a |
| 33 | directory that contains multiple Fossil repositories named with the |
| 34 | ".fossil" suffix. In this case, the request URL should begin with |
| 35 | the base name of the particular repository that is desired. |
| 36 | </p> |
| 37 | |
| 38 | <p> |
| 39 | Additional notes: |
| 40 | <ol> |
| 41 | <li>The option "--port NNN" will start the server on port |
| 42 | "NNN" instead of 8080. |
| 43 | <li>If port 8080 is already being used (perhaps by another Fossil server), then |
| 44 | Fossil will use the next available port number. |
| 45 | <li>The "server" and "ui" commands are an excellent options |
| 46 | for quickly sharing with coworkers on a small network. |
| 47 | <li>This deployment scenario does not require special "root" or |
| 48 | "administrator" access in order to share the repository. |
| 49 | </ol> |
| 50 | </p> |
| 51 | </blockquote> |
| 52 | |
| 53 | <h2>Fossil as an ''inetd'' service</h2><blockquote> |
| 54 | <p> |
| 55 | Modify your <tt>/etc/inetd.conf</tt> (on Linux, modify as appropriate for |
| 56 | your platform) so it contains a line like this: |
| 57 | <blockquote> |
| 58 | <pre> |
| 59 | 12345 stream tcp nowait.1000 root /path-to/fossil /path-to/fossil http /other-path-to/repository |
| 60 | </pre> |
| 61 | </blockquote> |
| 62 | In this example, you are telling "inetd" that when an incoming connection |
| 63 | on port "12345" happens, it should launch the binary "/path-to/fossil". |
| 64 | Obviously you will |
| 65 | need to modify the "path-to" parts as appropriate for your particular setup. |
| 66 | </p> |
| 67 | <p> |
| 68 | If you system is running xinetd, then a typical configuration will be |
| 69 | held an a separate file (often named "/etc/xinetd.d/http-alt") that might |
| 70 | look something like this:</p> |
| 71 | <blockquote> |
| 72 | <pre> |
| 73 | service http-alt |
| 74 | { |
| 75 | port = 591 |
| @@ -82,14 +83,16 @@ | |
| 82 | </pre> |
| 83 | </blockquote> |
| 84 | <p> |
| 85 | The xinetd example above has Fossil configured to serve multiple |
| 86 | repositories, contained under the "/home/fossil/repos/" directory. |
| 87 | All repositories should be named with a ".fossil" suffix. |
| 88 | In such a setup, the first element of the request URI should be the |
| 89 | name of the repository relative to the /home/fossil/repos/ directory |
| 90 | and without the ".fossil" suffix. |
| 91 | </p> |
| 92 | <p> |
| 93 | Using inetd or xinetd is a more complex setup |
| 94 | than the "standalone" server, but it has the |
| 95 | advantage of only using system resources when an actual connection is |
| @@ -97,82 +100,76 @@ | |
| 97 | not (automatically) run. It has the disadvantage of requiring "root" access |
| 98 | and therefore may not normally be available to lower-priced "shared" servers |
| 99 | on the internet. |
| 100 | </p> |
| 101 | </blockquote> |
| 102 | |
| 103 | <h2>Fossil as CGI</h2><blockquote> |
| 104 | <p> |
| 105 | This is the most flexible and most likely to be widely usable of these |
| 106 | deployment scenarios. In order for it to work, you must have the |
| 107 | ability to install "CGI scripts" on the server you are interested in using. |
| 108 | </p> |
| 109 | </blockquote> |
| 110 | |
| 111 | <h3>One script per repository</h3><blockquote> |
| 112 | <p> |
| 113 | Create a script (let's call it 'repo') in your CGI directory which has content |
| 114 | like this: |
| 115 | <blockquote><pre> |
| 116 | #!/path-to/fossil |
| 117 | repository: /path-to-repo/repository |
| 118 | </pre></blockquote> |
| 119 | </p> |
| 120 | <p> |
| 121 | It may be necessary to set permissions properly, or to modify an ".htaccess" |
| 122 | file or other server-specific things like that. Consult with your server |
| 123 | provider if you need that sort of assistance. |
| 124 | </p> |
| 125 | <p> |
| 126 | Once the script is set up correctly, and assuming your server is also set |
| 127 | correctly, you should be able to access your repository with a URL like: |
| 128 | <tt>http://mydomain.org/cgi-bin/repo</tt> (assuming the "repo" script is |
| 129 | accessible under "cgi-bin", which would be a typical deployment on Apache |
| 130 | for instance). |
| 131 | </p> |
| 132 | </blockquote> |
| 133 | |
| 134 | <h3>Serving multiple repositories with one script</h3><blockquote> |
| 135 | <p> |
| 136 | This scenario is almost identical to the previous one. However, here we |
| 137 | will assume you have multiple repositories, in one directory. |
| 138 | (Call the directory 'fossils'). All repositories served, in this case, must |
| 139 | use the ".fossil" filename suffix. |
| 140 | As before, create a script (again, 'repo'): |
| 141 | <blockquote><pre> |
| 142 | #!/path-to/fossil |
| 143 | directory: /path-to-repo/fossils |
| 144 | notfound: http://url-to-go-to-if-repo-not-found/ |
| 145 | </pre></blockquote> |
| 146 | </p> |
| 147 | <p> |
| 148 | Once deployed, a URL like: <tt>http://mydomain.org/cgi-bin/repo/XYZ</tt> |
| 149 | will serve up the repository "fossils/XYX.fossil" (if it exists). This |
| 150 | makes serving multiple projects on one server pretty painless. |
| 151 | </p> |
| 152 | </blockquote> |
| 153 | |
| 154 | <h2>Fossil as SCGI</h2><blockquote> |
| 155 | |
| 156 | <p> |
| 157 | The [/help/server|fossil server] command, described above as a way of |
| 158 | starting a stand-alone web server, can be used for SCGI. Simply add |
| 159 | the --scgi command-line option and the stand-alone server will interpret |
| 160 | and respond to the SimpleCGI or SCGI protocol rather than raw HTTP. This can |
| 161 | be used in combination with a webserver (such as Nginx) that does not |
| 162 | support CGI. A typical Nginx configuration to support SCGI with Fossil |
| 163 | would look something like this: |
| 164 | <blockquote><pre> |
| 165 | location ~ ^/demo_project/ { |
| 166 | include scgi_params; |
| 167 | scgi_pass localhost:9000; |
| 168 | scgi_param SCRIPT_NAME "/demo_project"; |
| 169 | } |
| 170 | </pre></blockquote> |
| 171 | <p> |
| 172 | Note that Fossil requires either the PATH_INFO or the SCRIPT_NAME variable |
| 173 | in order to function properly, but Nginx provides neither by default. |
| 174 | So it is necessary to provide the SCRIPT_NAME parameter in the configuration. |
| 175 | Failure to do this will cause Fossil to return an error. |
| 176 | </p> |
| 177 | <p> |
| 178 | All of the features of the stand-alone server mode described above, |
| @@ -233,7 +230,5 @@ | |
| 233 | host the server yourself, in which case you will need to allocate |
| 234 | resources to deal with administration issues. |
| 235 | </p> |
| 236 | |
| 237 | </blockquote> |
| 238 | |
| 239 | </nowiki> |
| 240 |
| --- www/server.wiki | |
| +++ www/server.wiki | |
| @@ -1,75 +1,76 @@ | |
| 1 | <title>How To Configure A Fossil Server</title> |
| 2 | <p>A server is not necessary to use Fossil, but it does help in collaborating with |
| 3 | peers. This article is a guide for setting up a Fossil server.</p> |
| 4 | <h2>Overview</h2><blockquote> |
| 5 | There are basically four ways to set up a Fossil server: |
| 6 | <ol> |
| 7 | <li>A stand-alone server |
| 8 | <li>Using inetd or xinetd |
| 9 | <li>[https://en.wikipedia.org/wiki/Common_Gateway_Interface|CGI] |
| 10 | <li>[http://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface|SCGI] |
| 11 | </ol> |
| 12 | Each of these can serve either a single repository, or a directory hierarchy |
| 13 | containing many repositories with names ending in ".fossil". |
| 14 | </blockquote> |
| 15 | <a name="standalone"></a> |
| 16 | <h2>Standalone server</h2><blockquote> |
| 17 | The easiest way to set up a Fossil server is to use either the |
| 18 | [/help/server|server] or the [/help/ui|ui] commands: |
| 19 | <ul> |
| 20 | <li><b>fossil server</b> <i>REPOSITORY</i> |
| 21 | <li><b>fossil ui</b> <i>REPOSITORY</i> |
| 22 | </ul> |
| 23 | <p> |
| 24 | The <i>REPOSITORY</i> argument is either the name of the repository file, or |
| 25 | a directory containing many repositories. |
| 26 | Both of these commands start a Fossil server, usually on TCP port 8080, though |
| 27 | a higher numbered port might also be used if 8080 is already occupied. You can |
| 28 | access these using URLs of the form <b>http://localhost:8080/</b>, or if |
| 29 | <i>REPOSITORY</i> is a directory, URLs of the form |
| 30 | <b>http://localhost:8080/</b><i>repo</i><b>/</b> where <i>repo</i> is the base |
| 31 | name of the repository file without the ".fossil" suffix. |
| 32 | The difference between "ui" and "server" is that "ui" will |
| 33 | also start a web browser and points it |
| 34 | to the URL mentioned above, and "ui" command binds to |
| 35 | the loopback IP address (127.0.0.1) only so that the "ui" command cannot be |
| 36 | used to serve content to a different machine. |
| 37 | </p> |
| 38 | <p> |
| 39 | If one of the commands above is run from within an option checkout, |
| 40 | then the <i>REPOSITORY</i> argument can be omitted and the checkout is used as |
| 41 | the repository. |
| 42 | </p> |
| 43 | <p> |
| 44 | Both commands have additional command-line options that can be used to refine |
| 45 | their behavior. See the [/help/server|online documentation] for an overview. |
| 46 | </p> |
| 47 | </blockquote> |
| 48 | <a name="inetd"></a> |
| 49 | <h2>Fossil as an inetd/xinetd service</h2><blockquote> |
| 50 | <p> |
| 51 | A Fossil server can be launched on-demand by inetd or xinetd using |
| 52 | the [/help/http|fossil http] command. To launch Fossil from inetd, modify |
| 53 | your inetd configuration file (typically "/etc/inetd.conf") to contain a |
| 54 | line something like this: |
| 55 | <blockquote> |
| 56 | <pre> |
| 57 | 12345 stream tcp nowait.1000 root /usr/bin/fossil /usr/bin/fossil http /home/fossil/repo.fossil |
| 58 | </pre> |
| 59 | </blockquote> |
| 60 | In this example, you are telling "inetd" that when an incoming connection |
| 61 | appears on port "12345", that it should launch the binary "/usr/bin/fossil" |
| 62 | program with the arguments shown. |
| 63 | Obviously you will |
| 64 | need to modify the pathnames parts as appropriate for your particular setup. |
| 65 | The final argument is either the name of the fossil repository to be served, |
| 66 | or a directory containing multiple repositories. |
| 67 | </p> |
| 68 | <p> |
| 69 | If you system is running xinetd, then the configuration is likely to be |
| 70 | in the file "/etc/xinetd.conf" or in a subfile of "/etc/xinetd.d". |
| 71 | An xinetd configuration file will appear like this:</p> |
| 72 | <blockquote> |
| 73 | <pre> |
| 74 | service http-alt |
| 75 | { |
| 76 | port = 591 |
| @@ -82,14 +83,16 @@ | |
| 83 | </pre> |
| 84 | </blockquote> |
| 85 | <p> |
| 86 | The xinetd example above has Fossil configured to serve multiple |
| 87 | repositories, contained under the "/home/fossil/repos/" directory. |
| 88 | </p> |
| 89 | <p> |
| 90 | In both cases notice that Fossil was launched as root. This is not required, |
| 91 | but if it is done, then Fossil will automatically put itself into a chroot |
| 92 | jail for the user who owns the fossil repository before reading any information |
| 93 | off of the wire. |
| 94 | </p> |
| 95 | <p> |
| 96 | Using inetd or xinetd is a more complex setup |
| 97 | than the "standalone" server, but it has the |
| 98 | advantage of only using system resources when an actual connection is |
| @@ -97,82 +100,76 @@ | |
| 100 | not (automatically) run. It has the disadvantage of requiring "root" access |
| 101 | and therefore may not normally be available to lower-priced "shared" servers |
| 102 | on the internet. |
| 103 | </p> |
| 104 | </blockquote> |
| 105 | <h2>Fossil as CGI</h2><blockquote> |
| 106 | <p> |
| 107 | A Fossil server can also be run from an ordinary web server as a CGI program. |
| 108 | This feature allows Fossil to be seamlessly integrated into a larger website. |
| 109 | CGI is how the [./selfhost.wiki | self-hosting fossil repositories] are |
| 110 | implemented. |
| 111 | </p> |
| 112 | <p> |
| 113 | To run Fossil as CGI, create a CGI script (here called "repo") in the CGI directory |
| 114 | of your web server and having content like this: |
| 115 | <blockquote><pre> |
| 116 | #!/usr/bin/fossil |
| 117 | repository: /home/fossil/repo.fossil |
| 118 | </pre></blockquote> |
| 119 | </p> |
| 120 | <p> |
| 121 | As always, adjust your paths appropriately. |
| 122 | It may be necessary to set permissions properly, or to modify an ".htaccess" |
| 123 | file or other server-specific things like that. Consult the documentation |
| 124 | for your particular server. |
| 125 | </p> |
| 126 | <p> |
| 127 | Once the script is set up correctly, and assuming your server is also set |
| 128 | correctly, you should be able to access your repository with a URL like: |
| 129 | <b>http://mydomain.org/cgi-bin/repo</b> (assuming the "repo" script is |
| 130 | accessible under "cgi-bin", which would be a typical deployment on Apache |
| 131 | for instance). |
| 132 | </p> |
| 133 | <p> |
| 134 | To server multiple repositories from a directory using CGI, use the "directory:" |
| 135 | tag in the CGI script rather than "repository:". You might also want to add |
| 136 | a "notfound:" tag to tell where to redirect if the particular repository requested |
| 137 | by the URL is not found: |
| 138 | <blockquote><pre> |
| 139 | #!/usr/bin/fossil |
| 140 | directory: /home/fossil/repos |
| 141 | notfound: http://url-to-go-to-if-repo-not-found/ |
| 142 | </pre></blockquote> |
| 143 | </p> |
| 144 | <p> |
| 145 | Once deployed, a URL like: <b>http://mydomain.org/cgi-bin/repo/XYZ</b> |
| 146 | will serve up the repository "/home/fossil/repos/XYX.fossil" (if it exists). |
| 147 | </p> |
| 148 | </blockquote> |
| 149 | |
| 150 | <h2>Fossil as SCGI</h2><blockquote> |
| 151 | |
| 152 | <p> |
| 153 | The [/help/server|fossil server] command, described above as a way of |
| 154 | starting a stand-alone web server, can also be used for SCGI. Simply add |
| 155 | the --scgi command-line option and the stand-alone server will interpret |
| 156 | and respond to the SimpleCGI or SCGI protocol rather than raw HTTP. This can |
| 157 | be used in combination with a webserver (such as [http://nginx.org|Nginx]) |
| 158 | that does not support CGI. A typical Nginx configuration to support SCGI |
| 159 | with Fossil would look something like this: |
| 160 | <blockquote><pre> |
| 161 | location ~ ^/demo_project/ { |
| 162 | include scgi_params; |
| 163 | scgi_pass localhost:9000; |
| 164 | scgi_param SCRIPT_NAME "/demo_project"; |
| 165 | } |
| 166 | </pre></blockquote> |
| 167 | <p> |
| 168 | Note that Fossil requires the SCRIPT_NAME variable |
| 169 | in order to function properly, but Nginx provides does not provide this |
| 170 | variable by default. |
| 171 | So it is necessary to provide the SCRIPT_NAME parameter in the configuration. |
| 172 | Failure to do this will cause Fossil to return an error. |
| 173 | </p> |
| 174 | <p> |
| 175 | All of the features of the stand-alone server mode described above, |
| @@ -233,7 +230,5 @@ | |
| 230 | host the server yourself, in which case you will need to allocate |
| 231 | resources to deal with administration issues. |
| 232 | </p> |
| 233 | |
| 234 | </blockquote> |
| 235 |