This commit is contained in:
Michael Stanclift 2020-07-07 15:37:20 -05:00
parent 6fe6a46794
commit 583c7c8400
4 changed files with 21 additions and 11 deletions

View File

@ -97,7 +97,7 @@ Gravity Sync will place logs in the same folder as the script (identified as .cr
Default setting in Gravity Sync is `$HOME/${LOCAL_FOLDR}`
#### `SYNCING_LOG=''`
Gravity Sync will write a timestamp for any completed pull, push or restore job to this file. If you want to change the name of this file, you will also need to adjust the LOG_PATH variable above, otherwise your file will be remove during an `update` operations.
Gravity Sync will write a timestamp for any completed sync, pull, push or restore job to this file. If you want to change the name of this file, you will also need to adjust the LOG_PATH variable above, otherwise your file will be remove during an `update` operations.
Default setting in Gravity Sync is `gravity-sync.log`
@ -108,6 +108,11 @@ This will have an impact to both the `./gravity-sync.sh automate` function and t
Default setting in Gravity Sync is `gravity-sync.cron`
#### `HISTORY_MD5=''`
Gravity Sync will log the file hashes of the previous `smart` task to this file. If you want to change the name of this file, you will also need to adjust the LOG_PATH variable above, otherwise your file will be removed during an `update` operations.
Default setting in Gravity Sync is `gravity-sync.md5`
#### `VERIFY_PASS=''`
Gravity Sync will prompt to verify user interactivity during push, restore, or config operations (that overwrite an existing configuration) with the intention that it prevents someone from accidentally automating in the wrong direction or overwriting data intentionally. If you'd like to automate a push function, or just don't like to be asked twice to do something distructive, then you can opt-out.

View File

@ -4,13 +4,15 @@
### The Smart Release
**Features**
For 2.0, the `push` and `pull` functions have been broken up for each component part (`gravity.db` and `custom.list`), and Gravity Sync will now detect not only if each component has changed since the last sync but also what direction they need to go.
In this release, Gravity Sync will now detect not only if each component (`gravity.db` and `custom.list`) has changed since the last sync, but also what direction they need to go. It will then initate a `push` and/or `pull` specific to each piece.
Example: If the `gravity.db` has been modified on the primary Pi-hole, but the `custom.list` file has been changed on the secondary, Gravity Sync will now do a pull and then push for each part, and then restart the correct components on each server. It will also only perform a sync of each component if there are changes within each type to replicate.
Example: If the `gravity.db` has been modified on the primary Pi-hole, but the `custom.list` file has been changed on the secondary, Gravity Sync will now do a pull of the `gravity.db` then push `custom.list` and finally restart the correct components on each server. It will also now only perform a sync of each component if there are changes within each type to replicate. So if you only make a small change to your Local DNS settings, it doesn't kickoff the larger `gravity.db` replication.
This allows you to be more flexible in where you make your configuration changes to block/allow lists and local DNS settings being made on either the primary or secondary, but it's best practice to continue making changes on the primary server where possible. In the event there are configuration changes to the same element (`custom.list` changes at both sides) then Gravity Sync will attempt to determine based on timestamps on what side the last changed happened, in which case the latest changes will be considered authoritative and overwrite the other side.
The default command for Gravity Sync is now just `./gravity-sync.sh` -- but you can also run `./gravity-sync.sh smart` if you feel like it, and it'll do the same thing.
Existing users who want to use this new method as their standard should run `./gravity-sync.sh automate` function to replace the existing automated `pull` with the new Smart Sync. You can also continue to use `pull` in your automation if you choose. New installs will use the smart Sync function by default. Running `./gravity-sync.sh` without any arguments will now run the smart Sync function.
This allows you to be more flexible in where you make your configuration changes to block/allow lists and local DNS settings being made on either the primary or secondary, but it's best practice to continue making changes on one side where possible. In the event there are configuration changes to the same element (example, `custom.list` changes at both sides) then Gravity Sync will attempt to determine based on timestamps on what side the last changed happened, in which case the latest changes will be considered authoritative and overwrite the other side. Gravity Sync does not merge the contents of the files when changes happen, it simply overwrites the entire content.
New installs will use the `smart` function by default. Existing users who want to use this new method as their standard should run `./gravity-sync.sh automate` function to replace the existing automated `pull` with the new Smart Sync. This is not required. The previous `./gravity-sync.sh pull` and `./gravity-sync.sh push` commands continue to function as they did previously, with no intention to break this functionality.
## 1.8
### The Logical Release

View File

@ -27,6 +27,7 @@ REMOTE_PASS=''
# LOG_PATH=''
# SYNCING_LOG=''
# CRONJOB_LOG=''
# HISTORY_MD5=''
# VERIFY_PASS=''
# SKIP_CUSTOM=''

View File

@ -429,7 +429,7 @@ function smart_gs {
then
if [ "${PRIDBCHANGE}" != "0" ]
then
MESSAGE="Both Sides Gravity Database Changed"
MESSAGE="Both ${GRAVITY_FI} Changed"
echo_warn
PRIDBDATE=$(${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "stat -c %Y ${PIHOLE_DIR}/${GRAVITY_FI}")
@ -437,13 +437,13 @@ function smart_gs {
if [ "${PRIDBDATE}" -gt "$SECDBDATE" ]
then
MESSAGE="Primary Gravity Database Last Changed"
MESSAGE="Primary ${GRAVITY_FI} Last Changed"
echo_info
pull_gs_grav
PULLRESTART="1"
else
MESSAGE="Secondary Gravity Database Last Changed"
MESSAGE="Secondary ${GRAVITY_FI} Last Changed"
echo_info
push_gs_grav
@ -476,7 +476,7 @@ function smart_gs {
then
if [ "${PRICLCHANGE}" != "0" ]
then
MESSAGE="Both Sides Custom DNS Changed"
MESSAGE="Both ${CUSTOM_DNS} Changed"
echo_warn
PRICLDATE=$(${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "stat -c %Y ${PIHOLE_DIR}/${CUSTOM_DNS}")
@ -484,13 +484,13 @@ function smart_gs {
if [ "${PRICLDATE}" -gt "$SECCLDATE" ]
then
MESSAGE="Primary Custom DNS Last Changed"
MESSAGE="Primary ${CUSTOM_DNS} Last Changed"
echo_info
pull_gs_cust
PULLRESTART="1"
else
MESSAGE="Secondary Custom DNS Last Changed"
MESSAGE="Secondary ${CUSTOM_DNS} Last Changed"
echo_info
push_gs_cust
@ -668,6 +668,8 @@ function logs_gs {
echo_info
echo -e "========================================================"
echo -e "Recent Complete ${YELLOW}SMART${NC} Executions"
tail -n 7 "${LOG_PATH}/${SYNCING_LOG}" | grep SMART
echo -e "Recent Complete ${YELLOW}PULL${NC} Executions"
tail -n 7 "${LOG_PATH}/${SYNCING_LOG}" | grep PULL
echo -e "Recent Complete ${YELLOW}PUSH${NC} Executions"