# Theo-soft NAS
###### tags: `cluster` `theo-soft_NAS`

## To do

* Fix Wake on LAN

## Hardware

* 1 Intel Xeon Processor E3-1240 v6, 4 cores/8 threads 3.7 GHz (4.1 GHz turbo) 8MB of cache
* 4 4GB DDR4
* 6 6TB HDD in hardware RAID setup managed by Areca arc-1224-8i

## Network

* IPv4: 129.175.81.105
* IPv6: fe80::c27:c66:2a36:a668
* DNS name: theo-soft-nas.lps.u-psud.fr
* MAC: ac:1f:6b:7f:69:88

## OS

Ubuntu 20.04.1 LTS (Focal Fossa)

## Storage
### Partitionning

Hardware RAID by Areca controller arc-1224-8i.
Contains 6 disks of 6TB merged into a 24TB RAID volume.
The RAID controller can be accessed during boot (it boots first). To modify or view the configuration, a password is required. It is "0000".

Partitions:
* 186.3GB ext4 partition for `/`
* 21.6TB ext4 partition for `/home`
* 14.9GB of swap

### `/home/share` directory

All users can read and write in `/home/share`.

#### Details

All users should be part of the `users` group. `/home/share` is simply owned by the group and has `770` permissions.
Users created with `adduser` are automatically assigned to the `users` group, and their home directory created with permissions `700` such that only them (and root) can access it (see Administration section).

## Access
### SSH

The NAS can be reached over ssh from the lab's network using

ssh <your username>@theo-soft-nas.lps.u-psud.fr

On first connection attempt, the server will offer it's public key for later authentication. NAS's public keys have the following fingerprints:

SHA256:VetZM2Nk63WGlgGMGsSQqadFZ2Luq6WTesD6HIUx1Ng (ED25519)
SHA256:lJXH//DOP2O3I9XOMuwh1+xaO71ypuZ2ATz2rgIsVac (RSA)

Once a key is accepted, you will be asked for your password.

To avoid typing the full name every time, a section can be added on the client machine in `~/.ssh/config`:

Host theo-soft-nas
Hostname theo-soft-nas.lps.u-psud.fr
User <your username>

Now you only need to type `ssh theo-soft-nas` to connect to the machine. Your password will still be required though.
To avoid typing the password, you can use public key authentication. **The NAS only accepts `ed25519` and `rsa` type public keys.** If you don't have a key pair already, you can generate one with:

ssh-keygen -t ed25519
ssh-keygen -t rsa -b 4096

Then, send your public key to the NAS using

ssh-copy-id theo-soft-nas

You can now connect to the NAS by typing `ssh theo-soft-nas` without being prompted for your password. Note that the generated private keys (`id_rsa` or `id_ed25519`) grant access to your account on every machine that knows about them, so they should be **kept secret**.

### Fail2ban

Fail2ban is running on the machine to prevent brute force attacks on ssh passwords.
If one enters a bad password more than 5 times in a 10 minutes window, its IP address is banned for the next 10 minutes.

The status of the jail can be checked by privileged users using

fail2ban-client status sshd

Fail2ban logs can be found in `/var/log/fail2ban.log`.

To unban an IP before the end of the sentence, run

fail2ban-client set sshd unbanip IP_ADDRESS_TO_UNBAN

### Wake On LAN
FIXME
The machine supports Wake On LAN. To power it up from a Linux machine connected to the lab's internal network, use for instance:

wakeonlan -i 129.175.81.105 ac:1f:6b:7f:69:88

## Administration
Root account is disabled and all administration is done via sudo.
Current sudoers are:
* Susana
* Etienne
* Frank
* Giuseppe

Feel free to ask if you need to set-up a new user, or anything else !

### User creation with `adduser`

Prefer `adduser` over `useradd` for user creation: the former calls the latter but also permits more flexible administration.
In particular, the script `/usr/local/sbin/adduser.local` is run after each user creation. Commands it contains so far:
* Force user to change their password on first login

Some default values for new users can be set in `/etc/adduser.conf`. Modifications from default:
* `USERGROUPS=no` disables the creation of one group per user at user creation
* `USERS_GID=100` new users are created with primary group `users (gid 100)`
* `DIR_MODE=0700` makes home directory of users only accessible to them

If `useradd` is used instead of `adduser`, the configurations above are not performed (default user group, home permissions).

### User deletion with `deluser`

Users can be deleted with `deluser`. To remove the home and mail spool properly, `--remove-home` can be added.

