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_len...@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
