From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5aef431f2c21560026646d6f28fac866@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] ndb/csquery: what is dns is not up? In-Reply-To: <20030423145118.J19261@cackle.proxima.alt.za> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-izkuvvtsralvchyxgzuhhmqsiw" Date: Wed, 23 Apr 2003 09:17:10 -0400 Topicbox-Message-UUID: 96aac3ae-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-izkuvvtsralvchyxgzuhhmqsiw Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Well, I just played with sshnet and looked at the source. It only gives you a /net/cs and a /net/tcp. ndb/cs in this world is a bit minimal. Unless your factotum is also started under that network, it shouldn't be able to dial auth servers available only under that network. You might try starting a second factotum. However, then it probably won't be able to figure out how to map the authdom to an auth server since that isn't available via the sshnet cs. I don't see a way around this without rewriting code. If the sshnet cs simulation actually looked in your /lib/ndb or if authdial looked in your /lib/ndb files after not finding things in /net/cs, you'ld have a chance of making it work. --upas-izkuvvtsralvchyxgzuhhmqsiw Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Wed Apr 23 08:52:21 EDT 2003 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Wed Apr 23 08:52:19 EDT 2003 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.30.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 907B619A9F; Wed, 23 Apr 2003 08:52:09 -0400 (EDT) Delivered-To: 9fans@cse.psu.edu Received: from cackle.proxima.alt.za (cackle.proxima.alt.za [196.30.44.141]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 8F9EF1999B for <9fans@cse.psu.edu>; Wed, 23 Apr 2003 08:51:32 -0400 (EDT) Received: from cackle.proxima.alt.za (localhost [127.0.0.1]) by cackle.proxima.alt.za (8.12.9/8.12.3) with ESMTP id h3NCpONF020097 for <9fans@cse.psu.edu>; Wed, 23 Apr 2003 14:51:28 +0200 (SAST) Received: (from lucio@localhost) by cackle.proxima.alt.za (8.12.9/8.12.3/Submit) id h3NCpM39020096 for 9fans@cse.psu.edu; Wed, 23 Apr 2003 14:51:22 +0200 (SAST) From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] ndb/csquery: what is dns is not up? Message-ID: <20030423145118.J19261@cackle.proxima.alt.za> Mail-Followup-To: 9fans@cse.psu.edu References: <49c539f6a568ec378811bea39824b177@plan9.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <49c539f6a568ec378811bea39824b177@plan9.bell-labs.com>; from David Presotto on Wed, Apr 23, 2003 at 08:22:59AM -0400 Organization: Proxima Research & Development Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu X-Reply-To: lucio@proxima.alt.za List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 23 Apr 2003 14:51:18 +0200 On Wed, Apr 23, 2003 at 08:22:59AM -0400, David Presotto wrote: > > ndb/csquery > > p9 > > [ ... ] Why does ndb/query authdom outside.plan9.bell-labs.com auth return sources.cs.bell-labs.com whereas ndb/ipquery authdom outside.plan9.bell-labs.com auth returns no response? I'm trying to get replica/pull to work across sshnet, but for some reason the authentication server is not being discovered whereas it seems that the 9fs connection is established correctly. I managed to get /net/dns to install itself once, but the rest of the time I have only net/ip and net/tcp and therefore not much in the line of useful information to reach the remote services :-) Not that I understand all the complications, I'm sure there's a lot that would be obvious to someone more comfortable with Plan 9 networking. ++L PS: Starting a new factotum seems to reroute the auth requests via the ssh tunnel rather than attempt to go via the original default route and that isn't what I expect either. --upas-izkuvvtsralvchyxgzuhhmqsiw--