[9fans] my plan9 server isn't responding

[9fans] my plan9 server isn't responding

[Ezequiel Aragon]

Hi group, I need help configuring a plan9 server (auth+dns+dhcp+fs).

I already have a plan9 system with /lib/ndb/local, /cfg/$sysname/cpurc
configured as per the wiki and other net sources. I compiled the
pccpuf kernel with no problems and declared it at /n/9fat/plan9.ini,
and I am able to boot the new system ok. I use ndb/ipquery, ndb/cs and
ndb/dnsquery to test that my server is well configured and all of them
give expected results. Then, I instaled another plan9 system (a
terminal) and told it to use dhcp with ip/ipconfig. I can see the
right ip given to it by the server in /net/ipselftab, but:

1) I can not resolv any name from my terminal, even though my server's
ndb database has declared a subnet with an default dns entry.
2) I can not authenticate to the server with any user from my terminal
system even though I can see the attempted conecction in the fossil
console.

I have to machines declared in ndb/local, akenaton ip 10.0.0.2 and
nefertiti ip 10.0.0.3, I can't say things like:
9fs akenaton
or
cpu -h akenaton
or even
ip/ping -n 4 akenaton

as the terminal system (nefertiti) don't know the dns.
Is is not supposed dhcp will feed nefertiti not only with an ip but
also dns an auth information?

What is missing in my configuration? Any clues?
If someone needs more information about any of my conf. files, please
tell me.
thanks in advance

Re: [9fans] my plan9 server isn't responding

[Richard Miller]

> 1) I can not resolv any name from my terminal, even though my server's
> ndb database has declared a subnet with an default dns entry.

Does 'cat /net/ndb' on the terminal show a 'dns=' entry?

> 2) I can not authenticate to the server with any user from my terminal
> system even though I can see the attempted conecction in the fossil
> console.

Running the auth/debug command on the terminal may reveal a clue.

Re: [9fans] my plan9 server isn't responding

[Ezequiel Aragon]

On Mar 30, 5:35 am, 9f...@hamnavoe.com (Richard Miller) wrote:
> > 1) I can not resolv any name from my terminal, even though my server's
> > ndb database has declared a subnet with an default dns entry.
>
> Does 'cat /net/ndb' on the terminal show a 'dns=' entry?
>

this is the info cat /net/ndb gives at the terminal

ip=10.0.0.3 ipmask=255.255.255.0 ipwg::
    sys=nefertiti
    dom=nefertiti.amarna.net
    fs=10.0.0.2
    auth=10.0.0.2
    dns=10.0.0.2

So, save for the ipwg, everything seems ok. The server akenaton as
ip=10.0.0.2 and it's ndb database has declared all these services.
Why then, isn't dns working?
I made a ps at the server and all services are running: dns -sr,
dhcpd, secstored, auth, etc.

> > 2) I can not authenticate to the server with any user from my terminal
> > system even though I can see the attempted conecction in the fossil
> > console.
>
> Running the auth/debug command on the terminal may reveal a clue.

I will try that

Re: [9fans] my plan9 server isn't responding

[erik quanstrom]

> So, save for the ipwg, everything seems ok. The server akenaton as

that could be your problem.  there's no route out.

- erik

Re: [9fans] my plan9 server isn't responding

[Richard Miller]

>> So, save for the ipwg, everything seems ok. The server akenaton as
>
> that could be your problem.  there's no route out.
>
> - erik

But that's not relevant when trying to reach machines
on the same subnet:

> I have to machines declared in ndb/local, akenaton ip 10.0.0.2 and
> nefertiti ip 10.0.0.3, I can't say things like:
> 9fs akenaton
> or
> cpu -h akenaton
> or even
> ip/ping -n 4 akenaton

I think the real problem is trying to resolve unqualified names without
a 'dnsdomain' defined -- see ndb(6)

Re: [9fans] my plan9 server isn't responding

[Ezequiel Aragon]

On Mar 30, 12:19 pm, 9f...@hamnavoe.com (Richard Miller) wrote:
> >> So, save for the ipwg, everything seems ok. The server akenaton as
>
> > that could be your problem.  there's no route out.
>
> > - erik
>
> But that's not relevant when trying to reach machines
> on the same subnet:
>
> > I have to machines declared in ndb/local, akenaton ip 10.0.0.2 and
> > nefertiti ip 10.0.0.3, I can't say things like:
> > 9fs akenaton
> > or
> > cpu -h akenaton
> > or even
> > ip/ping -n 4 akenaton
>
> I think the real problem is trying to resolve unqualified names without
> a 'dnsdomain' defined -- see ndb(6)

