Arts for X thin clients

[Stefan Westerfeld]

   Hi!

On Mon, Mar 29, 2004 at 11:18:47AM -0500, Chris de Vidal wrote:
> Lars Bungum said:
> > On Sat, 2004-03-20 at 21:13, Chris de Vidal wrote:
> >> Arts 1.2.1
> >> KDE 3.2.1
> >> I've Googled, I've read the Arts FAQ, I've searched this mailing list,
> >> but
> >> I cannot seem to enable ArtsD over a network.  Perhaps I've missed
> >> something.
> >> I have an X thin client.  The .mcoprc has had both
> >> GlobalComm=Arts::X11GlobalComm (which prevents artsd from starting) and
> >> GlobalComm=Arts::TmpGlobalComm.  I run artsd -n -F 5 -S 8192 & then X
> >> -query <X terminal server>.

You need to start artsd on the thin client after having logged in, if
you want to use Arts::X11GlobalComm (and you will probably want to do so,
if you want to use artsd remotely, see below).

> >> On the X terminal server, artsd is set in the KDE control panel not to
> >> start.  The .mcoprc matches on both ends.
> >> XMMS dies and says there is no sound server running.
> >> Argggg!
> >> Ideas?
> >
> > Chris,
> >
> > I've been struggling to get this to work for so long.   Therefore I ask
> > you - did you get anywhere with this?  My problem is that I don't
> > understand the authorization part at all.
> >
> > I log in as root on my (diskless) think client.  Is that a problem, for
> > instance?
> >
> > Hope someone answers. :)
> 
> I haven't gotten _any_ answer.  When I read similar threads on this list I
> see no answers.  It's almost as if the KDE people know it's broken but
> aren't saying so :-/

Well, so lets fix this here: its broken.

At least, most discussions I have with users on the subject of using a
non-local artsd earlier or later reach the point where the user says:
"oh well, if thats what artsd does, then I'll rather use an arts with
nas/mas/esd combination".

There are three reasons:

(a) its hard to get client and server find each other

If both run locally, this happens by reading files in /tmp/mcop-<username>,
which say which tcp host/port or unix domain socket to connect
(GlobalComm=Arts::TmpGlobalComm in .mcoprc). Of course, if you are
running on different hosts, this doesn't work, since they have different
/tmp directories.

Thats why Arts::X11GlobalComm was invented, which exchanges the information
over the X11 server. However, this implies that you have the X11 server
up and running _before_ starting artsd, and that client and server share
the same display. You can't start artsd and then log in.

An alternative but unsupported/undocumented way is to use the
ARTS_SERVER=host:port variable ; however, this does not work well
with authentication, so you can practically only use it with -u, which
is insecure.

(b) its hard to get client and server authenticate to each other
successfully

Basically, either you run with -u, or you use Arts::X11GlobalComm, or
you use artsd only locally.

(c) what you get might not be what you want

Usually, people expect that applications like noatun read and decode an
mp3, and artsd outputs the decoded data to the soundcard. What really
happens is however that applications like noatun tell artsd to read and
decode an mp3, and output it to the soundcard. This means two things:

 - both hosts need to have a reasonably similar file system (i.e. NFS
   mounted homes) otherwise, you will click on a file in noatun, which
   then can't be played
 - the cpu load will occur on the host running artsd, not on the host
   running noatun

This also indicates it is a very bad idea to run artsd as root for all
users, as you can then exploit the situation (as user) and tell artsd to
read security critical files, load .so files and execute arbitary code as
root, and so on.

> I did find a page for LTSP on recompiling arts with nas support.  It's an
> ugly hack but it should do what we want it to do (although I haven't had
> time to try it).  Here's the page:
> http://www.ncpl.lib.in.us/~rjune/lbe/LTSP-arts-howto.html

Yes, in fact my recommendation for most users who want to use KDE in a
setup where they log in remotely, is to select a pure sound server (MAS,
NAS or ESD), and configure KDE to use it. Most of the time, that will be
less work, and you will probably get what you expected to get in the
first place.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-