Problems that I'm having...

Problems that I'm having...

[G.David]

Kenji Okamoto <okamoto@earth.cias.osakafu-u.ac.jp> writes:
>David Butler <gdb@dbsystems.com> writes:
>> I start the terminal and login as me (gdb) with a password.  There is a
>> sucessful entry in /sys/log/auth.  In the 81/2 window I type cpu and get:
>> 
>> cpu: can't authenticate: auth: AS protocol botch

>In my case, I got

>cpu: can't authenticate: rhyolite(aka your auth): can't connect to AS

>(my situation is different from you, though).

>I know this comes from fail in the authlibrary (authdial()), however,
>I don't know why.....  I need more exersize on Plan 9.   ^_^

I think I had that problem before I entered the authid and password
with auth/changeuser.  Just because you can boot the auth server does
*not* mean that the authid password has been set in /adm/keys.  Chech
that you have a /mnt/keys/authid entry on the auth server.  (Where
authid is the id you input on your file and auth servers, e.g. bootes.)
You have to look on the auth server itself to determine this.  (I love
local namespaces!)

>Kenji

As for my problem, I solved it... in /lib/ndb/local I had:

	il=ticket  port=556

It should be:

	il=ticket  port=566

Sometimes I think that touch typing has its problems.  cpu now works
correctly.  That "protocol botch" message is *real* helpful though!? :-)

Problems that I'm having...

[G.David]

>> As for my problem, I solved it... in /lib/ndb/local I had:
>> 
>> 	il=ticket  port=556
>> 
>> It should be:
>> 
>> 	il=ticket  port=566
>> 
>> Sometimes I think that touch typing has its problems.  cpu now works
>> correctly.  That "protocol botch" message is *real* helpful though!? :-)
>
>I didn't have had this entry.   Then, I added this line in my 
>/lib/ndb/local.  Yes, now I can get cpu server from my terminal.
>How did you know this entry is neccessary.
>
>Kenji

This came from the errata page on plan9.att.com.

db

Problems that I'm having...

[Steve]

Kenji Okamoto <okamoto@earth.cias.osakafu-u.ac.jp> wrote:
> > As for my problem, I solved it... in /lib/ndb/local I had:
> > 	il=ticket  port=556
> > It should be:
> > 	il=ticket  port=566
> 
> I didn't have had this entry.   Then, I added this line in my 
> /lib/ndb/local.  Yes, now I can get cpu server from my terminal.
> How did you know this entry is neccessary.

It is documented in http://plan9.att.com/plan9/errata.html as follows:

/lib/ndb/local

The port for the ticket service is missing.  This will keep authentication
from working if you install from the CD.
Add the line:

il=ticket port=566

It is correct on the diskettes.

Problems that I'm having...

[Kenji]

> I think I had that problem before I entered the authid and password
> with auth/changeuser.  Just because you can boot the auth server does
> *not* mean that the authid password has been set in /adm/keys. 
 Chech
> that you have a /mnt/keys/authid entry on the auth server.

Yes, I have these entries in my CPU server.

> As for my problem, I solved it... in /lib/ndb/local I had:
> 
> 	il=ticket  port=556
> 
> It should be:
> 
> 	il=ticket  port=566
> 
> Sometimes I think that touch typing has its problems.  cpu now works
> correctly.  That "protocol botch" message is *real* helpful though!? :-)

I didn't have had this entry.   Then, I added this line in my 
/lib/ndb/local.  Yes, now I can get cpu server from my terminal.
How did you know this entry is neccessary.

Kenji

Problems that I'm having...

[Kenji]

> I start the terminal and login as me (gdb) with a password.  There is a
> sucessful entry in /sys/log/auth.  In the 81/2 window I type cpu and get:
> 
> cpu: can't authenticate: auth: AS protocol botch

In my case, I got

cpu: can't authenticate: rhyolite(aka your auth): can't connect to AS

(my situation is different from you, though).

I know this comes from fail in the authlibrary (authdial()), however,
I don't know why.....  I need more exersize on Plan 9.   ^_^

Kenji

Problems that I'm having...

[G.David]

Steve Kotsopoulos <steve@ecf.toronto.edu> wrote:
>"G. David Butler" <gdb@dbSystems.com> wrote:

>> About the diffs in errata and the update directory.  Which should
>> we use?  How do we know if there are new ones?
>> 
>> What is a boddle and what is it good for?
>
>The update area seems to have subsumed the errata area.
>They basically have the same purpose, but the boodles (bundle of diffs -
>think of them as the plan9 equivalent to 'patch' under unix)
>in the update area are easier to apply than the diffs in the errata directory.

Yes they are easier, but the latest changes in errata have not make it to
update.

forsyth@plan9.cs.york.ac.uk wrote:
>"G. David Butler" <gdb@dbSystems.com> wrote:

>>/lib/ndb/local file to set up my network.  (It is weird that
>>/lib/ndb/auth has hostid=authid instead of hostid=p9auth, but that is
>>what the installation did, so...)  I also tarred /usr/tor to /usr/none

>hostid should be the authentication USER name, not the name of
>a machine.  it sounds as though you answered `authid' to the
>request `Enter the site authentication user id' (`Example: bootes').
>if so, the installation did the right thing, rather than something
>weird, but you've undone that, and put it into a strange state.
>that might explain the subsequent problems with authentication.
>change it back to authid.  see the end of auth(6) `Data Base'
>for details on /lib/ndb/auth.

I have followed all the advise so far, I have applied all the updates
and errata diffs and I have run mk install in /sys/src (all of this is done
on the console of my cpu server.)

I'm still having the same problem, so I will provide as much information
as possible.

My file server is named bootes.dbSystems.com. (486DX/50, SCSI, WD8003)
My authid is bootes.
My cpu server is named auth.dbSystems.com. (486DX2/66, SCSI, WD8003)
My terminal is named term.dbSystems.com. (386DX/20, no hd, WD8003)
I have done auth/changekey for bootes and gdb

I start the terminal and login as me (gdb) with a password.  There is a
sucessful entry in /sys/log/auth.  In the 81/2 window I type cpu and get:

cpu: can't authenticate: auth: AS protocol botch

I get the same thing on the cpu server at the auth% prompt with cpu -h auth
I also get the the same thing if I telnet to auth, login as none and do
cpu -h auth.  It is at least consistent!  There are no entries added to
/sys/log/auth for any of these.

I have looked at the source and the number of places where that message
can be returned is amazing!

I would really appreciate any help with this.

Thanks in advance.

David Butler
gdb@dbSystems.com

Here is my /lib/ndb/auth file:

hostid=bootes
	uid=!sys uid=!adm uid=*

Here is my /adm/users file:

-1:adm:adm:bootes
0:none::bootes
1:gdb:gdb:
10000:sys::bootes
10001:map:map:
10002:doc::bootes
10003:upas:upas:
10004:font::
10005:bootes:bootes:

and finally my /lib/ndb/local file:

#
# systems on the local network
#
dom=
	ns=ns.dbsystems.com
dom=ns.dbsystems.com ip=204.181.117.1

#INSTALL this network
ipnet=network ip=204.181.117.0 ipmask=255.255.255.0
	ipgw=204.181.117.1
	fs=bootes.dbsystems.com
	auth=auth.dbsystems.com
#END

#INSTALL authserver
ip=204.181.117.5 ether=0000c0b20722 sys=auth
	dom=auth.dbsystems.com
	bootf=/386/9pccpudisk
	proto=il
#END

#INSTALL fileserver
ip=204.181.117.10 ether=0000c0891e1c sys=bootes
	dom=bootes.dbsystems.com
	proto=il
#END

ip=204.181.117.6 ether=0000c06dd28b sys=term
	dom=term.dbsystems.com
	bootf=/386/9pc
	proto=il

#
#  tcp services
#
tcp=cs		port=1
tcp=echo	port=7
tcp=discard	port=9
tcp=systat	port=11
tcp=daytime	port=13
tcp=netstat	port=15
tcp=ftp-data	port=20
tcp=ftp		port=21
tcp=telnet	port=23
tcp=smtp	port=25
tcp=time	port=37
tcp=whois	port=43
tcp=domain	port=53
tcp=uucp	port=64
tcp=rje		port=77
tcp=finger	port=79
tcp=link	port=87
tcp=supdup	port=95
tcp=hostnames	port=101
tcp=iso-tsap	port=102
tcp=x400	port=103
tcp=x400-snd	port=104
tcp=csnet-ns	port=105
tcp=pop-2	port=109
tcp=sunrpc	port=111
tcp=uucp-path	port=117
tcp=nntp	port=119
tcp=ntp		port=123
tcp=NeWS	port=144
tcp=fsb		port=400
tcp=sysmon	port=401
tcp=proxy	port=402
tcp=proxyd	port=404
tcp=rexec	port=512	restricted=
tcp=login	port=513	restricted=
tcp=shell	port=514	restricted=
tcp=printer	port=515
tcp=courier	port=530
tcp=cscan	port=531
tcp=9fs		port=564
tcp=whoami	port=565
tcp=fmclient	port=729
tcp=ingreslock	port=1524
tcp=Xdisplay	port=6000
tcp=face	port=32000

#
#  il services
#
il=ticket	port=556
il=cpu		port=17005
il=cpunote	port=17006
il=exportfs	port=17007
il=9fs		port=17008
il=rexexec	port=17009
il=fsauth	port=17020
il=rexauth	port=17021
il=changekey	port=17022
il=chal		port=17023
il=check	port=17024
il=whoami	port=17025
il=juke		port=17026

#
#  udp services
#
udp=tftp	port=69
udp=bootpc	port=68
udp=bootp	port=67

Problems that I'm having...

[Steve]

"G. David Butler" <gdb@dbSystems.com> wrote:

> I have not gotten any response to my previous message, so I'm just wondering
> if my questions are too general for this list or if I'm just such a novice
> that everybody else knows everything about getting Plan 9 up that they
> would rather not bother with my newbie questions.

It helps if you keep your messages short and to the point.
Longer messages tend to get ignored more on ANY mailing list or newsgroup.

> The Installation instructions hint to some of the things I'm trying to do,
> (like getting a auth server going, getting bootp going, getting an cpu/auth
> server to boot from a local disk, etc.) but provide no help or pointers to
> further information.

For the FAQ, see http://www.ecf.toronto.edu/plan9/plan9faq.html

For a collections of tips, patches and other information that is too
large for the FAQ, see http://www.ecf.toronto.edu/plan9/info/

> Also, how do you get a simple vga card and monitor to work.  I have a simple
> Paradise VGA controller connected to a simple VGA monitor (color) that "vga"
> doesn't recognize.  I have no idea what "chipset" it uses or that there is
> a "clock" on the board.  I tell every other piece of software in the world
> that it is a color VGA card/monitor and it works!

Simple vga cards and monitors should work at 640x480x[12]
For higher resolutions, you will have to find out more about the card
and do some investigation. See http://www.ecf.toronto.edu/plan9/info/vga
for the vga debugging guide.

> Here is the previous message.
> =============================================
> I have a Plan 9 PC file server up (named p9fs) and have installed the
> CD-ROM to it in "allow" mode.  I then made a PC into a cpu/auth
> server (called p9auth) and rebooted it.  After getting through the
> 0.0.0.0 auth server problem, I used ed on p9auth to edit the
> /lib/ndb/local file to set up my network.  (It is weird that
> /lib/ndb/auth has hostid=authid instead of hostid=p9auth, but that is
> what the installation did, so...)  I also tarred /usr/tor to /usr/none.
> I then reboot p9fs and let it come up from the "nvram" without "allow"
> and reboot p9auth.

The hostid is a user name, not a host name. Try setting 'hostid=bootes'.
That should fix most of your authentication problems (or at least get
you one step closer).

> And who or what is bootes?  (I really don't know.  Is this id somehow
> special?)

bootes is the default name for the authid (aka hostid).
The authid is the user who runs most of the services on cpu servers
(cron, cs, keyfs, arpd, bootp, dns, listen). It is also given the 
power of the 'speaks for' relation in /lib/ndb/auth, so that it 
can authenticate on others' behalf for telnet etc.

> About the diffs in errata and the update directory.  Which should
> we use?  How do we know if there are new ones?
> 
> What is a boddle and what is it good for?

The update area seems to have subsumed the errata area.
They basically have the same purpose, but the boodles (bundle of diffs -
think of them as the plan9 equivalent to 'patch' under unix)
in the update area are easier to apply than the diffs in the errata directory.

Problems that I'm having...

[forsyth]

>>What is a boddle and what is it good for?

it's a bundle o' diffs: an rc script that when run
with appropriate options will apply a set
of changes to the reference copy of the source from the CDROM
producing an updated copy in a subdirectory, for you
to cat and diff, and eventually cp onto the active source
for a subsequent mk.

(run a boddle file without options for details of usage).

the boddle command (not in the release, fetch it from plan9.att.com)
takes a reference source and an updated version and produces
a boddle file.  it comes with a manual page; read that for details.

Problems that I'm having...

[forsyth]

>>/lib/ndb/local file to set up my network.  (It is weird that
>>/lib/ndb/auth has hostid=authid instead of hostid=p9auth, but that is
>>what the installation did, so...)  I also tarred /usr/tor to /usr/none

hostid should be the authentication USER name, not the name of
a machine.  it sounds as though you answered `authid' to the
request `Enter the site authentication user id' (`Example: bootes').
if so, the installation did the right thing, rather than something
weird, but you've undone that, and put it into a strange state.
that might explain the subsequent problems with authentication.
change it back to authid.  see the end of auth(6) `Data Base'
for details on /lib/ndb/auth.

Problems that I'm having...

[forsyth]

>>disk to read/write the nvram partition?  Should I run 9pccpudisk, and
>>if so, how do I get that on the boot partition with a kernel that
>>doesn't talk to the disk?

you could boot the machine from a floppy containing 9pccpudisk,
b.com and plan9.ini.  once booted, you can copy 9pccpudisk into the
boot partition.

Problems that I'm having...

[forsyth]

>>First question, how does a cpu/auth server running 9pccpu get to the
>>disk to read/write the nvram partition?  Should I run 9pccpudisk, and
>>if so, how do I get that on the boot partition with a kernel that
>>doesn't talk to the disk?

/sys/src/9/pc/pccpu has got #H configured, but not scsi.
if you're using scsi discs only, you'll need to use pccpudisk.
auth/wrkey and others look for #H/hd0nvram and #w/sd0nvram
on a PC.  (the file server handles it differently.)

Problems that I'm having...

[G.David]

Hello All,

I have not gotten any response to my previous message, so I'm just wondering
if my questions are too general for this list or if I'm just such a novice
that everybody else knows everything about getting Plan 9 up that they
would rather not bother with my newbie questions.

The Installation instructions hint to some of the things I'm trying to do,
(like getting a auth server going, getting bootp going, getting an cpu/auth
server to boot from a local disk, etc.) but provide no help or pointers to
further information.

Also, how do you get a simple vga card and monitor to work.  I have a simple
Paradise VGA controller connected to a simple VGA monitor (color) that "vga"
doesn't recognize.  I have no idea what "chipset" it uses or that there is
a "clock" on the board.  I tell every other piece of software in the world
that it is a color VGA card/monitor and it works!

Please help if you can or tell me where to go to get my questions answered.

Here is the previous message.

=============================================

Hello fellow Plan 9 fans,

I have read and read and read and read and read (you get the idea...)
but have a few questions for those who have experienced.

I have a Plan 9 PC file server up (named p9fs) and have installed the
CD-ROM to it in "allow" mode.  I then made a PC into a cpu/auth
server (called p9auth) and rebooted it.  After getting through the
0.0.0.0 auth server problem, I used ed on p9auth to edit the
/lib/ndb/local file to set up my network.  (It is weird that
/lib/ndb/auth has hostid=authid instead of hostid=p9auth, but that is
what the installation did, so...)  I also tarred /usr/tor to /usr/none.
I then reboot p9fs and let it come up from the "nvram" without "allow"
and reboot p9auth.

First question, how does a cpu/auth server running 9pccpu get to the
disk to read/write the nvram partition?  Should I run 9pccpudisk, and
if so, how do I get that on the boot partition with a kernel that
doesn't talk to the disk?

Now I run newuser on p9fs and auth/changeuser on p9auth to add the the
auth userid and myself.  I get errors that /adm/keys and /adm/keys.who
can't be written.  (But the entries are put in /mnt/keys.) Sure enough,
the owner of the files is adm and the authid can't write it.  So, should
I change the owner of the files on p9fs or should I wait to get p9auth to
boot from the local disk and bind a local directory over /adm with -c?

At this point I start up my terminal (called p9term, real original :-))
with the boot disk modified to bootfile=manual and at the boot: prompt
I type e!0, and it finds p9auth and p9fs (from bootp running on p9auth)
and I give it my userid and passord.  I then do the /sys/lib/newuser and
up comes 8 1/2!  I then echo -n p9auth >/env/cpu and type "cpu" (or
cpu -h p9auth) and get:

	cpu: can't authenicate: p9auth: AS protocol botch

So I reboot the terminal and login as none and get 8 1/2 and get the same
response to cpu or cpu -h p9auth!  Not a authenication problem, I guess?
(Just to make sure, I again went in as me with an incorrect password and
it would not let me attach.)

Going a little further, I telnet to p9auth (from a UNIX machine) and if I
type none to the user: prompt, I get "cpu%"!  But if I type my userid I get,
about 15 seconds later, "authenication failure".  Is this related to the
"cpu" problem?

I did see the comment someone made about the network section of
/lib/ndb/local having an ip ending with 0, and mine does (class C.)

And who or what is bootes?  (I really don't know.  Is this id somehow
special?)

About the diffs in errata and the update directory.  Which should
we use?  How do we know if there are new ones?

What is a boddle and what is it good for?

I have not used any of the "cool" tools that everybody is talking about
yet, I decided to wait till I had a "full" configuration up to both
play and get a feel for the responsiveness of the system.  I am looking
forward to the experience!

For the curious, this is a *home* network.  P9fs is a NICE EISA
motherboard 486dx/50 16Mb RAM with an Adaptec 1742 in standard mode
with a 1 Gig drive and a WD8013.  P9auth is a AMI EISA motherboard
486dx2/66 16Mb RAM with an Adaptec 1740 in standard mode with a little
40meg drive and a WD8003.  P9term is a Tandy 4000 386dx/20 & '387 8Mb ram
a WD8003 and a Logitech 3 button mouse.  (No hard drive to test a floppy
booted term.)  A fourth machine runs NetBSD and watches over the PPP link.

Thanks for any help.

David Butler
gdb@dbSystems.com