[nas] Re: Bug#207659: hppa: cannot connect to host: connection refused
jon at radscan.com
Mon Sep 15 22:36:06 MDT 2003
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
> autolearn=ham version=2.53
> 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...
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
You talk like a Ferengi.
More information about the Nas