3.2.1

• Changes application of permissions for Docker instances to UID:GID instead of names. (#99/#128)
• Adds ./gravity-sync info function to help with troubleshooting installation/configuration settings.

3.2.0

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.

• 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'.
• 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 document for more details.

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.

Not implemented in 3.2.0, but coming within this release, Gravity Sync will be configured to monitor a custom file of your creation in this folder (default is 08-gs-lan.conf) which can contain additional configuration options for DNSMASQ.

An example would be setting different caching options for Pi-hole, or specifying the lookup targets for additional networks. Similar requirements as above for the CNAME syncing must be met for existing installs to leverage this functionality.

3.1.2

• Fix variable missing quotes error in configuration screen.
• Convert all bash files from mix of tabs and spaces to 4 space indentation.

3.1.1

• Fixes issue where Docker based Pi-hole restarts may not complete. #109

3.1.0

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

• Only the official Pi-hole managed Docker image 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.
• Smart Sync, and the associated push/pull operations, now will send exec commands to run Pi-hole restart commands within the Docker container.
• Your container configuration must expose access to the virtual /etc/pihole location to the host's file system, and be configured in your gravity-sync.conf file.

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

• 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.
• Only deploys passwordless SUDO components if deemed necessary. (i.e. Not running as root.)
• Now automatically runs the local configuration function on the secondary Pi-hole after execution.
• 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

• 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.
• Automatically prompts on during setup to configure advanced variables if a Docker installation is detected on the secondary (local) Pi-hole.
• Advanced users can set more options for non-standard deployments at installation. If you are using a Docker deployment of Pi-hole on your primary (remote) Pi-hole, but not the system running Gravity Sync, you will need to enter this advanced mode when prompted.
• 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

• REMOTE_FILE_OWNER variable renamed RILE_OWNER for consistency.
• RIHOLE_DIR variable added to set different Pi-hole directory for remote host than local.
• DOCKER_CON and ROCKER_CON variables added to specify different names for local and remote Pi-hole Docker containers.
• PH_IN_TYPE and RH_IN_TYPE variables allow you to to either standard or Docker deployments of Pi-hole, per side.
• 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

• 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

• Lots of long standing little buggles have been squashed.

Branding

• I made a logo.

3.0.2

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

3.0.1

• dev function now automatically updates Gravity Sync after application.
• dev function pulls new branches down before prompting to select which one to update against.
• Minor shuffle of gravity-sync.sh contents.
• Clarify installation requirements in README.md.
• Fixes issues with permissions on gravity.db after push operations.

3.0.0

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.

This release also features a brand new installation script, including a host check for both the primary and secondary Pi-hole system. This should reduce frustration of users who are missing parts of the system requirements. This will also place a file in the sudoers.d file on both systems to make sure passwordless sudo is configured as part of the installation.

Lastly, we adopts Pi-hole style iconography such as ✓ ✗ e ! ? instead of [ GOOD ] in command output.

Enjoy!

2.2.3

• Adds variable to easily override database/binary file owners, useful for container deployments. (Thanks @dpraul )
• Adds variable to easily override Pi-hole binary directory for remote host, seperate from local host. (Thanks @dpraul)
• Rewritten dev option now lets you select the branch to pull code against, allowing for more flexibility in updating against test versions of the code. The beta function introduced in 2.1.5 has now been removed.
• Validates existance of SQLite installation on local Pi-hole. (#97)
• Adds Gravity Sync permissions for running user to local /etc/sudoer.d file during config operation. (#92)
• 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. (#92)

2.2.2

• Corrects another logical problem that prevented custom.list from being backed up and replicated, if it didn't already exist on the local Pi-hole.