Newbie Question

Newbie Question

[Frank D. Engel, Jr.]

Hi,

I am hoping someone can help me with this.

I am trying as an experiment to set up a small plan9 cluster as a set of 
computers in a VMWare environment.

I am using the latest 9front distribution, and currently have two VMs 
booting plan9 with one network adapter each, on a private network (not 
connected to the internet or to the host computer), with no DHCP being 
provided by VMWare, and am attempting manual isolated configuration for now.


As far as I can tell, I was able to get an auth server running, booting 
off its own installation, with authentication enabled on its 
filesystem.  It comes up without the window system running (as a cpu 
server) and "keyfs" is among the processes which are listed when I run 
"ps"; I was able to use auth/changeuser to create user accounts for the 
hostowner users "glenda" (for my file server) and another account for my 
auth server, and was able to arrange for secstored to start with the 
system (from cpurc) and that seems to be working - I also created 
accounts in there to match the two I created with auth/changeuser, and 
both accounts are defined on the filesystem. If I do "ps | grep listen" 
I see five processes running: two owned by the host owner and three by 
"none".

I have a second system set up which I intend to be the file server (more 
storage space) and I can successfully use "rcpu" to access the auth 
server from that one.  The file server is still booting as a terminal 
rather than a cpu server, and I created matching user accounts (newuser) 
on the filesystem on the file server.


The last part of the /lib/ndb/local file on the file server looks like this:


auth=fingers authdom=9cluster


ipnet=9cluster ip=192.168.81.0 ipmask=255.255.255.0

     fs=cabinet

     tftpd=cabinet

     auth=fingers

     authdom=9cluster

     dnsdomain=9cluster


# file server

sys=cabinet ether=005056301268 ip=192.168.81.10

     dom=cabinet.9cluster


# auth server

sys=fingers ether=00505635c452 ip=192.168.81.12

     dom=fingers.9cluster



As I understand it, the next step would be to enable authentication on 
the file server.  I do this by rebooting, adding -c to the bootargs and 
at the "config:" prompt entering "noauth" twice, then "end".


When I try to do this, I am getting this set of messages:


mount: auth_proxy: auth_proxy read fd: authread: auth protocol not finished

mount: mount /root: authread: auth protocol not finished


followed by a list of partitions then a new prompt for bootargs


I am interpreting this to mean that I missed something in my 
authentication configuration, but after trying several things, I am a 
bit lost on how to proceed with this.


Can someone point me in the direction of what I might be missing?


Thank you!

Re: [9fans] Newbie Question

[cinap_lenrek]

i believe that this is due to running a with service=terminal.
this causes factotum to be started as a client with no keys in it.

the p9any auth protocol starts by the server presenting a set of
keys, auth domains and protocols, which you wont have in this
case (no keys there). which is most likely the reason the whole
thing fails.

if you boot your fileserver with service=cpu, then when factotum starts
it will prompt you for authid and password which will be the credentials
of the hostowner (of the fileserver) which should have to match what you
have on the authentication server. this information can be stored in
nvram to avoid the prompt on boot.

even if it doesnt match the auth key for (that user) on the authserver,
the fileserver should be able to boot and mount its root filesystem
as factotum talks to itself in this scenario and having the same keys
on both sides.

its just about to fail when there are no keys at all.

i hope this makes sense.

--
cinap

Re: [9fans] Newbie Question

[Frank D. Engel, Jr.]

Thank you!


When I tried bringing it up as a cpu server with auth enabled it did 
indeed make it past the errors.

I'll see if I can work things out from there.


On 12/16/19 2:27 PM, cinap_lenrek@felloff.net wrote:
> i believe that this is due to running a with service=terminal.
> this causes factotum to be started as a client with no keys in it.
>
> the p9any auth protocol starts by the server presenting a set of
> keys, auth domains and protocols, which you wont have in this
> case (no keys there). which is most likely the reason the whole
> thing fails.
>
> if you boot your fileserver with service=cpu, then when factotum starts
> it will prompt you for authid and password which will be the credentials
> of the hostowner (of the fileserver) which should have to match what you
> have on the authentication server. this information can be stored in
> nvram to avoid the prompt on boot.
>
> even if it doesnt match the auth key for (that user) on the authserver,
> the fileserver should be able to boot and mount its root filesystem
> as factotum talks to itself in this scenario and having the same keys
> on both sides.
>
> its just about to fail when there are no keys at all.
>
> i hope this makes sense.
>
> --
> cinap
>
> ------------------------------------------
> 9fans: 9fans
> Permalink: https://9fans.topicbox.com/groups/9fans/Tda6e61e03ce222c0-Mb737a8ba8068f0aae3e426d0
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
>
>

Re: [9fans] Newbie Question

