Arts for X thin clients

[Chris de Vidal]

Stefan Westerfeld said:
> > 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).

I believe I had even tried that.  Let's see... I logged into KDE remotely
then SSHed into the X thin client (the actual X server... am I the only
one that finds X server/client terms confusing??) from the X terminal
server (where KDE actually executes).  In the SSH session on the X thin
client (X server) using the same username that the X server was running
under (root), I ran
export DISPLAY=:0 # since the X server on the X thin client is
                  # running essentially as localhost
echo GlobalComm=Arts::X11GlobalComm > ~/.mcoprc
artsd -n -F 5 -S 8192

I believe I got the same error message as when I tried to start it with no
X server running and when I .  So it doesn't seem to flow as advertised.

I then ran xcalc which showed up on the X terminal server and back on my
remote X thin client (the X server), so I know I was authenticated
properly and my display variable was set correctly.

I could try it again and report the error message.

> > 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.

Ahh, thanks for your honesty :-)

> 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.

I tried this too; see above.

> 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.

I also tried something like this:
ssh user at host "artsd -n" & # The X thin client with the sound card
artsd &
artsrec | ARTS_SERVER=host:port artsrec
xmms --play # no sound

I could repeat this experiement, but I recall seeing auth errors.  Perhaps
I need to test the -u flag as you suggest.

> (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:

OK this explains alot.  arts isn't a sound conduit so much as it is a
front-end for an mp3/wav player.

>  - 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

Makes sense.

>  - the cpu load will occur on the host running artsd, not on the host
>    running noatun

Well I suppose this is OK considering I'm on a 10MBit shared-media network
and mp3s stream much better when compressed.  But it isn't what I was
expecting.

> 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.

Makes sense.

> > 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.

Do you know of more websites/resources like the above which document using
NAS/ESD/MAS with arts?


Thanks for the enlightenment,
/dev/idal