To be honest, I've never understood the point of running Rivendell as a dedicated system user rather than the one the operator is logged in as.
As for JACK, there seems to be very little information out there on getting it to run. On some machines I can't get it to start at all; on others, it runs with fits and sputters, and on still others it gives me no trouble at all. As far as I can see it's a crap shoot, much like the weather here in New England at this time of year.
Rob -- Я там, где ребята толковые, Я там, где плакаты "Вперёд", Где песни рабочие новые Страна трудовая поёт. On Mon, 6 Mar 2017, Fred Gleason wrote:
On Feb 28, 2017, at 09:05, Alessio Elmi <[email protected]> wrote: Just a recap of which are the presupposition: it has always been suggested to run Rivendell under dedicated user, something like a system user, different from the one which is 'graphically' logged in. For example you may want a simple-and-not-privileged user called 'studio', which cannot touch /var/snd folder. It can of course launch all Rivendell UI modules, and actually it does. On the other hand Rivendell daemons, caed/ripcd/rdcatchd run under 'rivendell' user, who hasn't any active X session, and it is the owner of /var/snd. A nice way of accomplish this security framework is to setuid the three binary daemons with chown rivendell:rivendell and then chmod 4755. So far, so good. Any problem with the above scenario? Are there newer recommendations? That is the current setup with BroadcastAppliance-based systems. Problems come up if you want to use jack server to handle audio resources. In fact, any applications looking for a jack server can only see instances running under the same user identity. If 'studio' runs 'jackd', this cannot be seen by 'caed', which is launched by 'rivendell'. You need to setuid also jackd the same way you did for caed. This is the only solution I found. But as you can imagine, this workaround leads to a domino effect, where any jack-related application must be setuid, otherwise it cannot work. And of course you cannot use any graphical tool, like qjackctl/patchage since they need an X server owned by the same jack-server user. There is another strange behavior I need to investigate better (you may confirm). If jack server is not setuid (just chmod 0755), and launched through systemd with a specific user, then caed cannot see it, even though users match. But this is not a big deal in the end. It is a pity. Jack is a very versatile tool. Since the computer is used for production purposes, I really would like users to listen to Youtube with the same audio card linked to RDLibrary. This is basically a problem with JACK. My understanding is that it is due to overly restrictive permissions applied to the shared memory segments that jackd uses for its IPC. Theoretically at least, it could be addressed by widening those permissions, though this also has security implications that would need to be analyzed and addressed. Their developer community is aware of it (and at one point even had a patch that would permit multiple users to share the same jackd instance), but at present don’t seem to be overly motivated to do anything about it. For example, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500249 Googling JACK_PROMISCUOUS_SERVER should bring up lots of info. Cheers! |----------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |----------------------------------------------------------------------| | A room without books is like a body without a soul. | | -- Cicero | |----------------------------------------------------------------------|
_______________________________________________ Rivendell-dev mailing list [email protected] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
