Skip to content
This repository has been archived by the owner on Jul 26, 2024. It is now read-only.

custom.list only replicates once it exists on secondary #39

Closed
xela1 opened this issue Jun 11, 2020 · 2 comments
Closed

custom.list only replicates once it exists on secondary #39

xela1 opened this issue Jun 11, 2020 · 2 comments
Assignees
Labels
bug Something isn't working

Comments

@xela1
Copy link

xela1 commented Jun 11, 2020

Describe the Issue
The custom.list only gets pulled from the primary, if it already exists on the secondary server.

Screenshots
[ INFO ] remote has custom.list
[ INFO ] No custom.list Detected on local
[ INFO ] No Replication Required
[ INFO ] Gravity Sync PULL Aborting (4 seconds)

sudo touch custom.list

[ OK ] Analyzing gravity.db on remote
[ OK ] Analyzing gravity.db on local
[ OK ] Analyzing custom.list on remote
[ OK ] Analyzing custom.list on local
[ WARN ] Differenced custom.list Detected
[ WARN ] Replication Required

Configuration:

  • OS for Primary/Secondary: Raspbian Buster lite
  • Platform for Primary/Secondary: Raspberry Pi3/Raspberry Pi Zero W
  • SSH Server/Client: OpenSSH
  • SSH Authentication: Keypair
  • Gravity Sync Version: 1.8.1
  • Pi-hole Versions: v5.0

Additional Context
Add any other context about the problem here. If you have any advanced flags set in your gravity-sync.conf please list them here.

@vmstan
Copy link
Owner

vmstan commented Jun 12, 2020

I think I've been able to reproduce this. It seems like it pulls and creates a new one if the gravity.db has a change, but if it only detects the custom.list doesn't exist, it doesn't proceed to the pull. I wasn't thinking through a situation where that would be the only thing that would need to be replicated, but if you've just made the change to the primary custom.list and nothing else, it wouldn't get there until the other piece of the puzzle was changed. Which you wouldn't know to do.

I've added a HASHMARK=$((HASHMARK+1) to the function that does this detection, basically treating it as a difference in comparison (typically it would do an MD5 hash between the two files, but if the file is just missing, it's still a difference) -- I'll test this and a couple other tweaks and likely roll 1.8.2 out soon.

@vmstan vmstan self-assigned this Jun 12, 2020
@vmstan vmstan added the bug Something isn't working label Jun 12, 2020
@vmstan
Copy link
Owner

vmstan commented Jun 12, 2020

1.8.2 published.

@vmstan vmstan closed this as completed Jun 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants