Browse Source

added services

pull/1/head
DistroByte 5 months ago
parent
commit
b2f06cd102
No known key found for this signature in database GPG Key ID: 216AF164FD24BD37
8 changed files with 359 additions and 0 deletions
  1. +30
    -0
      docs/services/bind.md
  2. +11
    -0
      docs/services/codimd.md
  3. +33
    -0
      docs/services/gitea.md
  4. +32
    -0
      docs/services/icecast.md
  5. +25
    -0
      docs/services/index.md
  6. +65
    -0
      docs/services/irc.md
  7. +116
    -0
      docs/services/nfs.md
  8. +47
    -0
      docs/services/znapzend.md

+ 30
- 0
docs/services/bind.md View File

@@ -0,0 +1,30 @@
# Bind9 - `distro`, `ylmcc`

Bind9 is our DNS provider. Currently it runs on Paphos, but is being moved to Fred during the restructuring.

## Configuration

The config files for bind are located in `/etc/bind/master/`. The most important file in this directory is the
`db.Redbrick.dcu.ie` file.

{==

You must never update this file without following the steps below first!

==}

## Updating DNS

To update DNS:

1. Change directory to `/etc/bind/master`
2. Back up the `db.Redbrick.dcu.ie` file, usually to `db.Redbrick.dcu.ie.bak`
3. Run `rndc freeze redbrick.dcu.ie` - this stops changes to the file affecting dns while you edit it
4. Edit `db.Redbrick.dcu.ie`
5. Before changing any DNS entry in the file, you **must** edit the serial number on 4. You can increment it by one if
you want, or follow the format: `YYYYMMDDrev` where rev is revision
6. Once you are happy with your file, you can check it with `named-checkzone redbrick.dcu.ie db.Redbrick.dcu.ie`
7. If this returns no errors, you are free to run `rndc thaw redbrick.dcu.ie`
8. Check the status of bind9 by running `service bind9 status`

You can access more logs from bind9 by checking `/var/log/named/default.log`.

+ 11
- 0
docs/services/codimd.md View File

@@ -0,0 +1,11 @@
# CodiMD - `distro`

