Start the rsync FROM Prod and TO Lab.
That way your Prod server needs to have
keys for your lab server but not vice-versa. (I’m assuming you’re
doing this using ssh.)
That is instead of running on the Lab
server: rsync prod:/path /path
Run on the Prod server: rsync /path
Lab:/path
rsync can use remote or local in both the
source and the target so you don’t have to let the lab folks initiate it –
you can initiate from the Prod machine.
Here we have no problem allowing Prod to
be “trusted” by dev/test machines but we do NOT allow Prod to trust
those machines. This means we can push whatever we want from Prod rather than
allow pulls from Dev/Test. The theory being that Prod would have a much
smaller cadre of users. If Prod were hacked we wouldn’t be as concerned
where they went from there because that would be the worst. Conversely if
Dev/Test is hacked we would not want someone to then suddenly have access to
Prod because we’d been dumb enough to allow trust from those machines to
Prod.
If you’re doing PCI this would be a
requirement I would think.
From:
veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Stump, Bob A
Sent: Wednesday, August 29, 2007
3:54 PM
To:
Veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] rsync and
SSH between production and lab
Hello,
I am leery about a request
that came in to setup rsync between the production master server and the master
server at a DR site for keeping the NetBackup catalog up to date. I know there
is always supposed to be a separation of production and DR/lab sites in order
to protect the safety and well being of the production site. Rsync works with
the superuser root having ssh capabilities both ways. GASP!
However, I know there are
some of you that use this approach. How do you protect your production site
with confidence that you and your management keep your jobs?
Thanks,
Bob Stump
