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" <c...@cwf1.com> To: "Rivendell-Dev" <rivendell-dev@lists.rivendellaudio.org> 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 Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev _______________________________________________ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
