mirror of
https://github.com/vmstan/gravity-sync.git
synced 2024-08-30 18:22:11 +00:00
2.2.0 (#81)
* import config file before executing * show_target function * git * Sync back (#72) * 2.1.6 beta 1 (#65) * select different files for restore * star trek reference * Log backup jobs * color restore * ping avoid and custom ssh prompts * z variable * or * [] * new method for defaults * variables matter * or this? * making it specific Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> * 2.1.6 beta 2 (#67) * select different files for restore * star trek reference * Log backup jobs * color restore * ping avoid and custom ssh prompts * z variable * or * [] * new method for defaults * variables matter * or this? * making it specific * adv conf: add ROOT_CHECK_AVOID for container. (#64) * adv conf: add ROOT_CHECK_AVOID for container. import_gs only once at start * allow parameters for automation option Co-authored-by: Michael Stanclift <mstanclift@vmware.com> * Post PR cleanup * Thanks for fbourqui * readjusts import_gs Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: fbourqui <fbourqui@yahoo.com> * 2.1.7 (#70) * import config file before executing * show_target function * git Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: fbourqui <fbourqui@yahoo.com> * Sync back (#73) * 2.1.6 beta 1 (#65) * select different files for restore * star trek reference * Log backup jobs * color restore * ping avoid and custom ssh prompts * z variable * or * [] * new method for defaults * variables matter * or this? * making it specific Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> * 2.1.6 beta 2 (#67) * select different files for restore * star trek reference * Log backup jobs * color restore * ping avoid and custom ssh prompts * z variable * or * [] * new method for defaults * variables matter * or this? * making it specific * adv conf: add ROOT_CHECK_AVOID for container. (#64) * adv conf: add ROOT_CHECK_AVOID for container. import_gs only once at start * allow parameters for automation option Co-authored-by: Michael Stanclift <mstanclift@vmware.com> * Post PR cleanup * Thanks for fbourqui * readjusts import_gs Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: fbourqui <fbourqui@yahoo.com> Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: fbourqui <fbourqui@yahoo.com> * spellcheck is awesome * I speel reel gurd * Spelling sucks * Update remote backup timeout to 60 This will avoid [ FAIL ] Performing Backup of Remote gravity.db * readme updates * spelling * extra fi * config cleanup * hide if dbclient installed but also ssh * move backup in config * backup process in configure * 2.2.0 beta 1 (#78) * 2.1.6 beta 1 (#65) * select different files for restore * star trek reference * Log backup jobs * color restore * ping avoid and custom ssh prompts * z variable * or * [] * new method for defaults * variables matter * or this? * making it specific Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> * 2.1.6 beta 2 (#67) * select different files for restore * star trek reference * Log backup jobs * color restore * ping avoid and custom ssh prompts * z variable * or * [] * new method for defaults * variables matter * or this? * making it specific * adv conf: add ROOT_CHECK_AVOID for container. (#64) * adv conf: add ROOT_CHECK_AVOID for container. import_gs only once at start * allow parameters for automation option Co-authored-by: Michael Stanclift <mstanclift@vmware.com> * Post PR cleanup * Thanks for fbourqui * readjusts import_gs Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: fbourqui <fbourqui@yahoo.com> * import config file before executing * show_target function * git * Sync back (#72) * 2.1.6 beta 1 (#65) * select different files for restore * star trek reference * Log backup jobs * color restore * ping avoid and custom ssh prompts * z variable * or * [] * new method for defaults * variables matter * or this? * making it specific Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> * 2.1.6 beta 2 (#67) * select different files for restore * star trek reference * Log backup jobs * color restore * ping avoid and custom ssh prompts * z variable * or * [] * new method for defaults * variables matter * or this? * making it specific * adv conf: add ROOT_CHECK_AVOID for container. (#64) * adv conf: add ROOT_CHECK_AVOID for container. import_gs only once at start * allow parameters for automation option Co-authored-by: Michael Stanclift <mstanclift@vmware.com> * Post PR cleanup * Thanks for fbourqui * readjusts import_gs Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: fbourqui <fbourqui@yahoo.com> * 2.1.7 (#70) * import config file before executing * show_target function * git Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: fbourqui <fbourqui@yahoo.com> * spellcheck is awesome * I speel reel gurd * Spelling sucks * Update remote backup timeout to 60 This will avoid [ FAIL ] Performing Backup of Remote gravity.db * readme updates * spelling * extra fi * config cleanup * hide if dbclient installed but also ssh * move backup in config * backup process in configure Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: fbourqui <fbourqui@yahoo.com> Co-authored-by: Sungray <ced.lapage@gmail.com> Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.local> * THE PURGE * PURGE IT * PURRRRRRGE * Purged Release * if beta * pihole note * silence git output * 2.2.0 beta 2 (#79) * 2.1.6 beta 1 (#65) * select different files for restore * star trek reference * Log backup jobs * color restore * ping avoid and custom ssh prompts * z variable * or * [] * new method for defaults * variables matter * or this? * making it specific Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> * 2.1.6 beta 2 (#67) * select different files for restore * star trek reference * Log backup jobs * color restore * ping avoid and custom ssh prompts * z variable * or * [] * new method for defaults * variables matter * or this? * making it specific * adv conf: add ROOT_CHECK_AVOID for container. (#64) * adv conf: add ROOT_CHECK_AVOID for container. import_gs only once at start * allow parameters for automation option Co-authored-by: Michael Stanclift <mstanclift@vmware.com> * Post PR cleanup * Thanks for fbourqui * readjusts import_gs Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: fbourqui <fbourqui@yahoo.com> * import config file before executing * show_target function * git * Sync back (#72) * 2.1.6 beta 1 (#65) * select different files for restore * star trek reference * Log backup jobs * color restore * ping avoid and custom ssh prompts * z variable * or * [] * new method for defaults * variables matter * or this? * making it specific Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> * 2.1.6 beta 2 (#67) * select different files for restore * star trek reference * Log backup jobs * color restore * ping avoid and custom ssh prompts * z variable * or * [] * new method for defaults * variables matter * or this? * making it specific * adv conf: add ROOT_CHECK_AVOID for container. (#64) * adv conf: add ROOT_CHECK_AVOID for container. import_gs only once at start * allow parameters for automation option Co-authored-by: Michael Stanclift <mstanclift@vmware.com> * Post PR cleanup * Thanks for fbourqui * readjusts import_gs Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: fbourqui <fbourqui@yahoo.com> * 2.1.7 (#70) * import config file before executing * show_target function * git Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: fbourqui <fbourqui@yahoo.com> * spellcheck is awesome * I speel reel gurd * Spelling sucks * Update remote backup timeout to 60 This will avoid [ FAIL ] Performing Backup of Remote gravity.db * readme updates * spelling * extra fi * config cleanup * hide if dbclient installed but also ssh * move backup in config * backup process in configure * THE PURGE * PURGE IT * PURRRRRRGE * Purged Release * if beta * pihole note * silence git output Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: fbourqui <fbourqui@yahoo.com> Co-authored-by: Sungray <ced.lapage@gmail.com> Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.local> * Installation instructions. * bash * words * purge now updates * purge reword * more warnigns * 2.2.0 Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.vmstan.net> Co-authored-by: fbourqui <fbourqui@yahoo.com> Co-authored-by: Sungray <ced.lapage@gmail.com> Co-authored-by: Michael Stanclift <vmstan@MS-MacBook.local>
This commit is contained in:
Michael Stanclift
GitHub
parent
0275a79573
commit
4aa301f179
4
.gitignore
vendored
4
.gitignore
vendored
@ -7,4 +7,6 @@ backup/*.last
|
||||
backup/*.backup
|
||||
backup/*.push
|
||||
backup/*.pull
|
||||
dev
|
||||
dev
|
||||
.vscode
|
||||
.DS_Store
|
||||
106
ADVANCED.md
106
ADVANCED.md
@ -1,12 +1,16 @@
|
||||
# Gravity Sync
|
||||
|
||||
## Advanced Configuration
|
||||
The purpose of this guide is to break out the manual install instructions, and any advanced configuration flags, into a seperate document to limit confusion from the primary README. It is expected that users have read and are familiar with the process and concepts outlined in the primary README.
|
||||
|
||||
The purpose of this guide is to break out the manual install instructions, and any advanced configuration flags, into a separate document to limit confusion from the primary README. It is expected that users have read and are familiar with the process and concepts outlined in the primary README.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- If you're installing Gravity Sync on a system running Fedora or CentOS, make sure that you are not just using the built in root account and have a dedicated user in the Administrator group. You'll also need SELinux disabled to install Pi-hole.
|
||||
|
||||
## Installation
|
||||
If you don't trust `git` to install your software, or just like doing things by hand, that's fine.
|
||||
|
||||
If you don't trust `git` to install your software, or just like doing things by hand, that's fine.
|
||||
|
||||
*Keep in mind that installing via this method means you won't be able to use Gravity Sync's built-in update mechanism.*
|
||||
|
||||
@ -14,14 +18,15 @@ Download the latest release from [GitHub](https://github.com/vmstan/gravity-sync
|
||||
|
||||
```bash
|
||||
cd ~
|
||||
wget https://github.com/vmstan/gravity-sync/archive/v2.1.7.zip
|
||||
unzip v2.1.7.zip -d gravity-sync
|
||||
wget https://github.com/vmstan/gravity-sync/archive/v2.2.0.zip
|
||||
unzip v2.2.0.zip -d gravity-sync
|
||||
cd gravity-sync
|
||||
```
|
||||
|
||||
Please note the script **must** be run from a folder in your user home directory (ex: /home/USER/gravity-sync) -- I wouldn't suggest deviating from the gravity-sync folder name. If you do you'll need to also change the configuration settings defined in the `gravity-sync.sh` script, which can be a little tedious to do everytime you upgrade the script.
|
||||
Please note the script **must** be run from a folder in your user home directory (ex: /home/USER/gravity-sync) -- I wouldn't suggest deviating from the gravity-sync folder name. If you do you'll need to also change the configuration settings defined in the `gravity-sync.sh` script, which can be a little tedious to do every time you upgrade the script.
|
||||
|
||||
## Configuration
|
||||
|
||||
After you install Gravity Sync to your server there will be a file called `gravity-sync.conf.example` that you can use as the basis for your own `gravity-sync.conf` file. Make a copy of the example file and modify it with your site specific settings.
|
||||
|
||||
```bash
|
||||
@ -29,7 +34,7 @@ cp gravity-sync.conf.example gravity-sync.conf
|
||||
vi gravity-sync.conf
|
||||
```
|
||||
|
||||
*Note: If you don't like VI or don't have VIM on your system, use NANO, or if you don't like any of those subsitute for your text editor of choice. I'm not here to start a war.*
|
||||
*Note: If you don't like VI or don't have VIM on your system, use NANO, or if you don't like any of those substitute for your text editor of choice. I'm not here to start a war.*
|
||||
|
||||
Make sure you've set the REMOTE_HOST and REMOTE_USER variables with the IP (or DNS name) and user account to authenticate to the primary Pi. This account will need to have sudo permissions on the remote system.
|
||||
|
||||
@ -41,10 +46,12 @@ REMOTE_USER='pi'
|
||||
*Do not set the `REMOTE_PASS` variable until you've read the next section on SSH.*
|
||||
|
||||
### SSH Configuration
|
||||
|
||||
Gravity Sync uses SSH to run commands on the primary Pi-hole, and sync the two systems by performing file copies. There are two methods available for authenticating with SSH.
|
||||
|
||||
#### Key-Pair Authentication
|
||||
This is the preferred option, as it's more reliable and less dependant on third party plugins.
|
||||
|
||||
This is the preferred option, as it's more reliable and less dependent on third party plugins.
|
||||
|
||||
You'll need to generate an SSH key for your secondary Pi-hole user and copy it to your primary Pi-hole. This will allow you to connect to and copy the necessary files without needing a password each time. When generating the SSH key, accept all the defaults and do not put a passphrase on your key file.
|
||||
|
||||
@ -55,11 +62,12 @@ ssh-keygen -t rsa
|
||||
ssh-copy-id -i ~/.ssh/id_rsa.pub REMOTE_USER@REMOTE_HOST
|
||||
```
|
||||
|
||||
Subsitute REMOTE_USER for the account on the primary Pi-hole with sudo permissions, and REMOTE_HOST for the IP or DNS name of the Pi-hole you have designated as the primary.
|
||||
Substitute REMOTE_USER for the account on the primary Pi-hole with sudo permissions, and REMOTE_HOST for the IP or DNS name of the Pi-hole you have designated as the primary.
|
||||
|
||||
Make sure to leave the `REMOTE_PASS` variable set to nothing in `gravity-sync.conf` if you want to use key-pair authentication.
|
||||
|
||||
#### Password Authentication
|
||||
|
||||
This is the non-preferred option, as it depends on an non-standard utility called `sshpass` which must be installed on your secondary Pi-hole. Install it using your package manager of choice. The example below is for Raspberry Pi OS (previously Raspbian) or Ubuntu.
|
||||
|
||||
```bash
|
||||
@ -72,20 +80,22 @@ Then enter your password in the `gravity-sync.conf` file you configured above.
|
||||
REMOTE_PASS='password'
|
||||
```
|
||||
|
||||
Gravity Sync will validate that the `sshpass` utility is installed on your system and failback to attempting key-pair authentication if it's not detected.
|
||||
Gravity Sync will validate that the `sshpass` utility is installed on your system and fail-back to attempting key-pair authentication if it's not detected.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
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
|
||||
@ -94,11 +104,12 @@ Gravity Sync includes the ability to `push` from the secondary Pi-hole back to t
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
### 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
|
||||
@ -107,34 +118,40 @@ Gravity Sync can also `restore` the database on the secondary Pi-hole in the eve
|
||||
|
||||
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.
|
||||
This function purposefully 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.
|
||||
|
||||
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 supersede 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.
|
||||
|
||||
#### `SSH_PORT=''`
|
||||
|
||||
Gravity Sync is configured by default to use the standard SSH port (22) but if you need to change this, such as if you're traversing a NAT/firewall for a multi-site deployment, to use a non-standard port.
|
||||
|
||||
Default setting in Gravity Sync is 22.
|
||||
|
||||
#### `SSH_PKIF=''`
|
||||
Gravity Sync is configured by default to use the `.ssh/id_rsa` keyfile that is generated using the `ssh-keygen` command. If you have an existing keyfile stored somewhere else that you'd like to use, you can configure that here. The keyfile will still need to be in the users $HOME directory.
|
||||
|
||||
At this time Gravity Sync does not support passphrases in RSA keyfiles. If you have a passphrase applied to your standard `.ssh/id_rsa` either remove it, or generate a new file and specify that key for use only by Gravity Sync.
|
||||
Gravity Sync is configured by default to use the `.ssh/id_rsa` key-file that is generated using the `ssh-keygen` command. If you have an existing key-file stored somewhere else that you'd like to use, you can configure that here. The key-file will still need to be in the users $HOME directory.
|
||||
|
||||
At this time Gravity Sync does not support using a passphrase in RSA key-files. If you have a passphrase applied to your standard `.ssh/id_rsa` either remove it, or generate a new file and specify that key for use only by Gravity Sync.
|
||||
|
||||
Default setting in Gravity Sync is `.ssh/id_rsa`
|
||||
|
||||
#### `LOG_PATH=''`
|
||||
|
||||
Gravity Sync will place logs in the same folder as the script (identified as .cron and .log) but if you'd like to place these in a another location, you can do that by identifying the full path to the directory. (ex: `/full/path/to/logs`)
|
||||
|
||||
Default setting in Gravity Sync is `$HOME/${LOCAL_FOLDR}`
|
||||
|
||||
#### `SYNCING_LOG=''`
|
||||
|
||||
Gravity Sync will write a timestamp for any completed sync, pull, push or restore job to this file. If you want to change the name of this file, you will also need to adjust the LOG_PATH variable above, otherwise your file will be remove during an `update` operations.
|
||||
|
||||
Default setting in Gravity Sync is `gravity-sync.log`
|
||||
|
||||
#### `CRONJOB_LOG=''`
|
||||
|
||||
Gravity Sync will log the execution history of the previous automation task via Cron to this file. If you want to change the name of this file, you will also need to adjust the LOG_PATH variable above, otherwise your file will be remove during an `update` operations.
|
||||
|
||||
This will have an impact to both the `./gravity-sync.sh automate` function and the `./gravity-sync.sh cron` functions. If you need to change this after running the automate function, either modify your crontab manually or delete the entry and re-run the automate function.
|
||||
@ -142,44 +159,53 @@ This will have an impact to both the `./gravity-sync.sh automate` function and t
|
||||
Default setting in Gravity Sync is `gravity-sync.cron`
|
||||
|
||||
#### `HISTORY_MD5=''`
|
||||
|
||||
Gravity Sync will log the file hashes of the previous `smart` task to this file. If you want to change the name of this file, you will also need to adjust the LOG_PATH variable above, otherwise your file will be removed during an `update` operations.
|
||||
|
||||
Default setting in Gravity Sync is `gravity-sync.md5`
|
||||
|
||||
#### `VERIFY_PASS=''`
|
||||
Gravity Sync will prompt to verify user interactivity during push, restore, or config operations (that overwrite an existing configuration) with the intention that it prevents someone from accidentally automating in the wrong direction or overwriting data intentionally. If you'd like to automate a push function, or just don't like to be asked twice to do something distructive, then you can opt-out.
|
||||
|
||||
Gravity Sync will prompt to verify user interactivity during push, restore, or config operations (that overwrite an existing configuration) with the intention that it prevents someone from accidentally automating in the wrong direction or overwriting data intentionally. If you'd like to automate a push function, or just don't like to be asked twice to do something destructive, then you can opt-out.
|
||||
|
||||
Default setting in Gravity Sync is 0, change to 1 to bypass this check.
|
||||
|
||||
#### `SKIP_CUSTOM=''`
|
||||
Starting in v1.7.0, Gravity Sync manages the `custom.list` file that contains the "Local DNS Records" function within the Pi-hole interface. If you do not want to sync this setting, perhaps if you're doing a mutli-site deployment with differing local DNS settings, then you can opt-out of this sync.
|
||||
|
||||
Starting in v1.7.0, Gravity Sync manages the `custom.list` file that contains the "Local DNS Records" function within the Pi-hole interface. If you do not want to sync this setting, perhaps if you're doing a multi-site deployment with differing local DNS settings, then you can opt-out of this sync.
|
||||
|
||||
Default setting in Gravity Sync is 0, change to 1 to exempt `custom.list` from replication.
|
||||
|
||||
#### `DATE_OUTPUT=''`
|
||||
#### `DATE_OUTPUT=''`
|
||||
|
||||
*This feature has not been fully implemented, but the intent is to provide the ability to add timestamped output to each status indicator in the script output (ex: [2020-05-28 19:46:54] [EXEC] $MESSAGE).*
|
||||
|
||||
Default setting in Gravity Sync is 0, change to 1 to print timestamped output.
|
||||
|
||||
#### `BASH_PATH=''`
|
||||
|
||||
If you need to adjust the path to bash that is identified for automated execution via Crontab, you can do that here. This will only have an impact if changed before generating the crontab via the `./gravity-sync.sh automate` function. If you need to change this after the fact, either modify your crontab manually or delete the entry and re-run the automate function.
|
||||
|
||||
#### `PING_AVOID=''`
|
||||
|
||||
The `./gravity-sync.sh config` function will attempt to ping the remote host to validate it has a valid network connection. If there is a firewall between your hosts preventing ping replies, or you otherwise wish to skip this step, it can by bypassed here.
|
||||
|
||||
Default setting in Gravity Sync is 0, change to 1 to skip this network test.
|
||||
|
||||
#### `ROOT_CHECK_AVOID=''`
|
||||
|
||||
At execution, Gravity Sync will check that it's deployed with it's own user (not running as root), but for a container deployment this is not necessary.
|
||||
|
||||
Default setting in Gravity Sync is 0, change to 1 to skip this root user test.
|
||||
|
||||
#### `BACKUP_RETAIN=''`
|
||||
|
||||
The `./gravity-sync.sh backup` function will retain a defined number of days worth of `gravity.db` and `custom.list` backups.
|
||||
|
||||
Default setting in Gravity Sync is 7, adjust as resired.
|
||||
Default setting in Gravity Sync is 7, adjust as desired.
|
||||
|
||||
## Execution
|
||||
|
||||
If you are just straight up unable to run the `gravity-sync.sh` file, make sure it's marked as an executable by Linux.
|
||||
|
||||
```bash
|
||||
@ -187,37 +213,45 @@ chmod +x gravity-sync.sh
|
||||
```
|
||||
|
||||
## Updates
|
||||
If you manually installed Gravity Sync via .zip or .tar.gz you will need to download and overwrite the `gravity-sync.sh` file with a newer version. If you've chosen this path, I won't lay out exactly what you'll need to do every time, but you should at least review the contents of the script bundle (specifically the example configuration file) to make sure there are no new additional files or required settings.
|
||||
|
||||
At the very least, I would reccomend backing up your existing `gravity-sync` folder and then deploying a fresh copy each time you update, and then either creating a new .conf file or copying your old file over to the new folder.
|
||||
If you manually installed Gravity Sync via `.zip` or `.tar.gz` you will need to download and overwrite the `gravity-sync.sh` file with a newer version. If you've chosen this path, I won't lay out exactly what you'll need to do every time, but you should at least review the contents of the script bundle (specifically the example configuration file) to make sure there are no new additional files or required settings.
|
||||
|
||||
At the very least, I would recommend backing up your existing `gravity-sync` folder and then deploying a fresh copy each time you update, and then either creating a new .conf file or copying your old file over to the new folder.
|
||||
|
||||
### Development Builds
|
||||
Starting in v1.7.2, you can easily flag if you want to receive the development branch of Gravity Sync when running the built in `./gravity-sync.sh update` function. Beginning in v1.7.4 `./gravity-sync.sh dev` will now toggle the dev flag on/off. No `touch` required, although it still works that way under the covers.
|
||||
|
||||
Starting in v1.7.2, you can easily flag if you want to receive the development branch of Gravity Sync when running the built in `./gravity-sync.sh update` function. Beginning in v1.7.4 `./gravity-sync.sh dev` will now toggle the dev flag on/off. No `touch` required, although it still works that way under the covers.
|
||||
|
||||
To manually adjust the flag, 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
|
||||
cd gravity-sync
|
||||
touch dev
|
||||
./gravity-sync.sh update
|
||||
```
|
||||
|
||||
Delete the `dev` file and update again to revert back to the stable/master branch.
|
||||
|
||||
This method for implementation is decidedly different than the configuration flags in the .conf file, as explained above, to make it easier to identify development systems.
|
||||
|
||||
### Updater Troubleshooting
|
||||
|
||||
If the built in updater doesn't function as expected, you can manually run the git commands that operate under the covers.
|
||||
```
|
||||
|
||||
```bash
|
||||
git fetch --all
|
||||
git reset --hard origin/master
|
||||
```
|
||||
|
||||
Use `origin/development` to pull that branch instead.
|
||||
|
||||
If your code is still not updating after this, reinstallation is suggested rather than spending all your time troubleshooting `git` commands.
|
||||
|
||||
## Automation
|
||||
|
||||
There are many automation methods available to run scripts on a regular basis of a Linux system. The one built into all of them is cron, but if you'd like to utilize something different then the principles are still the same.
|
||||
|
||||
If you prefer to still use cron but modify your settings by hand, using the entry below will cause the entry to run at the top and bottom of every hour (1:00 PM, 1:30 PM, 2:00 PM, etc) but you are free to dial this back or be more agressive if you feel the need.
|
||||
If you prefer to still use cron but modify your settings by hand, using the entry below will cause the entry to run at the top and bottom of every hour (1:00 PM, 1:30 PM, 2:00 PM, etc) but you are free to dial this back or be more aggressive if you feel the need.
|
||||
|
||||
```bash
|
||||
crontab -e
|
||||
@ -228,22 +262,22 @@ crontab -e
|
||||
### Automating Automation
|
||||
|
||||
To automate the deployment of automation option you can call it with 2 parameters:
|
||||
- First interval in minutes to run sync [0-30],
|
||||
- Second the hour to run backup [0-24]
|
||||
|
||||
(0 will disable the cron entry)
|
||||
- First interval in minutes to run sync [0-30]
|
||||
- Second the hour to run backup [0-24]
|
||||
|
||||
For example:
|
||||
`./gravity-sync.sh automate 15 23`
|
||||
_Note: a value of 0 will disable the cron entry._
|
||||
|
||||
Will configure automation of the sync function every 15 minutes and of a backup at 23:00.
|
||||
For example, `./gravity-sync.sh automate 15 23` will configure automation of the sync function every 15 minutes and of a backup at 23:00.
|
||||
|
||||
## 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.
|
||||
|
||||
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 physical 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 appropriate 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
|
||||
|
||||
|
||||
|
||||
This design requires the least amount of overhead, or additional software/network configuration beyond Pi-hole and Gravity Sync.
|
||||
@ -251,9 +285,10 @@ 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.) 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.
|
||||
You can make changes to your block-list, 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
|
||||
|
||||
|
||||
|
||||
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.
|
||||
@ -265,6 +300,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
|
||||
|
||||
|
||||
|
||||
For those who really love Pi-hole and Gravity Sync. Combining the best of both worlds.
|
||||
@ -275,4 +311,4 @@ For those who really love Pi-hole and Gravity Sync. Combining the best of both w
|
||||
|
||||
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.)
|
||||
(I call this crazy, but this is what I use at home.)
|
||||
|
||||
113
CHANGELOG.md
113
CHANGELOG.md
@ -1,6 +1,20 @@
|
||||
# The Changelog
|
||||
|
||||
## 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.)
|
||||
- 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
|
||||
|
||||
### 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.
|
||||
@ -9,24 +23,27 @@ New users will automatically have their local settings backed up after completio
|
||||
|
||||
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.
|
||||
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
|
||||
#### 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.
|
||||
|
||||
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.1.1
|
||||
- Last release was incorrectly published without logic to ignore `custom.list` if request or not used.
|
||||
|
||||
- Last release was incorrectly published without logic to ignore `custom.list` if request or not used.
|
||||
|
||||
#### 2.1.2
|
||||
|
||||
- Corrects a bug in `backup` automation that causes the backup to run every minute during the hour selected.
|
||||
|
||||
#### 2.1.5
|
||||
Skipping a few digits because what does it really matter?
|
||||
|
||||
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.
|
||||
@ -35,6 +52,7 @@ Skipping a few digits because what does it really matter?
|
||||
- `./gravity-sync.sh restore` now shows recent complete Backup executions.
|
||||
|
||||
#### 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))
|
||||
@ -42,13 +60,15 @@ Skipping a few digits because what does it really matter?
|
||||
(Thanks to [@fbourqui](https://github.com/fbourqui) for this contributions to this release.)
|
||||
|
||||
#### 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.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 initate a `push` and/or `pull` specific to each piece.
|
||||
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.
|
||||
|
||||
@ -59,9 +79,11 @@ 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. [#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.
|
||||
@ -69,9 +91,10 @@ New installs will use the `smart` function by default. Existing users who want t
|
||||
- Move much of the previous `README.md` to `ADVANCED.md` file.
|
||||
|
||||
## 1.8
|
||||
|
||||
### The Logical Release
|
||||
|
||||
There is nothing really sexy here, but a lot of changes under the covers to improve reliablity between different SSH client types. A lot of the logic and functions are more consistent and cleaner. In some cultures, fewer bugs and more reliablity are considered features. Much of this will continue through the 1.8.x line.
|
||||
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.
|
||||
|
||||
- SSH/RSYNC connection logic rewritten to be specific to client options between OpenSSH, OpenSSH w/ SSHPASS, and Dropbear.
|
||||
- Key-pair generation functions rewritten to be specific to client options, also now works with no (or at least fewer) user prompts.
|
||||
@ -80,54 +103,64 @@ There is nothing really sexy here, but a lot of changes under the covers to impr
|
||||
- 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.7
|
||||
|
||||
### 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.
|
||||
- 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.
|
||||
|
||||
#### 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.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.
|
||||
```
|
||||
|
||||
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
|
||||
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.3
|
||||
- Cleaning up output of argument listing
|
||||
|
||||
**Deprecation**
|
||||
- Cleaning up output of argument listing
|
||||
- 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.
|
||||
- `./gravity-sync.sh update` performs better error handling.
|
||||
- Slightly less verbose in some places to make up for being more verbose in others.
|
||||
- [DONE] has become [ OK ] in output.
|
||||
- [INFO] header is now yellow all the way across.
|
||||
- Tightens up verbage of status messages.
|
||||
- Tightens up verbiage of status messages.
|
||||
- Fixes `custom.list` not being processed by `./gravity-sync.sh restore` function.
|
||||
- Detects absence of `ssh` client command on host OS (DietPi)
|
||||
- Detects absence of `rsync` client command on host OS (DietPi)
|
||||
@ -135,29 +168,32 @@ Delete the `dev` file and update again to revert back to the stable/master branc
|
||||
- Changelog polarity reversed after heated discussions with marketing team.
|
||||
|
||||
#### 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.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.
|
||||
- Numerous fixes to accommodate 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.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.
|
||||
- Changes some [INFO] messages to [WARN] where appropriate.
|
||||
- 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.
|
||||
- Checks for existence 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.
|
||||
@ -165,33 +201,28 @@ Delete the `dev` file and update again to revert back to the stable/master branc
|
||||
- Validates log export operation.
|
||||
|
||||
## 1.6
|
||||
|
||||
### The Restorative Release
|
||||
|
||||
**Features**
|
||||
- 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.
|
||||
- Adds ability to override verification of 'push', 'restore' or 'config' reset, see `.example` file for details.
|
||||
- Five new Star Trek references.
|
||||
|
||||
**Bug Fixes**
|
||||
- New functions add consistency in status output.
|
||||
|
||||
## 1.5
|
||||
|
||||
### The Automated Release
|
||||
|
||||
**Features**
|
||||
- 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.
|
||||
|
||||
**Bug Fixes**
|
||||
|
||||
- Changes the method for pulling development branch updates via the 'beta' function.
|
||||
- Cleanup of various exit commands.
|
||||
|
||||
## 1.4
|
||||
|
||||
### The Configuration Release
|
||||
|
||||
**Features**
|
||||
- Adds new `./gravity-sync config` feature to simplify deployment!
|
||||
- Adds variables for SSH settings.
|
||||
- Rearranges functions, which impacts nothing.
|
||||
@ -199,97 +230,119 @@ Delete the `dev` file and update again to revert back to the stable/master branc
|
||||
- No new Star Trek references.
|
||||
|
||||
#### 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.3
|
||||
- Bug fixes around not properly utilizing custom SSH keyfile.
|
||||
|
||||
- Bug fixes around not properly utilizing custom SSH key-file.
|
||||
|
||||
## 1.3
|
||||
|
||||
### The Comparison Release
|
||||
|
||||
1.3 should be called 2.0, but I'll resist that temptation -- but there are so many new enhancements!
|
||||
|
||||
**Features**
|
||||
- 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.
|
||||
- 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.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
|
||||
|
||||
- Refactored process to use functions and cleanup process of execution.
|
||||
- Does not look for permission to update when run.
|
||||
- Cleanup and expand comments.
|
||||
|
||||
#### 1.2.1
|
||||
|
||||
- Improved logging functions.
|
||||
|
||||
#### 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.4
|
||||
|
||||
- Changes `~` to `$HOME`.
|
||||
- Fixes bug that prevented sync from working when run via crontab.
|
||||
|
||||
#### 1.2.5
|
||||
|
||||
- Push function now does a backup, on the secondary PH, of the primary database, before pushing.
|
||||
|
||||
## 1.1
|
||||
|
||||
### The Pushy Release
|
||||
|
||||
- Seperated main purpose of script into `pull` argument.
|
||||
- Separated main purpose of script into `pull` argument.
|
||||
- Allow process to reverse back using `push` argument.
|
||||
|
||||
#### 1.1.2
|
||||
|
||||
- First release since move from being just a Gist.
|
||||
- Just relearning how to use GitHub, minor bug fixes.
|
||||
|
||||
#### 1.1.3
|
||||
|
||||
- Now includes example an configuration file.
|
||||
|
||||
#### 1.1.4
|
||||
|
||||
- Added update script.
|
||||
- Added version check.
|
||||
|
||||
#### 1.1.5
|
||||
|
||||
- Added ability to view logs with `./gravity-sync.sh logs`.
|
||||
|
||||
#### 1.1.6
|
||||
|
||||
- Code easier to read with proper tabs.
|
||||
|
||||
## 1.0
|
||||
|
||||
### The Initial Release
|
||||
|
||||
No version control, variables or anything fancy. It only worked if everything was exactly perfect.
|
||||
|
||||
```
|
||||
```bash
|
||||
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'
|
||||
sudo cp /home/pi/gravity-sync/gravity.db /etc/pihole/
|
||||
sudo cp /home/pi/gravity-sync/gravity.db /etc/pihole/
|
||||
echo 'Reloading configuration of HA secondary FTLDNS from new gravity.db'
|
||||
pihole restartdns reload-lists
|
||||
```
|
||||
|
||||
129
README.md
129
README.md
@ -1,37 +1,58 @@
|
||||
# Gravity Sync
|
||||
|
||||
## 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.
|
||||
|
||||
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.
|
||||
|
||||
Gravity Sync will:
|
||||
- Sync 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.
|
||||
|
||||
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.
|
||||
- Sync the Adlist database (allow/block list) configurations stored in `gravity.db` between multiple Pi-hole.
|
||||
- Sync the Local DNS Settings stored in `custom.list` between multiple Pi-hole.
|
||||
- Provide an easy way to keep this happening in the background.
|
||||
|
||||
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 unnecessary.
|
||||
|
||||
### 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.
|
||||
- Keep DHCP settings or device leases synchronized.
|
||||
|
||||
It is suggested that you use an external DHCP server on your network (such as your router) when using multiple Pi-hole.
|
||||
|
||||
### Disclaimer
|
||||
|
||||
Gravity Sync is not developed by or affiliated with the Pi-hole project. This is a community effort that seeks to implement replication, which is currently not a part of the core Pi-hole product. The code has been well tested across multiple user environments but there always is an element of risk involved with running any arbitrary software you find on the Internet.
|
||||
|
||||
## Setup Steps
|
||||
|
||||
1. Read the installation Requirements!
|
||||
2. Install Gravity Sync to your Pi-hole.
|
||||
3. Configure your Gravity Sync installation.
|
||||
4. Test your Gravity Sync install.
|
||||
5. Automate future synchronizations.
|
||||
|
||||
## 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 5.0 (or higher) must already be installed on at least two systems, using any of the Linux distribution that Pi-hole is [certified to run on](https://docs.pi-hole.net/main/prerequesites/#supported-operating-systems).
|
||||
- While it is possible to leverage container/Docker deployments of Pi-hole and Gravity Sync, this configuration is currently not officially supported. Instructions here assume a "native" installation of Pi-hole.
|
||||
- You will need to make sure that you have password-less `SUDO` enabled for the user accounts on both the primary and secondary Pi-hole. 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. These two binaries are what does the heavy lifting between your Pi-hole nodes. In the past, Dropbear was supported but this has proven problematic. If you're using a ultra-lightweight Pi distribution (such as DietPi) that uses Dropbear by default, you will need to convert to OpenSSH as of Gravity Sync version 2.2.
|
||||
|
||||
### 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.
|
||||
|
||||
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 block-lists, device/group management, configuring custom/local network DNS, and changing other list settings.
|
||||
- The secondary Pi-hole(s) are where you will install and configure Gravity Sync.
|
||||
|
||||
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.)
|
||||
Starting with version 2.0, Gravity Sync will attempt to sync the Adlist database and Local DNS Settings on each Pi-hole regardless of where the data was changed. Previous versions only pulled data one way as the standard operation.
|
||||
|
||||
## Installation
|
||||
|
||||
Login to your *secondary* Pi-hole, and run:
|
||||
|
||||
```bash
|
||||
@ -43,35 +64,41 @@ You will now have a folder called `gravity-sync` in your home directory. Everyth
|
||||
Proceed to the Configuration section.
|
||||
|
||||
## Configuration
|
||||
After you install Gravity Sync to your server you will need to create a configuration file called `gravity-sync.conf` in the same folder as the script.
|
||||
|
||||
After you install Gravity Sync to your server you will need to create a configuration file.
|
||||
|
||||
```bash
|
||||
./gravity-sync.sh config
|
||||
```
|
||||
|
||||
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, and testing RSYNC to the primary.
|
||||
- Perform a backup of the existing Pi-hole database.
|
||||
|
||||
After you've completed your configuration, proceed to the Execution phase.
|
||||
The configuration will be saved as `gravity-sync.conf` in the same folder as the script. If you need to make adjustments to your settings in the future, you can edit this file or run the configuration tool to generate a new one.
|
||||
|
||||
After you're pleased your configuration, proceed to the Execution phase.
|
||||
|
||||
## Execution
|
||||
Now, test Gravity Sync. You can run a comparison between primary and secondary databases, which will be non-distruptive, and see if everything has been configured correctly.
|
||||
|
||||
Now, test Gravity Sync. You can run a comparison between primary and secondary databases, which will be non-disruptive, and see if everything has been configured correctly.
|
||||
|
||||
```bash
|
||||
./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 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.
|
||||
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 allow/block list on your primary Pi-hole, such as changing a description field or disabling a allow list item, and then running `./gravity-sync.sh compare` again to validate your installation is working correctly.
|
||||
|
||||
### The Sync
|
||||
|
||||
The default command for Gravity Sync is simple.
|
||||
|
||||
```
|
||||
```bash
|
||||
./gravity-sync.sh
|
||||
```
|
||||
|
||||
@ -83,32 +110,14 @@ Gravity Sync will perform some checks to help insure success and then stop befor
|
||||
|
||||
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.
|
||||
|
||||
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` or `.push`) for future use.
|
||||
If the execution completes, you will now have a synchronized copy of your running `gravity.db` and `custom.list` on the both Pi-hole after creating a time-stamped copy of the running files (with `.backup` appended) in the `backup` subfolder located with your script, on the secondary Pi-hole.
|
||||
|
||||
Finally, a file called `gravity-sync.log` will be created in the `gravity-sync` folder along side the script with the date the script was last executed appended to the bottom.
|
||||
|
||||
You can check for successful pull attempts by running: `./gravity-sync.sh logs`
|
||||
|
||||
## 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.
|
||||
|
||||
```
|
||||
./gravity-sync.sh version
|
||||
```
|
||||
|
||||
You can then run the built-in updater to get the latest version of all the files. Both the `version` and `update` commands reach out to GitHub, so outbound access to github.com is required.
|
||||
|
||||
```bash
|
||||
./gravity-sync.sh update
|
||||
```
|
||||
|
||||
Your copy of the `gravity-sync.conf` file, logs and backups should not be be impacted by this update, as they are specifically ignored. The main goal of Gravity Sync is to be simple to execute and maintain, so any additional requirements should also be called out when it's executed. After updating, be sure to manually run a `./gravity-sync.sh compare` or `./gravity-sync.sh pull` to validate things are still working as expected.
|
||||
|
||||
You can run a `./gravity-sync.sh config` at any time to generate a new configuration file if you're concerned that you're missing something.
|
||||
|
||||
- If the update script fails, make sure you did your original deployment via `git clone` and not a manual install. Refer to [ADVANCED.md](https://github.com/vmstan/gravity-sync/blob/master/ADVANCED.md) for more details.
|
||||
|
||||
## Automation
|
||||
|
||||
Automation of sync is accomplished by adding an execution of the script to the user's crontab file. As Gravity Sync won't make any changes if it doesn't detect a difference to sync, then the impact should be minor to your systems.
|
||||
|
||||
```bash
|
||||
@ -117,7 +126,7 @@ Automation of sync is accomplished by adding an execution of the script to the u
|
||||
|
||||
Select the frequency per hour (in minutes) that you'd like to sync and that's it.
|
||||
|
||||
Now, make another small adjustment to your primary settings and wait until annointed time to see if your changes have been synchronized. If so, profit! If not, start from the beginning. From this point forward any blocklist changes you make to the primary will reflect on the secondary within the frequency you select.
|
||||
Now, make another small adjustment to your primary settings and wait until anointed time to see if your changes have been synchronized. If so, profit! If not, start from the beginning. From this point forward any block list changes you make to the primary will reflect on the secondary within the frequency you select.
|
||||
|
||||
If you'd like to see the log of what was run the last crontab, you can view that output by running:
|
||||
|
||||
@ -128,7 +137,53 @@ If you'd like to see the log of what was run the last crontab, you can view that
|
||||
Keep in mind if your cron task has never run, you will not see any valid output from this command.
|
||||
|
||||
### Adjusting Automation
|
||||
|
||||
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.
|
||||
|
||||
## Updates
|
||||
|
||||
If you'd like to know what version of the script you have running, check the built in version checker. It will notify you if there are updates available.
|
||||
|
||||
```bash
|
||||
./gravity-sync.sh version
|
||||
```
|
||||
|
||||
You can then run the built-in updater to get the latest version of all the files. Both the `version` and `update` commands reach out to GitHub, so outbound access to GitHub.com is required.
|
||||
|
||||
```bash
|
||||
./gravity-sync.sh update
|
||||
```
|
||||
|
||||
Your copy of the `gravity-sync.conf` file, logs and backups should not be be impacted by this update, as they are specifically ignored. The main goal of Gravity Sync is to be simple to execute and maintain, so any additional requirements should also be called out when it's executed. After updating, be sure to manually run a `./gravity-sync.sh compare` or `./gravity-sync.sh pull` to validate things are still working as expected.
|
||||
|
||||
You can run a `./gravity-sync.sh config` at any time to generate a new configuration file if you're concerned that you're missing something.
|
||||
|
||||
- If the update script fails, make sure you did your original deployment via `git clone` and not a manual install. Refer to [ADVANCED.md](https://github.com/vmstan/gravity-sync/blob/master/ADVANCED.md) for more details.
|
||||
|
||||
## Starting Over
|
||||
|
||||
Starting in version 2.2, Gravity Sync has a built in tool to purge everything custom about itself from the system.
|
||||
|
||||
```bash
|
||||
./gravity-sync.sh purge
|
||||
```
|
||||
|
||||
This will remove:
|
||||
|
||||
- All backups files.
|
||||
- Your `gravity-sync.conf` file.
|
||||
- All cronjob/automation tasks.
|
||||
- All job history/logs.
|
||||
- The SSH id_rsa keys associated with Gravity Sync.
|
||||
|
||||
This function 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.
|
||||
|
||||
**This will not impact any of the Pi-hole binaries, configuration files, directories, services, etc.** Your Adlist database and Local Custom DNS records will no longer sync, but they will be in the status they were when Gravity Sync was removed.
|
||||
|
||||
### Uninstalling
|
||||
|
||||
If you are completely uninstalling Gravity Sync, the last step would be to remove the `gravity-sync` folder from your user's home directory.
|
||||
|
||||
## Advanced Installation
|
||||
|
||||
Please review the [Advanced Installation](https://github.com/vmstan/gravity-sync/blob/master/ADVANCED.md) guide for more assistance.
|
||||
|
||||
@ -18,7 +18,7 @@ REMOTE_PASS=''
|
||||
|
||||
# ADVANCED SETTINGS ######################
|
||||
|
||||
# Uncomment and set for auxillary control
|
||||
# Uncomment and set for auxiliary control
|
||||
# Overrides gravity-sync.sh defaults
|
||||
# See ADVANCED.md for more information
|
||||
|
||||
|
||||
222
gravity-sync.sh
222
gravity-sync.sh
@ -3,7 +3,7 @@ SCRIPT_START=$SECONDS
|
||||
|
||||
# GRAVITY SYNC BY VMSTAN #####################
|
||||
PROGRAM='Gravity Sync'
|
||||
VERSION='2.1.7'
|
||||
VERSION='2.2.0'
|
||||
|
||||
# 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
|
||||
@ -111,8 +111,6 @@ function show_target {
|
||||
# GS Update Functions
|
||||
## Master Branch
|
||||
function update_gs {
|
||||
TASKTYPE='UPDATE'
|
||||
|
||||
if [ -f "$HOME/${LOCAL_FOLDR}/dev" ]
|
||||
then
|
||||
BRANCH='development'
|
||||
@ -144,9 +142,7 @@ function update_gs {
|
||||
echo_stat
|
||||
git reset --hard origin/${BRANCH} >/dev/null 2>&1
|
||||
error_validate
|
||||
fi
|
||||
|
||||
exit_withchange
|
||||
fi
|
||||
}
|
||||
|
||||
# Gravity Core Functions
|
||||
@ -155,13 +151,6 @@ function pull_gs_grav {
|
||||
|
||||
backup_local_gravity
|
||||
backup_remote_gravity
|
||||
|
||||
# MESSAGE="Backing Up ${GRAVITY_FI} on $HOSTNAME"
|
||||
# echo_stat
|
||||
# cp ${PIHOLE_DIR}/${GRAVITY_FI} $HOME/${LOCAL_FOLDR}/${BACKUP_FOLD}/${GRAVITY_FI}.backup >/dev/null 2>&1
|
||||
# error_validate
|
||||
|
||||
|
||||
|
||||
MESSAGE="Pulling ${GRAVITY_FI} from ${REMOTE_HOST}"
|
||||
echo_stat
|
||||
@ -934,10 +923,10 @@ function create_sshcmd {
|
||||
timeout --preserve-status ${CMD_TIMEOUT} ${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -o StrictHostKeyChecking=no ${REMOTE_USER}@${REMOTE_HOST} "${CMD_REQUESTED}"
|
||||
error_validate
|
||||
fi
|
||||
elif hash dbclient 2>/dev/null
|
||||
then
|
||||
timeout --preserve-status ${CMD_TIMEOUT} ${SSH_CMD} -p ${SSH_PORT} -i $HOME/${SSH_PKIF} ${REMOTE_USER}@${REMOTE_HOST} "${CMD_REQUESTED}"
|
||||
error_validate
|
||||
# elif hash dbclient 2>/dev/null
|
||||
# then
|
||||
# timeout --preserve-status ${CMD_TIMEOUT} ${SSH_CMD} -p ${SSH_PORT} -i $HOME/${SSH_PKIF} ${REMOTE_USER}@${REMOTE_HOST} "${CMD_REQUESTED}"
|
||||
# error_validate
|
||||
fi
|
||||
}
|
||||
|
||||
@ -953,10 +942,10 @@ function create_rsynccmd {
|
||||
rsync --rsync-path="${RSYNC_REPATH}" -e "${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${RSYNC_SOURCE} ${RSYNC_TARGET} >/dev/null 2>&1
|
||||
error_validate
|
||||
fi
|
||||
elif hash dbclient 2>/dev/null
|
||||
then
|
||||
rsync --rsync-path="${RSYNC_REPATH}" -e "${SSH_CMD} -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${RSYNC_SOURCE} ${RSYNC_TARGET} >/dev/null 2>&1
|
||||
error_validate
|
||||
# elif hash dbclient 2>/dev/null
|
||||
# then
|
||||
# rsync --rsync-path="${RSYNC_REPATH}" -e "${SSH_CMD} -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${RSYNC_SOURCE} ${RSYNC_TARGET} >/dev/null 2>&1
|
||||
# error_validate
|
||||
fi
|
||||
}
|
||||
|
||||
@ -972,23 +961,25 @@ function detect_sshkeygen {
|
||||
echo_fail
|
||||
MESSAGE="SSH-KEYGEN is Required"
|
||||
echo_info
|
||||
MESSAGE="Attempting to Compensate"
|
||||
echo_warn
|
||||
|
||||
exit_nochange
|
||||
# MESSAGE="Attempting to Compensate"
|
||||
# echo_warn
|
||||
|
||||
if hash dropbearkey >/dev/null 2>&1
|
||||
then
|
||||
MESSAGE="Using DROPBEARKEY Instead"
|
||||
echo_info
|
||||
if [ ! -d $HOME/.ssh ]
|
||||
then
|
||||
mkdir $HOME/.ssh >/dev/null 2>&1
|
||||
fi
|
||||
KEYGEN_COMMAND="dropbearkey -t rsa -f"
|
||||
else
|
||||
MESSAGE="No Alternatives Located"
|
||||
echo_info
|
||||
exit_nochange
|
||||
fi
|
||||
# if hash dropbearkey >/dev/null 2>&1
|
||||
# then
|
||||
# MESSAGE="Using DROPBEARKEY Instead"
|
||||
# echo_info
|
||||
# if [ ! -d $HOME/.ssh ]
|
||||
# then
|
||||
# mkdir $HOME/.ssh >/dev/null 2>&1
|
||||
# fi
|
||||
# KEYGEN_COMMAND="dropbearkey -t rsa -f"
|
||||
# else
|
||||
# MESSAGE="No Alternatives Located"
|
||||
# echo_info
|
||||
# exit_nochange
|
||||
# fi
|
||||
fi
|
||||
}
|
||||
|
||||
@ -1008,17 +999,17 @@ function generate_sshkey {
|
||||
ssh-keygen -q -P "" -t rsa -f $HOME/${SSH_PKIF} >/dev/null 2>&1
|
||||
error_validate
|
||||
|
||||
elif hash dropbearkey >/dev/null 2>&1
|
||||
then
|
||||
MESSAGE="Generating ~/${SSH_PKIF} (DROPBEARKEY)"
|
||||
echo_stat
|
||||
if [ ! -d $HOME/.ssh ]
|
||||
then
|
||||
mkdir $HOME/.ssh >/dev/null 2>&1
|
||||
fi
|
||||
|
||||
dropbearkey -t rsa -f $HOME/${SSH_PKIF} >/dev/null 2>&1
|
||||
error_validate
|
||||
# elif hash dropbearkey >/dev/null 2>&1
|
||||
# then
|
||||
# MESSAGE="Generating ~/${SSH_PKIF} (DROPBEARKEY)"
|
||||
# echo_stat
|
||||
# if [ ! -d $HOME/.ssh ]
|
||||
# then
|
||||
# mkdir $HOME/.ssh >/dev/null 2>&1
|
||||
# fi
|
||||
#
|
||||
# dropbearkey -t rsa -f $HOME/${SSH_PKIF} >/dev/null 2>&1
|
||||
# error_validate
|
||||
else
|
||||
MESSAGE="No SSH Key Generator Located"
|
||||
echo_warn
|
||||
@ -1039,14 +1030,14 @@ function export_sshkey {
|
||||
#MESSAGE="Enter ${REMOTE_USER}@${REMOTE_HOST} Password Below"
|
||||
#echo -e "${NEED} ${MESSAGE}"
|
||||
|
||||
if hash ssh-copy-id 2>/dev/null
|
||||
then
|
||||
# if hash ssh-copy-id 2>/dev/null
|
||||
# then
|
||||
ssh-copy-id -f -p ${SSH_PORT} -i $HOME/${SSH_PKIF}.pub ${REMOTE_USER}@${REMOTE_HOST}
|
||||
elif hash dbclient 2>/dev/null
|
||||
then
|
||||
dropbearkey -y -f $HOME/${SSH_PKIF} | grep "^ssh-rsa " > $HOME/${SSH_PKIF}.pub
|
||||
cat $HOME/${SSH_PKIF}.pub | dbclient -p ${SSH_PORT} ${REMOTE_USER}@${REMOTE_HOST} 'cat - >> .ssh/authorized_keys'
|
||||
fi
|
||||
# elif hash dbclient 2>/dev/null
|
||||
# then
|
||||
# dropbearkey -y -f $HOME/${SSH_PKIF} | grep "^ssh-rsa " > $HOME/${SSH_PKIF}.pub
|
||||
# cat $HOME/${SSH_PKIF}.pub | dbclient -p ${SSH_PORT} ${REMOTE_USER}@${REMOTE_HOST} 'cat - >> .ssh/authorized_keys'
|
||||
# fi
|
||||
else
|
||||
MESSAGE="Error Registering Key-Pair"
|
||||
echo_warn
|
||||
@ -1094,8 +1085,11 @@ function detect_ssh {
|
||||
elif hash dbclient 2>/dev/null
|
||||
then
|
||||
MESSAGE="${MESSAGE} (Dropbear)"
|
||||
echo_good
|
||||
SSH_CMD='dbclient'
|
||||
echo_fail
|
||||
|
||||
MESSAGE="Dropbear not supported in GS ${VERSION}"
|
||||
echo_info
|
||||
exit_nochange
|
||||
else
|
||||
echo_fail
|
||||
|
||||
@ -1150,14 +1144,18 @@ function detect_remotersync {
|
||||
RSYNC_TARGET="$HOME/${LOCAL_FOLDR}/gs.test"
|
||||
create_rsynccmd
|
||||
|
||||
MESSAGE="Cleaning Up Test Files"
|
||||
MESSAGE="Cleaning Up Local Test File"
|
||||
echo_stat
|
||||
|
||||
rm $HOME/${LOCAL_FOLDR}/gs.test
|
||||
rm $HOME/${LOCAL_FOLDR}/gs.test
|
||||
error_validate
|
||||
|
||||
CMD_TIMEOUT='15'
|
||||
CMD_REQUESTED="rm ~/gs.test"
|
||||
create_sshcmd
|
||||
MESSAGE="Cleaning Up Remote Test File"
|
||||
echo_stat
|
||||
|
||||
CMD_TIMEOUT='15'
|
||||
CMD_REQUESTED="rm ~/gs.test"
|
||||
create_sshcmd
|
||||
}
|
||||
|
||||
## Error Validation
|
||||
@ -1493,10 +1491,6 @@ function config_generate {
|
||||
validate_os_sshpass
|
||||
|
||||
detect_remotersync
|
||||
|
||||
task_backup
|
||||
|
||||
exit_withchange
|
||||
}
|
||||
|
||||
## Delete Existing Configuration
|
||||
@ -1606,8 +1600,13 @@ function show_version {
|
||||
function dbclient_warning {
|
||||
if hash dbclient 2>/dev/null
|
||||
then
|
||||
MESSAGE="Dropbear support has been deprecated - please convert to OpenSSH"
|
||||
echo_warn
|
||||
if hash ssh 2>/dev/null
|
||||
then
|
||||
NOEMPTYBASHIF="1"
|
||||
else
|
||||
MESSAGE="Dropbear support has been deprecated - please convert to OpenSSH"
|
||||
echo_warn
|
||||
fi
|
||||
fi
|
||||
}
|
||||
|
||||
@ -1729,6 +1728,13 @@ function task_configure {
|
||||
|
||||
config_generate
|
||||
fi
|
||||
|
||||
backup_settime
|
||||
backup_local_gravity
|
||||
backup_local_custom
|
||||
backup_cleanup
|
||||
|
||||
exit_withchange
|
||||
}
|
||||
|
||||
## Devmode Task
|
||||
@ -1812,6 +1818,8 @@ function task_update {
|
||||
dbclient_warning
|
||||
|
||||
update_gs
|
||||
|
||||
exit_withchange
|
||||
}
|
||||
|
||||
## Version Task
|
||||
@ -1863,6 +1871,76 @@ function task_invalid {
|
||||
list_gs_arguments
|
||||
}
|
||||
|
||||
## Purge Task
|
||||
function task_purge {
|
||||
TASKTYPE="THE-PURGE"
|
||||
MESSAGE="${MESSAGE}: ${TASKTYPE} Requested"
|
||||
echo_good
|
||||
|
||||
MESSAGE="THIS WILL RESET YOUR ENTIRE GRAVITY SYNC INSTALLATION"
|
||||
echo_warn
|
||||
MESSAGE="This will remove:"
|
||||
echo_warn
|
||||
MESSAGE="- All backups files."
|
||||
echo_warn
|
||||
MESSAGE="- Your ${CONFIG_FILE} file."
|
||||
echo_warn
|
||||
|
||||
if [ -f "$HOME/${LOCAL_FOLDR}/dev" ]
|
||||
then
|
||||
MESSAGE="- Your development branch updater."
|
||||
elif [ -f "$HOME/${LOCAL_FOLDR}/beta" ]
|
||||
then
|
||||
MESSAGE="- Your beta branch updater."
|
||||
fi
|
||||
echo_warn
|
||||
|
||||
MESSAGE="- All cronjob/automation tasks."
|
||||
echo_warn
|
||||
MESSAGE="- All job history/logs."
|
||||
echo_warn
|
||||
MESSAGE="- Associated SSH id_rsa keys."
|
||||
echo_warn
|
||||
MESSAGE="This function cannot be undone!"
|
||||
echo_warn
|
||||
|
||||
MESSAGE="YOU WILL NEED TO REBUILD GRAVITY SYNC AFTER EXECUTION"
|
||||
echo_warn
|
||||
|
||||
MESSAGE="Pi-hole binaries, configuration and services ARE NOT impacted!"
|
||||
echo_info
|
||||
MESSAGE="Your device will continue to resolve and block DNS requests,"
|
||||
echo_info
|
||||
MESSAGE="but your ${GRAVITY_FI} and ${CUSTOM_DNS} WILL NOT sync anymore,"
|
||||
echo_info
|
||||
MESSAGE="until you reconfigure Gravity Sync on this device."
|
||||
echo_info
|
||||
|
||||
intent_validate
|
||||
|
||||
MESSAGE="Cleaning Gravity Sync Directory"
|
||||
echo_stat
|
||||
|
||||
git clean -f -X -d >/dev/null 2>&1
|
||||
error_validate
|
||||
|
||||
clear_cron
|
||||
|
||||
MESSAGE="Deleting SSH Key-files"
|
||||
echo_stat
|
||||
|
||||
rm -f $HOME/${SSH_PKIF} >/dev/null 2>&1
|
||||
rm -f $HOME/${SSH_PKIF}.pub >/dev/null 2>&1
|
||||
error_validate
|
||||
|
||||
MESSAGE="Realigning Dilithium Matrix"
|
||||
echo_fail
|
||||
|
||||
sleep 1
|
||||
|
||||
update_gs
|
||||
}
|
||||
|
||||
## Backup Task
|
||||
function task_backup {
|
||||
TASKTYPE='BACKUP'
|
||||
@ -1908,7 +1986,7 @@ function backup_remote_gravity {
|
||||
MESSAGE="Performing Backup of Remote ${GRAVITY_FI}"
|
||||
echo_stat
|
||||
|
||||
CMD_TIMEOUT='15'
|
||||
CMD_TIMEOUT='60'
|
||||
CMD_REQUESTED="sudo sqlite3 ${PIHOLE_DIR}/${GRAVITY_FI} \".backup '${PIHOLE_DIR}/${GRAVITY_FI}.backup'\""
|
||||
create_sshcmd
|
||||
}
|
||||
@ -2150,6 +2228,10 @@ case $# in
|
||||
task_backup
|
||||
;;
|
||||
|
||||
purge)
|
||||
task_purge
|
||||
;;
|
||||
|
||||
*)
|
||||
task_invalid
|
||||
;;
|
||||
@ -2177,4 +2259,4 @@ case $# in
|
||||
*)
|
||||
task_invalid
|
||||
;;
|
||||
esac
|
||||
esac
|
||||
|
||||
Loading…
Reference in New Issue
Block a user