The way I'd advise handling multiple for now, sort of reverts back to the master/secondary model, where one Pi-hole is the source of truth, where all changes are made (but Gravity Sync is not installed) and the other 2 (3, 4, etc) all are configured to point to it.

There is already an option for the installer that functions similar to how the legacy (3.x) one did, that will prep the master with all the necessary components and settings but not deploy Gravity Sync. I just didn't publish it yet.

curl -sSL http://gravity.vmstan.com | GS=prep bash

At some point I may develop a better way 😈

Has this been improved upon? I'm trying to do what you've suggested but running into issues.
I can go into detail but figured I'd ask first. :)

No, we haven't made any significant changes to 4.x that would change this.

Good to know.
Here is what I did...

1. Prep Primary PiHole (Source of Truth) w/ the following command...
   curl -sSL https://raw.githubusercontent.com/vmstan/gs-install/main/gs-install.sh | GS=prep bash

2. Install Gravity-Sync w/ the usual command on PiHole2 and PiHole3...
   curl -sSL https://raw.githubusercontent.com/vmstan/gs-install/main/gs-install.sh | bash

3. Attempt "gravity-sync pull" from PiHole2 and PiHole3

   • Minor Issue: This appears to work but I noticed that differences in files are always found. No matter how much this is ran.

4. When "gravity-sync auto quad" is ran and the systemd timer calls the systemd service, it spits out an error even though sync seems to work. I tried running the service as is and editing the .service file to use "gravity-sync pull". Both produce the same result.

Here is the error from checking the status of gravity.service...
~$ sudo systemctl status gravity-sync.service

• gravity-sync.service - Synchronize Pi-hole instances
  Loaded: loaded (/etc/systemd/system/gravity-sync.service; disabled; vendor preset: enabled)
  Active: failed (Result: exit-code) since Tue 2024-01-09 18:34:37 UTC; 1s ago
  TriggeredBy: * gravity-sync.timer
  Process: 11854 ExecStart=/usr/local/bin/gravity-sync (code=exited, status=1/FAILURE)
  Main PID: 11854 (code=exited, status=1/FAILURE)
  CPU: 547ms

Jan 09 18:34:37 pihole2 sudo[11921]: REDACTED : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/mv /tmp/05-pihole-custom-cname.conf.gsb /etc/dnsmasq.d/05-pihole-custom-cname.conf
Jan 09 18:34:37 pihole2 sudo[11921]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 09 18:34:37 pihole2 sudo[11921]: pam_unix(sudo:session): session closed for user root
Jan 09 18:34:37 pihole2 gravity-sync[11854]: [69B blob data]
Jan 09 18:34:37 pihole2 sudo[11923]: REDACTED: TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/chown pihole:pihole/etc/dnsmasq.d/05-pihole-custom-cname.conf
Jan 09 18:34:37 pihole2 sudo[11923]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 09 18:34:37 pihole2 sudo[11923]: pam_unix(sudo:session): session closed for user root
Jan 09 18:34:37 pihole2 gravity-sync[11854]: [81B blob data]
Jan 09 18:34:37 pihole2 systemd[1]: gravity-sync.service: Main process exited, code=exited, status=1/FAILURE
Jan 09 18:34:37 pihole2 systemd[1]: gravity-sync.service: Failed with result 'exit-code'.

[EDIT] Let me know if you'd rather me create a new ticket for this issue.

Thought this might be relevant too...
When ran manually...

~$ gravity-sync pull
∞ Initializing Gravity Sync (4.0.6)
✓ Loading gravity-sync.conf
✓ Detecting local Pi-hole installation
✓ Detecting remote Pi-hole installation
✓ Gravity Sync falling back to peerless mode
! Please configure Gravity Sync on remote host
✓ Evaluating arguments: PULL
» Remote target USER@IP
✓ Validating pathways to Pi-hole
✓ Validating pathways to DNSMASQ
✓ Hashing the remote Gravity Database
✓ Comparing to the local Gravity Database
! Differences detected in the Gravity Database
✓ Hashing the remote DNS Records
✓ Comparing to the local DNS Records
! Differences detected in the DNS Records
✓ Differences detected in the DNS Records
✓ Hashing the remote DNS CNAMEs
✓ Comparing to the local DNS CNAMEs
! Differences detected in the DNS CNAMEs
! Static DHCP Addresses not detected on the local Pi-hole
! Replication of Pi-hole settings is required
✓ Performing backup of local Gravity Database
✓ Performing backup of remote Gravity Database
✓ Checking Gravity Database copy integrity
✓ Pulling the remote Gravity Database
✓ Replacing the local Gravity Database
✓ Setting file ownership on Gravity Database
✓ Setting file permissions on Gravity Database
✓ Performing backup of local DNS Records
✓ Performing backup of remote DNS Records
✓ Pulling the remote DNS Records
✓ Replacing the local DNS Records
✓ Setting file ownership on DNS Records
✓ Setting file permissions on DNS Records
✓ Performing backup of local DNS CNAMEs
✓ Performing backup of remote DNS CNAMEs
✓ Pulling the remote DNS CNAMEs
✓ Replacing the local DNS CNAMEs
✗ Setting file ownership on DNS CNAMEs

Enough spam for now. :)

I've setup two Pi-holes and set them syncing. Subsequently I have setup a third. I did a gravity-sync pull and it seems to have successfully pulled the settings. I would like a proper three-way sync but is there anything wrong with a pair syncing and then doing a pull from the third?