Cutlery/gravity-sync
1
0
Fork 0
mirror of https://github.com/vmstan/gravity-sync.git synced 2025-07-31 14:33:47 -04:00
Code Issues Packages Projects Releases Wiki Activity

Updated Changelog (markdown)

Michael Stanclift 2021-02-11 11:48:19 -06:00
parent 0a98b15fed
commit 054ad158a0
1 changed files with 51 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

131
Changelog.md

@ -1,6 +1,4 @@
## 3.3
### The Podman Release
## 3.3 - The Podman Release
For this release, "beta" support for [Podman](https://podman.io) based container deployments has been added. (Thanks to work by [@mfschumann](https://github.com/vmstan/gravity-sync/pull/138)) This is marked as beta because at the moment, Gravity Sync may not be regularly tested with this container engine and so regular support may be limited. Use of the official Pi-hole container image is still required.
@ -8,30 +6,32 @@ This release also removes automated nightly backups as a function of the automat
Additionally, this release focuses on making some of the prompts and messages in Gravity Sync easier to understand. Starting with the initial install and configuration wizard. As the script has grown, added features, and become more complex... more options are necessary during install and it wasn't always clear what to do. This release adds some clarification to various components and will change over time.
#### Configuration Changes
### Configuration Changes
- The first time you execute Gravity Sync after upgrading to 3.3, your `gravity-sync.conf` file will be moved into a `settings` folder in the same directory.
- The first time you execute Gravity Sync after upgrading to 3.3, your existing `gravity-sync.md5`, `gravity-sync.log`, and `gravity-sync.cron` files will be moved into a `logs` folder in the same directory.
- The default number days for which backups are retained has been reduced from 7 to 3.
#### Bug Fixes
### Bug Fixes
- Docker Swarm use for the Pi-hole container should be supported by a change in the execution command.
## 3.2
#### 3.3.1
### The Alias Release
- Fixes issue with inverted Advanced Install Options selection [\#163](https://github.com/vmstan/gravity-sync/issues/163)
This release now fully supports Pi-hole 5.2, specifically the CNAME replication features that were added. Because the location of these settings is in a new directory that was not previously monitored by Gravity Sync, you will need to opt-in to replication by updating your configuration file.
## 3.2 - The Alias Release
This release now fully supports Pi-hole 5.2, specifically the CNAME replication features that were added. Because the location of these settings is in a new directory that was not previously monitored by Gravity Sync, you will need to opt-in to replication by updating your configuration file to enable support for replicating this.
- New setups can be prompted to enable this during configuration using the Advanced Configuration options.
- Existing installs wishing to make use of this feature, should either re-run the `./gravity-sync config` command, or manually edit the `gravity-sync.conf` to set `INCLUDE_CNAME='1'`.
- Existing installs wishing to make sure of this feature, should either re-run the `./gravity-sync config` command, or manually edit the `gravity-sync.conf` to set `INCLUDE_CNAME='1'`.
- Before you enable `INCLUDE_CNAME` make sure you've created at least one entry from within the primary Pi-hole interface, otherwise Gravity Sync will have nothing to replicate as the files will not yet exist.
- You cannot enable `INCLUDE_CNAME` if you've also enabled `SKIP_CUSTOM` as the CNAME function is dependent on Local DNS records. You can, however, only replicate the Local DNS Records if you do not intend to leverage CNAME records.
- Existing installs using Docker, or otherwise using a non-standard location for dnsmasq configuration files (default is `/etc/dnsmasq.d`) will also need to manually specify the location of these files.
- See the [Hidden Figures](https://github.com/vmstan/gravity-sync/wiki/Hidden-Figures) document for more details.
#### More Syncing Coming
### More Syncing Coming
Even before the Pi-hole team added the CNAME feature and implemented in such a way that the `/etc/dnsmasq.d` would need to be seen by Gravity Sync, I have had a desire to replicate additional custom files here for my own selfish needs. More people asked for a similar function, and now that it's required to be built into the core script, it's easier to include these additional files.
@ -47,8 +47,9 @@ An example would be setting different caching options for Pi-hole, or specifying
#### 3.2.2
The `./gravity-sync.sh restore` process completely revamped:
- You can now choose to ignore any of the three elements during restore.
- The prompts are clearer and more consistent with Gravity Sync script styling.
- You can now choose to ignore any of the three elements during restore.
- The prompts are clearer and more consistent with Gravity Sync script styling.
- Importantly, lack of backup files in an element will not cause the restoration to fail.
#### 3.2.3
@ -68,15 +69,13 @@ The `./gravity-sync.sh restore` process completely revamped:
- Adds old backup removal tasks into push/pull/sync/compare functions.
## 3.1
### The Container Release
## 3.1 - The Container Release
The premise of this release was to focus on adding better support for Docker container instances of Pi-hole. This release also changes a lot of things about the requirements that Gravity Sync has always had, which were not running as the root user, and requiring that the script be run from the user's home directory. Those two restrictions are gone.
You can now use a standard Pi-hole install as your primary, or your secondary. You can use a Docker install of Pi-hole as your primary, or your secondary. You can mix and match between the two however you choose. You can have Pi-hole installed in different directories at each side, either as standard installs or with container configuration files in different locations. Overall it's much more flexible.
#### Docker Support
### Docker Support
- Only the [official Pi-hole managed Docker image](https://hub.docker.com/r/pihole/pihole) is supported. Other builds may work, but they have not been tested.
- If you are using a name for your container other than the default `pihole` in your Docker configuration, you must specify this in your `gravity-sync.conf` file.
@ -85,7 +84,7 @@ You can now use a standard Pi-hole install as your primary, or your secondary. Y
**Example:** if your container configuration looked something like like `-v /home/vmstan/etc-pihole/:/etc/pihole` then the location `/home/vmstan/etc-pihole` would need to be accessible by the user running Gravity Sync, and be configured as the `PIHOLE_DIR` (or `RIHOLE_DIR`) in your `gravity-sync.conf` file.
#### Installation Script
### Installation Script
- Detects the running instance of default Pi-hole Docker container image, if standard Pi-hole lookup fails. Pi-hole must still be installed prior to Gravity Sync.
- Changes detection of root vs sudo users, and adapts commands to match. You no longer need to avoid running the script as `root`.
@ -94,7 +93,7 @@ You can now use a standard Pi-hole install as your primary, or your secondary. Y
- Deploys script via `git` to whatever directory the installer runs in, instead of defaulting to the user's `$HOME` directory.
- Gravity Sync no longer requires that it be run from the user's `$HOME` directory.
#### Configuration Workflow
### Configuration Workflow
- Overall, a simpler configuration function, as the online installer now checks for the dependencies prior to execution.
- New users with basic Pi-hole installs will only be prompted for the address of the primary (remote) Pi-hole, an SSH user and then the SSH password to establish a trusted relationship and share the keyfiles.
@ -103,7 +102,7 @@ You can now use a standard Pi-hole install as your primary, or your secondary. Y
- Existing users with default setups should not need to run the config utility again after upgrading, but those with custom installs (especially existing container users) should consider it to adopt new variable names and options in your config files.
- Creates a BASH environment alias to run the command `gravity-sync` from anywhere on the system. If you use a different shell (such as zsh or fish) as your default this may need to be added manually.
#### New Variables
### New Variables
- `REMOTE_FILE_OWNER` variable renamed `RILE_OWNER` for consistency.
- `RIHOLE_DIR` variable added to set different Pi-hole directory for remote host than local.
@ -112,21 +111,19 @@ You can now use a standard Pi-hole install as your primary, or your secondary. Y
- `DOCKER_BIN` and `ROCKER_BIN` variables allow you to set non-standard locations for Docker binary files, per side.
- Adds all variables to `gravity-sync.conf.example` for easy customization.
#### Removals
### Removals
- Support for `sshpass` has been removed, the only valid authentication method going forward will be ssh-key based.
- If you've previously configured Gravity Sync using `sshpass` you will need to run `./gravity-sync.sh config` again to create a new configuration file.
#### Bug Killer
### Bug Killer
- Lots of long standing little buggles have been squashed.
#### Branding
### Branding
- I made a logo.
<img src="https://raw.githubusercontent.com/vmstan/gravity-sync/master/docs/gs-logo.svg" height="150" width="150" alt="Gravity Sync">
#### 3.1.1
- Corrected an error where Docker exec commands would not run correctly on some distributions.
@ -136,9 +133,7 @@ You can now use a standard Pi-hole install as your primary, or your secondary. Y
- Fix variable missing quotes error in configuration screen.
- Convert all bash files from mix of tabs and spaces to 4 space indentation.
## 3.0
### The Breakout Release
## 3.0 - The Breakout Release
This release focuses on breaking out elements of the script from the main file into a collection of a dozen or so files located under the `includes/gs-*.sh` hirearchy. Seperating out allows new contributors to work on different parts of the script individually, provides an oppertunity to clean up and reorganize parts of the code, and hopefully provides less risk of breaking the entire script.
@ -162,16 +157,14 @@ Enjoy!
- Realigned EPS conduits, they overheat if you leave them pointed the same way for too long.
- Corrected error when running via crontab where includes directory was not properly sourced.
## 2.2
### The Purged Release
## 2.2 - The Purged Release
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](https://github.com/vmstan/gravity-sync/pull/76))
- Adds uninstall instructions to the README.md file. (Basically, run the new `purge` function and then delete the `gravity-sync` folder.)
- Updates the remote backup timeout from 15 to 60, preventing the `gravity.db` backup on the remote Pi-hole from failing. (PR [\#76](https://github.com/vmstan/gravity-sync/pull/76))
- Adds uninstall instructions to the [README.md](http://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.
@ -194,9 +187,7 @@ This release also adds the `./gravity-sync.sh purge` function that will totally
- Adds Gravity Sync permissions for running user to local `/etc/sudoer.d` file during `config` operation.
- Adds `./gravity-sync.sh sudo` function to create above file for existing setups, or to configure the remote Pi-hole by placing the installer files on that system. This is not required for existing functional installs, but this should also negate the need to give the Gravity Sync user NOPASSWD permissions to the entire system.
## 2.1
### The Backup Release
## 2.1 - The Backup Release
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.
@ -208,7 +199,7 @@ There are also enhancements to the `./gravity-sync.sh restore` function, where a
It's suggested to make sure your local restore was successful before completing the `restore` operation with the `push` job.
#### Dropbear Notice
### Dropbear Notice
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.
@ -235,8 +226,8 @@ Skipping a few digits because what does it really matter?
#### 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](https://github.com/vmstan/gravity-sync/pull/64))
- Adds the ability to automate automation. :mind_blown_emoji: Please see the ADVANCED.md document for more information. (PR [#64](https://github.com/vmstan/gravity-sync/pull/64))
- Adds `ROOT_CHECK_AVOID` variable to advanced configuration options, to help facilitate running Gravity Sync with container installations of Pi-hole. (PR [\#64](https://github.com/vmstan/gravity-sync/pull/64))
- Adds the ability to automate automation. :mind_blown_emoji: Please see the [ADVANCED.md](http://ADVANCED.md) document for more information. (PR [\#64](https://github.com/vmstan/gravity-sync/pull/64))
(Thanks to [@fbourqui](https://github.com/fbourqui) for this contributions to this release.)
@ -245,15 +236,13 @@ Skipping a few digits because what does it really matter?
- Adjusts placement of configuration import to fully implement `ROOT_CHECK_AVOID` variable.
- Someday I'll understand all these git error messages.
## 2.0
### The Smart Release
## 2.0 - The Smart Release
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 initiate 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.
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.
@ -261,19 +250,17 @@ 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. [#50](https://github.com/vmstan/gravity-sync/issues/50)
- 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.
- 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)
- 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
## 1.8 - The Logical Release
There is nothing really sexy here, but a lot of changes under the covers to improve reliability between different SSH client types. A lot of the logic and functions are more consistent and cleaner. In some cultures, fewer bugs and more reliability are considered features. Much of this will continue through the 1.8.x line.
@ -285,11 +272,11 @@ There is nothing really sexy here, but a lot of changes under the covers to impr
#### 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)
- 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)
- 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
@ -298,17 +285,15 @@ There is nothing really sexy here, but a lot of changes under the covers to impr
- 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.7
## 1.7 - The Andrew Release
### The Andrew Release
#### Features
### Features
- Gravity Sync will now manage the `custom.list` file that contains the "Local DNS Records" function within the Pi-hole interface.
- If you do not want this feature enabled it can be bypassed by adding a `SKIP_CUSTOM='1'` to your .conf file.
- Sync will be trigged during a pull operation if there are changes to either file.
#### Known Issues
### Known Issues
- No new Star Trek references.
@ -321,7 +306,7 @@ There is nothing really sexy here, but a lot of changes under the covers to impr
This update changes the way that beta/development updates are applied. To continue receiving 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.
```bash
```swift
cd gravity-sync
touch dev
./gravity-sync.sh update
@ -381,9 +366,7 @@ Delete the `dev` file and update again to revert back to the stable/master branc
- When applying `update` in DEV mode, the Git branch used will be shown.
- Validates log export operation.
## 1.6
### The Restorative Release
## 1.6 - The Restorative Release
- New `./gravity-sync.sh restore` function will bring a previous version of the `gravity.db` back from the dead.
- Changes the way that Gravity Sync prompts for data input and how confirmation prompts are handled.
@ -391,18 +374,14 @@ Delete the `dev` file and update again to revert back to the stable/master branc
- Five new Star Trek references.
- New functions add consistency in status output.
## 1.5
### The Automated Release
## 1.5 - The Automated Release
- You can now easily deploy the task automation via crontab by running `./gravity-sync.sh automate` which will simply ask how often you'd like to run the script per hour, and then create the entry for you.
- If you've already configured an entry for this manually with a prior version, the script should detect this and ask that you manually remove it or edit it via crontab -e. I'm hesitant to delete existing entries here, as it could potentially remove something unrelated to Gravity Sync.
- Changes the method for pulling development branch updates via the 'beta' function.
- Cleanup of various exit commands.
## 1.4
### The Configuration Release
## 1.4 - The Configuration Release
- Adds new `./gravity-sync config` feature to simplify deployment!
- Adds variables for SSH settings.
@ -422,11 +401,9 @@ Delete the `dev` file and update again to revert back to the stable/master branc
- Bug fixes around not properly utilizing custom SSH key-file.
## 1.3
## 1.3 - The Comparison Release
### The Comparison Release
1.3 should be called 2.0, but I'll resist that temptation -- but there are so many new enhancements!
1.3 should be called 2.0, but I'll resist that temptation–but there are so many new enhancements!
- Gravity Sync will now compare remote and local databases and only replicate if it detects a difference.
- Verifies most commands complete before continuing each step to fail more gracefully.
@ -453,9 +430,7 @@ Delete the `dev` file and update again to revert back to the stable/master branc
- Validates file ownership and permissions before attempting to rewrite.
- Added two Star Trek references.
## 1.2
### The Functional Release
## 1.2 - The Functional Release
- Refactored process to use functions and cleanup process of execution.
- Does not look for permission to update when run.
@ -484,9 +459,7 @@ Delete the `dev` file and update again to revert back to the stable/master branc
- Push function now does a backup, on the secondary PH, of the primary database, before pushing.
## 1.1
### The Pushy Release
## 1.1 - The Pushy Release
- Separated main purpose of script into `pull` argument.
- Allow process to reverse back using `push` argument.
@ -513,13 +486,11 @@ Delete the `dev` file and update again to revert back to the stable/master branc
- Code easier to read with proper tabs.
## 1.0
### The Initial Release
## 1.0 - The Initial Release
No version control, variables or anything fancy. It only worked if everything was exactly perfect.
```bash
```swift
echo 'Copying gravity.db from HA primary'
rsync -e 'ssh -p 22' ubuntu@192.168.7.5:/etc/pihole/gravity.db /home/pi/gravity-sync
echo 'Replacing gravity.db on HA secondary'
@ -528,4 +499,4 @@ echo 'Reloading configuration of HA secondary FTLDNS from new gravity.db'
pihole restartdns reload-lists
```
For real, that's it. 6 lines, and could probably have be done with less.
For real, that's it. 6 lines, and could probably have be done with less.