I have dnsdomain declared in my server's ndb file, should I declared
it as well in my terminal's ndb file? How much minimal info should I
have in my terminal file if I am using dhcp to fetch information to it?

Re: [9fans] my plan9 server isn't responding

[Ezequiel Aragon]

>
> I think the real problem is trying to resolve unqualified names without
> a 'dnsdomain' defined -- see ndb(6)

I tried with:

ip/ping akenaton.amarna.net

and yes, it works with a qualified name for the server. So that seems
to be the problem with dns. I then tried the line:

dnsdomain=amarna.net

in my terminal's ndb file, but it keeps failing with unqualified
names. I shoud I configure it for it to resolv unqualified names in my
terminal?

And on the auth problem: this is what the fossil cons reports when I
try:

9fs akenaton.amarna.net

attach main as glenda: phase error protocol phase error: read in state
SNeedTicket

in the terminal, the error shows a different message:

srv net!akenaton.amarna.net!9fs mount failed: fossil authCheck: auth
protocol not finished

then, I do:

auth/debug

and this is the output:

p9sk1 key: proto p9sk1 dom=amarna.net user=ezequiel !passwd?
    dialing up auth server net!akenaton!ticket
    cannot dial auth server: cs: can't translate address: dns:
resource does not exist; negrcode
    csquery authdom=amarna.net auth=akenaton

It seems to me that the whole error has something to do with the dns
not being able to resolv an unqualified name (akenaton) for the auth
process.
By the way, I am trying to connect as ezequiel with 9fs (the user
exists in the server) though I am logged as glenda in the terminal.

Re: [9fans] my plan9 server isn't responding

[Richard Miller]

> I then tried the line:
>
> dnsdomain=amarna.net
>
> in my terminal's ndb file, but it keeps failing with unqualified
> names.

You need something more like this:

ipnet=localnet ip=10.0.0.0 ipmask=255.255.255.0
	dnsdomain=amarna.net

> By the way, I am trying to connect as ezequiel with 9fs (the user
> exists in the server) though I am logged as glenda in the terminal.

I expect you have a p9sk1 password for user=ezequiel in your factotum
on the terminal.

Re: [9fans] my plan9 server isn't responding

[Ezequiel Aragon]

On Apr 2, 6:58 am, 9f...@hamnavoe.com (Richard Miller) wrote:
> > I then tried the line:
>
> > dnsdomain=amarna.net
>
> > in my terminal's ndb file, but it keeps failing with unqualified
> > names.
>
> You need something more like this:
>
> ipnet=localnet ip=10.0.0.0 ipmask=255.255.255.0
>         dnsdomain=amarna.net
>
> > By the way, I am trying to connect as ezequiel with 9fs (the user
> > exists in the server) though I am logged as glenda in the terminal.
>
> I expect you have a p9sk1 password for user=ezequiel in your factotum
> on the terminal.

I do have a p9sk1 key.

I think I have isolated the problem.
I configured my server ndb file with auth and fs using the server
fully qualified name.
As a result, now, my terminal ndb info looks more promising:

cat /net/ndb
  sys=nefertiti
  dom=nefertiti.amarna.net
  fs=10.0.0.2
  auth=10.0.0.2
  dns=10.0.0.2

But I can't yet connect to my server using 9fs, I try:

9fs akenaton.amarna.net

And it fails, I then look for debug info and notice the error:

net!akenaton!ticket      dns can't find this

of course, dns can not find akenaton alone. I try some test with cs:

ndb/csquery
> net!akenaton!ticket
   and it give the same error, so cs can't get the info from the 'url'
as dns fails
I then try:

> net!akenaton.amarna.net!ticket
or
> net!akenaton.amarna.net!9fs

And I get proper answers with these.

Why is cs using akenaton instead of akenaton.amarna.net, if I don't
have akenaton alone defined anywhere in the server ndb?
Is there a way to cope with this or to configure dns to solve
unqualified names somehow?

Re: [9fans] my plan9 server isn't responding

[erik quanstrom]

