commit - c0f81ed39edc7b35d1b529cebcdb4bc709b38000
commit + fc4b58d450a46d5335ff5a2349c518e6fce42eaf
blob - c62fb3ff7677b0030645be569b6d564ba9265b9e
blob + 3d9f3447a057b968ee6fd2cdada1cdc8b902c02f
--- site/quickstart.gmi
+++ site/quickstart.gmi
gmid will then generate a certificate inside ~/.local/share/gmid and serve the given directory locally.
-To run gmid in daemon mode a configuration file is needed. The format of the configuration file is described in the manpage and is quite flexible, but for simple setup something like the following should be enough:
+## Setting up a capsule with gmid
+To host a Gemini capsule you need to run gmid in “daemon” mode.
+
+To run gmid in daemon mode a configuration file is needed. The format of the configuration file is described in the manpage and is quite flexible, but something like the following should be enough to start:
+
```sample configuration file
# /etc/gmid.conf
}
```
-A X.509 (TLS) certificate can be generated using contrib/gencert
+You also need to generate a certificate for the capsule. A X.509 (TLS) certificate can be generated for e.g. with contrib/gencert
=> https://git.omarpolo.com/gmid/tree/contrib/gencert contrib/gencert
$ gmid -c /etc/gmid.conf
```
+Congratulations, your capsule is online!
+
## Securing your gmid installation
gmid employs various techniques to prevent the damage caused by bugs, but some steps needs to be done manually.
### A dedicated user
-Ideally, gmid should be started with root privileges and drop privileges to a local user. This way, the created certificates can be readable only by root. For example, on GNU/linux systems a ‘gmid’ user can be created with:
+Ideally, gmid should be started as root and drop privileges to a local user. This way, the certificates can be readable only by root. For example, on GNU/linux systems a ‘gmid’ user can be created with:
```how to create the gmid user
# useradd --system --no-create-home -s /bin/nologin -c "gmid Gemini server" gmid
server "example.com" { … }
```
-gmid then needs to be started with root privileges, but will then switch to the provided user automatically. If by accident the ‘user’ is forgotten and gmid is running as root, it will complain loudly in the logs.
+gmid then needs to be started with root privileges, but will then switch to the provided user automatically. If by accident the ‘user’ option is omitted and gmid is running as root, it will complain loudly in the logs.
### chroot
It’s a common practice for system daemons to chroot themselves into a directory. From here on I’ll assume /var/gemini, but it can be any directory.
-A chroot on UNIX-like OS is an operation that changes the “apparent” root directory (i.e. “/”) from the current process and its child. Think of it like imprisoning a process into a directory and never letting it escape until it terminates.
+A chroot on UNIX-like OS is an operation that changes the “apparent” root directory (i.e. the “/”) from the current process and its child. Think of it like imprisoning a process into a directory and never letting it escape until it terminates.
-Using a chroot may complicate the use of CGI scripts, because then all the dependencies of the scripts (like sh, perl, libraries…) need to be installed inside the chroot too. For this very reason gmid supports FastCGI.
+Using a chroot may complicate the use of CGI scripts, because then all the dependencies of the scripts (sh, perl, libraries…) need to be installed inside the chroot too. For this very reason gmid supports FastCGI.
The chroot feature requires a dedicate user, see the previous section.
blob - 3aad5961766a787a23ce264836c95462da205252
blob + 470db033e31872a7d7a0057d5ce83c3a3fa2d656
--- site/quickstart.html
+++ site/quickstart.html
gmid will then generate a certificate inside ~/.local/share/gmid
and serve the given directory locally.
</p>
+ <h2>Setting up a capsule with gmid</h2>
+ <p>To host a Gemini capsule you need to run gmid in “daemon” mode.</p>
<p>
To run gmid in daemon mode a configuration file is needed. The
format of the configuration file is described in the manpage and
- is quite flexible, but for simple setup something like the
- following should be enough:
+ is quite flexible, but something like the following should be
+ enough to start:
</p>
<pre># /etc/gmid.conf
root "/var/gemini/example.com"
}</pre>
<p>
- A X.509 (TLS) certificate can be generated using
+ You also need to generate a certificate for the capsule. A
+ X.509 (TLS) certificate can be generated for e.g. with
<a href="https://git.omarpolo.com/gmid/tree/contrib/gencert">contrib/gencert</a>:
</p>
<pre>$ ./contrib/gencert example.com
</p>
<p>Then running gmid is as easy as</p>
<pre>$ gmid -c /etc/gmid.conf</pre>
+ <p>Congratulations, your capsule is online!</p>
<h2>Securing your gmid installation</h2>
<p>
gmid employs various techniques to prevent the damage caused by
</p>
<h3>A dedicated user</h3>
<p>
- Ideally, gmid should be started with root privileges and drop
- privileges to a local user. This way, the created certificates
- can be readable only by root. For example, on GNU/linux systems
- a ‘gmid’ user can be created with:
+ Ideally, gmid should be started as root and drop privileges to a
+ local user. This way, the certificates can be readable only by
+ root. For example, on GNU/linux systems a ‘gmid’ user can be
+ created with:
</p>
<pre># useradd --system --no-create-home -s /bin/nologin -c "gmid Gemini server" gmid</pre>
<p>
<p>
gmid then needs to be started with root privileges, but will
then switch to the provided user automatically. If by accident
- the ‘user’ is forgotten and gmid is running as root, it will
- complain loudly in the logs.
+ the ‘user’ option is omitted and gmid is running as root, it
+ will complain loudly in the logs.
</p>
<h3>chroot</h3>
<p>
</p>
<p>
A chroot on UNIX-like OS is an operation that changes the
- “apparent” root directory (i.e. “/”) from the current process
- and its child. Think of it like imprisoning a process into a
- directory and never letting it escape until it terminates.
+ “apparent” root directory (i.e. the “/”) from the current
+ process and its child. Think of it like imprisoning a process
+ into a directory and never letting it escape until it
+ terminates.
</p>
<p>
Using a chroot may complicate the use of CGI scripts, because
- then all the dependencies of the scripts (like sh, perl,
- libraries…) need to be installed inside the chroot too. For
- this very reason gmid supports FastCGI.
+ then all the dependencies of the scripts (sh, perl, libraries…)
+ need to be installed inside the chroot too. For this very
+ reason gmid supports FastCGI.
</p>
<p>
The chroot feature requires a dedicate user, see the previous
