Run gravity update on the primary

[mentalsoup]

What feature would you like added?

With the upcoming feature completion on issue #28 I noticed that while the targets received and successfully processed a gravity update, the primary did not. Would it be possible to run a gravity update on the primary as either a pre sync step or post sync completion?

Version

1.2.2-beta.0

Log output

No response

[PromoFaux]

I think the assumption here is that you will already have run gravity on your primary Pi-hole instance after adding new lists, no need to automate this.

Thinking out loud, and maybe this would be a seperate issue @mattwebbio, however I wonder if it might not be better to have an option to only run gravity on the remote if it is detected that a list was added or removed. I've not yet dug into the internals of this project, so it might be more complex than meets the eye.

My thinking is: Pi-hole already runs gravity on a schedule once a week, which to be honest is more than enough. The only time that gravity should need to be run manually is after a change to the lists being used on the instance - or it a list maintainer resolves an issue with their list. Other than that, list contents don't change all that often - so running gravity every INTERVAL_MINUTES may just be overkill :)

[mattwebbio]

@PromoFaux

if it might not be better to have an option to only run gravity on the remote if it is detected that a list was added or removed

Taking this a step further, I would love to only perform a sync when changes are detected on the primary (as opposed to blindly uploading backups to the secondaries at the interval).

Right now, Orbital doesn't know anything about the state of the PiHoles it's syncing or the contents of the backups. If that problem were solved (though I'm not sure what the best approach to this would be), it would be much easier to control "when" things happen. I don't have much time to investigate this unfortunately, but ideas and PRs are definitely welcome 🙂

[PromoFaux]

Only things I can think of off the top of my head right now:

• Take a teleporter backup from both the primary and secondary, extract them, and then compare the file contents.
• Keep the previous teleporter backup from the primary in memory/file somewhere, and use that to compare against the newer backup - if there are no changes - no need to restore to secondary. If there are changes, is it just black/whitelist items? If so, just sync and do nothing. If there are adlist changes, then sync and also do gravity run.

In an ideal world, we would get off our arses and design some sort of HA functionality into Pi-hole directly - but it's finding the time! Never say never, though.

[JvdMaat]

Yeah, please do not do a gravity update on the primary. I have two piholes. Primary is in docker, the backup is on a Pi Zero W. (low power, cause it's just backup DNS and serves only about 25% of all queries). But the gravity update kills the Zero W, and the orbital sync was failing (timeout on gravity update). So I switched the orbital sync config around so the Pi Zero W is the "primary", and syncs changes to the docker container without issues.
Doesn't pihole automatically do a regular gravity update? As PromoFaux said, if you update the adlist, you should do your own manual gravity update.

And also seconding the only do a gravity update if there was a change. But that would require retaining the backup, unzipping it, inspecting it, etc. So that's quite a bit of work.

And extrapolating on that, if you keep backups of both primary and secondary (and tertiary, etc), you can theoretically make a change on any of the piholes, and it will sync out to the others. No need for primary or secondary. They're all equal.