Server: Difference between revisions

From Kanthaus wiki
No edit summary
Timber1 (talk | contribs)
Add section about Tor Relay
 
Line 55: Line 55:


Backups are done using Borgmatic. The backup target is the local hard-disk storage, so it does not safe us against fire or theft of the computer. We might think about adding a remote backup as well.
Backups are done using Borgmatic. The backup target is the local hard-disk storage, so it does not safe us against fire or theft of the computer. We might think about adding a remote backup as well.
== Tor Relay ==
We run a [https://metrics.torproject.org/rs.html#details/DB35C03124D5EC03BCFE2754078A48366133EE05 Tor middle/guard relay]. It was set up according to [https://community.torproject.org/relay/setup/guard/debian-ubuntu/ those instructions]. You can check its status with
sudo systemctl status tor@default
It (re)started successfully if the following line (with a different IP) appears in the journal (<code>sudo journalctl -xeu tor@default</code>):
Self-testing indicates your ORPort 84.184.31.103:9001 is reachable from the outside. Excellent. Publishing server descriptor.
However, you don't need to worry too much about it, since [https://chat.kanthaus.online/kanthaus/messages/@timber Timber] will get notified within 5 minutes of the Tor relay being down.
Also note that the Tor relay restarts every night something past 5 since our IP address changes around that time. This is expected behavior and nothing to worry about.
If you're very curious and want to see what happens on the server, you can check out <code>sudo nyx</code>, though be mindful to [https://community.torproject.org/relay/setup/post-install/ not share this data publicly], since it can endanger the anonymity of our users.
The keys of the relay lie in <code>/var/lib/tor/keys</code> and are included in <code>/opt/kh-services/configs/borgmatic.yml</code>, which ''should'' mean that they're being backed up.


== Other services ==
== Other services ==


* Foodsharing Gitlab CI runner (dockerized)
* Foodsharing Gitlab which CI runner (dockerized)
* House bus services
* House bus services
** local Web interface (dockerized)
** local Web interface (dockerized)
** Logging daemon to externally hosted influxdb
** Logging daemon to externally hosted influxdb
* Virtual machines (kvm/libvirt)
* Virtual machines (kvm/libvirt)

Latest revision as of 12:42, 5 December 2024

⭐️ We have a server running locally that provides a few services to residents as well as guests.

File sharing services

The server provides the possibility to store and exchange data. Some services are publicly available (e.g. connecting with an anonymous user), for others you need a user account with some privileges. All file services are only available in the full network and served via Samba. Use your computers file manager to browse the available network computers and locate the server as KANTHAUS-SERVER. If this doesn’t show up in your file manager or the link is broken, you can try entering smb://kanthaus-server/ directly into your file managers address bar. This should work on most Linux environments.

Getting a user account

To get a user account, speak to an admin (e.g. Antonin or Tilmann). The admin will add you to the Ansible user configuration and ask you to set a temporary password using your account. You can change the password yourself, e.g. via smbpasswd -r kanthaus-server -U yourusername.

Actually, you have two passwords:

  • System user account: Used for local access and SSH access. Change password using passwd when logged in
  • Samba account: Used for accessing the samba network shares. Change password using command above remotely or using smbpasswd when logged in.

Kanthaus cloud copy

  • The share kanthaus-public offers an anonymously usable read only copy of the public part of the kanthaus cloud.
  • The share cloud.kanthaus.online offers a read only copy of the whole kanthaus cloud. You need to have a user with the permissions class kanthaus.

The cloud copy is synchronized from the Kanthaus cloud once every minute.

Internal cloud

The share internalcloud stores some data which should only be available from inside Kanthaus (e.g. financial data) and is only available to users with the permissions class internal. Please make sure to only put security sensitive stuff in here and also make sure to not leak your user credentials or the contents of this folder, when you have access to it.

This folder is part of the daily backup.

Home folder

Every user account also has their personal home folder available as the homes storage. All data you put here is only available to yourself. Inside the home folder, there is a directory called storage. This folder lies on an easily expandable, cheap hard-disk storage. It is slower to access but suitable to store lots of data (e.g. backups of your computer).

Your home folder is part of a daily backup. Please put files called .nobackup into folders that you don’t want to be backed up (e.g. to save storage space). The storage folder is not part of the backup, but the hard-disks have a raid configuration to tolerate the loss of one hard-disk.

Shell access

When you have a user account, you can also use SSH to connect to the server and use it for computing tasks. To set an initial password, ask an admin. When you already have file sharing access, you can add your SSH public key to the homes/.ssh/authorized_keys and use that for logging in. Same as above: In your home directory there is a symlinked folder called storage which is on spinning disks, whereby the rest of your home folder is on limited SSD space.

SFTP Access

You can use software like FileZilla to access your home folder through sftp://kanthaus-server providing your username. See the Shell Access section above for other details.

How to unlock the encrypted kanthaus-server via network

  • be in kh-admin
  • ssh -p 2222 root@192.168.178.249
    • your key must be stored on the server in /etc/dropbear-initramfs/authorized_keys -> update-initramfs -u
    • ED25519 key fingerprint: SHA256:mvCVYx8D/Fv/qYq+a/H4MoRAcfExAUsAFW3L2NVHnD0
  • enter password (stored in keepass -> Server)

System specs

  • System is designed to save power but still have some computing resources.
  • CPU: Intel Core i5-2500K (4x 3.3 GHz)
  • Ram: 16 GB DDR3L
  • SSD: 1 TB Samsung 860 Evo as root file system
  • HDD: BTRFS pool with 2 disks. Current usable size 3 TB

Backups

Backups are done using Borgmatic. The backup target is the local hard-disk storage, so it does not safe us against fire or theft of the computer. We might think about adding a remote backup as well.

Tor Relay

We run a Tor middle/guard relay. It was set up according to those instructions. You can check its status with

sudo systemctl status tor@default

It (re)started successfully if the following line (with a different IP) appears in the journal (sudo journalctl -xeu tor@default):

Self-testing indicates your ORPort 84.184.31.103:9001 is reachable from the outside. Excellent. Publishing server descriptor.

However, you don't need to worry too much about it, since Timber will get notified within 5 minutes of the Tor relay being down.

Also note that the Tor relay restarts every night something past 5 since our IP address changes around that time. This is expected behavior and nothing to worry about.

If you're very curious and want to see what happens on the server, you can check out sudo nyx, though be mindful to not share this data publicly, since it can endanger the anonymity of our users.

The keys of the relay lie in /var/lib/tor/keys and are included in /opt/kh-services/configs/borgmatic.yml, which should mean that they're being backed up.

Other services

  • Foodsharing Gitlab which CI runner (dockerized)
  • House bus services
    • local Web interface (dockerized)
    • Logging daemon to externally hosted influxdb
  • Virtual machines (kvm/libvirt)