Closed C9312B4DC0 closed 12 months ago
Looks like it's abandoned.
So between yesterday and today I re-setup both of my pi-holes (though for different reasons). I did find out that they weren't working correctly, but can verify now that both are. 1 in push mode, 1 in pull mode.
https://github.com/theobjectivedad/pihole-cloudsync
This person made an update to the main pihole-cloudsync script to fix an issue with gravity table corruption (which I believe I have seen once or twice before the scripts stopped working). Delete the old pihole-cloudsync folder in /usr/lib/bin and pull the updated version from the repo above. Then install sqlite3 (apt get install sqlite3).
Afterwards set it back up just like normal according to the directions for push or pull mode.
Github has changed and now requires user tokens for authentication instead of passwords. Follow instructions on Github to generate a personal access token. I created fine-grained tokens (2) that only have access to "my-pihole-lists" repo. The push one has read/write access and the pull token has only read access. Use these tokens for authenticating when doing init-push or init-pull then as the guide says you can save your login username and token for auto-authentication.
The reason sqlite3 needs to be installed is that Pi-hole uses it's own version of sqlite3, pihole-FTL sqlite3. I tried to adjust the new script to use pihole-FTL sqlite3 but the script still failed. I found this thread on pi-hole.net that explains likely why. Basically the table modification calls made by the pihole-cloudsync script (any version) do not follow "best practices" for sqlite databases with how the script is wrote and uses sqlite3, so attempting the script with pihole-FTL sqlite3 results in failure because of foreign key constraint issues not being allowed as the recommended practice on sqlite3 databases. Regular sqlite3 as compiled doesn't have to obey the FOREIGN KEY constraints variable. You can have both regular sqlite3 and Pi-holes own version pihole-FTL sqlite installed at the same time. I have seen no issues.
Everything is backing to working correctly now. I think the other person that created the script tried to send the update as a merge request to the original author but he has not approved it. Either way the new one works and everyone can still enjoy this app.
https://github.com/vmstan/gravity-sync
I also recently saw this project as well. Kind of a successor to this it seems with active development.
Hi, this project is restarting. Thanks for the input and interest. Please feel free to send new merge requests.
I'm glad I found this issue. It turned out that I also had a corrupted gravity db and pihole started to block 100% of queries and had no adlists showing. Running a dig against the upstream DNS worked but pihole would fail on the same dig with a timeout and no servers found (DNS I assume).
I was initially worried that theobjectivedad's fork was older than the version 6 here in Steve's repository and had not been optimized for container operations but copying over the pihole-cloudsync bash script works fine so far. I run 2 instances of pihole+unbound in containers on Raspberry Pie 3b+s running Raspbian Bullseye.
Thanks a ton IconicLight.
Steve this gravity corruption issue is nasty and needs to be fixed ASAP. Glad to see you plan to bring this project back to life as it's brilliant.
edited to remove suggestion that simply copying over theobjectivedad's fork was sufficient to get everything working properly. It took a while but I did notice that my automated sync wasn't properly working. Following IconicLight's instruction to re-run the pihole-cloudsync setup procedure seems to have resolved that problem.
The title says it all. Is this still a viable solution for multi-pi setups?