Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CNAME initial sync #377

Closed
z3r0d1g1t opened this issue Jan 11, 2023 · 2 comments · Fixed by #384
Closed

CNAME initial sync #377

z3r0d1g1t opened this issue Jan 11, 2023 · 2 comments · Fixed by #384

Comments

@z3r0d1g1t
Copy link

First of all, you are truly a God sent, this was exactly what I have needed for months and months...

I just installed the scritps on two vm's. It seems CNAME's are not synced automatically out of the box. I had to manually write them in on the "slave" server too. After that the sync identified a mismatch, synced and became in sync (before that when using compare on the slave it only said no CNAME records were found on the "slave" server and that a sync was needed).

It might be that it is necessary to only write in one entry for it to trigger correctly, I have not tested this.

Best regards,
Jonas
@juahan
Copy link

juahan commented Jan 22, 2023

For me it helped if I just created "something" to the slave list, then on next push it did syncronize the full list correctly.

@systemofapwne
Copy link
Contributor

systemofapwne commented Feb 27, 2023 •
edited

I can confirm this.
The fix is rather easy: Instead of just testing, if "05-pihole-custom-cname.conf" exists on the remote end, on could have created that file via "touch" on the remote end in the first place.

The same happens btw for static DHCP: If 04-pihole-static-dhcp.conf is not present on the remote, gravity-sync fails. using "touch" on the remote to create an empty file with that name will make the sync to succeed.

systemofapwne added a commit to systemofapwne/gravity-sync that referenced this issue Feb 27, 2023
@systemofapwne
Fixing initial push of CNAME and Static DHCP entries to an 'empty' re…
006a357 
…mote (fixes vmstan#377)
@systemofapwne systemofapwne mentioned this issue Feb 27, 2023
Merged
systemofapwne added a commit to systemofapwne/gravity-sync that referenced this issue Mar 2, 2023
@systemofapwne
Fixed 'md5_recheck' for the bug vmstan#377
83d3b30
vmstan added a commit that referenced this issue May 18, 2023
@systemofapwne @vmstan
Fix: GS_SSH_PORT can be changed now via 'gravity-sync config <NEW_POR…
d77d9bb 
…T>' when already set in gravity-sync.conf. Fix: Initial sync of static DHCP and CNAME to 'empty pihole' now works. Enhancement: Various settings now settable via ENV vars (for Docker) (#384)

* SSH custom port: Fixed bug, where GS_SSH_PORT is overwritten by gravity-sync.conf (if set) when calling 'gravity-sync config NEW_SSH_PORT'. Docker enhancements: Made many config-variables settable via ENV vars

* Fixing initial push of CNAME and Static DHCP entries to an 'empty' remote (fixes #377)

* Removing unecessary 'export' keyword

* Fixed 'md5_recheck' for the bug #377

* Adding ENV documentation

* Fixing typo

* Fixed type and nicely formatted tables with emacs

---------

Co-authored-by: Michael Stanclift <mx@vmstan.com>
@vmstan vmstan closed this as completed in ad783f1 Jul 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
3 participants
@juahan @systemofapwne @z3r0d1g1t