Github user/pass deprecation by nov 2020 can we update to r3fl3ct token ssh key pairs auth for cloudsyncing

[piklz]

The ssh key info is there github but can we also update the setup help on front page here , ssh / or token base logins for future unattended pull/push of cloudsync lists thanks!

[dhcpserver]

Second this, the change at GitHub no longer allows for cached credentials, breaking sync. I know you eluded to SSL being for the advanced class, but I think that time has come!

[dhcpserver]

Creating the token wasn't too hard, I just can't figure out how to update it on my master and the sync keeps showing like everything is a-ok when it's not really updating.

[dispo2]

So this is what I did - I think (it was a long time ago now).

In the github web page, via account icon / settings / developer settings / personal access tokens I created a token with all 'repo' privileges but none of the others. I only have one repo so didnt try to narrow it down to which repo it applies to.

The token is effectively a password.
I also have a private email address configured within the 'noreply.github.com' domain under account / settings / email addresses

On the machines running pihole I use the above to authenticate

cd /usr/local/bin/my-pihole-lists
git config --global credential.helper store
git config --global user.email "whatever you get [email protected]"

when asked for a password paste in the PAT key.

Thats it. sync then works via the git software using the email as ID and the PAT as password.
I cant remember how it asks for the password. I record the above commands in a crib sheet in case I need to rebuild and have nothing recorded for password so assume it prompts you for it after entering the user.email. If it doesnt then I'll need to look it up.

I havent tried ssh etc as the above sync uses https so didnt feel the need.

[dhcpserver]

This worked perfectly, thank you so much! Everything is up and spinning again! Thanks for taking the time to detail all that out, it fixed everything.

It seems like blocklist items don't get replicated, is that correct behavior? I never really noticed it before but now that I started populating the lists, I caught that it didn't seem to replicate on at least one of the child nodes.

Thanks again, you saved the day!

[dispo2]

Not sure what you mean, do you mean blacklist / whitelist entries or the lists under group management / adlists ?

Either way they should definitely be replicated but the script copies the details of the adlists and the slave piholes will then try to download the list contents themselves. The actual adlist content is not replicated. This means that if a list is unreachable but is cached on the master then the slave will not have the entries but the master will have old / cached entries.

You should be able to see that in the pull log as a fail will be recorded when retrieving the adlist.

On my master and slaves the number os blocked domains is identical though they can drift slightly depending on when each pihole refreshes the adlist contents.

Any whitelist / blacklist / regex entries you have created should definitely sync to any slaves.