RE: [9fans] Auth problems (again?)

RE: [9fans] Auth problems (again?)

[Russ Cox]

It sounds like you're now having the same problems
Axel had a few weeks ago.  Can you make sure you
are running the latest kernel?  That is, do:

	9fat:
	cp /386/9pcdisk /n/9fat/9pcdisk

then halt and reboot.
I'm assuming you're booting from sdC0!9fat!9pcdisk;
that's how the install program sets things up.

Russ

[9fans] How Apache & Plan 9 will defeat Microsoft's Passport

[Arnaud SAHUGUET]

http://www.linuxworld.com/site-stories/2002/0918.plan9.html

Re: [9fans] Auth problems (again?)

[gabidiaz]

On Fri, Sep 20, 2002 at 12:22:36PM -0400, Russ Cox wrote:
> It sounds like you're now having the same problems
> Axel had a few weeks ago.  Can you make sure you
> are running the latest kernel?  That is, do:
>
> 	9fat:
> 	cp /386/9pcdisk /n/9fat/9pcdisk
>
> then halt and reboot.
> I'm assuming you're booting from sdC0!9fat!9pcdisk;
> that's how the install program sets things up.
>
> Russ
>

That's is!! Thank you Russ. i forgot to copy from /sys/src/9/pc


Un saludo

RE: [9fans] Auth problems (again?)

[Russ Cox]

Try updating from sources again.  It will pick
up a new program called auth/debug.

Run auth/debug.  It asks for your local user
password as well as the cpu hostowner name and
password.  It uses these to check that your
auth server is dialable and that it's giving out
correct tickets (which means it agrees with you
about those passwords).

The idea is that auth/debug will accumulate more
such sanity checks as time goes on.

For example, in my fairly complicated setup (three
p9sk1 domains), running auth/debug yields:

g% grep p9sk1 /mnt/factotum/ctl
key dom=cs.bell-labs.com proto=p9sk1 user=rsc !password?
key dom=outside.plan9.bell-labs.com proto=p9sk1 user=bozo !password?
key dom=insideout.plan9.bell-labs.com proto=p9sk1 role=speakfor user=glenda !password?
g% auth/debug
p9sk1 key: dom=cs.bell-labs.com proto=p9sk1 user=rsc !password?
	successfully dialed auth server
	password for rsc@cs.bell-labs.com [hit enter to skip test]:
	ticket request using rsc@cs.bell-labs.com key succeeded
	cpu server owner for domain cs.bell-labs.com [bootes]:
	password for bootes@cs.bell-labs.com [hit enter to skip test]:
	ticket request using bootes@cs.bell-labs.com key succeeded
p9sk1 key: dom=outside.plan9.bell-labs.com proto=p9sk1 user=bozo !password?
	successfully dialed auth server
	password for bozo@outside.plan9.bell-labs.com [hit enter to skip test]:
	ticket request using bozo@outside.plan9.bell-labs.com key succeeded
	cpu server owner for domain outside.plan9.bell-labs.com [bootes]: glenda
	password for glenda@outside.plan9.bell-labs.com [hit enter to skip test]:
	ticket request using glenda@outside.plan9.bell-labs.com key succeeded
p9sk1 key: dom=insideout.plan9.bell-labs.com proto=p9sk1 role=speakfor user=glenda !password?
	cannot dial auth server: no auth server found for insideout.plan9.bell-labs.com
	csquery authdom=insideout.plan9.bell-labs.com auth=* failed
	csquery dom=insideout.plan9.bell-labs.com auth=''
	dial net!!ticket failed: cs: can't translate address
g%

The first two sections are examples of domains
that worked: I have cs.bell-labs.com (used by plan9.bell-labs.com)
and outside.plan9.bell-labs.com (used by sources)
set up correctly.

In the third, auth/debug flags the fact that it can't
figure out the auth server for the domain and thus can't
dial it.  (That's okay because there is no auth server,
but this is a degenerate case.)

Let me know what you get when you run auth/debug and we'll
go from there.

Russ

RE: [9fans] Auth problems (again?)

[Gabriel Diaz Lopez de la Llave]

hello,

I updated again and run auth/debug tests.
The first time auth/debug says to me that password for bootes was bad,
but I changed it with auth/changeuser -p and echo asds > /dev/sdC0/nvram
to re-enter nvram stuff.

