networking arts outwith X

[Ron Arts]

Stefan Westerfeld wrote:
>    Hi!
> 
> On Sun, Jan 05, 2003 at 02:48:30PM +0100, Matthias Kretz wrote:
> 
>>On Saturday 04 January 2003 21:59, George Mochrie wrote:
>>
>>>I'm currently evaluating different ways of running X/KDE remotley on
>>>low-spec PCs and I could do with some help. I don't want to eat up too much
>>>network bandwidth and the spec of the xterms is an issue so I'm currently
>>>thinking of VNC using svgalib clients. Would it be possible to run artsd on
>>>the client and have all the groovy network transparency stuff without X?
>>>Could I tunnel it over ssh (not sure if I really want to, but everything
>>>else I need will be
>>
>>One way it could work:
>>Start artsd on the client with network transparency enabled (no need for 
>>X11GlobalComm - you can use the default of TmpGlobalComm).
>>It would make your life a lot easier if you tell artsd which port to use for 
>>tcp communication else you'd need "somehow" find that port number later.
>>
>>Then do the following on the application server:
>>export ARTS_SERVER=<client's ip address or domain name>:<portnumber>
>>This will tell all applications using the artsserver to connect to the remote 
>>artsd.
>>
>>Ah, I almost forgot: The apps need to authenticate with artsd. Either you 
>>disable authentication (for testing) or you find a way to automatically make 
>>it work [...]
>>
>>BUT there's some code missing - not a lot 
>>since I did some things already in kdenonbeta/arts/{jitterbuffer,branch} (but 
>>this is currently only working with a running X server since the 
>>authentication is done over X.
> 
> 
> I've thought a lot over the authentication problem myself in the last time,
> and even implemented another authentication scheme. But it seems that the new
> one is too complex (it allows specifying a server to accept only certain
> clients, and a client to connect only to certain servers), and not really
> secure, as the problem is, that through cookie based authentication anyone
> needs to know anyones cookie to successfully identify him, and can thus pretend
> to be anyone as well.
> 
> If somebody is interested in looking at it, I can provide a patch.
> 
> Nevertheless, I think the current situation needs to be improved. The problem
> is that with TmpGlobalComm the cookie is storied in /tmp. Thus, if you start
> a server on one computer and a client on another the cookies will be different
> (as they have different stuff in /tmp) and thus the authentication will fail
> if you're using TmpGlobalComm. The same is true if you're trying to build a
> connection between different users on the same system.
> 
> You can work around this (by doing cp ~/my-common-cookie /tmp/mcop-<username>/
> secret-cookie) or similar. I think the most useful way to change this for the
> next version of aRts (and thus, for KDE3.2) would be to use
> ~/.mcop/secret-cookie if it exists as new cookie, and write the cookie also
> there.
> 
> While this means that on NFS mounted homes (which quite some people use), the
> cookie will be automatically kept in sync, it also means that on NFS mounted
> homes, it will be transferred as plain-text over the local network. There,
> again, is a security vs. usability tradeoff to be made, but I think the new
> way is better than the old (as the old is absolutely unusable).
> 
> The code for doing so should also be folded into CSL. Then, using the CSL
> aRts driver (and compiling arts with --enable-csl) will allow cascading. Other
> apps that can use CSL will also be able to do authenticated cascading, then,
> which until now has not been possible due to the cookie problem.
> 
> Okay, thats just thoughts for now, any comments are welcome, and I hope to get
> the time to do the implementation of these soonish.
> 
>    Cu... Stefan

Stefan,

will this also help people that use PC-s as dumb X-terminals?
As I see it now, having artsd sound on your X-terminal requires
artsd running on that terminal, which requires mounting
your home directory from the server. This is not always
desirable, as the home directory may be in use for something else.

The LTSP project for example could benefit if sound on X-terminals
would be easier.

Best,
Ron Arts


-- 
Netland Internet Services
bedrijfsmatige internetoplossingen

http://www.netland.nl   Kruislaan 419              1098 VA Amsterdam
info: 020-5628282       servicedesk: 020-5628280   fax: 020-5628281

AIBOHPHOBIA - the fear of palindromes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3291 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20030110/e518a80d/attachment.bin>