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_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-M38b41bb53e4bc0dccad36a4b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
