SLUG Mailing List Archives
Re: [SLUG] Replicate Production to DR file system with rsync
- To: slug@xxxxxxxxxxx
- Subject: Re: [SLUG] Replicate Production to DR file system with rsync
- From: Daniel Pittman <daniel@xxxxxxxxxxxx>
- Date: Fri, 12 Feb 2010 16:18:16 +1100
- Reply-to: slug@xxxxxxxxxxx
- User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
James Gray <james@xxxxxxxxxxx> writes:
> I've googled this one for a while and can't find any examples of people
> doing *system* file sync with rsync. So I thought I'd throw it out to the
> collective wisdom of SLUG. Here's the full story.
> We have a SuSE-based production application/DB server pair and a
> corresponding pair in a disaster recovery location (offsite, bandwidth
> consumption needs to be minimised). We need to sync a number of files
> between these servers and some require elevated (root) privileges at *both*
> ends. Here lies the problem; we don't allow remote root logins (via SSH or
> any other method either...sudo, console or nadda).
> I want to use rsync because of it's ability to transfer
> differential/incremental changes and thus bandwidth friendly, however any
> other tool would be fine too. However, due to the inability for root to
> login directly, how the heck do I synchronise particular files in privileged
> locations (like /etc/shadow)?
...if you allow this tool to write to /etc/shadow, just allow root logins:
you have added *nothing* by forbidding them. Why? An attacker with access to
the rsync tool can add an additional root user with a known password anyhow,
so additional "security" doesn't actually change the problem space at all.
> I can start whatever services I need at either end (like an rsync server)
> but the main thing is all files maintain the same owner/group/mode at each
Just use root, if you want to go down this path.
Alternately, I would suggest using something like puppet which is designed to
do system management like this in an automated fashion; it is a completely
different approach, but one that will probably solve your underlying problem
without needing to change your security model so much.
 ...and, by implication, /etc/passwd, since the later isn't much use
without the former being updated too.
✣ Daniel Pittman ✉ daniel@xxxxxxxxxxxx ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons