[9fans] Plan9 terminal configuration

[9fans] Plan9 terminal configuration

[Matthew Haas]

Good morning,

 Having a couple problems getting our Plan9 terminals up and running.
We've got our authentication/cpu server and fileserver up and running and
supposedly are talking to each other.

 We're trying to boot the terminals, and boot from network (il), we enter
the appropriate IPs of the servers. However, when it comes to
authenticating the user, we enter the user & password of an account we
have setup (incidentally, the same account we've set up on both the auth
and fileserver).. however there seems to be some authentication issues
taking place, and we cannot get past this prompt.

 Any common symptoms to this problem?

 Is the /rc/bin/termrc file coming into use at this point? Or is that
called on after logging in?

 We've run the "snoopy" and "sniffer" utilities, and have verified that
the terminal is in fact contacting the auth server when we try to login.

 I've been reading through the list archives, but haven't found anything
yet (starting at the beginning, reading through current).. and there do
not seem to be any Wiki pages on terminal configuration.

 Thanks in advance for any pointers.

---
 Matthew Haas           Squirrel's Law #209203923: "Thou shalt ignoreth
 Corning/Geneseo, NY       all RAM specifications, they're noo scottish"

Re: [9fans] Plan9 terminal configuration

[andrey mirtchovski]

The problematic ones usually are your dom= and authdom= entries in /lib/ndb/local..

here's a solution to a problem similar to yours (this one involves a
vmware cpu/auth/kfs server and drawterm, but if you cpu to the machine using
drawterm you should be able to boot from it using il)..


the problem with connecting to it seems to be the fact that /net/ndb (cat
this file to see your settings) thinks that dom=.localdomain instead of
'dom=p9' as it should be in my case. doing a:

        echo 'dom=p9' > /net/ndb

fixes this.

if you try to connect with drawterm and get a 'no match' response that
means your passwords are not matching. if you know you're typing it correctly
then switch to the server and type 'auth/changeuse [user]' to reset the password
for the 'user' you're trying to log in as.

'bad key' or a similar response means that the 'dom='s are screwed.

and here's the modified /lib/ndb/local --

#
#  files comprising the database, use as many as you like, see ndb(6)
#
database=
	file=/lib/ndb/local
	file=/lib/ndb/common

ipnet=mynet ip=192.168.0.0 ipmask=255.255.0.0
	auth=p9
	dom=p9
	authdom=p9
	proto=il
	cpu=p9
	fs=p9

ip=192.168.125.128
	sys=p9
	dom=p9

auth=sources.cs.bell-labs.com authdom=outside.plan9.bell-labs.com

there is a chance that i'm doing things wrong, but this has been working for
a few days now..

andrey


On Thu, 3 Apr 2003, Matthew Haas wrote:

> Good morning,
>
>  Having a couple problems getting our Plan9 terminals up and running.
> We've got our authentication/cpu server and fileserver up and running and
> supposedly are talking to each other.
>
>  We're trying to boot the terminals, and boot from network (il), we enter
> the appropriate IPs of the servers. However, when it comes to
> authenticating the user, we enter the user & password of an account we
> have setup (incidentally, the same account we've set up on both the auth
> and fileserver).. however there seems to be some authentication issues
> taking place, and we cannot get past this prompt.
>
>  Any common symptoms to this problem?
>
>  Is the /rc/bin/termrc file coming into use at this point? Or is that
> called on after logging in?
>
>  We've run the "snoopy" and "sniffer" utilities, and have verified that
> the terminal is in fact contacting the auth server when we try to login.
>
>  I've been reading through the list archives, but haven't found anything
> yet (starting at the beginning, reading through current).. and there do
> not seem to be any Wiki pages on terminal configuration.
>
>  Thanks in advance for any pointers.
>
> ---
>  Matthew Haas           Squirrel's Law #209203923: "Thou shalt ignoreth
>  Corning/Geneseo, NY       all RAM specifications, they're noo scottish"
>