then i run auth/debug again with good results (i think)
---------------------
cpu# auth/debug
p9sk1 key: dom=ipsoluciones.com proto=p9sk1 user=bootes
	successfully dialed auth server
	password for bootes@ipsoluciones.com [hit enter to skip test]: 
	ticket request using bootes@ipsoluciones.com key succeeded
	cpu server owner for domain ipsoluciones.com [bootes]: 
	password for bootes@ipsoluciones.com [hit enter to skip test]: 
	ticket request using bootes@ipsoluciones.com key succeeded
cpu# auth/debug
p9sk1 key: dom=ipsoluciones.com proto=p9sk1 user=bootes
	successfully dialed auth server
	password for bootes@ipsoluciones.com [hit enter to skip test]: 
	ticket request using bootes@ipsoluciones.com key succeeded
	cpu server owner for domain ipsoluciones.com [bootes]: gabidiaz
	password for gabidiaz@ipsoluciones.com [hit enter to skip test]:

	ticket request using gabidiaz@ipsoluciones.com key succeeded
cpu#
--------------------


SSH connections fails with the message:


-------------------------
cpu Sep 20 11:45:21 [114] connect from 192.168.1.45!3242
cpu Sep 20 11:45:26 [114] auth_chuid to gabidiaz: writing  to
#¤/capuse: i/o count too small
/bin/aux/sshserve: auth_chuid: writing  to #¤/capuse: i/o count too
small
-------------------------

what is #¤/capuse? how can i see all bindings?

/sys/log/auth
-------------------
cpu Sep 20 12:03:53 secureidcheck: nil radius secret:
'/lib/ndb/common.radius' does not exist
cpu Sep 20 12:03:53 cr-fail authentication failed gabidiaz 213.0.106.123
cpu Sep 20 12:03:53 cr-fail gabidiaz@bootes(213.0.106.123): bad resp
---------------------

(i changed the password for that user with something silly and ease to
type but all the attempts fails)

Thank for the help!


-----Mensaje original-----
De: 9fans-admin@cse.psu.edu [mailto:9fans-admin@cse.psu.edu] En nombre
de Russ Cox
Enviado el: viernes, 20 de septiembre de 2002 7:03
Para: 9fans@cse.psu.edu
Asunto: RE: [9fans] Auth problems (again?)

Try updating from sources again.  It will pick
up a new program called auth/debug.

Run auth/debug.  It asks for your local user
password as well as the cpu hostowner name and
password.  It uses these to check that your
auth server is dialable and that it's giving out
correct tickets (which means it agrees with you
about those passwords).

The idea is that auth/debug will accumulate more
such sanity checks as time goes on.

For example, in my fairly complicated setup (three
p9sk1 domains), running auth/debug yields:

g% grep p9sk1 /mnt/factotum/ctl
key dom=cs.bell-labs.com proto=p9sk1 user=rsc !password?
key dom=outside.plan9.bell-labs.com proto=p9sk1 user=bozo !password?
key dom=insideout.plan9.bell-labs.com proto=p9sk1 role=speakfor
user=glenda !password?
g% auth/debug
p9sk1 key: dom=cs.bell-labs.com proto=p9sk1 user=rsc !password?
	successfully dialed auth server
	password for rsc@cs.bell-labs.com [hit enter to skip test]: 
	ticket request using rsc@cs.bell-labs.com key succeeded
	cpu server owner for domain cs.bell-labs.com [bootes]: 
	password for bootes@cs.bell-labs.com [hit enter to skip test]: 
	ticket request using bootes@cs.bell-labs.com key succeeded
p9sk1 key: dom=outside.plan9.bell-labs.com proto=p9sk1 user=bozo
!password?
	successfully dialed auth server
	password for bozo@outside.plan9.bell-labs.com [hit enter to skip
test]: 
	ticket request using bozo@outside.plan9.bell-labs.com key
succeeded
	cpu server owner for domain outside.plan9.bell-labs.com
[bootes]: glenda
	password for glenda@outside.plan9.bell-labs.com [hit enter to
skip test]: 
	ticket request using glenda@outside.plan9.bell-labs.com key
succeeded
p9sk1 key: dom=insideout.plan9.bell-labs.com proto=p9sk1 role=speakfor
user=glenda !password?
	cannot dial auth server: no auth server found for
