Mirrored_Repos/gravity-sync
1
0
Fork 0
mirror of https://github.com/vmstan/gravity-sync.git synced 2024-08-30 18:22:11 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #31 from vmstan:development

Browse Source 
1.7.6
This commit is contained in:
Michael Stanclift 2020-06-01 15:53:28 -05:00 committed by GitHub
commit 176604a4f8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 130 additions and 70 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
ADVANCED.md
View File

@ -11,8 +11,8 @@ Download the latest release from [GitHub](https://github.com/vmstan/gravity-sync
```bash
cd ~
wget https://github.com/vmstan/gravity-sync/archive/v1.7.5.zip
unzip v1.7.5.zip -d gravity-sync
wget https://github.com/vmstan/gravity-sync/archive/v1.7.6.zip
unzip v1.7.6.zip -d gravity-sync
cd gravity-sync
```
@ -76,53 +76,61 @@ Save. Keep calm, carry on.
### 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.
#### SSH_PORT=''
#### `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=''
#### `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.
Default setting for Gravity Sync is `.ssh/id_rsa`
#### LOG_PATH=''
#### `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 for Gravity Sync is `$HOME/${LOCAL_FOLDR}`
#### SYNCING_LOG=''
#### `SYNCING_LOG=''`
Gravity Sync will write a timestamp for any completed 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 `update` operations.
Default setting for Gravity Sync is `gravity-sync.log`
#### CRONJOB_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 `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.
Default setting for Gravity Sync is `gravity-sync.cron`
#### VERIFY_PASS=''
#### `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.
Default setting in Gravity Sync is 0, change to 1 to bypass this check.
#### SKIP_CUSTOM=''
#### `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.
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=''
#### `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.
## 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
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.
@ -141,6 +149,16 @@ Delete the `dev` file and update again to revert back to the stable/master branc
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.
```
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.
@ -152,18 +170,7 @@ crontab -e
```
## Troubleshooting
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
chmod +x gravity-sync.sh
```
If you are getting errors about missing SSH or RSYNC when you run your first `compare` or `pull` operation, and you're using an ultra-lightweight distro like DietPi, make sure they are installed on the base operating system.
- If your script prompts for a password on the remote system, make sure that your user account is setup not to require passwords in the sudoers file.
- If you use a non-standard SSH port to connect to your primary Pi-hole, you can add `SSH_PORT='123'` to the bottom of your `gravity-sync.conf` file. (Subsitute 123 for your non-standard port.) This will overwrite the `SSH_PORT=22` at the top of the script as it is imported later in the execution.
- If you'd like to know what version of the script you have running by running `./gravity-sync.sh version`
- If the update script fails, make sure you did your original deployment via `git clone` and not a manual install.
- If it doesn't kick off, you can manually execute a `git pull` while in the `gravity-sync` directory.
If all else fails, delete the entire `gravity-sync` folder from your system and re-deploy. This will have no impact on your replicated databases.

12
CHANGELOG.md
View File

@ -11,6 +11,16 @@
**Known Issues**
- No new Star Trek references.
#### 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.
- 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.5
- No code changes!
- Primary README now only reflect "The Easy Way" to install and configure Gravity Sync
@ -27,7 +37,7 @@
- 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)
- Detects absence of `ssh-keygen` utility on host OS and will use dropbearkey as an alternative (DietPi)
- Detects absence of `ssh-keygen` utility on host OS and will use `dropbearkey` as an alternative (DietPi)
- Changelog polarity reversed after heated discussions with marketing team.
#### 1.7.3

14
README.md
View File

@ -16,7 +16,7 @@ Gravity Sync **requires** Pi-hole 5.0 or higher be already installed on your ser
- Gravity Sync is regularly tested during development with on any of the Linux distrobutions that Pi-hole is [certified to run on](https://docs.pi-hole.net/main/prerequesites/#supported-operating-systems). As Gravity Sync is just an (admittedly) long bash script, it will likely work on other Linux distributions that have the the necessary components.
- Gravity Sync uses the `SUDO` command to elevate permissions for itself, on both Pi-hole systems, during execution. 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/).
- Gravity Sync has not been tested with Docker deployments of Pi-hole, and is not expected to work there without major modifications. You will need Pi-hole setup with a "traditional" install directly in the base operating system. There are likely other methods of sharing the `gravity.db` file between multiple Docker instances that are better suited to a container environment.
- Gravity Sync leverages SSH and RSYNC to do the leavy lifting between your Pi-hole nodes. If you're using a ultra-lightweight Pi distrbution (such as DietPi) make sure you have OpenSSH setup as your SSH client/server and not an alternative (such as Dropbear) which may act differently than OpenSSH.
- Gravity Sync leverages SSH and RSYNC to do 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 Architecture
You will need to designate one Pi-Hole as primary and at least one as secondary. The primary Pi-hole is where you'll make all your configuration changes through the Web UI, doing things such as; manual whitelisting, 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.
@ -86,6 +86,8 @@ Before executing, this will make a copy of the remote database under `backup/gra
This function purposefuly 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.
@ -98,7 +100,13 @@ This will copy your last `gravity.db.backup` and `custom.list.backup` to the ru
This function purposefuly asks for user interaction to avoid being accidentally automated.
## Updates
You can run the built-in updater to get the latest version of all the files.
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
@ -108,6 +116,8 @@ Your copy of the `gravity-sync.conf` file, logs and backups should not be be imp
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.

2
VERSION
View File

@ -1 +1 @@
1.7.5
1.7.6

119
gravity-sync.sh
View File

@ -2,7 +2,7 @@
# GRAVITY SYNC BY VMSTAN #####################
PROGRAM='Gravity Sync'
VERSION='1.7.5'
VERSION='1.7.6'
# 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
@ -142,7 +142,7 @@ function pull_gs {
MESSAGE="Pulling ${GRAVITY_FI} from ${REMOTE_HOST}"
echo_stat
${SSHPASSWORD} rsync -e "ssh -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST}:${PIHOLE_DIR}/${GRAVITY_FI} $HOME/${LOCAL_FOLDR}/${BACKUP_FOLD}/${GRAVITY_FI}.pull >/dev/null 2>&1
${SSHPASSWORD} rsync -e "${SSH_CMD} -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST}:${PIHOLE_DIR}/${GRAVITY_FI} $HOME/${LOCAL_FOLDR}/${BACKUP_FOLD}/${GRAVITY_FI}.pull >/dev/null 2>&1
error_validate
MESSAGE="Replacing ${GRAVITY_FI} on $HOSTNAME"
@ -192,14 +192,17 @@ function pull_gs {
then
if [ "$REMOTE_CUSTOM_DNS" == "1" ]
then
if [ -f ${PIHOLE_DIR}/${CUSTOM_DNS} ]
then
MESSAGE="Backing Up ${CUSTOM_DNS} on $HOSTNAME"
echo_stat
cp ${PIHOLE_DIR}/${CUSTOM_DNS} $HOME/${LOCAL_FOLDR}/${BACKUP_FOLD}/${CUSTOM_DNS}.backup >/dev/null 2>&1
error_validate
fi
MESSAGE="Pulling ${CUSTOM_DNS} from ${REMOTE_HOST}"
echo_stat
${SSHPASSWORD} rsync -e "ssh -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST}:${PIHOLE_DIR}/${CUSTOM_DNS} $HOME/${LOCAL_FOLDR}/${BACKUP_FOLD}/${CUSTOM_DNS}.pull >/dev/null 2>&1
${SSHPASSWORD} rsync -e "${SSH_CMD} -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST}:${PIHOLE_DIR}/${CUSTOM_DNS} $HOME/${LOCAL_FOLDR}/${BACKUP_FOLD}/${CUSTOM_DNS}.pull >/dev/null 2>&1
error_validate
MESSAGE="Replacing ${CUSTOM_DNS} on $HOSTNAME"
@ -247,7 +250,7 @@ function pull_gs {
fi
fi
MESSAGE="Inverting Tachyon Pulse"
MESSAGE="Isolating Regeneration Pathways"
echo_info
sleep 1
@ -273,22 +276,22 @@ function push_gs {
MESSAGE="Backing Up ${GRAVITY_FI} from ${REMOTE_HOST}"
echo_stat
${SSHPASSWORD} rsync -e "ssh -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST}:${PIHOLE_DIR}/${GRAVITY_FI} $HOME/${LOCAL_FOLDR}/${BACKUP_FOLD}/${GRAVITY_FI}.push >/dev/null 2>&1
${SSHPASSWORD} rsync -e "${SSH_CMD} -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST}:${PIHOLE_DIR}/${GRAVITY_FI} $HOME/${LOCAL_FOLDR}/${BACKUP_FOLD}/${GRAVITY_FI}.push >/dev/null 2>&1
error_validate
MESSAGE="Pushing ${GRAVITY_FI} to ${REMOTE_HOST}"
echo_stat
${SSHPASSWORD} rsync --rsync-path="sudo rsync" -e "ssh -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${PIHOLE_DIR}/${GRAVITY_FI} ${REMOTE_USER}@${REMOTE_HOST}:${PIHOLE_DIR}/${GRAVITY_FI} >/dev/null 2>&1
${SSHPASSWORD} rsync --rsync-path="sudo rsync" -e "${SSH_CMD} -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${PIHOLE_DIR}/${GRAVITY_FI} ${REMOTE_USER}@${REMOTE_HOST}:${PIHOLE_DIR}/${GRAVITY_FI} >/dev/null 2>&1
error_validate
MESSAGE="Setting Permissions on ${GRAVITY_FI}"
echo_stat
${SSHPASSWORD} ssh -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "sudo chmod 664 ${PIHOLE_DIR}/${GRAVITY_FI}" >/dev/null 2>&1
${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "sudo chmod 664 ${PIHOLE_DIR}/${GRAVITY_FI}" >/dev/null 2>&1
error_validate
MESSAGE="Setting Ownership on ${GRAVITY_FI}"
echo_stat
${SSHPASSWORD} ssh -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "sudo chown pihole:pihole ${PIHOLE_DIR}/${GRAVITY_FI}" >/dev/null 2>&1
${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "sudo chown pihole:pihole ${PIHOLE_DIR}/${GRAVITY_FI}" >/dev/null 2>&1
error_validate
if [ "$SKIP_CUSTOM" != '1' ]
@ -297,38 +300,38 @@ function push_gs {
then
MESSAGE="Backing Up ${CUSTOM_DNS} from ${REMOTE_HOST}"
echo_stat
${SSHPASSWORD} rsync -e "ssh -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST}:${PIHOLE_DIR}/${CUSTOM_DNS} $HOME/${LOCAL_FOLDR}/${BACKUP_FOLD}/${CUSTOM_DNS}.push >/dev/null 2>&1
${SSHPASSWORD} rsync -e "${SSH_CMD} -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST}:${PIHOLE_DIR}/${CUSTOM_DNS} $HOME/${LOCAL_FOLDR}/${BACKUP_FOLD}/${CUSTOM_DNS}.push >/dev/null 2>&1
error_validate
MESSAGE="Pushing ${CUSTOM_DNS} to ${REMOTE_HOST}"
echo_stat
${SSHPASSWORD} rsync --rsync-path="sudo rsync" -e "ssh -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${PIHOLE_DIR}/${CUSTOM_DNS} ${REMOTE_USER}@${REMOTE_HOST}:${PIHOLE_DIR}/${CUSTOM_DNS} >/dev/null 2>&1
${SSHPASSWORD} rsync --rsync-path="sudo rsync" -e "${SSH_CMD} -p ${SSH_PORT} -i $HOME/${SSH_PKIF}" ${PIHOLE_DIR}/${CUSTOM_DNS} ${REMOTE_USER}@${REMOTE_HOST}:${PIHOLE_DIR}/${CUSTOM_DNS} >/dev/null 2>&1
error_validate
MESSAGE="Setting Permissions on ${CUSTOM_DNS}"
echo_stat
${SSHPASSWORD} ssh -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "sudo chmod 644 ${PIHOLE_DIR}/${CUSTOM_DNS}" >/dev/null 2>&1
${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "sudo chmod 644 ${PIHOLE_DIR}/${CUSTOM_DNS}" >/dev/null 2>&1
error_validate
MESSAGE="Setting Ownership on ${CUSTOM_DNS}"
echo_stat
${SSHPASSWORD} ssh -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "sudo chown root:root ${PIHOLE_DIR}/${CUSTOM_DNS}" >/dev/null 2>&1
${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "sudo chown root:root ${PIHOLE_DIR}/${CUSTOM_DNS}" >/dev/null 2>&1
error_validate
fi
fi
MESSAGE="Contacting Borg Collective"
MESSAGE="Inverting Tachyon Pulse"
echo_info
sleep 1
MESSAGE="Updating FTLDNS Configuration"
echo_stat
${SSHPASSWORD} ssh -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "${PIHOLE_BIN} restartdns reloadlists" >/dev/null 2>&1
${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "${PIHOLE_BIN} restartdns reloadlists" >/dev/null 2>&1
error_validate
MESSAGE="Reloading FTLDNS Services"
echo_stat
${SSHPASSWORD} ssh -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "${PIHOLE_BIN} restartdns" >/dev/null 2>&1
${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "${PIHOLE_BIN} restartdns" >/dev/null 2>&1
error_validate
logs_export
@ -589,8 +592,16 @@ function validate_os_sshpass {
MESSAGE="Validating SSH Connection to ${REMOTE_HOST}"
echo_stat
timeout 5 ${SSHPASSWORD} ssh -p ${SSH_PORT} -i '$HOME/${SSH_PKIF}' -o StrictHostKeyChecking=no ${REMOTE_USER}@${REMOTE_HOST} 'exit' >/dev/null 2>&1
if hash ssh 2>/dev/null
then
timeout 5 ${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" -o StrictHostKeyChecking=no ${REMOTE_USER}@${REMOTE_HOST} 'exit' >/dev/null 2>&1
error_validate
elif hash dbclient 2>/dev/null
then
# if [ "$SSH_CMD" = "dbclient" ]; then echo ''; fi;
timeout 5 ${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} 'exit' >/dev/null 2>&1
error_validate
fi
}
@ -613,8 +624,13 @@ function detect_sshkeygen {
then
MESSAGE="Using DROPBEARKEY Instead"
echo_info
KEYGEN_COMMAND="dropbearkey -t rsa -f"
if [ -d $HOME/.ssh ]
then
KEYGEN_COMMAND="dropbearkey -t rsa -f"
else
mkdir $HOME/.ssh >/dev/null 2>&1
KEYGEN_COMMAND="dropbearkey -t rsa -f $HOME/${SSH_PKIF}"
fi
else
MESSAGE="No Alternatives Located"
echo_info
@ -627,6 +643,7 @@ function detect_sshkeygen {
function distro_check {
if hash apt-get 2>/dev/null
then
PKG_MANAGER="apt-get"
PKG_INSTALL="sudo apt-get --yes --no-install-recommends --quiet install"
elif hash rpm 2>/dev/null
then
@ -651,26 +668,32 @@ function distro_check {
## Detect SSH & RSYNC
function detect_ssh {
MESSAGE="Validating SSH Client on $HOSTNAME"
MESSAGE="Validating SSH on $HOSTNAME"
echo_stat
if hash ssh 2>/dev/null
then
MESSAGE="Validating SSH on $HOSTNAME (OpenSSH)"
echo_good
SSH_CMD='ssh'
elif hash dbclient 2>/dev/null
then
MESSAGE="Validating SSH on $HOSTNAME (Dropbear)"
echo_good
SSH_CMD='dbclient'
else
echo_fail
MESSAGE="Attempting to Compensate"
echo_info
distro_check
MESSAGE="Installing SSH on $HOSTNAME"
MESSAGE="Installing SSH Client with ${PKG_MANAGER}"
echo_stat
${PKG_INSTALL} ssh >/dev/null 2>&1
${PKG_INSTALL} ssh-client >/dev/null 2>&1
error_validate
fi
MESSAGE="Validating RSYNC Client on $HOSTNAME"
MESSAGE="Validating RSYNC on $HOSTNAME"
echo_stat
if hash rsync 2>/dev/null
@ -684,6 +707,9 @@ function detect_ssh {
distro_check
MESSAGE="Attempting to Compensate"
echo_info
MESSAGE="Installing RSYNC with ${PKG_MANAGER}"
echo_stat
${PKG_INSTALL} rsync >/dev/null 2>&1
error_validate
@ -702,19 +728,16 @@ function error_validate {
## Validate Sync Required
function md5_compare {
# MESSAGE="Comparing ${GRAVITY_FI} Changes"
# echo_info
HASHMARK='0'
MESSAGE="Analyzing ${REMOTE_HOST} ${GRAVITY_FI}"
echo_stat
primaryDBMD5=$(${SSHPASSWORD} ssh -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "md5sum ${PIHOLE_DIR}/${GRAVITY_FI}")
primaryDBMD5=$(${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "md5sum ${PIHOLE_DIR}/${GRAVITY_FI}" | sed 's/\s.*$//')
error_validate
MESSAGE="Analyzing $HOSTNAME ${GRAVITY_FI}"
echo_stat
secondDBMD5=$(md5sum ${PIHOLE_DIR}/${GRAVITY_FI})
secondDBMD5=$(md5sum ${PIHOLE_DIR}/${GRAVITY_FI} | sed 's/\s.*$//')
error_validate
if [ "$primaryDBMD5" == "$secondDBMD5" ]
@ -724,7 +747,7 @@ function md5_compare {
HASHMARK=$((HASHMARK+0))
else
MESSAGE="${GRAVITY_FI} Differenced"
echo_info
echo_warn
HASHMARK=$((HASHMARK+1))
fi
@ -732,21 +755,18 @@ function md5_compare {
then
if [ -f ${PIHOLE_DIR}/${CUSTOM_DNS} ]
then
# MESSAGE="Comparing ${CUSTOM_DNS} Changes"
# echo_info
if ${SSHPASSWORD} ssh -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} test -e ${PIHOLE_DIR}/${CUSTOM_DNS}
if ${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} test -e ${PIHOLE_DIR}/${CUSTOM_DNS}
then
REMOTE_CUSTOM_DNS="1"
MESSAGE="Analyzing ${REMOTE_HOST} ${CUSTOM_DNS}"
echo_stat
primaryCLMD5=$(${SSHPASSWORD} ssh -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "md5sum ${PIHOLE_DIR}/${CUSTOM_DNS}")
primaryCLMD5=$(${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} "md5sum ${PIHOLE_DIR}/${CUSTOM_DNS} | sed 's/\s.*$//'")
error_validate
MESSAGE="Analyzing $HOSTNAME ${CUSTOM_DNS}"
echo_stat
secondCLMD5=$(md5sum ${PIHOLE_DIR}/${CUSTOM_DNS})
secondCLMD5=$(md5sum ${PIHOLE_DIR}/${CUSTOM_DNS} | sed 's/\s.*$//')
error_validate
if [ "$primaryCLMD5" == "$secondCLMD5" ]
@ -756,7 +776,7 @@ function md5_compare {
HASHMARK=$((HASHMARK+0))
else
MESSAGE="${CUSTOM_DNS} Differenced"
echo_info
echo_warn
HASHMARK=$((HASHMARK+1))
fi
else
@ -764,6 +784,12 @@ function md5_compare {
echo_info
fi
else
if ${SSHPASSWORD} ${SSH_CMD} -p ${SSH_PORT} -i "$HOME/${SSH_PKIF}" ${REMOTE_USER}@${REMOTE_HOST} test -e ${PIHOLE_DIR}/${CUSTOM_DNS}
then
REMOTE_CUSTOM_DNS="1"
MESSAGE="${REMOTE_HOST} has ${CUSTOM_DNS}"
echo_info
fi
MESSAGE="No ${CUSTOM_DNS} Detected on $HOSTNAME"
echo_info
fi
@ -771,11 +797,11 @@ function md5_compare {
if [ "$HASHMARK" != "0" ]
then
MESSAGE="Replication Necessary"
echo_info
MESSAGE="Replication Required"
echo_warn
HASHMARK=$((HASHMARK+0))
else
MESSAGE="Replication Unncessary"
MESSAGE="No Changes to Replicate"
echo_info
exit_nochange
fi
@ -916,7 +942,14 @@ function config_generate {
echo -e "========================================================"
echo -e "========================================================"
ssh-copy-id -f -i $HOME/${SSH_PKIF}.pub ${REMOTE_USER}@${REMOTE_HOST}
if hash ssh-copy-id 2>/dev/null
then
ssh-copy-id -f -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 ${REMOTE_USER}@${REMOTE_HOST} 'cat - >> .ssh/authorized_keys'
fi
echo -e "========================================================"
echo -e "========================================================"
else
@ -1099,7 +1132,7 @@ function echo_info {
## Warning
function echo_warn {
echo -e "${WARN} ${MESSAGE}"
echo -e "${WARN} ${PURPLE}${MESSAGE}${NC}"
}
## Executing