> I think I have isolated the problem.
> I configured my server ndb file with auth and fs using the server
> fully qualified name.
> As a result, now, my terminal ndb info looks more promising:
>
> cat /net/ndb
>   sys=nefertiti
>   dom=nefertiti.amarna.net
>   fs=10.0.0.2
>   auth=10.0.0.2
>   dns=10.0.0.2
>
> But I can't yet connect to my server using 9fs, I try:
>
> 9fs akenaton.amarna.net
>
> And it fails, I then look for debug info and notice the error:
>
> net!akenaton!ticket      dns can't find this

there are two ways you can get a short name to work
- use a sys=xyz entry.  if you also want to use dns to
reach this node it would be conventional to have sys=xyz dom=xyz.dom.

- having a proper ipnet to guide the terminal in selecting
a default dns domain.  i think at the minimum.  please see
/lib/ndb/local.complicated.  (although the ipnet there does
defined some unused-by-the-distribution keywords.)


- erik

Re: [9fans] my plan9 server isn't responding

[Ezequiel Aragon]

> there are two ways you can get a short name to work
> - use a sys=xyz entry.  if you also want to use dns to
> reach this node it would be conventional to have sys=xyz dom=xyz.dom.

That was the first thing I did. My tipical entry en ndb looks like:

ip=10.0.0.2 ether=jhgsfs7sfs788 sys=akenaton dom=akenaton.amarna.net
ip=10.0.0.3 ether=jhgsfs45dfdff1 sys=nefertiti
dom=nefertiti.amarna.net

And still doesn;t work for short names.
I even tried something like:

dom=amarna.net soa=
    refresh=3600 ttl=3600
    ns=10.0.0.2
    cname=akenaton.amarna.net dom=akenaton
    cname=nefertiti.amarna.net dom=nefertiti

To see if using an alias (cname) in the dom info solved the case, but
there is no way the server can solve short names for the terminal

I tried at the terminal:

ndb/dnsquery
> akenaton
!dns: resource does not exist; negrcode 0
> akenaton.amarna.net
akenaton.amarna.net ip 10.0.0.2

See? It seems everything is well configured, but still no short name
resolution.
What puzzles me more is, the same dnsquery used at the server give
identical good results for both the short and large names:

ndb/dnsquery
> akenaton
akenaton.amarna.net ip 10.0.0.2
> akenaton.amarna.net
akenaton.amarna.net ip 10.0.0.2

Re: [9fans] my plan9 server isn't responding

[erik quanstrom]

On Mon Apr  2 10:31:33 EDT 2012, aragonezequiel@gmail.com wrote:
> 
> > there are two ways you can get a short name to work
> > - use a sys=xyz entry.  if you also want to use dns to
> > reach this node it would be conventional to have sys=xyz dom=xyz.dom.
> 
> That was the first thing I did. My tipical entry en ndb looks like:
> 
> ip=10.0.0.2 ether=jhgsfs7sfs788 sys=akenaton dom=akenaton.amarna.net
> ip=10.0.0.3 ether=jhgsfs45dfdff1 sys=nefertiti
> dom=nefertiti.amarna.net
> 
> And still doesn;t work for short names.
> I even tried something like:

i hope those are real eathernet addresses, and not as you present.
there should be no security concern with revealing your ethernet addresses.
they're useless unless you happen to be on the same segment.

> To see if using an alias (cname) in the dom info solved the case, but
> there is no way the server can solve short names for the terminal

please try making a valid ipnet.  that's where the default dns domain
comes from.

- erik

Re: [9fans] my plan9 server isn't responding

[Richard Miller]

> See? It seems everything is well configured, but still no short name
> resolution.
> What puzzles me more is, the same dnsquery used at the server give
> identical good results for both the short and large names:

Do you have in /lib/ndb/local on the terminal as I suggested:

ipnet=localnet ip=10.0.0.0 ipmask=255.255.255.0
	dnsdomain=amarna.net

You can also try

echo '  dnsdomain=amarna.net' >>/net/ndb

Re: [9fans] my plan9 server isn't responding

[Ezequiel Aragon]

On Apr 2, 10:35 am, 9f...@hamnavoe.com (Richard Miller) wrote:
> > See? It seems everything is well configured, but still no short name
> > resolution.
> > What puzzles me more is, the same dnsquery used at the server give
> > identical good results for both the short and large names:
>
> Do you have in /lib/ndb/local on the terminal as I suggested:
>
> ipnet=localnet ip=10.0.0.0 ipmask=255.255.255.0
>         dnsdomain=amarna.net
>
> You can also try
>
> echo '  dnsdomain=amarna.net' >>/net/ndb

