-
-
Notifications
You must be signed in to change notification settings - Fork 130
System Requirements
Gravity Sync requires two Pi-hole 5.x instances running on two separate hosts. These Pi-hole instances should be already be deployed and verified to be functional, prior to the installation of Gravity Sync. Unless otherwise specified, Gravity Sync is always developed against the latest version of Pi-hole that is generally available. It is also recommended that you validate that you're using a Linux distributions that Pi-hole is certified to run on.
- When running Pi-hole inside of a container, only the official Pi-hole Docker image is supported.
- For both standard and container based Pi-hole deployments, Gravity Sync will run directly on the host OS and not inside of the container image.
- Containers must use bind mounts to present the local Pi-hole configuration directories to the container, not Docker volumes.
- You can mix/match standard and container based deployments of Pi-hole, or use different underlying Linux distributions, in the same Gravity Sync deployment.
The Gravity Sync installer will perform checks to make sure the required components are available on your system during installation. If any of these components are missing, the installer will attempt to use your system's package manager to add them. If that fails you will have an opportunity to manually install them and then try again.
- Git
- OpenSSH
- Rsync
- Sudo
You will need a user account with operating system level administrator privileges on each Pi-hole host. This can be a dedicated account with sudo
ability, or the system's root
account. During installation, if you're using any account other than root
, it will be given password-less sudo permissions on the system. Even if you are utilizing the system's root
account, the sudo
utility will still need to be installed on the system.
Due to the nature of Pi-hole constantly writing logging to the disk, its can be abusive to the SD card of a Raspberry Pi. Gravity Sync introduces some further storage overhead. Hashing the running databases, taking backups, performing integrity checks, and transferring files between devices. The larger your Pi-hole's database is, the increased time it will take to perform these tasks, and perhaps additional risk of corruption due to failed replication.
When using a Raspberry Pi, it is suggested that you use storage media that can handle the higher IO operations. Using an dedicated USB device for storage, such a small external SSD, is highly recommended. If you have failed or inconsistent Gravity Sync replication sessions, that either don't complete the backup or don't pass the integrity check, storage performance is often the root cause.
While it's not possible to test Gravity Sync on all the places it's technically able to run, this chart outlines the places where it has been tested. Pi-hole has a list of supported platforms if it's a default install, but if your Pi-hole instance is running in a container, it provides more flexibility.
Distro | Version | Pi-hole Type | Notes |
---|---|---|---|
CentOS | 8 Stream | Default/Docker | |
Debian | 11 | Default/Docker | |
Debian | 10 | Default/Docker | |
DietPi | 8.3 | Default | |
Fedora | 35 | Docker | |
Photon | 4.0 | Docker | |
Raspbian | 11 | Default/Docker | |
Rocky | 8.5 | Docker | |
Ubuntu | 21.10 | Default/Docker | |
Ubuntu | 20.04 | Default/Docker |