[9fans] ndb/csquery: what is dns is not up?

[9fans] ndb/csquery: what is dns is not up?

[ron minnich]

I have the vmware auth server up. There is no ndb/dns running, since my
!$!@$!@$!@ DSL is down, so no DNS anyway.

As I read the man pages, if there is no dns running, ndb/csquery should
act pretty much like ndb/query, since it falls back to /lib/ndb (or so I
thought)

I do:
ndb/query sys p9

and would expect it to act like:
ndb/csquery
> p9

Is this true or not? they don't act the same at all, so I'm guessing
this is another mis-read on my part.

Does ndb/cs actually just layer over top of ndb/dns, and without ndb/dns
ndb/cs is hosed?

thanks

ron

Re: [9fans] ndb/csquery: what is dns is not up?

[Charles Forsyth]

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

ndb/query and ndb/ipquery look directly in the ndb files.
ndb/query does simple direct queries based on
the given attribute and value, ndb/ipquery
searches more extensively up through the subnet
hierarchy.  they are both good tools
to check basic functioning of an ndb file.  if they don't
produce sensible results, it's unlikely cs will.
ndb/query and (probably) ndb/ipquery do not talk to
ndb/cs or ndb/dns at all.

ndb/csquery simply opens /net/cs and speaks its protocol,
which expects strings of the form
	net!host!service
and replies with translations of them:

	term% ndb/csquery
	> net!plan9.bell-labs.com!9fs
	/net/il/clone 204.178.31.2!17008!fasttimeout
	/net/tcp/clone 204.178.31.2!564
	/net/il/clone 204.178.31.2!17008