insideout.plan9.bell-labs.com
	csquery authdom=insideout.plan9.bell-labs.com auth=* failed
	csquery dom=insideout.plan9.bell-labs.com auth=''
	dial net!!ticket failed: cs: can't translate address
g% 

The first two sections are examples of domains
that worked: I have cs.bell-labs.com (used by plan9.bell-labs.com)
and outside.plan9.bell-labs.com (used by sources)
set up correctly.

In the third, auth/debug flags the fact that it can't
figure out the auth server for the domain and thus can't
dial it.  (That's okay because there is no auth server,
but this is a degenerate case.)

Let me know what you get when you run auth/debug and we'll
go from there.

Russ

Re: [9fans] Auth problems (again?)

[Russ Cox]

ipsubmask= is now ignored.
the code searches all possible submasks
when walking the database.

on your cpu server, if you run

	cat /mnt/factotum/ctl

what do you see?

RE: [9fans] Auth problems (again?)

[Gabriel Diaz Lopez de la Llave]

ok, ipsubmask was removed from my ndb file.

# cat /mnt/factotum/ctl
key dom=ipsoluciones.com proto=p9sk1 user=bootes
#

I must start a factotum instance from cpurc for bootes user?

thank you.

-----Mensaje original-----
De: 9fans-admin@cse.psu.edu [mailto:9fans-admin@cse.psu.edu] En nombre
de Russ Cox
Enviado el: miércoles, 18 de septiembre de 2002 22:20
Para: 9fans@cse.psu.edu
Asunto: Re: [9fans] Auth problems (again?)

ipsubmask= is now ignored.
the code searches all possible submasks
when walking the database.

on your cpu server, if you run

	cat /mnt/factotum/ctl

what do you see?

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Charles Forsyth]

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

i think that's what we found when we did VESA-based
work for Inferno.  i'm happy to parcel that up yet
again if anyone's seriously interested in adapting it
for Plan 9, or even current Inferno, or anything else
for that matter, but it takes time to find all the bits,
so be reasonably sure you're going to have the stamina.
other `buts': it relied on software cursors in Inferno;
it relied on non-trivial changes to the bootstrap code
to do real-mode (unreal mode more like) BIOS calls
to gather data before loading the kernel, because cards
didn't implement the 32-bit variants; and it's all
a bit involved.

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

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c
Date: Wed, 18 Sep 2002 07:38:59 -0400
Message-ID: <c638d4fcbdf1f3ffb4afccb80d0178b0@plan9.bell-labs.com>

> VBE/AF Standard 1.0

Right.  If I recall correctly and nothing has changed since
then (neither is overwhemlingly likely; it was 1999), most
cards don't bother implementing this part of the standard.

Russ

[9fans] Auth problems (again?)

[Gabriel Diaz Lopez de la Llave]

Hello there,

I updated my 4ed. Plan9 Standalone cpu server a week ago (replica/pull
-v /dist/replica/network like usual) and it stopped to authenticate the
users. (The upgrade is these that include the new gs stuff)

Using the telnet client you can see the message:

"auth server protocol botch"

I read a post from Russ Cox about that and checked my ndb file.
All looks fine (before upgrade all works :?)

--- /lib/ndb/local ----
#
database=
	file=/lib/ndb/local
	file=/lib/ndb/common

ipnet=ipsoluciones.com
	ip=213.0.106.64
	ipmask=255.255.255.192
	auth=213.0.106.123
	authdom=ipsoluciones.com
	dnsdomain=ipsoluciones.com
	dns=213.0.106.67
	dns=213.0.106.68

ip=213.0.106.123 sys=cpu ether=00047574b319 dom=cpu.ipsoluciones.com
ipgw=213.0.106.65


----------

(I try the ipsubmask syntax like:
	ipnet=ipsoluciones.com
	ip=213.0.106.0
	ipmask=255.255.255.0
	ipsubmask=255.255.255.192
width the same results
what's the better/correct choice?)


In ssh logs file I can read logs like:

"/bin/aux/sshserve: got unexpected <early oef: short net read: needkey
dom? proto=9psk1 user?> message"

" cpu Sep 18 21:52:28 cr-fail gabidiaz@bootes(IP)"

I re-enter all auth passwords (even nvram pass for bootes, and authdom
stuff).

Someone can tell me where I must look?

Thank You!