A message might be displayed warning that the group `user` is now empty. This is not true, it is simply that it is the *primary* group of all users, and hence, usernames of the members do not appear in `/etc/group`.

## Software
Here we put some technical details about some software installation.

### BorgBackup

#### What is borg

Borg website : https://borgbackup.org
Documentation : https://borgbackup.readthedocs.io/en/stable/index.html

Reasons for choosing borg :

* Simple enough : you start by initialising a borg repository, in which you can later save as many backups as you like in so-called "archives". The set of commands is limited to the useful, but proposes options for more advanced tweaking.
* Command line : Everything is done in a terminal, using a few well-documented, pretty simple commands. Special care has been taken to make it easy to automatebackups using simple bash scripts.
* Efficient : Borg uses deduplication within repositories. The backuped data is chunked, and only chunkes that have never been seen before are actually saved.This makes the storage efficient while keeping restoration easy.
* Easy restore : Repositories or archives (backups stored in repo) can be directly mounted as filesystems. This allows easy exploration and selective restoration of a few files. Faster, complete restorations are also available.
* Works over ssh : Works nicely over ssh to perform remote backups. Borg needs to be installed on the client. If it is also installed on the server (it is the case for us), then some of the operations are shared and performances are improved.
* Compression : a full range of compression is proposed, from slow and high compression to fast and small compression.
* Encryption : Borg repositories can be (client-side) encryped.

#### Quickstart

Documentation provided by borg :
https://borgbackup.readthedocs.io/en/stable/quickstart.html

#### Super-quickstart

The directory `/home/share/borgbackup_example` contains simple example scripts to set up a borg repository and start backups. The scripts are intended to be **run on the machine to backup**.
For a more in depth explanation, refer to borg documentation.

##### Installation

The first task is to install Borg on the client machine. Please consider using `borg >= 1.1.11` since earlier versions have known bugs and might not be fully compatible with the version installed on the NAS. See https://borgbackup.readthedocs.io/en/stable/installation.html

##### Repository creation

Then, we need to create a Borg repository with `borg init` command. Repository creation needs only to be performed once.
Read, modify and run `init.sh`.
If you encrypted you repository with `repokey`, remember to print the file `PRINTME_key`. If, because of *very* bad luck, the key in the repository gets corrupted by a memory failure, you repository will be unusable without it.

##### Backup

The repo is now ready to receive backups.
Read and modify the example script`backup.sh`.
It will backup all paths specified in `to_backup`, excluding paths found in `to_exclude`. These files must contain one pattern per line. The usual wildcard `*` is allowed. The settings in the example files backup the whole system, excluding things that are meaningless to backup.

In addition, the script prunes the repository to keep only the last 3 backups. A more precise scheme can easily be implemented. For instance, replacing `--keep-last=3` by `--keep-daily=7 --keep-weekly=4 --keep-monthly=3` will prune the repository such that the last backup of the day is kept for the 7 last days (days without backup don't count), the last backup of the week is kept for the 4 last weeks and the last backup of the month is kept for the 3 last months.
See https://borgbackup.readthedocs.io/en/stable/usage/prune.html for details.
You can simply rerun the script every time you want to backup. Note that the first backup will likely take some time, but subsequent ones will be significantly faster.

##### Restoration

Borg repositories or archives can be mounted as usual filesystems (also works over ssh) using `borg mount` command. See https://borgbackup.readthedocs.io/en/stable/usage/mount.html. This makes exploration and selective restoration handy, at the cost of performance.

For better performances on large restorations, or if you know exactly which files you want to restore, prefer `borg extract` command. See https://borgbackup.readthedocs.io/en/stable/usage/extract.html.

##### Automation

Backups can be automated using, for instance, a `cron` task. If the repository is encrypted, environnement variables must be used in the script to supply the passphrase.
Refer to https://borgbackup.readthedocs.io/en/stable/quickstart.html#automating-backups for details.

#### Backup vs archive

It can be useful to make a distinction between *backuping* and *archiving*.
The first process aims to protect against hardware failures or human mistakes that might require data restoration.
The second process aims to store in an efficient way data that are not immediately necessary anymore, but should be kept in a safe place for future reference.

Though Borg is initially a backup program, it can be used for archiving as well. You could, for instance, store all the data relevant to one finished project into a repository with a high compression factor. The possibility to mount Borg archives as filesystems makes it easy to browse and retrieve some files from a past project.