cs relies on dns to translate domain names to ip addresses.
it does not expect a plain name such as `p9'.  it translates
dial(2) addresses.

there's a special case that's also useful in checking whether
your host, subnet and net defaults for services are reasonable.
	net!$attr!service
looks for the given attribute `attr' through the subnet
hierarchy starting at the host and working up.  thus
the dial(2) string `net!$fs!9fs' dials the (default) file server
configured for the current node, and the translation can
be checked by:
	term% ndb/csquery
	> net!$fs!9fs
	/net/il/clone 144.32.112.69!17008!fasttimeout
	/net/tcp/clone 144.32.112.69!564
	/net/il/clone 144.32.112.69!17008
i don't know without a lot of grepping
how much the $attr is used now but it is used
to find an authentication server in the absence of an authdom
(see /sys/src/libauthsrv/authdial.c).  it doesn't really matter
because the point here is that $xyz can be used to check that
cs gives a sensible value for xyz for the current node.

ndb/dnsquery opens /net/dns and uses its protocol:
	ndb/dnsquery
	> bell-labs.com ns
	bell-labs.com ns	ns.research.att.com
	bell-labs.com ns	yeats.pa.bell-labs.com
	bell-labs.com ns	crufty.research.bell-labs.com
	bell-labs.com ns	ns1.research.bell-labs.com
	bell-labs.com ns	dirty.research.bell-labs.com
	bell-labs.com ns	ns2.research.bell-labs.com
	> plan9.bell-labs.com
	plan9.bell-labs.com ip	204.178.31.2

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

From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: [9fans] ndb/csquery: what is dns is not up?
Date: Tue, 22 Apr 2003 22:37:19 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0304222230250.27065-100000@maxroach.lanl.gov>


I have the vmware auth server up. There is no ndb/dns running, since my
!$!@$!@$!@ DSL is down, so no DNS anyway.

As I read the man pages, if there is no dns running, ndb/csquery should
act pretty much like ndb/query, since it falls back to /lib/ndb (or so I
thought)

I do:
ndb/query sys p9

and would expect it to act like:
ndb/csquery
> p9

Is this true or not? they don't act the same at all, so I'm guessing
this is another mis-read on my part.

Does ndb/cs actually just layer over top of ndb/dns, and without ndb/dns
ndb/cs is hosed?

thanks

ron

Re: [9fans] ndb/csquery: what is dns is not up?

[David Presotto]

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

ndb/csquery
> p9

means, give me the formula for dialing net!p9!<no service specified>.  There is no such
formula.

However you could have said

ndb/csquery
> !sys=p9

This does mean the same as the ndb/query if there is nothing like
dns that cs can get added info from.

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

From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: [9fans] ndb/csquery: what is dns is not up?
Date: Tue, 22 Apr 2003 22:37:19 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0304222230250.27065-100000@maxroach.lanl.gov>


I have the vmware auth server up. There is no ndb/dns running, since my
!$!@$!@$!@ DSL is down, so no DNS anyway.

As I read the man pages, if there is no dns running, ndb/csquery should
act pretty much like ndb/query, since it falls back to /lib/ndb (or so I
thought)

I do:
ndb/query sys p9

and would expect it to act like:
ndb/csquery
> p9

Is this true or not? they don't act the same at all, so I'm guessing
this is another mis-read on my part.

Does ndb/cs actually just layer over top of ndb/dns, and without ndb/dns
ndb/cs is hosed?

thanks

ron

Re: [9fans] ndb/csquery: what is dns is not up?

[Lucio De Re]

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.

Re: [9fans] ndb/csquery: what is dns is not up?

[David Presotto]

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

Because ipquery starts and an ipaddress and looks through the database looking
for attributes bound to that address, then to the subnet containing that address,
then the subnet containing that subnet, ad nauseam looking for the attributes.

There is no ip address corresponding to an authdom, like outside.plan9.bell-labs.com.

I'll answer about sshnet as soon as I look at a man page to see what it
is.

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

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ndb/csquery: what is dns is not up?
Date: Wed, 23 Apr 2003 14:51:18 +0200
Message-ID: <20030423145118.J19261@cackle.proxima.alt.za>

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.

Re: [9fans] ndb/csquery: what is dns is not up?

[Lucio De Re]

On Wed, Apr 23, 2003 at 08:59:48AM -0400, David Presotto wrote:
>
> Because ipquery starts and an ipaddress and looks through the database looking
> for attributes bound to that address, then to the subnet containing that address,
> then the subnet containing that subnet, ad nauseam looking for the attributes.
>
> There is no ip address corresponding to an authdom, like outside.plan9.bell-labs.com.
>
Oh, OK!  I guess the name says it all, once you know what to look for.

> I'll answer about sshnet as soon as I look at a man page to see what it
> is.

Let me be less cryptic, while I have a chance.

My office is linked to the Internet via a convoluted path of private
networks, with a remote host that I can connect to using SSH.

I establish a "tunnel" to that host quite happily using sshnet, which
installs a stripped copy of /net.

The command

	srv sources.cs.bell-labs.com sources /n/sources

returns the reassuring "post..." and, in the absence of a factotum
key, prompts me for the proxima/......... which I use to authenticate.

Sadly, it seems to me that factotum attempts to connect directly to
sources.cs.bell-labs.com, according to tcpdump run on the remote
host.  The diagnostic output from factotum indicates the expected
timeout caused by the various filters in the path.

If I spawn a new factotum (it really needs an option to be removable,
by the way), I believe it fails to identify/resolve the auth server
associated with the auth domain.  I have no idea quite how to take
care of that problem.  Ideally, I'd create a /net/ndb entry, but
that's not possible with sshnet serving /net.

++L

Re: [9fans] ndb/csquery: what is dns is not up?

[David Presotto]

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

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.

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

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ndb/csquery: what is dns is not up?
Date: Wed, 23 Apr 2003 14:51:18 +0200
Message-ID: <20030423145118.J19261@cackle.proxima.alt.za>

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.

Re: [9fans] ndb/csquery: what is dns is not up?

[David Presotto]

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

Your message suggests a better solution than mine.  Just change sshnet to allow
also implement /net/ndb and have sshnet's simulated /net search that first.  It
would make it a lot more useful.  I don't have time right now, but perhaps you
do?

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

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ndb/csquery: what is dns is not up?
Date: Wed, 23 Apr 2003 15:16:25 +0200
Message-ID: <20030423151624.M19261@cackle.proxima.alt.za>

On Wed, Apr 23, 2003 at 08:59:48AM -0400, David Presotto wrote:
>
> Because ipquery starts and an ipaddress and looks through the database looking
> for attributes bound to that address, then to the subnet containing that address,
> then the subnet containing that subnet, ad nauseam looking for the attributes.
>
> There is no ip address corresponding to an authdom, like outside.plan9.bell-labs.com.
>
Oh, OK!  I guess the name says it all, once you know what to look for.

> I'll answer about sshnet as soon as I look at a man page to see what it
> is.

Let me be less cryptic, while I have a chance.

My office is linked to the Internet via a convoluted path of private
networks, with a remote host that I can connect to using SSH.

I establish a "tunnel" to that host quite happily using sshnet, which
installs a stripped copy of /net.

The command

	srv sources.cs.bell-labs.com sources /n/sources

returns the reassuring "post..." and, in the absence of a factotum
key, prompts me for the proxima/......... which I use to authenticate.

Sadly, it seems to me that factotum attempts to connect directly to
sources.cs.bell-labs.com, according to tcpdump run on the remote
host.  The diagnostic output from factotum indicates the expected
timeout caused by the various filters in the path.

If I spawn a new factotum (it really needs an option to be removable,
by the way), I believe it fails to identify/resolve the auth server
associated with the auth domain.  I have no idea quite how to take
care of that problem.  Ideally, I'd create a /net/ndb entry, but
that's not possible with sshnet serving /net.

++L

Re: [9fans] ndb/csquery: what is dns is not up?

[David Presotto]

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

God that message was terrible.  I meant to say:

1) have sshnet support a /net/ndb and set it up the usual way.
2) have sshnet's simulated cs, first search /net/ndb when resolving queries.

That would make it a lot more useful.

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

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ndb/csquery: what is dns is not up?
Date: Wed, 23 Apr 2003 15:16:25 +0200
Message-ID: <20030423151624.M19261@cackle.proxima.alt.za>

On Wed, Apr 23, 2003 at 08:59:48AM -0400, David Presotto wrote:
>
> Because ipquery starts and an ipaddress and looks through the database looking
> for attributes bound to that address, then to the subnet containing that address,
> then the subnet containing that subnet, ad nauseam looking for the attributes.
>
> There is no ip address corresponding to an authdom, like outside.plan9.bell-labs.com.
>
Oh, OK!  I guess the name says it all, once you know what to look for.

> I'll answer about sshnet as soon as I look at a man page to see what it
> is.

Let me be less cryptic, while I have a chance.

My office is linked to the Internet via a convoluted path of private
networks, with a remote host that I can connect to using SSH.

I establish a "tunnel" to that host quite happily using sshnet, which
installs a stripped copy of /net.

The command

	srv sources.cs.bell-labs.com sources /n/sources

returns the reassuring "post..." and, in the absence of a factotum
key, prompts me for the proxima/......... which I use to authenticate.

Sadly, it seems to me that factotum attempts to connect directly to
sources.cs.bell-labs.com, according to tcpdump run on the remote
host.  The diagnostic output from factotum indicates the expected
timeout caused by the various filters in the path.

If I spawn a new factotum (it really needs an option to be removable,
by the way), I believe it fails to identify/resolve the auth server
associated with the auth domain.  I have no idea quite how to take
care of that problem.  Ideally, I'd create a /net/ndb entry, but
that's not possible with sshnet serving /net.

++L

Re: [9fans] ndb/csquery: what is dns is not up?

[Lucio De Re]

On Wed, Apr 23, 2003 at 03:16:25PM +0200, Lucio De Re wrote:
>
> Sadly, it seems to me that factotum attempts to connect directly to
> sources.cs.bell-labs.com, according to tcpdump run on the remote
> host.  The diagnostic output from factotum indicates the expected
> timeout caused by the various filters in the path.
>
Nopes, I stand corrected.  This is what eventually pops out (I fear
it's not the most recent version of factotum):

21: failure cs: can't translate address
21: write 141 in phase CNeedTreq yields phase CNeedTreq: failure cs: can't translate address
21: write 141 in phase CRelay yields phase CRelay: failure cs: can't translate address

I don't know what address is involved, not what resolver service
is being invoked.  I also assumed that factotum itself did not
communicate with the remote authenticator, but that it delegated
all communication to the client or server!  This does not seem to
be the case here.

> If I spawn a new factotum (it really needs an option to be removable,
> by the way), I believe it fails to identify/resolve the auth server
> associated with the auth domain.  I have no idea quite how to take
> care of that problem.  Ideally, I'd create a /net/ndb entry, but
> that's not possible with sshnet serving /net.
>
I don't want to do this right now, as spawning a new factotum tends
to mess the namespace up enough for me to prefer to reboot.  The
alternative workstation I can use for testing is more or less a
pristine installation and I don't know how much the absence of
sensible configuration information actually cripples networking.

++L

Re: [9fans] ndb/csquery: what is dns is not up?

[Lucio De Re]

On Wed, Apr 23, 2003 at 09:17:10AM -0400, David Presotto wrote:
>
> 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.

At least you confirmed what I suspected.  I guess I can try to add a
feature or two to sshnet and factotum so that this becomes possible.

That leaves me wondering how I got to interpret the factotum docs as
suggesting that factotum itself did not do its own communications.
I'll have to re-read the documentation.

++L

Re: [9fans] ndb/csquery: what is dns is not up?

[Lucio De Re]

On Wed, Apr 23, 2003 at 09:20:06AM -0400, David Presotto wrote:
>
> Your message suggests a better solution than mine.  Just change sshnet to allow
> also implement /net/ndb and have sshnet's simulated /net search that first.  It
> would make it a lot more useful.  I don't have time right now, but perhaps you
> do?

Lack of self-confidence is a bigger problem, but I will look into it.
I suppose just copying the original /net/ndb would be a step forward.
Making it editable would be nice.

A new factotum becomes a necessity, I think I'll need an option to
kill it, then, maybe a control command that the first factotum does
not respond to?

++L

Re: [9fans] ndb/csquery: what is dns is not up?

[Russ Cox]

sshnet's simulated /net/cs should pass
queries through to the real /net/cs when
it can't answer them.

that will solve the auth problem.

you still need to start a second factotum
to get it to use the ssh network.

starting a new factotum should not
mess up your computer enough to require
a reboot.  if you just delete the window you
started the new factotum in, it's gone.

and even if you don't delete the window,
it's not present in the other windows.

Re: [9fans] ndb/csquery: what is dns is not up?

[Geoff Collyer]

I think starting a second factotum steps on /srv/factotum unless you
start the second one with -s and a unique service name.

Re: [9fans] ndb/csquery: what is dns is not up?

[Russ Cox]

> I think starting a second factotum steps on /srv/factotum unless you
> start the second one with -s and a unique service name.

That may have been true very early on,
but it's definitely not true now (I'm not sure
it ever was).  I run new factotums all the
time.  The default is not to post.  The system
factotum is run by /boot/boot as

	factotum -S -sfactotum

I start new factotums all the time.  It doesn't
break anything on my systems.

Russ