[Frank D. Engel, Jr.]

ok, I seem to have run into another one.

I now have the file server booting as a cpu server with authentication 
enabled, and am trying to net boot another host from there.

I have dhcpd and tftpd running on the file server; my /cfg/pxe/default 
looks like this:


bootfile=/386/9pc

bootargs=tls

auth=192.168.81.12

fs=192.168.81.10

mouseport=ps2intellimouse

monitor=vesa

vgasize=1440x900x32

*acpi=1


The entry in /lib/ndb/local is (with "..." being the actual MAC address):


sys=thinker ether=... ip=192.168.81.20

     dom=thinker.9cluster

     bootf=/386/9bootpxe



The "thinker" system is starting the plan9 kernel over the network (it 
has no local disk); I get prompted for a user account and for now am 
just using "glenda".  I enter the password I set for the auth server, 
for secstore, and for the filesystem on the file server (I used the same 
for each), and I am getting this on "thinker":


mount: mount /root: tls error

mount -c #s/boot /root: mount 145: mount


bootargs is (tcp, tls, il, local!device)[tls]


When this happens the file server console shows this:


/bin/aux/trampoline: dial net!$fs!9fs: connection rejected


I'm not sure if this means that the file server is rejecting the 
connection from the (currently) terminal, or what might be going on...  
the "$fs" showing up on the file server console seems curious to me as I 
would have thought if that were coming from the terminal the "$fs" would 
have been translated from there?  Again not sure where to go from here...


I was originally having a problem with secstored not having a "factotum" 
file for the terminal to retrieve, but after having worked that one out 
it now stored a key in it (and is no longer asking me to set one) for my 
"dom=9cluster", so I did manage to get past that one.


I also noticed that if I retry from the bootargs prompt I get the 
additional message "ipconfig: dialicmp6: address in use", but I am 
guessing that is simply a leftover from the earlier attempt, and 
assuming I can safely ignore that...




On 12/16/19 4:40 PM, Frank D. Engel, Jr. wrote:
> Thank you!
>
>
> When I tried bringing it up as a cpu server with auth enabled it did 
> indeed make it past the errors.
>
> I'll see if I can work things out from there.
>
>
> On 12/16/19 2:27 PM, cinap_lenrek@felloff.net wrote:
>> i believe that this is due to running a with service=terminal.
>> this causes factotum to be started as a client with no keys in it.
>>
>> the p9any auth protocol starts by the server presenting a set of
>> keys, auth domains and protocols, which you wont have in this
>> case (no keys there). which is most likely the reason the whole
>> thing fails.
>>
>> if you boot your fileserver with service=cpu, then when factotum starts
>> it will prompt you for authid and password which will be the credentials
>> of the hostowner (of the fileserver) which should have to match what you
>> have on the authentication server. this information can be stored in
>> nvram to avoid the prompt on boot.
>>
>> even if it doesnt match the auth key for (that user) on the authserver,
>> the fileserver should be able to boot and mount its root filesystem
>> as factotum talks to itself in this scenario and having the same keys
>> on both sides.
>>
>> its just about to fail when there are no keys at all.
>>
>> i hope this makes sense.
>>
>> -- 
>> cinap
>>
>
> ------------------------------------------
> 9fans: 9fans
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/Tda6e61e03ce222c0-Mde0a5711ad3df989fdb26cb6
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
>
>

Re: [9fans] Newbie Question

[Frank D. Engel, Jr.]

I figured this one out...  I had missed adding the "-a tcp!*!564" option 
on the file server bootargs.

Now it is working!