CodiMD lives on Zeus as a docker container. It is accessible through [md.redbrick.dcu.ie](https://md.redbrick.dcu.ie).

CodiMD is built locally and is based on [codimd](https://github.com/hackmdio/CodiMD), the docs for which are [here](https://hackmd.io/c/codimd-documentation/%2Fs%2Fcodimd-docker-deployment).

Hackmd auths against ldap and its configuration is controlled from docker-compose. Go to
`/etc/docker-compose/services/hackmd` on zeus to find the configuration.

See [CodiMD github](https://github.com/hackmdio/hackmd/#environment-variables-will-overwrite-other-server-configs) for
more info on configuration. The important points are disabling anonymus users and the ldap settings.

+ 33
- 0
docs/services/gitea.md View File

@@ -0,0 +1,33 @@
# Gitea

Redbrick uses [Gitea](https://gitea.io/en-US/) as an open source git host.

- [Gitea docs](https://docs.gitea.io/en-us/)
- [Gogs docs](https://gogs.io/docs), not really important, but Gitea is built on [Gogs](https://gogs.io/)
- [Link to Redbrick deployment](https://git.redbrick.dcu.ie/)

## Deployment

Gitea and its database are deployed to Hardcase which runs NixOS

- The actual repositories are stored in `/zroot/git` and most other data is stored in `/var/lib/gitea`
- The `SECRET_KEY` and `INTERNAL_TOKEN_URI` are stored in `/var/secrets`. They are not automatically created and must be
copied when setting up new hosts. Permissions on the `gitea_token.secret` must be 740 and owned by `git:gitea`
- Make sure that the `gitea_token.secret` does NOT have a newline character in it.

## Other Notes

The Giteadmin credentials are in the passwordsafe.

## Operation

Gitea is very well documented in itself. Here's a couple of special commands when deploying/migrating Gitea to a
different host.

```bash
# Regenerate hooks which fixes push errors
/path/to/gitea admin regenerate hooks

# If you didn't copy the authorized_keys folder then regen that too
/path/to/gitea admin regenerate keys
```

+ 32
- 0
docs/services/icecast.md View File

@@ -0,0 +1,32 @@
# Icecast - `mcmahon`

Icecast is a streaming server that we currently host on Paphos.

We stream DCUFm's Broadcasts to their apps via a stream presented on `dcufm.redbrick.dcu.ie:80`.

They serve an audio stream (stream128.mp3) via butt on a desktop in their studio to `icecast2`.

Icecast requires root privilege to bind to Port 80; normally icecast2 runs as the `icecast2` user and binds to `8001`.

## Procedure

The configuration file for icecast is located at `/etc/icecast2/icecast.xml`.

```bash
<!-- Sources log in with username 'source' --> <-- This is the audio source.
<source-password>$password1</source-password> <-- This must be copied for the DCUFM buttrc.
<!-- Relays log in username 'relay' -->
<relay-password>$password2</relay-password>
<admin-user>admin</admin-user> <-- This is for the WebUI frontend
<admin-password>$password3</admin-password>

<hostname>dcufm.redbrick.dcu.ie</hostname>

<listen-socket>
<port>80</port>
<bind-address>136.206.15.101</bind-address> <-- i.p. addr for dcufm.redbrick.dcu.ie A Record.
```

After that you must configure the default behaviour for the icecast server to allow icecast2 to bind to port 80.

Set `USERID` & `GROUPID` in `/etc/defaults/icecast2` to `root`.

+ 25
- 0
docs/services/index.md View File

@@ -0,0 +1,25 @@
# Preface

Here you will find a list of all the services Redbrick runs, along with some configs and some important information
surrounding them.

## Adding More Services

In order to add a new service, you will need to edit the [docs](https://github.com/redbrick/docs) repository.

Adding a new service is as easy as creating a new file in `docs/services/` with an appropriate name, and adding the
reference to `mkdocs.yml` in the root of the repository.

The style guide for a service file should be as follows:

```md
# ServiceName - `username`

Short description on how the service works and where it is running

## Configuration

Add some possible useful configs here, like a docker-compose file,
certain command you may have had to run, or something that is not very obvious.
Look at other services for hints on this.
```

+ 65
- 0
docs/services/irc.md View File

@@ -0,0 +1,65 @@
# IRC

## Redbrick InspIRCd

In 2016/2017 we began work to move to InspIRCd. This was due to the complications in ircd-hybrid and how old it was.
These complications stopped new netsocs joining us so we all agreed to move irc. $ 4 years later after multiple attempts
we had not migrated. Until TCD decided to shutdown their server breaking the network.

We run Inspircd v3 on Metharme. InspIRCd's docs can be found [here](https://docs.inspircd.org/) for configuration specifics.

IRC is available at `irc.redbrick.dcu.ie` on port `6697`. SSL is required for connection, we do not support non-SSL.

When connecting from a redbrick server a user will be automatically logged in. If connecting from an external server a
user must pass their password on login.

For the purpose of external peering of other servers the port `7001` is expose as well. Similarly to clients we only
support SSL on this port.

For docs on connecting and using an IRC client please refer to the [wiki](https://wiki.redbrick.dcu.ie/index.php/IRC).

## Installation

InspIRCd is installed with Nix. There is no Nix package for InspIRCd so we compile a specific git tag from source. See
[Nix package](https://github.com/redbrick/nix-configs/tree/master/packages/inspircd) for details on how it is compiled.

Given we only support SSL and require LDAP, we need to enable both at compile time.

## Configuration

InspIRCd's configuration is in Nix [here](https://github.com/redbrick/nix-configs/blob/master/services/ircd/inspircd/conf.nix).
This config will be converted to xml on disc.

### Important Configuration

_oper_ is a list of admin users on the irc server. Their `OPER` password will need to be manually hashed with
`hmac-sha256`, and placed in a secret on the server to be read in by inspircd.

_ldapwhitelist_ is a list of cidr addresses that do no require authentication. The list consists of Redbrick public and
private addresses as well as `oldsoc`.

_link_ is a list of all servers we peer with including the anope services server that runs on the same box.

### oldsoc.net

`oldsoc.net` is a server run by old TCD netsocers. All the users on it are the remaining TCD associates following the
shutdown of TCD IRCd. This server is maintained by its own users and has explicit permission to join IRC without LDAP auth.

## Anope

Redbrick runs Anope services for the entire network. As with
[inspircd we compile](https://github.com/redbrick/nix-configs/tree/master/packages/inspircd) from source. Refer to anopes
[github docs](https://github.com/anope/anope/tree/2.0/docs) for configuration specifics.

Our current Anope is configured with standard mods of chanserv, nickserv and operserv. All config is in [here](https://github.com/redbrick/nix-configs/tree/master/services/ircd/anope/confs).

Anope stores all info in a custom db file on disk.

## Discord Bridge - `butlerx`

We run a [bridge](https://github.com/qaisjp/go-discord-irc) between the Redbrick Discord and irc. The configuration for
this is [here](https://github.com/redbrick/nix-configs/tree/master/services/ircd/discord/conf.nix).

The bridge adds all users from discord with the suffix `_d2` and all irc users appear as them self but tagged as a bot
in discord. Not all discord channels are on IRC, the config above contains a mapping of irc channels to discord channels
id's. This needs to be manually updated to add more channels.

+ 116
- 0
docs/services/nfs.md View File

@@ -0,0 +1,116 @@
# NFS / Network File Storage

NFS is used to serve the notorious `/storage` directory on Icarus to all of Redbrick's machines, which in turn serves
`/home`, `/webtree` and some other critical folders.

## Deployment

- NFS is deployed with Nix on Icarus
- It is backed onto the PowerVault MD1200 with all its disk passed through single-drive RAID 0s toallow for setup of ZFS:
- 1 mirror of 2x 500GB drives
- 1 mirror of 2x 750GB drives
- 1 mirror of 2x 1TB drives
- Stripe across all the mirrors for 2TB of usable storage
- 1 hot spare 750GB drive
- ZFS is configured with compression onand dedup off
- The ZFS pool is called `zbackup`

## Redbrick Special Notes

On each machine where `/storage` is where NFS is mounted, but `/home` and `/webtree` are symlinks into there.

There are 2 scripts used to control quotas, detailed below.

NFS is backed up to Albus via [ZnapZend](/services/znapsend.md).

## `zfsquota` and `zfsquotaquery`

These are two bash scripts that run as systemd services on Icarus to manage quotas. This is achieved through getting and
setting the `userquota` and `userused` properties of the ZFS dataset.

### zfsquota

ZFSQuota will read the `quota` field from LDAP and sync this with the userquota value on the dataset. It is not event
driven - it runs on a timer every 3 hours and syncs all LDAP quotas with ZFS. It can be kicked off manually, which is
described below. Users with no quota in LDAP will have no quota in `/storage`, and users who have their quota removed will
persist on ZFS.

Changing user names has no impact on this since it is synced with uidNumber.

### zfsquotaquery

ZFSQuotaQuery returns the quota and used space of a particular user. This is used to then inform `rbquota` which provides
the data for the MOTD used space report. Both of these scripts are defined and deployed in the Nix config repo. It runs on
port 1995/tcp.

## Operation

In general, there isn't too much to do with NFS. Below are some commands of interest for checking its status.

```bash
# On the NFS server, list the exported filesystems
showmount -e

# Get the real space usage + fragmentation percent from ZFS
zpool list zbackup

# Check a user's quota
zpool get userquota@m1cr0man zbackup
zpool get userused@m1cr0man zbackup

# Delete a quota from ZFS (useful if a user is deleted)
zpool set userquota@123456=none zbackup

# Get all user quota usage, and sort it by usage
zfs userspace -o used,name zbackup | sort -h | tee used_space.txt

# Resync quotas (this command will not return until it is finished)
systemctl start zfsquota

# Check the status of zfsquotaquery
systemctl status zfsquotaquery
```

## Troubleshooting

In the event where clients are unable to read from NFS, your priority should be restoring the NFS server, rather than
unmounting NFS from clients. This is because NFS is mounted in `hard` mode everywhere, meaning that it will block on IO
until a request can be fulfilled.

### Check The Server

```bash
# Check the ZFS volume is readable and writable
ls -l /zbackup/home
touch /zbackup/testfile

# Check that rpc.mountd, rpc.statd and rpcbind are running and lisening
ss -anlp | grep rpc

# Check the above services for errors (don't worry about blkmap)
systemctl status nfs-{server,idmapd,mountd}
journalctl -fu nfs-server -u nfs-idmapd -u nfs-mountd
```

### Check The Client

```bash
# Check for connection to NFS
ss -atp | grep nfs

# Check the fstab entry
grep storage /etc/fstab

# Check if the NFS server port can be reached
telnet 192.168.0.150 2049
# Entering gibberish should cause the connection to close

# Remount read-only
mount -o remount,ro /storage

# Not much left you can do but remount entirely or reboot
```

### Rolling Back or Restoring a Backup

See [znapzend](/services/znapzend/)

+ 47
- 0
docs/services/znapzend.md View File

@@ -0,0 +1,47 @@
# ZnapZend

## Overview

[ZnapZend](https://www.znapzend.org/) is used to back up the NFS ZFS dataset from our NFS server to Albus.
It can also be used to back up other ZFS datasets on other hosts, but at the time of writing NFS is the only
thing being backed up this way.

ZnapZend runs on the client and sends backups to Albus over SSH using `zfs send | zfs receive` piping.

The backup strategy can be viewed in the [NixOS configuration](https://github.com/redbrick/nix-configs/blob/5ddaf2097a3267b871368fea73a530e399381b4a/services/znapzend.nix).

## Adding Another Backup

There is not much manual configuration to add a host to the ZnapZend backups.

1. Create an SSH key for the root user with no passphrase on the host you want to send the backups from. Use
`ssh-keygen -t ed25519`.
2. Add this new SSH public key to the rbbackup user's authorized keys on [Albus](https://github.com/redbrick/nix-configs/blob/5ddaf2097a3267b871368fea73a530e399381b4a/hosts/albus/configuration.nix#L32).
3. Try SSHing to `rbbackups@albus.internal` to load the host key and test the passwordless authentication.
4. Import the [znapzend service config](https://github.com/redbrick/nix-configs/blob/5ddaf2097a3267b871368fea73a530e399381b4a/services/znapzend.nix)
on the sending host and configure `redbrick.znapzendSourceDataset` and `redbrick.znapzendDestDataset`. Then apply the config.
**NOTE** The `DestDataset` must be unique across all configured backups/servers.

## Debugging

Znapzend runs at the top of every hour to make backups. You can watch the progress with `journalctl -fu znapzend.service`.
Failures are usually caused by incorrect SSH configuration, so make sure that passwordless auth using the sending host's
root SSH key is working.

## Rolling Back NFS

If the NFS server is online and functional, you do not need to involve Albus to roll back changes, as all the snapshots
are kept on Icarus too.

1. Find the snapshot you want to restore with zfs list -t snapshot.
2. Run zfs rollback $snapshotname.

That's it! These instructions obviously work for backups other than NFS too, should any ever exist.

## Restoring NFS from a backup

If the NFS server has died or you are creating a copy of it, here's how to pull the dataset from Albus,

1. On Albus, find the snapshot you want to restore with `zfs list -t snapshot`.
2. Open a screen/tmux, and copy the snapshot to a dataset in your target ZFS pool with
`ssh albus zfs send -vRLec $snapshotname | zfs receive $newpool/$datasetname`.

Loading…
Cancel
Save