2.2.1

• Corrects issue with Smart Sync where it would fail if there was no custom.list already present on the local Pi-hole. #86
• Adds Pi-hole default directories to gravity-sync.conf.example file.
• Adds RIHOLE_BIN variable to specify different Pi-hole binary location on remote server. #87

2.2.0

This release removes support for Dropbear SSH client/server. If you are using this instead of OpenSSH (common with DietPi) please reconfigure your installation to use OpenSSH. You will want to delete your existing ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub files and run ./gravity-sync.sh configure again to generate a new key and copy it to the primary Pi-hole.

This release also adds the ./gravity-sync.sh purge function that will totally wipe out your existing Gravity Sync installation and reset it to the default state for the version you are running. If all troubleshooting of a bad installation fails, this is the command of last resort.

• Updates the remote backup timeout from 15 to 60, preventing the gravity.db backup on the remote Pi-hole from failing. (PR #76)
• Adds uninstall instructions to the README.md file. (Basically, run the new purge function and then delete the gravity-sync folder.)
• I found a markdown spellcheck utility for Visual Studio Code, and ran it against all my markdown files. I'm sorry, I don't spell good. 🤷‍♂️
• New Star Trek references.

2.1.7

2.1.6

• Adds prompts during ./gravity-sync.sh configure to allow custom SSH port and enable PING avoidance.
• Adds ROOT_CHECK_AVOID variable to advanced configuration options, to help facilitate running Gravity Sync with container installations of Pi-hole. (PR #64)
• Adds the ability to automate automation. :mind_blown_emoji: Please see the ADVANCED.md document for more information. (PR #64)

2.1.7

• Adjusts placement of configuration import to fully implement ROOT_CHECK_AVOID variable.
• Someday I'll understand all these git error messages. 2.1.6 and 2.1.7 are effectively part of the same release.

(Thanks to @fbourqui for this contributions to these releases.)

2.1.5

Skipping a few digits because what does it really matter?

• Implements a new beta branch, and with it a new ./gravity-sync.sh beta function to enable it. This will hopefully allow new features and such to be added for test users who can adopt them and provide feedback before rolling out to the main update branch.
• Uses new SQLITE3 backup methodology introduced in 2.1, for all push/pull sync operations.

2.1.2

• Corrects a bug in backup automation that causes the backup to run every minute during the hour selected.

2.1.1

• Last release was incorrectly published without logic to ignore custom.list if request or not used.

2.1.0

A new function ./gravity-sync.sh backup will now perform a SQLITE3 operated backup of the gravity.db on the local Pi-hole. This can be run at any time you wish, but can also be automated by the ./gravity-sync.sh automate function to run once a day. New and existing users will be prompted to configure both during this task. If can also disable both using the automate function, or just automate one or the other, by setting the value to 0 during setup.

New users will automatically have their local settings backed up after completion of the initial setup, before the first run of any sync tasks.

By default, 7 days worth of backups will be retained in the backup folder. You can adjust the retention length by changing the BACKUP_RETAIN function in your gravity-sync.conf file. See the ADVANCED.md file for more information on setting these custom configuration options.

There are also enhancements to the ./gravity-sync.sh restore function, where as previously this task would only restore the previous copy of the database that is made during sync operations, now this will ask you to select a previous backup copy (by date) and will use that file to restore. This will stop the Pi-hole services on the local server while the task is completed. After a successful restoration, you will now also be prompted to perform a push operation of the restored database to the primary Pi-hole server.

It's suggested to make sure your local restore was successful before completing the restore operation with the push job.

Deprecation

Support for the the Dropbear SSH client/server (which was added in 1.7.6) will be removed in an upcoming version of Gravity Sync. If you are using this instead of OpenSSH (common with DietPi) please reconfigure your installation to use OpenSSH. You will want to delete your existing ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub files and run ./gravity-sync.sh configure again to generate a new key and copy it to the primary Pi-hole.

The ./gravity-sync.sh update and version functions will look for the dbclient binary on the local system and warn users about the upcoming changes.

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
• Move much of the previous README.md to ADVANCED.md file.

2.0.1

• Fixes bug that caused existing crontab entry not to be removed when switching from pull to Smart Sync.

2.0.0

Features
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 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.

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.

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.