From c8955d0ecfd304893bb080bb59974e60fcdff509 Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Wed, 8 Jul 2020 09:48:24 -0500 Subject: [PATCH 01/15] Correct output of argument listing --- ADVANCED.md | 4 +- CHANGELOG.md | 166 ++++++++++++++++++++++++------------------------ VERSION | 2 +- gravity-sync.sh | 2 +- 4 files changed, 88 insertions(+), 86 deletions(-) diff --git a/ADVANCED.md b/ADVANCED.md index 7a52bb1..eecbb94 100644 --- a/ADVANCED.md +++ b/ADVANCED.md @@ -14,8 +14,8 @@ Download the latest release from [GitHub](https://github.com/vmstan/gravity-sync ```bash cd ~ -wget https://github.com/vmstan/gravity-sync/archive/v2.0.1.zip -unzip v2.0.1.zip -d gravity-sync +wget https://github.com/vmstan/gravity-sync/archive/v2.0.2.zip +unzip v2.0.2.zip -d gravity-sync cd gravity-sync ``` diff --git a/CHANGELOG.md b/CHANGELOG.md index 20b3c1d..bbb6aca 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -16,6 +16,9 @@ New installs will use the `smart` function by default. Existing users who want t #### 2.0.1 - Fixes bug that caused existing crontab entry not to be removed when switching from `pull` to Smart Sync. +#### 2.0.2 +- Correct output of `smart` function when script is run without proper function requested. + ## 1.8 ### The Logical Release @@ -27,18 +30,18 @@ There is nothing really sexy here, but a lot of changes under the covers to impr - Adds custom port specification to ssh-copy-id and dropbearkey commands during configuration generation. - Generally better error handling of configuration options. +#### 1.8.1 +- Detects if script is running as the root user or via `sudo ./gravity-sync.sh` and exits on error. [#34](https://github.com/vmstan/gravity-sync/issues/34) + +#### 1.8.2 +- Corrects issue where `custom.list` file would not replicate if the file didn't exist locally, and there were no other changes to replicate. [#39](https://github.com/vmstan/gravity-sync/issues/39) + #### 1.8.3 - Simplified method for input of automation frequency when running `./gravity-sync.sh automate` function. - Now removes existing automation task from crontab, if it exists, when re-running `automate` function. - Automation can be disabled by setting frequency to `0` when prompted. - Adds `dev` tag to `./gravity-sync.sh version` output for users running off the development branch. -#### 1.8.2 -- Corrects issue where `custom.list` file would not replicate if the file didn't exist locally, and there were no other changes to replicate. [#39](https://github.com/vmstan/gravity-sync/issues/39) - -#### 1.8.1 -- Detects if script is running as the root user or via `sudo ./gravity-sync.sh` and exits on error. [#34](https://github.com/vmstan/gravity-sync/issues/34) - ## 1.7 ### The Andrew Release @@ -50,35 +53,24 @@ There is nothing really sexy here, but a lot of changes under the covers to impr **Known Issues** - No new Star Trek references. -#### 1.7.7 -- `config` function will attempt to ping remote host to validate network connection, can by bypassed by adding `PING_AVOID='1'` to your `gravity-sync.conf` file. -- Changes some [INFO] messages to [WARN] where approprate. -- Adds aliases for more Gravity Sync functions. -- Shows current version on each script execution. -- Adds time output to Aborting message (exit without change.) -- Includes parsing of functions in time calculation. -- Checks for existance of Pi-hole binaries during validation. -- Less chatty about each step of configuration validation if it completes. -- Less chatty about replication validation if it's not necessary. -- Less chatty about file validation if no changes are required. -- When applying `update` in DEV mode, the Git branch used will be shown. -- Validates log export operation. +#### 1.7.1 +- There is a changelog file now. I'm mentioning it in the changelog file. So meta. +- `./gravity-sync.sh version` will check for and alert you for new versions. -#### 1.7.6 -- Detects `dbclient` install as alternative to OpenSSH Client. -- Attempts to install OpenSSH Client if not found, and Dropbear is not alternative. -- Fix bug with `dropbearkey` not finding .ssh folder. -- Numerous fixes to accomidate DietPi in general. -- Fixes issue where `compare` function would show changes where actually none existed. -- [WARN] header is now purple all the way across, consistent with [INFO] as of 1.7.4. -- Fixes issue where `custom.list` would only pull if the file already existed on the secondary Pi-hole. -- One new Star Trek reference. +#### 1.7.2 +This update changes the way that beta/development updates are applied. To continue receving the development branch, create an empty file in the `gravity-sync` folder called `dev` and afterwards the standard `./gravity-sync.sh update` function will apply the correct updates. +``` +cd gravity-sync +touch dev +./gravity-sync.sh update +``` +Delete the `dev` file and update again to revert back to the stable/master branch. -#### 1.7.5 -- No code changes! -- Primary README now only reflect "The Easy Way" to install and configure Gravity Sync -- "The Less Easy Way" are now part of [ADVANCED.md](https://github.com/vmstan/gravity-sync/blob/master/ADVANCED.md) -- All advanced configuration options are outlined in [ADVANCED.md](https://github.com/vmstan/gravity-sync/blob/master/ADVANCED.md) +#### 1.7.3 +- Cleaning up output of argument listing + +**Deprecation** +- Removes `beta` function for applying development branch updates. #### 1.7.4 - `./gravity-sync.sh dev` will now toggle dev flag on/off. No `touch` required, although it still works that way under the covers. Improvement of methods added in 1.7.2. @@ -93,24 +85,35 @@ There is nothing really sexy here, but a lot of changes under the covers to impr - Detects absence of `ssh-keygen` utility on host OS and will use `dropbearkey` as an alternative (DietPi) - Changelog polarity reversed after heated discussions with marketing team. -#### 1.7.3 -- Cleaning up output of argument listing +#### 1.7.5 +- No code changes! +- Primary README now only reflect "The Easy Way" to install and configure Gravity Sync +- "The Less Easy Way" are now part of [ADVANCED.md](https://github.com/vmstan/gravity-sync/blob/master/ADVANCED.md) +- All advanced configuration options are outlined in [ADVANCED.md](https://github.com/vmstan/gravity-sync/blob/master/ADVANCED.md) -#### 1.7.2 -This update changes the way that beta/development updates are applied. To continue receving the development branch, create an empty file in the `gravity-sync` folder called `dev` and afterwards the standard `./gravity-sync.sh update` function will apply the correct updates. -``` -cd gravity-sync -touch dev -./gravity-sync.sh update -``` -Delete the `dev` file and update again to revert back to the stable/master branch. +#### 1.7.6 +- Detects `dbclient` install as alternative to OpenSSH Client. +- Attempts to install OpenSSH Client if not found, and Dropbear is not alternative. +- Fix bug with `dropbearkey` not finding .ssh folder. +- Numerous fixes to accomidate DietPi in general. +- Fixes issue where `compare` function would show changes where actually none existed. +- [WARN] header is now purple all the way across, consistent with [INFO] as of 1.7.4. +- Fixes issue where `custom.list` would only pull if the file already existed on the secondary Pi-hole. +- One new Star Trek reference. -**Deprecation** -- Removes `beta` function for applying development branch updates. - -#### 1.7.1 -- There is a changelog file now. I'm mentioning it in the changelog file. So meta. -- `./gravity-sync.sh version` will check for and alert you for new versions. +#### 1.7.7 +- `config` function will attempt to ping remote host to validate network connection, can by bypassed by adding `PING_AVOID='1'` to your `gravity-sync.conf` file. +- Changes some [INFO] messages to [WARN] where approprate. +- Adds aliases for more Gravity Sync functions. +- Shows current version on each script execution. +- Adds time output to Aborting message (exit without change.) +- Includes parsing of functions in time calculation. +- Checks for existance of Pi-hole binaries during validation. +- Less chatty about each step of configuration validation if it completes. +- Less chatty about replication validation if it's not necessary. +- Less chatty about file validation if no changes are required. +- When applying `update` in DEV mode, the Git branch used will be shown. +- Validates log export operation. ## 1.6 ### The Restorative Release @@ -146,14 +149,14 @@ Delete the `dev` file and update again to revert back to the stable/master branc - All new and exciting code comments. - No new Star Trek references. -#### 1.4.3 -- Bug fixes around not properly utilizing custom SSH keyfile. +#### 1.4.1 +- Adds variables for custom log locations to `gravity-sync.conf`, see `.example` file for listing. #### 1.4.2 - Will prompt to create new `gravity-sync.conf` file when run without an existing configuration. -#### 1.4.1 -- Adds variables for custom log locations to `gravity-sync.conf`, see `.example` file for listing. +#### 1.4.3 +- Bug fixes around not properly utilizing custom SSH keyfile. ## 1.3 ### The Comparison Release @@ -165,22 +168,21 @@ Delete the `dev` file and update again to revert back to the stable/master branc - Additional debugging options such as checking last cronjob output via `./gravity-sync.sh cron` if configured. - Much more consistency in how running commands are processed in interactive mode. -#### 1.3.4 -- Moves backup of local database before initiating remote pull. -- Validates file ownership and permissions before attempting to rewrite. -- Added two Star Trek references. - -#### 1.3.3 -- Corrected Pihole bin path issue that cause automated sync not to reload services. - -#### 1.3.2 -- MUCH cleaner output, same great features. - #### 1.3.1 - Changes [GOOD] to [DONE] in execution output. - Better validation of initial SSH connection. - Support for password based authentication using SSHPASS. +#### 1.3.2 +- MUCH cleaner output, same great features. + +#### 1.3.3 +- Corrected Pihole bin path issue that cause automated sync not to reload services. + +#### 1.3.4 +- Moves backup of local database before initiating remote pull. +- Validates file ownership and permissions before attempting to rewrite. +- Added two Star Trek references. ## 1.2 ### The Functional Release @@ -188,23 +190,23 @@ Delete the `dev` file and update again to revert back to the stable/master branc - Does not look for permission to update when run. - Cleanup and expand comments. -#### 1.2.5 -- Push function now does a backup, on the secondary PH, of the primary database, before pushing. +#### 1.2.1 +- Improved logging functions. -#### 1.2.4 -- Changes `~` to `$HOME`. -- Fixes bug that prevented sync from working when run via crontab. +#### 1.2.2 +- Different style for status updates. #### 1.2.3 - Uses a dedicated backup folder for `.backup` and `.last` files. - Copies db instead of moving to rename and then replacing to be more reliable. - Even cleaner label status. -#### 1.2.2 -- Different style for status updates. +#### 1.2.4 +- Changes `~` to `$HOME`. +- Fixes bug that prevented sync from working when run via crontab. -#### 1.2.1 -- Improved logging functions. +#### 1.2.5 +- Push function now does a backup, on the secondary PH, of the primary database, before pushing. ## 1.1 ### The Pushy Release @@ -212,22 +214,22 @@ Delete the `dev` file and update again to revert back to the stable/master branc - Seperated main purpose of script into `pull` argument. - Allow process to reverse back using `push` argument. -#### 1.1.6 -- Code easier to read with proper tabs. +#### 1.1.2 +- First release since move from being just a Gist. +- Just relearning how to use GitHub, minor bug fixes. -#### 1.1.5 -- Added ability to view logs with `./gravity-sync.sh logs`. +#### 1.1.3 +- Now includes example an configuration file. #### 1.1.4 - Added update script. - Added version check. -#### 1.1.3 -- Now includes example an configuration file. +#### 1.1.5 +- Added ability to view logs with `./gravity-sync.sh logs`. -#### 1.1.2 -- First release since move from being just a Gist. -- Just relearning how to use GitHub, minor bug fixes. +#### 1.1.6 +- Code easier to read with proper tabs. ## 1.0 ### The Initial Release diff --git a/VERSION b/VERSION index 10bf840..f93ea0c 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -2.0.1 \ No newline at end of file +2.0.2 \ No newline at end of file diff --git a/gravity-sync.sh b/gravity-sync.sh index 44f72aa..59e456b 100755 --- a/gravity-sync.sh +++ b/gravity-sync.sh @@ -1360,7 +1360,7 @@ function list_gs_arguments { echo -e " ${YELLOW}version${NC} Display installed version of ${PROGRAM}" echo -e "" echo -e "Replication Options:" - echo -e " ${YELLOW}sync${NC} Detect changes on each side and bring them together" + echo -e " ${YELLOW}smart${NC} Detect changes on each side and bring them together" echo -e " ${YELLOW}pull${NC} Force remote configuration changes to this server" echo -e " ${YELLOW}push${NC} Force local configuration made on this server back" echo -e " ${YELLOW}restore${NC} Restore the ${GRAVITY_FI} on this server" From c4704a2d459312f58f88d989995bf59269f165e9 Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Wed, 8 Jul 2020 11:23:02 -0500 Subject: [PATCH 02/15] Chris was right --- CHANGELOG.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index bbb6aca..feb295b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -18,6 +18,7 @@ New installs will use the `smart` function by default. Existing users who want t #### 2.0.2 - Correct output of `smart` function when script is run without proper function requested. +- Decided marketing team was correct about display of versions in `CHANGELOG.md` -- sorry Chris. ## 1.8 ### The Logical Release From 0536e36eef93e1581c7431025e4bc9f4374ae5c6 Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Wed, 8 Jul 2020 16:10:00 -0500 Subject: [PATCH 03/15] Reference arch --- ADVANCED.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/ADVANCED.md b/ADVANCED.md index eecbb94..1d6a44f 100644 --- a/ADVANCED.md +++ b/ADVANCED.md @@ -180,3 +180,39 @@ If you prefer to still use cron but modify your settings by hand, using the entr crontab -e */30 * * * * /bin/bash /home/USER/gravity-sync/gravity-sync.sh > /home/USER/gravity-sync/gravity-sync.cron ``` + +## Reference Architectures + +There are three reference architectures that I'll outline. All of them require an external DHCP server (such as a router, or dedicated DHCP server) handing out the DNS address(es) for your Pi-holes. Use of the integrated DHCP function in Pi-hole when using Gravity Sync is discouraged, although I'm sure there are ways to make it work. **Gravity Sync does not manage any DHCP settings.** + +### Easy Peasy +![Easy Peasy](https://user-images.githubusercontent.com/3002053/86969050-c1131400-c132-11ea-9328-dfda772dc280.png) + +This design requires the least amount of overhead, or additional software/network configuration beyond Pi-hole and Gravity Sync. + +1. Client requests an IP address from a DHCP server on the network and receives it along with DNS and gateway information back. Two DNS servers (Pi-hole) are returned to the client. +2. Client queries one of the two DNS servers, and Pi-hole does it's thing. + +You can make changes to your blocklist, exceptions, etc, on either Pi-hole and they will be sync'd to the other within the timeframe you establish (here, 15 minutes.) + +### Stay Alive +![Stay Alive](https://user-images.githubusercontent.com/3002053/86969056-c40e0480-c132-11ea-8db4-15c26ab8999d.png) + +The downside in the above design is you have two places where your clients are logging lookup requests to. Gravity Sync will let you change filter settings in either location, but if you're doing it often things may get overwritten. One way to get around this is by using keepalived and present a single virtual IP address of the two Pi-hole, to clients in an active/passive mode. The two nodes will check their own status, and each other, and hand the VIP around if there are issues. + +1. Client requests an IP address from a DHCP server on the network and receives it along with DNS and gateway information back. One DNS server (VIP) is returned to the client. +2. The VIP managed by the keepalived service will determine which Pi-hole responds. You make your configuration changes to the active VIP address. +3. Client queries the single DNS servers, and Pi-hole does it's thing. + +You make your configuration changes to the active VIP address and they will be sync'd to the other within the timeframe you establish (here, 15 minutes.) + +### Crazy Town +![Crazy Town](https://user-images.githubusercontent.com/3002053/86969028-b8bad900-c132-11ea-83f1-88b4888af32c.png) + +For those who really love Pi-hole and Gravity Sync. Combining the best of both worlds. + +1. Client requests an IP address from a DHCP server on the network and receives it along with DNS and gateway information back. Two DNS servers (VIPs) are returned to the client. +2. The VIPs are managed by the keepalived service on each side and will determine which of two Pi-hole responds. You can make your configuration changes to the active VIP address on either side. +3. Client queries one of the two VIP servers, and the responding Pi-hole does it's thing. + +Here we use `./gravity-sync pull` on the secondary Pi-hole at each side, and ofset the update intervals from the main sync. \ No newline at end of file From ab6a90d118688377770ad7514be719a32c3981f2 Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Wed, 8 Jul 2020 16:10:32 -0500 Subject: [PATCH 04/15] More references --- CHANGELOG.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index feb295b..b5df980 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -19,6 +19,7 @@ New installs will use the `smart` function by default. Existing users who want t #### 2.0.2 - Correct output of `smart` function when script is run without proper function requested. - Decided marketing team was correct about display of versions in `CHANGELOG.md` -- sorry Chris. +- Adds reference architectures to the `ADVANCED.md` file. ## 1.8 ### The Logical Release From 393924a836d159391c15ca4a81966cd6b434509f Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Wed, 8 Jul 2020 16:12:31 -0500 Subject: [PATCH 05/15] easy --- ADVANCED.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ADVANCED.md b/ADVANCED.md index 1d6a44f..f7bb9d7 100644 --- a/ADVANCED.md +++ b/ADVANCED.md @@ -193,12 +193,12 @@ This design requires the least amount of overhead, or additional software/networ 1. Client requests an IP address from a DHCP server on the network and receives it along with DNS and gateway information back. Two DNS servers (Pi-hole) are returned to the client. 2. Client queries one of the two DNS servers, and Pi-hole does it's thing. -You can make changes to your blocklist, exceptions, etc, on either Pi-hole and they will be sync'd to the other within the timeframe you establish (here, 15 minutes.) +You can make changes to your blocklist, exceptions, etc, on either Pi-hole and they will be sync'd to the other within the timeframe you establish (here, 15 minutes.) The downside in the above design is you have two places where your clients are logging lookup requests to. Gravity Sync will let you change filter settings in either location, but if you're doing it often things may get overwritten. ### Stay Alive ![Stay Alive](https://user-images.githubusercontent.com/3002053/86969056-c40e0480-c132-11ea-8db4-15c26ab8999d.png) -The downside in the above design is you have two places where your clients are logging lookup requests to. Gravity Sync will let you change filter settings in either location, but if you're doing it often things may get overwritten. One way to get around this is by using keepalived and present a single virtual IP address of the two Pi-hole, to clients in an active/passive mode. The two nodes will check their own status, and each other, and hand the VIP around if there are issues. +One way to get around having logging in two places is by using keepalived and present a single virtual IP address of the two Pi-hole, to clients in an active/passive mode. The two nodes will check their own status, and each other, and hand the VIP around if there are issues. 1. Client requests an IP address from a DHCP server on the network and receives it along with DNS and gateway information back. One DNS server (VIP) is returned to the client. 2. The VIP managed by the keepalived service will determine which Pi-hole responds. You make your configuration changes to the active VIP address. From 4d824c54ebf1588e7e6981700d6f774967259c7f Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Wed, 8 Jul 2020 20:48:53 -0500 Subject: [PATCH 06/15] Check for rsync on remote host --- ADVANCED.md | 2 +- gravity-sync.sh | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/ADVANCED.md b/ADVANCED.md index f7bb9d7..6f117b2 100644 --- a/ADVANCED.md +++ b/ADVANCED.md @@ -215,4 +215,4 @@ For those who really love Pi-hole and Gravity Sync. Combining the best of both w 2. The VIPs are managed by the keepalived service on each side and will determine which of two Pi-hole responds. You can make your configuration changes to the active VIP address on either side. 3. Client queries one of the two VIP servers, and the responding Pi-hole does it's thing. -Here we use `./gravity-sync pull` on the secondary Pi-hole at each side, and ofset the update intervals from the main sync. \ No newline at end of file +Here we use `./gravity-sync pull` on the secondary Pi-hole at each side, and off-set the update intervals from the main sync. \ No newline at end of file diff --git a/gravity-sync.sh b/gravity-sync.sh index 59e456b..a50da97 100755 --- a/gravity-sync.sh +++ b/gravity-sync.sh @@ -1013,6 +1013,23 @@ function detect_ssh { fi } +function detect_remotersync { + MESSAGE="Validating RSYNC Installed on ${REMOTE_HOST}" + echo_stat + + REMOTERSYNC=$(${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "hash rsync") + + if [ "${REMOTERSYNC}" == "-bash: hash: rsync: not found" + then + echo_fail + MESSAGE="Please install RSYNC on ${REMOTE_HOST}" + echo_info + exit_nochange + else + echo_good + fi +} + ## Error Validation function error_validate { if [ "$?" != "0" ] @@ -1304,6 +1321,8 @@ function config_generate { echo_info validate_os_sshpass + + detect_remotersync exit_withchange } From dc75b2b7ae14bf252c3af6a3e32be173f98a1c99 Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Wed, 8 Jul 2020 20:53:20 -0500 Subject: [PATCH 07/15] bracket --- gravity-sync.sh | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/gravity-sync.sh b/gravity-sync.sh index a50da97..fa41d40 100755 --- a/gravity-sync.sh +++ b/gravity-sync.sh @@ -1019,12 +1019,11 @@ function detect_remotersync { REMOTERSYNC=$(${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "hash rsync") - if [ "${REMOTERSYNC}" == "-bash: hash: rsync: not found" + if [ "${REMOTERSYNC}" == "-bash: hash: rsync: not found" ] then echo_fail MESSAGE="Please install RSYNC on ${REMOTE_HOST}" - echo_info - exit_nochange + echo_warn else echo_good fi From e10c202601d0d3a7c92701513874a87ed7eefd90 Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Wed, 8 Jul 2020 20:55:59 -0500 Subject: [PATCH 08/15] Thing down flip it and reverse it --- gravity-sync.sh | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gravity-sync.sh b/gravity-sync.sh index fa41d40..a274475 100755 --- a/gravity-sync.sh +++ b/gravity-sync.sh @@ -1017,15 +1017,15 @@ function detect_remotersync { MESSAGE="Validating RSYNC Installed on ${REMOTE_HOST}" echo_stat - REMOTERSYNC=$(${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "hash rsync") + REMOTERSYNC=$(${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "hash rsync") >/dev/null 2>&1 - if [ "${REMOTERSYNC}" == "-bash: hash: rsync: not found" ] + if [ "${REMOTERSYNC}" == "" ] then + echo_good + else echo_fail MESSAGE="Please install RSYNC on ${REMOTE_HOST}" echo_warn - else - echo_good fi } From 49a9198a51c243bedd8c4e22536bed15d560e015 Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Wed, 8 Jul 2020 21:00:03 -0500 Subject: [PATCH 09/15] Sed --- gravity-sync.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gravity-sync.sh b/gravity-sync.sh index a274475..7799201 100755 --- a/gravity-sync.sh +++ b/gravity-sync.sh @@ -1017,7 +1017,7 @@ function detect_remotersync { MESSAGE="Validating RSYNC Installed on ${REMOTE_HOST}" echo_stat - REMOTERSYNC=$(${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "hash rsync") >/dev/null 2>&1 + REMOTERSYNC=$(${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "hash rsync" | sed 's/\s.*$//') if [ "${REMOTERSYNC}" == "" ] then From 34f47c1267acb73b747ca0de493d3a3b2f3c9c7d Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Wed, 8 Jul 2020 21:18:13 -0500 Subject: [PATCH 10/15] rewrite check --- gravity-sync.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gravity-sync.sh b/gravity-sync.sh index 7799201..596c8cb 100755 --- a/gravity-sync.sh +++ b/gravity-sync.sh @@ -1017,9 +1017,9 @@ function detect_remotersync { MESSAGE="Validating RSYNC Installed on ${REMOTE_HOST}" echo_stat - REMOTERSYNC=$(${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "hash rsync" | sed 's/\s.*$//') + ${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "hash rsync" 2>/dev/null - if [ "${REMOTERSYNC}" == "" ] + if [ "$?" == "-bash: 0: command not found" ] then echo_good else From c13ca47f0657cbeb603f1869ea5699b9bbc22235 Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Wed, 8 Jul 2020 21:23:15 -0500 Subject: [PATCH 11/15] 0 --- gravity-sync.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gravity-sync.sh b/gravity-sync.sh index 596c8cb..23a2c38 100755 --- a/gravity-sync.sh +++ b/gravity-sync.sh @@ -1019,7 +1019,7 @@ function detect_remotersync { ${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "hash rsync" 2>/dev/null - if [ "$?" == "-bash: 0: command not found" ] + if [ "$?" == "0" ] then echo_good else From e725ab7f5d86e38e9755768c994d4ff316d4b35e Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Thu, 9 Jul 2020 10:02:51 -0500 Subject: [PATCH 12/15] New rsync validation method --- gravity-sync.sh | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/gravity-sync.sh b/gravity-sync.sh index 23a2c38..715d732 100755 --- a/gravity-sync.sh +++ b/gravity-sync.sh @@ -1017,16 +1017,22 @@ function detect_remotersync { MESSAGE="Validating RSYNC Installed on ${REMOTE_HOST}" echo_stat - ${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "hash rsync" 2>/dev/null + CMD_TIMEOUT='15' + CMD_REQUESTED="touch ~/gs.test" + create_sshcmd - if [ "$?" == "0" ] - then - echo_good - else - echo_fail - MESSAGE="Please install RSYNC on ${REMOTE_HOST}" - echo_warn - fi + RSYNC_REPATH="rsync" + RSYNC_SOURCE="${REMOTE_USER}@${REMOTE_HOST}:~/gs.test" + RSYNC_TARGET="$HOME/${LOCAL_FOLDR}/gs.test" + create_rsynccmd + + rm $HOME/${LOCAL_FOLDR}/gs.test + + CMD_TIMEOUT='15' + CMD_REQUESTED="rm ~/gs.test" + create_sshcmd + + error_validate } ## Error Validation From 270b354e80c57f9ab3b03926adbc1e8df8f6afa7 Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Thu, 9 Jul 2020 10:06:55 -0500 Subject: [PATCH 13/15] Messages --- gravity-sync.sh | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/gravity-sync.sh b/gravity-sync.sh index 715d732..1098ebb 100755 --- a/gravity-sync.sh +++ b/gravity-sync.sh @@ -1014,25 +1014,32 @@ function detect_ssh { } function detect_remotersync { - MESSAGE="Validating RSYNC Installed on ${REMOTE_HOST}" + MESSAGE="Validating RSYNC Ability to ${REMOTE_HOST}" + echo_info + + MESSAGE="Creating Test File on ${REMOTE_HOST}" echo_stat CMD_TIMEOUT='15' CMD_REQUESTED="touch ~/gs.test" create_sshcmd + MESSAGE="Pulling Test File to $HOSTNAME" + echo_stat + RSYNC_REPATH="rsync" RSYNC_SOURCE="${REMOTE_USER}@${REMOTE_HOST}:~/gs.test" RSYNC_TARGET="$HOME/${LOCAL_FOLDR}/gs.test" create_rsynccmd + MESSAGE="Cleaning Up Test Files" + echo_stat + rm $HOME/${LOCAL_FOLDR}/gs.test CMD_TIMEOUT='15' CMD_REQUESTED="rm ~/gs.test" create_sshcmd - - error_validate } ## Error Validation From 201807bc4d6f6465d8461c94ef47cd15b5b6050c Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Thu, 9 Jul 2020 10:10:25 -0500 Subject: [PATCH 14/15] Warn instead of info --- gravity-sync.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gravity-sync.sh b/gravity-sync.sh index 1098ebb..708d546 100755 --- a/gravity-sync.sh +++ b/gravity-sync.sh @@ -1014,9 +1014,6 @@ function detect_ssh { } function detect_remotersync { - MESSAGE="Validating RSYNC Ability to ${REMOTE_HOST}" - echo_info - MESSAGE="Creating Test File on ${REMOTE_HOST}" echo_stat @@ -1024,6 +1021,9 @@ function detect_remotersync { CMD_REQUESTED="touch ~/gs.test" create_sshcmd + MESSAGE="If this fails make sure RSYNC is installed on ${REMOTE_HOST}" + echo_warn + MESSAGE="Pulling Test File to $HOSTNAME" echo_stat From 23a6ceed3a9780bc6a9705885ce067da0a152797 Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Thu, 9 Jul 2020 10:42:09 -0500 Subject: [PATCH 15/15] 2.0.2 --- ADVANCED.md | 44 +++++++++++++++++++++++--- CHANGELOG.md | 4 ++- README.md | 82 ++++++++++++++++--------------------------------- gravity-sync.sh | 4 +-- 4 files changed, 72 insertions(+), 62 deletions(-) diff --git a/ADVANCED.md b/ADVANCED.md index 6f117b2..2b019e4 100644 --- a/ADVANCED.md +++ b/ADVANCED.md @@ -76,6 +76,39 @@ Gravity Sync will validate that the `sshpass` utility is installed on your syste Save. Keep calm, carry on. +### The Pull Function +The Gravity Sync Pull, prior to version 2.0, was the standard method of sync operation, and will not prompt for user input after execution. + +```bash +./gravity-sync.sh pull +``` + +If the execution completes, you will now have overwritten your running `gravity.db` and `custom.list` on the secondary Pi-hole after creating a copy of the running files (with `.backup` appended) in the `backup` subfolder located with your script. Gravity Sync will also keep a copy of the last sync'd files from the primary (in the `backup` folder appended with `.pull`) for future use. + +### The Push Function +Gravity Sync includes the ability to `push` from the secondary Pi-hole back to the primary. This would be useful in a situation where your primary Pi-hole is down for an extended period of time, and you have made list changes on the secondary Pi-hole that you want to force back to the primary, when it comes online. + +```bash +./gravity-sync.sh push +``` + +Before executing, this will make a copy of the remote database under `backup/gravity.db.push` and `backup/custom.list.push` then sync the local configuration to the primary Pi-hole. + +This function purposefuly asks for user interaction to avoid being accidentally automated. + +- If your script prompts for a password on the remote system, make sure that your remote user account is setup not to require passwords in the sudoers file. + +### The Restore Function +Gravity Sync can also `restore` the database on the secondary Pi-hole in the event you've overwritten it accidentally. This might happen in the above scenario where you've had your primary Pi-hole down for an extended period, made changes to the secondary, but perhaps didn't get a chance to perform a `push` of the changes back to the primary, before your automated sync ran. + +```bash +./gravity-sync.sh restore +``` + +This will copy your last `gravity.db.backup` and `custom.list.backup` to the running copy on the secondary Pi-hole. + +This function purposefuly asks for user interaction to avoid being accidentally automated. + ### Hidden Figures There are a series of advanced configuration options that you may need to change to better adapt Gravity Sync to your environment. They are referenced at the end of the `gravity-sync.conf` file. It is suggested that you make any necessary variable changes to this file, as they will superceed the ones located in the core script. If you want to revert back to the Gravity Sync default for any of these settings, just apply a `#` to the beginning of the line to comment it out. @@ -182,11 +215,12 @@ crontab -e ``` ## Reference Architectures +The designation of primary and secondary is purely at your discretion. The doesn't matter if you're using an HA process like keepalived to present a single DNS IP address to clients, or handing out two DNS resolvers via DHCP. Generally it is expected that the two (or more) Pi-hole(s) will be at the same phyiscal location, or at least on the same internal networks. It should also be possible to to replicate to a secondary Pi-hole across networks, either over a VPN or open-Internet, with the approprate firewall/NAT configuration. There are three reference architectures that I'll outline. All of them require an external DHCP server (such as a router, or dedicated DHCP server) handing out the DNS address(es) for your Pi-holes. Use of the integrated DHCP function in Pi-hole when using Gravity Sync is discouraged, although I'm sure there are ways to make it work. **Gravity Sync does not manage any DHCP settings.** ### Easy Peasy -![Easy Peasy](https://user-images.githubusercontent.com/3002053/86969050-c1131400-c132-11ea-9328-dfda772dc280.png) +![Easy Peasy](https://user-images.githubusercontent.com/3002053/87058413-ac378e80-c1cd-11ea-9f21-376170e69ff3.png) This design requires the least amount of overhead, or additional software/network configuration beyond Pi-hole and Gravity Sync. @@ -196,7 +230,7 @@ This design requires the least amount of overhead, or additional software/networ You can make changes to your blocklist, exceptions, etc, on either Pi-hole and they will be sync'd to the other within the timeframe you establish (here, 15 minutes.) The downside in the above design is you have two places where your clients are logging lookup requests to. Gravity Sync will let you change filter settings in either location, but if you're doing it often things may get overwritten. ### Stay Alive -![Stay Alive](https://user-images.githubusercontent.com/3002053/86969056-c40e0480-c132-11ea-8db4-15c26ab8999d.png) +![Stay Alive](https://user-images.githubusercontent.com/3002053/87058415-acd02500-c1cd-11ea-8884-6579a2d5eedc.png) One way to get around having logging in two places is by using keepalived and present a single virtual IP address of the two Pi-hole, to clients in an active/passive mode. The two nodes will check their own status, and each other, and hand the VIP around if there are issues. @@ -207,7 +241,7 @@ One way to get around having logging in two places is by using keepalived and pr You make your configuration changes to the active VIP address and they will be sync'd to the other within the timeframe you establish (here, 15 minutes.) ### Crazy Town -![Crazy Town](https://user-images.githubusercontent.com/3002053/86969028-b8bad900-c132-11ea-83f1-88b4888af32c.png) +![Crazy Town](https://user-images.githubusercontent.com/3002053/87058406-aa6dcb00-c1cd-11ea-8f64-59c529b00166.png) For those who really love Pi-hole and Gravity Sync. Combining the best of both worlds. @@ -215,4 +249,6 @@ For those who really love Pi-hole and Gravity Sync. Combining the best of both w 2. The VIPs are managed by the keepalived service on each side and will determine which of two Pi-hole responds. You can make your configuration changes to the active VIP address on either side. 3. Client queries one of the two VIP servers, and the responding Pi-hole does it's thing. -Here we use `./gravity-sync pull` on the secondary Pi-hole at each side, and off-set the update intervals from the main sync. \ No newline at end of file +Here we use `./gravity-sync pull` on the secondary Pi-hole at each side, and off-set the update intervals from the main sync. + +(I call this crazy, but this is what I use at home.) \ No newline at end of file diff --git a/CHANGELOG.md b/CHANGELOG.md index b5df980..400d621 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -14,12 +14,14 @@ This allows you to be more flexible in where you make your configuration changes 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. #### 2.0.1 -- Fixes bug that caused existing crontab entry not to be removed when switching from `pull` to Smart Sync. +- Fixes bug that caused existing crontab entry not to be removed when switching from `pull` to Smart Sync. [#50](https://github.com/vmstan/gravity-sync/issues/50) #### 2.0.2 - Correct output of `smart` function when script is run without proper function requested. - Decided marketing team was correct about display of versions in `CHANGELOG.md` -- sorry Chris. - Adds reference architectures to the `ADVANCED.md` file. +- Checks for RSYNC functionality to remote host during `./gravity-sync.sh configure` and prompts to install. [#53](https://github.com/vmstan/gravity-sync/issues/53) +- Move much of the previous `README.md` to `ADVANCED.md` file. ## 1.8 ### The Logical Release diff --git a/README.md b/README.md index 29ab571..3105c58 100644 --- a/README.md +++ b/README.md @@ -1,25 +1,30 @@ # Gravity Sync -## Background -What is better than a [Pi-hole](https://github.com/pi-hole/pi-hole) blocking ads via DNS on your network? That's right, Two Pi-hole! But if you have more than one Pi-hole in your network you'll want a simple way to keep the list configurations identical between the two. +## Features +What is better than a [Pi-hole](https://github.com/pi-hole/pi-hole) blocking ads via DNS on your network? That's right, Two Pi-hole! (Redundency is key in any network infrastucture.) But if you have more than one Pi-hole in your network you'll want a simple way to keep the list configurations and local DNS settings identical between the two. That's where Gravity Sync comes in. -That's Gravity Sync. +Gravity Sync will: +- Sync that the allow/blocklist configurations stored in `gravity.db` between two Pi-hole +- Sync the local DNS settings stored in `custom.list` between two Pi-hole. +- Provide an easy way to keep this happening in the background. -At it's core, Gravity Sync is maybe a handful of core bash commands, that uses rsync to reach out to a remote host, copy the running `gravity.db` file that contains the Pi-hole blocklist, as well as the `custom.list` file that contains local DNS enteries, and then replaces the copy on the local system. What Gravity Sync provides is an easy way to keep this happening in the background. Ideally you set it and forget it and in the long term, it would be awesome if the Pi-hole team made this entire script unncessary. +Ideally you set up Gravity Sync and forget about it -- and in the long term, it would be awesome if the Pi-hole team made this entire script unncessary. -Gravity Sync will **not** overwrite device specific settings such as device network configuration, admin/API passwords/keys, upstream DNS resolvers, etc. It will also **not** keep DHCP settings or device leases synchronized. +### Limitations +Gravity Sync will **not**: +- Overwrite individual Pi-hole specific settings such as the device's network configuration, admin/API passwords/keys, upstream DNS resolvers, etc. +- Keep DHCP settings or device leases synchronized. -## Prerequisites -### System Requirements -Gravity Sync **requires** Pi-hole 5.0 or higher be already installed on your server. -- Gravity Sync is regularly tested during development with on any of the Linux distrobutions that Pi-hole is [certified to run on](https://docs.pi-hole.net/main/prerequesites/#supported-operating-systems). As Gravity Sync is just an (admittedly) long bash script, it will likely work on other Linux distributions that have the the necessary components. -- Gravity Sync uses the `SUDO` command to elevate permissions for itself, on both Pi-hole systems, during execution. You will need to make sure that you have passwordless SUDO enabled for the accounts on both the primary and secondary Pi-hole that will be performing the work. Most of the pre-built images available for the Raspberry Pi already have this configured, but if you have your Pi-hole running in a virtual machine built from a generic ISO, you may need to [adjust this manually](https://linuxize.com/post/how-to-run-sudo-command-without-password/). -- Gravity Sync has not been tested with Docker deployments of Pi-hole, and is not expected to work there without major modifications. You will need Pi-hole setup with a "traditional" install directly in the base operating system. There are likely other methods of sharing the `gravity.db` file between multiple Docker instances that are better suited to a container environment. -- Gravity Sync leverages SSH and RSYNC to do the leavy lifting between your Pi-hole nodes. OpenSSH is reccomended but if you're using a ultra-lightweight Pi distrbution (such as DietPi) that uses Dropbear by default, it should work as well. Other SSH client/server combonations are not supported at this time. +It is suggested that you use an external DHCP server on your network (such as your router) when using multiple Pi-hole. + +### Requirements +- Pi-hole 5.0 (or higher) be installed on at least two systems, using any of the Linux distros that Pi-hole is [certified to run on](https://docs.pi-hole.net/main/prerequesites/#supported-operating-systems). Docker deployments of Pi-hole are not supported. +- You will need to make sure that you have passwordless `SUDO` enabled for the accounts on both the primary and secondary Pi-hole that will be performing the work. Most of the pre-built images available for the Raspberry Pi already have this configured, but if you have your Pi-hole running in a virtual machine built from a generic ISO, you may need to [adjust this manually](https://linuxize.com/post/how-to-run-sudo-command-without-password/). +- Make sure `SSH` and `RSYNC` are installed on both the primary and secondary Pi-hole prior to installation. This is what does the leavy lifting between your Pi-hole nodes. OpenSSH is reccomended but if you're using a ultra-lightweight Pi distrbution (such as DietPi) that uses Dropbear by default, it should work as well. Other SSH client/server combonations are not supported at this time. ### Pi-hole Architecture You will want 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 blocklists, device/group management, configuring custom/local network DNS, and other changing other list settings. The secondary Pi-hole(s) are where you will install and configure Gravity Sync. -The designation of primary and secondary is purely at your discretion. The doesn't matter if you're using an HA process like keepalived to present a single DNS IP address to clients, or handing out two DNS resolvers via DHCP. Generally it is expected that the two (or more) Pi-hole(s) will be at the same phyiscal location, or at least on the same internal networks. It should also be possible to to replicate to a secondary Pi-hole across networks, either over a VPN or open-Internet, with the approprate firewall/NAT configuration. +For more information and for reference architectures, please [refer to this document](https://github.com/vmstan/gravity-sync/blob/master/ADVANCED.md#reference-architectures) Starting with version 2.0, Gravity Sync will sync the `gravity.db` and `custom.list` files on each Pi-hole with each other. (Previous versions only pulled data one way.) @@ -42,11 +47,11 @@ After you install Gravity Sync to your server you will need to create a configur ``` This will guide you through the process of: -- Specifying the IP or DNS name of your primary Pi-hole -- Specifying the SSH username to connect to your primary Pi-hole -- Selecting the SSH authentication mechanism (key-pair or password) -- Configuring your key-pair and applying it to your primary Pi-hole -- Testing your authentication method +- Specifying the IP or DNS name of your primary Pi-hole. +- Specifying the SSH username to connect to your primary Pi-hole. +- Selecting the SSH authentication mechanism (key-pair or password.) +- Configuring your key-pair and applying it to your primary Pi-hole. +- Testing your authentication method, and testing RSYNC to the primary. After you've completed your configuration, proceed to the Execution phase. @@ -57,9 +62,9 @@ Now, test Gravity Sync. You can run a comparison between primary and secondary d ./gravity-sync.sh compare ``` -Assuming Gravity Sync runs successfully, it will indicate if there are changes pending between the two databases. If not, make a subtle change to a whitelist/blacklist on your primary Pi-hole, such as changing a description field or disabling a whitelist item, and then running `./gravity-sync.sh compare` again to validate your installation is working correctly. +Assuming Gravity Sync runs successfully, it will indicate if there are changes pending between the two databases. If not, make a subtle change to a allowlist/blocklist on your primary Pi-hole, such as changing a description field or disabling a allowlist item, and then running `./gravity-sync.sh compare` again to validate your installation is working correctly. -### The Smart Sync +### The Sync The default command for Gravity Sync is simple. @@ -69,7 +74,7 @@ The default command for Gravity Sync is simple. But you can also run `./gravity-sync.sh smart` if you feel like it, and it'll do the same thing. -It will perform some checks to help insure success and then stop before making changes if it detects an issue. It will also perform the same `compare` function outlined above, and if there are no changes pending, it will exit without making an attempt to copy data. +Gravity Sync will perform some checks to help insure success and then stop before making changes if it detects an issue. It will also perform the same `compare` function outlined above, and if there are no changes pending, it will exit without making an attempt to copy data. **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. @@ -81,39 +86,6 @@ Finally, a file called `gravity-sync.log` will be created in the `gravity-sync` You can check for successful pull attempts by running: `./gravity-sync.sh logs` -### The Pull Function -The Gravity Sync Pull, prior to version 2.0, was the standard method of sync operation, and will not prompt for user input after execution. - -```bash -./gravity-sync.sh pull -``` - -If the execution completes, you will now have overwritten your running `gravity.db` and `custom.list` on the secondary Pi-hole after creating a copy of the running files (with `.backup` appended) in the `backup` subfolder located with your script. Gravity Sync will also keep a copy of the last sync'd files from the primary (in the `backup` folder appended with `.pull`) for future use. - -### The Push Function -Gravity Sync includes the ability to `push` from the secondary Pi-hole back to the primary. This would be useful in a situation where your primary Pi-hole is down for an extended period of time, and you have made list changes on the secondary Pi-hole that you want to force back to the primary, when it comes online. - -```bash -./gravity-sync.sh push -``` - -Before executing, this will make a copy of the remote database under `backup/gravity.db.push` and `backup/custom.list.push` then sync the local configuration to the primary Pi-hole. - -This function purposefuly asks for user interaction to avoid being accidentally automated. - -- If your script prompts for a password on the remote system, make sure that your remote user account is setup not to require passwords in the sudoers file. - -### The Restore Function -Gravity Sync can also `restore` the database on the secondary Pi-hole in the event you've overwritten it accidentally. This might happen in the above scenario where you've had your primary Pi-hole down for an extended period, made changes to the secondary, but perhaps didn't get a chance to perform a `push` of the changes back to the primary, before your automated sync ran. - -```bash -./gravity-sync.sh restore -``` - -This will copy your last `gravity.db.backup` and `custom.list.backup` to the running copy on the secondary Pi-hole. - -This function purposefuly asks for user interaction to avoid being accidentally automated. - ## Updates If you'd like to know what version of the script you have running the built in version checker. It will notify you if there are updates available. @@ -156,4 +128,4 @@ Keep in mind if your cron task has never run, you will not see any valid output You can verify your existing automation entry by running `crontab -l` and see it listed at the bottom of the crontab file. If you decide to remove or change your frequency (as of version 1.8.3) you can run `./gravity-sync.sh automate` again and pick a new timing, including setting it to 0 to disable automation. ## Advanced Installation -Please review the [Advanced Installation](https://github.com/vmstan/gravity-sync/blob/master/ADVANCED.md) guide for assistance. +Please review the [Advanced Installation](https://github.com/vmstan/gravity-sync/blob/master/ADVANCED.md) guide for more assistance. diff --git a/gravity-sync.sh b/gravity-sync.sh index 708d546..1611444 100755 --- a/gravity-sync.sh +++ b/gravity-sync.sh @@ -3,7 +3,7 @@ SCRIPT_START=$SECONDS # GRAVITY SYNC BY VMSTAN ##################### PROGRAM='Gravity Sync' -VERSION='2.0.1' +VERSION='2.0.2' # Execute from the home folder of the user who owns it (ex: 'cd ~/gravity-sync') # For documentation or downloading updates visit https://github.com/vmstan/gravity-sync @@ -1021,7 +1021,7 @@ function detect_remotersync { CMD_REQUESTED="touch ~/gs.test" create_sshcmd - MESSAGE="If this fails make sure RSYNC is installed on ${REMOTE_HOST}" + MESSAGE="If pull test fails insure RSYNC is installed on ${REMOTE_HOST}" echo_warn MESSAGE="Pulling Test File to $HOSTNAME"