Rob, On Mon, Mar 6, 2017 at 3:49 PM, Rob Landry <[email protected]> wrote:
> > 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. I have had my troubles with jack but not that bad. My main troubles have come from onboard sound cards. n=2 versus n=3 has solved a good number of those in the past. IIRC, other times I have had to run at 48 and not 44.1. In the long ago past, I would sometimes run on a dummy sound card and use darkice (IIRC, way back when) to send to icecast. These days I use liquidsoap and glasscoder and haven't used darkice in years. I do have to get the group and limits stuff right though. > > > > Rob > > -- > Я там, где ребята толковые, > Я там, где плакаты "Вперёд", > Где песни рабочие новые > Страна трудовая поёт. > > all the best, drew > > 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 > > -- Bahamain Or Nuttin - http://www.bahamianornuttin.com <http://www.bahamianornuttin.com/>
_______________________________________________ Rivendell-dev mailing list [email protected] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
