---
sidebar_position: 20
---

# Requirements

If you are looking to self-host CDR Link, this page details what is required to run a secure and reliable instance.

The following requirements assume that your deployment framework will be the same as ours.
You may need to adjust the requirements if your framework differs materially, and while we can offer limited support for
this we would not be able to assist with in-depth troubleshooting.

## Deployment Host

:::danger
A compromise of this host effectively compromises the entire stack.
:::

* Appropriately hardened and vendor supported Linux operating system with the latest security updates applied
* SSH key backed by hardware security module and requiring unlock (e.g. [YubiKey](https://www.yubico.com/)) to be used
  for login to the instance host
* [Python](https://www.python.org/) 3.11+ (the `venv` module is included in Python since 3.3 so this is not a separate requirement)
* [Git](https://git-scm.com/)
* [Ansible](https://docs.ansible.com/)-compatible secrets management (e.g.
  [sops](https://getsops.io/) or
  [Bitwarden Secrets Manager](https://bitwarden.com/products/secrets-manager/))

## CDR Link Instance Host

It is **strongly recommended** that this host is dedicated to running the CDR Link software only.

* A [Red Hat Enterprise Linux](https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux)
  9 (or compatible) host with the latest security updates and appropriate hardening applied
* At least 4 (v)CPUs, 15GB RAM, and 75GB disk space
* Separate partitions for `/var`, `/var/log`, `/var/log/audit`, and `/home`
* `/home` must use the
  [XFS](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_file_systems/getting-started-with-xfs_managing-file-systems)
  file system (to apply quotas)
* A global scope IP address assigned to one of the network interfaces
* FirewallD is installed and enabled with only the `ssh` service enabled
  * Our deployment script will add the `http` and `https` services
* An unprivileged user created with 65536
  [subuids and subgids](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/building_running_and_managing_containers/assembly_starting-with-containers_building-running-and-managing-containers#proc_setting-up-rootless-containers_assembly_starting-with-containers)
  assigned that will be used to run the Link stack
* An unprivileged user with sudo permission, and the SSH public key from the deployment host installed as an authorised
  key

In our deployments, we would perform the hardening configuration using our
[baseline Ansible role](https://guardianproject.dev/sr2/ansible-collection-core/src/branch/main/roles/baseline),
however this role is not intended for general use and so may not fit your requirements.
We manage our users, groups, and subordinate IDs using
[Identity Management](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/installing_identity_management/index)
but a locally created user can also be used.

:::warning
Depending on your configuration it is also possible to use an LDAP user with locally defined subuids and subgids however
be aware that this may lead to conflicts between hosts, and complications if file system snapshots or backups are
available across hosts.
:::

## CDR Link Handset (Optional)

The handset is only required if you wish to use the Signal or WhatsApp channels with CDR Link.

It is **strongly recommended** that this handset is dedicated to running the CDR Link related apps only and is stored in
a secure facility.
Consider that the device will require to have its cellular connection available and so it would not be advised to store
the handset, for example, in a metallic container.

:::tip
Many of the handset related support requests we receive are due to partners using the handset directly rather than
allowing CDR Link to manage the channels leading to the system losing synchronisation and then failing to recover.
:::

The handset has the ability to send and receive messages via the helpdesk channels and so should not be frequently moved
between locations to reduce the risk of theft or other loss.

Cheaper handsets often do not receive security updates for Android promptly after their release as there are multiple
steps in the supply chain before an update can be distributed. Ensure that you purchase your handset from a reputable
manufacturer that provides a guaranteed period of security updates and has a track record of timely distribution of
those updates.

* At least Android 14, preferably at least 15 for new deployments, with latest system updates installed
* Google Play Services are required for Signal and WhatsApp
* Cellular plan that can receive SMS and with enough data to allow for system updates
  * SMS required to allow activation of the WhatsApp and Signal accounts 
  * We have seen lower rates of accounts being blocked (automatically flagged as spam or fraud) when using cellular data
    plans as opposed to WiFi
* At least 3GB RAM and 16GB storage
* [Mobile Device Management](https://www.android.com/intl/en_uk/enterprise/management/) for configuration, automatic
  updates and remote wipe capability
* Appropriate hardening, for example:
  * Ensure that a complex screen lock is used
  * Ensure that device encryption is enabled
  * Ensure that developer options are disabled
  * Ensure screen timeout is set
  * Ensure lock screen does not show notifications
  * Disable Bluetooth and WiFi
* 7-day timer to manage charging to avoid failure of the internal battery

:::danger
If you leave the phone permanently connected to the charger, the internal battery of the handset will fail and may pose
a fire hazard.
You should consider any charging of lithium-ion batteries in your local site risk assessments.
:::
