Cutlery/gravity-sync
1
0
Fork 0
mirror of https://github.com/vmstan/gravity-sync.git synced 2025-07-09 02:34:06 -04:00
Code Issues Packages Projects Releases Wiki Activity

Updated Pull vs Push (markdown)

Michael Stanclift 2020-10-21 20:54:35 -05:00
parent 21d1592b20
commit a007161b34
1 changed files with 9 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
Pull-vs-Push.md

@ -12,26 +12,17 @@ This allows you to be more flexible in where you make your configuration changes
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.
### The Pull Function
### When to Pull
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.
`./gravity-sync.sh pull` can/should be run when:
```bash
./gravity-sync.sh pull
```
- You are doing a fresh secondary Pi-hole deployment, and setting up Gravity Sync along side it, and you want to make sure that you don't push an empty or temporary copy of your database to the primary system.
- You know that your environment will never make changes to the secondary, perhaps in environments where the secondary is an HA pair behind a load balancer or another virtual IP address provider like keepalived, or in a different network (VPN).
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.
### When to Push
### The Push Function
`./gravity-sync.sh pull` can/should be run when:
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 purposefully 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.
- Your primary Pi-hole been offline for an extended period of time and there are changes from the secondary that you want to force back.
- Your secondary Pi-hole is actually in a public cloud provider, and the network requirements are such that pulling data to the secondary are more complicated than pushing them to a device with a dedicate IP address. (Note, in this case Gravity Sync actually would configured to run _on the primary internal/LAN_ Pi-hole.)
- You've done a restore of the gravity.db or custom.list to the secondary using `./gravity-sync.sh restore` and want to make sure those changes are replicated to the primary.