Re: [9fans] xscreensaver ports

Re: [9fans] xscreensaver ports

[okamoto]

>more to come, subject to time constraints :)

I'm using galaxy.c to show students how we can write very short
graphic program in Plan 9.   Thanks a lot!

Kenji

[9fans] authdom still

[matt]

Okay I'm not getting something here

here's my current /lib/ndb/local

but I still get the dreaded
authentication failure:auth server protocol botch

/me giving up :(

sys=tiger dom=tiger.punx ip=192.168.1.109 ether=00c0f0404d88

sys=gw dom=gw.punx ip=192.168.1.1 ether=002078C5EB1A

ipnet=lucid ip=192.168.1.0 ipmask=255.255.255.0
    ipgw=gw
    dns=194.168.4.100     # my isp
    dns=194.168.8.100     # my isp
    dnsdomain=punx
    auth=tiger authdom=punx
    cpu=tiger

Re: [9fans] authdom still

[Jack Johnson]

matt wrote:
> but I still get the dreaded
> authentication failure:auth server protocol botch
> 
> /me giving up :(
> 
> sys=tiger dom=tiger.punx ip=192.168.1.109 ether=00c0f0404d88
> 
> sys=gw dom=gw.punx ip=192.168.1.1 ether=002078C5EB1A
> 
> ipnet=lucid ip=192.168.1.0 ipmask=255.255.255.0
>     ipgw=gw
>     dns=194.168.4.100     # my isp
>     dns=194.168.8.100     # my isp
>     dnsdomain=punx
>     auth=tiger authdom=punx
>     cpu=tiger

Hi Matt,

I'm new at this, too, so take this all with a grain of salt.

The man pages say that the configuration should walk the IP path, but I 
found that I had to specify the auth and authdom for the specific host 
as well.  It may be different if your CPU server is also your DHCP 
server, I'm not sure.

So, something to try is changing your /lib/ndb/local entry for tiger to:

sys=tiger dom=tiger.punx ip=192.168.1.109 ether=00c0f0404d88
	auth=tiger authdom=punx

In my environment, my CPU server is not my DHCP server, and configured 
similarly to what you have going on currently, ndb/ipquery would not 
return auth or authdom values for hosts in the ipnet.

For instance, I'm guessing using your current config that if you try:

	ndb/ipquery ip 192.168.1.109 auth

you'll get a blank response, even though the documentation seems to say 
otherwise.  The way I read it, 'ndb/ipquery ip 192.168.1.anything auth' 
*should* report auth=tiger but I haven't been able to replicate that 
with any success (yet).

Someone please correct me if I'm wrong.

If you do get the correct auth response from the above command, a couple 
of other things you could check (speaking from experience) is to ensure 
that include=/lib/ndb/auth is in your /lib/ndb/local (if that's where 
you made the change suggested in the wiki), make sure the information 
and password you entered when the nvram checksum failed is the same that 
you entered for bootes using auth/changeuser.  One allows passwords of a 
different length than the other, so choose wisely.

Other than that, good luck!

-Jack

Re: [9fans] authdom - working

[matt]

> If you do get the correct auth response from the above command, a couple 
> of other things you could check (speaking from experience) is to ensure 
> that include=/lib/ndb/auth is in your /lib/ndb/local 

added that

I'd also skipped over 
cd /rc/bin/service.auth
mv authsrv.il566 il566
mv authsrv.tcp567 tcp567

but still no workee

it was then connecting but failing to authenticate

the 4th ed prompts  
secstore key:
and
password :

not knowing what secstore key was I'd put a dummy value in for both. 
The password was really bootes password wasn't it?

Well I made it the same as the one i'd set for auth/changeuser bootes

and then I added the  stuff for cpu & FS 

disk/kfscmd 'listen il!*!17008' 
echo '#!/bin/cpu -R' >/rc/bin/service/il17010
echo '#!/bin/cpu -R' >/rc/bin/service/tcp17010

and next boot it worked

end of fiddling ah, welcome back plan9, it's been too long away.

M