knowledgebase

Paritybit.ca Gemini-based Wiki
git clone https://git.sr.ht/~jbauer/knowledgebase
Log | Files | Refs | README

commit da13dbac686ebc0a5a63a7da2b9997e2a55a37a2
parent 9106099c1c79f498849b9cbaee1ab9f90d71c225
Author: Jake Bauer <jbauer@paritybit.ca>
Date:   Mon, 21 Feb 2022 17:47:43 -0500

Update server documentation

Diffstat:
Msysadmin/openbsd-server-details.gmi | 49++++++++++++++++++++++++++++++++++++++++++++-----
Msysadmin/openbsd-server-overview.gmi | 4++--
Msysadmin/relaying-service-mail-with-opensmtpd.gmi | 2+-
3 files changed, 47 insertions(+), 8 deletions(-)

diff --git a/sysadmin/openbsd-server-details.gmi b/sysadmin/openbsd-server-details.gmi @@ -16,11 +16,50 @@ inet6 alias 2a01:4ff:f0:f61::1 64 Note that Hetzner routes all IPv6 traffic for their cloud instances through fe80::1. +## TLS Certificates + +OpenBSD's acme-client is used to request certificates. This is the configuration: + +```/etc/acme-client.conf +authority letsencrypt { + api url "https://acme-v02.api.letsencrypt.org/directory" + account key "/etc/acme/letsencrypt-privkey.pem" +} + +domain paritybit.ca { + alternative names { www.paritybit.ca, ftp.paritybit.ca, git.paritybit.ca, jbauer.ca } + domain key "/etc/ssl/private/paritybit.ca.key" + domain full chain certificate "/etc/ssl/paritybit.ca.fullchain.pem" + sign with letsencrypt +} +``` + +Renewing the certificates is handled by /etc/monthly.local, which is run by cron once a month. The output is sent to me in an email. + +```/etc/monthly.local +next_part "Renewing TLS certificate(s):" +acme-client -v -F paritybit.ca +rcctl reload relayd httpd +``` + +## Daily Jobs + +A series of jobs are run daily to provide a daily report of basic server status. This is configured in /etc/daily.local: + +```/etc/daily.local +next_part "Checking for updates:" +pkg_add -un 2>&1 +next_part "Checking for available system patches:" +syspatch -c +next_part "Disk usage report:" +df -h +``` + ## HTTP Server All of the domains are served by the following httpd configuration. It also handles the file server since that is done over http. -```httpd +```/etc/httpd.conf types { include "/usr/share/misc/mime.types" } @@ -123,13 +162,13 @@ vger configuration is extremely simple, since it just uses inetd and relayd: This is the inetd configuration: -```inetd +```/etc/inetd.conf 127.0.0.1:11965 stream tcp nowait _vger /usr/local/bin/vger vger ``` And this is the relayd configuration: -```relayd +```/etc/relayd.conf log connection tcp protocol "gemini" { tls keypair paritybit.ca @@ -148,7 +187,7 @@ relay "gemini" { The configuration in inetd for fingerd is: -```inetd +```/etc/inetd.conf finger stream tcp nowait _fingerd /usr/libexec/fingerd fingerd -lsmu finger stream tcp6 nowait _fingerd /usr/libexec/fingerd fingerd -lsmu ``` @@ -159,7 +198,7 @@ A user (jbauer) was created with ~/.plan and ~/.project files which are displaye The static pages generated by stagit are served using the configuration in httpd.conf. Git repositories live in /var/git and updates are pushed there using SSH. The git daemon for cloning using the git:// protocol is invoked using inetd with the following configuration: -```inetd +```/etc/inetd.conf git stream tcp nowait _gitdaemon /usr/local/bin/git git daemon --inetd --verbose --base-path=/var/git --export-all /var/git/ git stream tcp6 nowait _gitdaemon /usr/local/bin/git git daemon --inetd --verbose --base-path=/var/git --export-all /var/git/ ``` diff --git a/sysadmin/openbsd-server-overview.gmi b/sysadmin/openbsd-server-overview.gmi @@ -49,7 +49,7 @@ OpenBSD's inetd is used to call OpenBSD's fingerd. ### Git Server -The "git server" is really nothing more than a git daemon to handle pushes and pulls and stagit to generate static pages for each repository so code and changes can be browsed from a web browser. +The "git server" is really nothing more than a git daemon to handle cloning/fetching/pulling and stagit to generate static pages for each repository so code and changes can be browsed from a web browser. SSH is used to push changes to the server, and the git daemon is invoked using OpenBSD's inetd. => https://codemadness.org/git/stagit/file/README.html stagit @@ -63,7 +63,7 @@ All of these services are run on the host machine. No "containers", "jails", or ### Backups and Snapshots -This server is not backed up. Configuration files are saved both here in this wiki and on my personal computer. If those are lost, they are easy to re-create anyways. All data on the server already lives in git repositories which are on sourcehut, my own machines, and the server itself. Files served by the file server are not critical and also already exist on my local machines. It is trivial to wipe away the server and re-create it so I have no need to pay extra for automated backups or tarsnap usage. +This server is not backed up. Configuration files are saved both here in this wiki (the content of which is in a git repository also hosted on sourcehut) and on my personal computer. If those are lost, they are easy to re-create anyways. All data on the server already lives in git repositories which are on sourcehut, my own machines, and the server itself. Files served by the file server are not critical and also already exist on my local machines. It is trivial to wipe away the server and re-create it so I have no need to pay extra for automated backups or tarsnap usage. Whenever updates are done or some significant change is needed, I can manually create a snapshot of the VPS in Hetzner's online console. diff --git a/sysadmin/relaying-service-mail-with-opensmtpd.gmi b/sysadmin/relaying-service-mail-with-opensmtpd.gmi @@ -4,7 +4,7 @@ This configuration is very useful for allowing services to send email, especiall This requires an email server which is already set up to accept submissions from remote hosts. I use SMTPS (port 465) but this also works with SMTP+STARTTLS (port 587). -First,create one or more accounts on the central mail server to handle the email (could be servicename@example.com or no-reply@example.com, etc). Creating multiple accounts when using SMTP AUTH is convenient in the case that a machine gets compromised and therefore the password used to authenticate with the mailserver gets compromised. If only one account is used, when you need to change the password for the service account, you need to update the configuration on all machines. On the other hand, one account for all service emails is easier to manage up front. +First, create one or more accounts on the central mail server to handle the email (could be servicename@example.com or no-reply@example.com, etc). Creating multiple accounts when using SMTP AUTH is convenient in the case that a machine gets compromised and therefore the password used to authenticate with the mailserver gets compromised. If only one account is used, when you need to change the password for the service account, you need to update the configuration on all machines. On the other hand, one account for all service emails is easier to manage up front. On the machine which will be sending email, add an alias for the relevant users to `/etc/mail/aliases`. For example: `root: jbauer@paritybit.ca` which will send all emails that would normally be sent to the root user (for output of cron jobs, etc.) to my personal email.