Isn't this what the Server/Client model is all about?
In our deployment, our main studio is located in another town from
the owner and myself. There's a "server" at the main studio (which
is also the active RDAirPlay host), and workstations at both my
location and the owners location. All of our networks (two home
locations, the main studio, and translator sites), are linked
together with VPNs across the internet.
The good:
We don't have to drive 30 miles to the main studio to make
schedule changes or add/remove content from the Rivendell system.
The bad:
It's painfully slow doing anything in Rivendell that's not on a
local LAN.
There are no issues with all of the Rivendell systems running at
the same time provided you don't work on the same thing from two
different locations. Even if you do though, the last change would
win. With the remote workstations, we're able to maintain content,
create and edit clocks/logs, pull reports...Pretty much everything
you can do locally with Rivendell, it's just slower. The speed
penalty is due to network latency. Two things we use to make this
easier for us: a NAS (with NFS mounts for the Rivendell Server),
and an IP KVM (from Avocent) that gives us a remote console to the
Rivendell box for operating it as if we were right there in the
studio.
The "glue" that makes this all happen is the VPN. There are
volumes written on VPNs, network security, remote access
technologies and they go far beyond the scope of Rivendell itself.
I would not recommend running a VPN directly on the Rivendell host
and instead build up a VPN on your network router, or use a VPN
service to tie your networks together. Keep in mind your security
requirements and trust between your partners network and your own
(in a site-to-site VPN, any computer on either side of the VPN has
access to all network devices on all VPN end-points).
James
----- Original Message -----
From: "Cowboy" <[email protected]>
To: "Rivendell-Dev" <[email protected]>
Sent: Saturday, February 3, 2018 1:47:01 PM
Subject: Re: [RDD] Guidance on remote machine access
On Saturday 03 February 2018 12:07:20 pm Rich Lawrence wrote:
Hello all.
I have a partner helping with my streaming station and I would
like him to be able to access the main database, which is housed
at my location, from a remote machine at his location.
This is mostly going to be used for adding new music, promos,
etc. Voice tracking is something g later down the line, but the
priority is the former.
I’m running 2.10.3 on Ubuntu 12, and would like some
suggestions on the best way to accomplish what I am looking to do.
"Access the main database" could be taken a few ways.
Literally...
I would first offer an EXTREME CAUTION doing this !!
The likelihood of completely trashing your database, resulting in
the loss of EVERYTHING is not trivial !
Fred and I have discussed this many times.
The problem is two people accessing the same thing at the same
time.
Which is the "valid" data ? The first one to commit, or the last
one to commit,
neither being aware of the other, thus commiting conflicting
data.
OK, got that ? You have been warned !
Figuratively, meaning able to work with the system, and not
directly access the database.
You could add his remote host, assuming he has a public IP on
that machine,
the same as any other. I'd strongly recommend against, as it
involves a good
deal of risky exposure at both ends, but you're not exposing your
database
directly on the open internet.
Across a VPN this should work easily.
Setting up a VPN on an unfamiliar OS ( Ubuntu ) is beyond me, but
once done
his remote machine is "local" as far as the system is concerned,
albeit slower.
Probably, you'd actually be creating the VPN firewall to firewall
so that the
Rivendell machines don't even need be aware it's not physically
local.
You could give him remote access to a local workstation via ssh
-X
Safer, but not without pitfalls, as music and such would have to
be first
transfered onto that machine, then imported "locally" at your
location though
he'd be the one actually doing it via remote access.
That's probably the way I'd approach it, based on familiarity
though the
idea of a VPN approach is probably the better way.
--
Cowboy
http://cowboy.cwf1.com
This Fortue Examined By INSPECTOR NO. 2-14
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
