Fossil

Check-in [dd357f7f]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Fix typos in the "Server" documentation. Also remove the "Security Considerations" paragraph at the end, which seems to be mostly common-sense.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:dd357f7f064a6c03b3b79e255de6c654bb33cc5b
User & Date: drh 2013-09-18 12:46:48
Context
2013-09-18
12:56
Always allow the administrator to moderate attachments. check-in: 41d9de6e user: drh tags: trunk
12:46
Fix typos in the "Server" documentation. Also remove the "Security Considerations" paragraph at the end, which seems to be mostly common-sense. check-in: dd357f7f user: drh tags: trunk
2013-09-17
16:08
Get a 10x speedup on long annotations by indexing a field in the temporary "ancestor" table. check-in: 1c40de18 user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/server.wiki.

38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
..
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
...
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
...
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
...
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
The difference between "ui" and "server" is that "ui" will
also start a web browser and points it
to the URL mentioned above, and "ui" command binds to
the loopback IP address (127.0.0.1) only so that the "ui" command cannot be
used to serve content to a different machine.
</p>
<p>
If one of the commands above is run from within an option checkout,
then the <i>REPOSITORY</i> argument can be omitted and the checkout is used as
the repository.
</p>
<p>
Both commands have additional command-line options that can be used to refine
their behavior.  See the [/help/server|online documentation] for an overview.
</p>
................................................................................
12345 stream tcp nowait.1000 root /usr/bin/fossil /usr/bin/fossil http /home/fossil/repo.fossil
</pre>
</blockquote>
In this example, you are telling "inetd" that when an incoming connection
appears on port "12345", that it should launch the binary "/usr/bin/fossil"
program with the arguments shown.
Obviously you will
need to modify the pathnames parts as appropriate for your particular setup.
The final argument is either the name of the fossil repository to be served,
or a directory containing multiple repositories.
</p>
<p>
If you system is running xinetd, then the configuration is likely to be
in the file "/etc/xinetd.conf" or in a subfile of "/etc/xinetd.d".
An xinetd configuration file will appear like this:</p>
................................................................................
#!/usr/bin/fossil
repository: /home/fossil/repo.fossil
</pre></blockquote>
</p>
<p>
As always, adjust your paths appropriately.
It may be necessary to set permissions properly, or to modify an ".htaccess"
file or other server-specific things like that.  Consult the documentation
for your particular server.
</p>
<p>
Once the script is set up correctly, and assuming your server is also set
correctly, you should be able to access your repository with a URL like:
<b>http://mydomain.org/cgi-bin/repo</b> (assuming the "repo" script is
accessible under "cgi-bin", which would be a typical deployment on Apache
for instance).
................................................................................
in order to function properly, but Nginx does not provide this
variable by default.
So it is necessary to provide the SCRIPT_NAME parameter in the configuration.
Failure to do this will cause Fossil to return an error.
</p>
<p>
All of the features of the stand-alone server mode described above,
such as the ability to server a directory full of Fossil repositories
rather than just a single repository, work the same way in SCGI mode.
</p>
</blockquote>

<h2>Securing a repository with SSL</h2><blockquote>
<p>
Using either CGI or SCGI, it is trivial to use SSL to
................................................................................
support SSL.
</p>
<p>
For more information, see <a href="./ssl.wiki">Using SSL with Fossil</a>.
</p>
</blockquote>

<h2>Various security concerns with hosted repositories</h2><blockquote>
<p>
There are two main concerns relating to usage of Fossil for sharing
sensitive information (source or any other data):
<ul>
<li>Interception of the Fossil synchronization stream, thereby capturing
data, and 
<li>Direct access to the Fossil repository on the server
</ul>
</p>
<p>
Regarding the first, it is adequate to secure the server using SSL, and
disallowing any non-SSL access.  The data stream will be encrypted by
the HTTPS protocol, rendering the data reasonably secure.  The truly
paranoid may wish to deploy <i>ssh</i> encrypted tunnels, but that is
quite a bit more difficult and cumbersome to set up (particularly for
a larger number of users).
</p>
<p>
As far as direct access to the repository, the same steps must be taken
as for any other internet-facing data-store.  Access passwords to any
disk-accessing accounts should be strong (and preferably changed from
time to time).  However, the data in the repository itself are <i>not</i>
encrypted (unless you save encrypted data yourself), and so the system
administrators of your server will be able to access your data (as with
any hosting service setup).  The only workaround in this case is to
host the server yourself, in which case you will need to allocate
resources to deal with administration issues.
</p>

</blockquote>







|







 







|







 







|
|







 







|







 







<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<

38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
..
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
...
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
...
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
...
212
213
214
215
216
217
218






























219
The difference between "ui" and "server" is that "ui" will
also start a web browser and points it
to the URL mentioned above, and "ui" command binds to
the loopback IP address (127.0.0.1) only so that the "ui" command cannot be
used to serve content to a different machine.
</p>
<p>
If one of the commands above is run from within an open checkout,
then the <i>REPOSITORY</i> argument can be omitted and the checkout is used as
the repository.
</p>
<p>
Both commands have additional command-line options that can be used to refine
their behavior.  See the [/help/server|online documentation] for an overview.
</p>
................................................................................
12345 stream tcp nowait.1000 root /usr/bin/fossil /usr/bin/fossil http /home/fossil/repo.fossil
</pre>
</blockquote>
In this example, you are telling "inetd" that when an incoming connection
appears on port "12345", that it should launch the binary "/usr/bin/fossil"
program with the arguments shown.
Obviously you will
need to modify the pathnames for your particular setup.
The final argument is either the name of the fossil repository to be served,
or a directory containing multiple repositories.
</p>
<p>
If you system is running xinetd, then the configuration is likely to be
in the file "/etc/xinetd.conf" or in a subfile of "/etc/xinetd.d".
An xinetd configuration file will appear like this:</p>
................................................................................
#!/usr/bin/fossil
repository: /home/fossil/repo.fossil
</pre></blockquote>
</p>
<p>
As always, adjust your paths appropriately.
It may be necessary to set permissions properly, or to modify an ".htaccess"
file or make other server-specific changes.  Consult the documentation
for your particular web server.
</p>
<p>
Once the script is set up correctly, and assuming your server is also set
correctly, you should be able to access your repository with a URL like:
<b>http://mydomain.org/cgi-bin/repo</b> (assuming the "repo" script is
accessible under "cgi-bin", which would be a typical deployment on Apache
for instance).
................................................................................
in order to function properly, but Nginx does not provide this
variable by default.
So it is necessary to provide the SCRIPT_NAME parameter in the configuration.
Failure to do this will cause Fossil to return an error.
</p>
<p>
All of the features of the stand-alone server mode described above,
such as the ability to serve a directory full of Fossil repositories
rather than just a single repository, work the same way in SCGI mode.
</p>
</blockquote>

<h2>Securing a repository with SSL</h2><blockquote>
<p>
Using either CGI or SCGI, it is trivial to use SSL to
................................................................................
support SSL.
</p>
<p>
For more information, see <a href="./ssl.wiki">Using SSL with Fossil</a>.
</p>
</blockquote>































</blockquote>