this is what my terminal /net/ndb looks like:

ip=10.0.0.1 ipmask=255.255.255.0 ipgw=10.0.0.1
    sys=nefertiti
    dom=nefertiti.amarna.net
    fs=10.0.0.2
    auth=10.0.0.2
    dns=10.0.0.2

So far so good but still, no dnsdomain info, I do have it defined as
part of my subnet info in the server ndb file.
This is my server ndb file:

database=
   file=/lib/ndb/local
   file=/lib/ndb/common
   file=/lib/ndb/auth

ipnet=mynet ip=10.0.0.0 ipmask=255.255.255.0
    ipgw=10.0.0.1
    dns=10.0.0.2
    dnsdomain=amarna.net
    auth=akenaton.amarna.net authdomain=amarna.net
    cpu=akenaton.amarna.net
    fs=akenaton.amarna.net

sys=localhost
    dom=localhost
    ip=127.0.0.1

sys=akenaton
    dom=akenaton.amarna.net
    ip=10.0.0.2 ether=525400a4f5a7

sys=nefertiti
    dom=nefertiti.amarna.net
    ip=10.0.0.3 ether=525400f727b1

Why isn't dnsdomain fetched with the rest of the info to the terminal?

I tried with echo '    dnsdomain=amarna.net' >> /net/ndb as you sugest
and it adds dnsdomain info
to my terminal /net/ndb, ok.

I then try:

ndb/csquery
> akenaton
akenaton.amarna.net ip 10.0.0.2

it works!! but then, I try again:

9fs akenaton

and it fails, and this time, debug info shows:

auth/debug
p9sk1 key: proto=p9sk1 dom=amarna.net user=ezequiel !passwod?
   cannot dial auth server: no auth server found for amarna.net
   csquery authdom=amarna.net auth=* failed
   csquery dom=amarna.net auth=*
   dia net!$auth!ticket succeeded

Re: [9fans] my plan9 server isn't responding

[Charles Forsyth]

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

/net/ndb is for the bootstrap data returned by (say) DHCP, enough to find
/lib/ndb and other resources and get going. it isn't a cache for ndb data.


On 3 April 2012 09:38, Ezequiel Aragon <aragonezequiel@gmail.com> wrote:

> Why isn't dnsdomain fetched with the rest of the info to the terminal?

[-- Attachment #2: Type: text/html, Size: 575 bytes --]

Re: [9fans] my plan9 server isn't responding

[Lucio De Re]

>     auth=akenaton.amarna.net authdomain=amarna.net

"authdom" not "authdomain".  Not a very forgiving database format.

++L

Re: [9fans] my plan9 server isn't responding

[erik quanstrom]

> "authdom" not "authdomain".  Not a very forgiving database format.

/n/sources/contrib/quanstro/root/sys/src/cmd/ndb/vrfy.y
/n/sources/contrib/quanstro/root/sys/man/10/ndbvrfy

this program might be a useful bit in sorting out your ndb file.

- erik

Re: [9fans] my plan9 server isn't responding

[Anthony Sorace]

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

On Apr 3, 2012, at 4:38 , Ezequiel Aragon wrote:

> ipnet=mynet ip=10.0.0.0 ipmask=255.255.255.0
>    ipgw=10.0.0.1
>    dns=10.0.0.2
>    dnsdomain=amarna.net
>    auth=akenaton.amarna.net authdomain=amarna.net
>    cpu=akenaton.amarna.net
>    fs=akenaton.amarna.net


This is unusual, at the least. Typically, you have something like:

authdom=mydomain.com auth=whatever.mydomain.com

in its own stanza. It's not clear to me the binding will pick it up the
way you have it. Certainly all the examples in /lib/ndb/common
are built that way. That's on top of Lucio's observation about it
being authdom, not authdomain.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 210 bytes --]

Re: [9fans] my plan9 server isn't responding

[Lucio De Re]

> This is unusual, at the least. Typically, you have something like:
>
> authdom=mydomain.com auth=whatever.mydomain.com
>
> in its own stanza.

