Mega doc update

README.md

@@ -6,7 +6,10 @@ The scripts assumes you have one "master" Pihole as the primary place you make a
 
 ### Prereqs
 
-You will need to make sure your secondary Pihole is setup to authenticate to your primary Pihole via certificates. 
+- This script is designed to work with Pihole 5.0 GA
+- This script has been tested with Ubuntu 20.04 and Rasbian
+
+You'll need to generate an SSH key for your secondary Pihole user and copy it to your primary Pihole. This will allow you to connect to and copy the gravity.db file without needing a password each time.
 
 ```
 ssh-keygen -t rsa
@@ -23,11 +26,11 @@ git clone https://github.com/vmstan/gravity-sync.git
 cd gravity-sync
 ```
 
-Please note the script **must** be run from a folder in your user home directory (ex: /home/pi/gravity-sync)
+Please note the script **must** be run from a folder in your user home directory (ex: /home/pi/gravity-sync) -- I wouldn't suggest changing the folder name.
 
 ### Configuration
 
-After you clone the base configuration, you will need to create a configuration file called `gravity-sync.conf` in the same folder.
+After you clone the base configuration, you will need to create a configuration file called `gravity-sync.conf` in the same folder as the script.
 
 ```
 vim gravity-sync.conf
@@ -48,4 +51,33 @@ Now test the script. I suggest making a subtle change to a whitelist/blacklist o
 ./gravity-sync.sh pull
 ```
 
-If you do a `git pull` while in this directory you should update to the latest copy of the script. Your changes to the .conf file, logs and backups should be uneffected by this.
+You will now have overwritten your running gravity.db on the secondary Pihole after creating a copy (gravity.db.backup) in the /etc/pihole directory. The script will also keep a copy of the last sync'd gravity.db from the master, in the gravity-sync folder (gravity.db.last) should you need it. Lastly, a file called gravity-sync.log will be created in the sync folder, with the date the script was last executed appended to the bottom.
+
+### Failover
+
+There is an option in the script to push from the secondary Pihole back to the primary. This would be useful in a situation where your primary is down for an extended period of time, and you have list changes you want to force back to the primary when it comes online.
+
+```
+./gravity-sync.sh push
+```
+
+Please note that the "push" option does not make any backups of anything. There is a warning about potental data loss before executing this function. This function purposefuly asks for user interaction to avoid being accidentally automated.
+
+### Updates
+
+If you do a `git pull` while in the `gravity-sync` directory you should be able to levegage git to update to the latest copy of the script. Your changes to the .conf file, logs and backups should be uneffected by this.
+
+### Automation
+
+I've automated by synchronization using Crontab. If you'd like to keep this a manual process then ignore this section. By default my script will run at the top and bottom of every hour (1:00 PM, 1:30 PM, 2:00 PM, etc) but you can dial this back if you feel this is too aggressive.
+
+```
+crontab -e
+*/30 * * * * sh /home/USER/gravity-sync/gravity-sync.sh pull >/dev/null 2>&1
+```
+
+Make another small adjustment to your primary settings. Now just wait until the annointed hour, and see if your changes have been synchronized. If so, profit!
+
+If not, start from the beginning.
+
+From this point forward any blocklist changes you make to the primary will reflect on the secondary within 30 minutes.