syntax highlighting for installation.md

This commit is contained in:
Miraty 2024-09-28 18:17:28 +02:00
parent cba12cb24a
commit 549e8bb732

View file

@ -24,7 +24,7 @@ The required sudoers configuration is `sudoers` and can be placed at `/etc/sudoe
Install the `torrc` file as your Tor configuration. The `%include` statement inside it includes configuration files that will be placed inside any subdirectory of `/srv/servnest/tor-config/`, and is central to the way ServNest uses Tor. Install the `torrc` file as your Tor configuration. The `%include` statement inside it includes configuration files that will be placed inside any subdirectory of `/srv/servnest/tor-config/`, and is central to the way ServNest uses Tor.
```shell ```bash
mkdir /srv/servnest/tor-config mkdir /srv/servnest/tor-config
chown -R servnest:tor /srv/servnest/tor-config chown -R servnest:tor /srv/servnest/tor-config
chmod -R u=rwX,g=rX,o= /srv/servnest/tor-config chmod -R u=rwX,g=rX,o= /srv/servnest/tor-config
@ -43,14 +43,14 @@ A local primary Knot DNS server is used for both the registry and name server se
For a public server, at least one secondary server should be set up. As zones can be dynamically added and deleted from the primary server, [catalog zones](https://zones.cat/) should be used. Configuration for a primary and a secondary server can be found respectively at `mkosi.extra/etc/knot/knot-primary.conf` and `mkosi.extra/etc/knot/knot-secondary.conf`. For a public server, at least one secondary server should be set up. As zones can be dynamically added and deleted from the primary server, [catalog zones](https://zones.cat/) should be used. Configuration for a primary and a secondary server can be found respectively at `mkosi.extra/etc/knot/knot-primary.conf` and `mkosi.extra/etc/knot/knot-secondary.conf`.
Add user `servnest` to group `knot` to allow ServNest to send commands to Knot: Add user `servnest` to group `knot` to allow ServNest to send commands to Knot:
```shell ```bash
usermod -aG knot servnest usermod -aG knot servnest
``` ```
#### Database configuration #### Database configuration
Knot configuration must be dynamic, therefore the configuration must stored in database, using: Knot configuration must be dynamic, therefore the configuration must stored in database, using:
```shell ```bash
sudo -u knot knotc conf-import /etc/knot/knot.conf sudo -u knot knotc conf-import /etc/knot/knot.conf
``` ```
@ -61,17 +61,17 @@ The configuration file won't be used by Knot anymore.
Database configuration can be changed using `knotc conf-*` commands, see [Knot DNS 3.2 documentation > Operation > Dynamic configuration](https://www.knot-dns.cz/docs/3.2/html/operation.html#dynamic-configuration). If you don't want to use that and don't want the best uptime possible, you can do the following steps to edit configuration through a plaintext file: Database configuration can be changed using `knotc conf-*` commands, see [Knot DNS 3.2 documentation > Operation > Dynamic configuration](https://www.knot-dns.cz/docs/3.2/html/operation.html#dynamic-configuration). If you don't want to use that and don't want the best uptime possible, you can do the following steps to edit configuration through a plaintext file:
1. Set `enabled` to `false` in `[reg]` and `[ns]` sections of `config.ini` 1. Set `enabled` to `false` in `[reg]` and `[ns]` sections of `config.ini`
2. `knotc conf-export /etc/knot/knot.conf` 2. `knotc conf-export /etc/knot/knot.conf`{.bash}
3. Edit `/etc/knot/knot.conf` 3. Edit `/etc/knot/knot.conf`
4. Stop the Knot DNS daemon 4. Stop the Knot DNS daemon
5. `sudo -u knot knotc conf-import /etc/knot/knot.conf` 5. `sudo -u knot knotc conf-import /etc/knot/knot.conf`{.bash}
6. Restart the Knot DNS daemon 6. Restart the Knot DNS daemon
7. Check for errors in logs: `cat /var/log/knot/knot.log` 7. Check for errors in logs: `cat /var/log/knot/knot.log`{.bash}
8. Reverse the first step to `true` 8. Reverse the first step to `true`
#### Directories #### Directories
```shell ```bash
mkdir /srv/servnest/reg /srv/servnest/ns mkdir /srv/servnest/reg /srv/servnest/ns
chown -R servnest:knot /srv/servnest/reg /srv/servnest/ns chown -R servnest:knot /srv/servnest/reg /srv/servnest/ns
chmod -R u=rwX,g=rwX,o= /srv/servnest/reg /srv/servnest/ns chmod -R u=rwX,g=rwX,o= /srv/servnest/reg /srv/servnest/ns
@ -81,37 +81,37 @@ chmod -R u=rwX,g=rwX,o= /srv/servnest/reg /srv/servnest/ns
In addition to being described in configuration, registry zone files need to be initialized (i.e. SOA and NS records) inside `/srv/servnest/reg/`. In addition to being described in configuration, registry zone files need to be initialized (i.e. SOA and NS records) inside `/srv/servnest/reg/`.
### ServNest core ### ServNest core {#test}
Set up the source code inside `/srv/servnest/core/`: Set up the source code inside `/srv/servnest/core/`:
```shell ```bash
git clone https://code.antopie.org/servnest/servnest/ /srv/servnest/core git clone https://code.antopie.org/servnest/servnest/ /srv/servnest/core
``` ```
Set permissions (except for `.git/` and `db/`): Set permissions (except for `.git/` and `db/`):
```shell ```bash
chmod -R u=rX,g=rX,o= $(find /srv/servnest/core -mindepth 1 -maxdepth 1 ! -name .git ! -name db) chmod -R u=rX,g=rX,o= $(find /srv/servnest/core -mindepth 1 -maxdepth 1 ! -name .git ! -name db)
chown -R servnest:nginx $(find /srv/servnest/core -mindepth 1 -maxdepth 1 ! -name .git ! -name db) chown -R servnest:nginx $(find /srv/servnest/core -mindepth 1 -maxdepth 1 ! -name .git ! -name db)
``` ```
Generate new SQLite database: Generate new SQLite database:
```shell ```bash
sqlite3 /srv/servnest/core/db/servnest.db < /srv/servnest/core/db/schema.sql sqlite3 /srv/servnest/core/db/servnest.db < /srv/servnest/core/db/schema.sql
``` ```
Set permissions for database: Set permissions for database:
```shell ```bash
chmod -R u=rwX,g=,o= /srv/servnest/core/db chmod -R u=rwX,g=,o= /srv/servnest/core/db
chown -R servnest: /srv/servnest/core/db chown -R servnest: /srv/servnest/core/db
``` ```
Initialize database secret keys: Initialize database secret keys:
```shell ```bash
echo "UPDATE params SET value = '$(openssl rand -hex 16)' WHERE name = 'username_salt';" | sqlite3 /srv/servnest/core/db/servnest.db echo "UPDATE params SET value = '$(openssl rand -hex 16)' WHERE name = 'username_salt';" | sqlite3 /srv/servnest/core/db/servnest.db
``` ```
Generate gettext translations: Generate gettext translations:
```shell ```bash
msgfmt /srv/servnest/core/locales/fr/C/LC_MESSAGES/messages.po -o /srv/servnest/core/locales/fr/C/LC_MESSAGES/messages.mo msgfmt /srv/servnest/core/locales/fr/C/LC_MESSAGES/messages.po -o /srv/servnest/core/locales/fr/C/LC_MESSAGES/messages.mo
chmod u=r,g=,o= /srv/servnest/core/locales/fr/C/LC_MESSAGES/messages.mo chmod u=r,g=,o= /srv/servnest/core/locales/fr/C/LC_MESSAGES/messages.mo
chown servnest: /srv/servnest/core/locales/fr/C/LC_MESSAGES/messages.mo chown servnest: /srv/servnest/core/locales/fr/C/LC_MESSAGES/messages.mo
@ -148,7 +148,7 @@ Use `php-fpm.conf` as the PHP-FPM configuration (e.g. in `/etc/php/php-fpm.d/ser
If you are setting up a testing environment, running `certbot` commands in this document without `--test-cert` is probably useless. If you are setting up a testing environment, running `certbot` commands in this document without `--test-cert` is probably useless.
Register an ACME account for Let's Encrypt (production and staging): Register an ACME account for Let's Encrypt (production and staging):
```shell ```bash
certbot register --no-eff-email certbot register --no-eff-email
certbot register --no-eff-email --test-cert certbot register --no-eff-email --test-cert
``` ```
@ -156,13 +156,13 @@ certbot register --no-eff-email --test-cert
Copy and adapt `certbot.ini` in `/etc/letsencrypt/servnest.ini` Copy and adapt `certbot.ini` in `/etc/letsencrypt/servnest.ini`
Install the Certbot deploy hook: Install the Certbot deploy hook:
```shell ```bash
cp certbot-deploy-hook.sh /root/ cp certbot-deploy-hook.sh /root/
chmod +x /root/certbot-deploy-hook.sh chmod +x /root/certbot-deploy-hook.sh
``` ```
Getting a Let's Encrypt certificate for a wildcard domain requires an ACME [DNS challenge](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge). Getting a Let's Encrypt certificate for a wildcard domain requires an ACME [DNS challenge](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge).
```shell ```bash
cp certbot-dns-challenge-hook.sh /root/ cp certbot-dns-challenge-hook.sh /root/
cp certbot-dns-cleanup-hook.sh /root/ cp certbot-dns-cleanup-hook.sh /root/
chmod +x /root/certbot-dns-challenge-hook.sh /root/certbot-dns-cleanup-hook.sh chmod +x /root/certbot-dns-challenge-hook.sh /root/certbot-dns-cleanup-hook.sh
@ -176,14 +176,14 @@ nginx is used for 2 purposes:
* acting as a reverse proxy before Apache, terminating TLS and enforcing headers policy * acting as a reverse proxy before Apache, terminating TLS and enforcing headers policy
Create the ACME HTTP challenge directory used by Certbot: Create the ACME HTTP challenge directory used by Certbot:
```shell ```bash
mkdir /srv/servnest/acme mkdir /srv/servnest/acme
chown nginx: /srv/servnest/acme chown nginx: /srv/servnest/acme
chmod u=rX,g=,o= /srv/servnest/acme chmod u=rX,g=,o= /srv/servnest/acme
``` ```
Generate default self-signed certificates: Generate default self-signed certificates:
```shell ```bash
openssl req -subj '/' -new -newkey RSA:3072 -days 3650 -nodes -x509 -keyout /etc/ssl/private/servnest.key -out /etc/ssl/certs/servnest.crt openssl req -subj '/' -new -newkey RSA:3072 -days 3650 -nodes -x509 -keyout /etc/ssl/private/servnest.key -out /etc/ssl/certs/servnest.crt
openssl req -subj '/CN=servnest.test' -new -newkey RSA:3072 -days 3650 -nodes -x509 -keyout /etc/ssl/private/servnest.test.key -out /etc/ssl/certs/servnest.test.crt openssl req -subj '/CN=servnest.test' -new -newkey RSA:3072 -days 3650 -nodes -x509 -keyout /etc/ssl/private/servnest.test.key -out /etc/ssl/certs/servnest.test.crt
openssl req -subj '/CN=ht.servnest.test' -new -newkey RSA:3072 -days 3650 -nodes -x509 -keyout /etc/ssl/private/ht.servnest.test.key -out /etc/ssl/certs/ht.servnest.test.crt openssl req -subj '/CN=ht.servnest.test' -new -newkey RSA:3072 -days 3650 -nodes -x509 -keyout /etc/ssl/private/ht.servnest.test.key -out /etc/ssl/certs/ht.servnest.test.crt
@ -195,7 +195,7 @@ A precise configuration is inside the `nginx/` directory. It requires the *heade
This configuration listens on `[::1]:42443`, `127.0.0.1:42443`, `[::1]:42080` and `127.0.0.1:42080`. For a public server, these should be replaced respectively by `[::]:443`, `0.0.0.0:443`, `[::]:80` and `0.0.0.0:80`. Other addresses (i.e for Onion services and SFTPGo authentication) are not meant to be publicly exposed. This configuration listens on `[::1]:42443`, `127.0.0.1:42443`, `[::1]:42080` and `127.0.0.1:42080`. For a public server, these should be replaced respectively by `[::]:443`, `0.0.0.0:443`, `[::]:80` and `0.0.0.0:80`. Other addresses (i.e for Onion services and SFTPGo authentication) are not meant to be publicly exposed.
Once this configuration is put in place, replace self-signed certificates by Let's Encrypt certificates: Once this configuration is put in place, replace self-signed certificates by Let's Encrypt certificates:
```shell ```bash
certbot certonly --config "/etc/letsencrypt/servnest.ini" -d "ht.servnest.example" certbot certonly --config "/etc/letsencrypt/servnest.ini" -d "ht.servnest.example"
certbot certonly --config "/etc/letsencrypt/servnest.ini" -d "servnest.example" certbot certonly --config "/etc/letsencrypt/servnest.ini" -d "servnest.example"
``` ```
@ -203,7 +203,7 @@ certbot certonly --config "/etc/letsencrypt/servnest.ini" -d "servnest.example"
The nginx configuration provided above uses the self-signed key pair at the locations set in the `openssl` command above. Replace those by the ones Certbot told you and reload nginx configuration. The nginx configuration provided above uses the self-signed key pair at the locations set in the `openssl` command above. Replace those by the ones Certbot told you and reload nginx configuration.
Allow nginx to access certificates: Allow nginx to access certificates:
```shell ```bash
mkdir -p /etc/letsencrypt/archive/ /etc/letsencrypt/live/ mkdir -p /etc/letsencrypt/archive/ /etc/letsencrypt/live/
chmod 710 /etc/letsencrypt/archive/ /etc/letsencrypt/live/ chmod 710 /etc/letsencrypt/archive/ /etc/letsencrypt/live/
chown root:nginx /etc/letsencrypt/archive/ /etc/letsencrypt/live/ chown root:nginx /etc/letsencrypt/archive/ /etc/letsencrypt/live/
@ -217,7 +217,7 @@ Apache in distributions is usually named `httpd`, `apache` or `apache2`. Adapt t
Apache configuration is inside the `apache/` directory. It runs Apache inside a chroot, though it is not required by the ServNest design. Some paths may need adaptation according to the distribution used (e.g. modules or logs). Apache configuration is inside the `apache/` directory. It runs Apache inside a chroot, though it is not required by the ServNest design. Some paths may need adaptation according to the distribution used (e.g. modules or logs).
Set up the directory where Apache will be chrooted: Set up the directory where Apache will be chrooted:
```shell ```bash
mkdir /srv/servnest/ht mkdir /srv/servnest/ht
cp -r /install/http-messages /srv/servnest/ht/http-messages cp -r /install/http-messages /srv/servnest/ht/http-messages
chown -R root:root /srv/servnest/ht chown -R root:root /srv/servnest/ht
@ -225,14 +225,14 @@ chmod -R u=rX,g=rX,o=rX /srv/servnest/ht
``` ```
Set up the directory managed by SFTPGo users: Set up the directory managed by SFTPGo users:
```shell ```bash
mkdir /srv/servnest/ht/fs mkdir /srv/servnest/ht/fs
chown -R apache:sftpgo /srv/servnest/ht/fs chown -R apache:sftpgo /srv/servnest/ht/fs
chmod -R u=rX,g=rwX,o= /srv/servnest/ht/fs chmod -R u=rX,g=rwX,o= /srv/servnest/ht/fs
``` ```
Set up the directory accessed by Apache and managed by ServNest that maps Web addresses to users directories using links: Set up the directory accessed by Apache and managed by ServNest that maps Web addresses to users directories using links:
```shell ```bash
mkdir /srv/servnest/ht/uri mkdir /srv/servnest/ht/uri
mkdir /srv/servnest/ht/uri/ht.servnest.test # Subpath access mkdir /srv/servnest/ht/uri/ht.servnest.test # Subpath access
chown -R servnest:apache /srv/servnest/ht/uri chown -R servnest:apache /srv/servnest/ht/uri
@ -240,7 +240,7 @@ chmod -R u=rwX,g=rX,o= /srv/servnest/ht/uri
``` ```
For Apache to work in a chroot, hardlinking some system dependencies inside the chroot may be needed: For Apache to work in a chroot, hardlinking some system dependencies inside the chroot may be needed:
```shell ```bash
# Display dependencies paths # Display dependencies paths
ldd $(which httpd) ldd $(which httpd)
@ -257,46 +257,46 @@ ln /usr/lib/libc.so.6 /srv/servnest/ht/usr/lib/libc.so.6
The script at `../root/sftpgo.sh` can be used to build SFTPGo from source. You can use other methods to get SFTPGo builds. The script at `../root/sftpgo.sh` can be used to build SFTPGo from source. You can use other methods to get SFTPGo builds.
Create a directory for configuration: `mkdir /etc/sftpgo` Create a directory for configuration: `mkdir /etc/sftpgo`{.bash}
Copy the systemd service: `cp /install/sftpgo.service /etc/systemd/system/sftpgo.service` Copy the systemd service: `cp /install/sftpgo.service /etc/systemd/system/sftpgo.service`{.bash}
Allow listening on privileged ports: `setcap 'cap_net_bind_service=+ep' /usr/local/bin/sftpgo` Allow listening on privileged ports: `setcap 'cap_net_bind_service=+ep' /usr/local/bin/sftpgo`{.bash}
#### Configure SFTPGo for ServNest #### Configure SFTPGo for ServNest
Generate a key pair using `ssh-keygen -f /etc/sftpgo/ed25519 -t ed25519 -N "" -C ""` Generate a key pair using `ssh-keygen -f /etc/sftpgo/ed25519 -t ed25519 -N "" -C ""`{.bash}
Compute key pair fingerprints: Compute key pair fingerprints:
```shell ```bash
fp=($(ssh-keygen -l -f /etc/sftpgo/ed25519)) fp=($(ssh-keygen -l -f /etc/sftpgo/ed25519))
echo ${fp[1]} > /etc/sftpgo/ed25519.fp echo ${fp[1]} > /etc/sftpgo/ed25519.fp
ssh-keygen -lv -f /etc/sftpgo/ed25519 | tail -n +2 > /etc/sftpgo/ed25519.asciiart ssh-keygen -lv -f /etc/sftpgo/ed25519 | tail -n +2 > /etc/sftpgo/ed25519.asciiart
``` ```
Copy the SFTPGo configuration: `cp /install/sftpgo.toml /etc/sftpgo/sftpgo.toml`. For a public setup, change `[[sftpd.bindings]]` sections in it to public IPs and port 22. You can optionally set up in `/etc/sftpgo/banner.txt` a message displayed to users when logging in. Copy the SFTPGo configuration: `cp /install/sftpgo.toml /etc/sftpgo/sftpgo.toml`{.bash}. For a public setup, change `[[sftpd.bindings]]` sections in it to public IPs and port 22. You can optionally set up in `/etc/sftpgo/banner.txt` a message displayed to users when logging in.
Add user `servnest` to group `sftpgo`: Add user `servnest` to group `sftpgo`:
```shell ```bash
usermod -aG sftpgo servnest usermod -aG sftpgo servnest
``` ```
Permissions for `/etc/sftpgo`: Permissions for `/etc/sftpgo`:
```shell ```bash
chown -R sftpgo: /etc/sftpgo chown -R sftpgo: /etc/sftpgo
chmod -R u=rX,g=rX,o= /etc/sftpgo chmod -R u=rX,g=rX,o= /etc/sftpgo
chmod u=r,g=,o= /etc/sftpgo/ed25519 chmod u=r,g=,o= /etc/sftpgo/ed25519
``` ```
Generate and add SSHFP record for the public SFTP domain: Generate and add SSHFP record for the public SFTP domain:
```shell ```bash
echo sftp.servnest.test. 86400 SSHFP 4 2 $(cut -d ' ' -f 2 /etc/sftpgo/ed25519.pub | base64 -d | sha256sum | cut -d ' ' -f 1) >> /srv/servnest/reg/servnest.test.zone echo sftp.servnest.test. 86400 SSHFP 4 2 $(cut -d ' ' -f 2 /etc/sftpgo/ed25519.pub | base64 -d | sha256sum | cut -d ' ' -f 1) >> /srv/servnest/reg/servnest.test.zone
``` ```
### ServNest core configuration ### ServNest core configuration
Copy the configuration template to the actual configuration file and adapt it according to [the ServNest configuration reference](configuration.md): Copy the configuration template to the actual configuration file and adapt it according to [the ServNest configuration reference](configuration.md):
```shell ```bash
cp /srv/servnest/core/config.template.ini /srv/servnest/core/config.ini cp /srv/servnest/core/config.template.ini /srv/servnest/core/config.ini
vim /srv/servnest/core/config.ini vim /srv/servnest/core/config.ini
``` ```