It works for me where I have a few different sites with distinct auth
servers and, to be safe, auth domains.  And though this may be just
luck, it follows the principle of least surprise.

++L

Re: [9fans] my plan9 server isn't responding

[Ezequiel Aragon]

I have made (thanks to all of you) progress with my configuration.
I thought the only problem to solve was the dns solving short names,
but I am still unable to connect using plan9.

I try:

9fs akenaton /n/akenaton

and get the error:

srv net!akenaton!9fs: mount failed: fossil authCheck: auth protocol
not finished

Here is whate auth/debug says:

p9sk1 key: proto=p9sk1 dom=amarna.net user=ezequiel !passwd?
    cannot dial auth server: no auth server found for amarna.net
    csquery authdom=amarna.net auth=* failed
    csquery dom=amarna.net auth=*
    dial net!$auth!ticket succeeded

And here is what I get in the server's fossil console:

attach main as glenda: phase error protocol phase error: read in state
SNeedTicket

I can see a /srv/akenaton created, but the second step (mount on /n/
akenaton) of the srv process fails

Re: [9fans] my plan9 server isn't responding

[Lucio De Re]

> So, save for the ipwg, everything seems ok. The server akenaton as
> ip=10.0.0.2 and it's ndb database has declared all these services.
> Why then, isn't dns working?

I had to use an IP number in the ipgw pair in the ipnet to force it to appear in /net/ndb.  I'm not sure whether this is expected but undocumented bahaviour or a bug, but a domain name didn't cut it.  I'd be curious to know.

Of course, this need not have anything to do with your problem.

++L

Re: [9fans] my plan9 server isn't responding

[Lyndon Nerenberg]

On 2012-03-30, at 6:56 AM, Lucio De Re wrote:

> I had to use an IP number in the ipgw pair in the ipnet to force it to appear in /net/ndb.  I'm not sure whether this is expected but undocumented bahaviour or a bug, but a domain name didn't cut it.  I'd be curious to know.

A hostname can map to many IP addresses, so in situations like this you need to list the specific IP address. (I don't know if ndb explicitly ignores hostnames here, but it's a general rule in networking configurations that gateway interfaces must be specified by address to avoid ambiguity.)

Re: [9fans] my plan9 server isn't responding

[Ezequiel Aragon]

> > 2) I can not authenticate to the server with any user from my terminal
> > system even though I can see the attempted conecction in the fossil
> > console.
>
> Running the auth/debug command on the terminal may reveal a clue.

I ran auth/debug, this is what it tells:

no p9sk1 keys found in factotum

Re: [9fans] my plan9 server isn't responding

[Richard Miller]

> no p9sk1 keys found in factotum

So, put one in and try again.

auth/factotum -g 'proto=p9sk1 user=xxxx dom=yyyy !password?'

where xxxx and yyyy are your username and authdom

Re: [9fans] my plan9 server isn't responding

[Ezequiel Aragon]

On Mar 30, 9:38 am, quans...@quanstro.net (erik quanstrom) wrote:
> > So, save for the ipwg, everything seems ok. The server akenaton as
>
> that could be your problem.  there's no route out.
>
> - erik

I have ipwg delcared in my server's ndb file, but still it does not
show up in cat /netndb in my terminal, It is the only parameter not
fetched from dhcp and I don't know why.
Anyways, I am just trying to use services exported by may server to a
terminal in the same subnet.

Re: [9fans] my plan9 server isn't responding

[Richard Miller]

> I have ipwg delcared in my server's ndb file

s/ipwg/ipgw/

Is it spelled correctly in server's /lib/ndb/local?

Re: [9fans] my plan9 server isn't responding

[Lucio De Re]

>> I have ipwg delcared in my server's ndb file
>
> s/ipwg/ipgw/
>
> Is it spelled correctly in server's /lib/ndb/local?

...  and is it really necessary for the terminal to have its own ndb
file?  At best, it's redundant, at worst, conflicting.

++L

Re: [9fans] my plan9 server isn't responding

[Richard Miller]

> ...  and is it really necessary for the terminal to have its own ndb
> file?  At best, it's redundant, at worst, conflicting.

Simplest practice is for the terminal to get its root file system from
the server, so they are sharing /lib/ndb/local.  If the terminal has
its own root, it needs its own ndb file because not everything is
exported via dhcp -- dnsdomain for example, and authdom/auth associations
for external systems.