I’m running into a challenge I’d love some advice on. I have 4 Debian 13 systems (one desktop, one laptop and 2 VMs) that I’d like to keep in sync so I don’t have to repeat the same setup steps on each one. The idea is:
If I install software on one, I’d like the others to have it too.
If I tweak configs (e.g., /etc, dotfiles, custom scripts), those changes should propagate.
Everything needs to run on infrastructure I own — servers, network, storage — in my home lab. No third-party cloud services. A VPN overlay between my systems is fine, but external SaaS is not.
Constraints / requirements:
One of the systems is a laptop that must also work offline. Obviously, when it’s offline it won’t sync, but it should still be fully functional with the last synced state. Same for the 2 VMs. When they boot up they may not have network connectivity. When it comes back online, it should reconcile changes.
I’m fine with a multi-layered approach, for example:
keep most of /etc and dotfiles in a self-hosted GitLab repo,
install/upgrade system packages manually via apt (I already mirror Debian repos locally),
put extra software in $HOME/run/bin or similar and sync that across systems.
What I want is a workflow that makes it practical and reliable to keep all 4 machines aligned without redoing work three times.
User data doesn’t need synchronization. That’s already taken care of.
Possible directions I’ve considered:
Git (GitLab CE instance in my lab) for configs + scripts.
Some Ansible style orchestration for pushing changes.
Rsync for syncing selected dirs.
Has anyone tackled a similar “keep multiple Debian machines in sync within a self-hosted environment” problem? I’d love to hear about approaches that worked (or pitfalls to avoid).
Something like Ansible to orchestrate actions and changes to each host is likely the easiest way to accomplish this. It’s pretty much what they’re designed to do. No sense reinventing the wheel (except for fun, of course).
Beyond learning the in’s and out’s of Ansible (or equivalent), it’s just a matter of getting yourself in the habit of making your desired changes in Ansible and pushing them out.
It might be worth having one additional host to play/test with to ensure that when you do deploy whatever to everything else, you are already confident in the expected results.
Yea that’s okay. I can deploy a VM on one of the nodes and play with that. However I am not sure that Ansible alone is the way to go here.
The 4 machines are never up at once to deploy the changes from a central location. These are my work computers, and I usually only have 1 of them powered (say the desktop), I manually install stuff on it, either from a github clone repo and local compile or some similar way, tweak configs until things work the way I need them. Then say 3 days later I pick up my laptop to do an on site job. Would love the new stuff to “magically” appear on it whenever it’s powered and connected.
What you’re describing is an “Endpoint Management” solution. There are ways to make Ansible work this way, but perhaps something like Puppet would be more inline with what you need.
In the Microsoft Windows world there’s SCCM, also known as Configuration Manager or MS Endpoint Manager (Microsoft being Microsoft, it’s gone through multiple name changes over the years haha… sigh). It literally does what you have described, though it only supports Windows client/server. (There was a time it supported Linux, but that support ended years ago. Not to mention it really is an ‘enterprise’ product and isn’t exactly cheap). I only mention this as it’s something you can reference in web searches and such to compare against
My friend Jay from Learn Linux TV solves this by using Ansible Pull. That way the systems don’t have to be on when you make the change but they will check on a schedule when they are on. He has a video on that here:
Thank you both for the help and for the suggestions. The video from Jay was especially interesting.
For my purposes Ansible Pull will get me about 40 - 50% there but alone is not enough, or actually it may be but with way more work formalizing every little change that it’s not really worth it to me.
Ansible Pull is great for a baseline install, with all the tools that can be deployed via packages and their predefined configurations. What I really want can be summed up like this: “I’m working on computer A. Part of that work may be for example creating custom scripts, analyzing binary files in Ghidra or doing some forensic work in Autopsy, or downloading a Python app from github, making some tweaks. Say during that work process I may change some Ghidra settings. I shut down computer A. I power on computer B and I would like to resume working where I left off the previous computer, with the exact same settings, files, binaries, etc.”
What I’ll likely end up using is a combination of Ansible Pull, a NFS export (or alternatively some rsync volume on a server) and some custom scripts.
Oh yea there’s Syncthing. I’ll have to play with that, but since I know you played with it too how secure is it? Can it be fully self-hosted with no “ping or contact home”? Does it preserve file ownership and permissions?
Later edit: Did a bit of research and looks like Syncthing is exactly what I need to keep the configs the same. Thank you @LTS_Tom for the suggestion!
It can then use a hub with versioning to safeguard against malicious actors deleting files on one of the devices, backed by ZFS snapshots and external backups. And apparently I can disable global discovery and relay servers and use my own self hosted so all the traffic is internal LAN or through VPN.
It preserves permissions (though not ownership but that’s fine, I can work around that), symlinks and has git like .stignore exclusions.
Yup, I use it for my real time backups also backed by ZFS on my TrueNAS. You can not only turn off relay, but also use direct connections between nodes
