[nas] Re: Bug#207659: hppa: cannot connect to host: connection refused

[Jon Trulson]

On Sat, 13 Sep 2003, Martin-Éric Racine wrote:

> From: Martin-Éric Racine <q-funk at pp.fishpool.fi>
> Date: Sat, 13 Sep 2003 22:51:06 +0300 (EEST)
> Subject: Re: [nas] Re: Bug#207659: hppa: cannot connect to host:
>     connection refused
> To: Jon Trulson <jon at radscan.com>
> Cc: Steve McIntyre <steve at einval.com>, 207659 at bugs.debian.org,
>      nas at radscan.com
> X-Spam-Status: No, hits=-31.5 required=5.0
> 	tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
> 	      QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE
> 	autolearn=ham version=2.53
> X-Spam-Level:
>
> On Tue, 9 Sep 2003, Jon Trulson wrote:
>
> > On Mon, 8 Sep 2003, Steve McIntyre wrote:
> >
[...]
>
> > do the nas clients (auplay, et. al.) work properly locally?  remotely?  I'd
> > make sure that works before messing with KDE/whatever you are trying to get
> > working...
>
> What sort of tests do you suggest that I do, on localhost?
>

	Trying out the nas clients, something like 'auinfo', 'auplay <some
.wav file>', etc... In other words, just see if the server is even working
properly with it's own clients...

>
> > 	I am not sure how ALSA plays into this...
>
> ;-) Alsaplayer is a sample player. Depending upon the compilation
> options, it is possible to enable built-in support to output to arts,
> esound, NAS, etc.
>

	Ahh, right, I think Erik did the alsaplayer plugin... Erik? :)
>
> > > >Btw, those NAS developers should figure out a stategy to transparently handle
> > > >authentication e.g. when logging on by remote via GDM, KDM or XDM.  Given that
> > > >the DISPLAY environment variable is automatically exported when using such a
> > > >display manager in indirect mode, one would think that e.g. KDE would then
> > > >automagically know where to find its audio device, but in practice this fails.
> >
> > 	;-) AUDIOSERVER is actually quite useful when your audio device is
> > across the room, but Steve is right - this is supposed to be working.  The
> > server to use is determined like so:
> >
> > 	$AUDIOSERVER
> > 	$DISPLAY
> > 	:0
> >
> > 	In that order...  This does require v1.6 though (there are various
> > bugs in previous versions)...  You can also run nasd with debugging - that
> > might show some useful info...
>
> Noted.
>

	Does it work??? ;-)

>
> > 	As for the auth tokens... Yes, that does need some revisiting... I
> > played with it a year or so ago, and it just didn't work.  Not surprising I
> > guess, since that code hasn't been changed since 1994 or so...
>
> TBH, I'd much rather see NAS daemon use libtcpwrap than that bloated
> xauth.  At any rate, I have always found xauth to be really cumbersome;
> thanks goodness SSH handles thta transparently, nowadays!
>
> The same goes for XDMCP (i.e.GDM,KDM,XDM), but that's a different issue. :)

	I accept patches ;-)

-- 
Jon Trulson    mailto:jon at radscan.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
You talk like a Ferengi.