[9fans] /bin/export (tunneling out)

[9fans] /bin/export (tunneling out)

[steve-simon]

Hi,

I want to want to export /net from my terminal to
a remote cpu server.

I assumed I could just do:
	term% cpu -h remotemachine
	cpu% bind /mnt/term/net/ /net.alt
	cpu% telnet /net.alt/tcp!111.222.333.444!telnet
	telnet: connection timed out

(I used IP addresses to avoid ndb/cs and any problems
it might introduce).

I don't understand why the telnet fails.

I think (guess) there is a better way to do
this using exportfs/srvfs/cpu but I cannot quite see how...

-Steve

Re: [9fans] /bin/export (tunneling out)

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 72 bytes --]

What if you just do:

	bind /mnt/term/net /net

and try it that way?

[-- Attachment #2: Type: message/rfc822, Size: 2171 bytes --]

From: steve-simon@ntlworld.nospam.com
To: 9fans@cse.psu.edu
Subject: [9fans] /bin/export (tunneling out)
Date: Mon, 15 Dec 2003 16:42:02 0000
Message-ID: <b11c9efb42da9958f25fbb9a809c0225@snellwilcox.com>

Hi,

I want to want to export /net from my terminal to
a remote cpu server.

I assumed I could just do:
	term% cpu -h remotemachine
	cpu% bind /mnt/term/net/ /net.alt
	cpu% telnet /net.alt/tcp!111.222.333.444!telnet
	telnet: connection timed out

(I used IP addresses to avoid ndb/cs and any problems
it might introduce).

I don't understand why the telnet fails.

I think (guess) there is a better way to do
this using exportfs/srvfs/cpu but I cannot quite see how...

-Steve

Re: [9fans] /bin/export (tunneling out)

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

The problem is that even with addresses, the remove /net's cs
comes back with a formula of

	/net/tcp/clone 111.222.333.444!23

It's a failure of vision on my part.  I always mount like
network to like so (/net to /net, /net.alt to /net.alt) and
don't notice it.  However, it is stupid.  I've been considering
fixing it for a while.  I guess its time.

[-- Attachment #2: Type: message/rfc822, Size: 2171 bytes --]

From: steve-simon@ntlworld.nospam.com
To: 9fans@cse.psu.edu
Subject: [9fans] /bin/export (tunneling out)
Date: Mon, 15 Dec 2003 16:42:02 0000
Message-ID: <b11c9efb42da9958f25fbb9a809c0225@snellwilcox.com>

Hi,

I want to want to export /net from my terminal to
a remote cpu server.

I assumed I could just do:
	term% cpu -h remotemachine
	cpu% bind /mnt/term/net/ /net.alt
	cpu% telnet /net.alt/tcp!111.222.333.444!telnet
	telnet: connection timed out

(I used IP addresses to avoid ndb/cs and any problems
it might introduce).

I don't understand why the telnet fails.

I think (guess) there is a better way to do
this using exportfs/srvfs/cpu but I cannot quite see how...

-Steve

Re: [9fans] /bin/export (tunneling out)

[Steve Simon]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

OK, after fiddleing some more I think I too
understand.

I can just mount over the top of /net for my application,
not as elegant but just as effective.

I'am not sure what your fix would be but a suggestion:
Could cs return relative paths rather than absolute ones?
The problem, of course, is finding all the things this breaks,
though I guess dial() reduces these in just a handfull.

Thanks for the help

-Steve


[-- Attachment #2: Type: message/rfc822, Size: 4752 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 359 bytes --]

The problem is that even with addresses, the remove /net's cs
comes back with a formula of

	/net/tcp/clone 111.222.333.444!23

It's a failure of vision on my part.  I always mount like
network to like so (/net to /net, /net.alt to /net.alt) and
don't notice it.  However, it is stupid.  I've been considering
fixing it for a while.  I guess its time.

[-- Attachment #2.1.2: Type: message/rfc822, Size: 2171 bytes --]

From: steve-simon@ntlworld.nospam.com
To: 9fans@cse.psu.edu
Subject: [9fans] /bin/export (tunneling out)
Date: Mon, 15 Dec 2003 16:42:02 0000
Message-ID: <b11c9efb42da9958f25fbb9a809c0225@snellwilcox.com>

Hi,

I want to want to export /net from my terminal to
a remote cpu server.

I assumed I could just do:
	term% cpu -h remotemachine
	cpu% bind /mnt/term/net/ /net.alt
	cpu% telnet /net.alt/tcp!111.222.333.444!telnet
	telnet: connection timed out

(I used IP addresses to avoid ndb/cs and any problems
it might introduce).

I don't understand why the telnet fails.

I think (guess) there is a better way to do
this using exportfs/srvfs/cpu but I cannot quite see how...

-Steve

Re: [9fans] /bin/export (tunneling out)

[David Presotto]

cs returns absolutes, clearly the mistake.  Only dial and csquery really care and they
already know the path of the cs called so they should be able to craft the abs
path from a relative one.

The fix can be easy.  I change dial to ignore the absolute path returned
by cs and just treat it as a relative one.  Then recompile everything that
uses dial.  That way nothing has to be recompiled immediately.

At some point in the future, I can change cs to just return
relative paths.

Re: [9fans] /bin/export (tunneling out)

[Steve Simon]

[-- Attachment #1: Type: text/plain, Size: 200 bytes --]

Great,

I am pleased that I did understand correctly ☺

In case you didn't realise my previous comments on
relative -v- absolute paths was susposed to be to
you and not 9fans (sigh).

-Steve

[-- Attachment #2: Type: message/rfc822, Size: 2387 bytes --]

From: David Presotto <presotto@closedmind.org>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] /bin/export (tunneling out)
Date: Mon, 15 Dec 2003 12:26:48 -0500
Message-ID: <dadb66d60d8f16294ac0f06d38175ec7@plan9.bell-labs.com>

cs returns absolutes, clearly the mistake.  Only dial and csquery really care and they
already know the path of the cs called so they should be able to craft the abs
path from a relative one.

The fix can be easy.  I change dial to ignore the absolute path returned
by cs and just treat it as a relative one.  Then recompile everything that
uses dial.  That way nothing has to be recompiled immediately.

At some point in the future, I can change cs to just return
relative paths.