Updated System Requirements (markdown)

System-Requirements.md

@@ -1,72 +1,38 @@
-The main requirement is Gravity Sync requires at least two separate Pi-hole 5.x instances. These Pi-hole instances should be already be deployed and verified to be functional, prior to the installation of Gravity Sync.
+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](https://docs.pi-hole.net/main/prerequesites/#supported-operating-systems).
 
-- Only the Linux distributions using systemd that Pi-hole is [certified to run on](https://docs.pi-hole.net/main/prerequesites/#supported-operating-systems) are officially supported. ([More Here](https://github.com/vmstan/gravity-sync/wiki/Frequent-Questions#do-you-support-dietpi-unraid-lxd-something-else))
-- You will need a user account with operating system level administrator privileges at each side. This can be a dedicated account with `sudo` ability, or the system's `root` account. 
-- If you're not using the `root` account, you can only install Gravity Sync in the user's `$HOME` directory.
-- If you're not using the `root` account, make sure that the account is a member of either the `sudo` or `wheel` group on both the primary and secondary Pi-hole. Most of the pre-built images available for the Raspberry Pi already have this configured, as does Ubuntu. 
-- During installation, if you're using any account other than `root`, it will be given [passwordless sudo](https://linuxize.com/post/how-to-run-sudo-command-without-password/) permissions to the system.
+- When running Pi-hole inside of a container, only the [official Pi-hole Docker image](https://hub.docker.com/r/pihole/pihole) 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](https://docs.docker.com/storage/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.
 
-### Containerized Pi-hole
+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.
 
-- Your Pi-hole installs can be a Docker container deployment as of Gravity Sync 3.1.
-- Support for Podman as a container engine has been introduced starting in Gravity Sync 3.3.
-- Gravity Sync will run directly on the host OS, and not inside of the container image.
-- Only the [official Pi-hole Docker image](https://hub.docker.com/r/pihole/pihole) is supported.
-- In addition to the officially supported Linux distributions as outlined above, when using a container engine, host OS deployments on more container oriented distributions such as [VMware Photon OS](https://vmware.github.io/photon/) may be used, so long as they’re able to run the Gravity Sync specific requirements below.
+- 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](https://linuxize.com/post/how-to-run-sudo-command-without-password/) 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.
 
 ### Storage Performance
 
-Pi-hole on its own can be abusive to SD card installs on a Raspberry Pi, due to its constant writes of logging to the disk. Gravity Sync introduces some additional storage overhead to a traditional Pi-hole environment. The replication process of the Domain Database involves:
+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.
 
-- Performing an MD5 hash of the running database
-- Taking backups of the running configuration
-- Performing an SQL integrity check
-- Transferring files across the network 
-- Further hashing to validate 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.
 
-Also the larger your Domain Database is, the increased time it will take to perform these tasks, and perhaps additional risk of corruption due to failed replication.
+### Tested Platforms
 
-When using a Raspberry Pi (or other similar device) as the primary or secondary Pi-hole target, it is suggested that you use storage media that can handle the higher IO operations. This _could_ be a high quality SD card, but an external flash drive, SSD or even a spinning disk is suggested, if available. 
+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.
 
-If you have failed or inconsistent Gravity Sync replication sessions, that either don't complete the backup or don't pass the integrity check, this is often the root cause. 
-
-## Required Components
-
-The installer will perform checks to make sure the required components to use Gravity Sync (such as OpenSSH, etc) are available on both the primary and secondary Pi-hole during installation. 
-
-- OpenSSH
-- Rsync
-- Git
-- Sudo
-- SQLite3
-
-If any of these components are missing, you will have an opportunity to use the package manager utility that is bundled with your Linux distribution to install them. 
-
-### Debian Based (Ubuntu, Raspbian)
-
-```bash
-apt install sqlite3 sudo git rsync ssh
-```
-
-### Redhat Based (CentOS, Fedora)
-
-```
-dnf install sqlite3 sudo git rsync ssh
-```
-
-### Photon OS
-
-```
-tdnf install sqlite3 sudo git rsync ssh
-```
-
-## Pi-hole Architecture
-
-You will need to designate one Pi-Hole as primary and at least one as secondary.
-
-- The primary Pi-hole is where you'll make most of your configuration changes through the Web UI, doing things such as; manual allow-listing, adding block-lists, device/group management, configuring custom/local network DNS, and changing other list settings.
-- The secondary Pi-hole(s) are where you will install and configure Gravity Sync.
-
-The primary Pi-hole will also be referred to in the interface as remote, while the secondary will be referred to as local. This is done to be as confusing as possible and make sure you read the documentation. (Just kidding) The default operation is to pull data from the primary to the secondary, and to put the operational load of Gravity Sync on what is expected to be a less active Pi-hole device.
-
-See also: [Reference Architectures](https://github.com/vmstan/gravity-sync/wiki/Reference-Architectures)
+| 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 | |