mirror of
https://github.com/vmstan/gravity-sync.git
synced 2024-08-30 18:22:11 +00:00
2.0.0
This commit is contained in:
parent
6fe6a46794
commit
583c7c8400
@ -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.
|
||||
|
||||
|
10
CHANGELOG.md
10
CHANGELOG.md
@ -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
|
||||
|
@ -27,6 +27,7 @@ REMOTE_PASS=''
|
||||
# LOG_PATH=''
|
||||
# SYNCING_LOG=''
|
||||
# CRONJOB_LOG=''
|
||||
# HISTORY_MD5=''
|
||||
|
||||
# VERIFY_PASS=''
|
||||
# SKIP_CUSTOM=''
|
||||
|
@ -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"
|
||||
|
Loading…
Reference in New Issue
Block a user