On 12/18/19 6:57 PM, Frank D. Engel, Jr. wrote:
> ok, I seem to have run into another one.
>
> I now have the file server booting as a cpu server with authentication 
> enabled, and am trying to net boot another host from there.
>
> I have dhcpd and tftpd running on the file server; my /cfg/pxe/default 
> looks like this:
>
>
> bootfile=/386/9pc
>
> bootargs=tls
>
> auth=192.168.81.12
>
> fs=192.168.81.10
>
> mouseport=ps2intellimouse
>
> monitor=vesa
>
> vgasize=1440x900x32
>
> *acpi=1
>
>
> The entry in /lib/ndb/local is (with "..." being the actual MAC address):
>
>
> sys=thinker ether=... ip=192.168.81.20
>
>     dom=thinker.9cluster
>
>     bootf=/386/9bootpxe
>
>
>
> The "thinker" system is starting the plan9 kernel over the network (it 
> has no local disk); I get prompted for a user account and for now am 
> just using "glenda".  I enter the password I set for the auth server, 
> for secstore, and for the filesystem on the file server (I used the 
> same for each), and I am getting this on "thinker":
>
>
> mount: mount /root: tls error
>
> mount -c #s/boot /root: mount 145: mount
>
>
> bootargs is (tcp, tls, il, local!device)[tls]
>
>
> When this happens the file server console shows this:
>
>
> /bin/aux/trampoline: dial net!$fs!9fs: connection rejected
>
>
> I'm not sure if this means that the file server is rejecting the 
> connection from the (currently) terminal, or what might be going 
> on...  the "$fs" showing up on the file server console seems curious 
> to me as I would have thought if that were coming from the terminal 
> the "$fs" would have been translated from there?  Again not sure where 
> to go from here...
>
>
> I was originally having a problem with secstored not having a 
> "factotum" file for the terminal to retrieve, but after having worked 
> that one out it now stored a key in it (and is no longer asking me to 
> set one) for my "dom=9cluster", so I did manage to get past that one.
>
>
> I also noticed that if I retry from the bootargs prompt I get the 
> additional message "ipconfig: dialicmp6: address in use", but I am 
> guessing that is simply a leftover from the earlier attempt, and 
> assuming I can safely ignore that...
>
>
>
>
> On 12/16/19 4:40 PM, Frank D. Engel, Jr. wrote:
>> Thank you!
>>
>>
>> When I tried bringing it up as a cpu server with auth enabled it did 
>> indeed make it past the errors.
>>
>> I'll see if I can work things out from there.
>>
>>
>> On 12/16/19 2:27 PM, cinap_lenrek@felloff.net wrote:
>>> i believe that this is due to running a with service=terminal.
>>> this causes factotum to be started as a client with no keys in it.
>>>
>>> the p9any auth protocol starts by the server presenting a set of
>>> keys, auth domains and protocols, which you wont have in this
>>> case (no keys there). which is most likely the reason the whole
>>> thing fails.
>>>
>>> if you boot your fileserver with service=cpu, then when factotum starts
>>> it will prompt you for authid and password which will be the 
>>> credentials
>>> of the hostowner (of the fileserver) which should have to match what 
>>> you
>>> have on the authentication server. this information can be stored in
>>> nvram to avoid the prompt on boot.
>>>
>>> even if it doesnt match the auth key for (that user) on the authserver,
>>> the fileserver should be able to boot and mount its root filesystem
>>> as factotum talks to itself in this scenario and having the same keys
>>> on both sides.
>>>
>>> its just about to fail when there are no keys at all.
>>>
>>> i hope this makes sense.
>>>
>>> -- 
>>> cinap
>>>
>>
>
> ------------------------------------------
> 9fans: 9fans
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/Tda6e61e03ce222c0-Mb08127daf7703de537047e02
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
>
>

Re: [9fans] Newbie Question

[cinap_lenrek]

makes sense.

you need to configure the fileserver to listen on the network by
specifying bootargs on the fs like: local!/dev/sdXX/fscache -a tcp!*!564

you can verify this with the netstat command on the fs console looking
for 9fs service in Listen state.

or use "tcp" instead of "tls" on the netbooting client's bootargs.

tls is handled by a helper service that terminates the tls connection
and relays the paintext to its fileserver. if that fileserver is not
listening for network connections that it will fail like this.

it is probably a good idea to put fs= and auth= attributes in your ndb
ipnet entry, so you do not need to specify this information in plan9.ini
and dhcpd will supply this information to the client.

--
cinap

Re: [9fans] Newbie Question

[cinap_lenrek]

ok, never mind.

--
cinap

Newbie question

[presotto]

Run 'hp' and set the term/TERM variable to hp2621.  The plan9
window doesn't obey any in line cursor controls.

Newbie question

[Scott]

Peter Henning <peterh@gem.co.za> writes:
| When telnetting into unix from plan9, the terminal type shows up as
| "9win" or somthing like that....

Add to /etc/termcap:
	p9|9term|p9win: :am:bl=^G:do=^J:nl=^J:
Or just use "dumb".

| What's the simplest way of getting the right kind of termcap entry for a
| plan9 client in unix? I use plan9 at home, and need to telnet to unix at
| the office but it is pretty messy with the default settings.

/bin/hp

Speaking of that, I spent some time arranging to have the keyboard
driver deliver distinct characters for the four arrow keys (using the
same values that 9term does under unix), and arranging for hp to emit
the right function key sequences for them.  But here the Guys From New
Jersey have defeated us, since the 2621's arrow keys send a carrage
return at the end, which confuses vi and emacs (although nvi works
ok), so I never posted the patches.  (sigh.)

Newbie question

[Peter]

Hi

When telnetting into unix from plan9, the terminal type shows up as
"9win" or somthing like that....

What's the simplest way of getting the right kind of termcap entry for a
plan9 client in unix? I use plan9 at home, and need to telnet to unix at
the office but it is pretty messy with the default settings.

Thanks.